Value Added Testing (VAT)

Testing is a time boxed effort, just that the time is mostly reduced.

Why VAT

1. How often does Client delivery get delayed to accommodate entire Testing time?

Does Development time ever get reduced?

Why VAT

2. Are the Testing estimates untouched / unaltered / utilized completely?

Test automation is only automating a crude approximation of one aspect of testing.

Why VAT

3. Are all internal QA bugs fixed by Development before the delivery?

If each side of brain can control different types of thinking, why cant each eye handle different tasks that of Maker and Checker?

Why VAT

4. Does an untested case get logged by the client and a tested case fails at client site and we are sure that the code is 100% bug free?

DST : You cant stop time but you can certainly advance it. VAT: You cant test everything, but you can certainly test what is good enough.

Why VAT

5. Post-delivery, does the (quality / quantity ) of documentation get questioned frequently and get referred in the future?

Testers are paid to play with the product

Why VAT

6. Does the testing team by itself inform that the estimates are very high for Testing?

It's a common misconception that a process can only be controlled by documented plans.

Why VAT

7. Proportionate amount of testing is completed in the first few days of Testing phase?

it isn't the number of bugs that matters, it's the effect of each bug

Why VAT

8. How often there are no lags in the preceding phases, leading to cascading delay in Testing?

The world is full of uncertainty, not only the code.

Why VAT

9. How often is Testing skipped partially / completely due to exhaustive Programmer testing?

10. Are known defects published to the client?

Apple shipped the first version of HyperCard with about 500 known bugs and Windows 3.1 was shipped with 5000 known bugs!

Why VAT

If the answer to any of the previous questions is NO,NEVER or SELDOM, there is definitely scope for VAT.

Fix a product before it is broken; never introduce a bug.

Why VAT

VAT is to identify and agree how much testing is good enough and test within the available time limit or in a truncated time frame and still deliver the best without a compromise on quality. It requires an unorthodox approach to the entire testing life cycle which questions and validates every single process / sub –process in the testing lifecycle, enhances it further, alters or skips sub-process or the entire process as required by the product / project and also revisits the estimate at intermediate stages to see if there is a possible reduction. In simple terms, VAT is not just good testing; it is good enough testing which would save time and cost to the company in multiple ways.

Every 8th line of code has a chance of picking up a new defect

Value Added Testing ( VAT)

Every piece of software is unique, and testing needs to vary dramatically from project to project .

A graphical representation

Choosing the right bugs and right quality to ship with is the key.

Could we term it as Sprinkle model?

Similarly, we need to “cover” the product with “enough” amount of test cases

How to do VATIdentify Value Added(VA) and Non-Value Added(NVA) activities.Eliminate NVA.Situational approach.Decide ALAP, deliver ASAP.Decide how much is “good enough”.

It is impossible to test a program completely

Few illustrationsNON-VALUE ADDED VALUE ADDED

Detailed documentation Lean/Light weight documentation

4 eyes principle ( for certain tasks) 2 eyes principle ( for certain tasks)

Proportionate headcount Realistic headcount

Enforced automation Possible automation

ASAP / ALAP ALAP / ASAP

Conventional Agile / Waterfall Flexible model ( Sprinkle ? )

Test all scenarios Test required scenarios

Manager : Subordinate(s) Mentor: Mentee(s)

Testing is a way to measure quality; it is not a remedy by itself.

Documentation

Selective documentation.

Checklist / Traceability matrix.

Light weight video recording tool.

Additional test cases.

Expedite testing.

Lean test documentation.

Documenting is not testing. It is one of the chief distractions to testing.

4 eyes or 2 eyes

Need based review.

Peer testing ( Unit testing level )

Hybrid unit test cases and test cases.

Agreed programming standards.

Everybody Tests, not just the designated testers.

Headcount

No project requires fixed number of headcount.

More testing does not mean increased quality.

Less number of testers would improve the quality of Unit Testing.

Businesses does not want testing. They want systems that work well enough to make money. Sometimes that requires more testing, sometimes less, sometimes none at all.

Automation

Testing is a thought process; involves learning and discovery.

Automate only whatever is possible.

Compliment it with manual testing.

Better not to entirely delegate to machines.

Imagine a bug and find it

ASAP / ALAP

Early involvement of testers not always required.

Late involvement could save time and rework.

Decide as late as possible; Deliver as fast as possible.

Need based involvement / Situational practice is crucial

Nothing works all the time

Full / Partial coverage

Cannot test everything, test what is good enough.

Wanting the product to work in deployment or preventing it from being deployed is the key.

Impossible to find all the bugs in the code.

Impossible to know whether all bugs are found.

Possible to prevent coding errors and have limited coverage.

It is impossible to test a program completely

Mentor : Mentee

Brain dump of successful testers is not available.

Testing is not clerical activity, it’s a subtle art to be learnt.

Mentors are also concerned about mentee development

ON time delivery is as important as ONE time delivery ( less number of fixes post-delivery )

Explaining testing is a big subject…

20% of the code causes 80% of the problem; identify it.

Some shortcuts to find killer bugs in initial days:

Rule of thumb, Educated guess, Intuitive judgment Common sense.

Apply DMAIC

True certification of a tester is the respect of respectable people

And finally, an analogy

Testing is like marriage. You meet the product (person), try to understand it better, change the test cases

according to the requirement, try to validate it day by day and get familiar with it. Problems are either fixed or accepted and tester has fairly reasonable idea how the

product will react. The product behaves as expected and the tester lives happily ever after.

Testers have to be the Master of messy thinking

Thank you,http://www.linkedin.com/in/haridhvar

TESTER needs to DEVELOP an eye for detail