Customers don't tell, YOU have to ask

“Customers don’t tell, YOU have to ask”
Science of Questioning

T Ashok
Founder & CEO
STAG Software Private Limited

in.linkedin.com/in/AshokSTAG
ash_thiru

Webinar hosted by

Jan 18, 2012, 1500-1615 IST

`

Customer
To build software, we need to have good
understanding of specifications. That is, we need
to know what end users need.

End users needs are really specifications.
But specifications are not always stated, or be
incomplete or fuzzy.
spec
converted to As a developer, I quietly make assumptions.
code
As a tester, my job is not just about checking
what is stated. It is about ensuring expectations
are met.

Expectations - These are indeed hard to state!
Software Engg Team

© 2012 STAG Software Private Limited. All rights reserved. 2

Customer
understanding of speciﬁcations. That is, we need
has different types of to know what end users need.
“End users”
End users needs are really speciﬁcations.
incomplete or fuzzy.
convert ensure
needs expectations As a developer, I quietly make assumptions.
to features are met
As a tester, my job is not just about checking
what is stated. It is about ensuring expectations
are met.
DEV TEST
Software Engg Team


“Customers don’t tell...
... who the various end users are understanding of speciﬁcations. That is, we need
to know what end users need.

... what each end user needs End users needs are really speciﬁcations.
... how they may use incomplete or fuzzy.

As a developer, I quietly make assumptions.

... what end users expect As a tester, my job is not just about checking
from the system what is stated. It is about ensuring expectations
are met.


YOU have to ask”

“... YOU have to ask”

... implies asking questions. Good questions.

... questions about types of end users, usage, behaviour,
data, attributes, architecture etc.

... questions that cover the breadth & depth, questions
that are pointed & open-ended.


Good questioning is key to good understanding.

Ask a question and you get a good answer.
Ask a question and you get a vague answer.
Ask a question and you don’t get an answer.
But don’t stop, continue to ASK QUESTIONS.

“It is more important to know what you do not know,
rather than be content with what you know”

It is therefore important to come up with good questions
rather than worry about the availability of answers.


Science of Questioning

Joe the tester faced with the problem of understanding a new application in a domain that he is
unfamilar with, has the “Aha” moment at a doctors’s ofﬁce during a patient diagnosis session.

He sees parallels in doctor’s questioning technique to diagnose the problem and his problem of
understanding the application.

He realizes that decomposing the problem into information elements and establishing the
connections between these elements enables him to come up with good questions to
understand the application in totality.Voila!

He concludes that there is a “science of questioning” - a systematic walkthrough of various
elements commencing from the customer’s needs/expectations and then into the application’s
deployment environment, architecture, features, behaviour and structure and then connecting
these elements to come up with ‘good questions’.

Read the full story “The diagnosis” at slideshare.net/stagsoft/the-diagnosis
Published in “Tea time with testers” May 2011


Layered Understanding
Marketplace Customer types Success factors
Customers
Deployment environment

User types Requirements #Users Usage proﬁle
End Users
Features Ranking of features Attributes

Structure - Architecture, Technologies
Product/App
Stage of development

Behaviour Data spec
Features
Interactions


Information needed for good
understanding...
Success factors The reason for deploying the system

Marketplace & Customer types The target for our business

Deployment environment Where will it run?

End users Who will use our system? How many?

Requirement, Features, Attributes What do they need? What are their expectations?

Ranking of features & Usage proﬁle Which is more important? How will it be used?

Interactions How do feature(s)/requirement(s) affect each other?

Structure - Architecture, Technologies How do the internals look like?

Stage of development Built new or modiﬁed or status quo?

Behaviour What conditions govern the behaviour of a feature?


Information needed for good
understanding...
Success factors
External information
Marketplace & Customer types

Deployment environment

End users

Requirement, Features, Attributes
to
Ranking of features & Usage proﬁle

Interactions

Structure - Architecture, Technologies

Stage of development

Behaviour
Internal information


Techniques to Aid “Scientific Questioning”

Landscaping – A Core Concept in HBT
A technique to rapidly understand the system by examining the various elements and the
connections between them.

Viewpoints – A Core Concept in HBT
See the system from various end users’ point of view to identify the needs & expectations to
set a clear baseline.

Personal, scientiﬁc test methodology.
HBT SIX staged evaluation powered by EIGHT disciplines of thinking
(STEMTM) using THIRTY TWO Core Concepts.


Landscaping – A Core Concept in HBT
A technique to rapidly understand the system by examining the various elements and the
connections between them.

It is based on the simple principle:
“Good questions matter more than the answers. Even if questions do not yield answers, it
is ok, as it is even more important to know what you do not know.”

Landscaping states that there are
about SIXTEEN information
elements that will enable good
understanding of the system.

The act of seeking information of
these SIXTEEN elements and their
interconnections results in
questions that aid in
understanding.


Viewpoints – A Core Concept in HBT
See the system from various end users’ point of view to identify the needs & expectations to set a
clear baseline.

Good testing requires that the tester evaluate the system from
the end use angle i.e. put oneself in the end-user’s shoes.
m
This is easier said than done. Syste

This is useful to dig deeper to get a clear handle on needs & expectations
once various end user types are identiﬁed.

Some questions generated by applying
Landscaping...
Marketplace What marketplace is my system addressing?
Why am I building this application? What problem is attempting to solve? What
are the success factors?
Customer type Are there different categories of customers in each marketplace?
How do I classify them? How are their needs different/unique?

End user (Actor) Who are the various types of end users (actors) in each type of customer?
What is the typical/max. number of end-users for each type?
Note: An end user is not necessarily a physical end user, a better word is
‘actor’
Requirement What does each end user want? What are the business use cases for each type
(Use case) of end user?
How important is this to an end user - what is the ranking of a requirement/
feature?
Attributes What attributes are key for a feature/requirement to be successful (for an end
user of each type of customer)?
How can I quantify the attribute i.e. make it testable?
Feature What are the (technical) features that make up a requirement (use-case)?
What is the ranking of these?
What attributes are key for a successful feature implementation?
How may a feature/requirement affect other feature(s)/requirement(s)?


Some questions generated by applying
Landscaping...

Deployment environment What does the deployment environment/architecture look like?
What are the various HW/SW that make up the environment?
Is my application co-located with other applications?
What other softwares does my application connect/inter-operate with?
What information do I have to migrate from existing system(s)? Volume,
Types etc.
Technology What technologies may/are used in my applications?
Languages, components, services...
Architecture How does the application structure look like?
What is the application architecture?
Usage proﬁle Who uses what?
How many times does a end user use per unit time? i.e. #/time
At what rate do they use a feature/requirement?
Are there different modes of usage (end of day, end of month) and what is
the proﬁle of usage in each of these modes?
What is the volume of data that the application should support?
Behaviour conditions What are the conditions that govern the behaviour of each requirement/
feature?
How is each condition met - what data (& value)drives each condition?


Hypothesis Based Testing - HBT 2.0
A Quick Introduction Personal, scientiﬁc test methodology.
SIX stage methodology powered by
EIGHT disciplines of thinking (STEMTM).

Setup Hypothesise
Cleanliness Criteria Potential Defect Types

SUT
Nine Stage
Cleanliness Assessment
Defect Removal Filter

Click here to know more about HBT.
http://slidesha.re/qBMNiy


Some Interesting Results

Understand complex product in less than a week

Discovered defects in requirements without testing, via questioning

Uncovered design ﬂaws by questioning behaviour

Lessen the dependency on domain expertise to understand product

Clear understanding of behaviour, resulting in complete test cases


Thank you!

Want to know more?
Connect with us... Attend the pre-conference tutorial at
STeP-IN Summit 2012, Feb 15, 2012 (0900-1300)
@stagsoft
blog.stagsoftware.com "Think like a Child. Act like an Adult."
The Science of Questioning"
stepinforum.org/stepin-summit-2012/tutorials/t_ashok.html

Offerings
Career programs
HBT Series of Workshops
www.cleansoft.in
A division of STAG

HBT is the intellectual property of STAG Software Private Limited.
STEMTM is the trademark of STAG Software Private Limited.

© 2012 STAG Software Private Limited. All rights reserved. www.stagsoftware.com

Customers don't tell, YOU have to ask

More Related Content

What's hot

Similar to Customers don't tell, YOU have to ask

More from STAG Software Private Limited

Recently uploaded

Customers don't tell, YOU have to ask