1. Øyvind Woll – Senior Consultant, Vivento AS
What do you do when you must go back to "basics” in the test management book ?
Testers without test experience combined with limited or missing requirements
Øyvind Woll – Senior Consultant, Vivento AS

2. “The best training is the training you actually do”
Oddvar Brå
Legendary Norwegian Cross country skier
“The best testing is the testing that is actually performed”

3. AGENDA 01 02 03 04 05 A realistic test strategy
The establishment of the test organization 03
Working with integrations and risk components 04
The process of documenting the business processes 05
Synergies between the test process and educating the end users

4. The Project Off the shelf solution – Receive project
Public sector - Healthcare
Large organization end users
Nurses, doctors, social workers, executive officers
Migration of sensitive data from existing system

5. Some of the challenges Immature test organization
Limited test basis quality
Limited availability of domain knowledge
Limited time

6. Inputs to the test strategy
How to test it
What to test
Inputs to the test strategy
Quality of Test Basis
Availability of Resources
Functional Domain knowledge
Test maturity
Test Tools
Documented Business processes
Test conditions
RED: Low
AMBER: Medium
GREEN: High 01
A realistic test strategy

7. The test strategy
Testdesign – keep it simple but adjust to different groups of testers
Test reporting – keep it simple but keep it updated
Test coverage – risk based – happy path first
Business processes documentation – keep it simple and visual 01
A realistic test strategy

8. The test process 02 03 04 05 04 04 01 A realistic test strategy
Document the business processes 02
Establishment of the test organization
Work with integrations and risk components 03 04
Introduce the project team to basic test knowledge
Work with the integrations
Document the business processes - high level
Test the business processes - high level e2e
Document the business processes - low level
Test the business processes individually – low level
Test the system and educate the end users 05 04 04 01
A realistic test strategy

9. The test levels Business processes 01 Integration Level Integrations
System Integration Level
Risk Components
Business processes
End to end Processes – No access control
User acceptance Level
Business processes - Actual access control 01
A realistic test strategy

10. The test plan 01 Week What Who 1 Test training
Basic test training
Integration test
Document Business processes - High Level
System Integration test-execution
Document Business processes - Low Level
User Acceptance test
Week
What
Who 1
Test training
Functional domain experts
2 - 6
Integration test (Test-Learn-Update)
Technical team
Document business processes – High level
4 - 6
Document risk components
Functional domain experts/Technical team
6 - 8
System Integration test (Test-Learn-Update)
8 - 11
Document business processes – Low level
11 – 16
User Acceptance test (Test-Learn-Update)
End users
Test - Learn- Update 01
A realistic test strategy

11. Establish the test organization – Test-training
Talk about the test prosess and why we test
Motivate the entire project organization("what´s in it for us?")
Teach and train the test resources in only specific test tasks
How to extract test conditions – Test analyses
How to record test results and defects using a test tool
How to participate in the defect process
Keep it simple, but repeat the How to often and the Why in every project meetings! 02
The establishment of the test organization

12. Establish a test framework
Develop templates for Importing requirements and tests to the test administration tool
Develop templates for collecting test conditions from functional domain experts
Prepare the test tool for reporting
Prepare to report on requirement coverage
Prepare to report on test progress
Work with test design
Plan to design high level tests for business process testing
Plan to design exploratory test sessions for risk components testing
Plan to design specification based tests for integration testing 02
The establishment of the test organization

13. Requirements - Coverage
Requirements Hierarchy
An example 02
The establishment of the test organization

14. Templates and test design
Test condition template
Test case template
UAT test result template 02
The establishment of the test organization

15. Work with integrations and Risk components
Workshops with functional domain experts
Look for interesting test conditions to test
The most important integrations
Technical resources and specialists from outside the project
Functional risk components
Domain experts
Non-functional risk components
Technical resources 03
Working with integrations and risk components

16. Work with integrations and Risk components
Risk matrix 03
Working with integrations and risk components

17. Document the business processes - Strategy
Establish the right level of detail for documenting business processes visually
Categorize the business processes into business areas
Plan and execute workshops on each business process
Make the business processes testable for the end users by writing step-by-step guides 04
The process of documenting the business processes

18. Documenting the business processes
Business areas
High level documentation
Low level documentation 04
The process of documenting the business processes

19. Learning by documenting business processes
Test basis developed during the test process
High level business processes documented
Low level business processes documented
The new system is Learned
Functional design adjusted 05
Synergies between the test process and educating the end users

20. Test basis used in training users
Learning by testing
Test basis used in training users
Tested end to end by Functional domain experts
The new system is learned
Low level process documentation adjusted
Low level process documentation used in training end users 05
Synergies between the test process and educating the end users

21. Lessons learned
Focus on testing business processes end to end – not only functionality
Focus on test conditions – not test steps
Focus on low level user documentation – not test cases