Quality assurance is more than just testing. Not only QA experts and testers should be involved in it. The misconception that quality assurance can be summed up as testing software applications that already work can be harmful to the development of your project. Let’s take a look at how, and go through setting up a proper QA process.
QA should be an element during all the steps of the software development process. Everyone should be involved in it: programmers, UI/UX designers, QA experts, business analysts, and even project managers. How?
Here’s a list of some activities that help ensure the high quality of development:
- checking requirements (what needs to be done) regularly to avoid misunderstandings and issues arising from changing business conditions,
- selecting the best libraries and technologies, which helps the development team meet the needs of the clients’ application,
- writing unit tests (done by developers),
- conducting code reviews (by separate developers),
- running UI/UX reviews or leaving implementation to UI/UX developers,
- software testing (for example system, regression, exploratory testing), generally performed by QA testers,
- acceptance testing, usually on the client’s side, to check if newly implemented software meets requirements and business needs,
- alpha/beta testing, during which a small number of users gets access to the app and shares feedback about what’s good or bad,
- A/B testing, which means preparing two versions of the app (or an element of the app) and checking which one is better for end users,
- deployment and failure prevention is also a crucial QA process,
- keeping backups and ensuring servers redundancy are ways to prevent critical failures from impacting the project too badly,
- automatic failure logging, to keep effective project analytics,
- running application logs, e.g. logging requests that are called on the server.
This is a long list of activities, many of which won’t be performed by QA experts. It illustrates why it’s so important to use the capabilities, experience and perspectives of the whole development team for quality assurance.
A real-world use case of a good development process flow
One of real-world uses of a good development process flow is using CI/CD tools that allow you to automate multiple steps. An example flow can look like this:
1. Development team plan
Time to set up the team, gather requirements, check the feasibility of specific ideas, and review the requirements to find potential issues.
2. Requirement design
Requirements should be designed for best results. For example, UI/UX developers might prepare the application design and wireframes for the front-end of the application. Programmers can design the structure of the back-end application and decide how the requirements should be implemented.
3. Development
This is the longest and most complex stage, but it can be roughly divided into simple steps:
- A feature is implemented.
- The developer writes unit tests as needed.
- The developer creates a pull request and sends it to an external repository (like GitHub or GitLab).
- Once the code is pushed to the repository, CI/CD tools can do some steps to check its quality:
- Unit and integration tests can be run once more in a separate environment;
- Static code analysis tools can check code quality, and find out if current code writing guidelines are met (for Ruby, the most popular tool is RuboCop);
- Automated regression tests can be executed. This step can partially automate the process of functionality testing, system integration, or acceptance testing. These tests are known as feature tests. They simulate user behavior in the application, finding defects in a fully functional application. Executing feature tests on every pull request can shorten the development process by finding defects without shifting the feature onto the QA testers’ plate.
- Next, it’s time to move the feature ticket to the code review column - the developer assigns another developer to review the pull request.
- If the review goes badly, the feature ticket is moved back to the original developer to fix the problem. Once it’s fixed, a new version of the feature is pushed to the pull request (CI/CD execute prepared test steps), and then once more to code review.
- After code review end in a success, the ticket is moved to QA testing. If it’s necessary, UI/UX developers can test the UI/UX that was implemented.
- If QA testing helps discover new problems, the ticket goes back to the developer (they fix the problem, push the pull request, move to code review, and then again to QA).
- If QA testing goes well, the ticket can be either moved to acceptance tests (where the implemented feature is checked on the client side to make sure it meets project needs) or deployed on production (a good example of when this might happen is for continuous integration and continuous deployment methods) through a prepared CI/CD flow (for example, after the code is merged, CI/CD set off a process that automatically deploys the code on production).
And that’s it. The result is a working feature implemented on production. As you can see, quality analysis begins long before the QA experts step in. After all, why should they work on code that isn’t actually finished?
Requirements design
During this step, it’s important to make sure that all features are adequately described and complete in their design. They descriptions should be detailed, leaving no uncertainty as to what business logic should do. Another critical point is to write requirements that are understandable for both the business and software development teams. Often, business analysts use a very specific jargon that IT teams do not understand. Additionally, some “obvious” things may be omitted by the business team - and leave the IT team confused! The same is true the other way around. Make sure that the requirements are clear to everyone involved in the project.
Software development
A good software development process implements many QA processes even without QA testers. Major ones include unit and integration tests. Usually, they are written by developers and should be an integral part of software development. A lack of tests is seen as a very bad practice.
What are the main benefits of unit testing?
- Improved code quality - small problems are identified and dealt with earlier;
- Agile development - an approach that can save time and money when implementing new features which require changes in old logic. It helps find defects that can break the old logic;
- Early bug detection - software developers can check their code on pre-prepared test scenarios and fix issues very early on, without involving another person;
- Room for code refactoring - with unit tests, developers can more easily refactor code (improve the code logic of already implemented features). It is much easier to change the code when there are tests that check if the code does what it should;
- Better documentation - unit tests are one of the processes that can go into the project documentation, preserving information on what each method does;
- Simplified debugging - tests failing when a change has been made are a great way to locate places where application responses are not correct;
- Feature design and implementation - within the right software development process (for example TDD - test-driven development), unit tests allow developers to design and implement features. Developers can think about how a feature should be implemented and write tests based on this knowledge;
- Reduced costs - unit tests allow software developers to fix issues as they fail during the feature implementation step. They also do not require testing by other team members, allowing them to focus on moving the project forward.
Code review
Code review is a very important step in the QA process. It means a new developer (or several developers) checking the code. This can greatly improve code quality, as the reviewer can find more potential defects with an unbiased eye (they are not affected by code that was written).
In multi-developers teams, code review is usually done through code exchanges between team members. In smaller projects where only one developer is needed, code review can be done by another developer in the software agency (a separate developer that only does code review in the project).
The main benefits of code review include:
- Feature design and implementation stay consistent,
- Code review can identify defects, as well as security and performance issues - this is true even for static code reviews,
- Much higher probability that requirements will be met,
- Improved code performance through best practices and better solutions,
- Application of new techniques, which better match the constantly changing software development standards.
QA testing documentation
Aside from normal testing while the product is being implemented, the QA process should also include test reports and written documentation. On the QA testers’ side, documentation writing is in the most part of writing test scenarios, test procedures and test plans.
Test cases, test scenarios and test procedures are valuable to the entire development team, as they provide information on how to test each feature, and which elements should be checked carefully. They also allow people who do not have any experience in the project, or non-technical team members, to correctly test the application’s features.
To make sure your project will benefit from proper QA testing, check out our guide to the 7 stages of testing an app.
Deployment and failures recovery
Another critical part of quality assurance and the development process happens when application is going live. Deployment is often automated and connected with CI/CD processes. Such deployment automation limits the risks of human error, makes results more predictable, and reduces deployment time.
A good deployment process should also cover backups and include a rollback strategy. Rollbacks are very important when pushed changes do not work as intended. Often, a rollback to a previously working version needs to be performed as quick as possible. There is no time to prepare fixes. For example, if new code that is pushed on production requires a change to database schema, developers should write a method to revert the changes on DB in case of failure. This way, they’ll be able to revert to a working version right away.
Backups are similarly critical to any digital business. They are needed for ensuring that application data will not be lost in case of trouble (software failures, servers issues or even malicious attacks). Good backups processes should be automated and executed on a regular basis.
Maintenance and errors logging
Application logs can provide crucial information about what happens in the application when something fails. Error logging can also very quickly inform the development team that there is a problem. This way, the team can quickly mitigate the issue and deploy necessary fixes. Logs can therefore greatly reduce costs (application is not working at least in some part, which may prevent it from achieving business goals) and time (normally, the client has to notice and then inform the dev team that something is not working).
There are many popular services that track errors logs, like Rollbar or Sentry. When dealing with production error reports, documentation is one of the most important things. Without it it is very hard to understand how the application should work and why errors may be occurring.
Involving other team members
Project managers are a part of the quality assurance process, too. They have an important role to play: managing the development team, ensuring that work is going smoothly, maintaining contact with the client. At first glace, it can look that they do not add to the QA process, but that isn’t the case. A projects without a PM is less organized and can move more slowly compared to projects with PMs. Because quality assurance depends on good organization, PMs affect it deeply, if indirectly.
One more thing to consider in the QA process
An important issue to consider is the degree of test independence. What does it look like in your projects?
- There are no independent testers - the developer who writes the code test the code.
- Independent developers or testers are present in the project team - code review is conducted and QA experts test the app’s features.
- The organization maintains an independent test team - they do not work on the project, aside from running tests.
- An external team is brought in for testing.
Choosing the correct degree of independence can be difficult, as each level has its pros and cons. Sometimes, using multiple levels of test independence within the same project is the most beneficial option.
Conclusions
Quality assurance is present in all the steps of the development process. To ensure the highest quality of your product, make sure to keep this in mind - or work with a technology partner who uses a fully developed QA process.
Ready to get started with your next software project? Let’s talk.
iRonin.IT’s experts use a tried and true QA process, best development practices, and highly valuable know-how.
