bugs

[David Burgun]

On 7 Apr 2006, at 17:49, Mark Wieder wrote:

> David-
>
> Friday, April 7, 2006, 3:26:29 AM, you wrote:
>
>> Approach 2, results in much better software and much happier
>> engineers. The idea is to have QA involved right from the start, at
>> the design stage. QA's job here is to ensure that components (such as
>> libraries etc.) are unit tested as they are written.
>
> 100% agreement on approach 1 vs 2. It really is true that the best way
> to eliminate bugs is not to code them in the first place. I always
> like to get QA involved at product inception and follow the sdlc
> through to the release.
>
> But... it shouldn't be QA's job to do unit testing. That's
> development's job.

In a way, yes, but on the other hand, I worked at one place that had  
around 5 imaging products and they all used a couple of common  
libraries. It made sense in this case for QA to track which versions  
of the libraries were used in the build of which products. Also since  
they were Shared Libraries (DLLs), they would switch out libraries  
and move back to older versions to track when a "bug" was introduced.  
They also had a Library test tool, which exercised the API.

> The tests written by QA should complement the unit
> tests in terms of integration testing, functional and boundary tests,
> etc. Otherwise you get QA locked into the same mindset as development
> to where you know what the program is supposed to do, so you don't
> test other scenarios. It's the same reason you can't do proper QA on a
> product you've written yourself. I've had my own apps pass all the
> unit tests I've written and come through with flying colors, only to
> be shot down in five minutes when I handed the "finished" product off
> to someone else.

I agree, the best policy I've found for this is the to have a Test  
department that writes code to test the robustness of key system  
components.

All the Best
Dave