Sunday, January 26, 2014

“Bull Shit” – Great testers do exist and they are important to the rapid delivery of excellent software!

Title uses the shout out straight from the “Cotton-eyed Joe”.  I do live in Texas.  

I am going to explore a common thread found in these two articles discovered via Twitter.  The common thread is we must deliver software fast.

First I am going to offer an opinion on this article that Michael Bolton commented about on Twitter -

Second I am going to share a couple of opinions on leveraging Kanban effectively. In my opinion delivering software fast you do not necessarily impact creativity but you embrace creativity.  This interview was discovered in a tweet by Smartbear Software linking to this interview -

I must admit Mr. Stanton’s article got me riled.  First of all it seemed to imply that Google does not have testers, which is absolutely false.  In fact Google has some amazing testers.  If you get a chance to speak with Ankit Mehta at Google and you will learn that integrated testers help keep the quality high on the more critical Google applications.  You will also learn that it is the community of testers that shows the developers how to test and implement automation effectively.  In my opinion they are well trained ninjas.

James Whitaker one of the author’s of the book “How Google Tests Software” seems extremely developer centric in some of his writings and presentations.  I have to admit the book is still in my queue to read, but having listened to Mr. Whitaker speak I think he would admit there are some great testers around and that testing is critical.

I would agree with one aspect about Mr. Stanton’s post and that is many developers do not know how to test nor do they think they should test.  Great testers can be important educators for teams like this, if the team is willing to learn, listen and continuously collaborate.  It truly does require a culture shift that includes great testers in the paradigm.

I will try to summarize my rebuttal with some key bullet points:
  •       Whether Scrum or Kanban try to remove the QA handoff by involving a great tester all along the way.
  •       Great testers can critique design, offer strategic planning, conduct code reviews, extend unit tests, and even help write code, especially automation.
  • ·     Great testers can assemble the release and deploy the product.  Once deployed they know how to quickly sniff out risk and locate critical defects the team may have been missed. 

Embed a great tester and treat the tester as a first class citizen, then you will see some amazing results.

I do like this statement “Design a workflow that requires developers to wipe their own behinds, by writing automated tests for and testing their own code.”  A story should not be complete until a reasonable amount of test automation is in place.  When a critical defect is found by a customer, the developer should prepare to apply some Desitin cream to their behinds by increasing the test coverage and manually experiencing the final product for excellence.

Speaking of delivering excellence, I think that is what David Hussman is about.  David Hussman provided an excellent keynote at "Keep Austin Agile" conference in 2013. 

The interviewer in the link above implies that because we have a desire to deliver software fast that we skimp on creativity.  My opinion is if you skimp on creativity and innovation you may not be creating an excellent product.  Side bar – I do love Mr. Hussman’s use of music to describe building great software.

The interviewer also seems to imply that using Kanban there is no room for creativity.  Again I have to disagree.  Kanban is all about the flow of delivering value.  A story can sit on that board for a period of time as long as other value is being delivered or until the value of that story is truly recognized.  Teams today can easily deliver pieces of functionality in the “dark”, providing time for the team to be creative as they develop.  It is the sum of all the parts that creates excellent software.

Kent Beck predicted that delivering software would get faster in is keynote at the 2009 STP Conference.  Software is being delivered fast today, but delivering excellent software that delights customers is the key.  I think we must permit creativity.  In fact I have seen teams have daisy changed Kanban boards where the first board outlines the creative process of design and experimentation.  From my experience developers and testers are extremely creative and nimble in their creativity.  Perhaps we can call it "Rapid Creativity".

Kent Beck was right and so is Jeremy Stanton in that we must adapt and change the way we test software in today’s rapid paced world.

Building a team that can deliver great software fast is a great challenge.  Building a great process integrating testing through out is not easy.  But I think an important part of that team should be a great tester.  Great testers do exist!

Sunday, January 19, 2014

Looking in a Mirror

I initially was going to add a post about checking versus testing.  I started to reread some of the posts starting in 2009 to the present.  I quickly concluded that the topic truly is not controversial at all.  In general I concluded that both are important if you do care to make a distinction.

