24. ACCEPTANCE: A SOFTWARE ERROR OCCURS AT
HIGH VEHICLE SPEED. REBOOT WITHIN 50 MSEC.
Source • System
Stimulus • Software error
Artifact • System
Env • High vehicle speed
Respons
e
• Reboot occurs
Respons
e
Measure
• Time to reboot up to 50 msec.
25. EXPLAINING ACCEPTANCE: GHERKIN
Given
Environment
• High vehicle
speed
Artifact
• System
As
Source
• System
When
Stimulus
• Software error
Then
Response
• Reboot occurs
Response
Measure
• Time to reboot up
to 50 msec.
27. TRACEABILITY: ACCEPTANCE TREE
1. Implementation directly linked to Quality
attribute
2. Quality attribute linked to business driver
3. Priority of the scenario shows might be a start
point for its automation
28. REAL USE CASE
Project specifics
Disk level data encryption system
Goal:
form acceptance for the system
Support large number of OS
Test in the cloud
Test definitions
None
Technology
Amazon + LAMP
Resources
Senior part time and junior full time developer
31. GETTING ANALYSIS DATA TOGETHER
Factor QAW-based Classic analysis approach
Work with stakeholders It’s better to have everybody in one
location, at least for a short period.
You can have several separate
sessions with technical
representatives only
Documentation That should be part of stakeholders
knowledge only
Might be outdated
Domain knowledge Not deep knowledge – participants
are the knowledge holders
Required
Rough Estimate 2-3 days 3-5 days
32. RESULT
Acceptance test suite definition (~30 tests)
Mini-framework implementation
Jenkins integration
Project was DECLINED to be released
because of NOT passing the automation tests
33.
34. RECAP: PROCESS DEFINITION
•Break scenario into
steps
•Define steps in QC
language
•Generate test stubs
•Prioritize
•Build timeline
•Implement
•Define Business Goals
•Gather Quality
Attributes
•Generate Scenarios
Architecture
Form
Acceptance
Test solution
Trace and
update