Developer

The most important thing to learn about test automation is the difference between writing code to develop an application and code to automate tests

Both systems (should) use:

• GOOD PROGRAMMING PRACTICES
• GOOD DEVELOPMENT PROCESS

when developing an application one should:

• write the application with the end user in mind
• give the user the possibility to select the next action
• show with infos, warnings or error messages how the application is doing
• document the code (best using unit tests)
• do pair programming
• refactor the code

when developing test automation one should:

• always remember that there is no 'user', only the tool and it is inherently stupid! See UNATTENDED TEST EXECUTION
• plan for possible incidents because otherwise the tool just stops in its tracks or races along trying to drive the application even if it is still waiting for some input and doesn't react (EXPECT INCIDENTS)
• remember that the automated tests not only drive but also react to the System under Test (SUT). If the SUT takes different times to execute the same action (depending on the data, the database, the network etc.) the automated test must be able to wait a longer or shorter time (VARIABLE DELAYS)
• make sure that tests can be executed at any time and on any machine and eventually in parallel (INDEPENDENT TEST CASES, DEDICATED RESOURCES, PRIORITIZE TESTS, PARALLELIZE TESTS)
• write logs with infos, warnings or error messages to show how a test is doing (READABLE REPORTS, EASY TO DEBUG FAILURES)
• PAIR UP
• refactor not only the code but also the data and the expected results (REFACTOR THE TESTWARE)

Back