Ready to Ship discussion

The 2 Minute Tester: 33 Routines to make you a better tester

My book finally arrived. After a quick glimpse through, I think I can complete 7 chapters per week because they are small, often no longer than 2 pages. What do you think?

Yeah, sounds good.

I'm going to comment each chapter separately here, I think. They all are about different stuff and I'm afraid to forget my thoughts.

I noted all my comments on each chapter, was thinking of dumping them here..or use it as an excuse to post on my blog lool

you can do both :D

1. Exploratory testing
Author says it's good when you need to test fast and you don't know the system. But It can be good with any amount of knowledge when you want to actually save time and don't spend it on all unnecessary test documentation.
2. Effective team. Working in QAT
In one sentence - be a good team player.
3. The tester mindset: 80/20
80% of efforts to the unhappy path - makes sense. And automate - of course.

For now - nothing new.

I’ll post on the blog once we discuss maybe I’m being overly picky and you refute me.. I’ll post my initial comments here below

Notes on 2 minute Tester book:

“Who this book is for” section, 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:

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 don’t I know the system? 

Questions aside, if you want to get something tested quickly whilst not knowing the system - 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:

Mentions:

“effective team working” and “..what makes an effective QAT team?..”

- Seems to imply the QA team are separate from the rest of the 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:


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: 



- 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


- 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


- 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


- 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

Chapter 8 -

4. Risk-based testing: test techniques
So do we define key functionality by how big the impact of the failure will be? Or do we difine the area of biggest failure by key functionality?
Why people always talk about prioritising test cases? Not features for testing or areas or components?
5. Static testing: test techniques
Shift-left!
"In terms of tools it's hard to beat the human eye for static testing" - AI, not today.
It's good tip about ambiguoug words.
6. Building your own avengers team 1: recruitment
Actually it was pretty fun in the first MCU phase with only Hulks, Iron men and Thors.
And actually Black Widow, Thor and Thanos are from the same phase as well. They were together in the movies. You should make analogies with areas you really know about :D.
I don't like the idea of the separate QA team.
Yeah, go and find yourself a perfect team where everybody has neccessary skill set for the job, but also has diffeent set as well and in general are very talented and care about product. Easy peasy.
We are talking about how people dress? For real?
7. Specification by example or true living documentation: test techniques
Should we add Gojko's book to "want to read"?

Added Gojko's book(s) to "want to read" :)

so far..

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. We just enable 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.

- Agreed on 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.. defect-free is just not a realistic goal
- 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

Mentions:


“In both agile and waterfall you need to resist the urge to micromanage..” but the example used for an alternative approach is quite patronising and sounds 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 2, 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.

8. UAT
I always had an impression that people who do UAT should be different people, people form product side.
And again we are talking about writing test cases!
And we have to cover all user roles not only in UAT, but in the ususal testing.
Btw I forgot how to call not UAT but usual testing 🤪.
9. Test team leadership: management
What is with this book's habit to use ":" in the chater titles??
Individual approach - yes, agree.
Encourage people to find their own solutions - agree too.
10. Dealing with management
"They don't get what you do in QAT" - thats' so true. A lot of people think that we test AC, write test cases and execute them.
I don't unserdtand how showing some specific tool to management will show them what QA do. It will show them what the tool does.
You can't get management to all meetings you want, They are kinda busy people.
To show them how QA runs macros looking for ambiguos words? How is it supposed to help QAs? They will just see another tool which can be used by any role.
11. Swot and how it can help your QA delivery
this swot model looks like retro board. Which is where all this points should be discussed and with the whole team.
But it seems like a good tool to evaluate your QA role in the team.
12. Becoming a test manager
I'm not going to type anything that goes after ":" in the chapter titles.
Everybosy was annoyed? At least smb had to support you, because if you are the only voice in the dark that means that you are worng, or in anti-utopia or in the fantasy novel.
This chapter feels like "Phoenix project" in summary.
All kinda true, but it's basic soft skills. If person becomes a lead or manager not knowing this stuff, how did they get the role?
Really: don't tell people that they did a bad job! What a great advice 🙄🙄.
13. Becoming a test manager
Book for adding - "The four-hour Workweek".
But I like to be busy with different things, not only with things that move me forward.
Another book - "High output Management".
Chapter seems useless.
14. GDPR
Why is this chapter here? we pass these trainings several times a year

