Does that sound familiar? It’s a pretty typical comment we hear from testing manager to a tester.
The time between releases is increasingly compressed; today a typical software project deploys every other-week, if that. Meaning that all of the testing for the sprint, or micro-project, must be embedded in those two weeks. The need for speed is driving business into a digital transformation (article by SDTimes).
At best, testers get half of that time to do their work, and not every project runs according to plan. For example:
Programmers might take longer than expected to get code in a testable state
Testers might find show stopper bugs that take time to fix and prevent further testing
Sometimes the test case management system is doing more to hinder than help
Successful testers must be able to adapt in a wildly changing environment.
So what can you do about it?
Below I have mapped out five tips to help software testers continually improve test case management by doing more with less. Hopefully it will give you a good spot to start or at least get you thinking about how to improve your software testing processes.
1) Powerful Test Cases
Testers use a variety of test case management techniques to expose problems in software. Domain testing focuses on how a user might change data, scenario testing is designed to replicate what a real user might do, and risk based testing is a way to organize testing work based on ways the product might fail. Typical test cases written in a prescriptive, step-by-step way cannot with all of these techniques. Instead of adjusting to new information, the tester gets locked into following instructions.
Powerful test cases leave either:
1) leave out the detailed procedural steps
2) replace these detailed steps with test objectives, goals, and areas of opportunity that allowing the tester to use her own creativity and skill.
A test idea with minimal detail introduces variation. Each person that performs that test will have new and different ideas about what is important to explore, and how that work should be done. This variation helps testers find important new bugs.
2) Moving Past the Specification
Testers run into problems when they rely on the specification without question. A specification might explain that a text field should only accept 5 characters but not describe the many failure conditions. For example, what should happen when users want to enter far more than 5 characters, or submits the page with no value in that field?
Strong testers understand that specifications are often incomplete, misunderstood, or nonexistent, and learn to reach out to product managers, programmers, other testers, and other pieces of software for guidance.
3) Better Test Case Management
Tools like test case management systems are designed to make teams more effective. Sometimes these tools have the opposite effect. Bloated tools make it difficult for a tester to perform simple tasks like adding notes to supplement a test case. Other times, these TCM tools can only do one thing: manage test cases. However, testers need to think about what test case management techniques they want to use during their testing pipeline. One example that most TCM don’t do well is providing tools and workflow for session based and exploratory testing.
Never adopt restrictive tools that force a tester to follow a procedure rather than encouraging creativity. Better tools incorporate TCM, but they also provided other tools for help testers share information about their ideas, what they tested, and what they found, without slowing them down.
4) Adjust Testing Scope
There is always more testing to be done than time available. Thinking about testing in terms of risk can help testers make tough decisions. A single sprint might include a complicated new feature for an existing happy customer, a small change for a customer that is considering cancelling their contract, and a new feature that will be used in sales demonstrations.
A tester that is aware of those features can make a choice. He might choose to spend less time on the feature for the happy customer, so that the unhappy customer and the sales features are more reliable. The tester might ask for help from a team member so that all the changes get tested thoroughly. Or a team might try collaborative tools like pairing to find problems before the change is released. Testers who are aware of their time constraints and risks can make better choices about testing priorities.
5) Automating the Right Things
Testing of the user interface is usually the first thing testers automate, but it might not best choice depending upon the type of UI. For example, web automation projects testing the Graphical User interface (GUI) often fail because of difficulty keeping the tests in sync with the latest version of the GUI and because the difficulty of creating tests that consistently return accurate results. However, leveraging a UI automation tool that specializing on Internet of Things devices, would provide test automation value that would never before been possible.
Most teams will get more value by automating closer to the code, at the API or lower. Building tests at this level helps programmers create a better product, and alerts them earlier when a new problem is introduced.
Doing More With Less
Time tables are short in modern software development, and only getting shorter. Testers that cannot adapt are at risk of becoming obsolete. Few, more powerful, more general test cases, managed well, coupled with smart automation can help testers provide information that matters on-time.