Pre Development in the World of Agile

Pre-Development in the World of Agile

• Just prior to the development of a story, the product owner[/BA], tester and developer meet to refine and add any missing Acceptance Tests. We call this a "Pre-Development" meeting.

The basis of Agile is a single, multi discipline team working collaboratively to deliver working software. But how do teams ensure that the have a common understanding of what they are delivering?

In must be understood that in the real-world implementation of the theory will be different for each team, project, organization and flavor of Agile.

Following the practices of iterative sprints, daily stand-ups and regular feature demos, how does each person within the team come to a common understanding regarding a feature or story?

This is when the Pre-Development sessions are held. They are a short 30 min – 1hr session to discuss all aspects of the story. During the session the following areas are discussed:

•Product Owner or Business analyst as proxy discuss user stories/requirements/acceptance criteria.

•Developers discuss the code/[preliminary estimate].

•Testers discuss scenarios/test cases.[Dev role to lead acceptance criteria written in Gherkin]

Without a shared understanding across the team, there can be confusion regarding behaviors, complexity, code, duplication and depth of testing.

Some teams see the Pre-Development as a prescriptive meeting with outcomes and an agenda [like Gherkin statements for written acceptance criteria in the story] and other teams use the Pre-Development as a discussion session for each story.

By introducing Pre-Development sessions to Sprints/Iterations [or continuously for Kanban], it gives the Product Owners and Business Analyst (BA) an opportunity to present the story requirements and discuss the tests for a new feature.

The Pre-Development - normally consisting of Product Owners/BA, Developer [or two], and Tester [Dev filling the role] - is one of the key ways to change the culture of the team to be more Agile, and encourage more collaboration. These sessions allow for the team to discuss the new feature and review the specification. The aim is to create a common understanding and shared vocabulary so that everyone is on the same page and also estimate how many story points each user story is allocated.

The Pre-Development ensures a common understanding for a story in the team; a session between Product Owner (Business), Developer, Tester. The Pre-Development session will also define the definition of done for the story. In other words, creating a set of criteria to know when the story is complete and the feature ready for delivery.

Good practice is for the Developer and Tester attending the sessions to be the same ones who will develop and test the feature through to completion.

The Tester and Developer can identify missing requirements/test cases, and once these are defined the feature can progress to development and allocated to the appropriate iteration/sprint.

From LeanDog’s Agile Guide

Quality Assurance Role

• Continually improve the tests with refactoring (including data)

• Work with the product owner/BA and developer to establish a plan for providing business value

• Understand the business intent of the story card which help define tests to measure the effectiveness of the story implementation

• Collect and organize story tests into an automated test suite that becomes the regression test

• Run and define exploratory tests and communicates results

• Undertake testing craftsmanship to help maintain development speed, quality, and efficiency

• Commit to be one of the “Pre-Development” / “Fantastic Four”, with excellent collaboration between product owner/BA and developers

• Assist with defining features and specifications with Acceptance Test Driven Development (ATDD)

• Automate ATDD tests

• Pair with a fellow team members to ensure someone else knows that section of the application, and hold each other to high levels of test quality

Automated Regression

Testing - What is "ility" Testing? Testing concerned with qualities such as security, maintainability, interoperability, compatibility, reliability, and installability.

• An iterative activity to build up a regression test suite by creating tests prior to writing code [and using components in ServiceNow]

• Tests are executed every time code is checked into the code repository, resulting in immediate feedback on the health of the overall code base

• Scripts are created for regression testing

• Automated tools run the scripts for regression testing

• Automated testing with duplicable test data generation

• Test entire application, both new and existing functionality, at least once per sprint/iteration

• In order to keep up with development efforts, regression testing must be automated

• Most development efforts are on existing applications. If you do not have great test coverage, where do you start?

• With buggy or trouble areas

• If no trouble areas, then start with the critical application areas

• Any new functionality

Essential

Automated Regression Testing is a testing process focused on detecting defects introduced into the software at the earliest possible opportunity while eliminating repetitive manual labor. Automated Regression Testing uses a comprehensive suite of automated tests to confirm the proper operation of each feature in the application, and notifies the team if one or more features of the software is not operating correctly.

Advanced

Undertake testing craftsmanship to help maintain development speed, quality, and efficiency

• Commit to be one of the “Pre-Development” / “Fantastic Four”, with excellent collaboration between product owner and developers

• Assist with defining features and specifications with Acceptance Test Driven Development (ATDD)

• Automate ATDD tests

• Pair with a fellow team members to ensure someone else knows that section of the application, and hold each other to high levels of test quality

Acceptance Test Driven Development

• Requirements are captured as combinations of free-form specification and Gherkin scenarios that describe how the system should behave when completed. These scenarios become the Acceptance Tests

• Just prior to the development of a story, the product owner/BA, tester and developer meet to refine and add any missing Acceptance Tests. We call this a "Pre-Development" meeting

• Automation of the Acceptance Tests must be completed prior to the completion of development

• Developer focuses on making the Acceptance Tests pass. Together with the tester, their focus throughout this effort is to prevent defects

• Story is functionally complete once all Acceptance Tests pass

• Acceptance Tests run continuously to act as a regression test

• The definition of "done" must be clear

• Tester automates Acceptance Tests at same time as the developer writes code. They are in constant collaboration during this effort

Gherkin example -

Feature: Checkout out after selecting a puppy In order to complete my online adoption as a customer of the puppy adoption site I want to be able to checkout by providing necessary information

It is important to capture the necessary information we require to process the adoption. We need to create a screen that captures the name, address, email address and payment type of the customer. [graphic of the screen could be included]

Scenario: Name is a required field

Given I am on the puppy adoption site

When I adopt a puppy leaving the name field blank

Then I should see the error message "Name can't be blank"

Scenario: Thank you message should be displayed when adoption completed

Given I am on the puppy adoption site

When I complete the adoption of a puppy

Then I should see "Thank you for adopting a puppy!"

Essential

Acceptance Test Driven Development (ATDD) is a practice in which the team discusses the acceptance criteria, then creates a set of clear acceptance tests before development begins. It ensures that the team has a shared understanding of what is being developed. It requires a significant shift in how the team members interact with each other. The transition to ATDD can be a challenge, but the payback is significant.

Advanced

Tester automates Acceptance Tests at same time as the developer writes code. They are in constant collaboration during this effort.