Intelligent Assurance and

Slides:



Advertisements
Similar presentations
Iteration Planning.
Advertisements

Roadmap for Sourcing Decision Review Board (DRB)
Acceptance Testing.
Lecture # 2 : Process Models
The software process A software process is a set of activities and associated results which lead to the production of a software product. This may involve.
Local Touch – Global Reach The New Tester Matthew Eakin, Manager Managed Testing Practice Sogeti, USA.
SCOPE! Simple Review For Your Reference If Needed.
A Framework for Testing in Scrum Projects Assurance with Intelligence Paul Gerrard Gerrard Consulting 1 Old Forge Close Maidenhead Berkshire SL6 2RD UK.
Agile development By Sam Chamberlain. First a bit of history..
Gu & Maher University of Sydney, October 2004 DECO2005 Monitoring Team Process.
Computer Engineering 203 R Smith Agile Development 1/ Agile Methods What are Agile Methods? – Extreme Programming is the best known example – SCRUM.
SE 555 Software Requirements & Specification Requirements Validation.
COMP8130 and 4130Adrian Marshall 8130 and 4130 Test Management Adrian Marshall.
Managing a Project Using an Agile Approach and the PMBOK® Guide
Copyright © 2014 ASTQB Presented by Rex Black, CTAL Introducing ISTQB Agile Foundation Extending the ISTQB Program’s Support Further.
Introduction to Agile.
PopMedNet Software Development Life Cycle Chayim Herzig-Marx Harvard Pilgrim Health Care Institute Daniel Dee Lincoln Peak Partners.
The Project AH Computing. Functional Requirements  What the product must do!  Examples attractive welcome screen all options available as clickable.
Mobile Apps: Review and Retrospectives Refresher Agile Transformation Team 1.
® IBM Software Group © 2006 IBM Corporation PRJ480 Mastering the Management of Iterative Development v2 Module 3: Phase Management - Inception.
 A project is “a unique endeavor to produce a set of deliverables within clearly specified time, cost and quality constraints”
