STAG Blog - Latest Comments

Re: Quality injection – Scientific validation of requirements

Shrini Kulkarni — Sat, 14 Apr 2012 13:39:31 -0000

What if you were to drop the word "scientific" from this post. Try reading it by omitting the word science or scientific - I think it just reads fine. Right?

Why did your customer want a "scientific" method to validate requirement instead of any other (possibly non scientific method)?

can you share one potential defect type that is hypothesized given (a) requirement, domain, technology, cleanliness criteria?

I hope you are not making the /mistake/ of counting the requirements

Shrini

Re: TMMi Implementation Guideline

Marc Gebauer-Dunlop — Tue, 21 Feb 2012 11:07:46 -0000

Hi,
This may help regarding how TMMi and agile:
http://www.experimentus.com...
regards
Marc

Re: Do you know the ‘potency’ of your test cases? (Webinar Q&A Audio)

Shrini Kulkarni — Sun, 19 Feb 2012 12:11:38 -0000

I think the question "countability" was not answered - instead a broader context of countability was given. I listend to this portion of talk again and again - but still I am lost. Consider this -

Ashok said - an entity like "Test" or "test case" can be decomposed of two parts -

1. Conditions that govern the behavior - notion of scenarios that come out
2. Stimuli to excite the system so that it displays some specific behavior - Inputs supplied to the system and their nature.

When we say countability - it is not I am somehow generating scenarios or test cases - but I model the system's behavior and understand the conditions (binary or 3 values, n value) for specific behavior - hence I take number of conditions, number of values. Then I apply various techniques for generating permutations and combinations such decision tables, state machines etc to arrive at a set of meaningful and provable scenarios.

For every scenario, as per this definition is -

There certain no of inputs - each of these take certain values and seek an optimum combination (some max and min) - this helps to comprehend the notion of countability objectively.

But the original question remains.

Are test cases countable?
Given an application, its behavior, conditions and inputs - it is possible arrive at A NUMBER of test cases that would be considered as OPTIMUM?

I know this is a tough question - but I think you folks have cracked it. Can you explain with an example?

Shrini

Re: Houston, we have a problem

STAG Software — Fri, 13 Jan 2012 08:57:11 -0000

Thank you Shrini for leaving your comment.

Re: Introduction to Hypothesis Based Testing

STAG Software — Fri, 13 Jan 2012 08:53:08 -0000

Thank you Nagenderr...

Re: Introduction to Hypothesis Based Testing

STAG Software — Fri, 13 Jan 2012 08:52:22 -0000

Thank You Tirumalanath.

Bookmark our blog link, and check in regularly as we shall be posting regularly.

Re: Introduction to Hypothesis Based Testing

tirumalanath neelaiagari — Fri, 13 Jan 2012 07:15:29 -0000

Hi,
I happen to listen to Mr.Ashok's presentation at a testing conference in Bangalore (may be Silicon India) on HBT. At that time, tried to gather information on the same but unsuccessful. I am happy to see lot of stuff on the website. Thanks for the post.

Tirumalanath

Re: Introduction to Hypothesis Based Testing

N.NAGENDERR — Fri, 13 Jan 2012 06:13:03 -0000

Dear Team,

Its really awesome and more useful.

With Regards,

N.NAGENDERR

Re: Houston, we have a problem

Shrinvas Kulkarni — Fri, 23 Dec 2011 11:44:17 -0000

I was there at the talk. it was Ashok at his usual whit. I specially liked google map analogy - at higher altitude "more we see" and when we go down "we see more".

It is a kind of mind "twister" - but common sensical .... yes . "We see diff problems at different levels" - great way to summarize challenges of testing.

Finally - one thing that we (I and ashok) did not agree on is - reification of the term "defect". I dont recollect Ashok's view on that.

It is uncomfortable for me to think/imagine that there are "concrete" classes of defects. To me, the term defect - its definition and form are very situational and context based. There can not be a concrete system of what constitutes a defect and what is not.

I hope that one day - we both reconcile our differences.

Good talk

Shrini

Re: HBT Solution – (Part 5)

M C Nagaraj — Mon, 29 Aug 2011 07:33:10 -0000

Dear Shrinivas,

