The final part of our book review for 'The 2 Minute Tester" - I'm sure you haven't been as excited for a finale since Breaking Bad! ...right? ... tough crowd..😝
Similar to the three previous review posts, I will briefly summarise the chapters and share my thoughts on each one separately. For a summary of my entire review, you can shortcut and just scroll right to the end of this post.
Chapter 22 - Management: Problem-Solving in QA Management - The Three Ps in QA
This chapter introduces the ‘PPT’ approach to problem solving (is it People, Processes or Tools at the cause of the problem?)
Generally I find this approach to identifying root causes of problems a good starting point. The author admits that there are of course other things that can cause problems with project delivery that fall beyond the 3 mentioned above but it would be a good shortcut for getting started.
In my opinion I feel this could be a good approach to projects in general - not just when there are problems that arise. We should always be assessing our progress and performance not just addressing these things after the problem occurs.
Chapter 23 - Continuous Improvement (Kaizen)
This chapter briefly summarises the Kaizen philosophy, which is a philosophy of making small steps that can eventually accumulate and lead to big improvements.
Overall a good chapter with what I think is a great philosophy for change. Again, I feel this can be applied throughout life in general with whatever one wishes to pursue.
Chapter 24 - Risk Mitigation: Stop it Going Wrong Before it Does
This chapter focusses on how one can address potential risks and resolve them before they become real problems for us.
I noticed that the ‘PPT’ problem-solving method from the earlier chapter is referenced, but this time the ’T’ stands for ‘Technology’ as opposed to ‘Tools’ - are these interchangeable? That’s debatable I guess.
The key takeaways of this chapter tell us to ‘1. Risk assess your people, 2. Risk assess your processes, 3. Risk assess your technologies’
I’m not sure these needed to be 3 separate takeaways. The author could have just had one takeaway, “risk assess you people, processes and technologies”.
That aside though, I’m not too sure how I feel about risk assessing ‘people’. For example, in the example the author uses in the chapter, we are told that a contractor was the most senior Automation Engineer on the QAT team but has been talking about leaving for another contract. We could have risk assessed the skills required on the team instead of assessing the person.
To further add, let’s say you required a Senior Automation Engineer on your project, if the best option for hiring was a contractor, then this risk should have been assessed at that stage instead of hiring and leaving the issue to become more important later - this would be truly stopping it going wrong before it does (as the chapter title reads)
Chapter 25 - Defects Adding to The Product Backlog and The Risk to Your Project
This chapter addresses how to handle projects that have a large backlog of bugs/defects building up.
We are told about the complexities that present themselves to the Product Manager when trying to arrange work from the project backlog, juggling between bug fixes and building new features.
In my experience, on agile projects if a defect is found during work on a ticket that is to be delivered in a sprint or by a specific date, then that ticket itself is not moved forward until the defect is fixed within the same pull request/ticket and therefore affects delivery of the project/feature in its entirety so is not added as a separate ticket and put on the backlog.
Alternatively, if or when there are defects found outside of the feature/epic being worked on, then those are the defects that tend to get added to the backlog because they are deemed beyond scope of the current work. In such a case, if we have bugs building up, we’d have to start thinking about making our case to the Product Owner in relation to getting some of the bugs addressed - as also suggested in this chapter.
During this chapter, I found there was emphasis put on ‘defect count’. To me, the count of defects on a backlog doesn’t really tell us much. The defects there may not have been assessed or refined to determine whether they are even valid bugs yet.
One of the key takeaways of this chapter mentions “look at root causes, any clustering?” - in my experience, the majority of bugs do not contain their root cause so I am not sure how beneficial this could be. As Testers we must be detailed and clear in our bug reporting. We can suggest possible causes which could be very helpful to the Engineer, but the Engineer in most cases would be better suited to identify a root cause, as they would have more technical understanding of the code and how it all works together. Though I do agree, when observing the defect count we should look for any clustering of tickets to help us group them and better manage the workload.
Chapter 26 - Keeping it All On Track: Daily, Weekly and Monthly Tasks
This chapter basically gives us an example of a task list, containing daily, weekly and monthly tasks.
This was quite a disappointing chapter for me because five pages used up on an example of a task list, made up of vague examples of different tasks. Eg, ‘deep dive into automation’
Chapter 27 - Tracking QA Project Progress (Waterfall)
We are advised in this chapter, to specifically monitor the schedule, costs and defect rate when tracking progress on a project.
These can be applied to any project in my opinion but the author chooses to specifically mention 'the QA Project'. I am left wondering what exactly a QA Project is? Is it something that only the QAs are doing, as part of their own team? For example, having the team look at different options for some tooling that would help them? Or does the author refer to the testing phase of a software project, the ‘QA project?’ - this isn’t clear to me in the chapter.
A negative for me in this chapter is we are told to monitor the defect ‘expected vs actual’ number. I would have liked to understand the author’s angle here a bit more. To me, it leaves me with questions like how does one decide their ‘expected’ amount of defects on a given project? One of our book club attendees suggested this could perhaps be a measurement against previous projects/features, but we all felt that to monitor this, isn't a great idea.
Additionally, this chapter has advises us to create data points when monitoring and make them colour coded. Then we are shown some examples on how this could look. Unfortunately, it doesn’t help us much because the book is printed in black and white.
One of the key takeaways is just ‘use colours’ - I had to go back and re-read the chapter to remind myself why the author has 'use colours' as a key takeaway. It would have been nice to have summarised that key takeaway with some more details. Something like 'use colours when creating data points'
Lastly, the final key takeaway is “Look at trends with defects over the week…” this key takeaway and the chapter implies, that if there is a high defect count, this is a bad thing. For me, a high defect count could be a sign of good progress and that our testers are actually finding bugs before other people do.
Chapter 28 - Stand-Ups: The Power of Introverts
This chapter briefly summarises what daily stand ups are and how they should be used.
When I finished reading this chapter, I wondered why ‘the power of introverts’ was mentioned in the title. There’s no mention of introverts, or dealing with such people, experiencing a standup as an introvert, how stand ups can help introverts. So to me, it was pointless mentioning 'the power of introverts' in the title.
Scattered throughout this book are quotes, at the beginning of chapters that I feel are totally misplaced. This chapter is one of those that starts with a misplaced quote.
“Not all those who are silent do not want to talk.” - Debasish Mridha
Does this chapter even mention anything about how to help others be more vocal, or in any way relate to the quote above?...you guessed it, NO.
The author suggests we take the chairs away during stand ups and make people stand. This could be a little harsh perhaps, especially nowadays where many are working from home since COVID. Not sure I agree with making everyone stand. Worth noting also that this book was published during COVID so the author would have been aware that offices were closed. Are we expected to stand up even from home?
Other than the negatives above, the chapter does a decent job of giving us some tips to improve our daily stand ups - but I'm still not sure how this is related to making me a better QAT professional as the title of the book claims?
Chapter 29 - Effective Communication
Generally in this chapter we are advised to communicate in person where possible instead of via emails and other chat applications. The problem I found was that despite that, the chapter focuses more on ways to communicate via emails and apps. It doesn’t give us a method of how to effectively communicate.
This is demonstrated in the 3 key takeaways at the end of the chapter: “1.explore alternatives to email for effective communication, 2. Schedule regular catchups, 3. Think of the rule of 5 and the rule of 3 when emailing”
2 of the 3 key takeaways are about emailing..
Additionally, none of the above takeaways have told us anything about how to communicate effectively.
What if we already do the above 3 in our daily work but still struggle with communicating effectively? Such a scenario is possible in my opinion.
Chapter 30 - Finance: Budgets and QA
In this chapter it is implied that managing budgets isn’t exciting "but like flossing and eating veggies, you gotta do it".. that quote is from this chapter and hurt me just to type it. Apologies.
'People' in this chapter are referred to as 'resources', something I’m not a fan of personally. We are also told about tools that can help when budgeting your QA project - as opposed to what kind of things to budget for.
Essentially this chapter is lost on me, because I am not told why a QA needs to budget for a project.
In my testing career, even as a Test Lead I never had to budget a project myself. When I needed to hire, I’d give some context as to why we need to hire, what role we need to hire for and what the market rate is. I'd then get hiring once management above agreed it was something we could do.
This chapter seems to be more relevant for a QA Manager, so like other chapters perhaps it should have made mention of this in the title.
We are also told to factor in overtime costs when budgeting. Personally, I’m not a fan of people being made to work overtime - but being told to factor this in, feels like we are already accepting that it will definitely happen.
One of the key takeaways of this chapter is: “Get involved early and use Excel” - Why Excel? Since we are talking about budgeting, how about a free alternative? Humour aside, I think the author should have mentioned something general like "use spreadsheets to help with budgeting"
Chapter 31 - Productivity: The Power of Next Action Steps - Keeping Momentum
This chapter suggests some tips that can potentially help us manage our tasks throughout the day, in busy environments where there are constant interruptions that can disturb our momentum.
The tips are summarised as, having no more than 5 items on your action list at any one time and time-blocking each action.
I find myself agreeing with time-blocking actions to help us keep focused on one thing. however the author suggests that when deciding what five actions to work on, we are advised to not care too much about the priority order of the actions, which is also one of the chapter’s key takeaways.
I’m not sure I agree with this, when drafting out ones actions for the day, arranging them according to the priority seems like something we would naturally do. We shouldn’t bother ourselves with other tasks if we have someone or something waiting on one of the tasks we have to complete. The author does however say that this is not a technique that should restrict us so is open to that adjustment.
I like the last paragraph making the distinction between being busy and productive - "The aim is to maintain momentum and not lose focus on what needs to get done as opposed to what actually gets done. This is part of the difference between being busy and being productive"
Chapter 32 - Management: Delegation
The chapter suggests tips on how a manager can delegate tasks to their team in a more effective manner.
This chapter felt a little contradictory to me because there’s mention of “spend time with your QA professional..” as opposed to just delegating tasks to them without setting out the context and goals - but then advises to set expectation boundaries - is this the manager’s expectations? If so, that doesn’t sound like a nice experience for the QA in my opinion because it seems like the manager here is only spending time with the QA so that they can dictate some expectation boundaries.
We are then advised to work up a list with them and set our YOUR thoughts for tactical and strategic success. What about listening to the QA’s thoughts?
It then mentions “…You are empowering your people and giving them clear information on what success looks like.” - this to me sounds like another contradiction.
Giving people information on what success looks like, without first hearing their feedback or ideas is not empowering them.
The end of the chapter mentions “you are delegating but not leaving people exposed and unsure of what they need to do” - the language used here implies that all of the tasks have been dictated to the QA.
Chapter 33 - Management: The Feedback Loop 3 To 1 Rule
This chapter advises how to give feedback in a more positive way.
Again, at the beginning of this chapter we find another misplaced quote: “In a growth mindset, challenges are exciting rather than threatening. So rather than thinking, oh, I’m going to reveal my weaknesses, you say, wow, here’s a chance to grow.”
Yet, we are told nothing in this chapter about how revealing our weaknesses can help us grow. There isn't really anything mentioned about growth - it is assumed that growth comes via the way the feedback is given.
The chapter just mentions that when giving feedback, do not focus mainly on negatives. These negatives may not be weaknesses though - there could be some external factors causing a delay on the project, lack of clarity from business team, conflicts in the team causing problems etc. Though are negatives, these are not weaknesses, they are just factors causing a negative impact on the project.
I do however like that there is a focus in this chapter on positive reinforcement and how beneficial it can be. Too often in QA we focus on negatives - since we are always curious about what things could possibly go wrong, where problems are - sometimes we look at all things in such a way.
Overall, some really good points about focussing on the positives over the negatives when managing a team and some good key takeaways for this chapter.
My Summary of The Book:
The chapter above causes me to reflect on my feedback sections for each chapter. Perhaps I was reading and focussing too much on the negatives?
Overall this book has some decent advice for those starting out as Testers/QA Engineers, but personally I didn’t take too much benefit from it. A lot of the book did not reflect the industry as a whole and seemed to be focussed on a particular method of QA - having QAs completely separate from the engineering/development team.
This book would be a good read for a junior QA and will give them a broad range of the different aspects of the testing role.
2/5 stars from me.
