When one of my devs asked me to repro a bug on his box because he didn't know how to execute my repro steps, I didn't think twice. But I was a little surprised when he stated his position that he was strongly in favor of QA always performing the repro steps on the developer's box instead of the developer doing it themself. He argued the devs didn't always have time to go through time consuming or complex repro steps. He attempted to retract portions of his statement once he found out I was blogging it...too late.

I should, however, add that this particular dev has been tremendously helpful to me in setting up tests and helping me understand their results.

That being said, I've never heard anything like this from a developer in all my years of testing and I think it's ridiculous. But it did make me think about how we speak to our devs via bug reports. When we log repro steps from blackbox tests we use a kind of domain specific language that requires a user-based understanding of the AUT. To perform a repro step like "Build an alternate invoice", one must understand all the micro steps required to build the alternate invoice and one may have to understand what an alternate invoice is in the first place. If the next repro step is "Release the invoice to SystemX", one must know how to release the invoice, etc.

I think it is realistic to expect developers to have an understanding of this business-centric language as well as knowing how to perform said procedures from the AUT. And in general, time spent learning and using the AUT will help the developers improve it's overall quality.

Am I right?


  1. А.Б. said...

    You are completely right that devs should understand and know main business logic. But what if system too large and number of devs is so big?
    Once I have being working for project with 70 devs and 20 testers. It was project for daimler chrysler factory. We have more than 1K of Use Cases to implement and more than 10K test cases to execute. Some times I wasn't surprised to see that devs didn't know business logic because it was very very difficult to understand and devs knew system only from position of use cases implemented by them (they knew only entry points and "exit poinst")

  2. Eric Jacobson said...


    Yeah, I guess it would be unfair in such cases to make the devs learn that much about such a complex AUT.

    I guess the devs would need assistance to arrive at the bug. The trade-off would be the dev would miss out on knowledge (i.e., the knowledge about parts of the AUT outside of their comfort zone) that could help them prevent additional bugs.

    In your example, were your 20 testers expected to learn the entire AUT?

  3. А.Б. said...

    We had about 20 BA (business Analysts) who wrote all Use Cases. Sometimes they helped us to undertsnd some specific features. Aslo, we (testers) had a lot of trainigs during business trips to customer's side. By the contract 2 testers had to test on native customer's environment during full develpoment cycle. That how we got all needed information.

Copyright 2006| Blogger Templates by GeckoandFly modified and converted to Blogger Beta by Blogcrowds.
No part of the content or the blog may be reproduced without prior written permission.