"Agile Software Test" reading notes (v)

the fifth part of the test staff experienced an iteration

15. Testers ' work during the release or thematic planning phase

Make a plan: a short plan is better. (priority changes, environmental instability, long-term plans are difficult to achieve.) ）

Project card: Needs to be done, in development, to be verified, completed.

Assessment story: Workload (small and medium size). Collective assessment, re-adjustment.

Story Test evaluation

Enjoy agility and make the meeting fun. (The station will speak at a timed interrupt.) ）

Development: First to achieve the most basic functions. Story apart. Offline tasks can not be done. Complete the story that affects other features of the system as early as possible.

Test data: Remove sensitive information, such as bank cards, ID cards, etc.

Test plan:

1. Lightweight: test equipment requirements, testers, investment time. Assumptions, risks, performance, UAT.

2. Use the test matrix:

Condition 1 Condition 2

Function 1

Function 2

Can be used as test coverage. Color-sensitive state.

3. Test form, Whiteboard

4. Automated Test list.

Communicate test results:

1. Passed the test number: as a function of 25 tests, a total of 100 use cases passed.

2. Test coverage: Packages, classes, methods, lines of code that can be run. Test the number of overlays/totals. 95%

Defect metrics:

16. Pre-Iteration Preparation

If the activity before the iteration is not time-saving in the iteration, give up decisively.

1. Iterative Requirements Seminar: Before sprint begins. (Clear beforehand, customer opinion is unanimous.) Learn what the story means for people of different roles. A reality-based use case discussion story. ）

2. At the beginning of the iteration, write the user acceptance test-high level. (For complex stories, write at least one common path, one that is very useful for paths.) ）

3. Test strategy: Consider when to start testing them.

17. Iteration Begins

1. Iteration Plan: Decompose story and evaluate workload. (Refer to Uat test cases, passing conditions.) --------understand story through prototype examples.

can be removed without doing the function. Stand in different ways: User, programmer, product, document writer. Consider the impact of the associated system function, exposing the uncertainties early.

When others disagree: it is recommended to add a subset of functions first, try an iteration.

Test strategy selection: Most of the sub-functions use "Just enough" data, and the complete data is used to verify the full functionality.

Determine the amount of work: Calculate the total time estimate, or the number of cards. Alternative story. When learning a new job: New risk time.

2. Can test story:

1. The entire team participates in testability issues

2. Such as system time: By increasing the runtime server properties. (Job: Modify the run time.) ）

3. High-level testing and examples

1. A picture wins thousands of words. When modifying features: Print existing features, pen callouts.

2. Requirements =story+ Communication + user scene + guide map

4. Test Case Review

Do you think there's something missing? Which block is most likely to be at risk? Focus on where?

Test cases are saved as documents: Use cases are easy to maintain. Test Code Export API, class structure diagram.

18. Coding and Testing

1. Drive development:

Start with simple: Write basic stream----> anomaly Scene construction first. Add Complexity: Exploratory testing.

Assess Risk: Entry impact * probability of occurrence = risk. Complex features that list potential risks.

Coding and testing are done at the same time, allowing all team members to participate, abandoning extreme situations that might not have happened.

Disagreements, look for third-party forces and make sure not to discuss the issue repeatedly.

Complete only one story at a time.

Self-Presentation: Speak your mind aloud: Put a little duck to remind yourself: think more before you ask questions.

Show to Customers:

2. Complete the test task

You can use mock or hard-coded data tests before accessing the data for the real service.

When an iteration cannot be completed: Discard a story. Notify the developer immediately. assist in testing.

Defect 0 tolerated.

3. What issues need to be recorded in the defect

A. Development confirmation is a problem B. Development cannot be repaired immediately. Try reserving 2 or half days for each story to fix the bug. (Immediate patching, later patching, no patching.) ）

Team principle: Defects must be fixed within the iteration, allowing the entire team to see defects.

The number of defects cannot exceed 10.

Multiple defects consider combination defects.

4. Ensure fast Build

A. There is no need to include all boundary conditions and similar situations in the regression test.

5. Iteration Metrics

Progress metrics, defect metrics.

Record Test time:

A single-table crud.

Complex business logic.

Defect recurrence time, defect verification time. Record the defect type.

Static analysis tool: FindBugs, find the highest problem of sprint priority growth.

Measure:

Story test Execution quantity.

Automation status.

Test pass/Fail line chart.

The summary and status of each story.

Defect metrics.

Finishing work at the end of an iteration

1. Iteration review: Within 30 minutes. Demonstrates new features.

What to do well, not good, to try for the next iteration.

Start, stop, continue list. Set up a checkpoint to verify that there is an improvement.

Run the single-Test code coverage tool. The 4th day before the iteration begins, complete the high-level test case for all stories. Development delivers a story to test before the 4th day of the iteration. Maintain a to-dos list.

Take time to celebrate and let the team pause and refresh the view.

2. Successful delivery

Training, documentation.

Periodically make a refactoring iteration to reduce technical debt and improve test coverage. There are always some tests that are not worth automating.

Automated regression testing, running at least daily.

Reliability testing, fault tolerance, resiliency testing, security.

Reduce risk by using external third-party testing as early as possible.

Use DB scripts to handle data transformations, backwards compatibility issues. After the database has been modified, run diff on the database.

Sets the task reminder feature.

3. Consider who the document is to, what they do with it, and if there is no answer, consider whether to discard the document.

4. Release criteria: Performance indicators, test coverage, no major defects, and allow customers to identify new features, such as live demonstrations.

"Agile Software Test" reading notes (v)