When do companies need software testing: tips from a lead QA engineer

While searching for professional QA engineers, companies are often struggling to meet estimated budget and time limitations. Yet, ignoring software testing can cost you a fortune and lead to massive technical debts as the entire development life cycle opens up numerous vulnerabilities. And the later these issues are found – the more resources and time it takes to fix them. 

Therefore, to shed some light on the role of a QA throughout different stages, we’ve partnered with a leading QA engineer from Grid Dynamics and explained when exactly companies need professional software testing services.

I assume you’ve seen this question before or perhaps even asked it yourself. This question might have come to you throughout different stages of the development life cycle – during the first (or regular) production deployment, dramatic requirements change, defect reports from customers, etc. 
In the example below, we’ve taken a loan application (REST API backend and web-UI frontend) and described at what stage companies might need QA engineers and why. 

At this point, you want to know how many tasks can be accomplished during each iteration. So, as soon as all of the tasks are described, developers make estimates and define the optimal number of tasks which should be brought into development. 
Because these estimates are initially quite rough, you might want to add or remove multiple tasks to/from each development iteration. Overall, the team’s capacity becomes clear after 2-4 development iterations. 

If this is just an architectural phase when you are setting up new projects, configuring frameworks, environments, continuous integration systems, etc. – you don’t need QA engineers unless they are required to set up continuous integration. 

In this phase, user roles and access rights are usually defined (borrower, lender and system administrator in our example) while the UI team is providing first page markups (login/register) without sending requests and processing server responses. 

IMPORTANT: Always start a project with defining user roles. As starting with an almighty system administrator and then adding roles with fewer responsibilities will guarantee you an enormous technical debt.

At this point, you might need a QA engineer to check if:

• Roles and access rights are defined properly (this can be done only via code-review, thus corresponding expertise is needed);
• The mockups are correspondingly displayed on required browsers
• The design is adaptive/responsive and is not corrupted on different devices;

• Roles and access rights are defined properly (this can be done only via code-review, thus corresponding expertise is needed);
• The mockups are correspondingly displayed on required browsers
• The design is adaptive/responsive and is not corrupted on different devices;

Also, an accurate development (feature branching) flow should be set up to reduce the number of future issues. 

In our case, this stage involves planning a simple registration form with an email, user role (borrower/lender), and a full name. After you’ve done some research, your form should be based on the following rules:

• Full name must contain at least 2 words
• Email must contain “.” after “@” symbol and only alphanumeric characters available 
• One of the roles should be selected (borrower role is pre-selected)

• Full name must contain at least 2 words
• Email must contain “.” after “@” symbol and only alphanumeric characters available 
• One of the roles should be selected (borrower role is pre-selected)

At first glance, everything seems fine. However, a QA engineer might ask you about a couple of things that are still missing, namely:

• Can a full name contain non-Latin characters, apostrophes?
• What is the maximum number of characters allowed for a full name, email?
• Should you accept emails of a top domain (e.g., abc@net) as it is technically possible?
• Should we have an escaping (to avoid XSS, for example)?

• Can a full name contain non-Latin characters, apostrophes?
• What is the maximum number of characters allowed for a full name, email?
• Should you accept emails of a top domain (e.g., abc@net) as it is technically possible?
• Should we have an escaping (to avoid XSS, for example)?

At this point, you might not necessarily need QA engineers because only light involvement is required.

When the first flows (registration, login, pledge creation and approval) are finished and capacity estimations are quite precise, you are starting to prepare for the first release. 
In case your product doesn’t have much functionality, it can be tested on your side or by the development team. You will have some defects after the release but in general, everything will be working properly. 

Usually, at this point, QA engineers are required to correctly define the Product Test Strategy, Test Plan, and ensure a successful product launch (if they weren’t involved from the very beginning).

So, to reduce the refuse ratio due to possible defects, a QA engineer will plan Regression Testing (which will cover all of the created functionality). Unfortunately, this process is pretty time-consuming but it will help you stabilize release candidates and deliver the product with a minimum number of defects. The defects that aren’t fixed will be marked as “known issues” – so that your customers will be aware of them and can wait until everything is fixed. 

During regression testing, a number of flows will be repeated every time (as a creation of a pledge). As for the core functionality, there is a small possibility that it will require any changes in the near future. Therefore, it is nice to run automated tests to ensure that no bug-fixes have previously broken the core and that no new features will break it in the future.

If yes – it’s essential to set up performance testing by common user scenarios. This way, you’ll be able to compare the current development environment, load, and a number of users with that of expected during production. 

At this stage, you received a request to build a CRM upon lenders (as it is quite hard for financial organizations to maintain pledges provided via your application). This phase will also require changing the user’s model (adding addresses, linking to a financial organization, etc.).

During this stage, you’ll need to ensure that previously developed functionality hasn’t changed and build automated tests against existing functionality. As soon as automation tests are present, this process will require up to 30 minutes to ensure everything is working properly or detect any defects during the development of the CRM. This way, you’ll be aware of the defects and be able to control the situation while some features might be postponed as time- and resource-consuming. 

If your application is on the support phase – good coverage of the automated tests will shorten your release delivery up to 1-2 hours (including running autotests, analyzing the report, manual smoke tests of fixed defects, branching, and updating).

If you already have QA professionals on board, you can enhance your team’s capacity with the following:

• Set-up Automation testing (includes continuous integration, system configuration, ongoing support, and team training with no additional environment required)
• Set-up Performance testing (includes team training, continuous integration, and system configuration)
• Speed up time-consuming testing (as regression)
• Set-up proper development flow (so that the features/release candidates can be tested isolatedly)

• Set-up Automation testing (includes continuous integration, system configuration, ongoing support, and team training with no additional environment required)
• Set-up Performance testing (includes team training, continuous integration, and system configuration)
• Speed up time-consuming testing (as regression)
• Set-up proper development flow (so that the features/release candidates can be tested isolatedly)

However, if you don’t have any QA engineers on your team, our service can be used to:

• Release candidate testing (perform regression testing before going to market)
• Documentation testing (find missing points and possible bottlenecks)
• Features testing (perform testing against new functionality)
• Regular regression and smoke testing (ensure that both new and previously created functionality are working properly)
• Automation testing for “happy-paths” (to ensure existing functionality is not broken), continuous integration system configuration and reporting included.
• Set-up correct development flow (so the features can be tested isolatedly)
• Performance testing (to ensure application handles the expected load), continuous integration system configuration and reporting included.

• Release candidate testing (perform regression testing before going to market)
• Documentation testing (find missing points and possible bottlenecks)
• Features testing (perform testing against new functionality)
• Regular regression and smoke testing (ensure that both new and previously created functionality are working properly)
• Automation testing for “happy-paths” (to ensure existing functionality is not broken), continuous integration system configuration and reporting included.
• Set-up correct development flow (so the features can be tested isolatedly)
• Performance testing (to ensure application handles the expected load), continuous integration system configuration and reporting included.

The golden rule remains unchanged – the earlier defects are found, the cheaper it will be to fix them. The above-mentioned tips will help you determine the role of a QA engineer during each stage of your project and all of the necessary quality assurance procedures. While our quality control and software testing service will enable you to stay within budget and extend your testing capacity at times when it is needed.