How to fit automated testing into scrum, and keep testers in sync with other teams
One of the benefits of the approaches of agile projects is their friendliness towards testing. The testing activities, and the testers with it, are integrated into the teams, and testing and quality are redefined as team responsibilities. Automation nowadays is a must-have that needs to be addressed. Automation happens on multiple levels in a system, starting with unit tests. Here, we’ll focus on functional tests at the UI level.
For functional tests timely automation can be difficult, due to UI dependency. A team might be “done” with work items in a sprint, but the development and automation of functional tests might not have been finished yet. Having to do such automation later is unattractive; it places the testing and automation out of sync with the other activities in the team, making it harder to cooperate.
A first step to make testing manageable in short sprints is to use a domain language approach. This can help the whole team express and communicate tests quickly. We use keyword based “actions” that are easy to manage, use and implement, and is supported well with our product TestArchitect™. We also have a tool to translate actions to and from Behavior Driven Development (BDD) scenarios, another domain language approach.
Actions become the basis of the modular test design method called Action Based Testing (ABT), which organizes the tests into “test modules”. A main distinction is made in ABT between modules for “business tests” and for “interaction tests”. In a business test one would use business level actions like “rent car” or “check balance”, while in an interaction test the actions would be at a lower level, like “select menu item” or “check window exists”.
To get to automated testing “done” in agile sprints we ended up with a process that is shown in the picture. When the sprint starts the testers create the higher business level tests. These tests stay at the same level as the user stories and acceptance criteria. Further into the sprint, interaction tests are developed, when the user interfaces have become stable enough to make it worthwhile.
Also very early in the sprint interface mappings are made. We recommend that those are created without the use of an interface viewer or other spy tool. This encourages the team to define easy to maintain identifying properties for upcoming UI elements, like the “name” property in Java. This also encourages better collaboration between QA and Dev teams.
When the UI becomes available, the team is ready with:
- Test Modules
⇒ Business Level Tests
⇒ Interaction Tests
- Interface mappings
- Actions – At this point actions are well thought out and finalized but not yet automated
An additional way to relieve teams and keep automated testing in sync with development is something we like to call “Outsourcing 2.0”, which is part of our services offering as a company. Under this model, excess workload for test development and automation is handed over to a service group that can grow and shrink over time, and can service multiple agile teams. This way the attention of all team members can be focused on new functionalities.
Hans leads LogiGear’s research and development of test automation solutions, and the delivery of advanced test automation consulting and engineering services. He is a pioneer of the keyword approach for software testing organizations, and he assists clients in strategic implementation of the Action Based Testing™ method throughout their testing organizations.
Hans is also the original architect of LogiGear’s TestArchitect™, the modular keyword-driven toolset for software test design, automation and management. Hans is an internationally recognized expert on test automation, test development and testing technology management. He is coauthor of Integrated Test Design and Automation (Addison Wesley, 2001), and speaks frequently at international testing conferences.
Hans holds a Master of Science in Computer Science from Free University, Amsterdam.
Subu Baskaran has over 11 years of experience in leading large, complex outsourcing projects both from onsite and offshore. He has a Bachelor’s degree in electronics and instrumentation engineering from Sastra University, India, and an MBA from Cass Business School, London.