It is about how we - as a team, in a structured way - can approach the topic "software quality" in an agile context.
I have already conducted the training "Agile Testing for the Whole Team” (ATF) many times. The interesting thing is that my participants say the same thing I did when I first got to know the course: you can immediately see that someone with hands-on experience has designed this course, someone who comes from the real world, someone who brings a breitband of project and consulting experience.
Everything that we learn in this training is immediately applied in group exercises. The training is accompanied by many practical examples, many stories and illustrations, which illustrate the whole thing. There are several small tasks where teams of 3, 4, 5 or 6 people are formed. The other thing that makes this course so specific is a task that runs and grows throughout the course.
Short answer: you cannot really compare those two very different trainings. A slightly longer answer: ISTQB is a pretty dry theory training where the focus is on methods and procedures that we use for testing: white-box, black-box and experience-based. It is very important for getting started with software testing and quality, but that is not enough. The "Agile Testing for the Whole Team" training focuses on quality as an integral part of software development. How do we get the best possible result for the team and the customer with what we have.
Source: Janet Gregory and Lisa Crispin from their ATF course
The training is really meant for the whole team. All the people involved in the success of the project, not just testers and developers, but also sales, support, operations, maybe a software architect, in other words, everyone who has an influence on the project. I use a surgery team as an example: surgeons, nurses, anesthesiologists - they all have to work together. It's not enough if just one of them does a good job, the whole team must collaborate in the best interests of the patient.
We know from the past that software development has not so many challenges when developers work together with developers or testers with testers. Problems typically arise where one team passes work results to the other team, e.g. developer to tester or tester to operations. This is an important part of agility, not to go back to the original professional teams and continue to practice mine and yours, but understand: that is all of us who are in this boat. What is the fastest way to move forward? It is about teams, team decisions and team cooperation. The whole team is responsible for software quality. That is why in agile we build cross-functional teams and train them to work seamlessly together. Collaboration means more than just sitting together in a room or working on the same project.
We all want to create useful software for our customers, we want to deliver quickly and we want to add value. We can only do this if we have a common understanding of the individual parts as well as the overall result.
Source: Janet Gregory and Lisa Crispin from their ATF course
Saving costs is a very important factor. I always ask: how much does success cost? How much is it worth that this team is successful? What does team responsibility mean to you and how important is software quality in this project/company? How does communication and knowledge transfer work in the team/company? Are these individual experts or teams with equal members and built in knowledge sharing? Answer those questions and you will have an answer to your question who should attend the training.
After almost every training I gave for a whole team, the participants almost always said, yes, now we see testing and software quality with different eyes and also understand team cooperation much better. I also gave training where only a part of a team or only one team member was present. Typical feedback in those groups is: it's a pity that the whole team wasn't there. It's not uncommon that these companies book a training session for the whole team afterwards.
In the training the focus is on testing and quality. But by doing that we have to address unpleasant, maybe even painful topics in the teams experience as well: Why didn't it work out so far? If this is structured, moderated and targeted, we can also see it as a team-building activity.
The assessment is another good example how much thought the creators put in this training. It is not punishment oriented, you cannot fail!
The assessment is built as a summary of what we have learned during the training. For example, my training looks different from the one that my colleague Arjan gives. We have different training styles and different experiences in software projects. So it is logical that I share different stories and we have a different atmosphere in the room. But what is important is that the core information reaches everyone, every participant, and is the same in every training. This is what we is checked during the assessment. Janet and Lisa have no interest to make you fail, but to make sure that you got most out of the training. That is why after the assessment participants have the opportunity to see the right answers for their wrong answers. To learn from it and to recognize the potential for improvement.
Source: Janet Gregory and Lisa Crispin from their ATF course
After the assessment, each participant receives an invitation to join the Agile Testing Fellowship. This is a slack channel, with different rooms for different topics. You have the possibility to talk directly to Lisa or Janet or other participants who did the training from all over the world. Of course I am there as well and will be glad to help you even after the training. Quite often people in very different companies and domains experience the same tricky situations. On Agile Testing Fellowship we come together and support each other. Sometimes it is simply compassion, sometimes an experience story or a link to a blog article or a book title. It is a community where you can address your questions and get answers.
trendig
