Table of Content
As featured in DevOps.com
Up until a few years ago, quality assurance was generally considered low level R&D. As a result, QA teams were characterized by a low budget, lack of attention, and more often than not, poor attitudes. Moreover, QA engineers were considered the enemies of developers and the product.
However, today, this is no longer the case, and QA is part of the entire software testing lifecycle. Today, organizations understand how a product’s quality affects the brand’s reputation and customer retention. In the agile eco-system, QA engineers no longer solely focus on testing, but also fill an important role in the planning and delivery domains. The shift left approach—where testing is performed earlier in the lifecycle—requires QA engineers to have higher technical abilities and involvement in the whole CI/CD process. Nevertheless, QA managers, who usually encourage assimilation in the scrum team, as well as rapid feedback on user stories and automation, must not forget the main objective of quality engineers— a high-quality product and a seamless user experience for customers.
High quality demands testing and verification. There are different types of ERP testing that can be conducted in order to meet quality goals. In one of their blog posts, Testing Excellence describes almost 60 types of testing that can be performed on a product.
What is functional testing?
Functional Testing is quite clearly one of the most important types of testing. Unlike other forms of testing, Functional Testing is considered one of the most sophisticated test type, and the most comprehensive one. It’s focus is to ensure that a software system or application functions as per the requirements, determined by a set of specifications. The results are black and white: either a clear pass or definite fail.
Same Team, Very Different Responsibilities
One important fact every QA engineer must remember is that developers develop and QA engineers test. Even though QA and developers are part of the same scrum team, their work, methodologies, and state of mind are completely different. In cases in which the significant contribution of QA isn’t visible to the whole team, testing might be considered an easy and clear task. Quite the contrary, testing an application is much more complicated and entangled than developing it. When planning tests and executing them, QA engineers must take into account several aspects developers likely never consider.
-
Thinking Like a Customer
The primary distinction between dev and QA is state of mind. While developers write pieces of code that later become features in the application, QA is expected to understand how real users think, engage customers to learn business scenarios, and confirm that the application satisfies customer needs.
Let’s look at eBay, for example. Every veteran R&D member will agree that eBay isn’t just a simple shopping application, but a comprehensive system. eBay includes a complete set of web and mobile capabilities that must be scrutinized with attention and understanding, in order to ascertain they function correctly. In such a rich and mature online platform, we can identify several types of users and many cases in which the application may be utilized. A seller performs different steps than a buyer and requires different functionalities, while a support agent needs an entirely different version of the application. When planning tests, all these personas must be taken into consideration with a particular test plan for each. Testing functionality is not just simulating user operations.
In addition, eBay is not a standalone application—its web application lives inside the browser and subsequently, depends on that browser’s rules and behaviors. This is true for eBay’s mobile apps as well, which must meet the OS constraints for it to function correctly, whether it’s navigating to the seller’s store or making a purchase.
This makes compatibility testing an integral part of functional testing. Most developers do not think about the product availability matrix when they code; so QA is required to contemplate all the ways the customer will engage with the application and verify functionality for each.
-
Testing the Application as a Whole
The first and most obvious attribute where dev and QA differ is their point of view. While developers focus on developing user stories, QA tests the user story that the feature it is part of, and application behavior with the new code. Integration testing is a crucial part of the application verification effort and requires a broader view of the application and how the new functionality integrates with it.
End-to-End testing is the fulfillment of the above two aspects, validating that real user scenarios behave as expected in the context of multiple regions. End-to-End tests increase test coverage and reduce the risk associated with integrating new code into an application.
-
Understanding the User Experience
As previously explained, testing an application’s functionality is merely one step in functional testing. Testing the operations available in the application encompasses another type of testing—the user experience. If a new feature was developed but users do not have easy access to it or cannot understand how to use it, it is as if the feature doesn’t exist. QA engineers must incorporate user experience as a main metric of features so users will not have room for error, which can lead to misuse and frustration.
For instance, in the past, eBay’s “all categories” page displayed all the categories by default, even though some of the categories had no items. While functionality-wise, this was the correct behavior, this caused user confusion and mistrust, and the “all categories” view was subsequently changed to show only categories with items.
A “tunnel vision” approach to a current task at hand might lead developers to implement features as they are told, without questioning or contemplating the specifications. In the same way, testers who test features without realizing how customers perceive them are missing an important benefit of the test.
The above three aspects—thinking like customers, testing the application as a whole and paying attention to user experience—revolve around the way developers and QA engineers relate to new features. While developers tend to have one-track minds and follow the specification guidelines, QA testers need to think outside the box when it comes to user consumption of features. Let’s consider the next two aspects that make QA work complicated and yet invaluable—test maintenance and test automation.
———-
You might also like our blog
How to Structure Your Release Management Process
———-
-
Ensuring High Quality Throughout a Release
In general, developers split their time between developing new features and fixing defects. QA work is much more diverse. A substantial portion of the release is spent on testing functionality which was already released and used. While the main effort of designing and writing test plans for this functionality is invested in past releases, every new feature developed requires a test plan and a maintenance effort on existing tests. One of the main goals for QA managers is reducing this effort to a minimum. Teams that succeed in creating clear and reusable tests simplify the maintenance struggle and optimize the test registration time.
-
Using Automation to Eliminate Risk
However, for QA, the most cost-effective solution is test automation. At a release’s end, while QA is at its most stressful period and every commit might introduce a new risk, automation of testing eliminates risk and provides early feedback on every change. Agile teams strive for the highest automation coverage percentage, so the development team can have confidence in committing changes late in the release. Only, development isn’t interested in investing time in automation. Sure, they support the QA automation effort, but they don’t want to “dirty their hands” testing. Whether it’s UI automation – during which achieving element uniqueness is essential, yet tricky and requires development intervention – or API testing for APIs, without proper documentation, QA faces intricate challenges that require sophisticated solutions. In most teams, however, development is not part of those solutions. While the development team focuses on the status of new features, QA attends to the application as a whole, with extra attention to identifying regressions created by a change.
Make the QA Process Visible to Everyone
Testing an application requires a completely different mindset than developing it. One of the main challenges in the agile methodology is to create development awareness of quality, involving other stakeholders in the quality assurance activities, and making the QA process visible to everyone. QA managers must understand how day-to-day QA work is different than the work of other team members, so they may truly represent the complexity, efforts, and eventual success. R&D groups that join forces and understand that QA extends far beyond the actual tasks of the QA team, set high standards for their product’s quality and have a much higher chance of improvement. Implementing the appropriate methodologies and utilizing the right tools lead to an increase in customer satisfaction and retention rate.