Test coach versus test specialist, impact on queues

I recently had a very interesting conversation with a group of skilled testers on whether or not there should always be a test specialist in a cross-functional team.

A lot of people say yes, my personal experience says not.

My personal experience tells me that the most effective and efficient approach uses a test coach that slowly makes himself scarce. My experience focuses on creating competencies for completing an activity (testing) in a collaborative context.

One aspect I am finding difficult to explain is the impact on queues of a test coach approach, I will use a series of Scenarios and pictures to facilitate my reasoning.

If you feel like substituting activity A = development and activity B = testing feel free, but this approach is activity agnostic in my experience as I have applied it to analysis, and development obtaining similar results.

Scenario 1 – Test specialist

In the presence of one specialist on Activity B and many specialists on activity A.
Problem: Long q
ueues form in Ready for Activity B (Case1) or worse specialist multitasks on many activities at the same time slowing down flow of work as per Little’s law (Case2)

Screen Shot 2017-05-29 at 10.40.47

Scenario 2 – Test coach

Stage 1: In the presence of one coach on Activity B and many specialists on activity A
Initially coach pairs on Activity B with people that do activity A. This way we obtain 2 benefits:

  1. Queue in “Waiting for Activity B” is reduced as one person normally performing activity A is busy pairing with coach on one activity B task
  2. By pairing on activity B feedback loops are shortened
  3. Person with activity A acquires new skills to perform activity B from pairing with coach
  4. Quality of activity B increases as it is a paired activity
  5. Flow improves because of 1 and 2

Screen Shot 2017-05-29 at 11.22.49

Stage 2: When cross-pollination of skills required for activity B starts to pay off, we have 2 benefits

  1. Normally some activity A person will show particular abilities with activity B, in this case this person can pair with another less skilled activity A person to perform activity B
  2. Queue in “Waiting for Activity B” is reduced as more people with activity A skills are performing activity B
  3. Flow of value improves lead time decreases
  4. More activity A people get skills on activity B

Screen Shot 2017-05-29 at 10.56.00

Stage 3: All activity A people are able to perform activity B
Activity B Coach can abandon the team to return only occasionally to check on progress. Benefits:

  1. Activity A and activity B can be performed by every member of the team
  2. the WIP limit can be changed to obtain maximum flow and eliminate the queue in Ready for Activity B.
  3. The flow of value is maximised
  4. The lead time is minimised

Screen Shot 2017-05-29 at 10.58.05

WARNING: I have applied this approach to help teams with testing for many years. It has worked in my context giving me massive improvements in throughput and reduction of lead time. This is not a recipe for every context, it might not work in your context, but before you say it won’t work, please run an experiment and see if it is possible.

This is not the only activity that a good test coach can help a team on, there are many shift left and shift right activities that will also reduce the dependency on activity B.

I have been told a million times “it will never work”, I never believed the people who told me and tried anyway, that’s why it worked.

Try for yourself, if it doesn’t work, you will have learned something anyway.

Testers, what business are you in?

businesscat

Recently I read an inspirational story from Jesse Lyn Stoner’s excellent blog  I would like to share with you.

The owner of a window shades company, was asked by a business consultant “What business are you in?” He initially answered “We are in the window shade business”. Then he was asked “When someone walks into your store, why do they want a window shade? What are you really selling?” he had to pause and think before he saw it

“We’re in the light-control and privacy business! – not the window shade business.”

The implications of this discovery were that by understanding the company real purpose, he was able to introduce new products that his customers loved.

You can find the full story (here)

Reading this story reminds me of the struggle of the testing community to get buy in from business owners. Years and years of hearing complaints that business owners don’t understand the importance of testing, they don’t appreciate the hard work of testers, I have grown tired of it.

I believe it’s not the business owners not to understand testers, I believe it is testers not understanding the business they are in.

The majority of the testers I know believe that they are either in

“The business of finding bugs”

or

“The business of sourcing information to help make decisions”

The testers I want to work with are in “the business of delighting their customers”, that is what we all need to be in.

If we make our business “delighting our customers” believe me, we will find a lot of innovative ways to do it as testers.

Forget about defects, forget about information, focus on delighting your customers and

  1. you will find innovative ideas to improve the quality of your product
  2. the business owners will love your work – and most of all
  3. you will have a lot of fun in the process!

 

 

 

Testers: what’s your strategy in a continuous delivery context?

