Designing testcases are based on input artifacts like Functional Spec, Design Docs, SRS and Use case docs. But consider an organization is not much exposed to quality processes or a company has taken over a product base without proper processes in place. In this case, how test design is taken care.
How effective the testing is done especially in reverse-engineering products/projects ? What type of testing is done?
We once took over some products together with user documentation. We build up test cases based on user docs. However we receive a lot of issues regarding “lost functionality” from old clients – those are all the undocumented features.
If you have no even user documentation you could want to refer the “exploratory” testing ideas. Hope someone else could comment about them.
?:the art of a constructive conflict perceived as a destructive diagnose.
There is a difference between what testing is done and where you get the information to design those tests!
There is also a difference in approach required for:
a. New functionality
b. Change or enhancement to existing functionality
c. Product support - fixes.
For a. New Functionality
you must have business requirements, else what is being delivered? These business requirements are then broken down into low level test requirements. Without any requirements, skip testing and wait to see what the customer complains about - it ain't going to get any better anyway!
For b. Change or enhancements
Regression testing is the issue (else it is the same as for a.)
For this, you need the input from BA/designers and developers. In the absense of documentation, the developer needs to identify whether new or changed code is required, where this code interacts with other code etc.
For c. Product support - fixes.
The issue report is the requirement. The BA/Designer solution is the requirement. See b. for what you do about any regression testing required.
The main problem you have is absense of a regression test pool or product map. This is where reverse engineering comes into play. It is not to be undertaken lightly. How effective this or the related regression test cases being created are depends on the quality, knowledge and experience of those doing the reverse engineering. Remember, this is reverse engineering for business processes - not for code structure. The development team may well want/need to do a similar exercise for code impact analysis.
I've taken over projects in the past where there is little or no documentation; I've tended to favour interviewing as many people as possible about what the product is supposed to do and supplement this with exploring the system. After a while you get a feel for what the product does and can build your test documentation in the normal way.