S/W Project Management
Introduction to RUP Spring Sharif Univ. of Tech.2 Outlines What is RUP? RUP Phases –Inception –Elaboration –Construction –Transition.
Chapter 3 – Agile Software Development 1Chapter 3 Agile software development.
© Blackboard, Inc. All rights reserved. Back to the Feature: An Agile, User-centric Software Development Lifecycle Cindy Barry Senior Product Manager Martha.
Current Trends in Systems Develpment
Demystifying the Business Analysis Body of Knowledge Central Iowa IIBA Chapter December 7, 2005.
CS 360 Lecture 3.  The software process is a structured set of activities required to develop a software system.  Fundamental Assumption:  Good software.
Testing Challenges in an Agile Environment Biraj Nakarja Sogeti UK 28 th October 2009.
Your Quiz 1) Name the process groups. 5 pts 2) What are the 4 areas of the Balanced Scorecard? 8 pts 3)Name 4 of the Knowledge Areas 4 pts 4) If someone.
Certificate IV in Project Management Introduction to Project Management Course Number Qualification Code BSB41507.
Industrial Software Project Management Some views on project managing industrial and business software projects.
What is a Business Analyst? A Business Analyst is someone who works as a liaison among stakeholders in order to elicit, analyze, communicate and validate.
AXIOMS Paul Gerrard THE TESTING OF.
Object-oriented Analysis and Design Stages in a Software Project Requirements Writing Analysis Design Implementation System Integration and Testing Maintenance.
Chapter 2 – Software Processes Lecture 1 Chapter 2 Software Processes1.
BSBPMG404A Apply Quality Management Techniques Apply Quality Management Techniques Project Quality Processes C ertificate IV in Project Management
Requirements Engineering Requirements Engineering in Agile Methods Lecture-28.
Modelling the Process and Life Cycle. The Meaning of Process A process: a series of steps involving activities, constrains, and resources that produce.
An Agile Requirements Approach 1. Step 1: Get Organized  Meet with your team and agree on the basic software processes you will employ.  Decide how.
Software Development Process CS 360 Lecture 3. Software Process The software process is a structured set of activities required to develop a software.
Lectures 2 & 3: Software Process Models Neelam Gupta.
Overview PRINCE Hogeschool Rotterdam. 2 Project definition  A project is a temporary organization that is created for the purpose of delivering.
Copyright 2015, Robert W. Hasker. Classic Model Gathering Requirements Specification Scenarios Sequences Design Architecture Class, state models Implementation.
P3 Business Analysis. 2 Section F: Project Management F1.The nature of projects F2. Building the Business Case F4. Planning,monitoring and controlling.
ServiceNow Special Interest Group Phased WorkTemplate Information & Educational Technology 1 DRAFT
Informed Traveler Program and Applications Agile / Scrum Overview Jerry Inberg.
Adaptive Software Development Process Framework. Version / 21 / 2001Page Project Initiation 2.0 Adaptive Cycle Planning 5.0 Final Q/A and.
PRINCE2 and the PMBoK guide
Scrum CS These outstanding slides were created by Kevin Schenk, BS in Computer Science, Purdue University, 2012.
Scrum CS These outstanding slides were created by Kevin Schenk, BS in Computer Science, Purdue University, 2012.
CS 389 – Software Engineering
September 20, 2017 Agile Techniques Workshop Susan Futey
Information Technology Project Management – Fifth Edition
By: By: Agile Scrum Master Online Training.
Chapter 2 SW Process Models
Process Improvement With Roles and Responsibilities explained
Chapter 3: The Project Management Process Groups: A Case Study
Project Management and the Agile Manifesto
Assurance: the Evolution of Test Management
How to Successfully Implement an Agile Project
Chapter 2 – Software Processes
Attend|Learn|Grow Taking Your Career to the Next Level
Chapter 2 Software Processes
Test Management without Test Managers
Project Ideation Agile Down-to-Earth © 2016.
Introducing ISTQB Agile Foundation Extending the ISTQB Program’s Support Further Presented by Rex Black, CTAL Copyright © 2014 ASTQB 1.
Quality Assurance in an Agile Development Team Michelle Wu 2018 PNSQC
Executive Project Kickoff
Presentation transcript:

Intelligent Assurance and Testing @paul_gerrard 1-Apr-17 Agile Test Strategy Paul Gerrard paul@gerrardconsulting.com @paul_gerrard gerrardconsulting.com

Assurance, Re-Training, Mentoring 1-Apr-17 Overview What is Agile Test Strategy? Project Profiling (Test Strategy as) Agile Interventions Test Automation What’s Left? Summary Q&A © Aqastra Limited 2008 Intelligent Definition and Assurance

What is Agile Test Strategy? Agile Strategy – an oxymoron?

Intelligent Definition and Assurance Agile Test Strategy What do we mean by this? AGILE Test Strategy – how to create a test strategy in an Agile way? AGILE Test Strategy – a test strategy for an Agile project? We’ll look at how we created an Agile approach to strategy, but we’ll spend more time on strategy for an Agile project. Intelligent Definition and Assurance

Google “Agile Test Strategy” There are plenty of recipes out there Most offer a selection of techniques but don’t provide much guidance on how to blend them We need to know how to make choices, not just know what choices exist Strategy is a thought process, not a document Although you might document the ideas for reuse, as a reminder or ‘for the record’. Intelligent Definition and Assurance

Intelligent Definition and Assurance Agile governance Governance is the act of governing. It relates to decisions that define expectations, grant power, or verify performance Wikipedia Define expectations – DEFINITION of need Grant power – DELEGATION to a project team Verify performance – ASSURANCE of solution. Intelligent Definition and Assurance

Strategy helps you decide what to do The strategy presents some decisions that can be made ahead of time Defines the process or method or information that will allow decisions to be made (in project) Sets out the principles (or process) to follow for uncertain situations or unplanned events In a structured/waterfall environment, most questions answered off-the-shelf – “A-style, ready for anything” In an Agile environment – might have some ready-made policies but we manage scope and adapt (mostly C?) Intelligent Definition and Assurance

