Upon reading Paul Holland’s blog post entitled ‘Functional Specification Blinders’ (found here: http://testingthoughts.com/blog/185), I harkened back to all my past test experience and realized that this was the main source for all my test plans, test cases or test ideas.

The functional spec document is the ‘bible’ for the developers. This is everyone’s main focus of attention when developing a new feature. If your developer(s) are solid and the spec is well defined and complete, it kind of makes sense that the solution should be fairly solid based on what’s in the design document. Kind of makes you question why tests are based solely on these documents – is there real value in that?

If you think about it, the functional spec is constantly reviewed by multiple stakeholders and SMEs, reworked and re-written continually. The solution is demo’d and goes through many variations of testing (CAT, UAT, etc).

It does make sense to expand your test ideas and strategies beyond what’s solely in the design/functional spec document. As Paul suggested, it may be a good idea to come up with ideas prior to even reading the spec.

This is not to say the spec should be ignored. It is an invaluable tool in testing the feature, particularly if you are thinking of writing regression tests.

Just do not make it your sole focus…

Ahh, the dreaded test documentation question…

Ask yourselves these questions:
1. Will anyone else really read this?
2. Does anyone care about what I’m writing (see also #1)
3. What level of detail do I need to go into?
4. Who is my audience?

There are many other questions you may ask yourself. I find I ask myself these 4 questions each time before I document something.

If the answer to #1 or #2 is ‘No’, question why you do it, and what is the purpose. After all, the more time you are spending documenting about what you are, or have been doing testing, the less time you are actually testing!

The answers to #3 and #4 will often vary on what the documentation is. Is it a test plan, test idea, test charter, test session, requirements test, regression test, bug report, etc? Try and think about who may/will read this and write them up accordingly.

Asking yourself these questions before you start typing away, it will help save you some time, clarify what you are trying to say, and better target your audience.

We’ve all worked on those projects that did not go so well. Constantly changing requirements, designs that continually changed, not enough time was allocated for development and proper testing (improper estimations). You do what you can to try and make the project succeed, and in the end you learn a lot, and can take away from these projects that you did your best.

We’ve all worked on those projects where you, the tester, were an integral piece. You were involved from the onset, providing great feedback and advice. You found ‘tons’ of defects and helped direct change in designs. You helped meet all the deadlines. Ahhh, doesn’t that feel great to be a valued and important member of the team!

Now, how about those projects you are on, where it feels like you don’t have much to add or contribute? The designers are top notch, the requirements are written in stone, the developers on the project are world class, the project manager is on top everything, there is adequate time to complete all the work. You are writing up and executing test plans and testcases like crazy, you are using every testing technique you can think of to try and uncover hidden bugs, you are trying anything you can to show you are a valued member of the team. Nothing… Nada. Not a significant bug to be found (darn you developer whiz kid!). How are you going to report to your manager that you did not find a single defect or perhaps a couple extremely minor ones!? How are you going to feel worthy!?

The answer… don’t sweat it! Enjoy it! Your job is not to find bugs, it is to observe the system and question it. These kind of projects may come from time to time, but are certainly not the norm. Be confident of what you did, how you did it, constantly learn and most of all take pride in your efforts. Maybe take that developer whiz kid out and buy him a beer for being so awesome (or soda if he really is a kid).

I once worked at a place where the mandate of the testers was to find defects at all costs, and to essentially celebrate and do a happy dance when they did. That was the way they felt worthy.

Do not fall into that trap.

Glad you asked…

I was trying to think of a clever name for my blog. I was thinking of what we as software testers do. I was thinking of how we relate to the old gunslingers of the past who ‘shoot from the hip’. Ok, so maybe we don’t have the cool hat, chaps (although there was that time at a Halloween party a long time ago), a gun and the whole danger element (ouch! paper cut), but we do tend to shoot from the hip alot in our daily lives as testers.

Whenever we have vague and constantly changing requirements, incomplete designs, multiple projects and priorities, oodles of bugs to test, documentation to create and update, senior managers to assuage over status of projects and ‘level of quality’, the term I came up with was ‘testing from the hip’.

Draw sucka! Hope we draw fast enough and hit one of our targets, then keep shooting!

I hope I continue with this blog and can reach out to others in the software testing field. Where it leads, who knows? I know for now, it will be a central repository for my own thoughts, ideas, questions and comments. Feel free to join in anytime with responses or discussions you may want to address.

Until my next post…