| || |
QA and Unit Testing
Our organization has broken up into different development units.
Let's say we have 4 different divisions, and each division will work on part of a product. So there are 4 components, that when integrated will result in our overall software product.
We also have 4 different QA departments within each division that have traditionally tested end user product.
But now - since it takes 4 "official" components to make up a product - our dilemma is "How should we handle the testing?
Isn't individual component testing really Unit Testing?
My company is proposing that each QA division test the components that were developed before they are integrated into the final product. The site where most of the equipment is located will be designated as the System QA Test, and that QA department is perform the System Test.
My feeling is that we'll be adding layers of paperwork (just following the process here takes months), time and money to the overall project itself.
And, traditionally, QA does not have the skill sets to perform some component - ie Unit Testing.
Any comments, suggestions? How does your organization handle component testing?
Thanks for listening and commenting upon our tale of woe!
Software QA Engineer Lead
Senior SQA Analyst
Re: QA and Unit Testing
1) Reorganize the company such that there is one QA department or function that serves all interests.
2) Consider reorganizing the developing agencies such that there is one.
NOTE! The obvious benefits of doing above 1 and 2, et al:
a. Communication improves
b. Redundancies eliminated
c. Huge cost-savings likely
3) Require testing at the unit/module/component (and integration thereof) levels of the developing agency(ies).
4) Establish a separate test engineering group that partners with the developing agency to accomplish testing in those test levels beyond those required of the developing agency.
5) There is a plethora of material available on the www that address the specifics of QA and testing.
Re: QA and Unit Testing
I am actually in a rather similar situation. We have divided our system into three smaller subsystems.
My solution to this is very much alike your proposal.
The level of unit tests is no difference, it is the developers that have the responsibility to test their components before they are handed over to subsystem tests.
The level above, subsystem in our case, is treated such that each subsystem (of the three I mentioned) is formally tested the same way as we earlier tested one system. This is still performed by the same QC-people as before disregarding which department they are working at. The important thing here is that we all must follow the same development process, thus ensure a high quality like before.
Now, as a consequnce of this, we have added a new level above this. This level is used to integrate all three subsystems to one bigger system. Our problem is the requirement management, because on this level we don't actually have requirements that can be applied to the resulting system.
This may sound odd, but the reason is that our system is only a part of an even bigger system. This means that the requirements on the top level can only be applied on the whole system. These requirements is then broken down and assigned to the subsystem level (earlier just one subsystem in our case, now three subsystems).
My department have the responsibility for this integration and I intend to use the test cases from the level below, sligthly modify them and apply them to the integration test.
Your concern of components is therefore, IMO, a matter of which level you specify your requirements on.
If the requirements is specified on the resulting product, then you may be able to treat it as unit tests otherwise not.
But on the other hand, I guess you must consider size, complexity, developer competence, quality demands etc. etc. before you decide how to manage this issue.
As a result of this change we have definitely added more administration and more possible sources of errors...
Best regards Björn