Technological development is changing the world. A plenty of functions and processes are automated while demand for manual labor is decreasing. This trend affects not only blue-collar jobs but also the IT industry itself. Manual Quality Assurance (QA) as a separate specialization could eventually fade away.

There is a lot of talk about testing, but in practice, very few teams have a strong test support for their code. In this article, I will share our experience in transforming a traditional manual testing process into a set of development approaches.

Though we mention own example only, it is widely applicable since the Railsware’s portfolio includes products and platforms of various size and complexity for a variety of industries.

Manual testing in development

Until recently, the majority of outsourcing companies, as well as numerous software teams, applied a common software development algorithm, which looks as follows:

• project managers assign tasks to engineers
• engineers write the code as soon as possible without much care for the quality and submit the developed feature for testing
• QA usually finds a lot of bugs and inconsistencies and sends it back for the update.

This cycle repeats several times and is characterized by considerable time expenses because when fixing bugs engineers often generate new ones in other places.

Despite several discussions about the unit and integration testing, these approaches failed to win much popularity among development teams. If other people hunt bugs for you, writing tests won’t be your headache anymore.

I am not claiming that all projects with separate QA commands have no test writing, but it is a frequent coincidence.

Transformation of product testing approaches

Upon Railsware’s shift to the software consultancy model, we had to improve significantly the quality of products and, accordingly, team qualification. After all, the lack of these components won’t let the company reach a new development stage. Our software quality assurance approaches were also transformed and improved. In the end we switched to test-driven development.

We researched successful examples in the market and experimentally identified several key approaches and techniques that are currently used:

• Unit tests and integration tests are an integral part of the code. Each and every engineer on any project has to provide features with automatic tests.
• Continuous integration is a system with automated tests run at any code change. There are many solutions for such sort of automation in the market. Here are some of them: Jenkins, CircleCI, Travis CI.
• Compulsory use of code quality validators, such as Rubocop, ESLint.
• Pull Request Policy. Any code of the project master branch must be verified and approved by one or more members but not the developer.
• Pair programming. This development technique involves joint simultaneity of two engineers on the same code.

When you apply the listed approaches, your project’s technical debt will significantly shrink, meaning that the number of bugs in the system will be reduced.

Have we completely excluded manual testing?

Implementation of these approaches has significantly cut the manual testers’ load on projects. For the full-time load, testers were allocated part-time on several projects at once (for small and medium-sized products). However, this model proved ineffective: QA did not fully immerse itself in the context of the tested product and was not aware of all the decisions taken. This caused more problems than benefits. On that account, we fulfilled the function of manual testing using another approach borrowed from our Dutch colleagues on the Philips Directlife project (at that time, they didn’t have their own QAs).

TestFest is a manual testing session performed before big releases. It involves engineers, product managers, sometimes UI/UX designers, and a client’s team. Here is an article with more details.

TestFest’s outcome is a list of bugs where each is prioritized and added to the total scope.

Application of this approach immediately removed any need for separate QA professionals.

Wrap it up

In this article, we shared the Railsware’s experience of losing the necessity to have a separate manual QA in the team.

During the business model transformation, we primarily tried to improve the code quality. The use of new development approaches significantly cut both the number of bugs and work scope for testers. The part-time load did not allow QA to fully immerse in the product’s context that affected the outputs. As a result, the QA manual role was completely excluded from the organizational structure, and the testing function was shared with team members

Developers, in turn, have noticeably improved the quality of the generated code by changing the development approaches. Their skill set and, as a result, the quality of Railsware’s products were enhanced

We have been developing products (both small and large platforms) in this format for seven years. Obviously, bugs are present. However, if you compare the quality of Railsware products before and after the QA transformation, the latter win by a wide margin.

We do not deny that some specific and complex products are difficult to test without designated professionals and manual approach. Nevertheless, in other cases, manual testing can be replaced by a set of development approaches that will lead to the reduction of technical debt and increase of the product quality in total.