Releasing software in the past was a QA’s dream, plenty of time to check every last corner of the product before eventually releasing to production. With the move to Agile and the speed at which we need to deliver software, this old school model no longer works. So what can your QA team do to ensure quality when the amount of time you’re given to test is very little? Certainly the first thing that comes to mind is a great CI (Continuous Integration) process with test automation.
The problem is fast reliable automation is very difficult to get working right. I strongly agree that solid test automation needs to be in place however if you wanted to improve quality without automation what could we do? I believe a practice my team uses to flush out bugs is a great one and wanted to share it with you.
I call this practice “Development Tours”. The idea is very simple. When a developer finishes implementing a feature/bug fix, the QA pairs up with them and they get a tour of the feature or bug fix. These tours have really helped us get things right even before the feature enters our CI pipe. Thus improving quality very early in the process.
Why do I call this practice “Development Tours”? The name came to mind after recently reading a book called Exploratory Software Testing by James Whittaker. In this book James outlines how to break up your software into Tours. For example the Historic Tour of your software would include legacy features introduced in earlier versions. Another sample tour area would be The Business Tour which contains the primary business purpose of your software. Breaking software into tour-able areas helps you key in on what needs to be tested and what areas might be more bug prone.
I thought to myself, wait a minute, we have these tour areas but I don’t want to explore this code without a “tour guide”. I want an experienced guide to help me understand the back alleys and pathways of the code. This guide already exists on your team. It’s the developer who implemented this code. How logical is that.
Let’s talk about the clear benefits of Development Tours: (QA pairing with Developer)
- QA engineer gets to learn more technical aspects of implementation. Today’s QA is required to be more technical so I love that I get to learn from the developer directly.
- Developers also learn from QA by seeing the types of bad user scenarios QA uses to flush out bugs. They learn new techniques around flushing out defects. What better way to improve software quality than training the devs to avoid implementing bugs in the first place!
- Review the actual purpose of the feature. We should already have good Acceptance tests but this is a great time to review these together.
- Discover newly uncharted use cases which could impact the user. You’re bound to find use cases you didn’t know about when starting to implement feature even with planning done up front.
- Gain an understanding of how well implemented a feature is. Was it implemented line by line from Acceptance criteria or did the developer really flush out outside cases which could cause issues. I think this occurs a lot. Developers stick to the acceptance like it’s the final word but really at times things come up that need to be fixed and should be fixed on the spot.
- Walk through the automated tests created around this feature because of course our definition of done includes these tests.
- Weeds out bugs that are a waste of time. I’m talking about the very obvious bugs that can be found within seconds of testing a new feature. I believe we want our QA to use their experience to flush out deeper issues not waste time finding obvious bugs which should have been caught by a developer. When we tour the feature together we find and crush these obvious bugs quickly. No need for bug write up etc..
Looking at the points outlined above it’s hard to argue that this simple practice doesn’t improve software quality. I also noticed since starting that developers are more actively engaging with QA. I believe you will know this process is working when developers are actively coming to you asking to review features or talk about implementation details.
So, encourage your team to try this early integration development tour. I think it’s a small change that will help your team improve the quality of your software.
