The online and mobile landscapes are ever changing because of the increasing number of competitors, carrier restrictions, and developments in the software platforms. The clients’ audiences also influence directly how successful web and mobile applications are. Besides that, users’ requirements and expectations are ever growing, so maintaining a high level of quality can eventually ensure the success of the software development company. The challenges that characterize the tech environment and the end-users can be easily overcome if development is accompanied by adequate quality assurance. After all, everything from physical gadgets to Facebook’s VR videos shot in Grand Central Terminal needs to undergo rigorous quality checks to make sure that they meet the standards imposed either by the industry or by the entities producing them.
Defined as ‘meeting the requirements,’ quality and its assurance mean to us more than just identifying the causes of the problems. We’re actually striving to improve the processes that help us prevent bugs, rather than curing them as they become apparent. In our vision, Quality Assurance (QA) needs to be complemented by Quality Control (QC), in order to guarantee that not only the clients’ requirements are met, but also that the needs of the end users are satisfied and even anticipated.
What Are the Main Web and Mobile QA Challenges?
Since we focus on iOS on the mobile side of things, the number of mobile devices doesn’t represent a challenge, but OS fragmentation might as well be regarded as one. On top of that, the different types of mobile apps (native, hybrid, Web) could put more pressure on the QA specialists. Other aspects that could make this activity more demanding include the great number of test interfaces and the diversity of testing tools.
How Do We Approach Quality Assurance?
To ensure that the product is qualitative throughout the entire duration of the project, our QA specialists work closely with several other roles. This way, all bases are covered and each aspect of mobile app development is analyzed thoroughly, from the clients’ environment to the product’s design.
The two aspects that we focus on are a close collaboration with the rest of the project team, which is particularly important during the Feature Peer Review (FPR), and a clearly planned process that’s based on three separate steps:
- Requirements Phase
- Development Phase
- Release Phase
During the Requirements Phase, the QA engineers participate in the analysis of the user stories. Next, they write automatic journey tests, do manual testing, and the aforementioned FPR. The Release Phase involves a workshop where the QA facilitates client acceptance. All of these phases are explained in great detail further down below.
Where Do the QA Specialists Fit in the Picture?
Quality Assurance really is something that needs to be part of any project from the very beginning. Right away, the QA specialists need to know the purpose of the product and the target audience. Such information helps them define the requirements that henceforth will become the standard to be met or exceeded. To gain access to such data, the QA specialists work closely with the Product Owner (PO) and the Business Analysts (BA). However, the collaboration between these roles doesn’t end here, as they also need to define such non-functional requirements as:
It is vital for the success of the project that the entire team establishes and understands the requirements right from the start. Among other things, doing so will prevent neglecting or even dropping any of them along the way.
QA & Design: Two Sides of Any Great App
No matter if we’re talking about web or mobile apps, design plays an essential role in how the final user perceives the product. Because of that, the quality of any and all app design elements should be assessed continuously. Hence, the QA specialists collaborate with the designers on such aspects as wireframes, UI design and HTML prototypes.
All of these are made at different stages of the project, but our approach enables us to measure and assure the quality of all of the ingredients as they are added, rather than checking the end result. The latter approach would most probably have disastrous results, as having to discover what went wrong months ago is not only time-consuming, but also frustrating, and could diminish the team’s morale.
The collaboration between these two roles continues during the QC phase, but that’s something we’ll discuss later in this post.
QA’s Role in Establishing the Scrum Definitions
Rather than letting the Project Manager (PM) or the PO create on their own such Scrum definitions as the Definition of Clean, Ready, and Done, we prefer to assign this task to the entire team. This enables everyone involved to agree on the criteria that best fit the project in case. Needless to say, establishing these definitions should happen right at the beginning of the project. Even though every team member has a say in this, it is the role of the QA specialists to make sure that these requirements are measured and met as planned.
On the bug testing side of things, the QA specialists and the rest of the team need to agree at the beginning of the project on how the bugs will be categorized. Hence, the types of bugs that might be encountered throughout the project are as follows:
- Blocker (the functionality is unusable)
- Critical (the bug makes the experience unpleasant)
- Major (reduced usefulness that doesn’t prevent the app from going live)
- Minor (secondary functionality doesn’t work as expected)
- Trivial (minor functionality or cosmetic issue)
The need for establishing these definitions arises from the fact that not all team members might perceive an issue the same. The defining characteristics of each bug helps the QA and the developers prioritize the order to solve them during the FPR.
Quality Control Complements QA Naturally
Once the QA specialists and the project team have agreed upon how quality should be measured, it’s time to proceed to testing it. The previous definitions help with classifying the bugs as soon as they are discovered, as this is one of the first things handled in QC. By having a clear image on which bugs are more serious, the team can prioritize solving them, fact that contributes to the overall success of the project.
The next phase of QC implies collaborating with a software developer on the FPR, but this is something we will detail further down this post. One important detail to keep in mind is that the QA specialist and the developer go through this process for each feature that gets implemented in the app.
Another task that is assigned to QA is deciding when and how exactly are team testing sessions done. Organizing and leading such sessions is up to the QA, and the only thing that’s fixed is that these activities should take place at the end of each sprint.
Aspects to Test Before Handing Over to the Dev Team
User Experience (UX) testing also takes place at this stage, as the QA specialists and the designers need to check, among other things:
- Use cases execution
- UI consistency
- Responsive design behavior
- Static testing and analysis
It’s important to make sure that all these happen before the development team starts working on the app.
Automating the Testing Process
Repetitive tests or tests that cause human error can hold back the development process tremendously. Even though app test automation involves a greater effort in the beginning, it eventually pays off. The impressive amount of time saved is reason enough to consider automation for tests that imply significant effort, but that’s only one of the advantages.
Agile environments involve ever-changing goals and processes, and even partial automation can help a lot with adjusting to such changes in direction. Of course, there needs to be a discussion about which tests should be automated first, and the general consensus is that the high-value/low effort ones should be prioritized.
To be able to automate the tests, the QA need clearly defined goals, a deep understanding of the app’s infrastructure, accurate app usage models, and cross-team collaboration throughout the entire duration of the project.
As for the tools we use for writing and automating the testing process, the options include:
- Calabash - a cross-platform tool for the automated acceptance testing of native apps
- Watir WebDriver - web application testing tool
- Ruby - dynamic, open-source programming language, used for writing automation scripts
- Cucumber - tool that relies on natural language to express an app’s behavior
- Protractor - end-to-end test framework for AngularJS apps
The type of app to be developed (native, hybrid, web) influences the choice of tools that will be used for automating the testing process, as follows:
- Cucumber + Watir WebDriver + Ruby or
- Calabash + Cucumber + Ruby for mobile apps
Choosing a set of tools over another depends on the characteristics of each project.
Our Secret Ingredient: Feature Peer Review
As mentioned before, each feature that’s being added to the product needs to be cross-reviewed by a QA specialist and a software developer. During the first part, the developer demos the feature, to give the QA an idea about what it is and what it adds to the product. The QA takes lead during the second part, as the feature undergoes thorough testing in order to see whether or not it meets the use case.
A list of Critical and Major bugs is put together by the developer, who should also proceed to solving them, as soon as the FPR is finished. Minor and Trivial bugs, on the other hand, don’t have as high of an impact on the Minimum Viable Product (MVP), so they can be added by the QA engineer to the project backlog.
This could be regarded as taking care of each other, as a second pair of eyes could offer another point of view on what works and what doesn’t. Such actions get reflected over our clients and partners, eventually.
The ultimate goal of the feature peer review is to create a more cohesive team that is able to cooperate better at all levels. Identifying the issues and prioritizing them depending on their gravity enables our teams to provide better products. What the cross-review does it to remove any biases the people from the same department might have towards their work, and enables developers to point out the issues as they’re discovered, and not just at the end of the project.
From our point of view, the FPR is one of the main differentiators between the linear approach to QA and the Agile approach. While the former implies major issues because of the fact that the product is only tested at the end, the latter ensures proper testing throughout the entire process.
It should be noted that efficient QA specialists have results that benefit more than just themselves. The entire project team, from designers and developers to POs and PMs, seeks to exceed the requirements of each customer, and without proper ways to measure and assure the quality of the project, their progress wouldn’t be possible. Thanks to their efforts, each team member can contribute to delivering a better product, be it a web or a mobile app. Given the competitiveness of the online and mobile markets, everyone’s contribution towards making better apps is essential.
While choosing better automation tools can have a great influence on the speed of the project, it is the approach that ultimately makes a difference. The agile QA process has clear advantages over the waterfall approach, as it enables us to discover the issues, solve them, and thus assure quality as we progress, rather than just at the end of the project.
This post was written by Alex, our experienced Content Writer. To find out more about Thinslices, get in touch with the company’s CEO, Emanuel Martonca.