IBM Software Group Collaborative Application Lifecycle Management C ALM

IBM Software Group Welcome to the Technical Exploration Center ● Introductions ● Access restrictions ● Restrooms ● Emergency Exits ● Smoking Policy ● Breakfast/Lunch/Snacks – location and times ● Special meal requirements? © 2009 IBM Corporation Collaborative Application Lifecycle Management 2

IBM Software Group Introductions ● Please introduce yourself ● Name and organization ● Current integration technologies/tools in use What do you want out of this Exploration session? © 2009 IBM Corporation Collaborative Application Lifecycle Management 3

IBM Software Group Agenda ● ● ● ● Introduction to Collaborative Application Lifecycle Management (C/ALM) Lab Overview Module 1 Update the Product Backlog Module 2 Plan the Sprint Module 3 Sprint Module 4 Respond to a Test Failure Session Summary © 2009 IBM Corporation Collaborative Application Lifecycle Management 4

IBM Software Group Objectives ● Explore how the Rational tools support collaborative application lifecycle management by 4 Enabling teams to collaborate in real time in the context of the work they are doing, especially in globally diverse environments 4 Enabling projects to be managed more effectively by providing visibility into accurate project health information drawn directly from actual work 4 Automating traceability and auditability by managing artifacts and their inter-relationships across the lifecycle, empowering teams to deliver more value ● Provide a hands on experience using Rational Team Concert and Rational Quality Manager to automate the software delivery process © 2009 IBM Corporation Collaborative Application Lifecycle Management 5

IBM Software Group Introduction to Collaborative Application Lifecycle Management (C/ALM) An IBM Proof of

IBM Software Group ALM Integrations. . . a blessing and a challenge. . . Integrations are the #1… 4 Reason customers buy Rational products. 4 Problem after they purchase. Brittle integrations Need to fully and seamlessly integrate the work of testers, business analysts, and developers It is hard to enact a process Inconsistency among products – user interface, underlying logic, storage Little or no project visibility – project management and reports need to span multiple repositories & time zones Proprietary repository API’s High maintenance and administration costs Our customers have requested integrations for many years, this is not new. What’s new is our approach to solving the problem via the Jazz Integration Architecture. © 2009 IBM Corporation Collaborative Application Lifecycle Management 7

IBM Software Group Integrations the old way Tool A Tool E Tool F Tool

IBM Software Group The Internet – an inspiration for an architecture ● Amazingly scalable ● Integrates information on a massive scale ● Infinitely extensible ● Collaboration on unprecedented scale ● World-wide information visibility © 2009 IBM Corporation Collaborative Application Lifecycle Management 9

IBM Software Group What does Internet inspiration mean? ● Data specified independently of tools ● All data are resources with URLs ● Multiple Tools access data ● References are embedded URLs ● Resources have representations ● Unprecedented extensibility ● Independent search and query ● REST (Representational State Transfer) Semantic web “Linked data”: http: //www. w 3. org/Design. Issues/Linked. Data. html © 2009 IBM Corporation Collaborative Application Lifecycle Management 10

IBM Software Group Inspired by the world-wide-web The evolution of software delivery: Surf the “ALM web” Jazz Integration Architecture Open Services for Lifecycle Collaboration C/ALM scenarios public on Jazz. net & open-services. net Data Workflow Proven architecture and principles of the Internet ● Presentation / Semantic Split ● Open, Extensible and On-Demand Open Approach to define the SDLC Data model ● Cohesive, open and customizable data model for the whole Software Delivery Life cycle ● Collaborate openly on common resource definitions “Outside-In” scenarios ● “Real-World” End-to-end lifecycle ● Role-based, task-based user experiences All three of these areas must be addressed © 2009 IBM Corporation Collaborative Application Lifecycle Management 11

IBM Software Group Team collaboration based on middleware services Built on an extensible platform and common repository Tool A Tool B Tool C Tool D Tool E Tool F Events & Services Team Collaboration Services © 2009 IBM Corporation Collaborative Application Lifecycle Management 12

IBM Software Group Project status, charts, reports Multi-repository data warehouse Web based UI Project & Iteration Plans Reports, Feeds Software Development Discipline-Specific Capabilities Requirements Management & Definition Collaborative Development Enterprise Build Management Quality Management Automation & Scanning Asset Management Discipline-specific pluggable modules Deep functionality Eclipse and web UI based on need Integrated Practitioner tools Project Health & Dashboard Jazz Foundation Services Cross-discipline integration Enterprise-scale Heterogeneous vendor support Cross-repository services Presenta-tion Discovery Storage Query Data warehouse Process Collaboration Admin Global Development and Delivery IBM & Partner Ecosystem © 2009 IBM Corporation Collaborative Application Lifecycle Management 13

