Walk Like a Customer

Ramesh Loganathan

VP Products & Center Head, Progress Software

Ramesh is a VP (Products) and Center Head of Progress Software in India, is responsible for leadi... more>>

When testing a product or a solution, what should the core basis for testing be? Is it the Functional Specs? Actual product? Development team? Design docs? Manuals? Competitive products? Or something else? At some basic level all of the above are important and must be factored into the testing planning and execution efforts. However, in the midst of all these more obvious considerations, often a key necessary ingredient gets missed out. The Customers!

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.

Latest postings by this author

Testing In and For the Cloud

View all>>

Business	Technology
Enterprise	Gadgets
Startups	Finance
US-Indian	Career
Magazines	Newsletters

Members	Blogs
Mentorship	Indian Entrepreneurs
Gyan	Advice
My Story

CXO	Technology
Entrepreneurship	Strategy

MBA	MCA
Engineering	Training Institutes
Online Courses	AIBIC
Mobile Apps Training	Online Summer Courses
Medical Institute	Overseas Education

CEO	Startup	Mobile
CIO	Women Leadership	Biz Intelligence
HR	SME	Cloud Computing
Marketing	Embedded	QA/Testing
IT Manager	Dot Net	Java
		Web Developer

Jobs	Freshers Jobs
Companies	HR Speak
Forum	Job Fair
Career News	US Job Fair

Real Estate	Travel
Finance	Gadgets
Products	Movie Reviews
Jokes	Videos
Cars

QA City

Walk Like a Customer