How I accidentally found out about the mysterious realm of testing.
One of my first memories, when I was about 4-years-old, is how I’m going through my grandfather’s stash of old and/or broken stuff, that’s either waiting to be repaired, reused, or tossed away, and him shouting: “Don’t touch that, you’ll kill yourself!”
He was probably right, because if I would plug that old power supply into the power socket, there’d probably be some fireworks. And later some fire. On my head.
I got kind of scared of trying new things because of this, and due to the fact that I’ve always wanted to be »a good boy« that »behaves« and makes his parents proud. This continued for almost two decades, but eventually things changed because of my nature to try to bend things as much as possible until they break. Sometimes even beyond that point. Several times.
I was lucky enough to receive an invite from Comtrade to join a project as a junior tester student (although I didn’t know what that really is, because I wanted to be a developer – duh!). I was supposed to test custom-made system that did something I-may-not-tell-here, for a company I-may-not-mention, and with programming language I barely knew (this I can say – it was Python). I immediately liked everything about it – the project, the people, the work. I tried to learn a lot, and optimize the system as much as I could… Everything was going great, and, after a brief pause, I started working on a different project, where I learned how to write Unit tests in Java, as well as manually testing frontend and reporting bugs. The team grew because of all the issues reported – and so did I. Every day I’ve learned something new (as I still do, today), and I’m even working closely with students that also want to have careers in QA engineering.
But, let’s stop here, and make couple of things clear. A lot of developers think of testers as second-class programmers, or even worse – non-programmers, because they don’t program at all. False. Have you ever seen an integration test written in Java?
People think that testers spend their days clicking through UIs or mobile apps. False. Have you ever seen Selenium tests?
And last, but not least, people think that QA engineers a.k.a. testers don’t have any friends. False again. I have 4 of them! 😊
People often think that testing is something that you do at the end, when you have “end product that is ready for implementation”, so “you just run those 10 tests just to verify that everything works”, but this is not true at all. Any serious QA engineer will tell you that testing starts even before the first line of code is written, because development and testing are basically the same: writing computer code. Imagine if you started writing something without thinking about it in advance – it probably wouldn’t work, and it would be messy, also. The same goes for tests – if you want to write good tests, you have to think about it, talk to developers, talk to the product owners, talk to the customer, make plans, give tasks to the testing team, manage the whole process with your and other teams, etc. Testing is very much like programming, especially if you want to write complex end-to-end tests, functional ones, or automate a whole UI. The only difference between the developer and a tester is that developer gets his “instructions” written on a piece of paper from a customer (e.g. create specific feature for the webpage), and tester gets the developer’s code. So, both programmers have their “set of instructions”, from which they build something.
Testing is not easy as one could imagine. Sure, you have sometimes some simple tests that check some trivial code, but if you want to seriously test something, you have to dive deep into the code and documentation, which can take several days, think about it, start writing test scenarios, and later implement them. On a higher level, you also have to choose and setup a framework, teach people about it if they don’t know it, setup a CI/CD, as Jenkins or Bamboo CI, debug why something isn’t working, etc.
I have learned, that QA is very much programming, as it is development, although on a different level. You have to have the right “how-to-break-stuff” mindset, and the necessary skills to do that (you really can’t destroy a building with a brush, can you?), mixed with some experience, and team, that is willing to take the thing down.
Sometimes I am confronted with the question: “Why can’t developers create their own tests? We really don’t need a QA team.” I immediately respond with an example: If I create a car with LEGO® blocks, and I play with it, I don’t want to drive it into the wall, as this is “not it’s intention”. I am sentimentally connected to my creation and I don’t want to do this.
But if you have a dedicated person that does this instead of you, there’s no attachment, whatsoever. He will sit on it, drive it into a wall, and throw it from 2 meters… Just to see if it can handle it. And that’s one of the most beautiful things you can imagine – you get paid for breaking stuff and trying to check its boundaries.
I don’t know why, but I’ve always admired the car crash tests, the slow-motion replays, the car getting destroyed. You know why this is done? To check the integrity, safety of the car. Similar tests are done in all aspects of life – and they should also be done in testing. Always. Because code runs your phone, and its security features, your car, your elevator, your mixer.
Interested in testing? Join one of our many teams. You will learn things you never knew existed, test software you thought it was impossible to break, and share your workspace with people you only dreamed of.