testjutsu

For those of you (us) whose Japanese reading skills aren’t comprehensive, you might find some valuable assistance with a firefox plugin called pera-pera kun. It is an extension of the also excellent rikai-chan.

It allows you to hover over Japanese words and phrase fragments and get a popup with dictionary / grammatical meanings. I couldn’t do without it.

You can find the plug-in here
and the required Japanese dictionary here

I believe there is also a Chinese dictionary out there, don’t think they do hangul (sorry Jared   )

For those that are studying Japanese (or anything where flashcards are useful, really), check out Anki.
I am creating my own study deck, but if you want to dive right in, there are a bunch of pre-made decks available and plugins if you like that sort of thing.

I wish I’d found both of these years ago. Seriously. Hopefully they’re handy for some of you.

Clearly I’ve had it far too easy for the past 10 years. Working for internet-based companies with unfettered access to install whatever I like on my machine, all the internets I could eat, complete control over my testing environment(s).

I have a question for all of you who have in the past experienced complete machine lockdown in your role as a tester (or developer or similar). Imagine the following completely hypothetical situation:

You need to install stuff on your local box, but can’t because you don’t have privileges. Getting stuff installed on your box requires going through a cubic buttload of bureaucracy and can literally take 3 weeks. No (instant or semi-instant) comms with the outside world, disabled USB ports, the works. Does this hypothetical situation sound familiar to anyone?

Does one

a) Politely request that ones machine (and the machines of one’s team mates) be unshackled and cite decreased productivity as a reason (and possibly offer to instead abide by a set of guidelines that are reasonable)?
b) Rant against the concept of treating intelligent adults like naughty children or criminals?
c) Say nothing, but add a couple of weeks per app one may need to install to project test estimation?
d) None of the above, but something awesome that I have neglected to mention here?

Teh Google shows a lot of hits for people who are in favour of lockdown. Guess it’s okay when you’re on the other side of the fence. I found a few articles that were in favour of trusting users – I enjoyed reading through the comments here. I think it comes down to finding (begging for?) balance. I know not every user out there is savvy enough to stay safe on the internets, but there are plenty that are. Why should they suffer?

I’m interested to hear how people have handled this situation and what the results were.

It’s funny how one word can have multiple meanings. I’ve been thinking about this a lot lately in relation to learning Japanese, and especially Japanese grammar where identical grammatical structures can have quite different meanings depending on context.

There’s also an English word that’s been bugging me a bit lately. The word ‘just’ can be an awesome word. It can mean ‘fair and honourable’, or ‘precise or exact’, but I’m not so much of a fan when it is used in the following sentence fragment – ‘You’re just a tester…’

It often is accompanied by phrases or questions like ‘you wouldn’t understand’, ‘you don’t need to worry about that’, ‘what are you asking about that for?’, ‘you don’t need access to that’ or ‘what do you mean you should be paid as much as a developer?’

As grating as the assumption that you’re not techie enough, or that anyone can do your job (or similar ignorance) may be, my advice is to not take it personally.

I could choose to feel insulted, but I don’t. It generally means to me that I have to help educate someone. I’ve heard it from developers, project managers, salespeople, executives, all sorts of people who think they have a handle on what it takes to be a tester. It may be that their previous experience has been a negative one with low-skilled testers. Maybe they have no experience with testers at all and are going on assumptions and second or even third-hand information. Whatever the reason, it is clear that their understanding of software testing is framed differently to mine.

Sometimes, a short conversation on what our differences in understanding are is all it takes, but if someone has the idea firmly in their head that testers are (just) monkeys that click on stuff toward the end of a project, you’re probably going to have to be a little more hands-on in demonstrating your value.

Find out what they think your limitations are, then find a way to add value that goes above and beyond what they’re expecting. At the start of a project, analyse the design and put together a risk analysis (along with what can be done – not just testing – to mitigate them). Are there unit tests or other automated tests you can review (and possibly improve)? Have developers put their money where their mouth is with Mike Kelly’s 5 bugs in 5 minutes challenge (PDF link – see page 5).

