13

In my firm, we don't have testers, exactly. We have analysts who translate business requirements into specifications. (Think the guy from Office Space, except these guys actually provide some value. Kind of.) Because they have an agenda (keeping the people who gave them the requirements happy) they are often lacking in the thoroughness of the testing they do. Sometimes it's because they simply hadn't considered one portion, but sometimes it's where they actively ignore an area because they know if they test it, it will break, or if they test it they wouldn't know right or wrong either way.

The kicker is, a month from now, I might get a spec that fixes "a bug introduced with project 12345." Well, gosh, I sure did a lot of testing on that, obviously I missed some of it. Now, the development team is the one who takes the flak because they're the one who introduced the bug. I for one am willing to admit I don't write perfect code, and so are people on my team. But how do you deal with a (biased) testing group that 1) doesn't communicate with other testers, and 2) refuses to accept the fact they also missed it in their testing?

Keep in mind that this is a highly un-idealistic environment. There are some of us who have had it quite good in the past, and would like to bring our department up to speed on best practices. It's a slow process, and sometimes we're not sure even where to start.

Improve this question
3
  • the title doesn't seem to describe the question very well. Perhaps "How do you improve testing with a team who aren't interested in improvement?" It seems that your problem isn't that your testers do more than test, it's that they don't really test, just go through the motions.
    – testerab
    Commented May 5, 2011 at 22:37
  • 2
    @testerab The key point is that they not only test, but also generate the spec, and functional requirements for the project. Because their primary goal is to get the project done to who ever requested it's satisfaction, they will often neglect to test the other effected areas, potentially breaking it for other people. Their bias as spec writers is the primary concern of the question.
    – corsiKa ♦
    Commented May 5, 2011 at 22:40
  • Ah - ok, now I see where you're coming from.
    – testerab
    Commented May 5, 2011 at 22:50

3 Answers 3

Reset to default
7

I dealt with the same issue several years ago, and frankly, as a portion of this issue is personal integrity, corporate accountability can only go so far. As a realist, I acknowledge that increased accountability did help, but only temporarily. As soon as the individual realized they can get away x amount of misunderstandings, errors and vague specs, they no longer kept a high level of work ethic integrity. The only thing I think the company did that truly helped was they swapped Business Analyst and QA team members, having the BA do QA, and the QA do BA. I love variety in my job so it didn't bother me to switch over temporarily. One BA in particular did vastly improve her specs and customer communication as a result of this.

Improve this answer
7
  • @Laura I appreciate the insight that you've offered (here|other posts). What suggestion would you have if the BA and QA people... are the exact same person? I.e. the BA handles the QA responsibilities for each project he submits.
    – corsiKa ♦
    Commented May 6, 2011 at 21:26
  • Back to the realist bit I mentioned (it works for me, and against me). I would start with trying to enforce accountability with this individual. Lay down expectations clearly to equalize all involved. (It could be expectations vary per person.) Then professionally monitor & communication. Hopefully a few examples are all that is needed. (Note to self: monitor emotions when communcating these discrepancies.) all emotions removed
    – Laura Hensley
    Commented May 6, 2011 at 22:04
  • @Laura I'll try to keep that in mind. Most of the people who are in those positions have been with the company for over 10 years, and... have many friends, which is an unfortunate circumstance. I guess that's all the more reason to try to keep emotions out of it. But in all honesty, I don't just want a pile of CYOA; I really just want these projects to get done, and get done right. The expectations do vary from person to person as you suggest. There's some important keywords in that recent comment; thanks again! :)
    – corsiKa ♦
    Commented May 6, 2011 at 22:09
  • It won't let me edit the prior comment; I guess I went over 5 mins in my thinking. Here is my revised comment:@glowcoder To clarify, this individual --as BA-- is missing critical pieces; then when they begin QA the feature that is poorly BA'd (pardon my 5pm Friday shortcut), the lack of coverage is resulting in poor QA? So essentially they are their own worst enemy in this situation? And they are in denial? Sorry, need clarification before I assume/presume the wrong thing.
    – Laura Hensley
    Commented May 6, 2011 at 22:11
  • OK Glowcoder, have read your response. Pardon my slowness at learning stackexchange. Best wishes!
    – Laura Hensley
    Commented May 6, 2011 at 22:12
4

I think someone needs to have a frank conversation with management. These people are not doing software testing in the QA / technical sense. They are doing user acceptance testing. Quite simply, you cannot expect someone who is involved in designing the project to be successful to also have a real desire to show how the product fails. This isn't the fault of the testers themselves, but the fault of whoever decided that the people filling the BA role / spec developer could also test effectively, without any other dedicated testing.

Management needs to understand that the greatest value of a tester on a project comes from their total devotion to showing that the specific product(s) they are testing doesn't work as intended. They are the only role on the team that is dedicated to showing how things can fail, and their failure-orientation needs to be protected. Having testers also take a primary role in defining the product destroys that failure orientation. The only role testers should take in building a product is to point out holes, unclear areas, mismatches between customer wants and actual specs, potential better alternatives to current designs, and other failures or risky areas. Once a person starts helping with the actual design, they are emotionally invested in success and will be less inclined to find failure.

Improve this answer
1

Could ask them if they feel that they can be held accountable for the code that they've tested/signed off on (if that's a requirement in your organization). Although you as the developer can test your code fairly well, you'd also be biased regarding it, and rightfully so. In the end, anyone involved with the process should be willing to take at least some accountability for the product. Not sure about how much testing is actually done, but, you could ask if you could sit down with them and show them some efficient ways to test functionality (I personally love it when the developers ask if they can help make my life easier).

As for the communication between testers, or anyone on the team, could always try to strike up a conversation regarding the working atmosphere and eventually ask about communication and what you think that you've noticed. This has worked for me in the past when looking at teams where it appears that there is almost none. Sometimes it's due to animosity between team members, sometimes, I've been completely wrong, and they actually had great communication, but, due to the corporate atmosphere, didn't display it overtly.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.