SOGETI UK BLOG

Trojan-horse-001

As we all know, many projects are still carried out with a traditional development approach. Why is it that people don’t question the persistent idea that the agile mindset is not miscible with traditional ideas? I think, and have seen it work in practice, that agile ideas are very useful for the traditional environments, especially  in solution to the challenges mentioned in the next section.

In traditional development approaches there are similar challenges as in agile approaches. However, in agile approaches we have found a solution to these challenges. Why not spread these solutions to other types of development approaches? Based on experiences as an agile-tester in agile projects, you would know how to apply agile solutions to challenges in traditional environments.  Challenges include: what should the level of documentation be, how to establish the quality of requirements, how to perform a risk analysis, how to determine a test strategy, how to get the tests scripts created on time, which test design technique should (must) be applied, what should the test intensity be, how to get the tests executed on time, how to work in a (multi-disciplinary) team, how to deal with test plans and defect management, etc.

So let us, the agile-testers, act as Trojan Horses in traditional development projects. That way the agile mindset will thrive in all types of development approaches.  Agile rules the world!

 

Leo van der Aalst AUTHOR:
Leo van der Aalst has more than 25 years of testing experience. He is experienced in international – consultancy - projects and developed amongst others services for agile testing and the implementation of test organisations.

Posted in: Agile, Software Development, SogetiLabs      
Comments: 0
Tags: , , , , , , , , , , , , , , , , , ,

 

evolutionScrum means the end for testers who do not want to change. In order to survive, the tester must adapt to the changing development environments.

With the deployment of an Agile development approach, such as the frequently used Scrum, each team member has a testing role.  Designers, programmers, managers and users are in fact all testers as well.  Therefore, it is plausible to suggest that testers are unnecessary. Does this seem short-sighted? Recently, an IT manager of a large organization suggested that the test department could be halved since they are working with Scrum. However, this IT manager should know that you can not expect all team members to suddenly have the same extensive testing skills as the experienced tester.  What if it is the other way around: a Scrum team with testers only? Would they all ‘suddenly’ be able to design and program? Probably not! Adapting to the changed circumstances will take time from all team members.

In practice it means that in a Scrum approach testers should help their team members to fulfill their roles as testers as well as possible. For example, they have to provide assistance in the preparation of high-quality user stories. The tester could teach the designer and user how to apply test evaluation techniques (e.g. INVEST model) or help the programmer with the preparation of unit tests and the user with the acceptance tests. Besides this, the tester should moderate the product risk analysis, which could be seen as one of the most important activities in a Scrum project. Because with the outcome of this analysis, the team will be able to find the balance between the investment in time (and money) on the one hand, and the risks covered on the other.

In this way and in order to survive, the test professional moves toward a catalyst for quality improvement!

Leo van der Aalst AUTHOR:
Leo van der Aalst has more than 25 years of testing experience. He is experienced in international – consultancy - projects and developed amongst others services for agile testing and the implementation of test organisations.

Posted in: Agile, Scrum, Software Development, SogetiLabs, User Experience      
Comments: 0
Tags: , , , , , , , , ,

 

A well-known Dutch politician (Willem Drees) once said: “Social Security should be a safety net, not a hammock!” He might have been talking about software testing. Testing, too, should be a safety net, not a hammock.

Many organizations or projects use a variety of test levels. For example, a series of unit test, unit integration test, system test, system integration test, functional acceptance test, user acceptance test, end-to-end test and production acceptance testing is no exception. This may seem sensible, however, it may well create lazy developers. “I deliver my code on time and I don’t have to worry about whether I introduce errors in it or not, because after me the code will be extensively tested anyway.” And, lo and behold, the developer dives into his hammock!

It appears that in organizations or projects that are not accustomed to arranging and executing many test levels, software with fewer errors is delivered. How is this possible? The answer is actually quite simple. Because of the many tests, the programmer feels less responsible for the quality of his product. In situations where software is put into production almost immediately after a unit test, the programmer is forced to take responsibility. After all, when something goes wrong, everyone knows who is to blame. In short, reducing and/or integrating test levels, and at the same time appealing more to the developer’s, or actually, all project members responsibility, promotes the delivery of quality software.

This will make testing a safety net again rather than a hammock!

Leo van der Aalst AUTHOR:
Leo van der Aalst has more than 25 years of testing experience. He is experienced in international – consultancy - projects and developed amongst others services for agile testing and the implementation of test organisations.

Posted in: End to end testing, Opinion, Shift Left, Software testing, SogetiLabs, Testing and innovation, Working in software testing      
Comments: 0
Tags: , , , , , , , , , , , , ,