You might demonstrate the value of exploratory testing by conducting a paired testing session with them. What you do will of course depend on your own situation. Be proactive about it though. You can point them at blog posts and pdf links all you like, but until you actually demonstrate to them the value of a tester in a way that they’re going to notice or care about, you’re just going to have to deal with being thought of as ‘just a tester’. You might not have created the situation, but if there are people (who matter) whose point of view needs adjustment then the onus is on you.

and shall be for the forseeable future.

I’m working with an insurance group, putting together a new software testing team. Can’t really say too much more than that. There’s a lot to do, but I have good people with me and I’m up for the challenge. I’m also a lot closer to the bottom of the kendo food chain than I’ve been in a long while – I’m enjoying that too.

That’s not to say it’s all beer and skittles. The Japanese language is kicking my arse at the moment. When I speak, I get the sorts of look people reserve for a particularly slow child. That’s okay. I’m weathering this punishment much like a caged animal endures a beating, knowing full well that one day the lock will fail, or someone will get careless and then I shall make the Japanese language my whimpering bitch. Oh my, yes.

I may even torture you all with attempts at translating local testing literature. I will probably learn Japanese testing terminology. You will probably just learn to hate me. More. That’s okay, you can tell me all about it at the next conference I get to. Buggered if I know when that will be, though. I’m hoping CAST later in 09, but travel is all a bit up in the air at the moment. Should have a better idea toward the end of Feb.

In the meantime, the intermittent drivel and Vogon poetry shall continue forthwith. Enjoy.

Besides also getting to hit people with a stick? Plenty – eventually.

As a beginner in kendo you generally start by learning the body mechanics, repeating the same movements over and over while your teacher continually corrects you on what seems like an endless stream of minutiae.

It’s tough at this point – you’re not quite sure why you’re doing what you’re doing, and you can see off to one side the more experienced students spiritedly attacking one another in what looks like a free-flowing and even random manner, and you wonder if you’ll ever get there.

Gradually though, your body learns and you start to understand why your hands and feet must move just so. Eventually you strap on the armour and it’s like starting over again. Your hands feel weird holding the shinai through your kote, your field of vision is restricted by the men gane, and when you finally add an opponent into the mix, it adds a whole new element to the entire dynamic. Having someone screaming at you and trying to hit you with a stick is not what we usually identify as an environment conducive to learning.

At some point down the track, you face off against someone and your body knows what to do. You have internalised the body mechanics your teacher spent months drilling into you, leaving you to explore how to implement it. You attack your opponent. Sometimes you’re successful, sometimes not. Sometimes they counterattack. Sometimes they confound you with their ability to evade even your most spirited attacks.

The day you achieve a real connection between you and your opponent is the day a new world opens up to you. There comes the realisation that knowing how to strike is not enough – more important is knowing when and why. When you achieve that connection with your opponent, you engage them in a battle of wits and will.

There is an ebb and flow to a match. You can feel it when you have the ascendency, when your opponent does and when it’s in the balance. You engage in a chess match to outmaneuver and outwit your opponent in order to strike them.

Eventually, you realise that a strike is successful not because you have hit the target, this is only a physical manifestation of success. The strike is successful because you have won your chess match and like the final move of a chess match, by the time it happens, there can be no other result.

If you like physical activity and you like to use your brain, then you’ll probably enjoy kendo. I was contamplating adding a software testing analogy in here, but what the hell. You software testers out there can draw your own parallels.

Things have been (and remain) a little crazy right now. A slight misunderstanding with my site host has added some further unrequested fun (they misunderstood how to bill my credit card apparently, despite having done so before – and shut down my site).

I’m in the middle of a move to another country, so unfortunately blogging is not at the top of my list right now – which is unfortunate because winding up at my current place of employment has left me with rather a lot to say.

