The following article is a guest post to Zephyr from Brain J.Noggle.
An agile-flavored software process should produce runnable code quickly and new code every iteration. Agile can put time and coverage pressures on any testing approach, but it puts extra pressures on automated testing - especially if team members don’t understand the nature and limitations of automated testing. You can improve your automated testing process by educating the team about proper automated testing techniques and by writing the automated test code to make it easier to update over time. This article will help you do both.
Educate stakeholders on automated testing limitations and strengths
Too often, product managers and unseasoned developers think automated testing is the easy way to quality. They hope that an automated tester can write the tests at the same time the developers write the code and that the automated tests will find defects in new functionality the first time the tests are run. To ensure a successful automated testing effort, you need to make sure that the other team members understand:
- Automated tests verify existing functionality and don’t detect bugs in new functionality.
- Automated tests have a maintenance cost; existing test code must change to reflect changes to the application code.
- Testers writing automated tests are not testing new functionality with the rigor that a manual tester explores the code.
This little bit of education can clear up some faulty expectations and ensure that the automated testing process works toward automated testing’s strengths instead of misconceptions.
Use the right tools to test
To some people, automated testing means simply automated user interface testing, such as using Selenium Webdriver to test Web pages. However, if the website acts through an Application Program Interface (API), you should consider also using automated test tools to submit API requests and verify data through them. Once the API is mature, it might prove slower to change than Web designs and can verify data processing functionality closer to the code than through the interface.
Encourage developers to make elements uniquely identifiable
When the developers build the interfaces, they might only give the elements and controls default names instead of specifying unique identifiers or IDs for each one. Your test code might then have to rely on fragile tricks to identify the elements, such as looking for the Register form’s Required Div’s Group Div’s Edit Box 1 edit box (it sounds worse in English than in code, if you can believe it). If the developers give edit box a unique and comprehensible name instead, such as FirstName, your code should be able to find it no matter how the designers shuffle the controls on the page.
Only write automated tests for (relatively) mature code
If you start writing automated tests too early, you’ll find that you’re constantly changing the test code to match changes in the application code. Because the nature of agile development process invites input and change requests early and often when developing a feature, the interface and even the workflow of a feature will change while it’s under active development.
If you can write your automated test code after a feature has matured and stabilized, you’ll spend less time rewriting the test code. You can often schedule this development at the beginning of the iteration after the feature is stable to best use this time before the new code in an iteration becomes testable.
Make your code as modular as possible
When you build your test code, consider the discrete operations you might ask of your tests and write functions or methods to encapsulate those actions. For example, when interacting with an Add User form, you could write a single function that clicks the button for the form, enters the data in the form, clicks Submit, and waits for a success page. Instead, you should create separate functions to click the button to display the form, to enter the data, to click Submit and to wait for the success message or page. That way, when the Edit User feature becomes available, you can reuse the function that enters the data and only write new functions for Click Edit User and, if needed, click Submit and wait for success.
Modular code can minimize the impact of changes to the default workflow much as proper use of unique identifiers can insulate you from reorganization within a page.
Separate data handling and log writing from interface interaction
While making your code modular, be sure to separate code that reads or manipulates test data, code that writes to log files, and other non-interface-specific logic into functions your code can use regardless of what page or operation it tests. This will make actual interface code easier to read when it comes time to update the interface automation, but it will also make it quicker to update the test code when the data the application needs changes.
An Agile process should produce software that evolves and best meets stakeholder needs as they perceive them and as they learn about them by using the software. This can put some stress on testers - particularly automated testers - that you can help mitigate through educating the whole team, a bit of planning and smart test code design. These tips are but a few that can help make your life easier and your tests more productive. Please share tips and insights you have in the comments below.
About the Author: Brian J. Noggle has worked in quality assurance and technical writing for over a decade, working with a variety of software types and industries. He currently works as a freelance software testing consultant through his own company, Jeracor Group LLC and has published a novel set in the IT world, John Donnelly's Gold.