Contexts of Test Strategy Axioms Communication Early Testing Risks De-Duplication Test Strategy Opportunities Goals Automation Culture Contract User involvement Constraints Human resource Artefacts Skills Environment Process (lack of?) Timescales

Traditional v Agile test strategy Traditional – structured, goal/risk-driven Identify stakeholders; what are their goals? Product risk analysis Allocate risks/goals to test stages Formulate test stage definitions (entry/exit criteria, environments, tools etc. etc. Agile – interventionist, consensus-driven Project profiling to set the testing theme Identify testing interventions (perhaps better, contributions) in the Agile process Test policy overlays the process; catches exceptions. Intelligent Definition and Assurance

Project Profiling Select a profile for your project first, then choose the aspects of test strategy that suite your project

Intelligent Definition and Assurance Template-driven? Bah! So this is just a template copy and edit process? Won’t you always end up with the same document? Profiling doesn’t need to be prescriptive No need to write a document if you don’t need to But if company policy or common sense dictates certain approaches, save yourself some time Create a set of deeper, more detailed questions to be answered (Pocketbook) Profilers are really just checklists: heuristic guidelines designed to help you make choices and trade-offs. Intelligent Definition and Assurance

Using a Project Profiler to Derive a Test Strategy and Project Plan Environment Story Guideline Tools Incident Mgt. Using a Project Profiler to Derive a Test Strategy and Project Plan (A government client example) Project Plan Test Assurance Project Manager Business, Project Team and Boards Consultation Cerise Orange Green Test Plan Items Product Risks Waterfall Test Strategy SCRUM/Agile Project Profiler Risk Profiler Blue Unknowns The Project Profiler (with Test Assurance) helps Project Managers to: Select a project style that fits (Waterfall or Agile) Identify the product risks that need testing Identify test activities to include in project plans Carefully define the scope of the project Intelligent Definition and Assurance

Project profiling process Task 1 Have the Information you need to hand 2 Project Profiler (section 3): Select the statements that best match your project context. The Blue column indicates that you need more information – consult your stakeholders, team or relevant Board(s). 3 Generic Risk Profiler (section 4): Consider the generic project risks – which are significant for your project? Can testing help? 4 Product Risk Profiler (Section 5): Consider the functional and non-functional risks that most concern your stakeholders – should they be tested? 5 Actions and Test Activities (Section 6): Consider the actions that prompt your ‘next steps’ and the test activities that should be incorporated into your project plan. 6 Create your Test Strategy from the Test Strategy Framework Template 7 Incorporate the activities from stage 5 and identified in 6 into your Project Plan. Intelligent Definition and Assurance

Project Profiler (part of section 3) Project Aspect Cerise Orange Green Blue Responsibility for Acceptance Users will take responsibility for UAT; they have UAT experience Users will be responsible for UAT but have no test experience Users will take part in UAT or witness tests at critical periods, and will review the outcome Users are unwilling/unable to take part in UAT; reluctant to make the acceptance decision or not known Requirements (Sources of Knowledge) New system replaces a well-understood existing system; users have clear vision of system goals and prefer to document their requirements up-front Users want to collaborate to jointly define requirements and meet them incrementally or iteratively Users put the onus of requirements elicitation on the project; requirements and the solution will evolve Inexperienced users who are unable or unwilling to collaborate with requirements gathering Requirements Stability New system is a functional replacement of an existing system or a well-defined process (requirements can be fixed early on) New system replaces an existing system with enhancements or an established (but not necessarily documented process) New system supports a new business need; business process exists but will change/evolve; users have experience of requirements New system supports a new business need; business process is not yet known; users have no experience or requirements Visibility, Formality High visibility/risk to general public; formal progress reporting required at board level; fixed scope and deliverables; formal approvals and sign-offs High visibility/risk to business; formal progress reporting required; some defined deliverables, some deliverables will emerge/evolve; some approvals and sign-offs Relatively low business-risk; informal progress reporting is acceptable; partial solution may suffice, incremental/iterative delivery Potentially, high visibility, high risk project, uncertain impact on the business External Dependencies More than one or new external suppliers responsible for development (and supplier testing) Single, known supplier responsible for development (and supplier testing) In-house development, no external dependencies Dependencies on external suppliers, their responsibilities or competence not yet known Etc. Intelligent Definition and Assurance

Project types - examples Cerise Structured, waterfall style of project (and includes COTS projects) Orange Iterative/prototyping style of project using SCRUM in a formal way and having dedicated resources for the Business Analyst and Tester roles. Green A project using SCRUM in a less formal way but not having dedicated resources for the Business Analyst and/or the Tester roles. Blue Blue column statements describe where there is insufficient information available to identify the style of project and the recommendation must be that some further investigation is required. Intelligent Definition and Assurance

(Test Strategy as) Agile Interventions I’m using Scrum/Sprint terminology, but you don’t have to of course

Interventions (government client example) No. Activity When? 1 Story Challenge As stories are added to the Product Backlog 2 Story Definition As stories are added to a Sprint Backlog These activities are repeated for each Sprint iteration 3 Daily Stand-Up Once per day during the Sprint 4 Story Refinement Occurs throughout the Sprint as new information emerges 5 Developer Testing Occurs throughout the Sprint as the developer codes the stories 6 Integration (and incremental System) Testing During and at the end of each sprint, including the final sprint 7 System Testing At the end of each sprint, including the final sprint 8 User Acceptance Testing 9 Non-functional Testing and Pre- Production Testing Expected to take place on an as-needs basis. On the following slides, we highlight 8 interventions Some are test phases, but some aren’t Intelligent Definition and Assurance

Project Level Test Activities (This diagram shows three sprints, but there could be more or fewer) Story Challenge Suggest ‘what-ifs’ to challenge new stories and define story headlines Sprint Backlog Sprint Backlog Sprint Backlog 2. Story Definition Introduce scenarios to enhance the Acceptance Criteria Sprint 1 Sprint 2 Sprint 3 Developed Stories Developed Stories Developed Stories New Code Integration into Existing Code base Automated testing 6. Integration Test 6. Integration Test 6. Integration Test Increasing Scope of Sys. Test and UAT 7. System Test 8. User Test Increasing Scope of Integration, System and Users Testing Complete Tests after Final Sprint

Project Level Test Activities (This diagram shows three sprints, but there could be more or fewer) Story Challenge Suggest ‘what-ifs’ to challenge new stories and define story headlines Sprint Backlog Sprint Backlog Sprint Backlog 2. Story Definition Introduce scenarios to enhance the Acceptance Criteria Sprint 1 Sprint 2 Sprint 3 Developed Stories Developed Stories Developed Stories New Code Integration into Existing Code base Automated testing 6. Integration Test 6. Integration Test 6. Integration Test Increasing Scope of Sys. Test and UAT 7. System Test 8. User Test Increasing Scope of Integration, System and Users Testing Complete Tests after Final Sprint

Project Level Test Activities (This diagram shows three sprints, but there could be more or fewer) Story Challenge Suggest ‘what-ifs’ to challenge new stories and define story headlines Sprint Backlog Sprint Backlog Sprint Backlog 2. Story Definition Introduce scenarios to enhance the Acceptance Criteria Sprint 1 Sprint 2 Sprint 3 Developed Stories Developed Stories Developed Stories New Code Integration into Existing Code base Automated testing 6. Integration Test 6. Integration Test 6. Integration Test Increasing Scope of Sys. Test and UAT 7. System Test 8. User Test Increasing Scope of Integration, System and Users Testing Complete Tests after Final Sprint

Project Level Test Activities (This diagram shows three sprints, but there could be more or fewer) Story Challenge Suggest ‘what-ifs’ to challenge new stories and define story headlines Sprint Backlog Sprint Backlog Sprint Backlog 2. Story Definition Introduce scenarios to enhance the Acceptance Criteria Sprint 1 Sprint 2 Sprint 3 Developed Stories Developed Stories Developed Stories New Code Integration into Existing Code base Automated testing 6. Integration Test 6. Integration Test 6. Integration Test Increasing Scope of Int. Sys. and UAT 7. System Test 8. User Test Increasing Scope of Integration, System and Users Testing Complete Tests after Final Sprint

Project Level Test Activities (This diagram shows three sprints, but there could be more or fewer) Story Challenge Suggest ‘what-ifs’ to challenge new stories and define story headlines Sprint Backlog Sprint Backlog Sprint Backlog 2. Story Definition Introduce scenarios to enhance the Acceptance Criteria Sprint 1 Sprint 2 Sprint 3 Developed Stories Developed Stories Developed Stories New Code Integration into Existing Code base Automated testing 6. Integration Test 6. Integration Test 6. Integration Test Increasing Scope of Int. Sys. and UAT 7. System Test 8. User Test Increasing Scope of Integration, System and Users Testing Complete Tests after Final Sprint

Test Activities in the Sprint 3. Daily Stand-Up Report anomalies found, stories tested, amended, created 5) Developer Testing Private ad-hoc tests and build/run automated unit tests Daily Scrum Stand-Up Meeting 24 Hours 4. Story Refinement Refine scenarios to enhance story definition, create system tests as stories, as required 6) Integration/System Testing Incorporate automated unit tests into the CI regime. On weekly basis and at end of Sprint, deploy to System test environment and tester runs system tests. 2-4 Weeks Backlog tasks expanded by team Sprint Backlog Potentially Shippable Product increment Product backlog As prioritised by Product Owner Intelligent Definition and Assurance