IBM Software Group Optimizing desired business outcomes Architect Business Planning & Alignment Automated status reporting derived from evolving engineering artifacts can improve productivity by 5 -10% Developer Configuration & Change Management Quality Management Business Executive Best practices in scope management can improve predictability of project delivery by 20 -30% Analyst Being able to collaborate on work items, defects and build errors can reduce late rework by 25 -50% Source: Based on hundreds of client interactions of the IBM Rational Services Organization, as observed by VP Services, IBM Rational © 2009 IBM Corporation Collaborative Application Lifecycle Management 14

IBM Software Group What is C/ALM 1. 0 ● One of many projects contributing to Rational’s C/ALM strategy. C/ALM 1. 0 will provide integrations between 4 Requirements Composer 2. 0 4 Team Concert 2. 0 4 Quality Manager 2. 0 4 all of which leverage Jazz Foundation 1. 0. x ● C/ALM 1. 0 builds on the Jazz Foundation integration support 4 Common User Interface elements 4 Collaboration in context with cross repository linking & queries 4 Dashboards supporting transparency of C/ALM information ● Integration capabilities exist in each product 4 When deployed together, the integration scenarios provide a C/ALM solution 4 There is no additional software needed to enable the integrations 4 We expect the integrations to deepen over time and to include many other products © 2009 IBM Corporation Collaborative Application Lifecycle Management 15

IBM Software Group Themes ● Connect the work of Analysts, Developers and Testers ● Enable users to weave a ‘web’ of ALM resources that they can use to collaborate, navigate and track status 4 In-context collaboration 4 Navigation 4 Transparency ● Enable our customers to choose the tools that best suit their needs by providing flexible and open integrations ● Collaborate with and contribute to OSLC specifications and implementations © 2009 IBM Corporation Collaborative Application Lifecycle Management 16

IBM Software Group Collaboration fosters business alignment & high quality Requirement links foster clarity Developer Rational Team Concert Analyst Tester Rational Requirements Composer Rational Quality Manager Developers link to requirements from work-items Testers link to requirements from test plans and test cases Analysts communicate requirements with links to development and test plans © 2009 IBM Corporation Collaborative Application Lifecycle Management 17

IBM Software Group Collaboration fosters business alignment & high quality Defect links speed time to resolution Analyst Rational Requirements Composer Developer Rational Team Concert Tester Rational Quality Manager Test Execution Results link to defects Defects can link to requirements Defects link to Test Execution results © 2009 IBM Corporation Collaborative Application Lifecycle Management 18

IBM Software Group Common UI elements aid in ease-of-use Common banners Dashboards in all products aid in transparency Link Dialogs enable cross-repository linking Rich hovers provide at-aglance, incontext information 19 © 2009 IBM Corporation Collaborative Application Lifecycle Management 19

IBM Software Group C/ALM Cross Product Query Viewlets C/ALM queries leverage links to provide

IBM Software Group C/ALM Mash-up Dashboard – RTC example Developers have insight into requirements in Rational Requirements Composer © 2009 IBM Corporation Collaborative Application Lifecycle Management 21

IBM Software Group Link Creation independent of product choice Quality Manager ● A common ‘delegated’ approach to artifact creation & linking in all products. 4 Product A asks Product B what artifacts it can create or link to 4 Product B provides the UI for creating or linking to its artifacts 4 Link types in Foundation 4 OSLC implementations (Integrating application uses a single URL) ● Provides choice and flexibility 4 Project associations drive link choices 4 Reduces the coupling between applications, enabling independent upgrades 4 Minimizes a products knowledge about the other repository artifacts ● Example: link RQM test execution failure to an RTC defect © 2009 IBM Corporation URL calls RTC link picker Collaborative Application Lifecycle Management RTC provides UI details & semantics 22

