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.
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.
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!
