During nearly every project I have worked on, the question Can I test everything? always comes up. The answer is (usually) a resounding NO. Sometimes it’s because of time, sometimes it’s lack of people. How can we still ensure a quality product, even if we can’t cover it all? Sometimes, we have to test smarter.
The usual suspects
The typical scramble to finish testing and get something released is usually (in my experience) a result of one of the following (or a combination thereof):
User stories that are WAY too big. When user stories are too large, it makes it difficult to break out tasks and identify all the acceptance criteria. They also become more difficult to plan for unforeseen scenarios, and can often blow estimates out of the water.
Complex Workflows. Depending on your feature, the workflow could be very complicated, and it can be difficult to anticipate how a user is actually going to use the product. This makes it more challenging to find every possible scenario for end-to-end tests. Even if your user stories are small, the overall workflow comprising all user stories can still result in missed tests if it is too complex.
Not using Test Driven Development. If you are still living in a world where Development works on their own and throws it over the proverbial fence to QA, you are opening up doors for late surprises to enter, and blocking bugs that hinder your testing progress. Read the rest of this entry »