Agile Development and Agile Testing

Agile development
is a human-centered, iterative, step-by-step development method. In agile development, the construction of a software project is divided into multiple sub-projects, and the results of each sub-project are tested and have the characteristics of integration and operation. In other words, it is to divide a large project into multiple small projects that are interconnected but can also run independently, and complete them separately. During this process, the software is always in a usable state.

1. The route of agile development:
- Test-Driven Development, test-driven development.
　It is the most important part of agile development. At ThoughtWorks, we start from testing to implement any function. First, we analyze the business requirements, decompose them into stories one by one, and record them on the Story Card. Then two people sit in front of the computer at the same time, one person writes the test code from the perspective of business requirements according to Story, and the other person looks at him and thinks. If there are different opinions, they will be discussed until a consensus is reached. The test code written in this way truly reflects the business functional requirements. Then another person controls the keyboard and writes the implementation of the test code. You can't write the implementation code of a feature without the test code. Write the test code first, so that the developer can clarify the goal, which is to make the test pass.

- Continuous Integration, continuous integration.
　　In the past software development process, integration was a very painful thing, and it usually took a long time to do integration, which would cause many problems, such as build failure or unit test failure. Continuous integration is advocated in agile development. It is integrated a dozen times or even dozens of times in a day. Such frequent integration can minimize conflicts. Because integration is very frequent, there are few changes in each integration. Even if the integration fails, it is easy to locate errors. What to do with an integration? It includes at least: getting all the source code, compiling the source code, running all the tests, including unit tests, functional tests, etc.; confirming whether the compilation and tests pass, and finally sending the report. Of course, it will also do some other tasks, such as code analysis, test coverage analysis, and so on. In our company, there is a volcano light on the developer's desk to indicate the status of the integration. If the light is yellow, it means that the integration is in progress; if it is green, it means that the last integration passed, and the code obtained by the developer at this time is available. And reliable; if it shows a red light, be careful, the last integration failed, you need to locate the cause of the failure as soon as possible so that the light turns green. In continuous integration, our company uses the product CruiseControl developed by ourselves.

- Refactoring, refactoring.
　　I believe everyone is familiar with it. There are many books used to introduce refactoring, the most famous are Martin's "Refactoring", Joshua's "From Refactoring to Patterns" and so on. Refactoring is to organize and optimize the internal structure without changing the external behavior of the system, so that the code is as simple, beautiful and extensible as possible. In the past development, there is usually a demand, and the current system architecture is not easy to implement, so the original system is refactored; or there is time left in the development process, the current code is refactored and sorted out. However, in agile development, refactoring runs through the entire development process. Before each developer checks in the code, the code must be refactored to make the code clean code that works. It is worth noting that when refactoring, each change should be as small as possible, use unit tests to ensure that the refactoring does not cause conflicts, and refactor not only the implementation code, but also the test code if there is duplication in it. Refactor.

- Pair-Programming, pair programming.
　　In agile development, doing everything is Pair's, including analysis, writing tests, writing implementation code or refactoring. Pair has many advantages in doing things. When two people discuss together, it is easy to generate sparks of ideas, and it is not easy to take a detour. In our company, there are still many things done by Pair, such as Pair learning, Pair translation, and Pair making PPT. On this topic, Qian Qian has a famous article to introduce it, called Pair Programming (pair programming). ).

- Stand up, stand up meeting.
　　Every morning, all members of the project team will stand for a meeting. Because they are standing, the time will not be very long, generally 15-20 minutes. The content of the meeting is not needs analysis, task assignment, etc., but everyone answers three questions: 1. What did you do yesterday? 2. What are you going to do today? 3. What difficulties did you encounter? Standup meetings allow teams to communicate, familiarize themselves with each other's work content, and if someone has ever encountered a problem similar to yours, after the standup meeting, he will discuss it with you.

- Frequent Releases, minor releases.
　　In agile development, this situation does not occur. After getting the demand, it works behind closed doors, and the product is not delivered to the customer until the end. Instead, as many products are released as possible, usually on a weekly or monthly basis. This way, customers will get released products to try out every once in a while, and we can get more feedback from customers to improve the product. Because of the frequent releases, the new functions of each version are simple and do not require complex design, so the documentation and design are simplified to a great extent. And because of the simple design and no complex architecture, customers can quickly adapt to new requirements or changes in requirements. 