IBM Software Group Summer 2009 – Team Concert 2. 0 & Quality Manager 2. 0 CQ integrations included ● Quality Manager users can: 4 Testers can link test cases to Team Concert plan items 4 Testers can create / link to defects to Team Concert 4 Submit defects to Clear. Quest 4 CALM Queries: Tests blocked by Defects, Defects blocking Test. ● Team Concert users can: 4 Developers can navigate links to test execution results / test cases 4 CALM Queries: Defects blocking Test. 4 Link work-items and Clear. Quest records ● Administrators can: 4 Establish Quality Manager & Team Concert repositories as “friends” 4 Link development and testing project areas 4 Configure the Clear. Quest Bridge for Team Concert 4 Configure the Clear. Quest defect provider for Team Concert © 2009 IBM Corporation Collaborative Application Lifecycle Management 23

IBM Software Group Fall 2009 – Add Requirements Composer 2. 0 ● Requirements Composer users can: 4 Requirements sets link to Quality Manager test plans 4 Requirements create / link to Quality Manager test cases 4 Requirement create/link to Team Concert plan items 4 CALM Mash-up Dashboards containing viewlets from Team Concert ● Quality Manager (2. 0. 0. 1) users can: 4 Link Test Plans to Composer requirements sets 4 Link test cases to Composer requirements ● Team Concert (2. 0. 0. 2) users can: 4 Link plan items to Composer requirements 4 Navigate links to Composer requirements 4 CALM Mash-up Dashboards containing viewlets from Composer © 2009 IBM Corporation Collaborative Application Lifecycle Management 24

IBM Software Group Supported Versions ● Jazz Foundation 1. 0 see Foundation 1. 0 Release Plan ● July: RTC/RQM 2. 0 ● Fall: RTC 2. 0. 0. 2, RQM 2. 0. 0. 1 and RRC 2. 0 ● RTC / z support (releases trail RTC 2. 0) © 2009 IBM Corporation Collaborative Application Lifecycle Management 25

IBM Software Group C/ALM 1. 0 Supported Configuration 1 Single LDAP for user groups Individual application servers. Single Database server hosting all three databases reduces infrastructure & provides database back-up User synchronization with LDAP server Documented on jazz. net: https: //jazz. net/wiki/bin/view/Main/CALMJazz. Config © 2009 IBM Corporation Collaborative Application Lifecycle Management 26

IBM Software Group C/ALM on Jazz. net © 2009 IBM Corporation Collaborative Application Lifecycle

IBM Software Group Community: open-services. net Wiki and mailing lists License terms 4 Encourage contribution to and implementation of specifications 4 Specifications are created under a Creative Commons Attribution copyright license 4 Covenant – specification implementers are free from patent claims by contributors 4 Process Stages 4 4 © 2009 IBM Corporation Collaborative Application Lifecycle Management Scope (scenarios) Draft Convergence (IP covenant) Final Specification 28

IBM Software Group © 2009 IBM Corporation Collaborative Application Lifecycle Management 29

IBM Software Group Scenario for Po. T Labs ● You will play the role of various members on a project (called SQUAWK) as they work through the definition, prioritization, implementation, testing and fixing of a new requirement: 4 Bob: The product owner 4 Scott: The Scrum master 4 Deb: A developer 4 Tanuj: The test lead 4 Marco: The development lead ● The project follows the Scrum methodology. ● You will be using Rational Team Concert and Rational Quality Manager as the project’s collaborative development environment. © 2009 IBM Corporation Collaborative Application Lifecycle Management 30

IBM Software Group Quick Scrum Overview ● “Scrum” is an agile process for software development. (Often spelled “SCRUM”, although not an acronym. ) ● Scrum roles: 4 Scrum Master: Individual who maintains the processes (essentially a project manager). Responsible for removing impediments to team progress. 4 Product Owner: Represents the stakeholders 4 Team: Cross-functional group of people who do the work ● Scrum concepts: 4 Story: A brief description of a user need. Each story has a relative priority and complexity. 4 Product backlog: A prioritized set of high-level requirements of work, usually described in stories. 4 Sprint: A 2 -to-4 week period in which the team creates a potentially shipping product. A Scrum project consists of several sprints. 4 Sprint planning meeting: A meeting to determine which backlog items go into a sprint. 4 Scrum: A short daily meeting where each team member shares what they accomplished yesterday, what they will work on today and what, if anything is blocking their progress. © 2009 IBM Corporation Collaborative Application Lifecycle Management 31

