Small white Growth Advice (8)-The enemy-cloud

Demand management

Demand management I put it in the last part of the theory, and it's the hardest place I think. The difficulty with demand management is that it is important for testing but is far from testing work. As we said earlier, the use case, especially the system test case, is very dependent on the requirements document, because the expected value of the use case is the final result and is determined by the requirements. So if the use case is correct, it often depends on whether the demand is correct.

Remember that there is a very classic English sentence:

is we build the right product?

is we build the product right?

This can be a good indication of whether the use case is important or the need is important. Good testers can always ensure that product right but there is no correct demand where is the rightproduct? So a product without bugs but bad use, not good to sell, in fact, testing also has a certain responsibility in the inside!

So what's in demand management? I'm going to talk about demand management from three perspectives:

1. Demand development

2. Demand management

3. Test Requirements Management

Demand development

Everyone has their own needs, in the reading of this article you will also have the need, but some requirements are explicit some of the requirements are implicit. Like often ask a friend "you look for objects have what request", answer always "not what request Ah, person good on line", behind the subtext is, look pleasing to the eye! And the so-called look pleasing to the eye is their own choice, did not want to clear the conditions, then think clearly say it.

The same problem exists for customers of software development. What the customer wants, and what you understand, there is a big gap between what you have the ability to do, and the key to the problem is communication.

1.BA business analyst Communication with customer

2. Communication between developers and business analysts

3. Communication between testers and business analysts

4. Test the communication with the customer

Here there is the ability to achieve and customer demand dislocation and communication of the technical cohesion blurred, resulting in the software will be such or such a aliasing. Although demand development is the responsibility of the business analyst, as a good test, in order to ensure the quality, then also need to have the corresponding ability to go to the needs of analysts around, to provide them with technical and business logic of some support.

If you want to be able to help demand analysts test requirements, then as a test you have to either walk on the customer side to analyze the problem, or you can go to the end of the technology to tell demand analysts this thing technology can be achieved, the implementation of how to verify.

Demand development involves a lot of technical content, the most direct is the business description. The technologies that exist in business descriptions include business writing (typically writing documents) and business modeling (often referred to as prototyping), where the tools used include not only traditional UML-like modeling tools, but also prototyping tools like axure and even more professional UI design tools. To make it easier for users and developers to understand exactly what to do.

Demand management

The content and relationship of the main management requirements for demand management. The content can be said not much, but the demand will also have its prescribed format, as far as possible to ensure the integrity of the demand information. For the relationship between requirements, this may be more important in demand management, what is the relationship between the requirements, here is an example:

If you send a request in a circle of friends, you need a pen, then there will be a lot of people see your needs, maybe they all have the conditions to help you, so they sent you a pen, and then you find that the pen is too much you can either return the pen or need a pen to put pens, and then you send a demand for everyone, since everyone gave me so many pens, So, give me another pencil case? The tragedy is likely to continue in samsara.

The problem here is:

1. The implementation of the requirements may be achieved by many people, if there is no control strategy, everyone to implement the requirements, may lead to the need to be excessively realized, and lead to waste of resources. (Send the old lady to cross the road to do good things jokes do not know people remember not)

2. How is the subsequent impact of the implementation of the requirements controlled and maintained? When a requirement is implemented or changed, all subordinates and related content can be affected, and how to assess the scope of the impact and the cost is very important.

In most companies, the problem is related to demand management, the problem is the ability to control the demand, which is how to effectively assess the impact of changes in demand (the more the ability of demand management, the impact on subsequent research and development testing is small, or expect the ability of the relevant departments is strong enough)

In general, demand management is the process of hierarchy of requirements, which can be easily understood as a binary tree-like situation. With such a clue, you can simply know the number of subsets of requirements under each requirement. Tools in this area can help us to manage these content, but the tool does not solve the essential requirements of the main requirements of the coverage ratio maintenance, not to say that a demand under a plurality of requirements will be able to completely decompose the main requirements and effectively cover the main requirements, once there is a demand omission, Then it means that development will be missed and the test will miss the point as well.

So essentially tools can help people who have ideas better manage and deal with problems, but tools do not allow people who do not think to do more, but will be blinded by the surface, too much to cater to the use of tools. In demand management, this is not a tester needs too much involved in the mire, but it is a good test engineers need to try the new world, because only the people who walk in front can really grasp the quality, improve quality.

Test Requirements Management

Earlier we talked about demand management, which is far from the test work. So now let's talk about the test requirements management that is relevant to the testing effort.

What are test requirements? Most white men equate the test needs with the requirements directly. In fact, the test demand from the demand, it is the tester's understanding of the needs of induction and summary. It may be said that good test requirements extraction is an important part of the design of test case framework, and good test case framework can effectively improve the efficiency of the whole test work. Especially for projects with frequent changes in requirements or complex business logic, the results are particularly noticeable.

If you want to ask how to extract the test requirements, then I can only say that each project has its own particularity, need to correspond to different test requirements extraction work. So how exactly should the test requirements management be done? In addition to the above-mentioned methods in demand management and the use of tools, we need to continue to practice in the work of summary. In layman's terms, write more test cases, modify test cases more, you will gradually have the use case framework concept, also understand how to do the test requirements extraction and management work.

By the end of this chapter, some of the basic theoretical chapters of the test have come to an end, looking back on the test basics, defect management, use case management, configuration management to today's requirements management, and strive to introduce in the simplest and most simple language what you need to know about those tests. It's not too easy to let the reading you feel boring.

After understanding some basic theories, I will take you to the next chapter to see some of the specific things.

Small white Growth Advice (8)-The enemy-cloud