Looking forward to our next discussion 🤣😭😅

15 Running a defect board/triage meeting
2/3 times a week just for one meet about bugs??
Agree - keeping notes about all the things that were agreed on during the meeting is important.
Agree - if the issue is too difficult to understand and takes a lot of time it should be discussed separately. And it is valid for any meeting, not only bug DRB.
And before each meeting QA should spend time to review all these bugs?? when to work? Maybe rules for defect tickets has to be set and followed from the begining. And If on the DRB meet you see a bug that lacks info, then you just return it to the person or team who created it.

16. Machine learning in testing
"At time of writing, there are no open-source AI/machine learning tools available..."
Ups, there are now. No point in checking the tools meantioned in the chapter.

17. Soft skills
Yes, great tech skills will not help you If you're rude and can't work with people.
"Comfort zone" - we already know that this term is created by corporations management to get more value from their employees. A lot of people doesn't have a comfort zone in the first place.
What should be said - is that people should try new stuff and deal with problems and challenges which will help them to grow.

18. Writing a great bug report
I hate when on interviews i'm asked about my best or favorite bug. I don't remember bugs! I will remember a bug only If I missed it, and it caused great problems on production.
Nothing new in this cahpter. Good for beginners.

19. Processes to improve QA processes
(double processes in the title)
Smth to check - Checklilst Manifesto by Atul Gawande.
Checklists for tasks - I do it, but not everyday. I don't like the idea of doing lists every day and following them all the time, not for my character, I'll go crazy.

20. Joining it up and looking for the breaks
Test integration - not only separate parts. That's true.

21. Company culture
Agree - it's very important and difficult to influence.
Again it reminds the Phoenix project.
We again are judging people's clothes??
Team rejected him because he didn't fit into the culture. Does anybody tried to explain the culture to him?
Agree - it's important to understand how people communicate.
But you also can make suggestions on how to improve the culture. Sometimes people would be glad for smth to change, but they are just used to work in some particular way. Doesn't mean that they can't adopt smth new.

"We again are judging people's clothes??" - I knew this one was coming! my exact thoughts Anastasiya

I always thought that it's great that people are becoming more relaxed about appearance. But seems like for some there is still a direct link between how people look and how people work.

Chapter 15 - Running a Defect Board/Triage Meeting

This chapter summarises defect review boards (DRBs) and how they are used.

Mentions:

“…are used in both agile and waterfall projects.”

- In my experience as a tester, I have only used a defect board in waterfall projects after a test phase. In agile projects, I haven’t used a defect-specific board as a mid and senior level tester. I think in agile projects, this is something more likely to be done by a product owner or management to track open bugs and get them prioritised. The process I am familiar with in agile projects is, when a bug is found, report it and notify the product owner so that they can prioritise the fix vs their other deadlines/projects. We can of course advise on impact when reporting the bug too but the reviewing of the defects etc isn’t something I have experienced in the testing role throughout agile projects - but this book is aimed at testers.

- The key takeaways from this chapter are “rules for running an effective defect board…” many of which I agree with but one of them is “don’t have your DRB over 4 hours long”, for me even 1 hour in one of these things seem like a drag.

- I cannot say I am in favour of this approach, and prefer the agile approach I mentioned above. For this reason, some of the key takeaways/rules do not work for me, for example “Own them: make sure defects are assigned, either to the dev team or even better an individual.” I prefer to have the product owner prioritise the work. The defect should be reported well enough that any dev that has capacity can work on it, rather than dictating who should fix it.



Chapter 16 - Machine Learning in Testing: The Cyborgs are Coming…Trends

