Ready to Ship discussion

Would Heu-risk it?: Tools, traps and weapons for Software Testing

Preface. About me:
I like the joyking names for different types of testers. It's fun, I've met some of them))

Part 1 Traps

Pairing/Mentoring
I suppose that kind of stuff is more convinient to do offline. Though it's definetely good practic.

Self Reflection/Retrospective
Also a good practic. The one that I'm aware of but always forget to do.

Mischievous Misconceptions
I didn't understand the verse in the begining.
I suppose the meaning of this chapter in these: Don't suppose that smth is not possible just because it always seemd so. There's a lot of things we don't know about everything. Things can change and you may not know about it untill it's a problem. Keep the mind open but not too open.
The verse in the end I understood.

The Temptress' Trails
Negative tests find more bugs - that's kinda obvious for me. I'm surprised that the author was surprised.
But I suppose we more concentrated on the happy path because the most users don't go far off this path. And because If happy path doesn't work there is no point in further testing.
Example is a bit silly. Because concentrating on the happy path and not doing negative tests at all - that's different things.
And also I'm not sure If I really spent 30% of time on negative. Because there's always much more negative tests than positive.

The Glutton
Tester need to be good at "Letting go" - good quality for nay role.
Example: omg, It's great that the author understands that they behaviour was not okay. That's a good personal grows.
It's a good example of how "doing everything perfect and by the book" can actually be destructive.

The shallows
Good point. Not smth new, but good anyway. Also good examples.

Alethophobia
Truthspeakers - is a job title for servants of some nation with horrible culture in the Wheel Of Time)))))
The point in the chpater is good again. It kinda repeats what was said in the previous chapters, but under a bit different light.
I agree that it's highly important to feel safe in the team.
Also good ponit - not to make decisions out of fear.
And agree that "testers don't own quality and are not gatekeepers" doesn't mean our job is to inform only.

Fool's Assumptions
Beware of the assumptions! Also good point.
I like the quote "When you ASSUME, you make an ASS of U and ME". ))))

Drowning in the deep

We should try to find a balance when we really need to test very deep or when we have to stop. We should evaluate the impact we will make by testing as deeply as we are going to.
If I understand correctly what this book is saying in this chapter and previous ones: we should always ask - Is it worth it? And how big will be the cost?

The shapeshifter

Don't fall into pattern, don't always use the same approaches, try to find new more suitable ways for each task.
Possible question for the author: did she really made all these mistakes in the past? Or it's for the book? she often tells "I wasn't a pleasant person to be around". Was it really true?
I actually like this approach, when the author uses themselves as a bad example, and it's not usual "we had this person on this project who did bad things". It would be nice even if it was fiction.

The inconceivable

"We test for the circumstances that matter, for people who matter, right now and in the foreseeable future".
One point in this chapter - that it's important to have healthy discussions. Healthy!!!!
"You can never know - you can only learn".

Tunnel Vision

Example with road from home to work - so true.
When you are doing routine - you become unfocused.
Yes, I notice how when I run test cases I don't pay attention to other stuff.

Enjoyed the traps section and we had some nice discussions. I feel the author is relatable and honest which is nice. Onto the tools section next! 🙌

Tools
The Facade
Good point - to check under the surface of UI.

Don't turn back
User's detours - yeah, nice point too. Have an example from my current project: confirmation pop-ups appear with both "cancel" button and "close" button. And also you can click on any other stuff on the page. So many ways to mess things up))

Forever and never
Never say never and always - valid point.

The observer
Observe data and learn - got it

The illusionist
i don't understand this chapter fully

Constantly Consistent
Yeah, we can find the inconsistency, and point it out, but it's not up to us to fix it. I suppose it'll be a fight over inconsistency in the majority of the cases.

The contract
Is it about dependencies? Why is it called "contract testing"?

Goldilocks
??

on consistencies - how does one navigate consistencies with innovation? true, we like consistency and initially might not like changes, but after some time we can adapt - we are humans after all.. I think not being consistent at times is good, but as long as it is not a hinderance.

On contract testing - a chapter, like the other chapters that give us a title, but no explanation on what it is. We have to figure it out ourselves it seems. From reading this it seems it refers to using 3rd parties/ also considered dependancies. I checked around online, and it seems the industry uses contract testing, for when we test our application and it's integrations/dependancies on 3rd party tools. In smart case, could be calastone, gocardless etc..

Goldilocks - Nice chapter, though there is no mention of goldilocks and why it is relevant. There's just a quote at the end from the story. So, Goldilocks tastes 3 bowls, 1 is too hot, 1 is too cold and 1 is just right... let's ignore the bears coming back to find this thief and eat her - but if it was related to testing - goldilocks would have been happy to find a bowl too hot and too cold, because those are the 'not right' ones.. also, too hot for her? but the users here are the bears, its made for them not her.. so she's like an edge case anyways.. and a mental case..