Thank you for your interest! Hope the following will give answers to your queries.
The term scientific in HBT means - can the approach/method followed for test design demonstrate the design completeness fully?. The goal centric approach followed in HBT (Hypothesis Based Testing) helps to define cleanliness criteria for software under test which is mutually agreed by stakeholders and QA team before creating the required test assets used to prove the degree of cleanliness criteria met. If the gaps are found in cleanliness criteria by domain experts the same will be addressed before starting test design work. With this approach degree of test completeness goes significantly up and customer also agree to the same. This also can be seen as a result in terms of increase defect detection rate by executing the test assets created and reduced escape % etc.

What is not scientific? If test design completeness assessed just by gut feeling and customer refuse to agree then we need to make an attempt to show why he/she should see completeness in our approach. HBT has helped in addressing such situations.

Also request you to go through HBT link in the above blog for more details. Address given below also.
http://www.slideshare.net/s...

Regards,
Nagaraj

Re: How many hairs do you have on your head?

T Ashok — Fri, 26 Aug 2011 09:48:11 -0000

Shrini,
"Engineering" is about application of science to "craft real things". The essence of engineering is pragmatism and realism, and these are not strictly bounded. Good engineering is about dealing with uncertainty and probability & approximations do play a key role. Over time, we lose touch and moan about lack of clarity.

Do agree that in the context of testing, it is necessary to be constantly stay fresh and inquisitive.

Thanks for your comment Shrini.

Re: “The Ugly Duckling” – The changing face of testing

STAG Software — Fri, 26 Aug 2011 09:26:00 -0000

Thanks Shrini. There was an error in the title. Action taken.

Re: HBT Solution – (Part 5)

Shrinvas Kulkarni — Thu, 25 Aug 2011 17:26:07 -0000

I am interested in knowing how do you define the term "scientific" approach?

how to distinguish between a scientific approach and a non scientific or pseudo scientific approach?

Re: How many hairs do you have on your head?

Shrinvas Kulkarni — Thu, 25 Aug 2011 16:52:56 -0000

Ashok,

>>>> Engineering staff find it difficult to deal with uncertainty.

True. That is why I find the term "test engineer" so inappropriate to testers. True testers love uncertainties - they play with them and have fun in repeatedly ask "what if". Poor engineers hare stuck with their obsessions on certainty.

Re: “The Ugly Duckling” – The changing face of testing

Shrinvas Kulkarni — Thu, 25 Aug 2011 16:19:08 -0000

Please call this as "Changing face of Testing" -

I am sure you distinguish between QA and Testing and QA -

Shrini

Re: TMMi Implementation Guideline

M C Nagaraj — Wed, 15 Jun 2011 13:45:54 -0000

Hi Ramesh,

Thanks for your comments. I feel agile testing call for frequent evaluation. According to me a stable and tailored process here will help in consistency, less time in understanding and re-use of test assets (validation suite approach of HBT) as great advantage. As long as you create work product keeping the user in mind you can reduce documentation make it suitable to the constraint you have. Normally people write test scenario and test cases so descriptively where you find duplication. Sometime you feel like we can create some sections and refer them at many places. I recommend you take few test cases for a module you will find many texts are duplicated which can be avoided.

Hope this helps. The only way we can address the issue of "more with less" which is the expectation in many situation we have to depend on consistency, reuse, less documentation and so on. All of this are addressed by focus on process improvement.

Regards,
Nagaraj

Re: TMMi Implementation Guideline

BR Ramesh — Thu, 09 Jun 2011 10:09:58 -0000

MC,

Godo coverage. and nice material. Only thing i was unable to fully correlate to the Agile testing which is the in thing in my company
Regards
Ramesh

Re: Hypothesis Based Testing (HBT)

Bhaskar V — Tue, 24 May 2011 10:07:12 -0000

Could you please send a document on HBT?

Re: De-ticking a dog – What can we learn from this?

T Ashok — Wed, 27 Apr 2011 06:35:56 -0000

Thanks Ramesh

Re: De-ticking a dog – What can we learn from this?

G Ramesh — Mon, 18 Apr 2011 04:01:12 -0000

Great Stuff Ashok!

Cheers

Ramesh

Re: Hypothesis Based Testing (HBT)

Sonal Balte — Thu, 20 Jan 2011 09:53:11 -0000

I am working as Product engineer in my company.
we are a product based company.
It have software product in windows and web environment.
We perform manual testing.
we want to switch to Automation testing.
can HBT help on our queries?
my contact no.is 9930264747.

Re: We demystified the automation puzzle. Relentless validation tamed!

Ravi — Thu, 01 Jul 2010 05:10:57 -0000

hi ,
Can you tell me how efficient and different is this framework w.r.t STAF framework of IBM. It seems that You guies have developed similer kind of STUFF.