- Minimal Documentation, less documentation.
　　In fact, in agile development, it is not that there is no documentation, but there is a lot of documentation, that is, testing. These test codes truly reflect the needs of customers and the usage of the system API. If a new person joins the team, the fastest way to get familiar with the project is to show him the test code, which is more efficient than debugging while looking at the documentation. If written documentation or comments are used, and the code changes one day, these documents need to be updated. Once you forget to update the documentation, there will be a mismatch between the code and the documentation, which is even more confusing. In agile, it does not appear, because the code changes only when the test changes, and the test actually reflects the code. At this time someone will ask: Does the code not write comment lines? Doesn't generally good code require a lot of comments? In fact, simple and readable code is good code. Since it is simple and readable, others can understand it at a glance. At this time, there is no need to comment on the code at all. If you think this code is uncommented, others may not understand it, it means that the design is not simple enough and it needs to be refactored.

- Collaborative Focus, centered on collaboration, manifested as code sharing.
　　In agile development, the code is owned by the team rather than the code of which modules belong to whom. Everyone has the right to get the code of any part of the system and modify it. If someone sees some code that is unhappy, he can Part of the code is refactored without asking the author of the code, and probably not knowing who wrote that part of the code. This way, everyone can be familiar with the code of the system, and there is no risk even if the personnel of the team changes.

- Customer Engagement, live customers.
　　In agile development, the customer works with the development team, and the team develops at the customer's site or invites the customer to the team company for development. If there is any problem in the development process or the product goes through an iteration, it can get feedback from customers as quickly as possible.

- Automated Testing, automated testing.
　　In order to reduce manpower or repetitive work, all tests including unit tests, functional tests or integration tests are automated, which puts forward higher requirements for QA personnel. They need to be familiar with development languages, automated testing tools, and be able to write automated test scripts or record them with tools. Our company has done a lot of work on automated testing, including the Selenium open source project.

- Adaptive Planning, adjustable planning.
　　The plan in agile development is adjustable. It is not like in the previous development process, requirements analysis->outline design->detailed design->development->test->delivery, each stage is carried out in a planned way, a stage When it is over, the next stage begins. In agile development, there is only one iteration, a small version is released, and corresponding adjustments and changes are made at any time according to customer feedback.

　　The agile development process is very different from the traditional development process. In this process, the team is passionate and dynamic, able to adapt to greater changes and produce higher-quality software.

2. Agile development methods There are many
agile methods, including Scrum, extreme programming, function-driven development, and unified process (RUP). Work as a whole; work in short iteration cycles; deliver something per iteration; focus on business priorities; review and adjust. Agile testing First of all, Agile testing is a type of testing. In the original testing definition, problems are found by executing the system under test. The concept of providing metrics for the system under test through testing is still applicable. Agile testing is a testing practice that follows the Agile Manifesto: 1. Emphasizes testing the system from the customer's point of view, that is, from the point of view of the users who use the system. 2. Focus on continuous iterative testing of newly developed features, rather than the rigorous testing phase of the traditional testing process.









3. It is recommended to start testing as soon as possible. Once a certain level of the system can be tested, such as providing module functions, unit testing at the module level should be started. At the same time, as the test deepens, continuous regression testing should be carried out to ensure the correctness of the previously tested content.

The difference between agile testing and ordinary testing:
1. The project is equivalent to parallel development and testing, and the overall project time is faster.
2. The module submission is faster, and the test is more oppressive.
3. The work tasks are clearly divided and the work efficiency is high.
4. The project planning should be reasonable, otherwise there will be re-testing during the test, and the workload will be increased.
5. The problem needs to be followed closely. The staff in the project are busy, and the problem is easily forgotten.
6. Problems that are time-consuming or difficult to solve and have little impact on the project will generally be left to the next stage to solve.
7. It is found that the BUG can be solved quickly, and the impact on the testing of related modules is relatively small.
8. The version replacement is more frequent, which affects the speed of the test.
9. Communicate with developers more.
10. Pay attention to the update of the version.
11. Testers attend almost all meetings of the entire project team.