Lastly, the author should know, goldilocks didn't know the bowls were too hot too cold etc, whereas in her chapter, we as testers should know the boundaries, otherwise how could we go beyond them... again, goldilocks is not needed here..

Three is the magic number:
- not sure we would always require three layers of 'why' .. when we find a bug, devs usually know the root cause, we usually don't require to get 2 other opinions on it.

- it wouldn't be a biased decision if our dev tell us the cause. We'd just re-test the fix, and if the issue still happens then we'd know it wasn't the solution...

- Perhaps this applies when we find a bug and dev tells us it's a feature, or it's not a bug, or not linked to their work.. we can always go to the PO - who would be our source of right and wrong. But again here, it isn't 3 people, just 2 in this case.

- Going to get 3 layers of perspective each time could be time consuming, and quite rude for the recipient perhaps.

- thinking fast and slow book is on my to-read list, but I have read reviews saying it's very tricky to read.

- author references 3 amigos, again - this isn't really used to solve problems. It's used to iron out refinements as I understand. And to set expectations, identify risks perhaps. Kind of a refinements but more effort and time spent.

- I think the author, or me, has misunderstood what the 5 whys are. I always thought they were a way to identify a cause of something - not to hear one answer, then not accepted it, go get another answer not accept it etc..As I understand it, even one person can perform the 5 whys. You ask why, 5 times and each time you hope to get a layer deeper to the cause.

- some grammar issues here on page 103:
"the first "why" might get you that.."
"the second "why" might get you that they.."
I don't think it sounds or reads correctly..

- the author mentions that we are lazy and we want the easy solution. I'm not sure that means we are lazy. It depends on the nature of the issue. For example, let's say we have some currupt data in a db, we could correct the code which would take longer and may be more complex, or we could just run some rake task type of thing to correct the data directly and immediately. The easy option is the latter, but doesn't mean we are lazy. We are just helping the customer more promptly in this case. Also, why would someone actively choose a more difficult solution for the same issue? it's a natural thing to do what is easier.

- agree though with no reacting to our first thoughts about something

- 4 typos on page 105 .. tut tut..

- In the example, the author mentions they used the 3 why etc and ended up with 3 solutions.. but they didn't mention which was the first one they come up with , and which one they decided to go for.. this would have been good because it would have shown that the 3 whys, led to a better solution than the initial one.

The Memory Master:

- not sure how I feel about the analogy used for heuristics.. opening doors? .. hmm

- agreed with no point using others heuristics and mnemonics if they do not help you

- interesting task perhaps to come up with our own heuristic or mnemonic? that works for us

- I left the chapter not really seeing practical use of heuristics.. if I use a mnemonic, that's a heuristic? or vice versa? .. are they innate or build up over time and experience? like the opening doors analogy?

- authors favourite mnemonic is for remembering days of the week :'( not even test related.. so not sure how valuable these are haha
Also, it is a terrible mnemonic.. only 7 days, really need something to help remember those? .. I need a mnemonic to remember the mnemonic for the days of the week.. so long and unnecessary!

three is a magic number
if i understand correctly the matter not in the number three but in going deeper

the memory master
and I actually stopped trying to force myself to memorize things that I don't use often and that can be easily looked up in the internet

Weapons overview:

- seems like an interesting overview.. I have assumed from it, that we will get some dev secrets and potential ideas on things commonly missed or forgotten by devs, that we can use as our 'weapons' in QA

The Rift:

- Starts with saying: "I know this is a topic a lot of people find really intimidating." ... Well, it would be nice to first know what this topic even is first.. we are expected to know what the topic is from the rhyme at the beginning.. in most cases it still isn't clear before starting the chapter..

- I like that there are some practical things we can do if we want to continue our research on security testing. I like the mention of hackers using error messages to navigate. I have seen this also:
for example, you enter correct email but incorrect password, some applications tell you something like "the password is incorrect" which implies the email is correct. or vice versa.

- sometimes selling security testing or 'evil user stories' to teams is difficult because they seem like such extreme edge cases. Imagine refining some simple new text field and we ask about SQL injection there. Though it is valid, it might be considered overkill and disregarded.

- I like the question "how could someone exploit this?" - but we should also first ask, "what would happen if somebody exploited it" - then we can decide if we needed to address such matters.

- the quote at the end of the chapter makes no sense to me:
"Don't overlook low-level security findings. The attacker won't bother picking the locks if they can climb over the fence"

Shouldn't it be 'cannot climb over the fence' ? .. if they can climb the fence, they are definitely picking the locks lol ..

weapons
the rift
well... not sure what to say. there's a point in this chapter but I'm kinda not interested in it?

The unexpected
Custom error messages - that's always good

The hive
good point too, no additional thoughts. Just finding the root cause of the bug cluster can be difficult. It's easier i think when it's tech problem. Harder to handle when it's people problem.

Lost in translation
Good tips. (Three body problem example)

The Juggler
yep, performance testing is tricky