Why should you necessarily hire QA engineers?

Why do we need to test applications if we hired good developers?

It’s misleading to think “We don’t need testers since engineers we hired are highly experienced”. Human proneness to error is hardly the only reason why to hire quality assurance engineers for a team. QA engineers’ task is not only to track bugs software engineers could have made and missed to fix. They take responsibility for making sure the product works according to the client’s expectations and namely, according to Acceptance Criteria.

Imagine, a software engineer develops feature #4, which somehow impacts feature #2. The task of quality assurance engineers is to track all current changes that can influence the rest of the already developed product features and help developers be aware of what goes wrong. Quality assurance engineers can set challenging questions while testing documentation to find defects in it.

Because developers see their code as a well-done job, they can miss the bugs which the QA engineer, specifically skilled and knowledgeable in the field, catches and reports on them. Besides, software developers will need more time to test which might occur pretty tough: testing methods are numerous.

Of course, developers can write unit tests, which is quite a standard practice in software development companies. However, the QA engineers are the ones to test the solution inside-out and verify it works in accordance with all the requirements.

Why should we add a QA engineer from the start of the project?

Involving QA engineers too late in the project can become the pitfall nobody was expecting. Imagine a project almost complete, but requirements are still clear only in somebody’s head or scattered across documents and chats. The day the team decided to review the acceptance criteria, it turns out that developed functionality differs from what was initially planned.

Imagine a field that has to be filled with a certain category of symbols. Instead, a software engineer builds the field that will allow input of all possible kinds of symbols. This is QA engineers’ work to know what exact symbols should be filled in there and whether there are any restrictions. This is the smallest detail that can turn into a defect before release, but how many critical bugs connected with integrations, UI, data, security can slip into the production if there is no QA engineer from the very beginning of the project.

The goals of manual testing are to leverage the possibility that the product:

• works well in any conditions
• meets all the requirements

Testing aims at providing the actual information on the state and quality of the application at the moment.

Stages of quality assurance testing:

• Analysis of the product
• Work with requirements
• Testing strategy development
• Planning of quality control procedures
• Compiling QA documentation
• Prototype testing
• Main testing
• Stabilization
• Exploitation

Levels of testing

Unit testing

Unit testing checks functionality and looks for defects in the parts of the product that are available and can be tested separately (models, objects, classes, functions). Imagine a new button is created, while doing unit testing, the QA engineer checks only the scope of this button, so to make sure it works or not. Unit testing can be described as a lower level of testing.

Integration testing

Testing of communication between system components after conducting unit testing. It is targeted at detecting defects in interactions between integrated components, or between the whole systems and packages.

Regression testing

Regression testing is connected with changes. It is designed to monitor changes made in an application or development environment: defects fixing, integration, migrations to other databases, application server, or web server. This kind of testing approves that previously developed functionality works as it should. Both functional and non-functional tests can be part of regression testing.

System testing

System testing aims to check both functional and non-functional requirements in the system in general. This kind of testing reveals such defects as improper use of system resources, the unpredictable combination of data at a user level, incompatibility with the environment, missed user scenarios, missed or wrong functionality, inconvenient UX, etc.

Release testing

Even if the system meets all the requirements, it’s important to check if the system meets users’ requirements as it was initially defined in the business model. To note, business models can also contain mistakes. That’s why it’s critical to conduct release testing as the final step of validation. Besides, testing in the operating environment allows you to identify non-functional problems, such as conflict with other systems related to business or software and electronic environments; insufficient system performance in the operating environment, etc. Finding such things at the implementation stage is a critical and costly problem. Therefore, it is so important to carry out not only verification but also validation, from the earliest stages of software development.

Acceptance testing

The standard process of testing aims at verifying if the system meets requirements, acceptance criteria. It allows for obtaining the client’s feedback on whether or not the application can be accepted.

White and black-box testing

White-box, black-box, and grey testing are methods of testing based on the access of engineers to the source code. The black-box method is functional testing of software while the white-box is structural testing of software. In white-box testing, QA engineers have all the knowledge about the internal structure and code of the system. In black-box testing information about the structure and code is hidden and remains unknown for QA engineers.

Functional types:

• Functional testing
• GUI testing (User Interface testing)
• Security and Access Control testing
• Interoperability testing

Non-functional types:

• Performance and Load testing
• Stress testing
• Stability/ Reliability testing
• Volume testing
• Installation testing
• Usability testing
• Failover and Recovery Testing
• Configuration testing

How to perform manual testing? Insights into the process

When the project starts, a great number of test cases are written because of a lot of documentation. Part of test cases can be automated, but more often they are done manually. At the very beginning of the project, the automation practice is rare. Usually, after manual check-up, tests go to the regression stage for which they can be automated. Regression tests check previously developed functionality and ensure if a developed solution is not broken. Some of the most popular and known tools used by QA engineers are JIRA, Postman, Fidler, New Relic, Jenkins.

Going deeper into the process of testing, there would be such stages as:

Reading project documentation

Profound project documentation and a structured abundance of it helps streamline QA engineering work. Newcomers explore documentation at the beginning of the project, or on condition of new feature development, bug detection, etc.

Create test cases

The lead of the QA team and QA engineers conduct the process of writing test cases according to acceptance criteria at the beginning of the sprint and during the whole project. Some test cases go into regressions testing during the next sprints. The game testing team often compiles check-lists to accelerate the process of testing.

Review test cases with product owner/client

The team defines test cases that will be conducted in the current sprint. On condition there are new features to be tested, the team defines what exactly has to be covered and whether they need integration testing.

Testing Execution

After deployment to the environment, QA engineers conduct testing within the sprint. The part of simpler test cases can be automated and, thus, performed by QA automation engineers. While, manual engineers perform more complicated test cases, e.g. the ones involving testing UI, translation, etc. No project can be fully tested by automation. Manual testing is an indispensable part of quality software development.

Report bugs. Verify bugs

If bugs are revealed during testing, QA engineers create bug reports consisting of summary, steps to reproduce, description, assign to, fix versions, severity priority. After fixing the bug, the QA engineer checks it once again.

Create a report

The QA team Lead creates a report after which the traceability matrix should be compiled. The matrix displays concrete functional features and the number of test cases to cover them. Also, the report includes the percentage of passed, failed, and blocked test cases. The QA team meets up to decide whether the sprint can be shifted to the production stage.

This is a short overview of the QA testing process. Hiring a QA team or at least one QA engineer is 100% worth your investments. Investing in the quality of the product from the very beginning means you contribute to its success when the release is coming. If you are looking for expertise in Quality Assurance Services, feel free to contact us. Upgrade the quality of your code today.