Part 2 of our book review series for 'The 2 Minute Tester' and this time around I am sharing my feedback and thoughts on chapters 8 through 14. Some of these chapters were a cause of some good discussions (thank you fellow book club members!)
Chapter 8 - User Acceptance Testing (UAT): Test Techniques
- This chapter briefly defines UAT as ‘real users using the real system to run through real business processes’
Mentions: “..create UAT test cases..” And “…act as an enabler. You are enabling the business users to access the system” but then later in the key takeaways section mentions “be very clear in how you categorise any issues you find..”
- I’m confused - I have assumed based on the chapter that the end users do all the testing not us. This chapter implies that we just enable the UAT via setting up the system, providing logins etc. But then it specifically mentions we are the ones that found the issue and categorise, in the key takeaway.. Is this because the UAT team are reporting these directly to us? In my experience this hasn’t happened. They may report to us if they need help with certain aspects of their testing, but not for us to collate all their bugs, observations and enhancement requests. However, my experience with UAT is quite limited in this regard (reporting etc)
- The chapter also appears to contradict itself by defining UAT as having real users run through real business processes, but it’s the tester that is defining all of the business processes via test cases - in my experience end users always know their business processes and do not require test cases for those. Perhaps some high level charters will be shared with them, and then agreed - we can then help with the steps/scenarios
- The first page and half of the next is specifically for waterfall environments. Only a few lines mention how things might be different in an Agile environment - but could be applied to waterfall projects too so not to clear on the difference here other than having it included as part of definition of ‘done’ in a sprint.
- I agree with one of the main takeaways being 'act as an enabler/facilitator'
Chapter 9 - Test Team Leadership: Management
A chapter on leadership and what it requires.
Mentions: “Your role is to describe what good looks like, for example, ‘Defect-free release of system A in 8 weeks with 35 specific user flows fully functional and able to cope with 10,000 concurrent users’.”
- regarding this, if we never test it at all, technically it’s defect-free (because there'd be no defects raised)..Also 'defect-free' in my opinion is just not a measurement
- all of the above can be achieved by automation. Do we really need testers? Just automation engineers it seems
- that aside, I like that the example used for defining the description of good is specific, and avoids ambiguity (as this can be quite vague in teams at times)
Mentions: “In both agile and waterfall you need to resist the urge to micromanage..” but the example used when suggesting an alternative approach is quite patronising and sounds does very micro-managing-like “you have an awful lot of negative tests..”
- this also contradicts another one of the key takeaways listed “ask questions; don’t offer what you think the answer is immediately”. In the example above the author has already offered the answer of looking at commonality between the tests to reduce the number.
- I like that the chapter emphasises coaching and enabling over micro management.
Chapter 10 - Dealing with Management or ‘Wait, what do you guys do again?’
This chapter does a pretty good job of offering ways testers (not just managers) can demonstrate the value they bring to a team and a project.
- I like that one of the key takeaways specifically mentions ‘..demonstrate, and not with powerpoint..’
I also liked that the author reminds us that “this is a problem you need to own and resolve” - but I’m not sure on the 'resolve' part of that. It can happen that testers demonstrate their value, but are still not valued by their team or specific team members (in my experience)
There are some good examples of ways to collaborate like mentioning 3-amigos sessions etc. There was mention of using the ABC macro which is ambiguity checking in requirements but I found this could be used in refinement sessions too and also we could look for not only the presence of words like 'may', 'might', 'could' and 'should' but we should also be aware of the absence of them too.
For example an absence of the word ’should’ could imply that we have either mistakenly assumed something ‘will’ do something or we haven’t explained how something ’should’ work (what we expect to happen)
Chapter 11 - SWOT and How it Can Help Your QA Delivery: Test Techniques
This chapter summarises the SWOT approach which is a 2 by 2 table showing strengths, weaknesses, opportunities and threats.
Generally I like that this chapter emphasises on talking to members of your team to get the full picture. The example SWOT table shown in the chapter was limited to only a QA team, but I think it could apply well to cross-functional teams too with input from each role.
Chapter 12 - Becoming a Test Manager (1): Management
After the first paragraph I feel I somewhat start to know the author as opposed to previous chapters which were your typical tips. I’d like to see more of the authors experiences shared. This was a good touch to the chapter for me.
One of the key take aways listed is ‘Empathise, don’t tell.’ I enjoyed this short chapter. The author mentioned 3 references for working in management ‘communicate, set and see’. The small criticism I have is this is not really specific to management, and can apply in general for all levels of testers as we are often the bearers of bad news, it’s important we share this information in the correct way.
Chapter 13 - Becoming a Test Manager (2): Management
This chapter should have been before the previous one in my opinion because unlike the previous, it touches on making the move into management and what you can do to get there.
In general I like this chapter too, there are some practical bits of information I can take with me, some books referenced and I generally agree with all of the key takeaways from the chapter.
Chapter 14 - GDPR: Data
This chapter highlights the importance of the GDPR data legislation and how we can go about navigating this in our roles.
In my experience, companies usually have specific teams that handle this, and also generate some policies that employees have to abide by. Training is also provided but with that said, I’d have liked this chapter to have focussed more on the importance of data and anonymisation.
Data legislation and policies around this are very important for testers - so I am glad the topic of data has a dedicated chapter in this book. There are some good points raised around using production data in testing and how potential breaches lay in wait.
I did however disagree with one of the key takeaways which is simply “Do a data audit”. This could be something a tester could initiate or facilitate but doing the audit themselves - I’m not sure that is best/good practice as in my experience, as mentioned above it's always been a third party doing the auditing.
Leave your comment
Post a Comment