Just Enough Testing presentation from TestIL meetup 2018, Also presented in QAGeekWeek and SIGiST 2017 How can we improve our testing process making it leaner on one side but not neglecting Quality on the other? Written as tips and procedures from over 20 years of experience as SW Tester and group leader, These are highlights of my talk, for further details - feel free to invite Me to expend the details in 2 hours or more lecture :-)

1. Just Enough Testing
by Kobi Halperin
bit.ly/TestIL-FB www.testingworld.co.il
Magazine
bit.ly/TestIL
bit.ly/TW-Reg
Promoted by:

2. Who am I?
• Kobi Halperin
• Tester and test manager with 23 years of experience in the
Telecom/Datacom field (SDH, TDM, Eth, Optics, Radio, NMS);
Member of ITCB AB;
Leading TestIL FB community (& Tapuz);
Testing World Magazine Technical content editor;
Seeking to widen discussions in the field of testing.
• Twitter: @halperinko
• LinkedIn: https://www.linkedin.com/in/kobi-halperin-3b47482
• Facebook Group: bit.ly/TestIL-FB
• Magazine: www.testingworld.co.il

3. What shall we talk about?
• Are we putting the Testing Efforts right?
• Just Enough – Test Documentation.
• Quick feedback loop – ABCD approach.

4. Are we putting the Testing Efforts right?
• Are you GOOD Testers?
• Where do we Learn Testing?
• What are Professional Testers?

5. Just Enough – Test Documentation.
• Do we need to fully document ALL tests?
• TC not Learning Material ! 
Shared HowTo
and Common / Shared steps.
• A picture is worth a 1,000 words
A Table is worth 1,000,000

6. Just Enough – Test Documentation.
How to Squeeze 9 Dimensions in 1 Table:

7. Just Enough – Test Documentation.
When writing documents, it is wise to :
At 1st
write just STD/TC names & purpose – For ALL Features
Quick Feed Back – Easy to Review Short Doc
Why at all? - to find Redundant & Missing issues & improve our strategy
* At times – a single sample of detailed description might be useful to
verify the approach.
Then we will move on into writing full details of steps starting with High
Risk and complicated grasp area & Review them.
(If we don’t find the time for all, at least we have the short format for all
topics, rather then having full document for few features, and nothing for
the rest)
And Finally we will complete the rest of the documents and review them.

8. Additional Test Planning topics
• Repeatability vs. Diversity?
• How to include Diversity in TCs?

9. Just Enough – Food for thought.
Other considerations:
Atomic test cases are right for 1st
version when unstable,
But not practical for Regression (Complicated Scenarios)
Do we really need to write detailed tests for 1st
release – we will execute
just once?
Part of 1st
release tests are actually quite Generic Checks – can these be
shared and/or automated?

10. Quick feedback loop – ABCD approach.
You get a bunch of tests – in what order do you execute?
Do you prioritize your tests (I mean really…?)
So you did… – Does it change the way you work?

11. Quick feedback loop – ABCD approach.
Goals:
1. Detect major issues as early as possible in the version
cycle.
2. Define a test documentation structure and test
execution methodology.
3. Achieve a relatively stable version to test, as far as
possible in time from delivery, in order to increase
confidence
4. The ultimate goal is the release better products -
earlier.

12. Quick feedback loop – ABCD approach.
No matter if we use Gantt or Agile Yellow-Stickers,
We plan testers work in a serial manner – one after the other.
Can the tester perform his tasks in a useful manner?
Normally s/he works a bit, tackle 2-3 Testing stopper bugs and wait for fix.
So we slow down till fix arrives, doing some unplanned tasks, then we continue.
Have we planned for Regression? , What?, When?
t0 t1 t2 t3 t4
Feature #1 Feature #2 Feature #3
Normal working procedure:
How much do we know on Features 1-3 at t1, t2, t3, t4 ?
What does developer of Feature#2 knows at t1 ?

13. Quick feedback loop – ABCD approach.
A, B, C, D content:
A: Sanity/Gating
A predefined sample of feature wide tests, selected throughout the whole
document, in order to cover the essentials of each and every part of a given
feature/scope of document.
B: Complicated Scenario
A set of tests that comprise Initial Complex, Load, interoperability between
features, preliminary mass usage and user like tests.
All those tests that if they pass, we gain significant confidence in the functionality
being tested.
C: Full Coverage
All the parts of the document including necessary regression of A and/or B parts.
D: Stress/Regression
Tests set based on B, applied on setups more "customer like", with specific
considerations for full final regression.
Normally includes tests which covers several features together, on larger scale
setups & stress conditions

14. C #1
C #2
C #3
D
D
D
Quick feedback loop – ABCD approach.
Following is a description of the ABCD Approach,
For complex features (which requires more then 2-3 testing days), in order to improve
testing visibility and efficiency during the release.
This method shall be implemented within our Documents & Gantts, in a way that will
allow greater visibility of the stability of more features at any given time in the
release process.
It will be combined with interlocking of several features testing sessions of the same
level
t0 t1 t2 t3 t4
Feature #1 Feature #2 Feature #3
Normal working procedure:
A+B
A+B
A+B
ABCD working procedure:

15. Thank You !
Any Questions?
bit.ly/TestIL-FB www.testingworld.co.il
Magazine
bit.ly/TestIL
bit.ly/TW-Reg
Promoted by:

16. Additional Test Planning topics
Common methods for Tree Break-Down:
•By Requirement/Features topics.
•(By Release in an ALM)
•By system screens.

17. Additional Test Planning topics
Remember to Add:
•Non-Functional areas
•What to include in each stage
(Sanity, Regression …)

18. Additional Test Planning topics
What is our Test Basis?
•Req., HLD/Spec, Help & User-Manuals,
Similar Products, Bug DB, Standards
•Discuss with Devs, Product Mng., CS,
Clients, Previous Testers.
•Validate the Test Basis!

19. Where do Test Ideas come from?

20. Where do Test Ideas come from?
The Testing Wheel

21. Where do Test Ideas come from?
TheTestEye_SourcesForTestIdeas.pdf

22. Where do Test Ideas come from?
TheTestEye_SoftwareQualityCharacteristics

23. Where do Test Ideas come from?
Satisfice - HeuristicTestStrategyModel.pdf

24. Thank You !
Any Questions?
bit.ly/TestIL-FB www.testingworld.co.il
Magazine
bit.ly/TestIL
bit.ly/TW-Reg
Promoted by: