This question is more for change tickets (e.g. bug fixes, feature enhancements…not new features). I am still fairly new at testing, so I have been asking a lot of questions and this was one of them. We can spend time exploring every aspect of a feature that may have been affected by a change, but does that provide the best use of my time. We only have a limited amount of time to do testing so every minute counts. To insure we are providing value to the team we need to focus on getting the best bang for those precious minutes. I believe we should test the ticket by focusing on the most risky aspects of a change. After reporting the initial risk assessment then we can focus on additional manual testing as time permits. After doing the initial manual testing, decide if any of the manual tests are valuable enough to be a candidate for automation. If so, add them to the list of tests to automate.

Test the Ticket

By testing the ticket I mean a manual exploration of the changes to a feature to insure the intent of the ticket was satisfied and its highest risks evaluated. Yes, manual. Even though I am responsible for automated testing (or checking), I first have to understand how to test manually. The automation are just running checks like a line of robots in an assembly line, it runs the same checks over and over, no real variation, just what is coded in the test.

Unfortunately, our users aren’t robots and they don’t follow the test script when using the application so manual testing is absolutely necessary to add variability like our users will. Yet, automation is a time saver for mundane tests like regression. So after we are done with manual testing, we evaluate the tests to decide if any of them are valuable enough to automate and add them to an automated test suite (e.g. regression, smoke, performance…).

As the ticket progresses through the delivery pipeline, at each stage we run additional test. This way additional feedback can be had at each stage and we also increase test coverage the closer the ticket gets to delivery. By not trying to rely only on automation, we also benefit from early feedback from the manually exploration of the ticket changes. I believe we can manually explore them than automate them (IMHO). So, as soon as a ticket is ready for testing we begin exploration. A ticket is only ready after it has passed a manual code review, automated build, automated unit test, and automated code analysis. So, we have multiple gates that a ticket must pass and fast feedback at each step.

Conclusion

That was probably an obvious answer to seasoned testers, but it may not be pondered by new testers.The point is to focus at first on the change in the ticket as this will be the fastest way to provide feedback on the risks in delivering the ticket. Then move on to running longer running tests as the ticket moves closer to being deployed to production. Fast feedback is the name of the game.