"Agile Software Test" reading notes (vi)

Summary of the fourth part

1. Overall team involvement

2. Use Agile Test Thinking

3. Automated Regression Testing

4. Provide and get feedback

5. Fundamentals of building core practices [continuous integration, test environments, managing technical debt, incremental work, coding and testing are important components of the same process, collaboration between practices]

6. Working with customers

7. Keep Bigger picture

------------------------Self-reflection--------------------------------------------------------

1. Is the document really important in agile testing?

In the current project, there is a very missing document. Agile testing pays attention to ROI and thinks that meaningless things can be done without. But I am still a task document is very meaningful, one is the current staff is a carding process, in writing documents to add more thinking, to ensure the correctness of the project, the other is to promote communication between the correctness and the basis, and also write documents for the maintenance of the later project is very helpful, reduce the familiarity of the staff behind the cost.

Unable to understand the current project, why there is no document, even a little bit of documentation, suspect that the previous person did not record in the public area documents, handover work is not done.

2. What is the relationship with the product manager? We don't have access to real customers.

Agile testing requires testing in accordance with the user's point of view to ensure product quality, but the actual work often has product managers to direct customer exchanges, we are difficult to directly communicate with customers. Then we as users are only ourselves. Product managers also tend to misunderstand customer needs. The existence of these contradictions should not be tested should be involved in the whole process of the project, from the requirements to the final release of the project, and even to the online feedback. If the whole process is covered, it is possible that testing can really guarantee the effectiveness and quality of the product. But what about the real situation? The project team ignores the test, the test is only as the development team is unwilling to do things, testing work because of unequal treatment in the project is not good, the work is not done well is not recognized by the team, so vicious circle. Testing is an awkward position, from the top to the bottom of the non-attention, the big environment that the test is back to the second job.

3. I know the agile test?

Agile testing is value-oriented and is oriented to efficient output value. Agile testing, in other words, is an Agile development team that tests how it should work.

Method: Test ahead, use TDD to ensure the quality of the code and reduce their useless work, the time to apply to valuable things, positive communication, in the team to encourage everyone to support the work of agile testing, continuous improvement of project problems, record production problems, use automation to reduce duplication of work, Improve work efficiency;

Speaking of a point where I have always understood the wrong idea, I agreed with him after discussing it with my classmates at x. Previously I thought: Agile testing is a kind of chaotic mode similar to the current company, constantly iterative products, constantly on-line. Now, in fact, it is not so, agile is not equal to "chaos", but not "demand is not clear." Agile simply shortens the product cycle, uses an iterative approach to develop products quickly, and obtains user feedback in advance to improve product quality. At present, the company's "chaos" development, is because the demand is unclear, did not consider clearly, blindly pursue the product's on-line speed. In addition, I think agile development does not mean that the final product speed must have a big step forward, but its product quality must be more to meet user requirements, and in line with the times. Say now the company's chaotic mode, speed must be fast, but the quality of the dare not compliment, the ultimate bear can only be users.

4. Who will certify the quality?

In fact, whether it is agile testing, quality should ultimately be authenticated by the user, because the user is the ultimate product of the bear, the product and the user is the most closely related. Good quality products, user benefits, conversely, the user is the consumer of bad quality. No matter what the final product realization is, users feel good, is good, feel bad, that is, rotten products.

There are also "dominant users, change the user habits of a said," If in the long run, this thing is beneficial to users, a moment to let users uncomfortable is actually acceptable.

5. How to develop a good relationship?

The story of the candy in the book is still very interesting, some candy can be in exchange for the harmonious relationship, the status of Equality. There is also a view that testers should be a co-worker rather than a mandatory one, so it can be seen that the author is more likely to recognize that the people on the team are helper roles that are helping the team and the product grow.

The relationship that individuals feel can be promoted and developed from the following points: 1). People get along with people must be "feeling" of harmony, usually more exchanges and sharing can let other people to "friends" and partners to recognize you; 2). Give them more help, even if you simply build an environment that yields the value you can produce; 3). The promise of things must be done, small things to do as best as possible, recognition of your work is to recognize you.

6. Can testing really be a driver of TDD?

I think it is obviously not possible, or if it is to be done, it must be conditional.

Reasons for not: 1). The most direct, the constant change of demand, lead to testcase too early completion may be useless work; 2). Status inequality, testers cannot be able to exist as a driver; 3). The ability and level of the tester is limited, not convincing;

The premise of being a driver: the ability of a tester is equivalent to the level of an architect, and the product can be fully determined at first;

"Agile Software Test" reading notes (vi)