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...