Scrum Testing Product Owner

Introduction

During the software development process it is vital to establish a robust process of software quality assurance, even if you are developing using an Agile development methodology.

It is important to mention that Agile development should not be confused with development without a defined quality management software. It is strongly recommended that the tasks of creating test cases and performing automated tests be planned for each development iteration.

In addition, having a test-focused person is a key to the quality of software development during the Agile iterations.

Agile Planning and Quality Assurance Tasks

The Agile iteration planning process allocates at least one resource for testing activities, and does not involve this resource in development activities within the iteration. This process is important to avoid poor quality testing.

Within a development team of five people, having at least one person focused on these tests tasks will greatly help to ensure the quality of the software. In this case we are talking about functional tests (black-box testing) planned and written through test cases. However, we must not forget that the unit tests (white-box testing) are the responsibility of the development team, and the tasks of developing these unit tests must be estimated together with the backlog items.

The advantage of include planning and execution quality assurance tasks even in an Agile software development cycle is the concern of the development team in delivering quality software to those responsible for running the tests. It is amazing how the simple fact there is a person planning and thinking about software testing already increases the quality of the software.

Here are some tests tasks that can be executed during a development iteration:

  • Creating a test-planning;
  • Creating the detailed test cases for each user story or backlog item;
  • Preparing test environments required for system tests;
  • Preparing test data: getting real data from production or simulation.

In addition the tests can be automated, so the tasks below can be included:

  • Automating unit tests;
  • Automating functional tests;
  • Writing mocks, test drivers, data simulators, test frameworks.

Scrum Master Dublin

Tools for planning and running tests

It is not the purpose of this article to present test tools. However, it is important for the agility of the software development process to look for tools to automate the execution of the tests as well as documenting the test plans and the test cases.

Remember that tests can be re-used in future development iterations, so it is very important to define a centralised method and tool to manage the test plans and test cases. An efficient test management tool will help you with the agility and quality of your software.

The following are some suggestions for test tools:

  • qTest
  • PractiTest
  • Test Collab
  • TestFLO for Jira
  • XQual
  • TestCaseLab
  • Microsoft Test Manager (Test planning and automation)
  • Microsoft Team Services (Test cases)
  • Selenium (Automation of functional tests for Web applications)
  • TestRail
Planning Poker

Agile Estimation: Approaches

The software development process, with its constant uncertainties and frequent changes, together with the difficulty in getting users to articulate their requirements, has long been a headache for project managers.

Agile development processes still bring with them some of these headaches, but we can simplify the estimation process. I have listed some of the approaches below.

Poker Planning Games

Planning Poker

Planning Poker

Planning Poker is a technique used to estimate the relative size of tasks, or the effort required to complete them, in software development. A development team estimates using a deck of cards that are usually a Fibonacci sequence (1, 2, 3, 5, 8, 13, 21, 34, … ) to indicate the difficult of the task. You can easily replicate this by asking the team to make their own cards. When starting off in Agile, sometimes teams equate this to the number of hours required to perform the estimated task – though this is probably not the best way to do it.

The estimates occur as follows:

An item is selected for discussion.

  • Each team member chooses a card that most reflects the “size” of the selected story (or task). This decision is based on the knowledge and experience of each member of the team.
  • All members show their cards at the same time so that there are no changes of mind after each member has seen the other hands.
  • In most cases we will have cards with different values. The divergences, and the reason for the differences in the estimates, is discussed. Large divergence suggests a lack of information, in which case more negotiation/discussion must occur in order to get agreement on the estimation.
  • The story estimation ends when the cards’ values converge to a value agreed by shared consensus of the team.

Agile Estimation using the Fibonacci sequence

Consider the sequence of numbers 1, 2, 3, 5, 8, 13, 21, ….

Each number is the sum of the two previous numbers. In some cases, the numbers are rounded up or down to the nearest 5 or 10. Often a 0 and a 1/2 are also added. 0 (zero) represents a story that requires no appreciable effort to develop; for example, if another story already being completed will be used to end this story.

Generally, the question mark is used to indicate that a team member does not have enough knowledge of the story to estimate it, and thus requires more discussion and greater detail about the story.

The symbol of infinity is used to indicate that a story is too large to estimate, more like an epic, and so needs to be broken down into smaller stories.

The idea here is that the team should really develop their own technique for building out estimates. Time may not be the best measure, as the team should be trying to get more efficient in each subsequent sprint. The non-linear nature of the Fibonacci sequence makes it harder to sit on the fence with in-between estimates.

Estimate user stories using T-shirt sizes

T shirt sizing

Sizing

There are several other ways of estimating stories, another of which is T-shirt sizing. In this type of estimation, stories can be small, medium, large, or XL. What exactly these sizes mean depends on the team. In addition to the terminology being familiar and easy to use, even by non-technical people, this works really well on teams with very short iterations.

 

 

 

 

Conclusion

Estimating software delivery times really is an art. The accuracy of the estimate depends greatly on each team, as well as the level of detail available for the estimate. The most important thing is for each team to evolve, always seeking to increase the accuracy behind the estimates.

In addition, estimates combined with good retrospectives can help identify parts of a system that need refactoring. For example, if stories fall behind, or are often labelled as difficult, you can investigate what these stories have in common, and seek solutions that can mitigate those problems.

Of course there are many agilest that advocate no estimates at all