One of my first recollections of physics is the image of Archimedes running down the street, dripping wet from his bath and shouting: “Eureka I found it!” on discovering his principle of fluid displacement to measure the force.
Add to that Isaac Newton who quietly sat under an apple tree, musing the day away until he discovered his laws of motion, one which states;
For every action there is an equal and opposite reaction..
Many companies want to improve their testing, particularly if that improvement is translated into reduced time or cost.
To achieve this, there’s a big trend to embed testers into development teams. There’s no longer ‘us’ and ‘them’ but an harmonious ‘we’. The wall of independence is torn down replaced by a gleaming whiteboard emblazoned with the banner ‘Quality is a team responsibility’.
The reality though is that just like Archimedes in his bath, or Newton and his Apple, embedding testers into a team of developers is going to create displacement and cause a reaction.
This is common sense. Put one tester into a team of multiple developers and it’s going to change the team dynamics. Add to the mix, that the tester will most likely become a point of constraint disrupting what was perhaps a seamless flow of stories into the Done column and it’s no wonder the apple cart gets upset.
For example, developers discover they need to get more involved in testing and decision making.That can be a big mindset change if traditionally developers are used to handing work over to testers (as opposed to receiving it from them).
Testers need to change and adapt too. They have to let go control over all the testing and entrust the developers to help them test. Again big mindset change for testers who traditionally rely on empirical evidence than a developers word to evaluate quality.
Why then, do we seemed surprised when we face resistance and/or confusion when these changes are attempted?
This is our brave new world. I wonder where we will all end up? Wether a team develops a true and meaningful relationship or simply an uneasy alliance is I guess up to how much both testers and developers are prepared to appreciate each other’s challenges.
One way we can help each other out is to be supportive as opposed to defensive when people face the impact of changes and perhaps feel displaced and confused. How much we are prepared to let go our assumptions and prejudices about each other will also play a big part in how ‘successful’ these experiments are deemed to be.
Exciting times indeed!
Oh tester why dost thou despair?
The code is right
of this we are aware!
We verify. We know what we do know
No need to doubt and think of all this woe!
Instead be bright and bring us certainty,
Let Done be Done, thus ends this homily!
Does the thought of ‘dropping the ball’ fill you with dread ? Perhaps you feel you will let people down, or more importantly yourself?
Here’s a thought experiment: What if you actually let the ball drop? Do you know what might happen? Will the sky fall? Are people let down?
If so, is that so bad? We all fail at some point in time in our lives. We don’t expect perfection from others, but for some reason expect it from ourselves. But that’s not physically possible is it? Expecting perfection in this way is about as practical as promising perfect software right?
So next time your spreading raspberry jam too thinly consider giving yourself permission to drop the ball. After all as a tester you owe it to yourself to try, don’t you?
Apologies for mixed metaphors 🙂
My family and I arrived in Dublin on a cold dark wintry November night in 2008. At least metaphorically speaking it was. It was right after the GFC and we watched a country and economy wrestle with the prospect of becoming bankrupt. Regardless, Dublin’s IT and entrepreneurial spirit flourished. People who were made redundant invested their expertise into new ventures. There was a sense of familiarity in being in a recession (The common term for the GFC was recession 2.0) but also that the future was very much up to themselves.
I decided to start an Irish testers meetup, an opportunity for testers to share their expertise and learn from each other. Our first meetup had 4 testers. It never grew beyond that. I discovered that there was more to running a meetup than post on a blog. I learned that testers cannot thrive on testing alone, and that having a nibble or two and a drink goes a long way to attracting turn out. Having noteworthy speakers also helps.
So when I returned to Australia in 2010, and heard of a Sydney Testers Meetup I was keen to join. I discovered a hardy band of testers. Amongst them were Trish Khoo, Marlena Compton and Bruce McLeod. But they had similar problem as I had in Dublin. It was hard to get the word out and attendance was poor.
Sponsorship by Softed and getting some few heavy hitting speakers quickly changed that. We had James Bach, Elizabeth Henrickson, Scott Barber come along and speak. Trish has fantastic ideas about different types of activities. We had games nights and book nights. Julietta Jung came along and brought along enthusiasm and excellent pizza ordering skills.
The Sydney Testers Meetup rapidly grew but not without its ups and downs. We’ve lost sponsorship, turned down sponsorship and for a while lived without any sponsorship. We had have committee members move to far away lands. But throughout it all we managed to maintain the spirit of the Sydney Testers Meetup. Today Attribute Testing sponsor the meetup that has a 600 strong membership.
It’s time now for me to hang up my boots as organiser of the meetup. It’s been a blast and I’ve loved seeing people become infected by testing. I’m leaving the STM in safe hands. Richard Robinson and Devesh Maheshwari will be taking over as organisers. I wish them the best and look forward to seeing the STM do great things.
Ever been in a long car journey packed with young kids? I remember these eight hour drives with six kids crammed into a car driving to our holiday destination. My younger brother in particular was annoying, constantly asking questions and irritating his sisters. By far the most irritating question (especially to our parents) was: Are we there yet? This line of questioning would normally begin half an hour into the journey, and would be constantly repeated throughout the journey.
This potent cocktail of repetitive questioning usually resulted in one of my parents (usually my Dad) exploding in frustration, yelling at us all to be quiet. This was typically followed by a threat of being dumped on the side of the road. (He actually carried out on his threat once, dumping my brother, who unfazed promptly hid in some nearby field, resulting in the whole car load having to search for him.)
But it was a fair question from us kids. We had no real sense of time or distance to help gauge how far we had come and had to go. We also were totally bored with no iPods or stuff to entertain us. Singing (very Von Trapp like) took us only so far. Counting number plates helped a little. And remember, we were going on holidays, the mere thought conjured up more excitement than our poor little bodies could hold. The journey was always going to be arduous when faced with a destination the held so much promise.
As a parent myself, I have a little more sympathy for my parents. Of course, we have the luxury of allowing our kids to be immersed in some tacky iPod game, distracting them to the point they forget they are going on holidays. But I get it. I get that its really hard to explain to someone with little understanding of distance or time, how long something is going to take.
When testers ask me how we know when we are done in Exploratory Testing, I am faced with a similar challenge. How do I help a tester understand when they are done? Pointing them to the excellent list of Stopping Heuristics on Michael Bolton’s blog helps but how do you apply them? Some of them are easier than others. For example, with the “Time’s up!” heuristic, its pretty simple to apply. But take something like the Flatline Heuristic. The Flatline heuristic tells us to stop when “No matter what we do, we’re getting the same result.” But as Michael points out, there are hidden risks to this. For example, it may be that there is no new information, but it also may mean we are insufficiently explored the application in depth.
In this situation, how do we know what to do?
Like many things in testing, there is no clear cut answer to this. A considered answer requires an understanding of what’s happening around testing, and the implications of the decision being made. Hence the inclusion of the word heuristic.
I’ve found a conversation with stakeholders around stopping heuristics *before* testing starts a useful exercise. Knowing that you have a time limit on your testing goes a long way to preventing tester angst about when to stop. Include in that conversation a discussion on what ‘done’ means including into that the impossibility of complete testing. Stakeholder who get that bugs may be missed can influence which stopping heuristics you use.
Like kids in the back seat, as we test we need to repeatedly ask ourselves the question “are we done yet?”. It may be useful to use our emotions to trigger this question. For example, if I’m bored, does that mean I’m done – or does it mean I need to change something in my testing? If I’m anxious does that mean I’m about to hit some constraint in the form of time? If I’m angry, does that mean my information is being ignored and maybe I need to address that instead of raising a tsunami of bugs. If I’m confused, does that mean I need to explore more? Emotions like these can be useful indicators of when to ask if your done. Again Michael Bolton has done lots of work in this area.
I’ve also found that in times of deep uncertainty its always a good idea to draw on the “phone a friend” card and ask someone more experienced than you for their opinion. There’s no shame in this, these are tough questions to answer. An outsider may have insight or additional knowledge that you’ve overlooked.
Building relationships and credibility with those around will also go a long way to helping you in situations when that significant bug is missed. And as in most of testing, articulating your process and your decision making helps to demonstrate diligence and considered testing.
Michael Bolton tweeted yesterday:
Testers: let’s not obsess over trying to be influential, and work on being helpful. And let’s be careful to offer—not inflict—help. #testing
— Michael Bolton (@michaelbolton) October 16, 2013
Why do testers insist on trying to be influential? I suspect part of the reason is that part of a tester’s job is to recognise problems. Too often , testers see that the *real* problem is not the software itself, but the process behind the software and go into bug prevention mode. That sort of change requires influence.
Often though, we simply don’t have the authority or the influence to do make change. We may moan and tear our hair out in frustration, but at the end of the day, without the mandate to make change and the influence to implement it, there’s little we can do to change an organisations culture or process.
Trying do do so regardless, can lead to a sense of helplessness and even slowly, over time, a sense of powerlessness. I suspect most of us at one time or another have felt like this. It’s not a great position to be in.
I know I’ve been there. I tried to change the culture of a company (company no less!) that had some negative ideas about testing and teamwork in general. (I’m talking about this at Eurostar this year). As a consultant, I probably should have known better, but I argued (to myself) that the culture was affecting the tester’s ability to perform their job. It needed to change!
We testers are gifted with keen observation skills and the nature of our role sometimes means we get to see and recognise problems that perhaps others don’t. But lets not get away with ourselves. Without a mandate for change, we become close to the schoolyard tale tattler, dobbing in on everyone and despised by all (including often the teacher). I failed to recognise that I hadn’t the authority or the influence to make these sorts of changes. I fell into a classic consultants trap. I really should have known better.
It’s not that we *should* or *should not* ignore these problems. Often these challenges are too complex to be solved with simple answers and probably need to be dealt with on a case by case basis. But I think adopting the tone of helper (or servant) goes a long way to contributing to an answer. In some cases a question sprinkled with a little humility can be more helpful than smothering the problem with large doses of tester sauce.
I hope I’ll remember that next time!
I wrote this email to Helen today who emailed me a letter seeking work. I thought it pretty much summarises what Testing Times stands for.
Thanks for contacting me through my website.
Firstly, I want to congratulate you. Not many people bother to read my website properly and send me the information I require, my estimation of you as a tester as increased a notch!
I purposefully ask testers to only send me a cover letter explaining why they want to work for me. Most testers send in a resume.
Testing Times is not a typical software testing consultancy. Based on many years of experience, we’ve come to realise that the majority of testing performed is rubbish. Unrealistic schedules, stupid estimations, test strategies and plans that no-one reads or cares about, metrics that make no sense.
We’ve decided that enough is enough, and we will only perform quality testing. If this type of consultancy interests you read on.
We see ourselves as context driven testers (google and read up) and we believe this is one way to promote quality testing.
Be aware, we only work with truly passionate testers. This doesn’t necessarily mean lots of technical proficiency, but we expect you to have studied testing, read blogs and have an opinion on what quality testing is.
If this sounds like you, send your resume in!
Its a rare luxury this week as I have the house to my own. Perhaps those of you with partners and or younger kids will identify with this sentiment! Suddenly life seems to be easy and manageable. I don’t feel responsible for looking after other people and their problems. The challenge to manage a house, be a mother and partner, run a business, organise a conference and oh yeah, do some testing is a lot easier when its only yourself to look after!
When I took PSL last year, one of the ‘skills’ I realised I had was running around making sure everyone on the team was being heard and was ok. Another word for this is meddler. How, I thought could the team function without me, unless I was there to keep it together?
I guess after reading the first paragraph again work isn’t the only place I fall into meddling.
In a moment of retrospection, I feel my desire and ability to solve problems is sometimes more of a curse than an asset. Perhaps in my drive to solve problems, I forget something crucial. That is, often it’s not about solving a problems its about having the conversation.
Earlier this year, Michael Bolton introduced me to Marshall McLuhan and his concept that “the message is the medium”. Is it possible then, that solving a problem is not as important as the process used to solve the problem? Or in other words, the conversation you have to solve a problem, is more important than the resolution of the problem you are having?
A while back I read David Bohm’s book “On Dialogue”. In it, he encourages groups in dialogue to take the focus off decision making and instead put the emphasis on the process of communication.He encourages participants in the dialogue process to suspend judgement and be open to what emerges from dialogue. In this way a group can develop deeper meaning. For example, instead of trying to create a common terminology, common terminology becomes created.
He also talks about the challenge in problem solving. Mostly, what we call ‘problems’ are in reality paradoxes and inherently its impossible to solve such ‘problems’. Bohm believed that the dialogue process(I haven’t tried it) is a way of acknowledging and respecting differences allowing new ideas to emerge.
We all have a basic need(well I like to think we do!) to connect and understand each other. To be *human* if you will. Its this human need, at a tacit level that perhaps defines who we are, more than any high level problem solving skill dictated by our frontal lobes. As an engineer, I’m taught communication is essential to solve a problem. As a human, I’ve learned that its about taking the time to include people in your day, to actively listen regardless of the outcome.
Just a thought.
I went and visited one of my clients yesterday. Its been a while since I helped them and I wanted to catch up on where they were at.
As it turns out, this company has been going great guns, building their testing from zero to three testers. However, growth often means pain, and this particular company had some pain points. I knew there was something I could do to help.
They also wanted help in recruitment. Now, this has always been a bit of a sore point for me. While I want to help my clients, I’m not a recruiter. On the other hand, I know many testers who want to do interesting work. Could I add value here?
Well, it turns out I could. But its not the value I’m particularly interested in offering. I’m a consultant, trainer and coach. I advise people on how to improve their testing. Instead, I pointed them to the best recruiter in Sydney, Catherine Karena to help them out on recruitment.
They also wanted help in offshoring, so I pointed them to the best offshoring company in India, Moolya.
What financial gain have I made out of all this?
Nothing. A big fat zero.
Yes, that’s right. I made no financial gain from this event. In fact, you could argue I lost money, if I take into the account that I spent an hour of my time speaking with a client.
I know, that many will argue that I could have rightly skimmed off the top of these introductions. After all, its common (add some say good business sense) to add a percentage on top of these deals, in lieu of the introduction. After all, new leads are like gold dust in this industry
I got something out of it though, you know it did, because I probably wouldn’t be writing this post if I didn’t.
Saying no has given me strength. I’ve put my foot down, and said “value matters”. That feels good. That feels right.
Making a fast buck? Meh! Knowing what you stand for? Priceless!!