Sunk Cost Fallacy - Let's talk about bias 3

We continue our review of  biases we all have intrinsecally implemented in our own brains that lead us to make certain decisions, as Rolf Dobelli describes in his bestseller The Art of Thinking Clearly.

Sunk Cost Fallacy - Are you Lean enough?

This really is a very useful bias. I believe if we're honest enough with ourselves it helps us to really do a better job saving unnecessary costs for our company.

Without much introduction, two cases that immediately come to my mind:

1. You see this huge beautiful implementation arriving testing. Verification passes without any flaw. You then notice: validation fails! This is not really what we wanted. Do you dare to create a bug and vote for throwing away / reworking all that hard and good work? Do you try to bend in and persuade any opposing mind to believe that that's what they wanted? Sometimes this is not the worst choice - sometimes clients just don't know what they want XD
2. You've convinced everybody you need those automated tests / manual test scripts / test management system - whatever - to improve your testing process and all over quality of your product(s). It becomes a nuissance in time, things change, tempora mutantur. Are you willing to let go, to not hold it back anymore? Throw away what lacks purpose and be really lean.

Social Proof - Let's talk about bias 2

We continue our review of  biases we all have intrinsecally implemented in our own brains that lead us to make certain decisions, as Rolf Dobelli describes in his bestseller The Art of Thinking Clearly.

Social Proof

SCRUM planning session. A tester (role) points out that a certain US should include a some test to minimize risk of failure (functional, non-functional, however). The team and the product owner discuss the risk and convince themselves that the test is not necessary. The tester role has given in and will rest in peace.

The social proof makes you believe a decision is right because everybody else seems to believe it's right.

As tester you then have to ask yourself critically: is it their arguments that convince me or is it them being so convinced that does? If it's their arguments you might rest in peace, really. If not, argument against it or forever remain silent.

Survivorship bias - Let's talk about bias 1

You'll probably remember that a tester's profile has one of its main reasons for existence in avoiding author bias.

As QA and testers dive into Agile environments it's hard not to become part of the problem.

Interesting enough, there are well known biases we all have intrinsecally implemented in our own brains that lead us to make certain decisions, as Rolf Dobelli describes in his bestseller The Art of Thinking Clearly.

This post starts a series of checks of those biases with QA specific examples, so any tester or QA role can improve their work. Besides Agile, I like the move forward Quality Assistance because I experience that it works. So anybody in the team should have some advantage by knowing these biases.

Survivorship Bias

You as QA are confronted with developers and business representatives telling you "product X didn't have all of those design patterns, automated tests, branching policies, etc."

They strike you hard. You feel like earth's gonna swallow you. You're in China and only speak Hopi. Shit!

This is not your bias! Let'em check out their bug reports and time (and money - YEEEES, business speaks MO-O-NEY!) spent on fixing them. Speak to them about your customers serving as testers. But we're not facebook, we sell other stuff under different conditions. And if you really can't find none of those arguments to have effect present them the worst case, find examples for companies who failed with much embarrassment or quit your job, right now there are great developers at work!