IBM Software Group Sequence of events Create the new story Prioritize the backlog Describe the highest priority features Bob (product owner) Define the sprint goal Agree to items for the backlog Align the test sprint plan Check the team’s alignment Marco Tanuj Scott Deb (Development (Developer) (Test Lead) (SCRUM Master) Lead) Add development tasks Create script and execution records Develop “surfer squawker” Monitor the build status Monitor the integration build Execute test & submit defect Confirm defect is fixed Triage defects Fix defect & deliver change Track status © 2009 IBM Corporation Collaborative Application Lifecycle Management 32

IBM Software Group Sequence of events – Lab 1 Create the new story Prioritize the backlog Describe the highest priority features Bob (product owner) Define the sprint goal Agree to items for the backlog Align the test sprint plan Check the team’s alignment Marco Tanuj Scott Deb (Development (Developer) (Test Lead) (SCRUM Master) Lead) Add development tasks Create script and execution records Develop “surfer squawker” Monitor the build status Monitor the integration build Execute test & submit defect Confirm defect is fixed Triage defects Fix defect & deliver change Track status © 2009 IBM Corporation Collaborative Application Lifecycle Management 33

IBM Software Group Sequence of events – Lab 2 Create the new story Prioritize the backlog Describe the highest priority features Bob (product owner) Define the sprint goal Agree to items for the backlog Align the test sprint plan Check the team’s alignment Marco Tanuj Scott Deb (Development (Developer) (Test Lead) (SCRUM Master) Lead) Add development tasks Create script and execution records Develop “surfer squawker” Monitor the build status Monitor the integration build Execute test & submit defect Confirm defect is fixed Triage defects Fix defect & deliver change Track status © 2009 IBM Corporation Collaborative Application Lifecycle Management 34

IBM Software Group Sequence of events – Lab 3 Create the new story Prioritize the backlog Describe the highest priority features Bob (product owner) Define the sprint goal Agree to items for the backlog Align the test sprint plan Check the team’s alignment Marco Tanuj Scott Deb (Development (Developer) (Test Lead) (SCRUM Master) Lead) Add development tasks Create script and execution records Develop “surfer squawker” Monitor the build status Monitor the integration build Execute test & submit defect Confirm defect is fixed Triage defects Fix defect & deliver change Track status © 2009 IBM Corporation Collaborative Application Lifecycle Management 35

IBM Software Group Sequence of events – Lab 4 Create the new story Prioritize the backlog Describe the highest priority features Bob (product owner) Define the sprint goal Agree to items for the backlog Align the test sprint plan Check the team’s alignment Marco Tanuj Scott Deb (Development (Developer) (Test Lead) (SCRUM Master) Lead) Add development tasks Create script and execution records Develop “surfer squawker” Monitor the build status Monitor the integration build Execute test & submit defect Confirm defect is fixed Triage defects Fix defect & deliver change Track status © 2009 IBM Corporation Collaborative Application Lifecycle Management 36

IBM Software Group Rational C/ALM Solution Components Quality Manager Team Concert Requirements Composer Collaboraitve Business-Driven Quality Innovation Through Collaboration Business Expert Collaboration Coordinate quality assurance plans, processes and resources Unify by “thinking & working” in unison with real-time project heath Elicit, capture, elaborate, discuss and review requirements Quality Manager offering Requirements Composer Team Concert Business Partner Jazz Offerings Best Practice Processes Search and Query Security Dashboards Team awareness collaboration Events notification JAZZ TEAM SERVER Open Lifecycle Service Integrations Clear. Quest Powered by Clear. Case © 2009 IBM Corporation Build Forge Requisite Pro Asset Manager Collaborative Application Lifecycle Management 38

IBM Software Group Rational Team Concert: A closer look Iteration Planning Project Transparency Integrated iteration planning and execution Task estimation linked to key milestones Out of the box agile process templates SCM Integrated stream management Component level baselines Server-based sandboxes Parallel development Clear. Case connector Customizable web based dashboards Real time metrics and reports Project milestone tracking and status Work Items Defects, enhancements and conversations View and share query results Support for approvals and discussions Query editor interface Clear. Quest connector Build Work item and change set traceability Build definitions for team and private builds Local or remote build servers Supports Ant and command line tools Integration with Build Forge® IBM Jazz™ Team Server Single structure for project related artifacts World-class team on-boarding / off-boarding including team membership, sub-teams and project inheritance Role-based operational control for flexible definition of process and capabilities © 2009 IBM Corporation Team advisor for defining / refining “rules” and enabling continuous improvement Process enactment and enforcement In-context collaboration enables team members to communicate in context of their work Collaborative Application Lifecycle Management 39

