The 2 Minute Tester by David Bruce is a blend of soft and hard skills, advice and tips spread throughout 33 chapters. The review for this book will be split in a series of posts, as and when the specific chapters are covered in our book club. The questions and comments I have on each chapter are cause for some great discussions and my comments are not always correct. In fact, I was reading back through, and it seems in the beginning of the comment I appear to be unsure of a thing, but then later convince myself that I actually agree. Take my review as you will - and I certainly hope it doesn't discourage you from reading.
Introduction pages:
At the beginning, in the “Who this book is for” section, it mentions:
“..where assurance is key..” And “…assurance requires a deep understanding of techniques…”
- I disagree that assurance is solely the tester’s responsibility, despite the common title of “quality assurance engineer”
Chapter 1 - Exploratory Testing
This chapter generally summarises exploratory testing and the benefits of using the approach
mentions:
“you don’t have much time..”
And “exploratory testing is a useful technique when there isn’t much time available, you need the system tested quickly”
- At first I didn’t think the time issue was relevant to exploratory testing, but upon reflection if I didn’t know a system and someone wanted their product shipped asap, I’d first ask - why am I testing this now? at the point where I have not much time and more importantly, why do I not know the system? (if working on a project)
Questions aside, if you want to get something tested quickly and you do not know the system/application of how it works - exploratory is the natural approach to take. So agree here.
- I found it interesting that point 3, mentions “pre-investigation” and speaking with the team, under the chapter of exploratory testing. This is often overlooked.
Mentions:
“is it often most effective either at the beginning or end of a specific test phase..” And “…if operating in an agile manner, at the end of each sprint”
- I’m not sure I agree with this. Why would exploratory testing be most effective at the end of a sprint or test phase? Exploratory testing is about learning, ideally we’d want to carry this out as soon as the product is ready to test (and also via discussions before it is built)
Chapter 2 - Effective Team Working in QAT
This chapter is a brief summary of how to effectively work as a QA team.
Mentions:
“effective team working” and “..what makes an effective QAT team?..”
- Seems to imply the QA team are separate from the rest of the dev/engineering team. Personally I believe when you make QA a separate team, this is quite ineffective. I prefer the Agile approach where you have cross functional teams (QA, dev, product owner etc all in one team together collaborating)
Mentions:
“stop thinking of devs as people whose work you are trying to find fault with and start with the view that you are helping them deliver the best solution possible”
- how about both? I am aiming to find problems in the work - and help them deliver the best solution possible. Just be kind and compassionate as you should be - don’t treat people bad, period.
Chapter 3 - The Tester Mindset: 80/20
This chapter explains that 80% of our efforts should be focussed on edge cases and 20% of our efforts on "happy paths"
Mentions:
“As your suite of tests increase (if you are testing in an iterative, agile manner) more and more of your negative tests should be automated”
- 1. Why is this restricted to agile? Waterfall projects also have test suites build up over time, from which you can automate the negative tests
- 2. I don’t have experience of working with test suites on agile projects, but we did trial X-ray and the test case approach didn’t work for us
Chapter 4 - Risk-based Testing: Test Techniques
This chapter briefly explains what risk-based testing is, how and when it is used and the benefits of the technique.
- The author tells us that risk-based testing is when “…you need to test the most-important, or riskiest parts of the solution”
- Personally I’m not sure where I stand in relation to assuming here that ‘most-important’ and ‘riskiest’ are the same thing. On a pension application for example, the most important thing could be simply seeing what the current valuations of their savings are, a value feeding through to the front end - but most riskiest could be performance. What happens when hundreds of thousands of customers do this at the beginning of the month, after they’ve been paid by their employers and they login to see the state of their pension?
I incline to believe they are the same, because important can be the riskiest, depending on who you are referring to - your customer? Or your in-house architecture team?
- I like the 3 parts mentioned for defining most-important, or riskiest:
- key functionalities
- Likelihood of failure
- Impact of failure
- I also like that we are reminded a lot of the information above can be found through discussions with subject matter experts. I’d have liked to have seen this mentioned as a key takeaway at the end of the chapter
- In the section for “Impact of failure” I liked the example used for purchasing something as a gift on an online store and hiding the price of the gift for the receiver
- One of the key takeaways from this chapter that are mentioned is “focus on key functionality, less so on edge cases.” Usually in projects, a lot of the key functionality is usually automated and monitored. But even if they are not, I believe when looking at the most-important parts of a system, spending a good amount of time thinking and exploring edge cases is required, and in fact often naturally performed by the tester due to the importance/risk of the part being tested
Chapter 5 - Static Testing: Test Techniques
This chapter appears to assume that static testing is performed on requirements documents.
- We are told that great benefit of this technique is that it is done very early in the development cycle, but then in the next paragraph tells us in relation to tools to use for this technique, “In terms of tools it is hard to beat the human eye for static testing.” The author seems to assume Testers cannot get involved even earlier, before any documentation is drafted throughout this chapter.
- I have found working with Product Owners that present their ideas/intentions for building something before drafting documents up as gospel, to be of great benefit.
- Again the bulk of this chapter is advising us how to perform static testing on documents using search functionalities however I liked that the author suggests we look out for terms such as should, may, could, possibly - the author reduces this to searching for these in documents, but we should always take note when such terms are used in discussions around the product in general too.
- I’m left pondering on whether I need to go back to my “ISTQB Foundations” material, to verify whether static testing, is only to be done on documentation? (As the chapter suggests)
Chapter 6 - Building Your Own Avengers Team: Recruitment
This chapter is a brief summary of how to build a diverse team.
- First immediate thought was, is the author testing us Marvel fans by telling us Thanos is part of Avengers “team”?! Using an example to demonstrate the strength of diversity, the author writes: “..it’s hard to think of a more diverse team than Black Widow, Thanos and Thor, for example”
- On how to build a great diverse team, the author mentions: “You hire different from yourself…if they look like you, then you don’t have a diverse team.” That could be true, but in Agile environments there is typically no separate QA team. So if you look around, and everyone doesn’t look like you, but they have the same role and perform the same job as you - is that diversity? In my opinion, the cross-functional team approach is a great example of diversity - you have many diverse opinions on one subject all viewing it from the lens of their role in the team. This can strengthen our testing, and help us consider more variables when testing too.
- It seems the author isn’t sure if by diverse he means the way people look, or diverse in relation to skillsets and approaches. The author mentions how he had an interviewed someone wearing a flowery Hawaiian shirt, shorts and sandals - but ended up being hired, based on his passion and background working in startups.. no mention of skillset or presenting a diverse opinion or approach here.
- In my humble opinion, a diverse team is more about the shared ideas, approaches and opinions and consideration for others when sharing those. For example, we could hire an automation engineer that believes all the testers are beneath them because they are doing the work of monkeys manually tapping and clicking away. So here, we have some diversity in opinions/skills and approach, but does that now mean we have a great team?
Chapter 7 - Specification by Example, or True Living Documentation: Test Techniques
This chapter refers to a test technique called 'specification by example' but doesn't do a great job of explaining what it is. The lack clarity here though is my problem and I'll be reading up on this matter.
- Admittedly I don’t know much about Gojko Adjic or his concept of SBE - and that’s a good thing because now I will go and read up and learn more (one of the key takeaways listed at the end of the chapter too)
- UPDATE: after reading up about it, I initially thought this was the gherkin/BDD approach to things (which is how I interpreted it from the book) - but there does seem to be a subtle difference. Still slightly confused. With that said though I’m all for removing ambiguities and having some clear (as possible) requirements.
- The chapter is a little confusing to me, but that’s my problem
- One of the other key takeaways at the end of the chapter mentions: “Remember it isn’t just QA, it covers development, business analysis and project management as well” - but in my experience this is the same for your typical set of requirements also. We all interpret the document in our own way, and frequently revisit (sometimes with customers) to ensure we are on the right track. Not sure why this is mentioned as if it is specific to the ‘specification by example’ approach
To be continued...
