Making testing great again

Testing. The much-maligned and less glamorous cousin of software development. Testing’s boring, repetitive and can’t really be that hard, right? Testers are only there to break stuff, find bugs (nitpick), and generally make life difficult for developers. What do they do when there are no features to test? If automated tests are already written, why would we still need a tester to repeat it manually? Plus, developers are cool! Testers are. . . meh.


Well, those are some of the common stereotypes about testing/testers. And I’ll be the first to admit that some of them were at the top of my mind when I was asked if I was interested in stepping into a testing role here at Media Suite.

But, the draw of helping shape how testing’s done at Media Suite was too hard to resist, so here I am on the other side, in Testing Land. I hope that by sharing my journey and some of the processes we have, I can debunk some of these myths, and make testing great again!

I joined Media Suite about 2 years ago as an intern, after graduating from Enspiral DevAcademy in Wellington. I stayed on as a developer, until I moved over to testing on one of our major projects, and now I’m known as the testing guy. I was an accountant in Singapore in a previous life, which might explain why I’m boring and suitable for this role.

giphy (6)

Being the testing guy at Media Suite

I was lucky, in the sense that everyone at Media Suite understood that testing and quality assurance for our applications requires a team effort, and not just the responsibility of the tester. This meant that I wasn’t seen as an adversary or the ‘quality police’, and that made my integration into the team a lot easier. Which also meant that the developers still liked me. . . I think?

An example of this team mentality is that features are tested by the developers before submitting it for code review/testing. This, coupled with the automated unit and integration tests that they’ve written while developing the feature, means that the feature has already been well tested before it comes to me. Small things they may be, but it frees me up to focus on the bigger picture, instead of looking for defects on individual features.

This focus on the bigger picture, is where I feel a tester can add the most value to a product. Because of the nature of the role, the tester often has the most domain knowledge on a product (other than the project managers). This allows the tester to consider what impact a feature might have on other parts of the product, and how they tie in together to fulfil the business requirements of the users.

The tester would also be able to put his/her user cap on, and manually test the product like an actual user would. This exercise picks up plenty of bugs that would be missed by automated tests and when testing individual features.

Bugs and me


Every time a bug gets reported, I feel conflicted. On the one hand, it feels terrible when someone else finds something you should’ve found, but missed. And now you have to get a developer to fix it, when it’s more expensive than if it was caught earlier. On the other hand – yay – another bug to reproduce, another puzzle to solve. Cheap thrill (and weird), I know. But this is where I ask, how is testing boring when I’m thrown different challenges every day, and no two issues are the same?

I once spent 6 hours reproducing a bug, that turns out to only happen when an user revised an application 8 times. Yep, that was a long day, but it was thoroughly satisfying, and the user was happy that she wasn’t seeing things (and we fixed it). That was the day I really knew I was cut out for this testing business.

giphy (4)

The future and beyond

How we test our work at Media Suite differs from project to project, but I’m hoping we could replicate some of the things we’ve learnt on this project on the others (and this blog post is a start!). Going forward, we’re looking to involve myself at an earlier stage, when user stories are written, so the user acceptance criteria gets a testing input.

Now that we also have Natalie, our User Experience guru onboard, I’m looking forward to more collaborations – our roles operate in similar spaces, but with different focuses. Having another pair of eyes would also prevent tunnel vision and mean we catch issues earlier. All this would allow us to build better features that meets the needs of our users, while improving our craft.


I hope I’ve managed to convince you somewhat that testing has plenty of real value, and isn’t as half bad as its reputation is!

That time we went to nz.js(con);

Before I tell you about the conference, I’ll clarify the pride I feel for Media Suite, stepping up as a Diversity and Financial Aid Sponsor. We helped people attend a conference that they otherwise would not be able to attend. This sponsorship is core to our values, not something which needs a special case.

Right, about the conference.

The best part of nz.js(con); was seeing my colleagues who work remotely and forming the “nerd huddle”. Together we ate Korean BBQ, drank Wellington’s finest craft beer and ate the largest pizza I’ve ever met. I got to dive deep on some technical discussions which are at a different level to a chat or video call.

Media Suite's delegation in their matching branded t-shirts. So, so cool.
Media Suite’s delegation in their matching branded t-shirts. So, so cool.

Over two days, 32 talks were presented. There was something for everyone within the two tracks at the conference. One, focused more on the technical, another was more accessible.  In my opinion the non-technical talks were much more interesting.

Diversity, burn-out and mental health were recurring themes. It came through in multiple talks. One taught us how blameless culture can help your team learn and grow. Another, how you can build someone into a confident professional developer in six months.

Learning new ways to express these ideas was something incredibly valuable to get from this conference.

Image uploaded from iOS (1)
Queenstown Dev Jonathan with the biggest pizza I have ever met.

Two talks which really stood out to me were on personal projects that had grown and matured over the years.  One, about a digital audio workshop (think Fruityloops or Pro Tools). Another, an interactive exercise on algorithms, told through a story about a post-apocalyptic world ruled by rats (in a maze).

Seeing the passion of these people was inspiring and it brings me a lot of joy to see technology used in creative ways.  It blurs the line between technology and art. Choosing to recreate an existing tool is objectively crazy, but people still do it – it’s equal parts exciting and insane.

How can I sum up this experience? I learned a lot about myself.  I’m not that interested in the technical content at this conference. Everything presented was something which I would have learned about in my own development time. I learned that I should be playing more of a contributor role in the JavaScript community. Now I’m helping run the Christchurch JavaScript group, I hope that by building up the community I can play a part in growing our industry.
Beyond the conference and the learnings, sharing meals with a group of “suitees” (Media Suite people) was the best part of nz.js(con); and some of these colleagues I was meeting for the first time! Richie, you’re taller in person.