IBM Software Group Centralised Quality Management hub enabled by Jazz IBM Collaborative Application Lifecycle Management Rational Quality Manager Quality Dashboard Test Management Requirements Management Defect Management Create Plan Build Tests Manage Test Lab Report Results Execute Tests Best Practice Processes Collaboration Presentation: Mashups SAP Test Data Quality © 2009 IBM Corporation Functional Testing Java Security Open Lifecycle Service Integrations Performance Testing Storage Search & Query Web Service Quality System z, i Code Quality Collaborative Application Lifecycle Management Administration: Users, projects, process . NET Open Platform Security and Compliance homegrown 40 40

IBM Software Group Rational Requirements Composer: A closer look Rich Authoring Environment Use Cases Web Review and Approval Wiki style interface Categorize / Tag Comment Review / Approve Rich Text Requirements Glossaries UI Sketching and Storyboarding Process Sketching © 2009 IBM Corporation Collaboration Server Share work instantly Users / teams / authorizations Linking between all artifacts Versioning Collaborative Application Lifecycle Management 41

IBM Software Group © 2009 IBM Corporation Collaborative Application Lifecycle Management 42

IBM Software Group Module 1 – Update the Product Backlog An IBM Proof of

IBM Software Group Agenda ● ● ● ● Introduction to Collaborative Application Lifecycle Management (C/ALM) Lab Overview Module 1 Update the Product Backlog Module 2 Plan the Sprint Module 3 Sprint! Module 4 Responding to a Test Failure Session Summary © 2009 IBM Corporation Module 1 – Update the Product Backlog 45

IBM Software Group Objectives ● Explore the Rational Team Concert (RTC) web interface. ● Explore RTC dashboards and viewlets. ● Explore how RTC can facilitate and manage changes to project plans. ● Explore how RTC can manage SCRUM stories and product backlogs. © 2009 IBM Corporation Module 1 – Update the Product Backlog 46

IBM Software Group Sequence of events – Lab 1 Create the new story Prioritize the backlog Describe the highest priority features Bob (product owner) Define the sprint goal Agree to items for the backlog Align the test sprint plan Check the team’s alignment Marco Tanuj Scott Deb (Development (Developer) (Test Lead) (SCRUM Master) Lead) Add development tasks Create script and execution records Develop “surfer squawker” Monitor the build status Monitor the integration build Execute test & submit defect Confirm defect is fixed Triage defects Fix defect & deliver change Track status © 2009 IBM Corporation Module 1 – Update the Product Backlog 47

IBM Software Group Lab 1 Scenario ● You are “Bob”, the product owner, for this entire lab. ● You have a new story that you want included in the coming sprint. ● You will create the new story, add it to the product backlog and then reprioritize the backlog so that your new story becomes the highest priority. ● All of Bob’s work will be done via the Rational Team Concert web interface. © 2009 IBM Corporation Module 1 – Update the Product Backlog 48

IBM Software Group Lab 1 Concepts Learned ● The Rational Team Concert (RTC) web interface is a robust interface that can be used as the primary interface for many team roles (essentially, anyone who does not have a requirement to modify items under source control). ● RTC provides direct support for Scrum. Note: While this session uses Scrum, RTC provides excellent support for a variety of development methodologies. ● RTC dashboards provide each team member with the information they require. Projects, teams and individuals can have their own dashboards customized to their needs. ● RTC makes it easy to manage a project's development plan. © 2009 IBM Corporation Module 1 – Update the Product Backlog 49

IBM Software Group © 2009 IBM Corporation Module 1 – Update the Product Backlog

IBM Software Group Module 2 – Plan the Sprint An IBM Proof of Technology

IBM Software Group Agenda ● ● ● ● Introduction to Collaborative Application Lifecycle Management (C/ALM) Lab Overview Module 1 Update the Product Backlog Module 2 Plan the Sprint Module 3 Sprint! Module 4 Responding to a Test Failure Session Summary © 2009 IBM Corporation Module 2 – Plan the Sprint 52

