As part of the Internet product development process, test cases are a painstaking and patient endeavor. The writing and expression of test cases require testers to be familiar with the page hopping logic and functional explanation of products, so product personnel must participate in test case verification or even design.



Test cases will also have corresponding use case reviews. The test case review also becomes a meeting for re-understanding and communicating requirements. Different from requirements review personnel, test case review involves test, development, and product personnel.


If you haven’t been through a test case review, don’t assume the current development process is flawed. In the startup team, use cases should only ensure that the main functions and main processes are common, in order to launch the MVP product as soon as possible. Non-urgent bug issues are treated by both the product and the testers as late optimizations, and test case reviews can slow down the development process.



Unlike test case reviews, if there is no test case review there must be a need to communicate with the small team again, we can also use such communication as a use case review. However, such communication tends to be on the main function, not as detailed as test cases, and there is no top-down, inside-out communication sequence of requirements, leading to requirements adjustments or changes during development.



The product person double-checks the requirements


Often in test case design, this requirement has already been reviewed weekly. Product people are already wandering around other requirements at this point. Review meetings around use cases can lead to problems such as unwashed or forgotten requirements.


  • Use case review in advance

  • Upstream and downstream issues of demand

  • Demand background


I recommend that product newbies do all three before preparing test cases. The first is a timely review of the use cases, and the second is to clarify the upstream and downstream of the requirement (for example, the order will involve logistics rush, inventory, financial settlement), and what the problem is solved by the requirement.



In use case design, it is also a training for product people to improve their boundary value and product design ability. The reason WHY I ask product newbies to learn how to design test cases is because the test cases take into account product flow, page hops, and interaction issues. Gathering feedback on your product from testing and even development can make it better.


The product manager cannot ensure that every requirement is 100% unobstructed and perfect. By timely collecting unreasonable requirements feedback in use case design, the product manager finally summarizes the weak requirements of his own.


Similar to the above screening conditions, it is difficult for product people to think of the sub-logic of screening. Does the user operate from top to bottom or bottom to top or in combination? Simple 2 components with a lot of logic behind them.


Start with use cases


Many product manager hires, myself included, look for product recruits from product assistants or product specialists. It does not want to come from the transformation of development or design, for the purpose of establishing a set of “user experience” of the product sense.


Once you get into development or design, the idea is not to be primarily user oriented. But even so, we have to deny, from doing design, development to product students also have advantages.


The previous experience can be used for reference in the difficulty assessment and design assessment of requirements.

But I would say that for newcomers to the product, learn to start with use cases. Learn to describe use cases and possible interactions for a product page. Familiar with the number of controls and pages in the product, timely grasp the basic product interaction or jump form.


A good use case design must be fast, accurate, master the main flow and main function, secondary path. It is convenient for newcomers to better consider future expansion and background management.



But keep in mind that test cases only help us better understand the requirements and their justification. It is unnecessary to spend a lot of time designing a few use cases for a single page. Communication of requirements is essential


Well, that’s it for today’s share. I try to update two articles a week



A recent project




Product landing meticulous work, standard copy

Background products, 1 case | column is activated

Learn to “guide”, let demand quickly landing

Another way to deal with price reduction, product PK demand side

Life is inseparable from the product manager

What do product assistant (specialist), product manager, senior product manager, product director look like?

Who was the product manager 10 years ago?




In addition, my first book “From Zero to One: PM changes the World” was officially launched as an electronic file. This book summarizes 222 original products, covering the content of product manager interview, algorithm, interaction and other different dimensions. If you are interested, you can reward and leave a message on your email. I will send an email to you around 12:00 noon every day (hope you do not spread support, support copyright). If you need to preview the book outline, jump to the link


A book for yourself and product people: from zero to one.