Test Activities in the Sprint 3. Daily Stand-Up Report anomalies found, stories tested, amended, created 5) Developer Testing Private ad-hoc tests and build/run automated unit tests Daily Scrum Stand-Up Meeting 24 Hours 4. Story Refinement Refine scenarios to enhance story definition, create system tests as stories, as required 6) Integration/System Testing Incorporate automated unit tests into the CI regime. On weekly basis and at end of Sprint, deploy to System test environment and tester runs system tests. 2-4 Weeks Backlog tasks expanded by team Sprint Backlog Potentially Shippable Product increment Product backlog As prioritised by Product Owner Intelligent Definition and Assurance

Test Activities in the Sprint 3. Daily Stand-Up Report anomalies found, stories tested, amended, created 5) Developer Testing Private ad-hoc tests and build/run automated unit tests Daily Scrum Stand-Up Meeting 24 Hours 4. Story Refinement Refine scenarios to enhance story definition, create system tests as stories, as required 6) Integration/System Testing Incorporate automated unit tests into the CI regime. On weekly basis and at end of Sprint, deploy to System test environment and tester runs system tests. 2-4 Weeks Backlog tasks expanded by team Sprint Backlog Potentially Shippable Product increment Product backlog As prioritised by Product Owner Intelligent Definition and Assurance