The actual move is a month away, and then there’s the whole settling into the new job thing, not to mention everything else that goes with packing up and then unpacking your life several thousand miles away. In all likelihood it’ll probably be another 6 weeks before I am in a position to put more words here. At some point a 10 hour flight will be involved, so that may provide some opportunity – that reminds me – note to self – buy noise-cancelling headphones.

Anyway, that’s me for now.

Jeff Atwood recently wrote a post about phases of software development/release. He wondered where the terms come from and why we rarely use ‘gamma’ – I wondered if these terms actually have any relevance to what actually goes on in software development anymore.

To me, these terms are used to broadly group stages of software stability as simplifiers to people who don’t necessarily understand the finer details of software development (or don’t particularly want to). These labels seem to equate these days to marketing wank for shops that still do big design up front. It’s easier to say ‘we’re at alpha release’ than saying ‘we’re two-thirds feature complete with no current showstoppers, have a bug trendline that indicates a find-rate approaching zero and we’re satisfied that testing to date has adequately mitigated the risks identified so far’.

My issue with these terms is that they oversimplify a process that should be viewed as difficult. Alpha/Beta/Gamma (or whatever other pre-release signifiers you like) imply a linear, production-line progression of software. Anyone that has worked on any project of significance knows that the development of software is anything but. I worry that this oversimplification helps tie us in to a flawed mental model that invites us to fail over and over again.

There is no guarantee that half way through ‘beta testing’ your testing team won’t find a showstopper that requires you to go back to pre-alpha. How well does your ‘A->B->Ship it’ model stack up then? It seems that because we have this simplified mental model of development, decision makers think that a) we can reliably estimate up-front the time and budget required to put together complex systems and b) when, close to completion neither of these estimates prove even remotely accurate, makes them insist on kludging their way through so that the immutable ship date can be met.

The problem with this mental model is that while it probably works well for automatons that churn out identical widgets time and again, software development is not that. Software development is about human beings turning out solutions to difficult problems in a non-uniform manner. Human beings each with their own individual strengths, weaknesses, passions, neuroses and everything else that makes us human. The fact that these people are not producing identical widgets day in, day out means that the production line model is entirely inappropriate, as is the model of big design (and estimation) up front.

This is a can of worms that you could (and some have) write a book about. Entwined with development is software testing. Another very challenging craft done by humans. Testing is an oft-misunderstood profession. The alpha/beta/ship it model doesn’t help. I worry that this model locks people into thinking that testing is something that happens once the developers have finished doing what they do, at which point the testers are left to find whatever bugs they are able to in between that point and the shipping date.

Then, depending on the nature of the project and the people they’re working with, they’re possibly blamed for finding too many bugs, or flaws that, if properly fixed, would extend the length of the project well beyond the date where the PM gets his nice fat bonus for bringing this thing in on time. The PM shoots the messenger because what other choice is there at that point?

This is a stupid way to make software. This is a stupid way to think about making software.

Scrum appears to be intended to make transparent the human issues that crop up in software development and it sounds great in theory, but I wonder how many software shops are prepared to invest in the up-front discomfort of changing over and are prepared to have (on a daily basis) the open, honest and frank dialogue necessary for a framework like that to work. My guess is not many. This is perhaps a subject for another post.

If you want to be an extremely effective software tester, I highly recommend you do something else. Really. I’m not talking about being able to complete Halo3 in world-record time. Specifically I mean you should find something that you are passionate about; that takes practice and perseverance to become proficient in, and then master it.

I’m not talking about ‘I have nothing more to learn from anyone’ arrogance. Anyone who has mastered anything knows there is always more to learn. Always. What I mean is that you should do it at least until you can confidently teach someone else without fear of leading them astray.

Things like playing a musical instrument, speaking a second language, ikebana, playing golf, it doesn’t need to be remotely testing related or even related to computers. It may be better if it isn’t.

