The Shift Left Strategy v2.2

50 %
50 %
Information about The Shift Left Strategy v2.2

Published on April 26, 2018

Author: Clearskytest


THE “SHIFT LEFT” STRATEGY: THE “SHIFT LEFT” STRATEGY OVERCOMING THE DOWNWARD SPIRAL OF DOOM Darian Rashid Slide2: 2 Slide3: 3 Late? Too many defects? Not enough content delivered? How did we get here? LETS REWIND: 4 Deploy Design Development Test Requirement Create Test Cases LETS REWIND First time we validate requirements Development has most likely overrun its time Test capacity is constrained Not enough people and time to run System, Integration and Regression effectively Slide5: 5 Slide6: 6 Fix easy issues first “Cannot replicate” Test “Coverage” Technical debt mountain How many issues can be differed? How many issues from previous releases continue to be ignored? AMBIGUITY IN REQUIREMENTS?: AMBIGUITY IN REQUIREMENTS? 7 Leads to missed expectations and rework Discovered well into development cycle Each reworked item could: Impact delivery schedule Incur fines WELL, YES AND NO… Best case: Spend time arguing that the delivery met the requirements Worst Case: Implement CRs during testing Ambiguous requirements Test cases created after development has begun “We just finished up our sprints. Now we’re gonna test.”: “We just finished up our sprints. Now we’re gonna test.” BUT.. THE CODEBASE: 9 THE CODEBASE THE CODEBASE: 10 THE CODEBASE Brittle code Deeply coupled, interconnected web Usually new features on top of legacy code Refactored last in the Regan era Slide11: 11 THE TEAM Slide12: 12 Slide13: 13 EMERGENCY PATCHES: 14 EMERGENCY PATCHES Haven’t accounted for these in the release Are already overcommitted for the next release Cannot drop deliverables RESULT: A compressed time frame for the next release THE “DOWNWARD SPIRAL OF DOOM”: 15 THE “DOWNWARD SPIRAL OF DOOM” EACH RELEASE WORSE THAN THE LAST Slide16: 16 THE PARADIGM SHIFT: Prove Delivery Run Manual Tests Create Test Specifications Create Development Design Documents Develop Code/ Execute Tests, Daily Create Customer Requirements THE PARADIGM SHIFT PROVE SOFTWARE DELIVERY BY: Creating test specifications BEFORE development begins Execute ALL test cases DAILY , even during development Measure test coverage against requirements DAILY Customer Requirements Objectively measurable test specifications CONTAIN ISSUES Slide18: CONVENTIONAL GHERKIN Create Adult Customer Profile with Preferred Phone as Home Phone 1.Launch the eCustomer Application 2.Click on ‘or register’ link GIVEN I am at the Home page WHEN I click on the “Register Now” Link THEN I will be taken to the Register screen AND I will see the following: 3.Enter the following Mandatory Details: (a) enter the valid 10 digit Home phone number (b) Preferred Phone: Home (c)Preferred Contact Method: Email (d)Enter the other details given in the default demographics section of test case initialization table WHEN I enter the following: THEN I will be taken to the Contact Information Screen AND I should see the following Title First Name Middle Name Last Name … Answer (blank) (blank) (blank) (blank) … (blank) First Name Middle Name Last Name … Answer Miss Bethany Jones … 9021 First Name Middle Name Last Name … Answer Miss Bethany Jones … 9021 COMPARE LEFT AND RIGHT What should I see when I click on this link? How do I know which page I’m taken to? How do I know that data loaded that page correctly. If this page isn’t right, the rest of the test cannot proceed. Each cell is a test case. The number of output values to check against will depend on the test case. What other details? Which details are valid details? Which are invalid? TEST SPECIFICATIONS: 19 TEST SPECIFICATIONS Represent the behaviors of the user and the system Created in a simple, human-readable manner Objectively measurable Used as the primary customer and internal acceptance criteria Become the requirements for the development organization Proves delivery Slide20: Test Specs. Pass. Feature complete, add to regression suite. Unit Testing Manual Testing PROVE DELIVERY Creating OBJECTIVELY MEASURABLE test specifications Execute EVERY test cases EVERY day Measure test coverage against requirements DAILY END RESULTS Maintain quality Accurately show % delivery Foresee Risk Execute EVERY Test EVERY Day?: 21 Execute EVERY Test EVERY Day? BUT…: 22 BUT… Number of Tests 1 VM 1000 8.3 Hours 3000 25 Hours 5000 41.6 Hours 10,000 83.3 Hours Average Test Execution Time: 2 minutes Slide23: 23 THE ANSWER HYPERSCALE ON THE CLOUD MAXIMIZE TEST THROUGHPUT THROUGH MASSIVE-SCALE PARALLEL TESTING USING THE CLOUD: 24 MAXIMIZE TEST THROUGHPUT THROUGH MASSIVE-SCALE PARALLEL TESTING USING THE CLOUD CLEAR SKY CORE RUNNERS SYSTEM CAN’T TAKE THE HEAT? KEEP SCALING!: 25 SYSTEM CAN’T TAKE THE HEAT? KEEP SCALING! CLEAR SKY CORE RUNNERS LOAD BALANCER Slide26: THE DEMO THE CONCLUSION: 27 THE CONCLUSION Create unambiguous test specifications, used as requirements Run EVERY test EVERY day to create a safety net Use hyperscaled automation on the cloud to scale Test case Instances under test KEEP QUALITY CONSTANT DAILY

Add a comment

Related presentations