This little cutie illustrates another trap, so that means you have another common problem coming up. Prepare for rhyme time:
“For a tester it might feel we are never done
One risk mitigated, we think of another one
Beware if you feel you could keep going forever
Time unfortunately isn´t endless, prioritize and be clever”
So, what does it mean?
Historically, when describing a good tester I would guess you would hear/say they are:
- Detail oriented
- … but also keeping track of the bigger picture
- Do not mind repeating things over and over again
- Champion of the user
- Thinking outside of the box
- Critical thinking
- Advocating for quality
But. While those still hold true, in order to function in a rapid development cycle, we also need to be good at:
- Time management
- Letting go.
Ok, so first we teach people that they finally have somewhere where that control-freakiness is perfect. We tell them that there is a place where being pedantic is a great asset.
Then we tell them they can’t have the time needed to make things perfect.
So, just to be clear:
We take a bunch of people who really want things do be of high quality, who could probably polish stuff for ever if needed. And we tell them to choose.
It’s a bit of a miracle that people don’t go completely mad!
Really, this is probably my biggest flaw. I hate having to live with “good enough”. I mean, I did an entire talk ranting about how bad software kills people!
But that is just reality and even grumpy old cats like me need to realize it and adapt. Even with “unlimited time”, we could always find something else to test.
So, learning to prioritize and manage time is an amazing skill. Learning how to take a step back and… Let it go.
So. I am a control freak. There, I said it.
My example today will maybe feel less testing related than most but.. it´s my blog and I can do whatever I want 🙂
One of my first assignments in testing was a big (for us), very traditional waterfall project. We used use cases to describe the user scenarios, we had a team of specialists doing that, internal experts from the business and external requirement experts. We had a team of testers, some full-time from the IT side (like me) and some part- or full-time from the business side. And of course we had developers, project managers and all the other roles needed for a traditional project.
I had taken a bunch of courses to prepare. Read so many books. I was SO ready for this!
One thing that I was extra enthusiastic about, and still think is incredibly important, was to get the requirements right. So, I made sure that we schedules reviews for the different use cases. They were large(-ish). Well, maybe not compared to traditional x100-page documents but still, say 20-30 pages at least. We booked about an hour per use case.
So, to make sure everyone is on board, the use cases I am talking about describes an… hm… let’s call it an action that the user would take in the system. Including all “normal flows” and all “alternative flows”. So, this could be something like (Making these up so as to not tell which system it was) “Login”, “Update personal information”, “Withdraw money”, “Deposit money”, “Apply for a personal loan”.
Ok, so in the first review I sat down with my mentor, our business expert and our requirement expert. Everyone was happy, talking about how long it had taken to get them done, how nice it was to “finally get started for real”. Nice. Friendly.
I pulled out my 2 A4 paper filled with questions, suggestions, comments, remarks, clarifications. And started firing away. ANYTHING that could be misunderstood (sometimes almost only by drinking a bottle of wine first, standing on one leg and not speaking the language properly) was scrutinised. It took us forever to get through all of the use cases, all of the revisions, all of the tiny tiny details I wanted done.
Of course, the requirements turned out really good and we understood them really well but MAN, we could have had them ready for the developers so much faster. Oh, by the way. Did anyone notice the absence of developers in those reviews? I sure didn’t at the time. I do now!
Ok, well. Time passed and finally I was satisfied with the documents. Then I went about writing the test cases…. (No, to be honest I had done that already because I wanted to prepare. This meant I had to update them all after every review…)
I think I wrote something like…. 500 or 1000 test cases for those use cases. And I could have kept going until the end of time if they would have let me.
Then I was annoyed that requirements were not updated to match changes we had done after either talking to users or after our reviews. And nagging about it did not help so frustrated I took the passive aggressive path and…. any guesses?
Yes. I reported every. single. discrepancy. Every one. There were hundreds.
And they all had to go through our Change Control Board.
I get tired just writing about this.
Moral of this story: I got too engaged, too committed and I wanted everything too perfect. I could have spend a quarter of that time building relationships with people and figuring out
1. How to motivate them
2 What was really important to internal and external users.
Quote of the day
“Let it go, let it goElsa. Frozen.
Can’t hold it back anymore
Let it go, let it go
Turn away and slam the door”
Visualize how changes flow to production – Lisa Crispin and Ashley Hunsberger
Risk based testing: Strategies for prioritizing against a deadline – Hans Schaefer, Logigear
Risk based testing – Guru99
Impact and probability in Risk Assssment – Karlotta Thorhallsdóttir, Denmark Technical University
Gamify your testing to lower risk and increase value – Lisa Crispin and Lena Wiberg
What to do then there isn´t enough time to test? – Software testing help