smallbatchIn my last stint as a tester from October 2012 to Jan 2014, I helped my organisation at that time moving from delivering once every month, to delivering multiple times a day.

Let me first clarify that we didn’t move to multiple deliveries per day just for the fun of it, but because we needed it.

 

Your organisation might not yet know it needs this level of agility but more than likely it will at some stage in the future.

How did this transform the role of the testers within the organisation?

Massively

The start

When I joined I found scrum teams that delivered either once a month or once every 2 months. The teams had 3 different defects management databases full with old and new defects. Testers were doing the following activities:

  1. automation (~30-50%)
  2. exploratory testing (~50-70&)

The batches were big, the exploratory sessions were long and found a lot of defects. The automation was not effective, as it was slow and unpredictable, its value was negative.

When I left

When I left, we were using kanban, delivering multiple times a day, defects were more or less a myth of the past, no defect management tool existed. Testers were doing the following activities:

  1. Three amigos BDD sessions with customers and developers
  2. Exploratory testing (1~5%) – never longer than 10 minutes per card, more often than not reporting no defects
  3. Pairing with developers
  4. Coaching developers on testing
  5. Writing automation (0%)
  6. Talking to the customer and the team
  7. Improving the system
  8. Designing the product with the team and the customer
  9. Helping define what to monitor in production
  10. Any other valuable activity the team needed them to do

As you can see the activities that before occupied 100% of testers time, now occupy from 1 to 5% of testers time.

Were testers busy before? Yes, absolutely

Were testers busy after? Yes, absolutely

Were testers complaining because they weren’t doing automation or enough exploratory testing? No, believe me. Most testers I worked with saw the new activities in the role as a learning activity and an opportunity to broaden their skills and become more valuable to any company.

If a tester didn’t want to adapt to the new reality and embrace the change and new ways of doing things, he would have been busy for 10 minutes  a day (~2%) and he would have not been useful to the team.

Did we get there with the touch of a magic wand? No, the end stage was the result of many experiments. It was, back then, a good recipe for that context at that time (it is continuously changing)

So, tester, what’s your strategy for working in a company that releases multiple times a day?

 

What tester are you? /s

Let’s see what kind of tester you are, answer the 3 questions below and find you profile description at the bottom.

You start testing and the product has obvious problems even with the “happy path”, both cosmetic and very obvious bugs are everywhere, what do you do?

  1. I send the product build back and don’t touch it because it is not testable and back to facebook for the day!
  2. I log 124 bugs in extreme detail, one for every problem I encounter. If somebody after 3 days asks me why I am not finished yet, I respond that I am logging bugs and testing is not complete.
  3. I go talk to the developer that made the last check in and ask him why he didn’t test his product. If he says, “because you are supposed to do that” I talk to him about the incredible amount of waste he is creating by delaying the feedback on the product and not testing it himself. I sit down with him, ask him to test the product and fix the issues we find together in a continuous loop until we both are quite happy with the result.
    I then explain to him that if the feedback for each of the issues has to come from a different party (me) the delays in the detect fix retest rate will create a massive amount of waste. I encourage him to test his application before sending it to me and as we are at it I suggest the next time we test it and fix it together.
  4. I tweet to the world how idiotic my developers are and include screenshots of the errors. I spend 2 hours defending my point on social media and catching my interlocutors on inappropriate use of terms to prove my point.

You have been sitting idle on your chair for over an hour because there is a delay in the build you want to test, what do you do?

  1. Yippee I have time to browse the web and watch some videos on youtube! I hope their problem persists for a while, the new Game of Thrones season is awesome!
  2. I look at my test plan, change it a bit, add some graphics, get a coffee and start reading that testing book I always wanted to read.
  3. I have been out of my desk already for 50 minutes. 10 minutes idle time is waste, our customers are getting our product later than they should.They say there is a problem with the build, let me see if I can help out. I go and offer my help to my teams’ developers. They might need me to rebuild a machine to check something or to try something quickly to debug the problem. I get stuck into it, wow, I even learn something about it! I might even resolve the problem altogether using my strong critical thinking skills and looking at the problem from a different perspective. I help, we solve the problem and, yes, now I can test it! Chances are that while troubleshooting the problem I have already gathered a lot of information on the product that will support and supplement my testing.
  4. If developers are idiots there is nothing I can do, I will spend this time blogging about how to become a better tester and how testing is the most important thin g in the universe, much more complex than development by the way.

