Managing Regression Risk with Evolving Manual and Automated Test Cases

In an Agile project, as each iteration completes, the product grows. Therefore, the scope of testing also increases. Along with testing the code changes made in the current iteration, testers also need to verify no regression risk has been introduced on features that were developed and tested in previous iterations. The risk of introducing regression in Agile development is high due to extensive code churn (lines of code added, modified, or deleted from one version to another). Since responding to change is a key Agile principle, changes can also be made to previously delivered features to meet business needs. In order to maintain velocity without incurring a large amount of technical debt, it is critical that teams invest in test automation at all test levels as early as possible. It is also critical that all test assets such as automated tests, manual test cases, test data, and other testing artifacts are kept up-to-date with each iteration. Regression Risk is highly recommended that all regression test assets be maintained in a configuration management tool in order to enable version control, to ensure ease of access by all team members, and to support making changes as required due to changing functionality while still preserving the historic information of the test assets.

Testers often do routine job every iteration; however, there might be excessive work load during some iteration it may be difficult to juggle around several issues. The testers at the beginning of the iteration will have to get together to prepare a test strategy to deal with the unknowns and known and proceed accordingly. They testers team should also review the tests written earlier and discuss the probably touch points on where they need to add or delete the scripts.

Because complete repetition of all tests is seldom possible, especially in tight-timeline Agile process, testers need to allocate time in each iteration to review manual and automated test cases from previous and current iterations to select test cases that may be candidates for the regression test suite, and to retire test cases that are no longer relevant. Tests written in earlier iterations to verify specific features may have little value in later iterations due to feature changes or new features which alter the way those earlier features behave.

While reviewing test cases, testers should consider suitability for automation. The team needs to automate as many tests as possible from previous and current iterations. This allows automated regression tests to reduce regression risk with less effort than manual regression testing would require. This reduced regression test effort frees the testers to more thoroughly test new features and functions in the current iteration.

It is critical that testers have the ability to quickly identify and update test cases from previous iterations and/or releases that are affected by the changes made in the current iteration. Defining how the team designs, writes, and stores test cases should occur during release planning. Good practices for test design and implementation need to be adopted early and applied consistently. The shorter time-frames for testing and the constant change in each iteration will increase the impact of poor test design and implementation practices and reduce regression risk.

Use of test automation, at all test levels, allows Agile teams to provide rapid feedback on product quality. Well-written automated tests provide a living document of system functionality. By checking the automated tests and their corresponding test results into the configuration management system, aligned with the versioning of the product builds, Agile teams can review the functionality tested and the test results for any given build at any given point in time.

Automated unit tests are run before source code is checked into the mainline of the configuration management system to ensure the code changes do not break the software build. To reduce build breaks, which can slow down the progress of the whole team, code should not be checked in unless all automated unit tests pass. Automated unit test results provide immediate feedback on code and build quality, but not on product quality.

Automated acceptance tests are run regularly as part of the continuous integration full system build. These tests are run against a complete system build at least daily, but are generally not run with each code check-in as they take longer to run than automated unit tests and could slow down code check-ins. The test results from automated acceptance tests provide feedback on product quality with respect to regression since the last build, but they do not provide status of overall product quality.

Automated tests can be run continuously against the system. An initial subset of automated tests to cover critical system functionality and integration points should be created immediately after a new build is deployed into the test environment. These tests are commonly known as build verification tests. Results from the build verification tests will provide instant feedback on the software after deployment, so teams don’t waste time testing an unstable build.

Automated tests contained in the regression test set are generally run as part of the daily main build in the continuous integration environment, and again when a new build is deployed into the test environment. As soon as an automated regression test fails, the team stops and investigates the reasons for the failing test. The test may have failed due to legitimate functional changes in the current iteration, in which case the test and/or user story may need to be updated to reflect the new acceptance criteria. Alternatively, the test may need to be retired if another test has been built to cover the changes. However, if the test failed due to a defect, it is a good practice for the team to fix the defect prior to progressing with new features.

In addition to test automation, the following testing tasks and regression risk may also be automated:

• Test data generation
• Loading test data into systems
• Deployment of builds into the test environments
• Restoration of a test environment (e.g., the database or website data files) to a baseline
• Comparison of data outputs

Automation of these regression test reduces the overhead and allows the team to spend time developing and testing new features.

The post Regression Risk appeared first on World Of Agile.

