Recently, "agile testing" has become a hot word, and my friends, including students, will also ask me, what is agile testing? The reason is probably because of the popularity of the concept of agile development. After reading the trial reading chapter of Mr. Zhu's book, I also have a deeper understanding of agile testing, so I also follow the content in the trial reading and make a simple "agile testing" that I carried out for the first time. elaborate.
The first time I started agile testing was when I first entered the field of testing, applying the "agile" mindset to a small project team in a small company. First of all, I would like to say that this agile attempt was a complete failure, and I believe that failures like ours are not just a single case. You can continue to learn more about it. There were six people in the team at that time, one PO was responsible for the organization of user stories and the formulation of sprints; one PM was responsible for the planning and assignment of tasks for the entire sprint; three developers and myself. But what is the final form? It has become an agile waterfall process; po is the requirement person, organizes requirements, pm assigns tasks, developers just write code silently, and me, as the last testing link, is in the process of "continuous delivery" Acceptance testing of this version and regression testing of the previous version before giving it to customers. The only thing that remains is the "daily standup meeting" in Agile, and the undocumented tradition.
Is there any real meaning in such a "pseudo-agile" process? I think the answer is almost no, but the endless meetings, undocumented but gradually lack of communication made the whole process more detours. Later, when I actually completed an agile process, I went back and summarized the failure process and found the following points:
1. As Mr. Zhu Shaomin mentioned in the book, agile testing should emphasize "automated testing". Without automation, how can agility be achieved, and how to continuously deliver software that satisfies customers? Embracing changes in requirements also depends on complete automated testing including unit testing, otherwise the so-called embracing changes in requirements is just empty talk.
Second, agile emphasizes communication, because few working documents are produced. However, when agile is first performed, the enthusiasm is still there, and the communication is more frequent, and gradually, everyone does not feel the meaning of communication, so agile becomes empty talk.
Third, the idea of test-driven development. In other words, unit testing is the foundation of everything, and neither the developers nor the testers had the ability or willingness to do "additional" unit testing at the time of our project. what's the result? There are many problems with each test, and fixing these problems takes a lot of time. Where does "agile" come from?
In addition to mentioning these three points, there are actually many problems. Here I just want to give this example to tell all colleagues, whether it is PO, PM, development or testing, remember that "agile" is not just a word, nor is it a It can be done by maintaining a few meetings or something, but it is a kind of thinking concept. Agile is the general trend, but it also requires sufficient conditions to develop.