We’ve placed a ban on crappy work within my test team. From now on, we declare that the testing team will refuse to do crappy work.
The challenge is in knowing how your doing good work or crappy work? This is why I’ve created this simple 5 minute ‘Crappy Work’™ ² test to help any tester to figure out if you’re doing crappy work or not. ¹
1) Do I fully understand what I’ve been asked to do?
2) Why am I doing this task?
3) Who will benefit, and I have spoken to them ?
4) Am I doing this task simply because its part of the process?
5) If I think it’s crappy work, how can I make it valuable?
I’m sure there are plenty more ‘crappy work’ questions that would be useful to add, but my 5 minutes is up.
Why not share your ‘crappy work’ litmus tests?
¹ Maverick Tester takes no responsibility if you take this quiz and continue to do crappy work
² It’s a 5 minute quiz because it took me 5 minutes to think it up. It’s trademarked so I can sell you a certificate in passing the ‘Crappy Work’ test, thereby making a whole lot of money out of it.
It’s my first day in permanent employment for, oh, about 20 years. I feel a little giddy, like someone’s first day of school – nervous but excited.
Unlike my first day of school, I have some clear goals and ideas I want to implement. I thought I might outline them here to help remind me of what I want to achieve and also to see how different it turns out.
Testing is an skilled activity(not a phase) that all, to some degree can acquire.
Testers need autonomy to make decisions, to develop and perform excellent testing.
Quality is something we all care about, though it means different things to different people.
Every test has a cost (design, building, maintaining, reporting)
Goals for Testing
To develop a company wide reputation for excellent testing
To develop a test team that is able to handle testing problems with courage, skill and humility.
To coach and help develop the skill of testing with whoever may need it
To identify where testing is occurring and help augment that
To develop and the grow the test team in size, skill and expertise.
To engage with and support the testing community
To acquire knowledge in testing within a continuous deployment, delivery environment
To learn more about functional programming
To be able to identify how to repair code
To work with integrity and within the bounds of what I consider ethical
Jon Bach this morning wrote a post about how we need to be precise in our thinking. Thank you Jon, its a lovely honest piece with lots of wisdom. But it got me thinking how sometimes precision can let us down too.
For instance, we can get fooled into thinking that being precise always matters. There are many situations where vagary(what a wonderful word!) is incredibly useful.
When my husbands asks me how my day was, I don’t reply with “What do you mean by day?”, instead I typically respond with ‘fine’ or something equally inane. What’s important here is not the precision of the question or even the precision of the answer. My husband’s not that interested in my day at all but it’s his way of asking “are you ok?”. My answer though perhaps a little short, is important too, though it’s not really the answer that matters, its the tone of my answer that he’s listening out for.
You see this vagary in software teams that work closely together. Over time, these teams have developed their own language and don’t feel the need to question every definition. Team members pick up cues from body language and follow unwritten rules without much thought. I see this ability to follow such rules without question as a way of building trust. Often teams that work together for a while just ‘know’. They’ve built up a certain amount of tacit knowledge which doesn’t need to be openly discussed.
Unfortunately many of us have, at one point in time, worked in situations where this culture (for want of a better word) is not so healthy. I worked in one such company where open questioning was implicitly discouraged to the point where a developer worked on the wrong story for a whole iteration. I’ve seen many a tester battered and torn from attempting to pull down those unwritten walls of silence and ambiguity.
But what’s important here is we recognise that in certain situations its appropriate for us to be loose in our language. In fact, I often hold off from being precise especially if I’m new to a team or client. Instead, I sit and listen, waiting for ambiguity to bubble up and emerge. This intentioned act of silence allows me to witness rather than be told where implicit assumptions may fester.
So while being able to be precise is an important testing skill, another important one is the ability to identify when and where precision is most required, and when and where we can allow ourselves to be a little more accommodating.