I recently began Integration Testing between two AUTs. Each AUT has its own bug DB and dev team. Let’s say we execute a simple test like this...
Step 1: Trigger EventA in AUT1.
Expected Result: EventB occurs in AUT2.
Actual Result: EventB does not occur in AUT2.
We’ve got the repro steps. Can we log it as a bug? Not yet, because where do we log it? AUT1 or AUT2’s bug DB? In this type of testing, I think fewer bugs are logged per hour. I believe this is because the burden on the tester to perform a deep investigation is much higher than during Integration Testing between different modules of the same AUT.
Part of the problem may be a pride-thing between the dev teams. Each dev team believes the bug belongs to the other dev team until proven wrong by the tester. Yikes...not very healthy! This dev team pride-thing may exist because devs are not always fond of collaborating with other dev teams. On my floor, the QA teams are forced to work together while the dev teams somehow manage to survive in their own clans. There are exceptions, of course.
Anyway, after adequate bug research, it is usually possible to determine bug ownership. But what if neither dev team is at fault? What if the bug exists merely due to an integration design oversight? Where do you log it then?
Boy, being a software tester is hard work!
RSS
Test blogs I try to read
- Adam Goucher
- Adam White
- Ben Simo's Quality Frog
- Dawn Cannan's Blog
- Google Testing Blog
- I.M. Testy
- James Bach's Satisfice
- Jonathan Kohl's Collaborative Software Testing
- Matt Heusser's Blog
- Michael Bolton's DevelopSense
- MSDN's Software Testing Forum
- Steve Rowe's Blog
- Test Obsessed
- Testy Redhead
- The Braidy Tester
Blog Archive
Who am I?
- Eric Jacobson
- Atlanta, Georgia, United States
- My typical day: get up, hit the gym, listen to public radio, drink strong coffee, perform virgin software tests, break for lunch and a Euro-board game with the devs, log more bugs, walk the dogs, enjoy a meal with Melissa, an IPA, and a Netflix, look forward to a weekend with a cave trip or woodworking project.
A good tester is a trouble shooter. By trouble-shooting, you should eliminate possible causes of a bug in one module and then do the same with another module. As a dev, I would not want to debug other dev's problem if I don't have to. It's just too time-consuming and makes me look like an idiot when I don't know well about another module (so many stupid questions to ask just to set up test data). I assume you were talking about a complex system. Hence, test data is hard to set up. Otherwise, you wouldn't have this problem of figuring out which module is buggy.
Yes, I agree, a good tester should do that. But only to an extent. Even after eliminating possible causes the devs still sometimes shrug and say "it's not my code". And it is difficult for the tester to convince them otherwise.
I don't think it's unreasonable to ask the devs to walk over to each other's cube and figure it out sometimes. In fact, I'm embarrassed for them if they have not done this prior to giving me something testable.