No QA No Bugs
What value does a QA delivers anyways?
In 2017, it was a funny time to be a QA. But not funny ha-ha. Funny weird. Everyone wanted to shift left (within reason) but not to improve their quality, they would do it in the mindset of reducing the bottleneck of the classic quality assurance specialist, that would, in the end of a sprint, test everything.
I remember a few years ago, I was the only QA on a team of 5 devs, we didn’t have a lot of automated tests in place, but the shift-left mindset was applied, at least in part. I would help them out sooner rather than later in the development of their stories and it would pay off in the end of the sprint, the testing phase was minimal. At best we would find an issue or two in staging, quickly fix them (or assume the issue until the next release).
A new project within the company had started and they wanted to apply the shift-left mindset right off the bat, but they didn’t need a QA. All could be done with automated testing, and the devs would assume and own those tests completely. As a QA analyst I was curious, I wanted to see how they would do that, how they would cover that case, or that other case, I wanted to learn and help them on the way. But I got pushed on the sideline, because automation was the way, no need for a “manual QA”.
I hit my “told ya” moment when they approached me after a few months and they had a TON of issues in production. It was a mess. That was the point they realized that even if they wrote a ton of tests, they didn’t think about their test strategy. The solution was then to put a “manual QA” on the team to mash the hell out of the application and prevent any more bugs in production.
Fast forward to today when I realize that they were SO close. They were owning the automation testing strategy. Any new dev on the team went thru a rigorous process of code coverage, pair-programming, meticulous pull request reviews. The only thing they were missing was a good test strategy, implement the missing test pyramid (I know some of you despise that, but sometimes, it really helps the team to categorize and focus on the right things!), think a bit more on the user experience.
So what role can your QA team member can take in a shift-left transformation or project?
- Documenting can prove to be useful when starting a shift-left. It allows an easier transition from the traditional approach by making sure to target the most critical points in both existing features and new features. Usually focus on user-critical features and common fragile points in you application;
- Participate in kick-off meetings with the devs. Help to think ahead of time of potential issues, leading these meeting using exemples is the best practice. Personally, I prefer to have these meetings in an informal manner when a developer starts a story, but you can also make these a regular meeting, similar to your scrum planning and refinement meetings. This practice is also referred as the 3 amigos (good read btw);
- Learn to read the code, take a look at the PR reviews, learn automation, more versatile your QA team member is, more confident the developers will be in delivering their features with confidence, as a team rather than relying on a QA police;
If your team doesn’t have a QA already on board, your team can already start applying the same guidelines. Stop, breathe and take 15 minutes to think about possible test cases. Don’t go too deep in the features, but thinking of all the ramifications of possible user cases helps a lot. Write 👏 them 👏 down 👏. It will help you to prevent a lot the oh-I-didn’t-think-of-that cases.
Although this is not a perfect guide, it’s good first steps to what I call “the confidence of deploying at 4PM on a Friday before a 3-day weekend”. But that’s a story for another time.
