This has been on my mind for quite some time. During the past week I read three blog entries which reminded me to write this down. First of all there was Vesna Leonard who wrote that she was not like any other qa or tester that her colleagues had met. Second, Lanette Creamer wrote a tale of two testers. Finally Alan Page blogged about the Tester DNA. Having referenced my inspirations, let’s take a look on things that us testers do, but should stop doing, and most importantly why.
When working through the feature set of a new product release, testers have to stop thinking for a moment why this feature is breaking the product. Another consideration here is, that automated tests should not block the development of new features in the software. Remember: your company gains competitive advantage by including new features into the software. Instead think how you could test it, and if you don’t know how, discuss this with the rest of the team, instead of blocking new features that seem hard to test for you.
Sometimes our test environment might break. At this point, we should not drop our pen, and start to browse the web for the latest comic. Instead we should get up, and seek for alternatives. Maybe we can run this test suite on a developer machine, maybe we can seek help in fixing the problem with the test environment from a nearby programmer, or another teammate. It’s our initiative that counts here.
Hide in the testing cubicle
The days where testers had to be separated form programmers should be over. We’re living in the 21st century, and software development is a responsibility of a team. Instead of working in your little testing cubicle, throwing bugs over the wall – preferably on a Friday afternoon forcing your co-workers to do overtime over the weekend – is unprofessional and irresponsible. Instead stand-up, walk to your colleague, and talk. Software development is a human activity, and that requires communication and collaboration – however daunting you may perceive this.
Use testing as quality gate
Having the power to say “ship!” or “don’t ship!” is a seductive ability to have. But surely, making the decision to ship some piece of software is not a decision that a tester can make. As long as we don’t know about the implications for our company, the contract the client has with our company, the risks involved in going live with a product that may contain problems, we shouldn’t make this decision. As I learned from Cem Kaner, and Michael Bolton it’s a business decision to ship or not ship the product. We can inform this decision by our report, but testers shouldn’t make this decision.
Poor management reports
This could be a pure test management thing, but testers often also fall guilty of this. Remember one of the first lessons from Lessons Learned in Software Testing: Testers are the headlights of the project. We light the way for the project. We have to provide our information in a way that our audience understands. This includes to drop unnecessary details in our explanations. This includes to provide a business understandable level of report. It’s what you’re getting paid for! Dusty headlights don’t help much.
Working the fortieth weekend straight is not going to help you in any way. Surely you want to help, but you provide a better help if you lead a balanced live, instead of a burning one. When you’re overworked you may miss things that would be crucial. You may be worried that you took time with your family the last time one year ago. When you’re worried, you may not be of a great help to the project either. So placating the manager who asks you about coming in for the weekend will just make bad things even worse. Instead provide the unambiguous message why you will be spending your best efforts on the critical release during the office hours next week – but not any sooner.
Work nine to five
Working nine to five controversially doesn’t help either. There are tough times, where your company may get into an advantageous position by releasing the product. At this time you may be asked to do your best. This should be the exception though.
Think you know it all
Thus far I know that I don’t know about a lot of things. This is ok. But I didn’t meet someone who knew it all, either. Instead keep your mind open for new things, for learning about things. In fact, the day when I will stop learning, is the day when I will be dead. Life-long learning is the duty and responsibility of the knowledge-worker.
Busy bee’s swamps
From time to time you should reflect on your work, and see if you have been doing a daunting task, and how you could improve that. Just working without thinking over it will not help in the long term. In fact, you might have painted yourself into a corner, but didn’t realize this until it was too late. Think about your work, your team, and how you could improve your process. Share your thoughts with colleagues and see what you can do to implement this.
Search for best practices
Managing a project is very easy if you exactly know what to do. Unfortunately I have never worked on a project, where I knew all the time what I had to do, or what the best thing to do was. After all, if a project was that easy, we wouldn’t need management after all. We would simply do the job. But in each project we gain insights into the business matter. As our understanding grows, we can come up with more creative solutions to the unique problems at hand. That’s why we shouldn’t support the search for the holy grail of best practices in first place.