EMBIQ CTO about Quality Assurance

Can skipping the quality assurance stage pay off for us? We asked EMBIQ CTO Bartek about this. 

• Is it true that quality must cost money?

Bartek: If we really want to, we can skip the quality assurance stage. But it is exactly the lack of it that could cost us. Money invested in the quality of a product comes back double: firstly because there are far fewer setbacks, and secondly because the final product is far more reliable

• Is money the only thing we can lose due to a lack of quality?

Bartek: Worse, our client may lose their customers. By failing to ensure quality, they may expose themselves to disclosure or loss of data, with the result that the product will not be fit for use and customers will not be able to use it properly. It always costs money if we produce something that is for the end-user. It is often the case that without quality assurance such a product may not even be suitable for release. Quality is something that customers are not always aware of. It turns out that it is not only this development phase that is important, but also what lies beyond it.

• Is it worth investing in quality? Can you skip this stage? Will you pay more later?

Bartek: It depends on what we want to achieve. Many of our products are based on an R&D phase with little or no testing. When it comes to the final products we produce that are intended for production or release, it is worth not skipping this step. In the first phase, you don’t see this, but at the end there may be some flaws. It then becomes apparent that the product is not stable for publication. The stage connected with quality can be abandoned when we want to produce, for example, a prototype.

• What are the quality assurance stages for software?

Bartek: Quality assurance starts even before software development begins with a well worked out product concept, functionality, architecture and test cases. Then, in the process of software development, these are unit tests, automated tests, integration tests, manual tests according to scenarios, monkey tests. But also, quality assurance should not be confused with testing, because quality is also a well-set process of software production and its automatic and continuous integration.

The first step is to design the tests. Of course, the scope of testing is finite; we have limited capacity. We need to develop a concept for these tests – just as we do a concept for the view of design or architecture. In the same way, this test execution concept must be developed in this phase. And after this point, the first tests begin. We refer to this as the ‘use cases’ of a product, which describe the process of a user using the application. This is the first step for web applications, for example, but also for mobile apps or devices or in any other aspect.

Once this first step is over, we move on to the second phase of producing a product, the development phase. At this stage, there are several types of tests to be performed. Depending on the types of products/projects we do, we usually try to build the widest possible range of tests to be carried out. Starting with unit tests for individual functions, and then supporting integration tests. The tester him/herself also plays an important role at this stage. Because once the functionality is produced and goes into the main product branch, the tester verifies the functionality on his/her environment by running his/her tests and testing it manually.

The third phase the tester is involved in is automating and describing his/her work. Automated testing, end-to-end testing and testing of the potential user interface of this application. They are written based on detailed test scenarios, i.e. what the endpoint of the product is, is automated so that these tests can be repeated as early as possible.

For example, in web testing, in addition to the basic operation, we also automate testing of the application interface itself (API)

• When it comes to the software development process, what should it look like to ensure the best quality?

Bartek: Each change goes through static code analysis, metrics such as code coverage in unit tests are checked, it must also compile correctly and without comments, and then go through a full cycle of automated testing. Only after this has been done at least one more member of the development team reviews the change and accepts it or returns it for correction if they notice something worrying.

The software creation process starts with development itself. A given part of the created code is verified in terms of quality and security. For a given code, there is verification through 2 stages, first by team members (by a leader in a given technology who evaluates the quality of the code). At this stage, we try to make the scope of verification as wide as possible – the more people there are, the easier it is to find a mistake. The second stage is the static factor, which is used to verify the code in terms of its security, style and format. For each project, we prepare a local environment to detect potential errors as quickly and as early as possible.

Between these processes, automated tests and API tests are run. Automatic ones are started when this task is finished. Before the tester spends time reviewing this code, other team members execute integration automation tests.

These are standard steps taken to ensure the quality of the software, the code produced and its security.

Of course, we never forget the customer. During the implementation of tests, an internal environment is built as well as an intermediate environment for acceptance tests – the customer has insight into this stage before the final version of the application is implemented.

• The above sounds like it would go on and on.

Bartek: Not necessarily, a well-placed and integrated process does most of the work on servers where these tasks are paralleled. Even where the software is the firmware for IoT devices, this whole process can be measured as required. And besides, its change will be so thoroughly verified, that it will put even more effort into passing the process already in the first iteration.

• Does every one of our projects go through such a thorough QA procedure?

Bartek: We recommend its implementation in every project, but we also realize that it is not always rational. For example, if a project is set up as the first round of funding and its purpose is to explore the technological possibilities for further software production, then creating long-term quality assurance processes misses the point, as the project itself may take less time than producing a test plan and environment. However, with every product that is to reach the end customer, we insist very much on the standards of the QA procedure.

Each of our projects goes through such a thorough procedure. 

We often look at testing as the final stage, but there is a long way to go before a project is at that stage. Parallel software testing is better because you don’t have to spend extra time on quality assurance – everything happens at the same time. In practice, testing is unnoticeable to the developer. Additionally, cranking this out on servers makes it very scalable. 

• Can quality be bought? i.e. can you order just the quality assurance service?

Bartek: Yes, you can. We happen to undertake projects in which we do not deliver the software itself, but advise on and create the entire related infrastructure. We help develop functional expectations, create test scenarios, set up environments, integrate CI and create support tools for automated testing. After all, we’ve been in the software development business for almost 12 years, and we are happy to share that experience.