Ron Wilson
With software testing, and agile testing in particular, it is critical not to forget about the negative test scenarios. Agile forces teams to move a break neck speeds and often we are lucky to get the happy path scenarios tested, so you are probably thinking how in the world can we also have time to cover the negative test scenarios. Unfortunately, when there are production quality issues, the root of most of those defects is that the test scenario was not tested. Planning in agile, contrary to what many may think is that test planning is a critical piece of the overall process of quality.
I have been running an agile team for over a year now, and we have done a great job at covering happy path scenarios, or those items which we identified which need to be tested. However, we have done a very poor job of identifying and documenting negative test scenarios. For our product, we manage electronic file transfers between our customers and other internal systems. With this one scenario, two different files were received at the same time, and the second file ended up overwriting the first file. While we were able to reprocess the overwritten files, it was a painful lesson because we did not factor that negative test scenario in our testing.
While it is impossible to account for all the different negative test scenarios, it is possible to document those which might be most probable and automate as much of those scenarios that you can, so that you can speed up the testing process. In the event that defects are discovered like it happened on my team, it provides a great learning opportunity to grow and raise awareness which will help identify potential missed opportunities. I would venture to guess that most agile testing covers 90 to 95 percent of happy path scenarios. If we spend more time and identify 5 to 10 percent more negative test scenarios, then I believe our overall quality will increase.
