This is a common topic for everybody that works on a software product or on a software project. Every product has a testing team (although the reporting structure of the team can vary from products where the testing team works as an independent team, or the team can report into the overall manager of the project), but the focus of the post is on a specific phrase called 'everybody tests'. The testing team is the last and probably the only major element in the entire project (leaving aside the processes such as design reviews and unit testing) that controls the quality of the product, and everybody should have a stake in their success. However, this is easier said than done. Many a times when there is some kind of struggle regarding the amount of time available for a product, the thought has gone towards the amount of time dedicated to testing, and whether can be some kind of compromise.
I would like to showcase my experience. I am not on the testing team, but have a good idea of the kind of effort it takes, as well as the amount of time it takes to reach a phase where the testing has come to a completion and a large percentage of the defects have been removed. However, this is one of the biggest problems - there is no such thing as 100% testing, and it can become extremely critical for people to understand that. One of the best ways of doing that is to experience the testing environment and also go through some of the pains involved with the entire testing process.
So, I had the designation of something called a Product Specialist, and my job was to determine the business requirements and provide those in the form of requirements to the development team, work with the team to ensure that those got done and interact with users for training and other purposes. There was a level of understanding of the product that was adequate for my work, but if you asked me, there were levels of complexity in all the workflows that I did not possess. Further, there was always a level of impatience regarding the time-frame it took the development team to get the work coded, and a higher level of impatience regarding the time it took for testing.
However, at a certain phase, we all were way behind in our schedule, and all the non-testing team members were asked to do integration and acceptance testing (we were not qualified to do the system testing part). This was the first time I was doing testing, and the process of ensuring that data was available, of looking at the test cases and selecting the ones for a greater detail of testing, and then the entire process of testing, all these gave an entirely new perspective to the process of testing for me. I had the same feeling as a testing team would get when somebody from the development team would query and deny a defect I found or treat it as a low level of defect that did not really need a fix, and so on. Overall, this experience lasted 2 weeks, and provided me a perspective into the testing process that I never had earlier. An additional benefit was about getting a much higher level of learing of the various workflows in the areas that I was testing. As a result, as I moved into positions of project management, I would always have discussions about ensuring that everybody in the team was asked to do some level of testing, even if they were very busy.
Even if a developer was doing testing, it provided them an invaluable experience of seeing how the feature workflows behaved, and how sometimes even small things can get critical to users if it serves to hinder their workflows in some way. And this is only one of the advantages of having a developer or another role in the team doing the testing.
I would like to showcase my experience. I am not on the testing team, but have a good idea of the kind of effort it takes, as well as the amount of time it takes to reach a phase where the testing has come to a completion and a large percentage of the defects have been removed. However, this is one of the biggest problems - there is no such thing as 100% testing, and it can become extremely critical for people to understand that. One of the best ways of doing that is to experience the testing environment and also go through some of the pains involved with the entire testing process.
So, I had the designation of something called a Product Specialist, and my job was to determine the business requirements and provide those in the form of requirements to the development team, work with the team to ensure that those got done and interact with users for training and other purposes. There was a level of understanding of the product that was adequate for my work, but if you asked me, there were levels of complexity in all the workflows that I did not possess. Further, there was always a level of impatience regarding the time-frame it took the development team to get the work coded, and a higher level of impatience regarding the time it took for testing.
However, at a certain phase, we all were way behind in our schedule, and all the non-testing team members were asked to do integration and acceptance testing (we were not qualified to do the system testing part). This was the first time I was doing testing, and the process of ensuring that data was available, of looking at the test cases and selecting the ones for a greater detail of testing, and then the entire process of testing, all these gave an entirely new perspective to the process of testing for me. I had the same feeling as a testing team would get when somebody from the development team would query and deny a defect I found or treat it as a low level of defect that did not really need a fix, and so on. Overall, this experience lasted 2 weeks, and provided me a perspective into the testing process that I never had earlier. An additional benefit was about getting a much higher level of learing of the various workflows in the areas that I was testing. As a result, as I moved into positions of project management, I would always have discussions about ensuring that everybody in the team was asked to do some level of testing, even if they were very busy.
Even if a developer was doing testing, it provided them an invaluable experience of seeing how the feature workflows behaved, and how sometimes even small things can get critical to users if it serves to hinder their workflows in some way. And this is only one of the advantages of having a developer or another role in the team doing the testing.
No comments:
Post a Comment