Yesterday I read a fantastic post by Marlena Compton called Seven Ways to Make Testing Irrelevant on Your Team. On her blog Marlena references a great companion article by Scott Barber called Scott Barber's Top 10 Things About Testing That Should Die. Both of these are great articles and I must say "Nice Bike" to both of them.
I did want to make a few comments on Marlena's article. First the term, irrelevant, struck a harsh tone with me. Lets start with a definition via Webster online.
irrelevant - not important or relating to what is being discussed right now.
I was like "Wow" can the actions of testers really make Testing Irrelevant? After reading Marlena's article I would say "Yes we can"! It is very sad but true. It is so truthful that I must admit "I AM GUILTY".
One of the things I love is to inspect process and suggest changes that could result in improvement. I would never intentionally force process on anyone. Our government or management does enough of that already. I adhor process for the sake of process. But I can reflect and see that in my career there have been times when my suggestions could have been perceived as being forced upon a team. Testers please be honest with yourselves. Have you every stated it is my way or the highway. So I concur with Marlena forced process could give testing a black eye.
Lock horns with teams on whether or not to release. I agree again with Marlena. Again I am guilty of doing this in my career, but there have been times when I have really had to fight hard to prevent my company from making a huge mistake. Delaying a release for a short period of time is a viable answer. Unfortunately I have seen companies so set on hitting a date, that they cannot see the forest through the trees. So depending on the context my recommendation in this situation is to get all stakeholders to sign off on the decision process to release despite the testing evidence or advice. Sounds bureaucratic, but the reason I suggest it is that these stakeholders should conduct a retrospective post release and during that retrospective collaborate on ways that release could have been better.
Third point of the article is with respect to complaining about a decision after the fact. Honestly I did this the other day. Crap, I am so guilty! Did I complain to anyone that mattered? No, but I complained none the less. So my solution here is to also coordinate a retrospective with the key stakeholders. Why did we make that decision and what could we have done better. I will do my best to stop complaining. Thanks Marlena for the reminder.
Geez! At this point I am feeling sad, because Marlena called me out with her top three points. Need I continue? The guilt is killing ME!
"Insist that everything be perfect when you look at it". Finally something on the list that I do not do today. Oh wait! Yes I have done this in the past. Dang guilty again! The reason I do not do this much today is that I know how hard rapid software development is. If I can jump in extremely early on a new feature and close collaborate with developers, then I do not have to document defects. I ask lots of questions and we fix things before a bug report even has to be generated. The thing with this is that you have to work close with developers to prove to them that your skills are not irrelevant. Sometimes developers do like another pair of eyes and thoughts. Testers should collaborate early, often, and politely!
Dang it! Marlena caught me again. Point number five regarding spread the attitude that developers are untrustworthy to test their own code. It is not that developers are untrustworthy, but in the rapid software world sometimes great developers do not stop to smell the coffee. Again I would never intentionally state that developers are untrustworthy, but I would say that great testers can add a tremendous amount of value. My comment to Marlena is that there are many developers that think testers are untrustworthy too. Honest Injun! I have stated in my past that developers do not know how to test. Given time constraints in rapid software development I now MUST trust developers to test and I trust that they are doing the best that they can!
Man! Can I survive two more bullets of this article?
Assume developers don't care about testing and testers. This is a neutral one for me because in my heart of hearts I believe everyone is striving to put out quality code. I have never been told on a development project that my skills were not needed. I have heard developers state "we do not need testers". Since the Agile Manifesto 10 years ago I have heard this off and on. Heck! Kent Beck practically stated this at STPCon Fall 2010 in his key note. So my position on this one is NOT guilty! My main assumption is that the team can always get better at testing. Testing is relevant and it does not matter who does the testing.
Final bullet point from Marlena is tell people that developers are biased toward their code so they cannot test it. I guess I am slightly guilty again. At a previous company I believed this, but today not so much. A great man in Austin Texas, Neal Kocurek, once taught me a course at Radian Corporation on Leadership. In that course he taught me a new word, scotoma. He taught that a scotoma is a blind spot. As leaders (no matter how great), we have blind spots. I would contend that developers can sometimes be blinded. This most likely is never intentional, but a reality.
So Marlena I must thank you for making me conduct this self inspection. The judge and jury rule that I have been GUILTY in the past of doing the things that you say make testing irrelevant. I now want to move forward and cultivate that collaborative relationship you describe. I am sentenced to a life of continuous improvement. Kaizen!
I do believe today that collaboration is king. And I will do my absolute best to not make testing irrelevant! By writing this blog I have some done some testing, testing of oneself. Thanks Marlena and Scott for the inspiration and blunt bullet points.
Testing is definitely NOT irrelevant nor should testers act in ways to make the act of testing irrelevant.
Testers - have you been guilty?
No comments:
Post a Comment