How to be a failure as a software tester
There are multiple sources for testers who strive to excellence, but the other perspective hasn’t been covered… yet. In my essay I’ll try to show you how to make terrible job which can label you, your work and even your team as a FAILURE.
The list consist of few points which can’t be neglected if you want to achieve miserable results in your profession.
Fundamentals - mind & body
Every ambitious goal in your life require proper foundations. Ignoring you personal development when it comes to mind & body is probably the single most important thing to do.
If you train too much, eat healthy and keep your body relaxed you are in great danger of missing sick leaves which can be used as additional holiday. Exercises have adverse effects on concentration and releasing stress. Better to keep your muscles tense and always be slightly irritated.
When it comes to mental development you may have seen certain kinds of people who advocate reading books. That’s a terrible thing to do - better to keep your mind numb and never challenge it (especially with different points of view). If you happen to read, make sure it does not force you to think. There are plenty of pages or newspapers which can be used in that regard.
Quality guardian
Ingenious managers (who, I believe can proudly call themselves failures as well) had a brilliant idea some time ago. They decided to transfer responsibility for successful releases into testers / QAs by introducing ‘quality guardian’ role. For those who don’t know how it works: this person has a decisive opinion whether given software can be safely released into production.
Imagine how much power it creates for failure testers. Most of the time successful IT products are released as soon as possible in order to collect feedback and verify early version (called proof of concept - PoC). As a quality guardian you can ‘Advocate “caution.” Be “reasonable” and urge your fellow-conferees to be “reasonable” and avoid haste which might result in embarrassments or difficulties later on’ (see my What CIA teaches us about productivity post for more ideas) to make sure releasing your software is cumbersome and slow process which require a lot of hassling and discussions. If you notice however, that particular release candidate is in very bad shape don’t be afraid to release it as quickly as possible.
Make sure you always support introducing ‘quality guardian’ idea into your organisation. You can advertise it as idea which frees developers from caring about quality. Be the only ‘quality guardian’ in your team.
Avoid technology
There is a lot of unnecessary talk around ‘technical tester’ concept. Apparently such person should be highly technical with a lot of computer skills. As someone who wants to achieve miserable results you should actively refute such nonsense.
You shouldn’t innovate much. It’s better to keep things as they stand now without any automation at all. ISTQB advocates heavy processes with a lot of documents, strategies, descriptive test cases etc. That’s a way to go. Do not experiment with exploratory testing. Better to create new test cases and execute them shallowly.
As a master you can go level higher and automate things which shouldn’t be automated (preferably using hard to maintain Selenium scripts on top level) and execute manually tests which can be easily automated.
TestOps? What?
Remember and advocate it whenever possible: test environment maintenance is not you job. If something isn’t working properly (for example one of adjacent webservice is down) shout that you are blocked and you can’t properly do your job. Such problems should be fixed by ‘others’, ideally poorly defined ‘others’. Do not get your hands dirty trying to fix it.
Occasionally some developers may introduce you with cheaper, easier to maintain alternatives ( like Docker Selenium). Remember: it’s a trap. Do not experiment too much with such things. You may strategically say that you will check it later (remember not to commit for any date!), but in fact you won’t.
Avoid Infrastructure as a Code concept. Better to keep things misconfigured on various type of servers.
Team flow disruption
Believe it or not, but software development is social activity. As a team member you can influence your teammates in many ways.
You shouldn’t smile too much, that may lead to unnecessary positive vibes around. Better to be always in negative mood and radiate it around your open space. If something bothers you make sure you complain loudly and everybody hears what you have to say.
Do not socialise with others drinking coffee or going for a beer after work hours. Better to be loner who isn’t bothered much by peers. In rare instance, if someone asks you for help do not be too eager. Keep your knowledge to yourself and don’t teach anyone anything.
In lean software development there is a thing called ‘waste’. Make sure you understand it fully and know how to increase the amount of it. Look at your team as a complicated system and try to influence it negative way.
Community perspective
Few testers wants you to be active part of community. Ignore them totally, do not attend local meetups, do not write blogs, do not attend conferences, do not read technical books, do not discuss testing topics with others. Building your personal brand is a sham.
Why are you reading this post anyway? :)
Tags: testing thoughts
Categories: Testing thoughts
Updated: