get in touch open menu close menu

Get uncomfortable: stepping out of your testing yard!

QA, QC, QA tester, QA automation … terms that people sometimes wrongly use to describe the same thing: a software tester, a person that always breaks stuff and complains that they break…the last one being a joke, so no offense to the software testing community :).

So, what is a tester after all?

Is it just the person who clicks randomly and finding issues everywhere? The person who does automagi..automation? A software tester is, according to definition, “involved in the quality assurance stage of software development and deployment. He conducts automated and manual tests to ensure the software created by programmers is fit for purpose. Software testing involves the analysis of software, and systems, to avert risk and prevent software issues“.

That’s all fine and dandy, but how can a tester be a part of more? Let’s face it, you could just stay in your cool testing yard, do your thing, and never worry about the company neighbors, but there’s a whole world for you out there to explore (hah, explore) ok, lame joke aside, the point still stands, the world is big, and knowledge is everywhere.

Say you’re in a company, and you do the best job you can do on your project: you have a great testing strategy, awesome test cases defined, and more automation coverage than highways in Romania.

Can you keep this up without wanting to know more? About involving yourself more, and thus, learning more?

In my opinion, not for long; the need for getting out of the yard kicks in. And thus, the question comes: How can you get out of your yard, and more importantly, make it worthwhile?

In first instance, to get a taste, start at the company level, by being a part of the Testing Community team, sharing knowledge, tips and tricks, tools; you’d be surprised to learn how sometimes, the way some things are done on other projects can make sense on yours also, and so, contribute to the overall quality.

Most of the time, asking questions is hard, mainly due to fear of appearing that you don’t have the knowledge, but that’s exactly why you should ask questions, because guess what? That’s how you get knowledge.

And knowledge doesn’t only involve technical stuff, but also things like how others interact with the developers and the client, learning to better communicate, thinking outside the box. And that’s just the tip of the iceberg. It might not feel like yourself, but it sure gets the job done.

One of my favorite quotes states: “Your work is going to fill a large part of your life, and the only way to be truly satisfied is to do what you believe is great work.” How do you define great work? It differs from person to person, but focusing on a tester’s role, it is much more than finding bugs.

You could hold a workshop on that new awesome tool you found, and you’re having great fun with. It might not be used on your project, but that doesn’t make it any less useful for others, and especially for you, because let’s face it, you’re not gonna be on the same project forever, right?

But let’s say maybe you’re at a point where you think you might not have anything to contribute (there couldn’t be a statement more wrong than this, but I digress); you could maybe not hold a workshop, but take a part in one. Start small, attend a workshop in your company, then attend a workshop in your local community, and pretty soon you might end up attending, or even better, holding a workshop at an international conference. Possibilities are limited by imagination.

There is also the part where you could get involved in non testing roles or actions. For example, maybe you could become the scrum master for your team, a sometimes very overlooked role, but one that might help a tester more than any other team member, due to the constant team and client interaction, and you might not be seen as the “evil tester” anymore 🙂 but as a process responsible and team integrator.

These are all suggestions that could apply to new guys/gals, but also to those that think they hit the wall.

They are not a set of predefined rules, or a recipe for success, but things that might just work for you (as some of them worked for me).

TL; DR version:  “A conclusion is simply the place where you got tired of thinking.” – Dan Chaon

That means, there’s no short version, so get on reading :).



Subscribe to our newsletter today and get regular updates on customer cases, blog posts, best practices and events.