17 September, 2019
Every customer outsourcing work to a software company, expects their product to be of the highest quality (thanks, Captain Obvious). And it’s the Quality Assurance team that’s responsible for thoroughly checking whether the application is error-free and falls in line with customer requirements. How to painlessly go through the testing process without getting lost and confused? By introducing Quality Assurance standards – they may sound scary but it’s the best way to systematise work and improve software quality.
During every stage of development, clients 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 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 here at The Software House:
- What practices give us the greatest value?
- What improves 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?
What are the day-to-day standards for us?
Standards are a complete set of procedures in the testing process – including document templates and proper work organization – providing the highest quality of product/service.
At The Software House, every QA engineer uses defined standards and tools to facilitate their work on a daily basis (using tools is also a standard!). It allows us to:
- create documentation (Confluence),
- manage tasks and report daily work (JIRA),
- create test cases and perform tests (QA Touch).
One of the first standards we created was error logging. You probably ask yourself: “why this one”? The answer is simple – every QA engineer, while testing an application, provides a list of errors which they’ve found and which need to be corrected. The standard describes 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 must be detailed and contain all the information needed to reproduce it: preconditions, reproduce steps, actual result, expected result and finally a description of the test environment.
Also, for each error we specify the priority determining its impact on the 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? We spot bugs, so 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 standard pattern. You may spend more time to correctly log a bug, but in the end, this action directly increases the quality of the tested software.
This is where we use our 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 tests 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.
We create a space in Confluence for each project. This is where we store all the basic information about the project, 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 project, the new person has all the necessary information available straight away and can quickly catch up with all the details to support the project team with tests.
As a QA department, we also have our own Confluence space where descriptions of processes and standards implemented in our department are provided. This QA space also contains the defined goals for Quality Assurance engineers, know-how materials that allow for further training and exchange of knowledge among us.
Every Thursday, our QAs are required to provide the status of their assigned testing tasks. 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 QA 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 department. It allows you to manage the test run and is used during pre-release regression testing for the client. For QA engineer 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 project, strictly based on the 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 a 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 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.
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 QA engineer must remember the most important functionalities of the application from a business point of view and the correct operation of the application.
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 and what the client will receive after their completion. Tests begin when the client approves their 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.
In order to prepare a satisfactory test summary, you need to collect all important information 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. But at The Software House, it’s yet another document based on a created standard. It provides the client with a description of the carried-out tests, deviations from the test plan and the most important information – status of application quality.
The report should be legible and contain relevant information. 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.
How to learn to use standards?
A well-created standard is flexible to the needs of any project and has ready-to-use templates. However, the most important element in this process is to actually use standards and improve them through practice. It seems that Aristotle was one of the first QA engineers, as he said that:
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 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, basing on our experience and knowledge. Sharing is caring!
Don’t be afraid of standards! By using them you show your maturity as a QA specialist and introduce improvements to product quality and approach to work.