It's been my experience that a highly performing lean software development team moves quickly and, as a general rule, produces code with good automated test coverage.
In the early stages of my role providing quality assurance on a lean project, I struggled a little bit to figure out exactly where I fit in as part of the product team. The developers wrote their own tests, so creating automated tests wasn't part of my role. The product owner wrote the acceptance tests for each story, so that wasn't up to me either.
I think it's typical for a QA professional on their first lean project to struggle a little bit to figure out exactly where they fit in, just as I did. More than two years later, I have a pretty good idea of what a tester can do to add value on a healthy, high performance lean team. Here are four key areas in which a QA professional can contribute.
Exploratory testing is a style of testing that emphasizes the personal freedom and responsibility of the tester, by allowing the design and execution of a "test" to emerge simultaneously. This is very different from scripted testing, where the design of the experiment happens before its execution, often in the planning stage of a phase-based project. @73895
In exploratory testing, a tester uses their skills, instincts and testing oracles to hunt for bugs in a specific area for a short period of time (about 45 minutes). The focus of their testing is defined by the project charter, a brief document that outlines the goals of their test session and captures their notes and assessment of their testing activities.
Exploratory testing fills an important gap in the lean software development process by attempting to find the bugs that were not covered by the automated tests created by the developer of the feature. Test oracles, such as HICCUPP, also help testers find bugs in the larger context of the product beyond just the specifications of the story, helping to ensure that the overall goals of the product are a part of the quality assurance process.
The idea of the test charter comes from Session-based Test Management, an approach to exploratory testing pioneered by James and John Bach. You can learn more about this valuable skill by visiting their respective sites. You can also read a summary of the approach in Exploratory Testing in a Nutshell, by this author.
In lean software development, the vast majority of automated tests should be written by the same developers who write the code. Lean software development simply isn't sustainable unless this happens consistently. Without automated testing, the cost of regression testing after each iteration becomes prohibitive, so your job as a QA professional is not to write the tests, but to make the tests written by others as effective as possible.
You can do this by:
- Looking for gaps in testing by reviewing code commits.
- Innovating test development by keeping abreast of changes in the automated testing technologies that are relevant to your project and sharing what you have learned with developers.
- Updating existing tests to include coverage for the bugs you find in exploratory testing.
The continuous integration server is the pulse of a lean software development project. It creates a fresh build of your product and runs all the automated tests every time someone changes the code. If your team is operating the way it should, the team scrambles to "fix the build" every time any of the test fails. This helps keep your project's technical debt low by throwing up a barrier to new development anytime anyone breaks the application. Work stops until the problem is fixed, which means everyone is motivated to fix the build as quickly as possible.
You can help make continuous integration more effective in a number of ways. At a minimum, you should understand how the continuous integration server works and know enough about its configuration to help diagnose problems when things go awry. If it fits well with the makeup of your team, you can even "own" the integration server and be responsible for configuring it, keeping it operational and hooking it in to your other tools.
Release path testing
All good things come to an end, and in lean software development that happens pretty frequently. Iterations can be pretty short, and often times they will result in a new version of the software being released in one form or other - either as a patch or new release to customers, as an update to an existing SaaS site (as is the case for my personal project, TroopTrack.com), or perhaps as a compiled product that is delivered via download or CD. In any case, it's important that the release path be tested at the end of any iteration that results in the shipment of software.
Here are a few examples of release path tests that are applicable to some of the most common means of delivering software:
- Testing a software installation against a variety of technology stacks that are supported by your product (LAMP, Windows Desktop, etc.).
- Testing a software upgrade on a platform and dataset that is representative of a specific customer to which the product will be shipped.
- Verifying the final "packaging" of the application into an installable binary works appropriately.
- Performing an upgrade "dry run" against a recent copy of production data from a SaaS implementation.
The role of the QA professional on a lean software development project is considerably different from her role on a more traditional project, but it is still important nonetheless. The key to being successful lies in your ability to adapting to new ways of adding value in the context of a rapidly progress product creation process.
David Christiansen is a senior developer at Collaborative Software Initiative and the founder and managing editor of TechDarkSide.com
How to determine if you are on the right quality assurance career path