Have you ever wondered how big football clubs achieve success? Is it because they simply hire good players, bring in the best coaches, or have the best managers, directors, or player benefits? I don’t think so. The same applies to successful companies, especially their IT teams and the quality of their products.
We often hear complaints from managers: “We need better quality!”, “We must have zero bugs in production!”, “We need to automate all test cases.”, “All QA professionals should be involved in automation.” We can provide more examples that most IT professionals are familiar with.
However, the reality is that when it comes to practice, it’s often a different story. Do all managers truly prioritize quality?
Do they establish transparent communication with clients, stakeholders, and sponsors to advocate for better quality from their teams? We don’t think so at all. In this article, we will focus on the main QA problems and explore ways to optimize them in the realm of Quality Assurance Testing.
Testing Process and Quality Assurance Testing
In every software development environment, customization is essential to align with the specific needs of the project and the teams involved. For instance, if you have a robust team that conducts thorough local testing, it significantly simplifies the life of Quality Assurance (QA) professionals and enhances the overall product quality. Supporting User Acceptance Testing (UAT) and production becomes more straightforward.
However, when you lack a strong team, challenges arise. This is where proactive QA practices become crucial. QA professionals must actively engage, cover edge cases, maintain a proactive stance, and prevent themselves from being used solely as a means to identify all bugs. Effective communication is pivotal, with a preference for clear and concise written communication. The team should perceive the QA engineer as the guardian of quality, ensuring that nothing is merged into the release branch without rigorous Quality Assurance Testing.
Another crucial aspect is test case creation and analysis. Encouraging a collaborative environment between senior and junior members is invaluable. Junior QAs can acquire knowledge beyond testing, learning how to write test cases and analyze complex scenarios.
In our opinion, the senior-junior partnership can be more effective than a senior-senior relationship, particularly in manual testing projects. Junior team members can focus on smaller user stories with fewer story points, while senior QAs can dedicate their expertise to more intricate tasks. This approach allows senior QAs to avoid investing time in smaller user stories, such as those related to UI, translation, or minor changes.
The Role of Test Automation in Quality Assurance Testing
A new trend in developer-based companies is the “automation of every test case.” However, there is still a discussion among QAs about whether automation is a support tool or the main tool. We still think that Quality Assurance Testing is the main supportive tool.
Everything can be automated, but is it going to be effective enough? How long will it take to run every test case? Automating every translation, button text, and every step combination will be useful? How much time will QAs spend automating? How will automation suite maintenance be handled? Dreaming is good, but reality with automation should match needs.
The automation test suite should be smart enough to cover main patterns, integrated parts with other systems, or third parties due to changes, and repeating issues as the main focus. Then, if there are enough QA resources and time to develop and refactor automated test cases, the test suite can be expanded. Working smart is always better than working hard.
Training of New QA Members in Quality Assurance Testing
The onboarding process can be expedited by immersing QA members in real problems. How? By creating a bug, testing a feature, analyzing a user story, and automating test cases but always under true mentorship. When you engage with someone who shares knowledge and highlights key points, the onboarding time will be shorter, and new members will encounter more problems and solutions. Increasing the diversity of problems and solutions will create an understanding of the project.
Identifying Bottlenecks Before Releases in Quality Assurance Testing
Like a sixth sense, it is expected from QA to anticipate
bottlenecks in the testing cycle. What can be the reasons for bottlenecks? Some of the main reasons are as follows:
- Dependencies
- Back-and-forths during testing
- Pending open questions during the development process
- An unoptimized test execution plan that causes repetitive work
- Not well-designed processes during the software development life cycle
- Scope increases during the development process with no defense from team leads, project managers, or scrum masters against sponsors or system owners
All these main reasons should be considered individually and handled according to project needs.
Approaches of L1-L2-L3 Application Team Supports in Quality Assurance Testing
Another challenge lies in production support teams. Production support teams have direct contact with application users, business, system owners, basically everyone, sometimes even the CEO or managing directors. Application support teams have a lot of repetitive work that should be handled by the L1 team, which is responsible for triaging and resolving the problem. However, most of the L1 team members are not well-trained in best practices and how to handle situations when the number of incidents is increasing. For example:
- Minimum incident criteria to include in tickets for the L2 team
- Trying to reproduce on a lower environment for experienced L1 teams
- Understanding the application
- Providing specific documentation for L1 teams to answer users directly or providing users with the correct KBI to close incidents to prevent business escalations
The L1 team needs support from L2 always. Those teams are connected to each other to solve the problems. One of the biggest responsibilities of L2 teams is the training of L1 team members in clear incident ticket creation. What does it mean to create a clear incident ticket?
- When a ticket is raised to L2 teams, it should contain enough information for L2 to look into the problem.
- L2 teams should be aware of connected system abilities to address incidents to the related system instead of closing tickets “as designed.”
- In P1 issues, they should be capable of organizing L1 and L2 teams for potential upcoming questions from other systems.
- L2 teams should come up with improvements to decrease the number of reported incidents from “users” to “L1” and “L1” to “L2.”
L2 teams should be in good communication with L3 teams or product teams where new features are provided. There are a few reasons behind this:
- For new features and changes, L2 support teams will have open questions to discuss.
- On P1 issues or critical issues, collaboration between L2 and L3 or product teams is very important in solving issues.
- Release notes or demo meetings will always bring more questions to L2 and L1 teams. Those questions should be communicated with product teams.
There are different approaches in each case and each team. Simply put, everything is based on communication and a well-defined process setup. Due to team needs, project needs, and business needs, all ideas should be built and customized on the core agile process in the context of Quality Assurance Testing.