There is nothing quite like the adrenaline rush mixed with fear you feel when you ride an incredible rollercoaster for the first time. Your heart pounding from the unknown but at the same time you get on and ride because you know that it was carefully designed, checked over many times by experts in the field, each detail evaluated and conceptually tested. Even after that stringent process the track was tested many times before anyone ever rode it. Even today, before you arrived at the theme park the ride was sent through its paces to make sure it was running as expected to ensure your experience was ideal.
Can you honestly say that the software you build is handled the same way?
Sure, there may not be lives on the line when you create that sign-up page or add one more foreign key relationship to your tables but your customers are still expecting the same level of dependability when they try to enjoy your applications and services. So, if your software isn’t as reliable as the rollercoaster, why is that?
Unlike the rollercoaster, quality is not baked into the software development lifecycle from the beginning.
“Of course it is,” I hear you say, “we have shifted left and our test automation begins at the start of the sprint just like our development does.” That is fantastic, and we will get back to that, but quality is about more than just when test automation starts or when you write your test cases. Quality engineering begins the moment the project is considered. Just like planning a rollercoaster there are a whole host of questions to answer as the project gets off the ground. No one is going to start construction on a 200-foot-tall steel rollercoaster with just a crude crayon drawing in hand.
Laying the Foundation: Quality in Planning
Quality begins in the planning phase, and test engineering needs to be part of the conversation.
It’s true that the responsibility of creating and documenting the project, justifying its ROI, coordinating with stakeholders, identifying required resources, etc. should not fall on the shoulders of the test engineer, just as it would not fall to the application developer or the DBA. That does not mean that those team members can simply sit back and wait for their turn. As a test engineer especially you are the customer advocate, and that job is true on all days for all projects. Your intervention in the planning process is key to prevent poorly considered or missed requirements from making it into the early phases of development. Imagine that the intense rollercoaster was planned to be built in the kiddie section of the park. Is that where it belongs? Someone was not acting as the customer advocate and looking out for both those looking for accessible rides as well as though looking for an adrenaline rush.
Shifting Left: Integrating Quality into Development
Hey, you finally made it through planning and everything was considered! Now it’s time for development to take over right?
Well, yes and no. This is where we get back to that shift-left mentioned previously. Building quality into this phase of the SDLC is a more common consideration. Yes, you need your developers to begin building to the stories as the sprint kicks off, keeping unit testing in mind (or starting there if you are a TDD shop). Almost more importantly though is that this is when test begins building out the details of those test cases defined in the stories which won’t get automated, so they can move on to building the automation that will drop alongside the developed functionality. As for the product team, they are hard at work preparing the next set of stories for backlog refinement, doing their best to learn from previous iterations to better build in quality requirements.
At all times, all functions within the team are hard at work focusing on quality. This comes to a head as the sprint comes to a close.
Manual Testing and Exploratory Approaches
So, the development team has delivered code into your QA environment and your automation has run. No bugs have been found! You’re ready to move it along the pipeline right? Well not quite. Despite a robust approach to automated testing, the team, not just the test engineer, needs to get in and do some manual testing based on the test cases that couldn’t or shouldn’t be automated and exploratory testing needs to happen. This is a time where everyone needs to have their customer hat on, think outside the box, and treat the system as if it will be used by both the most sophisticated end-user as well as the most clueless. We are building for the entire customer base after all.
Congratulations, everything looks good! We have achieved success and quality engineering is complete for this sprint! Well, the Development piece is anyway. We still need to ensure that we have quality control in place and that we learn from this release.
Monitoring, Rollbacks, and Learning from Releases
As we release the new code through our delivery pipeline we need to ensure we have the right gates in place and the best possible post-release monitoring and rollback strategy. Part of quality is knowing when you didn’t meet the high bar you and your customers hold and how to deal with it. The whole team is responsible for understanding how to evaluate a new release and how to best handle any issues that may arise.
Without any more games or getting your hopes up we come to the final pillar in a quality engineering SDLC which is improvement. Yes, we should all be reflecting and introspecting day in and day out but having true retrospectives, gathering feedback from stakeholders and customers, and looking at metrics related to the release are all vital towards building higher quality as you move forward. There is no ceiling when it comes to quality, we must always reach higher!
That is quite the journey to undertake each and every sprint. It can feel daunting at times and it may be challenging to keep the entire team caring about quality but importantly it is and must be the team. No one person can be responsible for every aspect of quality, only the whole can be greater than the sum of its parts.
About the Author
Bret Gregersen is a Senior Test Automation Architect with Impower.ai. His 15+ year career includes notable stops in the test automation and QA departments at Microsoft, Google, and Wendy's.