The Sprint Retrospective is the event in Agile which brings in the iterative, inspective and adaptive nature into picture. The team reflects upon the previous timebox with a view to learn some lessons, adjust the behavior or environment in order to improve their experience.

A Sprint Retrospective is a special meeting that takes place at the end of each sprint, in which the team members gather to inspect and improve their methods and teamwork.

Since Sprint Retrospectives happen during the sprint, the lessons and improvements that result from them are applicable and relevant to upcoming work on the next sprints.

Advantages of Sprint Retrospectives include the following

• Improved Productivity : By applying lessons learned and reducing rework, the team can get more productivity work done.
• Improved Capability : Retrospectives provide a venue for spreading knowledge, so does the number of people who can perform tasks associated with the knowledge.
• Improved Quality : We can improve quality on our projects by finding the circumstances that led to defects and removing the causes.
• Improved Capacity : Retrospectives focus on finding process efficiency improvements, which can improve the team capacity to do work.

What is a Sprint Retrospective?

Sprint Retrospectives are important because they give the team visibility into issues and help them to take action to correct course and make work environment more efficient and more productive.

• Sprint Retrospectives is a 3 hour (max) meeting at the end of the Sprint .
• This meeting is held after the Sprint Review Meeting. This helps the team to review what is working and what is not.
• Two main questions are asked in the sprint retrospective: What went well during the sprint? What could be improved in the next sprint?
• Team then can take actions going forward
• All team members reflect on the past sprint
• Make continuous process improvements
• Mandatory attendees are Product owner , Scrum Master  and developers
• To bring in a neutral viewpoint, you may want to bring in a unbiased attendee also such as a ScrumMaster of another team

What is not the objective of Retrospective

• The Sprint retrospective is a meeting “By the Team” and “For the team”
• It is not a performance review by senior Management
• Nor is it a postmortem meeting where the goal is to assign blame

Making Retrospective Effective

The Sprint Retrospective is not an easy meeting to conduct or to keep on track. Depending on different personalities within the team, the tendency may be to keep the meeting to be a “Goody Goody” meeting and keep all the dis-functions under the carpet. Alternatively, it may turn out to be a virtual “free for all slanging match” where team members blame each other. Either ways, the meeting can turn out to be counter-productive.

Some of the best practices for conducting a Sprint  retrospective are following a step wise process. The steps in the retrospective could be

1. Set the Stage
2. Gather data
3. Generate Insights
4. Decide What to Do
5. Close the Retrospective

Set the Stage

At the start of the Sprint retrospective, we need to set the stage to help people focus on the task at hand of reflecting on how things went. One could Start by creating 3 lists

o   What is working

o   What is not working

o   What we could try in the next Sprint

Activities to help set the stage include

• Checkin : This exercise helps people put aside their concerns and focus on the retrospective. In a round robin format, the people are asked to summarize in one or two sentences what they hope to get from the retrospective.
• Focus on/Focus off : This activity is used to establish a mindset for productive communication. A white board setting some ground rules could be a good ides. Examples of Ground rules for Sprint retrospective may include “Inquiry rather than Advocacy”, “Dialogue rather than debate”, “Conversation rather than Argument”, “Understanding rather than defending” etc.
• ESVP : This is a anonymous exercise in which the participants identify themselves with one of the identities

o   Explorers : Explorers are eager to learn and discover new ideas

o   Shoppers : Shoppers are the ones who will go home even if they learn one useful idea

o   Vacationers : Vacationers are not very interested in the Sprint retrospective but they are happy to be away from their day-to-day job.

o   Prisoners : Prisoners feel that they are being forced to attend and would rather prefer to do something else.

The anonymous results are collected and tallied for the group to gauge the participants level of energy and commitment. Accordingly the Retrospective can be planned to invite better participation or decide if you can get the Vacationers and Prisoners get interested and make them at least the Shoppers.

• Working agreement: In this activity, small groups of participants are made and they are given different topics to work on. Then the groups are asked to define and explain the working agreements they would like to see in place for the retrospective. Then with the entire group we spend time clarifying and refining ideas, building a single master list to work from.

Gather the Data

In this phase, the team creates a shared picture of what happened during the sprint (or release, depending on the focus of the retrospective). Without a common vision for what occurred, the team may simply speculate on improvements and may end up not working on the real issue.

Various Data Gathering techniques already detailed in this book can be used. To recap, following are some of the data gathering techniques

• Timeline
• Triple Nickel
• Color code dots
• Mad, Sad, glad
• Locate Strengths
• Satisfaction Histogram
• Team radar

