• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
VodQA-TooMuchVerificationNotEnoughValidation_SrinivasChillara
 

VodQA-TooMuchVerificationNotEnoughValidation_SrinivasChillara

on

  • 443 views

This was a lightening talk presented by Srinivas Chillara in vodQA-3 : A QA Meet held in ThoughtWorks, Pune.

This was a lightening talk presented by Srinivas Chillara in vodQA-3 : A QA Meet held in ThoughtWorks, Pune.

Statistics

Views

Total Views
443
Views on SlideShare
443
Embed Views
0

Actions

Likes
0
Downloads
1
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Quality is seen too narrowly as lack of bugs … bugs being defined as non conformance to documented wishes.
  • Quality is seen too narrowly as lack of bugs … bugs being defined as non conformance to documented wishes.

VodQA-TooMuchVerificationNotEnoughValidation_SrinivasChillara VodQA-TooMuchVerificationNotEnoughValidation_SrinivasChillara Presentation Transcript

  • Saturday, 26 th March, 2011
  • Too Much Verification; insufficient Validation
    • Srinivas S Chillara
    • Independent Consultant
    • GoodAgile
  • QA?
    • The QA community is obsessed by bugs;
    • Should it be the case?
    • Well, yes and no.
  • How is it a case of impropriety? We are not doing justice to the QA role, but stopping at QC… … how do we see quality (as shown by our actions)… … Let’s see how we stop at QC
  • The underlying influencers
    • As we write test cases we tend to anchor it to some document or the other
    • Unfortunately many of us largely take document as correct
    • Somewhere as a group we think that the quality of software that we build lies in the meeting the functional description documented
    • Quality is lack of bugs
    • Meet the letter… what about the spirit?
  • The two problems
    • Meet the letter… what about the spirit?
    • Quality is seen too narrowly
    • We create conflict later on, between ourselves and our customers
  • What can be done about it? We have to spend more time on validation activities, instead of only looking at verification Verification => That we are building it right Validation => That we are building the right thing While many of us will nod our heads wisely, there is little evidence on the ground in terms of behaviour.
  • Example Sides of a triangle: a,b,c String ClassifyTriangle(a,b,c)
  • Example Cancelling a railway ticket… you want to cancel first?
  • What are the signs of validation We should see that significantly more functionality being designed as a result of validation… in other words there are many more alternate paths identified. 80% of the code is executed in only 20% of the instances. We would be filling in the 80%. The analysts/designers, and end customers engage more with the testers, only then we’d have justification to the title of Quality Assurance.