Software Testing "Basics"

Software Testing Lifecycle

Requirements analysis → test plan → test design, test development → test execution → test evaluation

Requirements analysis: analyze whether the requirements are complete and correct, and obtain test requirements according to the requirements

Test plan: planning and executing the test plan, including when to start the test, who will test it, when to end the test, when the project will go online, etc.

Test Design: Design test cases based on software requirements

Test development: develop test tools, develop automated test cases

Test execution: Execute the test case, if a BUG is found during the test, submit the BUG, ​​and the developer must accept the BUG after modifying the BUG

Test evaluation: output test report

Example of test report

how to describe a bug

Why describe a BUG?

Testers and developers communicate about bugs mainly through bug descriptions. If bug description information is not generated, testers and developers have to communicate face-to-face. Therefore, through the description of the bug, the developers can understand the bug and solve the bug

how to describe a bug

1. The version where the problem was found

Developers need to know the version where the problem occurs, so that they can obtain the corresponding version of the code to reproduce the fault. And the identification of the version is also conducive to statistics and analysis of the quality of each version.

2. The environment where the problem occurs

The environment is divided into hardware environment and software environment. If it is a web project, you need to describe the browser version, client operating system, etc. If it is an app project, you need to describe the model, resolution, and operating system version. A detailed description of the environment facilitates fault location.

3. Steps to reproduce the error

Describe the shortest steps to reproduce the problem .

4. Description of expected behavior

Let the developer guide what is correct (the steps to operate when the result is normal), especially to describe the behavior of the program from the user's perspective. If the fault is based on the requirement, it is best to state the source of the requirement.

Believe it: Testers know the requirements best.

5. Description of wrong behavior

Describe the error phenomenon. Crash , etc. can upload logs , and UI problems can have screenshots. (Describe the generation of the problem, and we can directly take screenshots at the UI level)

6. Others

Some companies have other requirements, such as the classification of faults: functional faults, interface faults, compatibility faults, etc. Some priority classifications seriously affect the test and need to be modified by developers first. You can set the priority to high

example

How to define the level of bug

Blocker (Crash):

Problems that hinder development or testing work; cause system crashes, crashes, and endless loops, resulting in loss of database data, errors in connection with the database, loss of main functions, and missing basic modules. Such as: code error, infinite loop, database deadlock, important first-level menu functions cannot be used, etc. (this problem rarely occurs in the test, once it occurs, the current version test should be terminated immediately).

Critical :

Some of the main functions of the system are lost, the database is saved and called incorrectly, user data is lost, and the first-level function menu cannot be used, but it does not affect the test of other functions. The functional design does not meet the requirements seriously, the module cannot be started or called, the program restarts, automatically exits, call conflicts between related programs, security issues, stability, etc. Such as: errors displayed in the database after the data in the software are saved, missing functions required by users, program interface errors, numerical calculation statistics errors, etc.

Major (General):

The function is not fully realized but it does not affect the use, and the function menu has defects but it will not affect the system stability. Such as: long operation time, long query time, wrong format, wrong boundary conditions, no confirmation box for deletion, too many fields in the database table, etc. ( this problem exists most in the actual test)

Minor (secondary):

Interface and performance defects, suggestions, problems that do not affect the execution of operation functions, solutions that can optimize performance, etc. Such as: typos, irregular interface format, overlapped page display, hiding what should not be displayed, unclear description, missing prompts, irregular text arrangement, incorrect cursor position, poor user experience, solutions that can optimize performance, etc. (There are many such problems in the early stage of the test, and the priority is low; there are few problems in the later stage of the test, and they should be dealt with in time)

bug life cycle

New: Newly discovered bugs that have not been reviewed to decide whether to assign them to developers for modification.

● Open : It is confirmed that it is a bug , and it is considered that it needs to be modified and assigned to the corresponding developer.

● Fixed: After the developer makes the modification, it is marked as a modified state, and it needs to be verified by the regression test of the tester.

● Rejected : If it is considered not a bug , the modification will be rejected.

● Delay: If it is considered that there is no need to modify or cannot be modified temporarily, the modification will be postponed.

● Closed : If the modified bug is verified by the tester's regression test, the bug will be closed .

● Reopen : If it is verified that the bug still exists, the bug needs to be reopened , and the developer can modify it again.

Invalid bugs : open->closed open-rejected-closed

What to do if there is a dispute in the team - don't quarrel

1. Exclude your own reasons

Check whether there is any misoperation or misunderstanding of the software requirements

2. Troubleshoot the way you work

Check whether your description of the bug is clear, if it is not clear enough, improve the bug description, if the description is not clear in words, find the relevant developer to explain the bug description after submitting the bug

3. Provide ideas/methods for developers to solve problems

To improve one's own business and technical level, one must not only be able to ask questions, but also be able to come up with ideas for solving them. This will make it more convincing.

4. Consider the problem from the perspective of the user

Considering the problem from the user's point of view should allow developers to understand the possible troubles that bugs may cause to users, so as to encourage developers to modify bugs more actively and with high quality . When in dispute, you can ask: If you are a user, can you accept it?

5. Third Party Meetings

Bring all relevant personnel involved in the project into the meeting, including test leaders and development leaders. At this time, you have to describe the bug in detail, and propose your own ideas to solve the bug, and finally get a result: whether this bug needs to be fixed

How to do the first test

As a rookie, when we enter the test team and start the first test, we need to make a lot of preparations:

1. Read all project-related documents, including: requirements documents, design documents, user manuals

2. Participate in various project meetings as much as possible, understand the background of the project, personnel composition, and understand the needs and business as much as possible. Especially for projects with strong professionalism, such as banking business, it is necessary to understand various business knowledge, such as high and low cabinets, first, second and third types of accounts, deposits, loans, etc.

3. Familiar with the test management tools and configuration management tools used in the project, and obtain the corresponding address and login method

4. Read existing test plans and test cases

5. Read the old bug library to understand the system functions. It is especially important to maintain the same fault classification principles as the existing test team

6. Understand the company's standard requirements, especially the use case writing standard, use case execution standard, bug submission standard, test tool use standard  etc. After the above preparations, the first test work has come, we need to communicate with The test team leader confirms the specific work content:

1. What is the test plan?

2. What is the content of the test? How many test cases are there? How many days are scheduled for execution? Is there free testing time?

3. Who is the content developer I want to test? Who is the person in need?

4. Does the test content assigned to me require special test resources? Are resources meeting needs?

After we confirm the above content, we can start the execution of the test