IBM Software Group Objectives ● Explore how a team using Rational Team Concert (RTC) and Rational Quality Manager (RQM) can collaborate to integrate testers with the development team and ensure test coverage. ● Further explore the RTC web interface. ● Further explore RTC dashboards and viewlets. ● Explore how RTC enables agile teams to manage sprint/iteration plans. ● Explore how RTC can be used to facilitate a sprint planning meeting. ● Explore how RTC can be used to track project status and find impediments to progress. ● Explore using RQM to update the test plan, create new test cases and link them to requirements. © 2009 IBM Corporation Module 2 – Plan the Sprint 53

IBM Software Group Sequence of events – Lab 2 Create the new story Prioritize the backlog Describe the highest priority features Bob (product owner) Define the sprint goal Agree to items for the backlog Align the test sprint plan Check the team’s alignment Marco Tanuj Scott Deb (Development (Developer) (Test Lead) (SCRUM Master) Lead) Add development tasks Create script and execution records Develop “surfer squawker” Monitor the build status Monitor the integration build Execute test & submit defect Confirm defect is fixed Triage defects Fix defect & deliver change Track status © 2009 IBM Corporation Module 2 – Plan the Sprint 54

IBM Software Group Lab 2 Scenario ● You will play three different roles in this lab! ● As Bob, the product owner, you will use the Rational Team Concert (RTC) web interface to order and describe the highest priority features to the team. ● As Scott, the scrum master, you will use the RTC web interface to create a plan for the new sprint, add items to the plan and create development tasks for each item in the plan. ● As Tanuj, the test lead, you will use Rational Quality Manager (RQM) to add new test cases to the test plan and link them to the stories they are testing. ● Finally, as Scott (again), you will use the RTC web interface to ensure that all stories planned for this sprint have test cases associated with them. © 2009 IBM Corporation Module 2 – Plan the Sprint 55

IBM Software Group Lab 2 Concepts Learned ● RQM and RTC to give users of either tool visibility into data from the other tool, and link items from either tool together. This helps all team members stay in sync. ● For teams using Scrum, RTC can be an integral tool in the sprint planning meeting. It provides views (Product Backlog, Taskboard) and viewlets (Team Velocity) that are essential to Scrum. ● RTC makes it easy to create new sprint/iteration plans and add work to them, or move items from one plan to another. ● For Scrum, stories can link to one or more development tasks that can be used to assign work to developers. © 2009 IBM Corporation Module 2 – Plan the Sprint 56

IBM Software Group © 2009 IBM Corporation Module 2 – Plan the Sprint 57

IBM Software Group Module 3 & 4 – Sprint! & Responding to a Test

IBM Software Group Agenda ● ● ● ● Introduction to Collaborative Application Lifecycle Management (C/ALM) Lab Overview Module 1 Update the Product Backlog Module 2 Plan the Sprint Module 3 Sprint! Module 4 Responding to a Test Failure Session Summary © 2009 IBM Corporation Module 3 – Sprint! 59

IBM Software Group Objectives ● Explore how Rational Quality Manager (RQM) can be used to associate test implementations (scripts) with test cases. ● Explore the Rational Team Concert (RTC) Eclipse interface from a developer’s perspective. ● Understand uses RTC to accept work, complete development tasks and deliver updated work to the team. ● Explore the team build features of RTC. ● Explore how all team members can monitor the status of team builds, regardless of whether they use RTC or RQM. © 2009 IBM Corporation Module 3 – Sprint! 60

IBM Software Group Objectives ● Explore how Rational Quality Manager (RQM) can be used to execute manual tests, log test results and generate defects for the development team to fix. ● Explore how Rational Team Concert (RTC) can be used to triage defects and help determine who should be assigned new work. ● Further explore how a developer uses RTC to discover new work assigned to them, fix defects, deliver fixes to the team and work with team builds. ● Explore how a tester can use RQM to monitor the team build status, determine what work is included in a new build and verify that defects have been fixed. © 2009 IBM Corporation Module 4 – Responding to a Test Failure 61

IBM Software Group Sequence of events – Lab 3 Create the new story Prioritize the backlog Describe the highest priority features Bob (product owner) Define the sprint goal Agree to items for the backlog Align the test sprint plan Check the team’s alignment Marco Tanuj Scott Deb (Development (Developer) (Test Lead) (SCRUM Master) Lead) Add development tasks Create script and execution records Develop “surfer squawker” Monitor the build status Monitor the integration build Execute test & submit defect Confirm defect is fixed Triage defects Fix defect & deliver change Track status © 2009 IBM Corporation Module 3 – Sprint! 62

