Was there a test for that? No, and there shouldn't be.

The release shipped. For a while, the team felt good. The work was done, the team had achieved something, and that was rewarding.

Unfortunately for the team, it wasn't long before a problem was found. The Product Owner wasn't happy and had asked was going on down there in the galley, do we need new coders? Better ones? Hipster coders?

The release shipped...

After an investigation, some blushes, raised eyebrows and a couple of "Oh... Yeeeah's" they found the cause. A confusion had collided with a bodge, and the result was a mess.

Should they write an automated - test for this problem?

An embarrassing mistake or a misstep can make us feel we have to do something. An action greater than a fix is needed. A penitance needs to be performed, to redeem ourselves, to make us right again.

Sometimes the penitence is best spent adding a test for that issue. Especially if writing that test has a low cost, the frequency of the problem occurring is high or the impact of the problem is substantial.

But often, there is a smarter path. Take for example the opportunity cost. While you add that automated test, What else could your team be doing? For example, you might be able to spend the time fixing that underlying bodge.

As a tester, a highly targeted automated test might give an instant feeling of protection and a helpful dose of CYA. But while you are coding that test - you are not spending as much time:

Looking for root causes, in code and process
Searching for similar assumptions the team made
Thinking laterally about what else might be broken
Talking to your team about how to stop this happening again.

Also, the automated test may just turn out to be more expensive to write than the fix. Sometimes, iterating is the right thing to do - not just regarding isolating the right product but also in honing its quality.

You can learn from failure, it's essential you step back & take a moment to let that happen. Investigating Software can help you do that.

Comments

Betting in Testing

“I’ve completed my testing of this feature, and I think it's ready to ship” “Are you willing to bet on that?” No, Don't worry, I’m not going to list various ways you could test the feature better or things you might have forgotten. Instead, I recommend you to ask yourself that question next time you believe you are finished. Why? It might cause you to analyse your belief more critically. We arrive at a decision usually by means of a mixture of emotion, convention and reason. Considering the question of whether the feature and the app are good enough as a bet is likely to make you use a more evidence-based approach. Testing is gambling with your time to find information about the app. Why do I think I am done here? Would I bet money/reputation on it? I have a checklist stuck to one of my screens, that I read and contemplate when I get to this point. When you have considered the options, you may decide to check some more things or ship the app

XSS and Open Redirect on Telegraph.co.uk Authentication pages

I recently found a couple of security issues with the Telegraph.co.uk website. The site contained an Open redirect as well as an XSS vulnerability. These issues were in the authentication section of the website, https://auth.telegraph.co.uk/ . The flaws could provide an easy means to phish customer details and passwords from unsuspecting users. I informed the telegraph's technical management, as part of a responsible disclosure process. The telegraph management forwarded the issue report and thanked me the same day. (12th May 2014) The fix went live between the 11th and 14th of July, 2 months after the issue was reported. The details: The code served via auth.telegraph.co.uk appeared to have 2 vulnerabilities, an open redirect and a reflected Cross Site Scripting (XSS) vulnerability. Both types of vulnerabilty are in the OWASP Top 10 and can be used to manipulate and phish users of a website. As well has potentially hijack a user's session. Compromised URLs, that exp

What possible use could Gen AI be to me? (Part 1)

There’s a great scene in the Simpsons where the Monorail salesman comes to town and everyone (except Lisa of course) is quickly entranced by Monorail fever… He has an answer for every question and guess what? The Monorail will solve all the problems… somehow. The hype around Generative AI can seem a bit like that, and like Monorail-guy the sales-guy’s assure you Gen AI will solve all your problems - but can be pretty vague on the “how” part of the answer. So I’m going to provide a few short guides into how Generative (& other forms of AI) Artificial Intelligence can help you and your team. I’ll pitch the technical level differently for each one, and we’ll start with something fairly not technical: Custom Chatbots. ChatBots these days have evolved from the crude web sales tools of ten years ago, designed to hoover up leads for the sales team. They can now provide informative answers to questions based on documents or websites. If we take the most famous: Chat GPT 4. If we ignore the

investigating software

Search This Blog