When you first join a company and a brand new product is placed in front of you, how do you get started quickly?
dot dot dot. . .
Although practice is the first element to become familiar with the system, we need to think about it quietly.
who I am? --QAWhere
am I? --**Product Group
What do I want to do? --Guaranteed quality
How many are you familiar with? --One week
What resources are available? --Use cases, documentation, a group of happy friends, etc.
As the saying goes, cats have cat lanes and dogs have dog lanes:
Programmers can read code and design documents.
Products can read requirements documents and product manuals.
Testers can read use cases, BUG sheets, and related requirements design documents.
Step 1: Determine the product life cycle
The product life cycle is divided into: entry period, growth period, maturity period and decline period.
Depending on the stage of the product, we must also be selective in learning and in-depth when we start.
-
Entering period
: At this time, there are fewer users of the product, and various functions and documents are being continuously updated and iterated. Quality and reliability are low. -
Growth stage
: The market growth rate is high and demand is also growing rapidly. -
In the mature stage
, the market is basically saturated, with fewer new customers and more reliance on repurchases from old customers. -
During the decline period
, new products are substituted, and the products are gradually withdrawn from the market or maintenance is stopped.
Step 2: Understand the background of the product
When we buy a brand new product, don’t rush to operate the operating system first.
After understanding the stage of the system, you also need to understand the product solution and the related background of the product, and clarify the following questions:
What is the background of making the product? What
does the product do?
Who are the customers and user groups it serves? What
are the core business scenarios? What are
the core functions and processes?
After clarifying the above issues, before operating the application system, you can become familiar with the product and operate the system purposefully.
Step 3: What content is available for reference?
In the process of operating the operating system, it is still difficult to master the detailed product design and application logic from simple operations. At this time, we need to use some resources at hand, so we need to see what information is available for our reference.
If the production process is relatively standardized, the following documents should be available:
Requirements document - understand the background of making relevant requirements, so that we can better understand the requirements.
Design document - understand how the relevant requirements are implemented in detail, including interface design, field design, algorithm, etc.
UI/UX - understand the interface specifications, Design style, business process, etc.
Product manual - understand the use of specific functional modules
Test cases - understand the test points of relevant functional modules, compare detailed
flow charts - understand the business processes, generally only core businesses will organize flow charts, and you can organize the business Operate and string together
BUG lists - understand development and testing thinking, and find problems more easily.
Friends - besides yourself, who else is working on this product?
The above are all output documents in the product development process, which can better help us become familiar with the product in depth.
When the product is in the entry stage and does not have many system features:
You can study the design documents carefully and perform system operations according to the test cases to become familiar with the product, which is more precise.
When the product is in other stages and has relatively large functions:
Because there are many requirements, design documents, and test cases, there will be a lot of redundant information [problems such as untimely update and iteration of requirement use cases].
The learning cycle will be very long, and you have to distinguish the authenticity by yourself, which is really time-consuming and labor-intensive, and may not necessarily lead to better results.
Suggestion: Start with the core business first, follow the business flow chart operation practice, and then review relevant documents in a targeted manner when encountering detailed problems.
In the process of getting familiar with it, you can try to sort out the relevant business logic and draw flow charts. When you can sort out a relatively complete business process, it means that your mastery of the product has reached a certain level.
In addition, we can also obtain change records of relevant functional requirements from TAPD/JIRA/ZenTao to assist our learning.
As you become familiar with the business and become proficient in product operation, you can consciously understand some of the product architecture and technologies used, which will help with daily testing.
Finally: The complete software testing video tutorial below has been compiled and uploaded. Friends who need it can get it by themselves [guaranteed 100% free]
Software Testing Interview Document
We must study to find a high-paying job. The following interview questions are the latest interview materials from first-tier Internet companies such as Alibaba, Tencent, Byte, etc., and some Byte bosses have given authoritative answers. After finishing this set I believe everyone can find a satisfactory job based on the interview information.
