Image Credit: https://www.techarcis.com/shifting-toward-shift-left-testing/
Start testing the product requirements before you test the product
It’s the year 2019, software development life cycle has evolved. From good old Waterfall model to agile methodology. The question that comes to mind is, software development life cycle has evolved, so software testing life cycle should also keep up with the needs of faster, efficient delivery of product, right?
Traditionally, Quality Assurance in software industry has been a team of people who will come in at the tail end of things, test it, file bugs, and ship the product. I have worked for 4 companies and I have seen things change from when I started till the present. While earlier the focus was to get things tested at the end and ship it. It has changed now to test early in the process and find bugs and fix them. The next question is how can we get things tested if there are multiple builds in a day? What types of testing will you provide to certify the build is good? If you have multiple environments, can you guarantee it will work all the way through production? And mind you, time is never on QAs side. More often than not the timeline you have provided is getting eaten up by teams up in the funnel.
There are multiple things that we need to follow to be able to successfully ship the product. This doesn’t assure that your product will be bug free, but it will ensure we hit the deadlines and push features at a faster rate. My role as a QA manager is to ensure that the stakeholders in the project are all aligned with my plan. I make sure that they involve QA much earlier in the process. I ask the product to involve us in a technical grooming meeting, where the Product explains the features to devs. Why? Because we start working on our test scenarios and uncover any scenarios that were not taken into consideration by Product. Once we have our test scenarios ready, we review with the stakeholders and agree on the test plan.
So the question comes, what do we do when developers are still building features? Well, we start structuring our automation framework (API, UI, database). Automation is the key to making things faster, efficient. We all live in a time when we want faster results. For that to happen, it is important that we setup automation. From API automation standpoint, we start hitting the endpoints and these are usually the fastest to build. The APIs are the most vulnerable at the start of a new project because things keep changing and there are more chances of our scripts becoming outdated. The only way to know is when the response or payload or endpoint itself changes and the test fails. For UI Automation, I have worked with our UI developers to involve us in their PRs and start capturing the objects which we interact with viz. textboxes, buttons, listviews, and any other fancy components. We start setting up our page objects, helpers, and test flows. And by the time the build is ready for us we can start running our automation suite and be better prepared.
How do we get the developers to buy into our automation? We have setup our automation tests to run smoke test on every deployment to the QA environment. We started publishing the build results to our Slack channel which had devs and qa. At first, none of the devs paid attention. But I started asking my SDETs to start publishing the reason why the build failed. The idea was to give them a sense of responsibility, for both SDETs and the devs. And there were also times when tests failed due to environmental issues, or changes that weren’t communicated early on. We started seeing better results after the collaboration. The next thing we want to do in the process is to have them run the tests on dev’s branches. Everytime they commit the code, we setup our automation tests to run on their branch. It’s relatively easier on the API side because tests run faster. For UI, we are still experimenting with what could be the easiest way for devs.
As part of automation, we also run our regression suite which is more detailed test scripts that run on a nightly basis. The build picks up the latest deployed version and runs tests on it. The confidence of the build depends on the test result. As a last line of defense we have to make sure that our automation suite gives us enough confidence that we can either go out in production or hold off deployment. For this part to succeed, we need to automate. Automate a lot of our test scenarios. Not everything can be automated, but all those mundane scenarios that we don’t want human intervention should be. Manual testing should be done for negative or exploratory testing. We want testers to identify different ways the system can be broken. We focus on other pieces of the system viz. Performance testing, monitoring system, security testing etc.
This is the approach that has been working for me for the last couple of years. I have realized that getting involved earlier on in the project is important and gives us an opportunity to look at it from both the inside and outside perspective. We would like to believe that we see product’s vision, translate developer’s work, and view it from the customer's eyes. Shift Left Testing is definitely the way to go forward when your company is moving at a fast pace.
Read the full article