There is no requirement document! How to test? How to design test cases?

 

How to design test cases when there is no requirement document

1. Sort out the test requirement traceability table according to the customer's function points:

  • Generally, customers have to write a form of the function points of the software to be developed and submit it to the marketing department, and the marketing department will transfer it to the R&D department. Therefore, the customer's function point is the most important basis for writing test cases.

2. Organize our functional test points according to the Developer’s Software Specification List:

  • Generally speaking, developers must divide the function into several sub-modules to realize a function, so the Software Specification List is another important basis for our reference.

3. Carry out project inter-departmental seminars:

  • You can take time to call the project leader, product manager, project manager, software development manager, and software developer of the marketing department to talk about their understanding and design patterns of the entire product, and their understanding and knowledge of each function point. Follow the train of thought and reach a consensus, the tester is responsible for recording, and the test leader is responsible for sorting and summarizing, forming part of the reference documents for the test.

4. The testers sort out the use case requirements and submit them to the project team and customer representatives to reply:

  • Based on the understanding after the project discussion meeting, the testers may encounter problems (such as: boundary value, input data type, etc.) and unclear requirements during the test process, sort out the use case requirements and ask the relevant module leaders to " Respond to the "Use Case Requirement Question" form, and give a detailed explanation and description.

5. Project internal use case review:

  • Testers write test case points based on their understanding of the project. After the internal review and modification of the test team, members of the project team can be summoned to help review and then make changes. After many revisions and reviews, the main points of the test case may be more comprehensive.

6. Mail and customer representatives confirm some disputes:

  • Testers, developers, and project team members sometimes have different opinions when discussing demand issues, and each has its own reasons. In this case, it is best to write the disputed issue as an e-mail and send it to the customer for the customer to approve and determine that the demand is reasonable. , How to do it? Copy to all members of the project team, so that everyone can understand the opinions of customers. When writing the test case at the end, the content of the customer’s email shall prevail.

7. Project Demo and some developed systems:

  • In most systems, because there is no demand, in order to avoid project risks, developers generally have to make demos, and constantly ask customers to sign after confirmation, and constantly display newly developed functions to achieve the purpose of attracting customers. If there is a Demo in the project, the Demo is also a reference standard. If there is nothing, then some of the functional modules that have been developed should be known to users at any time, and some suggestions for revisions should be put forward, which can also provide some basis for us to be familiar with the system.

8. Refer to similar products in the same industry and competitors:

  • If it is a website similar to an online bookstore, when we write test cases, we can look at "Dangdang", "China-pub" and other similar mature related websites. It is easy to find problems with our products and unconsciously add competitiveness to the products. The understanding of competitors must be indispensable.

9. The test of the cross module is most easily overlooked:

  • In general products, the cross of functional parts means that the parameters are set in the A module, and the actual application of the parameters is reflected in the B module and the C module. The more difficult ones are the cross-modules in the "banking system" we are testing now, and it may also involve calls between different users and more than 3 modules. Even if there is a demand, it is rarely written, and it is also a weak link in demand writing. It is difficult for junior test engineers to consider the issue of writing test cases like this. For modules with this kind of cross-functionality, the elite soldiers in the project team must be required to draw a related call relationship diagram to indicate the call relationship, so as to facilitate the writing of test cases later.

10. You can use telephone, MSN, Skype and other online chat tools to consult some requirements:

  • Most of the customers of the products we make are abroad, and the test manager can also use these online chat tools to confirm some demand questions with customers. However, it is necessary to have better time in advance, and pay attention to the "time difference" in different places.

Software testing exchange group: 785128166

WeChat public account: Programmer Erhei; After paying attention, you can receive a set of video resources for free; explain in detail: python automated testing, web automation, interface automation, mobile terminal automation, interview experience and other related content, the value of learning resources depends on you Action, don’t be a "collector"

Next update: Five misunderstandings in test case design

Here is a collection of selected dry goods articles for functional testing:

Dry goods sharing | Featured article collection of functional tests (Are you afraid that you can't find the article you need?)

Guess you like

Origin blog.csdn.net/m0_52668874/article/details/115141839