We’re republishing a series of articles from LogiGear and our LogiGear Magazine that we think merit second looks!
Tools work at the service of people. People talking to each other, working together and solving problems is much more important than following a process or conforming to a tool. This also means someone who tells you a tool will solve your Agile problems knows nothing about Agile. Companies that invested gobs of money into project management or test management tools to replace successful practices of software development made certain tool vendors rich and many software development teams unhappy.
There are a couple of rules to remember when it comes to tools and Agile. First, tools need to fit teams not the other way around, and then, test teams need to grow in their technical responsibility. Adding management tools adds overhead, reduces efficiency, and limits the Agile idea of self-directing teams. However, communication tools can help in distributed development situations and scaling into large organizations.
Often when beginning an Agile project, there is a need for some re-tooling in order to be successful. The same set of tools used in traditional development may not be enough to support rapid communication, dynamic user story change and ranking, and increased code development.
The groups of tools of specific use to test teams focused on here are:
- Application Lifecycle Management (ALM)
- Test Case Management Tools
- Continuous Integration Tools
- Automation Tools
Application Lifecycle Management Tools (ALM)
Often tools are discussed in relation to the Application Lifecycle. Naturally tool vendors refer to their large suites as Application Lifecycle Management Tools (ALM). There are multitudes of tool sets in the ALM space with some minor category tools in the ALM spectrum that relate specifically to testers.
The use of ALM tools has grown as teams have become more distributed, faster and more dynamic, and at the same time coming under increased pressure from executives to be more measurable and manageable. When Agile as a development framework grew explosively, the anti-tool development framework got inundated by tools.
ALM tool suites generally manage user stories/requirements, call center/support tickets and also help track planning poker, store test cases associated with user stories and bugs. The big leap forward with current ALM tools was the ability to link to source control, unit testing frameworks, and GUI test automation tools. There are good reasons for using ALM tools:
- To communicate what teams are doing and where they are in a project.
- When working with distributed/offshore teams.
- For working on projects with large product backlogs, or with dynamic backlogs of changing value.
- Where test teams are still required to produce many artifacts—like test cases and bug reports, build reports, automation result report, and status reports.
These are all good and beneficial reasons to use tool, but a word of caution: the tool can’t control you or the use and benefit of going Agile will be diminished.
Test Case Management Tools
Many test organizations have migrated to using an enterprise wide test case management tool (TCM) for tracking test cases, bugs/issues and support tickets in the same repository. Strict process says a tool to manage test cases is not necessary in Agile and any test teams have mixed feeling about these tools—sometimes feeling chained to them as they inhibit spontaneous thinking and technical creativity.
Continuous Integration
In rapid development, getting and validating a new build can kill progress. Test teams can use a continuous integration tool to make a big build validation process. This does not mean writing the unit tests – it means re-run, for example, the J-unit harness of tests. Test teams taking over the continuous integration process is what separates consistently successful teams from teams that enjoy only occasional success.
Test Automation
When discussing automation in Agile with team members, scrum masters or anyone knowledgeable in Agile, the part of testing that a test team needs to automate is not unit testing, that automation comes from developers. Test teams need to focus on:
- Automated smoke/ build validation tests.
- Large automated regression suites.
- Automated user story validation tests (typically a test team handles this. But- there are very successful groups that have developers automate these tests at the unit, api or UI level).
- New functionality testing, which can be difficult to automate during a sprint. This requires a very dynamic and easy method for building test cases.
Below are the main points about test automation tools in Agile:
- The need for massive automation is essential.
- The need for a manageable and maintainable, extendible framework—like tools that support action-based testing.
- Developers need to be involved in test automation—designing for testability and automation will solve automation problems.
- Training is key to building a successful automation framework.
- Tools alone never solve automation problems. Better automation design solves automation problems.
Summary:
Tools in Agile need to be used to fit people, not the other way around.
Tools need to be easy to use (from your perspective- not the tool vendor’s perspective) and have low time and management overheads.