This chapter briefly describes what machine learning can be used for however, I would have liked to have read a general summary/introduction as to what machine learning is. Perhaps the author has assumed the reader already knows what this is, as he refers to it as “one of the buzzwords in testing”

- The bulk of the chapter is about 2 specific tools (Appliance and Functionize). It’s good in a sense that I have never heard of these tools nor have I used them but as mentioned above I’d like to have a brief introduction to what it is. Too much focus is put on the tools and it spills over into the key takeaways too (2 of the 3 being the websites for the tools)

- I agree with the author in that AI and machine learning are the buzzwords at the moment, and there are differences of opinion emerging in relation to how reliable it can be as a tool for testers.



Chapter 17 - Soft Skills

This chapter introduces the reader to some soft skills and briefly explains how they can help one improve as a tester. Though I do feel these transfer over into any role or aspect of life in my opinion.

The author writes:

“You can be the best tester in the world but if you can’t communicate in a clear and effective manner, you are not going to progress in the world.”

- I’m not sure how I feel about this statement. It seems like a contradiction - you cannot be a good tester, let alone the best in the world if you can’t communicate, period. Secondly, the author only lists clear and effective as being the measurement for progressing. In my experience, people can be clear with you but still rude. I don’t believe it’s such a black and white, clear subject.

- I like that the author emphasises the importance of soft skills and how they can enable one to work effectively and more importantly harmoniously



Chapter 18 - Writing a Great Bug Report: Test Techniques

This chapter as you’d expect, provides tips on how to write a bug report.

- I agree that a tester must be able to write a good bug report. In my opinion, a bug report can range in length and detail, similar to what the author mentions also “A great bug report can be one paragraph.”

- I also agree with the 3 of the numerous principles listed for a good bug report; 1. Keep it neutral in tone, 2. Define the defect clearly and 3. Clear steps to reproduce the issue

- I like the principle “Don’t lead the witness’. I have never heard this term, but agreed that we should only suspect or suggest solutions and underlying causes when drafting bug reports.

- I would have liked to have seen something around communication listed. I’m not a fan of creating bugs and dropping them over to devs without you having at least spoke to them and confirmed it together. I feel it can be a bit cold, when devs just received tickets assigned to them without first ensuring you are on the right track. Of course, this doesn’t always happen but in my ideal working environment, it would.

Chapter 19 - Processes to Improve QA Processes


This chapter briefly mentions some processes that can help other processes, such as strategic approaches vs tactical approaches.

- The chapter also starts with, what I feel is an out-of-place Aristotle quote:

“We are what we repeatedly do. Excellence then is not an act, but a habit” 

- I can see how this applies to life and gaining new skills, but not work processes. In my opinion, habits can be a hindrance when working (ways of working that no longer help us but are still habits)

- The author references a book titled ‘Checklist Manifesto’ by Arul Gawande. I haven’t read this and will now be checking it out in the hope that it will help me manage my productivity.

- Moving on through the chapter, there is mention of the direction of QAT moving towards automation and DevOps - and the checklist manifesto is referenced in relation to how it can help us achieve this. Are we to accept and not challenge this direction? I would have liked to read the Author’s thoughts on this

- There is also reference to the failures in the aircraft industry during the 1940s and 50s to demonstrate the impact of using checklists. I have seen a few times now, that the tech world use the factories/auto mobile industries a lot when bringing in processes. Safety checklists for pilots are very different to checklists for daily/testing tasks in my book. The cause for the checklists being used by pilots has a specific reasoning and context behind it, and it seems that because they saw improvements in pilot safety, someone decided this will mean improvement in getting tasks completed. As mentioned, it seems that way to me, but could not be the case.

- Time-boxing each checklist item, as suggested in this chapter seems like an interesting approach and is not something I have tried.

Chapter 20 - Joining it Up and Looking for The Breaks: Integration

This chapter briefly discusses integration testing i.e testing to see how everything comes together.

- Again, in this chapter we are referencing back to the 1950s and rockets exploding. We are told that after a deep dive investigation they found the root cause of the events were because all of the components were tested individually and not altogether in the final build. I’d have to look into this. I don’t see how this information benefits the reader in relation to this topic at all. Again, a completely different time, reason and context for testing the way they did.