There’s something interesting that happens when you master an art. You can recognise that same mastery of something in others, even when what they do is completely different. When you understand the sort of effort required to reach a certain proficiency, you tend to appreciate it wherever else you find it. There is recognition too, of the many stages of learning one goes through on the way to mastering something. You see it in others because you yourself have been there.

How do you recognise that same thing in others? Because once you have mastered something, it reveals itself in everything that you do. Your experience cannot help but inform you about other things, and influence the way you take action.

How will that make you a better tester?

If nothing else, it will make it easier for you to play the simile game. X is like Y. It’s an effective way to learn something new – relate it to something you already know well. It can give you a different way of thinking about things. Paradoxically, any art worth mastering will have concepts that are unique to that art, that don’t directly translate into anything else. Opening your mind to new concepts can help you look at testing problems from angles you may not otherwise have considered.

Recognising various stages in learning allows you to become a better teacher. If you can recognise where someone else is along the path, you can more effectively tailor your guidance to be more meaningful. There’s no point talking about concepts they’re going to have no clue about if what they need is a simple, straightforward explanation that leads them to a deeper understanding.

So I maintain that if you really want to become a great software tester, be great at something else.

In testing, I think there is a tendency to confuse repetition for the purpose of learning with repetition as the application of skill. I have heard that some expound using scripts as a means of skilling up unskilled staff. I believe this thinking is fundamentally flawed. The reason being is that there is no clear delineation between the repetition of an action (i.e., a script) and actual software testing, which is far, far more than simply following a recipe.

In kendo, a beginner starts by learning the basic moves. A student might practise a single cut 10,000 times or more. Time and again they are made to demonstrate correct footwork, body position, striking and movement. At this point, they have no clue about the application of these techniques, only how to execute them. They can make a cut, but it doesn’t mean they can consider themselves skilled in kendo.

Once they have the basic mechanics down, they are ready to strap on armour and face a real opponent. Unlike before, where they had specific instructions about what do do, how and when, they now face a situation where the application of their techniques may or may not work and it is up to them to work out why. Moreover, their opponent is attacking them, shouting at them, trying to unsettle them, make them nervous and throw them off their game. Are you software testers out there seeing parallels?

The difference here is that the delineation in kendo between learning basic technique and application of that technique is quite explicit. In software testing, especially where scripting is involved, this is not always so. Herein lies the danger of using scripts as learning tools. A script may help you learn to execute a technique. It will not teach you to be a tester.

So I’m back from CAST. Yes, I know I haven’t finished writing up my notes from the CITCON event. I had every intention of doing so on the trip home, but 30 hours stuck in planes and transit lounges with screaming children, people with questionable personable hygiene and vapid narcissists who need to share with everyone within earshot is not conducive to cogent writing. The good news is that I’m not in prison for visiting bloody ruin upon any of the aforementioned human vermin, and hope to return you to your (ir)regular programming soon.

So, CAST rocked. Toronto was a cool place. The local people were, if not friendly then at least not aggressively disinterested (apart from a bartender at the Imperial, who was a total douche). The attendees of the conference were amazing human beings, if for no other reason than their eyes not glazing over when I was talking about testing. Some really bloody smart people there doing some very cool stuff.

I took the day-long tutorial with Jerry Weinberg on communicating as a tester. The cost of the course was probably worth it for this alone. There were keynote speeches by other big names in testing, which were also very good. More importantly though I think were the people I got to hang out with. I think it takes a particular brand of weirdness to be a good tester. There’s a certain pattern to the way they speak that gives you an insight into how they think. Testers aren’t afraid to probe, or question either so I also enjoyed the distinct lack of listening along politely.

I have more material to write up than I know what to do with. I have a busy few weeks coming up on the kendo front, so I’m not going to get to it as soon as I want to, but it’s coming. In the meantime, check out the CAST site conference archive. If you’re considering going to next year’s, it’s in Colorado Springs. I highly recommend it. I shall be doing everything in my power to make it there. If you have any sort of interest in software testing, I urge you to do the same.