News

I just read an excellent article from James Whittaker on testing at Google and I just loved his point about the T-shirts that state “I test therefore I am”. The premise is that people should not be too hung up on roles, more focused on products. I come across this so much working in the Agile testing space. I find so much resistance to developers doing testing. Not unit testing….”just testing”…such as executing a scenario test.

However, even more importantly, I find so much resistance from testers to get actively involved in the other aspects of the software development or maintenance lifecycles. I really struggle with this as most of my testing career has been advocating early testing involvement in the lifecycle and now with Agile I can get involved right from the beginning. I think this is brilliant! But when I talk to testers about this I get the responses such as “oh no, I’m not equipped to do that”. AARRRGGGGH!!!!

What is the role of the tester in a project? Is it just to test stuff, to execute tests, to write test cases? What about the Developer? Just to develop code? Nope – not any more (actually not ever)! The role of any team member is to contribute to the quality of the deliverable in any way they can! How can we all contribute to the quality of the product? We can work together to plan the approach, making sure that all the aspects of quality have been discussed and considered and either incorporated into the approach or discarded with team agreement.

It is really important that all team members understand the proposed solution, the risks and the quality aspects of the solution, the timelines and the work that needs to be fitted into the time line. Otherwise how else can we work together with each other? Maybe this focus on roles explains the common issues and disconnects that we experience in the testing space.

Testers, in my opinion, do not need to know how to write code, but they do need to understand the code technology being used to consider the various risks associated with them. Testers do not need to write the requirements, but they do need to know how to identify risks in the requirements gathering approaches and techniques. Testers do not need to be the project manager, but they do need to work with the PM to define the most appropriate project timelines and milestones to deliver the required solutions. What do you think?