Delve into Agile methodologies, compare them with Waterfall, explore planning techniques, and discover tools like SCRUM and Kanban. Gain insights into solving common problems with Agile.

This course is designed to help learners build an understanding of Agile’s process model and its different approaches and techniques.

To understand the advantages of implementing Agile techniques, the course begins with a comparison of Agile methods and the traditional Waterfall model. Then, you’ll get to know about different planning approaches to help users effectively adjust deadlines. Next, there’s a discussion on backlogs and different visual techniques, such as burn-down charts and burn-up charts, that help increase the efficiency of projects.

You will also learn Agile methodologies including SCRUM, eXtreme Programming, DSDM, Smart and Kanban, as well as the differences and similarities between these approaches. Finally, you’ll look at some common problems and learn ways to solve them using Agile methodologies.

Learn Agile Methodologies from Scratch

Interestingly enough, in most Agile approaches, the specific role of the tester isn’t appointed. That said, this is a crucial role. The importance of it is well reflected in the Law of Boehm.


Boehm’s Law states that the later an error is discovered, the greater the effort required to solve it. The increase in effort is exponential. This is especially true in the Waterfall. The increase in effort is caused by performing the phases only once. If an error is detected late, a lot of work has already been performed in previous phases.

<p>Boehm’s Law states that the later an error is discovered, the greater the effort required to solve it. The increase in effort is exponential. This is especially true in the Waterfall. The increase in effort is caused by performing the phases only once. If an error is detected late, a lot of work has already been performed in previous phases.</p>


Boehm’s Law illustrates why testing in Agile is much more effective. When developing a work item, there are similar phases, but they’re performed in an iteration here. The realization of individual work items takes up to a few days, not several months. This illustrates how starting to test from day one reduces the required effort highly.

However, it can be even more effective. Precisely because of Boehm’s law, we recommend developing, testing, and accepting work items in a single iteration. So, the effort to resolve errors is further reduced.

Lightweight Agile approaches assume that the customer is responsible for the testing of the work items. This presents challenges. Often the customer, user, or domain expert lacks sufficient time and understanding. Moreover, in complex projects, it’s important to test more thoroughly than users normally do.

Think of services in a service-oriented architecture in a complex application landscape. Now it’s sensible for the tester to test and the customer only performs the final acceptance of work items. Involve testers as developers as early as possible in projects. That way, even testers gain knowledge of the customer and the domain as soon as possible.


# Testers in Agile

Just like developers, we involve testers in estimating the size and complexity of work items. Estimates should be done by those performing the work. We then involve them in the development of work items in iterations. For user stories, we usually determine tasks and consequently test tasks. For smart use cases, the basic flow and alternative flows are elaborated. In both techniques, scenarios are worked out.

In our experience, testers play a vital role at this stage. Testers have a different view of the world than domain experts and developers. The latter see the positive scenarios. Testers are more focused on impossibilities and exceptions before any code is written. This way, errors can be prevented before they occur.

Then, the tester writes the test scenarios and test cases and the developer realizes the code. Once a work item is realized, the tester compares the result with its test scenarios and test cases. Working with a developer, any errors found are now immediately improved. This prevents Boehm’s law. Also, this way the tester facilitates the work of domain experts or users, who have to do the final acceptance of the work item. Testers guide this acceptance. Due to this the pressure on product owner, user, and domain expert decreases, and the team’s velocity increases.


As the amount of delivered functionality grows, it becomes increasingly important to test the consistency and continue testing. This is called **regression testing**. An often-heard misconception is that unit testing takes care of regression testing in Agile. There’s a big difference. Unit testing tests the correct operation of code. Regression testing checks if the code does what was agreed upon. Unit testing supports the team, regression testing supports the product.

When a project has a long duration or is completed in phases, regression testing becomes increasingly important. We recommend running regression tests on a regular basis. For example, during the last iteration before a release. Testers are responsible for these tests. Regression testing takes a lot of time, so try automating these tests wherever possible. Again, this requires close collaboration between testers and developers.

In short, although the role of testers in many Agile approaches isn’t described explicitly, this role contributes a great deal to the success of projects. A tester on each team is a no-brainer. A tester on the team increases quality and saves the customer time. 


# Specification by example

An interesting emerging technique is **specification by example**. The core of this technique is that the customer, together with the team, composes an unambiguous definition of a work item’s requirements. This is typically done during workshops, preferably with domain experts, developers, and testers. Subsequently, examples are sought to allow this single definition to be tested, automatically. These examples are also fine-tuned with the customer and the team.

As with test-driven development, these tests are elaborated in test code. There are several frameworks that support specification by example. Well-known examples of these are Spec-Flow and Fitness. The automated testing of smart use cases, which happens a lot in Smart, falls into this category.

Specification by example, also called acceptance test-driven development, is an elegant way to partially automate software acceptance. An important starting point is for the customer and team to agree on the unequivocal definition, and more importantly, on good examples to test the work item.

This makes it a counterpart to many traditional and more formal testing techniques, which are often based on testing all possibilities. Testing everything isn’t always as simple as it seems, which contributes to the popularity of specification by example.


As with test-driven development, the repeatability of these automated acceptance tests are a great advantage. Just as with test-driven development, it’s important to not underestimate how much the test code may need to be modified or extended when requirements change during the project.

Learn about the roles of software testers in an Agile environment.


Getting Started

Why does the Waterfall Process model not work?

What is Agile?

Short Iterations in Agile

Collaboration in Teams

Collaborating Roles

Agile Requirements

Estimating

Planning

Implementing Agile

Issues in Using Agile

Choosing the Most Appropriate Process Model

Conclusion

Testers and Testing