How QA can save your product
The crisis happening all around is making a huge impact on all sectors of the industry. Cust-cutting happens all around us, and enterprises seek where can the spending be limited. Some branches take on the situation better, some worse – but we can agree that the pandemic has affected everyone. We obviously still have to wait for the real outcome – but budgets are reduced already.
Pandemic Impacts IT development
In IT, and software development the cuts are visible, and we have concluded, that clarification has to be made about the way it’s done.
IT development outsourcing is usually handled by managers that delegate a huge list of competencies into the hands of the dev team. That includes Business Analysis and Project Management roles besides the engineering part. While it works great during stable times, we see that the cooperation starts to crack, when the client’s side is pressured to reduce the development cots. What happens in most cases, is that the customer approaches us and wants to cut the efforts spent on QA and testing phases.
This, along with the attempts to reduce the resources dedicated to the Business Analysis part, forms a sort of “scissors” that wish to cut the short ends of the string on both sides, without considering the consequences of such approach. Taking the shortest route is a huge mistake in this case!
Misconceptions about QA engineers
Only the Pen-testing part matches the stereotype applied to the application testing process, as it happens very late in the process, after the app is deployed and operational in its final environment.
The popular misconception on the QA engineer work is thinking about them as a “simple” bug-testers, that spend their time clicking around looking for typos, pages not loading properly, and simple database errors. While it is a part of the application testing process, it is not an accurate image.
When we work in agile we work in cycles. With SCRUM methodology, the product is built in 2-3 week-long sprints – each concluded with release that can be considered “live”. This means that the features that are developed during those stages, each and every time go through the QA phase of the funnel.
The purpose of the Quality Assurance is not marking the feature as a “OK/BAD” but providing an insightful feedback on how exactly part of the software behaves and how it impacts the whole product.
The QA engineers have a task similar to Business Analysts who verify and asses how the assumptions and ideas made by the architects of the vision will affect the final product. They check how the compleated pieces impact the product as a whole. Finished pieces are verified against the logical structure of the application and its’ assumptions.
This means that the tests greatly exceed the practical checkups. You can compare it to a logical jigsaw puzzle, that when solved, eliminate problems that might occur in the future. Lets raise the stakes – it’s like playing chess on a pro-level – thinking how moving your pawn now, will affect the bishops’ plan that triggers 10 turns from now.
The usual stereotype, however – does indeed apply – but only when the development reaches it’s final stages. After the platform is deployed in an environment close to its final one, the penetration testing can start. At codelabs.rocks we have a dedicated “task-force” that will on purpose attack and try to break the developed product in any way physically possible. Thanks to this process we have NEVER had any real break-ins or incidents on the products that we develop for our customers.
Make safe adjustments to the budget
So what can be done to counter the problem of cutting costs with a wrong approach?
If the situation really calls for budget reductions, and its understandable in the current global economical mood, you should trust your software house even more than usually.
Business Analysts and Project Managers that are attached to your project know it inside out, and they already might have a plan for you ready. Since one of the main duties of BA/PM duo is to maintain a priority list of features to implement, they are the best people to approach when cost-cutting is needed.
What should be considered is not reducing resources spent on particular parts of the process, but limitations in the features, or even scratching-off some of them whatsoever. Reconsideration of priorities will lead to informed and responsible decisions that will not hinder existing parts of the product, and will not end in a catastrophic failure, which is – a release of untested application, ill-prepared to face the public it aims to serve.
So, to put the advice into simple words:
After reconsideration of the features – the least essential ones should be eliminated as a whole – releasing the resources to spend on the more important ones.
This approach ensures that the core of the product is developed maintaining a healthy and safe workflow, without jeopardizing the product integrity.