Test Activities in the Sprint 3. Daily Stand-Up Report anomalies found, stories tested, amended, created 5) Developer Testing Private ad-hoc tests and build/run automated unit tests Daily Scrum Stand-Up Meeting 24 Hours 4. Story Refinement Refine scenarios to enhance story definition, create system tests as stories, as required 6) Integration/System Testing Incorporate automated unit tests into the CI regime. On weekly basis and at end of Sprint, deploy to System test environment and tester runs system tests. 2-4 Weeks Backlog tasks expanded by team Sprint Backlog Potentially Shippable Product increment Product backlog As prioritised by Product Owner Intelligent Definition and Assurance

4. Story Refinement (example definition) Objectives To define acceptance criteria for all stories that are included in a Sprint as they are worked on by development To define scenarios that describe the tests and expected behaviours of the System Improve understanding of the requirement and communicate anomalies to developers To identify System Tests that exercise functionality of multiple stories that can be system tested in this sprint To assure the completeness for stories in the current Sprint What’s being tested? Stories to be included in the current Sprint Deliverables Refined story definitions with defined acceptance criteria and scenarios, where appropriate System tests Responsibilities (Orange) Tester – challenges stories by suggesting potential scenarios, new stories, story merges and splits; performs ad-hoc testing with/on behalf of developers; assures completeness of stories. Developers – considers stories, evaluates impact on development Product Owner or Analyst – collates feedback and decisions on stories Product Owner – approves changes to stories, accepts completeness of stories Scrum Master – monitors progress; evaluates impact on resources and schedules Responsibilities (Green) Not performed in Green projects Baseline Story Guideline (reference 3) Entry Criteria On commencement of the Sprint Exit Criteria When all stories within a Sprint are considered complete Queries, anomalies, discrepancies and inconsistencies have been eliminated or explained System Tests appropriate to the Sprint have been defined Definition of acceptance is agreed with Product Owner Intelligent Definition and Assurance

