During every stage of product development, customers are in constant contact with the production team – providing them with requirements, checking the progress, and adjusting new features. Even though all this varies depending on a development project, we need universal Quality Assurance standards which could be applied to (almost) any software project. Here are a few things which we had in mind when we designed such QA standards processes here at The Software House:

• What practices give us the greatest value?
• What improves product software quality?
• How can the customer gain confidence that their product is in good hands?
• How to adapt QA testing standards to many different projects, products, and systems?

What are the day-to-day QA standards for our Quality Assurance department?

Quality Assurance standards are a complete set of procedures in the testing process – including document templates and proper work organization – providing the highest quality of products and services.

At The Software House, every Quality Assurance engineer uses defined standards and tools to facilitate their work on a daily basis (using tools is also a quality assurance standard!). It allows us to:

• create documentation (Confluence),
• manage tasks and report daily work (JIRA),
• create test cases and perform high-quality control tests (QA Touch).

Error Logging

One of the first Quality Assurance standards we created was error logging. You probably ask yourself: “why this one”? The answer is simple – every Quality Assurance engineer, while testing an application, provides a list of errors that they’ve found in the product and that need to be corrected in order to ensure high-quality improvement. The QA standards describe all the necessary elements which should be included in the error log.

For a logged error to be understood by other team members, its description documents must be detailed and contain all the regulatory information needed to reproduce it: preconditions, reproduce steps, actual result, expected result and finally a description of the test environment.

Also, for each error Quality Assurance specialists specify the priority determining its impact on the developed system. You know the drill: critical errors should be repaired quickly because they prevent the full business path from being executed.

Why is that important? Quality Assurance spots bugs, so software developers could take care of them later. Describing errors according to the standard guarantees that developers will quickly reproduce the error and will be able to fix it in no time. After all, they are subjected to the same software quality assurance standard pattern. You may spend more time to correctly log a bug, but in the end, this action directly increases the quality of products/software.

JIRA

This is where we use our Quality Assurance standard to log errors. Also, due to its capabilities, JIRA is useful to describe a given functionality as a User Story. The task prepared in this way is sent for testing. After completing the Quality Assurance activities and closing the task, the tester must enter a comment containing a brief description of their work performed during the tests – what exactly was tested, in what environment, and which devices were used for this purpose along with information about the software version and the tested application. 

Confluence

We create a space in Confluence for each software project. This is where we store all the basic information about the project development, functional descriptions, and solutions used in creating or testing the application. This is a very important element for us – in the case of substitution in the software project, the new person (whether it’s a software developer or Quality Assurance control) has all the necessary data available straight away and can quickly catch up with all the details to support the project team with conducting specific tests objectives.

As a QA department, we also have our own Confluence space where guidelines and descriptions of processes and standards implemented in our department are provided. This Quality Assurance space also contains the defined requirements, activities, and goals for Quality Assurance engineers and know-how materials that allow for further training and exchange of knowledge inside the company.

Weekly report

Every Thursday, our QAs are required to provide the status of their assigned testing activities. As mentioned before, Confluence is pretty useful here – we have a special report template that we simply fill in using defined statuses and failure reasons. After that, all reports are assigned to the Head of Quality Assurance who can quickly check the status of each project (and know whether his help is needed or not).

Regression testing & QA Touch

QA Touch is a fairly new tool in our organization. It allows you to manage the test run and is used during pre-release regression testing for the client. For Quality Assurance engineers to take full advantage of the tool, they must have test cases prepared before performing regression testing. Where to get them?

Test cases are created during the entire test process in the software quality project, strictly based on Quality Assurance standards. You create them in the easiest way possible, so they include the lowest maintenance cost (the so-called high-level cases), and their implementation is quick and simple. Each test case should contain well-described initial conditions, steps to perform it, and the expected result. Cases are created for basic business paths, they are saved in QA Touch and then assigned to tests in a given release. While performing tests, the QA engineer sets their status and, after completing the tests, generates a report (including the number of cases that have been carried out and how many of them passed/failed the tests). I highly recommend QA Touch, as it has many other possibilities that you can discover and use in your testing process.

What about automation in quality systems?

In big projects, we implement tests to cover business flow using Gherkin. The already-prepared scenarios are used during regression testing with our custom, open-source automation tool Kakunin. If you want to read more and check out how it works,  you can visit Kakunin’s official website here. 

Testing plan

When we start regression testing, before we release the production version, we wonder where to start and what we should test. During such tests, every Quality Assurance engineer must remember the most important functionalities of the application from a business point of view and the correct operation of the software.

The test plan is a document that is delivered to the customer before the testing process begins. What should such a document contain?

Basing on the global IEEE 829 standard and its 16 points, we’ve created an 8-points list – it contains all the most important and most valuable information about the course of tests.

The document aims to show the client

• what the scope of the tests is,
• what will not be tested,
• under what conditions the tests will be carried out,
• when the tests will take place,
• what the client will receive after the quality control is completed.

Software quality assurance processes begin when the client approves the plan.

In preparation for testing, the QA engineer is required to create a document, but thanks to the well-created test plan template, their ability to do it in a fast and legible way.

Test reporting

In order to prepare a satisfactory quality control process summary, you need to collect all important data from the entire course of the tests and write them down in the form of a report. Normally, it could take a lot of time, especially if the software project had a lot of services and requirements. But at The Software House, it’s yet another document based on a created software quality assurance standard. It provides the client with a description of the carried-out tests, deviations from the product test plan and the most important information – status of application quality.

The report should be legible and contain relevant data. It is based on a previously prepared template and test plan. Test data are presented in tables and graphs. Completed with a short description, the client won’t have a problem with finding information and understanding what is going on in the project.

Learn to use quality standards for improved customer satisfaction

A well-created Quality Assurance standard is flexible to the needs of any software development project and has ready-to-use templates. However, the most important element in this process is to actually use quality control standards and improve them through practice. It seems that Aristotle was one of the first QA engineers, as he said:

Quality is not an act, it is a habit.

Writing a big book of standards usually scares people. No wonder. That’s why in our quality management team when implementing standards, we organize workshops aimed at getting familiar with the given standard and acquiring practical knowledge on how to use it. What’s more, we try to create the standards together, based on our experience and knowledge. Sharing is caring!