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.
Block development
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.
Block yourself
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.
Placate management
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.
As a developer, I totally agree with your list for the devs on the team as well. I would, however, add one more for testers: Stop insisting that you don’t need to learn how to code to do your job well. Just learn how to code and see how much better you become at your job. I can’t guarantee that you’ll love it as much as I do, but you will definitely add more value to the project.
Thanks for taking the time to leave me a comment, Dan. I completely agree with you on learning to code, but there are even more fields which serve meaningful for a tester, like philosophy, psychology and management. That point came to mind while I did this write-up. However, I never intended it to be a thorough list containing all aspects. Your hint is a nice addition on that. I think Lessons Learned in Software Testing has about 300 more on this. :)
I completely agree with the point about hiding in the testing cubicle. Only up to a point though.
On the one hand it makes such a big difference if you build a good relationship with your colleagues in the development team. Being able to talk to someone about an issue usually saves time and helps build a great team.
However, in these days of open plan offices finding time to block out and dedicate to running your tests becomes more and more difficult. And I’m sure it’s the same for developers. I expect the amount of uninterrupted time they get to just focus on writing code is very small. Constant interruptions from colleagues can really affect our productivity.
So my suggestion would be to have a couple of periods set aside during the day where it’s agreed that it’s acceptable to interrupt your colleges to talk about issues. In this way testers and developers get the chance to have periods during the day where they can work uninterrupted.
To a certain degree I agree with this. But we have to keep in mind that we might introduce the biggest problems during our private time, when we work for ourselves. The problems we’re introducing counter-act with the notion of Collective Coder Ownership, and Collective Test Ownership (how Elisabeth Hendrickson coined it). When we’re running down an alley, we might not see the light, and do very bad things. One comment in code I recently heard from was the following:
// Only God and I knew what I was thinking when I wrote this.
// Now only God knows.
A second thing is, that I might be fiddling with my tests and have worked myself into a dead-end. At that time I have to notice it, step up, and ask for help. I won’t ask for help, if I don’t realize the problem. And far too often I realized my flaws in my thinking too late, when the stuff already came back at me weeks later.
The same holds for tests. The reason more traditional methodologies called out for heavy documentation was the fact, that having one person leaving the company (or getting hit by the bus), shall not cause the project to a halt. With heavy documentation, I can achieve this. When everything is documented to the degree, that everyone else can do it, this is Collective Ability to Test. Collective Test Ownership on the other hand goes a step further in that it favors that everyone shall have the responsibility to think of a test and run it.
Instead, I welcome pairing. Pairing for Exploratory testing, pairing for production code, pairing for test automation code. These ideas are not new, and nothing else than pairing brings me the benefit of a shared understanding and an instant review – up to the point that a pairing partner reviews my ideas when they come up (maybe this will be possible once we have neuro-interfaces). Of course, I will be exhausted from time to time, and need personal focus time then, but I think it’s crucial to pair most of the day to overcome the earlier mentioned problems. And it has the benefits that I also may be hit to a certain flaw in my thinking earlier, and seek out for help before going down a dead-end.
As I said in the post, we’re living in the 21st century, and we really should stop applying models from manufacturing ideas, that never worked at the beginning of the last century in the plants, either.
I’m not sure I agree with point 7 “[don’t] Work nine to five”
In my mind, if your business requires you to work longer than the hours you are contracted for, you as a worker are being exploited. It also suggests that your company simply does not value quality, or at least is not willing to pay for it.
You have a number of working hours stipulated in your contract for a reason. I understand that we all want to do a good job and impress our superiors – but suggesting that testers need to start working for free occasionally? I don’t think that is very sensible.
Oh, I think you got me wrong on that one. I meant that you shouldn’t simply turn your cadaver to work, because you did so for the past ten years. Instead, you should seek what your stakeholder is currently needing. That might mean that you should work a little overtime as the situation demands, but that this should also be an exception – not the rule. Does this make more sense under these circumstances?
I do understand your point of view completely. Be adaptable in your working practices and hours right? I work in an agile shop and we try to take this quote to heart:
Of course, find myself working more hours than contracted on plenty of occasions myself to help release a product. But I personally feel that, in an ideal world, the pressure should be on the stakeholders to hire the right number of people for a product release and not the development team having to extend working hours occasionally.