Developers have nothing to do because the analyst has been sick and there are no refined user stories in the backlog, you just finished testing, what do you do?

  1. BINGO! I might as well re-start House of Cards
  2. I start complaining and moaning about how this company sucks and about how better it would be if I was the decision maker here. We need to hire more analysts and testers of course! I then go back to writing more test cases even if there is nothing to test. I might also create some fancy SQL query to extract lovely bug lists to show to management with graphs and all.
  3. Great opportunity for learning a bit more about how business analysis works. In the previous weeks I have been helping the analyst and I think I can get the job done. I organise a meeting with the team and we start breaking down user stories, as soon as we have a couple ready we can start working. I will replenish the backlog until the flow is reestablished, using WIP limits will help me understand how much work I need to do on this.
  4. There is nothing to do, if development activities are foreign to me, imagine how I feel about doing something that is even further away from my testing world. I am here to find bugs and provide information to stakeholders, not write user stories, hire more analysts if you don’t want this to happen.

RESULTS

If most of your answers are 1, you are a slacker that happened to be doing testing. Why don’t you find a job you enjoy doing instead of trying to avoid the one you have?

If most of your answers are 2, you are an old time tester that spent the last 15 years in a bubble far away from the evolving world. Nothing outside your little testing world is worth consideration, after all you know better than anybody else and why should you improve?

If most of your answers are 3, keep on doing what you’re doing, you and your company will be OK

If most of your answers are 4, I know who you are 🙂

 

 

 

Testers Prevent Problems, every day

500_euro_banknoten

Earlier Today, I read an article from the notorious tester Michael Bolton titled “Testers don’t prevent problems“. I would like to use an example to counter this assertion end expand the conversation.

Disclosure – I am a firm believer in prevention over detection in product/software delivery.

The Fact– In today’s news, we read that the ECB will be stopping the print of the 500 euro banknote because of its association with money laundering and terror financing.

(Source: The Guardian)

The Problem: According to the article, producing 500 euro bills was an error. It is a bug in the product “Euro currency bills and coins denomination”. In fact such bug has caused quite a lot of problems to our society according to what reported in the article.

Larry the tester – Let’s imagine that Larry, a tester, happened to be in the room where people where deciding the denominations of the euro notes. Let’s imagine he said “Hang on lads, this could be a problem as it would be easy to conceal large sums of money and smuggle them. Banknotes this valuable might help illicit traffic, should we stop at 200 or maybe even at 100?”

Let’s assume there were smart people in the room that decided to take the objection into consideration, made research to prove its validity and as a consequence decided not to print the 500 euro notes.

The Question – Could we say that Larry had helped prevent the problem?

I say yes, how about you?

If I want to be treated like a professional I should act like one

Drunk-Surgeon-801916Developers and testers often complain that they are not recognised as real professional experts, I wonder why.
One category of respected professional experts is for example heart surgeons.

Now let’s imagine I go talk to heart surgeon Mike and go

<me> I need heart surgery
<Mike> Sure we will schedule it
<me> No no no, I need it now because I have a dinner appointment tonight
<Mike> OK, that’s fine we’ll do it quickly, I won’t even wash my hands

Would you trust Mike as a real professional expert? I wouldn’t

Now let’s think about a common scenario where Product owner Jeff comes to me (developer) and says

<Jeff> I need the new payment feature
<me> Sure we will schedule it
<Jeff> No no no, I need it by tomorrow, we need to comply with regulation
<me> OK that’s fine, I’ll hack it together for you and I won’t even write tests

How can i expect to be treated like a professional?

Thanks for the idea to Marcello Duarte (@_md)

 

Mind maps as a testing tool bug me a lot

I use Mindmup.com for my mindmaps
I use Mindmup.com for my mindmaps

There is one thing that bugs me about mind maps as a testing tool, it really bugs me a lot.

Don’t get me wrong, I find mind maps a great collaboration tool to get ideas out of people’s heads and put them on paper. They are great for designing a test plan, a few testers can sit down, brainstorm and create a map that can be efficiently used as a complete plan.

So what bothers me so much?

This: “Why don’t we do the same exercise together with the developers before the code is written?”

Are we so obsessed with finding bugs that we cannot share our thought process and help PREVENT (yes prevent) the defects instead of catching developers out and wasting customer’s money and time?

I really hope that somebody out there will give me a valid reason why we shouldn’t shift left the mind map creation and prevent the defects instead of detecting them.

Otherwise we should start doing it now, no excuses.