Hiccupps

My QA team operates as a horizontal resource across the company. As you'd expect we predominantly provide our services to the dev team and most often that's for production work, although we do research and prototype projects with them too. But other functions, including documentation, marketing, consulting, operations and IT need test input on a regular basis too. Depending on who's asking, what they're asking for, and the kind of project they're working on, we'll ask for different levels of specificity in the input they give us.  For example: a one-time, ad hoc project to gather some performance data from a trial server might require no more than an email confirming the test envelope and environment and an idea of the intent of the experiment a three-month R&D project which delivers scripts to a partner might have a brief description of the aims, the high-level requirements and any areas which were not addressed a brand new software feature would ...

I'm sure you've worked with people who don't pull their weight. People who deliver sub-standard material when it's too late to do anything other just than use it.  People who find a way to wedge an i into team  and make time - theirs, that they could be doing better things with. People whose shoulders slope so steeply that Jackass have arranged to slide down them naked and greased up. So I'm sure you've enjoyed it ( go on , admit it) when eventually they've got it badly wrong. I'd like to call that feeling mustworkhardenfreude . Image:  http://www.flickr.com/photos/dullhunk/6296553264/  under Creative Commons

It's an oft-spoken and oft-heard lament that the scope wasn't well-defined. Usually from project managers towards the end of a piece of work and usually from QA towards the start. There's no way around it: if you don't define the purview of a project you will very likely compromise it in some way. The usual ways are lateness, quality and budget. As a tester, understanding the feature envelope is important but it's not impossible to test without and you shouldn't be scared or unwilling to try. In fact, even when you do have a definition your first action should be to consider whether it's the right one. I keep two scoping tools in my testing kitbag: a telescope for the big picture and a microscope for the details. You'll always need both. You may be the only person on a project who recognises that both are necessary and is capable of combining the view the two produce. You may be the only person on the project who really wants to look. Image...

As a tester, it's easy to focus on the negative. It's in the nature of what we do. You might not be able to  prove the the software is defect-free but you can, and we do, spend much of our time and effort on looking for the problems that we expect will exist in it. Constantly finding issues can lead you to think that your dev team, your boss, your process, your software, your company, the sandwiches in the canteen, the fashion for colourful jeans and life itself are pointless. You need to find a way to keep those feelings in check. Except for the one about colourful jeans. But how? Listen to feedback from your customers. Talk to your sales and post-sales teams and find out what customers are saying about the software, how they are adding value to their business, which features are most prized, what recent additions have saved them time and effort. Remember that you're in the information generation business. It's your job, amongst other things, to give a bal...

My QA team are observers on all bug and support traffic. They aren't required to respond to any of it or even to read it all, but they are expected to skim it. If nothing else this gives a flavour of where current issues are in the released and in-development builds. But we find it's more valuable than that. It generates test ideas based on customer scenarios, or even asides or expressions of interest in future features. It means that we can provide a more informed user viewpoint for product decisions, alongside our customer-facing colleagues. It's also not uncommon for QA staff to provide information that helps the support staff identify issues. With the overview we get, we can join the dots across the product. We reduce the number of dupes that are filed, we spread knowledge of fixes that may affect repro of other bugs, we often find that an issue that someone has seen sporadically and not filed because they can't repro will be related to another ticket and we...

Testing is like making love ... it never lasts as long as you wanted it to.  Testing is like making love ... once it's over you're the only one interested in discussing how it went. Testing is like making love... well, I'm sure you get the idea. But if testing isn't really much like making love, what is it like? Non-testers can think testing software consists of nothing more than trying a couple of examples and then declaring that "it seems to work OK ".  Finding a simple analogy for the testing process could help to disabuse this notion. Which is where word searches come in. Every year, to show what a great guy I am I spend as little time as possible thinking up some test-related game for a team meeting in late December and force the team to play along. (And they love me for it. Or, at least, they know I'd sack the first one to protest.) One year we taste-tested stollen, mince pies and panettone; last year it was proofing a bogus Christmas card fr...

I like to listen to podcasts on my walk to work and I try to interleave testing stuff with general science and technology. The other day a chap from Cambridge University was talking about entropy and, more particularly, the idea that the natural state of things is to drift towards disorder. Entropy : "Historically, the concept of entropy evolved in order to explain why some processes (permitted by conservation laws) occur spontaneously while their time reversals (also permitted by conservation laws) do not; systems tend to progress in the direction of increasing entropy."  In an ironic reversal of its naturally confused state, my brain spontaneously organised a couple of previously distinct notions (entropy in the natural world and the state of a code base) and started churning out ideas: Is the development of a piece of code over time an analogue of entropy in the universe? Could we say that as more commits are made, the codebase becomes more fragmented and any orig...

Assume and make an ass out of u and me   is how the old saw goes. But when we're testing we're always making assumptions. We can't test everything so we take a view on the least risky areas and test them least. We're assuming that our risk analysis is reasonable, based on whatever evidence is available. We're up front about it - we may even have been directed to do it - and stakeholders have visibility of it. However, often assumptions aren't prominent. This may be because we didn't think it was worth documenting them, or that we didn't even know we were making them. The second set are the more troublesome. We need to be clear in our own mind what we think it is we are doing and what information we think we are going to get from it. For instance, if we're testing a new feature and we think it affects components X, Y and Z, we need to be aware that what we're doing is restricting our test space and we need to state that assumption up...

I ask my test team to be proxy  users. They can and do report issues over, above, outside, around, across and regardless of any spec, convention or any other consideration if they feel that customers will find it an issue. To help to keep the team in step with customer thinking, all QA engineers are watchers on support traffic. (This has other benefits too, but that's for another time .) When you're doing this, especially in exploratory work, you have to be careful not to confuse your user with your self. You just won't have a single model user and, even if you did, the chances of it or any particular user having your own set of behaviours and prejudices is small (although obviously your behaviours and prejudices are the optimal set of behaviours and prejudices to have). So, if you're navigating the product and you like to use short cuts , don't just use short cuts. Take the slow route with mouse clicks too because some of your users will. Hover over all the ...

You're busy and you'd like to squeeze some extra time out of the day without spending more time in the office? You should look for ways to make small repetitive tasks more efficient. I'm not talking about test automation (although that's certainly something you should be open to and looking for) but the kinds of things you do all day every day, probably without even thinking about them. You almost certainly swap between applications under test, test harnesses, email clients, editors, command lines, word processors, spreadsheets, bug trackers, browsers and so on tens or hundreds of times a day. If you're a mouse jockey you probably spend a few seconds mousing to the task bar, clicking on the next application, mousing back up and clicking in the application to get focus. Did you know that Alt-Tab  throws up a quick task switcher? You probably have to edit and run scripts at the command line. Do you find yourself repeatedly opening an editor, editing a script, c...