It's regress stata how to read

Quality is the responsibility of the entire team

We have had the Agile Manifesto since 2001 and since then the entire IT industry has learned to apply agile principles and values ​​in the daily work of software development.

 

Agile manifest

One of the problems in my opinion is that many who claim to work in an agile environment have never read or really understood the agile values. When advising teams or at training courses, I have heard countless times that the Agile Manifesto claims that everything that is on the right is what we shouldn't do: e.g. in agile we would have no plans, no contracts, none Documentation or processes. I got to know a team that lost its software architects in the agile transition because architects are not mentioned in the agile manifesto. Now they are struggling with major technical problems and there is no one who can help them ... But is that really agile? The Agile Manifesto states that the value in elements is based on both Pages is included, but when we have to choose we choose items on the left. Logic says that we have all elements of the Agile Manifesto need to have, if we Deliver sustainable software and want to improve our delivery cycle. The aspect that agile methods want to emphasize is that documentation, plans or contracts are not the goals of the project, they are supporting tools. The goals of an agile project are always: to deliver working software and to appreciate each team member, the cooperation with customers and the reaction to changes.

 

The Whole Team Approach

The way in which we achieve the values ​​and principles described in the Agile Manifesto is based on the overall team approach. Since the way we work together on a project is fundamentally changing, it can be said that it is a new style of project management where everyone in the team equally for the quality and success of the product responsible is.

Software development professionals know that every development decision is also a quality decision. The Agile Manifesto assumes it is the top priority. Software quality does not depend on the software development model we use, but on the method by which we all together as a team structure the entire software development process. Together we use tools and activities that support the achievement of high software quality. One of these activities is testing.

 

What does testing mean?

Everyone in the world knows or can imagine what "software development" or "project management" is, but very few can say what software testing is, how to do it and, above all, why.

 

Ten years ago, when I started my career in testing, there was the statement: "Anyone can test!", Which means that you don't need any special skills to test. Today I declare myself: "Everyone can test software" - everyone: developers, software architects, product owners, support staff and in the company - anyone who can analyze information and build a mental model to identify invisible strings and deviations between software and requirements, business rules To discover user stories, standards, norms and legal regulations. So it can be said that testing is an intellectual sport. This is not a customary description in the industry, we say rather Testing is the process of collecting information about our product, with the aim that the team can decide what to do next based on that information.

 

Two types of tests are very important in an agile context: automated regression and exploratory tests. With regression tests we collect information about software functions that are already being used by users, and with exploratory tests we learn more about software functions that we are developing.

 

If you run tests and your team cannot make decisions based on the information gathered from your tests, the tests will not add any value. If you write weekly reports and nobody on your team reads them, the reports don't add value. When there are 12,000 automated tests and no one can say what they cover, the automated scripts don't add any value.

 

You may still have a tester on your agile team who acts as a coach for test techniques and carries out some of the tests, but everyone in an agile team should be able to gather information about the current state of the software. Remember: Quality is the responsibility of the team and not with individuals.

 

The challenge of change

The essence of the total team approach is that testers, developers and business representatives work closely together in every step of the development process. Since the entire team is responsible for success and quality, is the whole team or at least representatives of each discipline - see three Amigos - involved in any consultation or meeting where product features are presented, analyzed or estimated. It can be a struggle for many organizations and individuals.

 

In my experience, the first attempt to switch to agile software development looks like a 2-week waterfall development in 90% of cases. It's difficult to change the way a person works or thinks, a corporate culture, or processes that already exist. People and companies need to overcome established unfavorable practices, such as working in silos or not listening to young members. Give them time and recognize people's fears because at first it is scary to change! Some of the concerns people have expressed to me are:

  • "How exactly should I support my team members?"

  • "If everyone should be able to test, what else should I, the tester, do?"

  • "When the whole team decides on issues, what should I, the project manager, do? Is there still a job for me?"

  • "As per our HR guidelines and my job title, I'm a senior developer, but I've never really understood testing. What will happen if others find out?"

All of these are legitimate questions and should be addressed.

 

But you are not alone with all of these questions; many members of teams around the world are confronted with them. Janet Gregory and Lisa Crispin were two of the pioneers in agile testing. Many agile testers reverently fondly refer to their book "Agile Testing" as the Bible because it was the first comprehensive book on testing in an agile context. Today there is the extension "More Agile Testing" and the three-day practical training in English "Agile Testing for the Whole Team", for the entire software development team with games and exercises on collaboration, planning and agile test quadrants. I give this training myself because I am convinced that I can use it to give many team members valuable knowledge for implementation in their everyday work. But no matter whether you are reading a book or training or blog posts or just trying it out for yourself: I encourage everyone to deal with the whole team approach, because it is an important step forward when the entire team feels responsible for success and quality.

 

Do you also struggle with the questions I have described? Let me know in the comments.

Please enable JavaScript to view the comments powered by Disqus.