- The chapter mentions:

“Just like massive engineering projects, in software development and QA, we don’t have to wait until all pieces are integrated before we test them” 

For me this statement has a few problems. Firstly, we’ve just read before this about how dangerous it can be when approaching things that way, but then we are told in this paragraph about the benefit of testing all things individually ie, the same way. Also, there’s clear separation between software development and QA in the quote above, but QA is part of and embedded into software development.

- I feel it’s always a good thing to try to remember how your piece of work you are testing, fits and works when it interacts with other parts of a system or application

Chapter 21 - Company Culture: Or Avoiding Rejection

This chapter seems to advise us on how to identify a good company culture.

- The chapter opens with what I feel, another misplaced quote:

“Company cultures are like country cultures, Never try to change one. Try, instead, to work with what you’ve got.” - Peter Drucker

- As a working professional I totally disagree with this. If a company’s culture is toxic for you, then you shouldn’t “work with what you’ve got” - sorry Peter.

- I like that assessing company culture has been given a chapter dedicated to the importance of it. Company culture can make or break someone in a role, in my experience.

- Again, as mentioned in a previous chapter, we are made to think the way someone dresses is in someway important at all

“One example I had was a QA engineer who was technically brilliant but dressed like he was going to the beach..” - why is the way he was dressed mentioned at all?.. The Author should at least tell us why he thinks this was a negative thing worthy of mention.

- It is also mentioned that this QA did not fit their tightly-controlled, agile way of working and should have adapted the way he worked and communicated in order to fit within it. Again, I strongly disagree with this approach. No one should adapt to fit into a culture that they feel is not good for them.

22. Management: problem solving bla bla
PPT - interesting model. Simple, but true.
Founf here smth very good: "Are we trying to automate everything even though there is a core of tests that would be better off doing manually?".
--
23. KAIZEN (Hello, Brad!)
It's a good advise - no need to try and jump very high every day. You can do small improvements regularly and it will make a difference.
Good chapter in general.
--
24. Risk mitigation
Yes, It's good to thinks about risks beforehand.
--
25. Defects adding to the product backlog...
Don't have anything to day about this chapter.
--
26. Keeping it all on track
Just examples of meetings. Dunno what to tell about it also.
--
27. Tracking QA project progress watrefall
This guide is too sprecific. Not some general recommendations but some particular way to do things. I'm not sure I like such approach.
--
28. Stand-ups
Yeah, completely agree! Stand ups have to be quick and consise. All big discussions to the outside, please!
About standing - yes, we all stood when were in the offices. But this book is published in 2021 when everyone was working at home already. Author thought that everybody will trturn to the offices after years of working remotely?
--
29. Effective communication
Whaaaaat. Emails instaed of messangers?????? It was 2021! what emails?
Author has some weird view on communication channels.
This chapter was a bit confusing.
--
30. finance
Why QAs would be managing a budget?
In key takeways it is said to use Excel. WHy not some other tool?
--
31. productivity
5 action steps - interesting techniqe for keeping focus on work. But it's just one of the many.
--
32. Management delegation
In general: delegate wisely, communicate clearly.
--
33. management: the feedback loop
Good advice - to give a good feedback along with bad.

So far (3 more chapters to come but my brain is fried reading this book)

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 but it would be a good shortcut. 

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. Basically changing for the good.

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 an 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 tell us to ‘risk assess your people, risk assess your processes, 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, mentions 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 themselves. 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 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 backlog, choosing between fixing bugs and building new features. In my experience, on agile projects if a defect is found during work on a ticket, that ticket itself is not moved forward until the defect is fixed and therefore affects delivery of the project/feature in its entirety. Alternatively, there are defects found outside of the feature/epic being worked on and those are the ones 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 for getting some of the bugs addressed - as also suggested in this chapter.

I found there was some emphasis put on ‘defect count’ - to me, if these are on the backlog, the count doesn’t really tell me much. They haven’t been assessed or refined to determine whether they are even valid bugs yet.

