{"id":221,"date":"2018-02-26T22:53:12","date_gmt":"2018-02-26T20:53:12","guid":{"rendered":"http:\/\/testhexen.de\/?p=221"},"modified":"2018-02-26T23:01:40","modified_gmt":"2018-02-26T21:01:40","slug":"scriptless-automated-testing-a-solution-for-business-testers","status":"publish","type":"post","link":"https:\/\/testhexen.de\/?p=221","title":{"rendered":"Scriptless Automated Testing \u2013 a Solution for Business Testers?"},"content":{"rendered":"

Looking for failures in a system requires curiosity, professional pessimism, a critical eye, attention to detail, good communication with development peers, and experience on which to base error guessing.\u201d This sentence from the CTFL syllabus would also scare you away? It sounds so depressing. Professional pessimism. Who wants that? I guess testers only. They can cope. And find their satisfaction just knowing that it serves a good purpose.<\/p>\n

But then, there are situations, where you have to involve people into your team, who are not testers by heart. As Georg Haupt<\/a>from OOSE described in the talk he gave at the last StugHH event<\/a>, there are situations, where people from helpdesks or other non test-trained areas \u2013 like end users of large systems, would be of large benefit. Let us call these helpful people \u201cbusiness testers\u201d.
\nBased on a testing survey in 2015 by HS Bremen, HS Bremerhaven, TH K\u00f6ln<\/a>, about 81% of the companies apply use case based testcase creation methods in order to get a good test coverage. It only sounds reasonable to then also involve business testers.<\/p>\n

But \u2013 we want to automate tests! So, on top of trying to teach\/implant the end users some testing gene, we also have to teach them to automate tests? NO WAY.<\/p>\n

To the Rescue<\/h2>\n

Luckily, there are some old and actually well-known approaches to shield the business testers from technology. MicroFocus ALM (better known as HP ALM or even Quality Center) has its \u201cBusiness Process Testing\u201d, where basically, using keywords, reusable, parametrizable script snippets (to be coded in UFT) can be called, even by a person not knowing the processes behind.<\/p>\n

\"\"
Relation between screen view and script view (from Georg’s Presentation)<\/figcaption><\/figure>\n

Tricentis with TOSCA has something they call \u201cModel-based Test automation\u201d. I have not yet worked with TOSCA, but it the approach is described<\/a> as \u201cModel-based test automation (that) decouples the test cases from the system’s underlying technology. You can think of TOSCA\u2019s automation model as a reverse-engineered interface catalogue of the system-under-test, in which modules (components of the automation model) are proxies of the interfaces.\u201d Another benefit is described<\/a> as \u201cOne major feature where this tool is gaining leverage over other automation tools is due to its model based technique where a model of AUT (application under test) is created instead of scripts for test automation. All the technical details about AUT, test script logic and test data are separately saved and merged together at the time of test case execution. The central model gets updated the moment any change is encountered in elements of the application.\u201d So the major difference seems to be that for TOSCA you do not have to code the stuff behind the scenes.<\/p>\n

\"\"
Test data entry view (from Georg’s presentation)<\/figcaption><\/figure>\n

Anyways, before I get into product discussions here: The main benefit for both variants is that in the end, the test case looks to the end user almost like an excel sheet, where he only has to tell per field per block, which value to enter. Such an entirely data driven approach can really help to gap fear about testing. Business testers love Excel!
\nIn my current project I have quite a few of those business testers. While they still learn testing<\/a>, they will also support automation. We do not use any of the above products, but something specific to the product being implemented after some customization. In the end, here we also will be able to use excel sheets to have a data driven approach to create test cases. Depending on the modularization concept chosen (the span of the functions in ALM business testing, the scope of the model in TOSCA, the length of a script in my project) this already now proves to be very helpful.<\/p>\n

Practical Stuff<\/h2>\n

As this is a work in progress here a list of observations we made up to now \u2013 which I think will be the same for any of the tools:<\/p>\n\n\n\n\n
Good practices<\/td>\nPossible Pain Points<\/td>\n<\/tr>\n
\n
    \n
  • The span of a script is within one technology, and within a logically bound piece of a business process (for example not necessarily per screen, but few screens that are always used together)<\/li>\n
  • It would be good to be able to have a hierarchy of scripts in order to be able to reuse already written snippets<\/li>\n
  • Entering data should already take care of validation of values against formats or lists of values in order to keep frustration of testers limited.<\/li>\n<\/ul>\n

     <\/td>\n

\n
    \n
  • How to implement behavior based on decisions? Or loops?<\/li>\n
  • What if on a dynamic screen there are fields available depending on a previous data entry? Do I need then two modules or can I do something with the script?<\/li>\n
  • If the data entry form is depending on the script, how do you cope with situations where you want to use the very same data in two different scripts?<\/li>\n
  • Modularization concept has to support reuse of code so that code duplication is minimal in order to make scripts maintainable.<\/li>\n
  • What if the AUT changes? Is the testing code decoupled?<\/li>\n<\/ul>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

    Depending on the tool chosen, the exposure of the test scripts to the business tester is very different. While Micro Focus suggests to have the scripts written by a test programmer and hidden to the end user, Tricentis with Tosca says, that most code is automatically scanned and there is no need to see it. In my project we also have a simple scripting language that is definitely human readable. Really complex behaviors cannot be scripted with this, nor loops. The first problem can be resolved by subprograms that then can be used in the scripts. The idea is to train the business users at least to create the test data to run the script but maybe also to update smaller bits inside the scripts. We believe that they can fix smaller issues themselves. However, the overall setup is being done by a test automation engineer.<\/p>\n

    First experiences show that the business testers do appreciate to supply test data in a format that very much looks like a list of fields on the screens they use for testing. But we are not into the really difficult testing tasks yet. So, we are still collecting experiences \u2013 and any comments are really welcome!<\/p>\n","protected":false},"excerpt":{"rendered":"

    Looking for failures in a system requires curiosity, professional pessimism, a critical eye, attention to detail, good communication with development peers, and experience on which to base error guessing.\u201d This sentence from the CTFL syllabus would also scare you away? It sounds so depressing. Professional pessimism. Who wants that? I …<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[19,12],"tags":[26],"class_list":["post-221","post","type-post","status-publish","format-standard","hentry","category-exploring-methods","category-stughh","tag-data-driven-testing"],"_links":{"self":[{"href":"https:\/\/testhexen.de\/index.php?rest_route=\/wp\/v2\/posts\/221","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/testhexen.de\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/testhexen.de\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/testhexen.de\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/testhexen.de\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=221"}],"version-history":[{"count":14,"href":"https:\/\/testhexen.de\/index.php?rest_route=\/wp\/v2\/posts\/221\/revisions"}],"predecessor-version":[{"id":237,"href":"https:\/\/testhexen.de\/index.php?rest_route=\/wp\/v2\/posts\/221\/revisions\/237"}],"wp:attachment":[{"href":"https:\/\/testhexen.de\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=221"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/testhexen.de\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=221"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/testhexen.de\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=221"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}