When a software product is a success – the developers get the glory and when it fails – the testers get the blame! That’s the unfair story of a test professional’s life. It’s kind of weird that even when from an end user perspective quality of the product matters the most, software quality professionals are so many times referred to as the “poorer cousins” of developers. I have been at the brunt of this discrimination from some of my “coding genius” friends as well colleagues, even if it was in the form of humor. But on a serious note this really is the mentality that exists across the industry.
A deeper analysis of this status quo clearly points to one factor for testers not getting their dues. It is the sense of negativity attached to the role itself. Agree or not, no one likes to be told about their mistakes and then being asked to fix those mistakes that too in a short interval of time. It is this basic philosophy that needs to change. We need to move away from “breaking the product” culture to “building a successful” product culture. I think test teams themselves have the biggest role to play to make things turn around. Associating a positive meaning to their work can help test teams being valued for their hard work and contribution in the success of a software project. The onus lies both with managers and team members. Some things that can change the way test teams are looked at and perceived are –
- Rise above numbers – While trying to explain this I am reminded of a funny incident. A few years back, one of the “finicky” managers that I was working with wanted me to collate the number of issues that were raised by each of the testers in the team and then publish this on the daily dashboard. With all due respect, it was his idea of developing a competitive streak amongst this group of graduate trainees we had in the test team. When I look back, the whole approach sounds pretty much flawed. By doing so we were moving away from the goal of delivering a successful project to being the reason for failure. As a lead/manager, it is necessary to condition your team not to look for defects just for the sake of numbers. Testers/Test Analysts should be smart enough to hit the areas of core importance and raise critical issues that hinder a project from going live on time. Raising 10 issues contributing to typos, content mistakes, look and feel won’t help as much as raising 5 functional defects that hold back a product from going live would. Working with this approach will reflect the test team as an enabler in delivering a project on time with optimum quality.
- Defect Free Product is a myth – It is important for test team to understand that a 100% defect free product delivery is far from reality. Testers need to align their work with this fact and should not hold back a sign off because of a few trivial open issues. They could always be passed as a caveat and be fixed at a later time. The decision has to be taken between the project and the customer teams; however quality team can help them to do so by providing an impact for such issues. So again this would make them a collaborator rather than an inhibiter.
- Help Projects make informed decisions – Test team can play critical role in go-no go calls. A summary of test cycle with clear and concise impact of open issues, defect fix rates, pass/failure rates etc can be strong basis for going forward with the release or not. In this manner the test team gets to play a more significant role rather than just pointing out the developers mistakes. This again puts quality guys in a better light.
- Early visibility of Test Teams in the SDLC – It is a proven fact that a great number of issues can be avoided if testers are involved early in the project life cycle. The cost to fix an issue that is caught during the requirement analysis is far less than when it is caught after the code implementation. Also, this helps in collaborative relationship building between the test and the development teams. It helps in bringing them at par in terms of what software is expected to do and thus, working towards a common goal.
- Moving towards Agile – A good way to implement a collaborative approach is moving towards agile. Agile gives the opportunity to every team member to be involved right from the beginning of a sprint. It offers the test team to be more versatile and has tasks assigned throughout the sprint and not just at the end of the development as opposed to waterfall. Testers in agile ensure that quality is built into the code right from the start. Their role is more than merely testing. Agile sort of integrates the team into one single unit working towards a common objective. Agile Development is in sync with “building a successful product together” philosophy.
There is no data to prove that testing is any less important than development for the delivery of high quality software. It is the negative mind-set that needs to be changed that surrounds testing. Traditionally, testers and developer have been pitched as each other’s rivals. Elimination of this rivalry is the first step for testing to get its fair share of acknowledgement. A product fails not only because testers let the bugs percolate into production but also because the code quality might have not been of a certain standard when it was first delivered for testing. Be it failure or success it has to be a shared responsibility by the team as a whole. Test Teams should not be obstacles to delivery, they should rather be contributors. This contributory trait needs to be reflected in the day to day attitude and work ethics of testers, be it in meetings, stand up calls, emails, defect reports etc. As much it is critical to highlight where an application fails, it is equally helpful to highlight what are the positive factors. Communication is imperative, and doing it the right way is even more crucial.
Bringing a few changes in the way test teams work can bring in a lot more appreciation and worthiness to their work. Give it a try and till then Happy Testing J
When a software product is a success – the developers get the glory and when it fails – the testers get the blame! That’s the unfair story of a test professional’s life. It’s kind of weird that even when from an end user perspective quality of the product matters the most, software quality professionals are so many times referred to as the “poorer cousins” of developers. I have been at the brunt of this discrimination from some of my “coding genius” friends as well colleagues, even if it was in the form of humor. But on a serious note this really is the mentality that exists across the industry.
A deeper analysis of this status quo clearly points to one factor for testers not getting their dues. It is the sense of negativity attached to the role itself. Agree or not, no one likes to be told about their mistakes and then being asked to fix those mistakes that too in a short interval of time. It is this basic philosophy that needs to change. We need to move away from “breaking the product” culture to “building a successful” product culture. I think test teams themselves have the biggest role to play to make things turn around. Associating a positive meaning to their work can help test teams being valued for their hard work and contribution in the success of a software project. The onus lies both with managers and team members. Some things that can change the way test teams are looked at and perceived are –
- Rise above numbers – While trying to explain this I am reminded of a funny incident. A few years back, one of the “finicky” managers that I was working with wanted me to collate the number of issues that were raised by each of the testers in the team and then publish this on the daily dashboard. With all due respect, it was his idea of developing a competitive streak amongst this group of graduate trainees we had in the test team. When I look back, the whole approach sounds pretty much flawed. By doing so we were moving away from the goal of delivering a successful project to being the reason for failure. As a lead/manager, it is necessary to condition your team not to look for defects just for the sake of numbers. Testers/Test Analysts should be smart enough to hit the areas of core importance and raise critical issues that hinder a project from going live on time. Raising 10 issues contributing to typos, content mistakes, look and feel won’t help as much as raising 5 functional defects that hold back a product from going live would. Working with this approach will reflect the test team as an enabler in delivering a project on time with optimum quality.
- Defect Free Product is a myth – It is important for test team to understand that a 100% defect free product delivery is far from reality. Testers need to align their work with this fact and should not hold back a sign off because of a few trivial open issues. They could always be passed as a caveat and be fixed at a later time. The decision has to be taken between the project and the customer teams; however quality team can help them to do so by providing an impact for such issues. So again this would make them a collaborator rather than an inhibiter.
- Help Projects make informed decisions – Test team can play critical role in go-no go calls. A summary of test cycle with clear and concise impact of open issues, defect fix rates, pass/failure rates etc can be strong basis for going forward with the release or not. In this manner the test team gets to play a more significant role rather than just pointing out the developers mistakes. This again puts quality guys in a better light.
- Early visibility of Test Teams in the SDLC – It is a proven fact that a great number of issues can be avoided if testers are involved early in the project life cycle. The cost to fix an issue that is caught during the requirement analysis is far less than when it is caught after the code implementation. Also, this helps in collaborative relationship building between the test and the development teams. It helps in bringing them at par in terms of what software is expected to do and thus, working towards a common goal.
- Moving towards Agile – A good way to implement a collaborative approach is moving towards agile. Agile gives the opportunity to every team member to be involved right from the beginning of a sprint. It offers the test team to be more versatile and has tasks assigned throughout the sprint and not just at the end of the development as opposed to waterfall. Testers in agile ensure that quality is built into the code right from the start. Their role is more than merely testing. Agile sort of integrates the team into one single unit working towards a common objective. Agile Development is in sync with “building a successful product together” philosophy.
There is no data to prove that testing is any less important than development for the delivery of high quality software. It is the negative mind-set that needs to be changed that surrounds testing. Traditionally, testers and developer have been pitched as each other’s rivals. Elimination of this rivalry is the first step for testing to get its fair share of acknowledgement. A product fails not only because testers let the bugs percolate into production but also because the code quality might have not been of a certain standard when it was first delivered for testing. Be it failure or success it has to be a shared responsibility by the team as a whole. Test Teams should not be obstacles to delivery, they should rather be contributors. This contributory trait needs to be reflected in the day to day attitude and work ethics of testers, be it in meetings, stand up calls, emails, defect reports etc. As much it is critical to highlight where an application fails, it is equally helpful to highlight what are the positive factors. Communication is imperative, and doing it the right way is even more crucial.
Bringing a few changes in the way test teams work can bring in a lot more appreciation and worthiness to their work. Give it a try and till then Happy Testing J
