Everyone stresses the importance of quality assurance in the development process, but do you really understand what hides behind these letters “QA”? What is quality assurance as such?
Some software development company customers imagine a young guy sitting in front of a computer just clicking through a ready piece of software (be it a simple website or a complex logistics management system) to check that each button works correctly. That’s why some customers don’t even want to pay for a quality assurance engineer. Instead, they insist, “I’ll test it by myself”.
But what if I told you QA is much more than just an inexperienced guy clicking through an application?
Quality assurance is a complex process involving several professionals with different expertise and isn’t limited to just testing ready software. Work on quality assurance starts long before the actual coding process and doesn’t end after the product is released to market. QA is your key to a high-quality product, so don’t neglect it. Instead, stick to these quality assurance best practices to ensure you make most of this process!
Quality assurance techniques and best practices:
1. Involve a QA team starting with the discovery phase
In most cases, the QA team enters the game only after some functionality is developed and needs to be tested. As a result, testers report a lot of bugs that could have been prevented with proper planning.
But, it’s a good idea to involve a team of various professionals in the discovery phase. That way, everyone has a chance to improve the development plan from their expertise perspective. A project manager plans sprints and budget, a developer offers more efficient technical solutions, a designer brings fresh ideas about user experience and current trends in UI, and finally, a quality assurance engineer introduces a more complex view of the development process based on his experience in testing various applications. He can foresee and prevent certain problems in app usage or issues with integration and compatibility of different services, etc.
Changing anything in design or technical implementation at the planning stage isn’t painful. But when problems are discovered in the ready product, changes can end up costing quite a bit.
By participating in project discussion and planning, a QA team can better understand the scope of the project and foresee and reduce possible risks. The results of this phase are detailed requirements and an exact roadmap for the whole development team on how the project scope will be reached.
2. Plan and record your testing process
Sometimes, it seems like planning the testing process is a complete waste of time. A QA team may think they can quickly test a product’s functionality and interface intuitively or on the go. But even so, planning is one of main quality control best practices, especially when it comes to complex projects.
The quality control process should start with writing testing documentation. This documentation is often a checklist of what requires testing. The document also lists out the tools needed to run proper tests, required devices and environments, and acceptance criteria that define whether the final product corresponds with customer’s initial goal.
Proper planning allows the QA engineer to prepare for the testing process. Finding out that some testing device is missing at the start of a test automatically means that a test has failed. If that happens, you’ll have to wait until the required device is received (which can take several days). Meanwhile, the number of untested features and bugs grows.
Later the QA engineer can check the tests he has finished and maintain control over the process. Testing documentation is also very helpful for new members joining the team. They can quickly jump into the quality assurance process.
3. Test-driven development
Test-driven development is a type of agile software development methodology that’s become one of the main principles of extreme programming. In order to achieve the highest quality product, extreme programming values frequent releases in short development cycles, extensive code review (often achieved through pair programming) and unit tests that cover all the code.
But, test-driven development is also used as a separate approach to producing the highest quality code in the shortest amount of time.
Adding or changing functionality starts with writing a test that covers the desired change. After that, code is written to pass the initial test. It is considered a good practice when a developer writes tests for his own code. When he does that, he understands requirements for a new functionality and develops it to pass the test.
So, let’s dispel the myth: software testing begins before actual programming. If testing occurs after programming, a developer is lured into to write the test to fit existing code, not vice versa.
4. Obligatory code review for every single feature
According to quality assurance methods, development for each new feature should start in a single branch. This approach enables to follow changes and test them locally. Besides, the development team can use these code reviews to ensure everything works as it should without breaking the ready functionality. When the feature is programmed, it should go through an obligatory code review conducted by another member of a team. Code review has one clear aim: to find any weaknesses that could have been overlooked during initial development to improve overall code quality.
Involving someone else in checking your code doesn’t mean you’re questioning your experience and skills. A view from another perspective is beneficial. It allows you to discover obvious weaknesses you overlooked in the code as you focused on solving an important problem.
Besides, this approach will enable your company to develop and adhere to its unique coding standard. As a result, the code becomes well-structured and understandable for all team members.
5. Don’t neglect integration testing
A feature may be tested in isolation and perform seamlessly, but after merging it with the rest of the product, it may break everything. That’s why integration tests are something you should never neglect.
It is also important to conduct environment tests. A feature may work seamlessly in the testing environment, but minor or major bugs may appear when moving to production.
Integration testing is especially valuable when two separate teams are working on frontend and backend development. Sometimes, putting these parts together results in an error. The reason for this error could prove quite minor and totally unpredictable. For example, different date formats used by frontend and backend development teams due to a lack of communication may cause a hidden error.
You can’t say a feature is ready until it’s been tested as a part of the whole product.
6. Automate when possible
Usually, every feature should be tested more than once. Ideally, a test should be conducted whenever something is changed or added. Automated testing can help you avoid monotonous manual work, especially when it comes to regression tests, which should be repeated frequently. In this case, you program software to automatically perform the actions needed to prove the quality of the developed product. Automated tests have a lot of advantages, like an ability to test several products at the same time on different devices, an ability to test outside of working hours, extremely precise test results, and more.
Know, however, that preparing automated tests does take more time than manual testing, and this requires specific automation testing tools, most of which are paid. So, make sure that you automate only if it is really worth it. Usually, if a single test case needs to be executed more than twice, it is a good candidate for automation. Careful planning of testing process will enable you to make the most out of test automation.
7. Keep in mind user experience
The QA engineer must prioritize end user experience over preferences of the customer or view of the designer. A good QA engineer forgets the latest trends and instead focuses on the experience software users should receive.
To understand what the user expects from the application, it is important to build a buyer persona in the discovery stage. A buyer persona is a detailed description of your ideal user and their habits and preferences. This information will help you build a product your target audience will appreciate.
When it comes to testing, a QA professional should walk through the whole application from the point of view of the end user. For example, if the product’s target audience is elderly people, it is important to pay attention to buttons size and text readability. Imagine whether your grandma would be acquainted with all gestures required in an application. Maybe, it would be better to give up all swipes and make the interface as simple as possible?
8. Ask questions
Sometimes we avoid asking questions because we’re afraid of looking stupid. But in software development and quality assurance process, there’s no room for being shy or too self-conscious. Communication is the key to a successful product.
A QA engineer should communicate with the rest of the team, and the entire team (and not just the PM) should communicate with the client. The more often you communicate, the better. When communication flows freely, all questions are answered immediately and there is timely feedback. As a result, the client and the development team move together towards the end goal much more efficiently and bypass misunderstandings.
9. Keep the whole team under one roof
Sometimes, a client wants to save money by hiring several professionals with different expertise and from different countries and time zones to work on a single project. Such an approach negatively affects communication, tasks assignment and execution. If a team member needs credentials from a colleague who works in another time zone, he may have to wait for several hours. The work is paused, but money keeps flowing. Instead of reducing the budget, the client then must face deadline breaks and unexpected expenses. And, as we all know, poor communication results in quality issues.
The best outcomes occur when the whole team works in one place. Even if this may seem more expensive, in the long run, you’ll save a lot of time, money and brain cells.
Conclusion
Quality assurance should not be seen as a single stage in product development process. The set of QA best practices outlined above should be followed starting from the discovery phase up to product release and beyond, including support and maintenance.
Of course, it is not necessary to implement all these quality assurance best practices in one project. A strong and experienced QA team will choose the right approach and the right tools to match the needs of a certain case. The expertise they’ve gained from previous projects will result in a seamless workflow and exceptional end product quality.
Interested in reading more content like this? Then our blog is the right place for you. Subscribe to our mailing list to receive the best business and technology-related reads monthly.
