{"id":1042,"date":"2015-12-23T12:26:35","date_gmt":"2015-12-23T12:26:35","guid":{"rendered":"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/?p=1042"},"modified":"2024-02-26T09:32:34","modified_gmt":"2024-02-26T09:32:34","slug":"recipes-for-test-automation-part-1","status":"publish","type":"post","link":"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/recipes-for-test-automation-part-1\/","title":{"rendered":"Recipes for Test Automation (Part 1) \u2013 Soup"},"content":{"rendered":"\n

Ingredients, appliances, and who is the chef<\/strong>?<\/strong><\/h2>\n\n\n\n

A colleague recently approached me and asked me whether I know a recipe for good test automation. I told him that, just like with a good soup, it takes more than a recipe: The kitchen appliances, ingredients, and the cook are important as well. Accordingly, the project framework, the selection of the test tools, and the testers involved in the test automation are decisive in test automation.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n
<\/div>\n\n\n\n

How do we find out if the framework is right for test automation? Generally speaking, we have to differentiate between software projects that are still in the pre-planning stage where test automation is planned from the start, and projects that are already underway, where test automation is intended to support the project.<\/p>\n\n\n\n

First of all: The earlier well-planned test automation is started, the more likely it will be successful. This is often due to the fact that the initial effort involved in test automation is underestimated, and the benefits, in terms of figures at least, are not reaped until after the project has been completed.<\/p>\n\n\n\n

To counter this, a project that is about to start requires good planning, and a project in progress requires a preliminary study of the ongoing processes, test cases, and framework. Such a preliminary study is used to analyze and evaluate the existing test case portfolio, the test object and the testers\u2019 knowledge, among other aspects. This way, we can identify the project\u2019s true weaknesses in the field of testing.<\/p>\n\n\n\n

Test automation is often used to try and solve problems that have nothing to do with the test automation, and that can sometimes even be exacerbated by it. Just like with cooking: When the soup tastes bad, replacing the cook with an automaton will not necessarily improve it. The result will, in fact, often be even worse\u2014just think of the coffee maker out in the hallway. It is important to ensure that the prerequisites for the test automation have reached a minimum quality before you can start selecting the tools or begin the actual automation. Test automation is the dab of cream that tops off the soup, i.e. test automation can only be successful with a well-functioning test process. The test cases also need a sufficient level of detail for automation The level of detail required depends on the level of technical know-how the tester has in regard to the test object. Some people might suggest that the technical department, i.e. those who have the technical know-how, could carry out the test automation. However, that is usually not a good idea because these colleagues cannot spare the time. On the one hand, their everyday work always comes before the test automation in terms of priorities, and on the other hand, they would need to gain proficiency in the use of the tools and testing experience first. Therefore, the technical department should preferably provide the manual test cases with a sufficient level of detail that the tester understands even without knowledge of the domain. The tester then uses their testing experience and knowledge of the tools to carry out the automation.<\/p>\n\n\n\n

It is illusory to believe that you can automate everything, which is why the test cases are prioritized in the preliminary study. In this context, it must be checked whether the test object or the software that is to be tested can be automated. Dynamic object IDs that change every time they are requested, for example, pose a particular challenge in test automation.<\/p>\n\n\n\n

And then, like the cook in the kitchen, the tester who carries out the test automation also plays an important role. Firstly, they need the necessary knowledge of the tools, and secondly, they have to be able to decide where, specifically, test automation is worthwhile. For example, it makes no sense to automate a feature of the software that is rarely needed, yet takes great effort to automate.<\/p>\n\n\n\n

This is why you should always adhere to the recipe:<\/p>\n\n\n\n