At the initial stage of the implementation of test activities, test engineers need to analyze test objects from several dimensions such as target definition, project background, test tasks, test resources, test risks, etc., in order to have a deeper understanding of product requirements, extract test requirements, design test cases and execute them Test cases and find product defects.
3.1.1 Test target definition
The definition of test objectives is to determine the goals expected to be achieved in this or this round of testing activities. Unlike test tasks, test tasks are specific tasks, test goals are results, and test tasks are the process of achieving the definition of test goals.
Taking the ECShop project as an example, the test goal is to verify whether the business in each Sprint has met the functional, security, UI, compatibility, performance and other requirements defined in the product requirements through the implementation of functional, safety, compatibility, interface and performance tests. .
The definition of test objectives needs to be combined with the explicit and implicit needs of users. Explicit needs are usually clearly defined in product requirements or user stories, while implicit requirements are determined by test engineers based on their own technology and project experience, combined with software background, user background, and operating background. Factors such as comprehensive consideration analysis and extraction.
After the test target is defined, the test task can be identified according to the test target. After the test scope is determined, the test target should be evaluated quantitatively or qualitatively as much as possible, such as function realization coverage, performance index, defect repair rate, compatibility coverage, etc.
3.1.2 Project background analysis
All product or project development has an initial design background. Through the project background analysis, the test engineer can understand what industry the test object belongs to, whether there are related systems or platforms, and whether there are special business requirements, etc.
For example, in order to design a mobile phone for the elderly, the font should be enlarged as much as possible, the sound should be enlarged, the battery capacity should be increased, and the number of charging should be reduced.
Different industries may have some requirements that are in line with their own industry characteristics. For example, the financial industry pays more attention to data security and performance in addition to functions. The external business system of government enterprises pays more attention to security than functions, while App focuses on User interaction.
Knowing the industry of the product or project will help test engineers to adopt industry-specific test methods or experience, thereby improving test efficiency and quality.
For a brand-new product or project, there may not be a system or platform coupled with it. However, if it is an upgraded software or derivative system, it is necessary to analyze whether there is an interactive interface in the coupled business system. If it exists, it is necessary to design a test strategy Consider the interface test method.
When a test engineer performs a background analysis of a test object, he usually obtains it from relevant materials such as product meetings, requirements outlines, and product to-do lists.
3.1.3 Test task identification
After the test target is defined, the target needs to be decomposed to identify the specific test task. Agile testing is different from the traditional software testing double-V model. The tasks of test engineers in agile testing are usually determined by the agile development team according to the content of each Sprint. How many user stories or requirements lists to be developed and tested in a Sprint is determined by the team Evaluation decision, once the Sprint content is determined, the test task is determined accordingly.
In the Scrum development model, product requirements evolve into user stories with clear requirements. When describing user stories, they cannot be considered from the developer's perspective, and technical terms are not allowed to express requirements. This prevents the requirements from being separated from actual user scenarios.
However, as a test engineer, not only consider the user’s point of view during test implementation, but also consider the overall design of the product. In addition to functionality and ease of use, it may also consider features such as product portability and efficiency. Therefore, test engineers must go deep Understand the application scenarios and user needs of the tested object.
Agile testing tasks mainly include workload estimation, test preparation, and test execution.
01. Workload estimation
According to experience, in a Sprint, the test time usually accounts for about 30%-40% of the development time. Therefore, when estimating the test time, the test engineer should first understand the development time, and then plan the test time according to the development time and task nodes. The workload of the work is then recorded in the form of a list.
After the test engineer participates in the daily stand-up meeting, according to the development progress of Sprint, the workload estimate is updated in time, and the problem is adjusted in time.
02. Test preparation
Before the test activity is executed, the test engineer needs to design test cases (if necessary), construct test data, develop interface scripts, automated scripts, and performance test scripts according to the test objectives.
Test case design can generally be determined according to the granularity of the user story and the requirements of the agile development team. If the user story is relatively detailed and can clearly verify the function, there is no need to write test cases, and the user story is directly used as the test basis.
If the user story only lists the user's expectations and there are more verifying functions, it is necessary to use equivalence classes, boundary values, orthogonal experiments, state transitions and other methods for use case design to facilitate subsequent test execution activities.
A large amount of data may be required during the testing process, especially when testing process business, the test engineer needs to determine the method and script for constructing the data. For example, when the test environment is set up, you can use SQL statements to restore test data, use some software that generates ID numbers in batches, and simulate ID card information.
In many cases, agile testing requires automation of the test execution process, such as interface testing. At this time, automated test scripts need to be written, and test engineers are required to have the ability to program and use tools.
Performance testing is the same as automated testing, and both require the development and optimization of test scripts.
03. Test execution
In the test execution phase, test engineers need to build a test environment, execute test cases, analyze and output test results, and track and deal with defects.
If the test environment is very complicated, it may be built by the development engineer, but the author recommends that the test engineer build it by himself, so as to facilitate the understanding of the deeper architecture.
The construction of the test environment requires more knowledge. In the test task identification link, the test engineer should clarify the operating environment of the product to the development engineer, and then prepare relevant resources. If you do not have the knowledge of environment construction, you need to learn in advance.
In addition to the product test environment, a test management environment may be required, such as test case management, defect management, etc. Generally, a more comprehensive management tool, such as ALM or Zen Tao, is selected.
The problems found during test execution can be recorded in time, which is convenient for later defect tracking.