Could you create an Agile Test Strategy without automation? Test Automation Could you create an Agile Test Strategy without automation?

Brian Marick’s Testing quadrants Assurance, Re-Training, Mentoring 1-Apr-17 Brian Marick’s Testing quadrants Intelligent Definition and Assurance © Aqastra Limited 2008

Test Automation Pyramid – Lisa Crispin’s version (Google others) Pyramid reflects the relative numbers of tests Focus on unit/component Acceptance of “Services” GUI are end-to-end Manual checking the exception? Intelligent Definition and Assurance

Where do you automate? Stories/ Scenarios Test Code GUI Test Tool 3. Non-Technical testers write scripts Stories/ Scenarios Tools Experts write interface Test Code 4. Programmers write low level HTTP GET/POST calls through a driver that simulates a browser GUI Test Framework GUI Test Tool Unit Test Framework 2. Technical Testers code scripts directly Browser HTTP Driver 1. Programmers write unit tests or execute embedded unit tests using a unit test framework to test components HTTP/S HTTP/S Inter/Intranet HTTP/S Test Code Web Server App. Server Unit Test Framework API DB Server

Intelligent Definition and Assurance Distributed testing Use business stories and scenarios/acceptance criteria to validate requirements Reuse those stories to feed ‘Acceptance-Driven Development’ BDD/TDD process Automated tests are an Anti-Regression tactic Automated tests don’t replicate manual tests; think of them as a ‘change trip-wire’ that triggers an alarm, if tripped. Intelligent Definition and Assurance

Deriving scenarios to test To understand feature scope? To get stakeholder to accept? To validate the requirement? To estimate the work to build this feature? To system test this feature? To unit test this feature? Story Challenge Story Refinement Story Definition Iteration Planning System Testing Developer Testing Scenarios are created to meet several goals Intelligent Definition and Assurance

What’s Left?

Other aspects of test policy Definitions (of done etc.) Incident management Test automation Story format e.g. Gherkin Environment request and management Regression testing (at what levels) Test deliverables and documentation. Intelligent Definition and Assurance

Intelligent Definition and Assurance The Three Amigos Business Analyst Liaises and manages stakeholders and their needs Transforms business requirements into specification (at multiple levels) Developer Scopes, designs, builds, tests and delivers features Tester Challenges the thinking on the project Performs ‘Assurance in the small’. Intelligent Definition and Assurance

The tester’s contribution to testing _________ feature/story acceptance criteria _________ the developers to unit test (auto) _________ feature/story acceptance _________ acceptance test _________ service/UI level automation Scope: from low-level detail to system integration Liaison with integration testers and feedback Fill in the blanks yourself; negotiate with your team. Intelligent Definition and Assurance

Assurance, Re-Training, Mentoring 1-Apr-17 Summary © Aqastra Limited 2008

Intelligent Definition and Assurance Close Agile test strategy has its place and many aspects of test can be pre-defined Importantly, we use a principled approach to deal with the unexpected Project profiling can help Testing as interventions, rather than test phases The testing role is split at least three ways – the tester doesn’t own testing – think TESTMASTER Test automation in the context of Specification by Example, requirements validation, BDD, TDD. Intelligent Definition and Assurance

Intelligent Assurance and Testing @paul_gerrard 1-Apr-17 Agile Test Strategy Paul Gerrard paul@gerrardconsulting.com @paul_gerrard gerrardconsulting.com