One of the key takeaways mentions “look at root causes, any clustering?” - in my experience, majority of bugs do not contain their root cause so I am not sure how beneficial this could be. 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, as 5 pages are full with an example of made-up tasks, many of which contained hardly any detail. Eg, ‘deep dive into automation’


Chapter 27 - Tracking QA Project Progress (Waterfall)

This chapter mentions some things to monitor in order to track a projects progress (those being schedule, costs and defect rate)

Monitoring schedule, seems to be a given if one wants to track progress of a project. I also wondered 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 around 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.

Again, a negative for me is we are told to monitor the defect ‘expected vs actual’ number. I’d like to hear and understand the Author’s angle here a bit more. To me, it leaves me with questions that I’d like addressed - for example, how do you decide your ‘expected’ amount of defects on a given project?

Additionally, this chapter has some markers/data points that should be ‘colour coded’ - and these are referenced. 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 remind re-read the page or so before to remember why the author mentioned colours. It would have been nice to have summarised that key takeaway with some more details.

Lastly, the final key takeaway is “Look at trends with defects over the week…” this as well as the chapter implies, that if there is a high defect count, this is a bad thing. For me, it’s a sign of good progress, our testers are actually finding bugs before other people do.


Chapter 28 - Stand-Ups: The Power of Introverts


As one would assume, this chapter briefly summarises what daily stand ups are, and how they should be used.

Upon completion of this chapter, I wondered why ‘the power of introverts’ was mentioned in the title. There’s no mention of this, or dealing with such people, experiencing a standup as an introvert, how it can help introverts..So to me, it was pointless mentioning introverts in the title.

Yet again, we have another misplaced quote at the beginning of the chapter: “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 and make people stand up during the stand up..A bit harsh perhaps, especially nowadays where many are working from home. Not sure I agree with that.

Other than the negatives above, the chapter does a decent job of giving us some tips to improve our standups - but 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 vs emails and software and to communicate effectively but focuses more on ways that one could do that. It doesn’t give us a precise method of how to effectively communicate. This is demonstrated in the 3 key takeaways at the end of the chapter:

- “explore alternatives to email for effective communication”
- “Schedule regular catchups”
- “Think of the rule of 5 and the rule of 3 when emailing”

None of the above have told us anything about how to communicate effectively. What if we already do the above 3 throughout our day 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 from this chapter hurt just to type it. Apologies. 



People in this chapter are referred to as resources, something I’m not a fan of. We are also told about tools to help budget your QA project. 



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 Lead I never had to budget a project myself. When I needed to hire, I’d give some information about why, the role requirements and the going salary and started recruiting once management above agreed it was something we could do. I can see this chapter being more relevant to a QA Manager or QA Lead. 



We are also told to factor in overtime costs when budgeting. Again, I’m not a fan of people working overtime - this feels like we are already accepting that it will happen. 



One of the key takeaways is: “Get involved early and use Excel” .. Why Excel?

Chapter 31 - Productivity: The Power of Next Action Steps - Keeping Momentum

This chapter suggests a technique that can potentially help us in managing our tasks throughout the day when there are constant interruptions that can disturb our momentum.

The technique the author advises is 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 to not care to 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, at least when drafting out ones 5 actions for the day, priority must have some say in what order we perform each task. We shouldn’t bother ourselves with admin work 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. 

Mentions:
“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 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..” Over 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 nice experience for the QA to me. 

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 all 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 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 feedback can help us grow and revealing our weaknesses, at least to me. It just mentions to not spend most of the feedback focussed on negatives. These negatives may not be weaknesses though - could be some external factors causing a delay on the project, lack of clarity from business team etc. 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.


Summary:


The chapter above brings me to reflection of my chapter reviews. Perhaps I was reading focussing too much on the negatives? Overall I fee this book has some decent advice for those starting out as Testers or QA Engineers, but personally I didn’t take too much benefit from this book. A lot of it didn’t 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.

2/5 stars from me.