I’ve been playing with some new toys lately.

First off, completely unrelated to testing, but I picked up a 24-70mm 2.8 L II lens a couple of weeks ago. It’s been amazing – incredibly sharp lens, beautiful images. For full goodness I’ll need a full frame camera (currently running on my awesome 7D) but that can wait.

Software related toys, I’ve come across Asana after reading about it on Rands in Repose. Looks like something I could use. I’m after an information radiator type tool for the various teams of testers where I’m working and this, coupled with Sprintboards (with a side helping of Instagantt for scheduling and tracking) looks like just the thing.

Oh yeah, the new gig. It’s working out better than I expected. Very much enjoying myself, even in the face of some “interesting” environmental issues. More on that later.

As I sit here in a new office, two weeks into a new role which I’m enjoying, wearing shorts and a t-shirt on this stinking hot day… I can’t help but think back to a time in another job when the corporate policy was white shirt and tie in the office regardless of how hot it got, working for people I wouldn’t piss on if they were on fire and generally not having much fun of it.

The words that immediately come to mind are “Suck it, shitheads” but I realise that would be uncharitable.

Meh, fuck it.

Mind mapping

I like to use mind maps for, well, lots of different things. They’re handy as I build a picture of a new testing project, developing test cases, fleshing out test ideas, overhauling the approach, whatever. Start with a central idea and grow outwards from there.

Mindmup is a free online tool for doing just that. Quickly, easily, and you don’t have to worry about installing anything. Get on it.

5 Things to Remember When Writing Test Cases

When writing test cases for your project, it’s often easy to forget what is important. This article is aimed at reminding experienced testers or informing new ones of what the key items are, to ensure we are being efficient in writing our tests.

The End User is Key

Who will be executing the test scripts? Will the scripts form part of a Regression Pack? Will the scripts be used for anything else (e.g. training manuals)?

These questions are meant to kick start your thought process. Essentially, the person who writes the test is not always the person who executes it. As such, Test Cases need to be written so that anyone of any level can read, understand and be able to execute the test case. The aim of this is that no matter the level of the tester, the outcome will always be the same. When writing your test, if you approach this with ‘baby-steps’ in mind and make no assumptions that the person who executes it is has any prior knowledge of the project, and you shouldn’t go far wrong Continue reading

Dribs & Drabs

Been a while since I posted. I’ve started and stopped two entries because I couldn’t get the prose right. This is just a quick post of various dribs and drabs to provide a placeholder. I might get around to building one or two of these things into full posts.

Note to sensitive readers (why are you reading this blog if you’re easily offended?): Language warning ahead.

Continue reading

Destructive Testing

Apple’s example of a Security flaw in their iOs v6.1 shows us why negative and ‘destructive’ testing techniques should be considered when compiling your test plan and test cases. If you want to read further info on this, find the article on ZDNet here.

Whilst testing the ‘happy path’ scenarios bears fruit and proves that the software is performing as expected, it is the negative scenarios that exercises the code in order to build rigidity and stability.

Continue reading

JIRA Test Management

Generally speaking, JIRA (from Atlassian) sucks for test case management. I hope I’m not telling you something revolutionary there. Unfortunately what I’ve seen this lead to is for testers (and leaders and managers) to decide the best solution is to simply use QC or ALM. A solution looking for a problem bound to lead to a need for more solutions if I’ve ever seen one. To those wanting to do this: No. Stop it. Bad manager. No cookie.

It might be less of a problem given that HP is now making connectors for a number of IDEs to allow QC/ALM to talk to everything in Development land, but cost is usually the number one complaint with HP’s testing products.

There are easier (not to mention VAHHHHHSTLY cheaper) options available. Instead of going down the HP path to financial ruin, consider using Zephyr, available from the Atlassian Marketplace. There’s a nice eight and half minute demo video available at YouTube that will give you a quick intro to its capabilities.

Combine this with Bonfire for session based testing and you have a pretty powerful suite of tools for quite a reasonable price (Zephyr starts at $10 for 10 users – this includes maintenance and support for a year).

What’s this Agile thing and how do I test in it?

There’s quite a bit of work at my current employer regarding agile testing. What some might see as a part of the overall test management process others see as a discipline requiring its own focus. I’m getting to the point where I don’t give a shit (I originally got a little ragey about the whole thing which wasn’t helping so I decided that if you can’t beat ‘em… arrange to have them beaten) but I think what matters is how testers fit into an agile team. I don’t think we need to be focusing on what Scrum is or how a retrospective works or what do we do with these cards with all the writing on them. Instead we should be focusing on getting shit done. How do we do that? Try, fail, try something different, succeed, refine, repeat.

What should be of most interest to testers is how do we go about testing in a team that’s doing some variant that at least looks a little like Agile rather than waterfall. Given this context, I’m always on the lookout for anything to make the job a little easier. Rather than reinventing the wheel I keep an eye out for what smart people have already done and look for ways to adapt it.

The good folks over at Ministry of Testing have put together a set of useful resources. One of these is the image below:

agile testing mindmap

There’s a lot to absorb there. The image is worth printing out on a large sheet of paper and sticking to a wall somewhere close at hand when you start looking at the project from a testing point of view. It needs to be easy to get to because you’ll be adding your own notes to it sooner rather than later.

I’m tempted to rush into this and talk about areas that interest me specifically, but I think that’s for another post.

The mindmap even goes into