šŸ„§ Pie Mail - sunk costs and supertests šŸ„§

published2 months ago
4 min read

ā€‹

Kia Ora! It's pie-mail time again!

Hope you're all doing well! We've just finished another couple of weeks in lockdown here in Auckland, and the end is in sight.

I've been filling my time learning some new automation tools - SuperTest and Playwright. I'm sure you'll see some updates on those things in upcoming newsletters!

I also had my first COVID jab - which was an adventure in software problems. It turns out, I don't exist in the national health system. Or I did, but my record has 'somehow' been merged with someone else.

Part of the fun of being a tester I guess, is that the bugs come to me. I still managed to get the vaccination though, that's the main thing!

Here's your regularly scheduled (but admittedly late) newsletter!


šŸš¢ Sunk costs šŸš¢

ā€‹

Let's talk about sunk costs!

At some point or another, I reckon every engineer or tester will come across a 'sunk cost'. The term comes from accounting and economics. It's when you realise that something you've invested in isn't going to work out.

In software, that often takes the form of projects that are started but never finished. Time and energy gets invested, but then, for some reason, the project is no longer viable.

There's a few reasons this might happen. The business might see changes in the market that shift their priorities. This could be things like a big new customer, or a competitor going under, or changes to legal requirements. It can happen due to technology too - for example, buying a tool without realising it doesn't do what you needed it to.

So, the project that was in progress becomes a 'sunk cost' and gets discarded in favour of something else.

Having to deal with these sunk costs can be demoralizing. For me, it means that the time and energy I've put into something feels 'wasted'.

But here's some things that can help:

  • It's better to know about the sunk cost now than later! Maybe we churned three weeks on something we shouldn't have, but three weeks is better than three months.
  • There's learning opportunities. The work that was done isn't a waste, even if it's being discarded.
  • In my experience, sometimes not all of the work is a waste - there may be things that can be salvaged!

Of course, we still want to avoid these sunk costs, which is one reason we want to start testing as early as possible. It's alarming, too, if this happens with any sort of regularity.

But, occasionally, they'll happen. Agile means requirements can shift underneath us, and we have to learn to handle it.

I've learned, as much as it stings, to take positives from it, and move on to the next thing!


āœØ Some interesting links āœØ

The founding story of M-Com

I don't think you could throw a rock in Auckland without hitting someone who has worked at Fiserv (originally called M-Com). They're one of Aucklands software success stories. Bradley Scott talks to some of the original M-Com team - Graeme Ransley, Adam Clark and Serge Van Dam - about what those early days were like.

ā€‹

Quality Coaching

Kim Engel has polished off a series of posts on what it means to be a Quality Coach.

ā€‹Here's part one (of four) - definitely worth taking the time to read!

ā€‹

What's the difference between em, rem and px?

I learned a while back that it wasn't good to use 'px' to declare pixel sizes on the web - but nobody explained why. Now I know, thanks to this video from Jessica from coder-coder. Check it out to learn why 'rem' is nicer than 'px'.

ā€‹

Tech Talks Weekly

Tech Talks Weekly is a superb new show from Gwen Diagram, Sanjay Purswani and Neil Studd. I say new, they're already up to episode four - I'm clearly behind the times. It's fun to watch though, check out the latest episode!

ā€‹

Your proposal is whack

From the tales of testing gone horribly wrong Someone at a UK city council thought they were using a test environment, but they were actually using production. The fun part is, it's legally binding.


šŸ§© Puzzle time šŸ§©

I've started using SuperTest (a JavaScript API test tool) this week (and I'm using Chai for assertions).

While doing some experiments, here's an example assertion I came across:

expect({'name':'susan'}).to.equal({'name':'susan'});

Would you expect this test to pass or fail? Why or why not? What could you change?


šŸŽŖ Events coming up šŸŽŖ

Events for those of you in New Zealand:

Still in lockdown sadly, but hopefully we'll be changing levels soon!

Events for anyone anywhere!

Creating test strategies teams will read (Sep 22)

Thomas Shipley presents this masterclass in test strategies, and how to get your team involved in building one - should be good!

ā€‹

Continuous Quality with Postman (Sep 22)

Neil Studd and Joyce Lin are hosting this intermediate level workshop on Postman - if you're looking to level up your Postman skillset, this is the one for you!

ā€‹

Figma Workshop (Sept 24)

This one's very exciting - UX Auckland are hosting Miguel A. Cardona Jr, from Figma! He'll be running a practical workshop on the fundamentals of using Figma.

This one has a (very reasonable) cost, and some prep required - so check it out in advance. Figma's a neat tool, worth learning, and here you can learn from one of the best.

ā€‹

How to build a culture of quality (Sep 28)

Ministry of Testings 99 minute workshops have returned! There's a full list for pro members, if you're not a pro member yet, then check out the first sponsored workshop, how to build a culture of quality!


šŸ‘‹ Thanks for reading! šŸ‘‹

Take care, and reach out to me any time on LinkedIn or Twitter.

Nga mihi,

James a.k.a. JPie šŸ„§

ā€‹https://jpie.nzā€‹


I respect your privacy. Unsubscribe at any time