So I decided to walk through recent blog posts and I came a across a gem from Peter Walen.  I have meet Mr. Walen at I believe two conferences and I always learn something, so enjoy his post.  Where his post struck a nerve with me is the idea of self reflection or introspection.

I believe people tend to blame others before they look in the mirror.  I recommend that everyone do some introspection before they seek external cause.  So I would like to point anyone who happens upon this blog to check out "The Leadership Gift".  Christopher Avery educates communities on the "Responsibility Tree".  You can see the tree on the right hand side of the link.  I think very few people are able to work up the ladder to the final rung to take responsibility for their own actions.

When I read Peter's post I can relate.  The hiring process is hard.  Letting go of control is hard.  Trust is hard.  Achieving success hard.  So in combining the post on personality traits and the responsibility tree, I think you should be looking in the mirror at oneself first in order to continuously improve.  Introspection will allow you to grow and perhaps help others.

Sunday, January 12, 2014

To Many Bugs

I was a bit disappointed that I never saw a response to my questions on the Atlassian blog posts in order to gain a bit more context.  However I do realize the comment ping pong can go on and on.

I read quite a few blog posts this week, but nothing really got me really thinking.  I did come across a tweet that was interesting by Michael Kelly.  He tweeted "There is nothing more depressing to me then logging bug after bug after bug. Feels like a waste, but it's clearly needed. Sad."

I recently experienced a situation where we had to stop testing for a similar reason.  Two many defects were being found in one specific section of a website. It was not the highest risk section so we felt the value of the testing although important was not the best use of the time available.

Mike's tweet made me wonder about when is it appropriate to stop testing if there are too many defects. If this occurred in a single session, I might recommend the team spend another iteration before the next test session is scheduled.  Another angle is that I might call a test dojo where the team is all in a room testing together.  Perhaps we can find and fix as we go.  Developers typically take a lot of pride in their work, so they will be responsive to rapidly fixing things or openly admit they need more time or assistance.

I believe I also read a tweet from Lisa Crispin that illustrated a paired story deliver approach.  I like the approach but the paradigm may not always work.  In the case of finding two bugs it might be a great time for a tester to offer to pair.

To many bugs from my point of view is most likely hurried work.  I guess it could be due to poor design, lack of functional detail, or something else that was poorly communicated.  Regardless of the cause I would recommend that testers find the most professional and collaborative way to adjust the situation.

I agree with Michael that it can be a huge time sink having to document a large volume of bugs.  Personally I would rather see them get fixed than create an object in some system that now needs to be managed to resolution.

I guess find the bug nest early and get creative on a rapid solution.

Happy Testing!

Saturday, January 04, 2014

Quality Assistance

Recently there were a couple of blog posts by Atlassian testers.  The first article I read was called “Inside Atlassian - Introducing  Atlassian QA” , which was developed by Andrew Prentice.  The second article was titled “The Jira QA Process”, which was written by Penny Wyatt.

Both are well-crafted articles and I believe they did the job of causing me to think.

First I would like to explore a statement was made by Andrew.  He said, “To be fair, a large number of people claiming to be professional testers can’t test either.”  I cannot say I disagree with the statement, but I ponder how do you determine if someone can test or not.  I would suggest that it is through demonstration of skill and others having the trust in that skill.

In Penny’s article she explains, “During this process, a QA engineer has multiple points at which he or she provides input into the way the story is developed and tested – providing every form of quality improvement except actually testing the story themselves.”  This thought seems to slightly contradict Andrew’s position by stating their testers do not even test.  I agree with her premise that they are involved in the entire process injecting quality into every story.  Where I disagree is the testers not actually testing.   I certainly may be missing something, but I have found that through the active act of testing a vast amount of knowledge is gained.  Typically great testing leads to more great testing.  Perhaps Penny was only referencing testing at the story level.

I agree that everyone should own quality.  I agree that experienced testers should assist in the education of others.  I do not like the term Quality Assurance.  But I think great testers should always test.

I am leaning toward using the term Quality Engineering, but I know that will be controversial so I had better prepare.