Generate Insights

This stage gives the team time to evaluate the data that was gathered in the earlier step and derive meaningful insights from it. Various techniques which can be used to generate insignts include

• Brainstorming
• Five whys
• Fishbone diagram(also known as Ishikawa diagram)

Decide What to Do

The activities of this step move the team away from the current sprint towards the next one by thinking about “what to do better in the next sprint”. The team identifies and prioritizes the action items and creates plan for experiments to achieve the desired result.

Various techniques to decide include

• Sprint Retrospective Planning games
• Fist of Five
• Voting
• Round robin

Following are some of the important recommendations while making decisions

• Prioritize the inputs received and arrive at a prioritized list of actions. Assigning priorities are very important since things can get lost and the team might not end up doing things differently
• Try only a few things at a time. Do not try to do everything.
• Assign specific actions to people for what needs to be done
• Agree on what Penalty would be if the actions are not taken. These penalties should be friendly penalties and not threats because threats can be counter-productive. Example of a friendly penalty could be that a team member “buys coffee or lunch for the entire team” if he/she does not complete the task.
• Find ways to make the meeting fun. Use of Humour is recommended. Bring in some food/Snacks or plan to go for coffee after the retrospective.

Close the Sprint Retrospective

The final step is closing the retrospective. In this team the team members are given opportunity to reflect on what happened during the retrospective and to express appreciation to each other. Activities that summarize what the team decided to keep and what to change, what the team is thankful for and what the team decided to improve or continue as-is going forward.

There are several team-based activities that can be used in this stage which include

• Plus/Delta : In this exercise the facilitator captures and validates the team’s ideas for what the team should do more of and what the team should change.

• Helped, Hindered, Hypothesis: This exercise helps generate feedback on the retrospective process itself and produce ideas for improvement. To run this session, three flipcharts are prepared which are titled “HELPED”, “HINDERED” and “HYPOTHESIS”. The participants then write on posits and paste on the different flipcharts. The ideas are collected and evaluated for future consideration.
• Return on Time Invested: This is an exercise to get feedback from participants if their time was spent appropriately.
• Appreciations: During this exercise the team members express gratitude towards others and appreciate others for help, contributions or helping them solve problems.

The post Sprint Retrospective appeared first on World Of Agile.

At the end of a sprint cycle, two meetings are held: the “Sprint Review Meeting” and the “Sprint Retrospective”. This section describes the Sprint Review Meeting and next section describes the Sprint Retrospectives. One must understand that the objectives of both meetings are very different.

At the Sprint Review Meeting:

• Attended by Product Owner, Scrum Master, team and other stakeholders as required
• The objective of this meeting is

o   To review the work that was completed

o   The planned work that was not completed

o   If the team is on track

o   Get Feedback

• Present the completed work to the stakeholders (“the demo”)
• Incomplete work cannot be demonstrated
• Four-hour time limit
• Feedback from participants are reviewed and recorded. The product owner should consider the feedback as potential backlog items

Best Practices at the end of Sprint review

• Items which were not completed are added back to the Product Backlog.
• Product Owner should assess the priorities of feedback and add to backlog if necessary
• If the customer wants to feel the product, the Product owner should consider making a partial release (Alpha or Beta release) so that the customer can play around with the product.
• It is a good practice to record the demo and make it available to the participants who could not attend the review

Handing Sprint Reviews

• Communicate effectively: Team members who are most able to communicate effectively with the team, Product Owner, Scrum Master, and stakeholders should present, so that they can represent the team in front of the customer.
• Fluent speaker: Another approach is to record the demonstration before the meeting to allow the developers to create the recording at their own pace in the language of the meeting, or to have a fluent speaker speak over the recorded demonstration.
• Scheduling for teams with overlapping work hours: Make sure all team members of the distributed team, regardless of the time zone, can complete their work and prepare for the demo within overlapping work hours.
• Scheduling for teams with no overlapping work hours alternate meeting time: The distributed team holds one sprint review meeting during the normal workday for part of the Scrum team and holds the other sprint review meeting during the normal work hours of the other part of the Scrum team.
• Keeping track of the stakeholder comments: During the sprint meeting, the distributed team needs to capture these comments so the product owner and the developers can decide which ones they will act on.
• Remote demonstrations: Distributed teams should test their tools ahead of time to be sure the distributed meeting will run smoothly, without network poor performance. The team can also consider making the recordings available for download before the demonstration meeting and discussing them through a teleconference.
• Services may vary by location: Set up a single machine with a standard configuration that everyone uses during the demonstration meeting. Before the start of the meeting, distributed team members can access the machine (remotely or locally) to bookmark links, set up scripts, and do a quick dry run of their presentation