IBM Software Group Sequence of events – Lab 4 Create the new story Prioritize the backlog Describe the highest priority features Bob (product owner) Define the sprint goal Agree to items for the backlog Align the test sprint plan Check the team’s alignment Marco Tanuj Scott Deb (Development (Developer) (Test Lead) (SCRUM Master) Lead) Add development tasks Create script and execution records Develop “surfer squawker” Monitor the build status Monitor the integration build Execute test & submit defect Confirm defect is fixed Triage defects Fix defect & deliver change Track status © 2009 IBM Corporation Module 4 – Responding to a Test Failure 63

IBM Software Group Lab 3 Scenario ● You will play two different roles in this lab. ● As Tanuj, the test lead, you will use Rational Quality Manager (RQM) to create and edit new test scripts and test execution records for the test cases you added in the previous lab. ● As Deb, the developer, you will use the Rational Team Concert (RTC) Eclipse interface to plan your work, complete your development tasks, deliver your updates to the team and execute an integration build on the team's build server. ● As Tanuj (again), you will use RQM to monitor the team build status and deploy the built application (following a test script) so that the application is ready for test. © 2009 IBM Corporation Module 3 – Sprint! 64

IBM Software Group Lab 4 Scenario ● You will play three different roles in this lab! ● As Tanuj, the test lead, you will use RQM to execute a manual test, denote that the test failed and generate a new defect related to the test result. ● As Macro, the development lead, you will use the RTC web interface to analyze the new defect, determine who should fix the defect and assign the defect. ● As Deb, the developer, you will use the RTC Eclipse interface to determine that there is a new defect assigned to you, analyze the test result related to that defect, resolve the defect and request a new team build. ● As Tanuj (again), you will notice the new build result, determine what is fixed in that build, deploy the new build and verify that the defect you created is indeed fixed. © 2009 IBM Corporation Module 4 – Responding to a Test Failure 65

IBM Software Group Lab 3 Concepts Learned ● RQM test scripts implement test cases that can be linked to the drivers for those test cases (in this case, stories). ● RQM includes a highly descriptive manual testing facility that provides the tester with the right level of detail required to execute the test correctly. ● RTC queries make it simple for any team member to see what they need to work on. ● A change set is the fundamental unit of change and collaboration in your team environment. Change sets are migrated between streams via two operations: accepting and delivering. ● This team did not require work items to be associated with delivered changes, but that could be turned on. ● Developers can run "personal builds" on the team's build server to ensure that the code they see in their workspace successfully builds using the team's build process. Ensuring compilation in the IDE isn't always enough. ● Team members can request a "team build" that will grab the latest code on the team's integration stream and build it on the team build server. ● Every team member has access to build data from team builds. This promotes communication and collaboration among the contributors – on local or remote sites. © 2009 IBM Corporation Module 3 – Sprint! 66

IBM Software Group Lab 4 Concepts Learned ● RQM's manual test facility allows the test to document step-by-step test results as the test is being executed, including grabbing helpful screen snapshots that may be useful in debugging. ● Test results can document the build that was used for the test, to aid in debugging. ● Defects can be created from test results and routed to the development team. Defects created from test results are automatically linked back to the test result, to aid in debugging. ● Testers can denote which defects are preventing (blocking) test cases from succeeding…ensuring they don't waste time executing the same test and generating duplicate defects. This also helps testers monitor the defects they've generated so they know when it's worthwhile to run the test again. ● RTC queries make it easy for team leads to find new work and determine the appropriate person for assignment. ● Change sets can be associated with work items to denote which artifacts were modified to implement a work item. © 2009 IBM Corporation Module 4 – Responding to a Test Failure 67

IBM Software Group © 2009 IBM Corporation Module 3 – Sprint! 68

IBM Software Group Contacts ● Perth 4 Andy Rutherford 4 arutherf@au 1. ibm. com ● Adelaide 4 Lee Kinsman 4 lkinsman@au 1. ibm. com ● Auckland 4 Alan Kan 4 alankan@nz 1. ibm. com ● Brisbane 4 Davyd Norris 4 dnorris@au 1. ibm. com ● Wellington 4 Alan Kan 4 alankan@nz 1. ibm. com ● Canberra 4 Joe Williams ● Melbourne 4 Davyd Norris 4 dnorris@au 1. ibm. com ● Sydney 4 Rafal Michalski 4 Rafal. Michalski@au 1. ibm. com © 2009 IBM Corporation Module 3 – Sprint! 69