VP Products & Center Head, Progress Software
Ramesh is a VP (Products) and Center Head of Progress Software in India, is responsible for leadi... more>>
Conventional wisdom says that as the specs define the functionality being built (and the same finds its way into the manuals et al that highlight the same to the customers), so the specs must be the primary basis to test a product or project. However, while this is a factual statement of individual capabilities or features, customers do not "use" features. They use the software in Toto to realize some business goals. Understanding exactly what the customer is going to use the product for is essential and the objective and purpose of the customer using the product. The customer usecases and the business context of these usecases are critical to understand how exactly the customer will use the software. And it is this understanding that should be at the core of the testing effort with specs providing additional specific references.
One can go about testing the product one feature or capability at a time. And technically be "done" with testing and certify the release to be functioning as per the specs. But this will only ensure the base functionality is tested. Doing end user testing and complex scenario testing is what puts these capabilities in a real-world sequence and ensure all still works well. These scenarios could be any logical grouping of steps. But the gest grouping of steps is what the actual customer may eventually do. When looking at what customers will do, first option is to understand typical usecases. In which the business analyst or product manager will be able to provide. This takes the value from testing few notches up from just verifying functionality. Will now helps to verify the specific usage of the products.
The challenge here though is in getting all the use cases likely in the field. PM and analysts may give some usecases, but these often end up being more just as reference usecases an snot the super-set of the cases that is likely. How does one get the super-set of real world cases to build the integration and scenario test cases?
No better way than "understanding" the customer. Who the customer organization is? What roles on the organization will use the software? What are the typical business operations or flows involved, where this software will help? To what end goal do they use it? What business value will they realize? Is it an operational automation system, or is it an efficiency improvement or some other goal. Essentially, understanding the customer and the business usecases involved should be at the core of the testing process.
Experts on QA