For many myths around Sprint Review, refer to following articles

• Myth about Sprint Review being a sign-off event or a demo forum

The post Sprint Review appeared first on World Of Agile.

The Developers consists of professionals who are committed to creating any aspect of a usable Increment each Sprint. Only members of the Scrum Team create the Increment.

Developers are structured and empowered by the organization to organize and manage their own work. The resulting synergy optimizes the Scrum Team’s overall efficiency and effectiveness.

Developers Characteristics

Developers have the following characteristics:

• They are self-organizing. No one (not even the Scrum Master) tells the Developers how to turn Product Backlog into Increments of potentially releasable functionality;
• Developers are cross-functional, with all of the skills as a team necessary to create a product Increment;
• Scrum recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person; there are no exceptions to this rule;
• Scrum recognizes no sub-teams in the Development Team, regardless of particular domains that need to be addressed like testing or business analysis; there are no exceptions to this rule;
• Individual Developers may have specialized skills and areas of focus, but accountability belongs to the Scrum Team as a whole.
• The team should be cross functional. i.e. they should have all skills necessary to complete all work necessary to deliver value to customer.

Building a Scrum Team

It is really no different from building any conventional team in theory. Key modifications to this rule are as follows

• Team members need to collaborate more than conventional teams since the team is self managing.
• There is nobody to tell them what to do and that they have to release a releasable code every interaction which will force them to collaborate a lot more
• Therefore, naturally you will look at team members who are good at working in teams and have good communication skills.
• You will need specialists of course, however, you will need more generalists who are versatile and can do multiple activities e.g. code, test, if required jump into areas which are not his/her own but need help etc.
• You will need highly motivated individuals who can make decisions and stand by the decisions and commitments and strive to meet the goals.
• This essentially means you need to coach the team and trust them to deliver. Thus they will definitely promote a right attitude.
• One must remember that they will always not be successful. Therefore make it “Safe” for people to make mistakes so long as they are learning from their mistakes and learning as they go along.

Building Empowered Teams

Key concept here is “Empowerment”. An empowered team is a team which acts on its own and within. Therefore Empowerment is

• Responsibility and ownership and NOT throwing rule book out of the window.
• Working independently towards common objective and NOT bypassing everyone who say NO
• The team can understand reasons behind a decision so that they can apply sound judgement in decision making. It is not always doing the fun part of the job and ignoring the rest.
• It s about weighing the impact of the decisions on stakeholders and not freedom to unilaterally make decisions that impact others.
• It is about making trade-offs while making decisions that impact others.

Therefore “Empowerment” does not mean you throw out the rule book and do whatever you want.

Developers Team Size

• Optimal Developers Team size is small enough to remain nimble and large enough to complete significant work within a Sprint.
• Fewer than three Developers Team members decrease interaction and results in smaller productivity gains. Smaller Developers Teams may encounter skill constraints during the Sprint, causing the Developers Team to be unable to deliver a potentially releasable Increment.
• Having more than nine members requires too much coordination. Large Developers Teams generate too much complexity for an empirical process to manage.
• The Product Owner and Scrum Master roles are not included in this count unless they are also executing the work of the Sprint

Specialist Roles

There may be requirements for Specialist roles in a team which may be appointed based on the nature of the project. However, the Specialist roles should be in a position to fold their sleeves and get down to the core development work if there is no Specialist work pending.

Some of the Specialist Roles seen in the industry are

Architect

Sometimes the project is highly technical. An Architect can play a key role in making crucial decisions on designs, review designs. In Scrum, it is expected that even the Architect is “hands on” and should be able to fold his sleeves and help out others in solving critical issues.

Automation Test Expert

Automation is the key in ensuring Quality in a Scrum Project. Since the team sizes are small, there may not be dedicated manual testing teams. In such cases, a Automation Test Expert is essential so that many of the testing can be automated.

Configuration Manager

Configuration Manager role will be required for managing the repository and proper versioning. This role may be required in case of complex projects which require help of a independent person to maintain the right versions. This will help save the time required by the Scrum Team while developing and producing the outputs quickly.

The post Developers appeared first on World Of Agile.