Monday, August 8, 2011

Testers and Testing

I've been working on a variety of projects lately that are staffed very differently. One project has a dedicated test team, and a development team. One project has no dedicated tester, and the development team is terrified that they "don't know how to test any of this". Yet another team has no dedicated testers, and they figure they're doing all right without it.

Why such different teams? And why such different reactions?

I suggest that it is entirely to do with testers versus testing.

Testers are people filling roles.
Testing is an activity.

A tester is (ideally) someone who is dedicated to the study of testing, and to doing the testing activity better, more efficiently, more effectively, etc. That doesn't mean that only testers can do testing. That doesn't mean that testers must only do testing. It mostly means that someone who is a tester is more likely to do testing activities more thoroughly and efficiently than someone who is not a tester. It's a simple analogy to a database architect. Sure, they're probably going to build you a better data model faster, but you could also have another engineer create a data model. It's up to you to decide whether that activity (the data model, or the testing) is worth having a dedicated resource.

Be careful not to conflate the role (tester) with the activity (testing). It's perfectly acceptable for all the testing activities to be done by people with the formal role of developer, or project manager, or client. It's completely all right if a person with the formal role of tester does testing activities.

The important thing for a successful project is not that there is a dedicated tester. The important thing is that the testing activity is occurring.

As with any software development activity, decide how important it is, and staff accordingly. Don't build a team based on roles; build a team based on activities.


  1. This post hits home to me because I have noticed this same thing perusing the SQA boards for years. When people insist that requirements are mandatory, or somesuch is mandatory, I just smile. Many things are nice-to-have, but in the end, it is what works for the team you are on at that moment. The team I am on has very little of what I suspect would be termed "industry standard" or "best practices" but what we do have is working fine for us, and our customers. Yes, I would tweak a few things if I could, but since quality is delivered and customers are not only happy but returning and recommending our product, we are doing fine.

  2. Software testability is how easily, completely and conveniently a computer program can be tested.
    Software engineers design a computer product, system or program keeping in mind the product testability. Good programmers are willing to do things that will help the testing process and a checklist of possible design points, features and so on can be useful in negotiating with them.

    The following testing activities should be performed during the phases
    • Requirements Analysis - (1) Determine correctness (2) Generate functional test data.
    • Design - (1) Determine correctness and consistency (2) Generate structural and functional test data.
    • Programming/Construction - (1) Determine correctness and consistency (2) Generate structural and functional test data (3) Apply test data (4) Refine test data.
    • Operation and Maintenance - (1) Retest.

  3. Dwebb, that's one way to look at it. I'd be careful to differentiate between testing (the activity), the tester ( a person who primarily focuses on the testing activity), and testability (how easy or difficult it is to perform effective testing activities on a given system). Same root, but different concepts!

  4. Good post!

    You hit the spot exactly: don't judge a project by the number of testers, but by the testing activity being done.

    This relates to a post I wrote (called, When Your Job is Not to Test) where I also elaborated on the fact that the no. of testers vs. programmers, and level of "formal" testing doesn't indicate the level of de-facto testing, and certainly does not indicate the level of bugs.

    As the above post states, what matters in the amount of testing that is actually being done.

  5. Thank you for sharing this article. I beleive all good testers are independent thinkers and Independent software testing is always a value add.