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
Popular Posts
-
After attempting to use Microsoft Test Manager 2010 for an iteration, we quickly decided not to use it. Here is why. About 3 years ago we ...
-
Data warehouse (DW) testing is a far cry from functional testing. As testers, we need to let the team know if the DW dimension, fact, and b...
-
I recently read about 15 resumes for tester positions on my team. None of them told us anything about how well the candidate can test. Her...
-
This sucks. I’ve been testing all day and I haven't found a single problem. No, wait… This is good, right? Clean software is the goa...
-
Hey conference haters. Maybe it’s you… I just got back from another awesome testing conference, Spring STPCon 2012 in New Orleans. Appare...
Who am I?
- Eric Jacobson
- Atlanta, Georgia, United States
- My typical day: get up, hit the gym, listen to public radio, do not drink coffee (I kicked it), test software or help others test it, break for lunch and a Euro-board game with the devs, log more bugs, walk the dog and baby, enjoy a meal with Melissa, an IPA, and a Netflix movie, look forward to a weekend of hanging out with my daughter, Josie, and perhaps a woodworking or woodturning project.
My other passion is woodturning.
Test blogs I try to read
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.