We're almost done with our book review series for 'The 2 Minute Tester'! We discussed maybe completing the book throughout the next batch of reading, as opposed to reading only another 7 chapters and then part 5 being just covering the remaining 5 chapters. As the chapters are short and concise, this may just be possible. Look out for part 4 coming next week!
The chapters we discussed this week were a cause for more questions than discussions. Most of which we have mentioned below.
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
- When framing this quote within a work environment, I totally disagree with this. I believe that if a company’s culture is toxic for you, then you should not “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
Mentions:
“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.
And with that, we end part 3 of our book review. Don't hesitate to share your thoughts with us!
Until next time!
Leave your comment
Post a Comment