How To Survive as a QA in a Software Development Team

It is not always easy to be a software tester in a software development team. Developers will often consider software quality assurance (QA) people as inferior and would wonder how they could question the perfection of the beautiful code that they have just written. In this article, Alexander Rayskiy discusses some of the physical and psychological issues that software testers are facing and propose solutions to avoid them. Author: Alexander Rayskiy, XB Software, What is usually considered in the first place when it comes to a discussion of a successfully finished software development project? Developers’ efforts, used stack of technologies, pros and cons of the chosen development methodology, etc. But the issues which the software quality assurance (QA) team members face from day to day are usually barely mentioned. In this article we will try to shed some light on this question and consider possible solutions of the most significant problems. The list of day-to-day disagreements that can crush the will of a QA specialist can be divided into two groups: physical and psychological aspects. Physical aspects are caused by the peculiarities of the industry and describe the trends characteristic for most companies. Psychological aspects mostly belong to the sphere of interpersonal communication. You may or may not face them during your professional activities. It depends on the experience of your colleagues, features of project management, and other aspects specific to a specific company. Physical Aspects: QA to Developers Ratio and Gender Imbalance This section contains the issues associated with the software development industry itself. Even if you don’t have any experience as a member of a software testing company, you can predict some of the issues by analyzing the available statistical data. For example, let’s take a look at the ratio of testers to developers. Choosing the proper number of the QA team members depends on many aspects. Not all companies follow the Microsoft’s golden rule: “Keep developers to testers ratio equal to 1:1” and the most common ratio is 1 tester to 3 developers. It could even be 1 tester to 10 developers in some cases. The point is that in the most optimistic scenario, a QA specialist will have to handle the code written by three different developers. As a minimum. If the workflow was not adequately planned, you could find yourself overwhelmed with tasks very quickly. It can lead to a decline in productivity, stress, and frustration. Some software development approaches, like Scrum for example, imply regular meetings that can help discuss what has been done, what needs to be done, and what problems does the team have. This Agile context is a good chance for a software tester to attract attention to a great many tasks he or she has. But in the case of larger V model or Waterfall based projects that don’t imply regular meetings by design, there should be a mechanism for communication between teams. The project manager has to ensure that there are no unspoken opinions and QA team members are free to discuss the problems they face as well as ideas to solve them. The next issue is related to the gender imbalance in the IT industry. According to the statistics, developers are mostly men and the world of QA is represented mainly by women. This situation can lead to different issues. The most obvious consequence is that the relationships between these teams can go far beyond professional etiquette. The problem can take different forms. The most innocuous of which is the common difficulties of communication between groups of males and females. Inappropriate behavior and flirting are fraught with more serious consequences and can influence the psychological climate inside the company. Strict company policy regarding inappropriate behavior in the workplace should be brought to the attention of all employees. Psychological Aspects: “It Works on my PC” and why Team Building is Important From time to time every QA team member faces the situation when a developer or a manager disagrees that a detected bug is a bug despite all the evidences. The arguments may vary. The most common situation usually looks like this. You come to the developer and describe the bug that you have just detected. But instead of running to his working place and fixing everything, he makes a helpless gesture and tells you: “But everything works fine on my PC!” Attempts to convince him to your point of view may spoil the relationships within the team and complicate further work on the project. It may look like a complex psychological issue, but it may have a relatively simple technical solution. Make sure that QA and development teams run the same environment. This approach can help to avoid the above problem. Despite the fact that the peculiarities of the profession associated with solving technical issues, non-tech problems can be pretty difficult to overcome. Since you work with other people you should always remember that the impact of human factors such as subjective judgment can’t be underestimated. For example, what should you do when the project manager is so intended to finish the project as soon as possible, so he insists that a detected bug is not a bug at all and there are no reasons to spend extra time and efforts on solving it? Strict specifications and knowledge of products of large companies with similar functionality are magic pills that can prevent the possibility of discrepancies. Indeed, if your company has clearly defined what is a bug and what is a feature, then you don’t even have to convince anyone of your conscientiousness and can be sure that the work is not done in vain. When you know exactly what your potential competitors have to offer to their customers and there is a bug that can break the functionality of your product and deprive you of a competitive advantage, ignoring it can negate all efforts. Any manager in such situation will treat the opinion of the testing team with due attention. The burden of responsibility for the quality of the released product is usually on the QA team. Unfortunately, in most cases, the ideas for improving the workflow proposed by testers are ignored. You can imagine what psychological pressure can be caused by the described situation. You must release the product in a limited time, you have no influence on how everything is done, and at the same time, you are considered responsible for its quality. It is an unpleasant situation indeed. The power to resist such challenges usually come along with the experience. If you can’t change the situation, you have to adapt to it. Even if you have to work on a tight deadline, don’t rush. Spend as much time as you need to prioritize code checking and depth of code coverage correctly, and you will be able to avoid undesirable consequences. In most cases, the team of developers keeps apart from the QA team. Developers stick together, share common interests, and keep the distance from a person that looks at their code as a pile of bugs. Taking into account the fact that the overall number of testers in the company is lower than the number of developers, a QA team member can feel himself as an outcast sometimes. It can lead to a situation when testers and developers perceive each other as members of different castes but not the parts of a common mechanism. Various forms of team building activities can correct the situation. We do not necessarily talk about something costly. The key goal of team building is learning to solve problems together. In order to do this, you don’t have to climb the mountain along with your colleagues. This sounds exciting, but is not necessary. There are a lot of activities that can be held in your own office and will not take more than 20 minutes. Show some creativity and you will find dozens of ways of creating a team spirit. Conclusion The climate within a software development company is a pretty sensitive theme. The IT industry is a heterogeneous environment, and there is no single solution that can fit all the companies. Creating a good team spirit is a job that requires adaptation to conditions and flexibility. The desire to show one’s will despite everything will rather harm than benefit. We hope that combining the approaches presented in the article, you will be able to find your own and unique way of building the software development dream team. About the Author Alexander Rayskiy is Head of QA Department at XB Software. He is an analytical and responsible QA professional with strong leadership and people management skills. Alexander can easily define and implement effective test strategies. He perfectly manages QA staff both on internal and external projects, and takes care of providing QA staff augmentation services to meet the clients’ needs.