And so the time has come for the decisive stage in the battle against evil. We are getting ready to blow up the Death Star! To strike the enemy, we need to draw up a solid plan and lay out our tactics and sequence of actions in clear order.

As you guessed, we will be preparing a test plan. The pinnacle of the tester's art, the culmination of the theory part, fanfare, drumroll! The most complicated technical documentation in testing will submit to you today!

Stages of testing

Before you start planning the testing process, you need to break the whole process down into stages:

The stages of the software testing process are groups of work that define the main direction of activities for achieving the result set for, and defined by, the stage as a whole
Singling out the main activities and grouping them into stages of work makes it possible to plan all the activities and to estimate the effort for a particular stage of software testing

What stages the testing process consists of:

Every tester needs to know this!

Testing consists of the following stages:

Test planning
Test design
Implementing/recording test procedures
Test execution
Test debugging
Analysis of the results
Documenting the results

It all looks simple and clear enough here. We have already discussed and gone through all of these stages. You know how to do each of them separately, and all that's left is to draw up a plan for carrying out these activities.

Test planning

In this drop-down list you can find out what the first stage of testing (planning) includes. That, in fact, is why this level was launched

"Why do we even need a test plan? - you ask. - I've got test cases, a technical specification, and, after all, I already know what to do, I can explain everything on my fingers!"

And that's true. My personal opinion (which matches the opinions of many employers) is that the time spent on documentation should be nowhere near the time spent on the testing itself, that is, it should not exceed roughly 10% of the total time spent.

For example, if all you have to test is a data submission form like the one in level 4, you don't need a test plan for it - you'd spend more time on the plan than on the testing itself.

A test plan is necessary when the feature is big and it's simply impossible to hold the whole scope of work for it in your head. You can't afford to miss any aspect of testing. And for that you need to put everything into a document, sort out the order of actions, and think everything through up front. Having a test plan is especially important when several people take part in testing. Then you're already saving time on meetings and on explaining the plan of action to other people over and over.

Important facts about the test plan:

A test plan contains: the scope of work, deadlines, ways of solving the tasks involved in the work, resources, and a timeline for the work
It is the main artifact that aligns the plans of the development and testing teams
A necessary artifact for planning the development project and the delivery of the software

Main sections of the test plan

Title, Project
Change log
Introduction Project identification Scope Source data Purpose
Test requirements Test strategy (see below) Resources Schedule
Deliverables

While you're still studying, C3PO has reached level 23, become a tester, and is now living the dream

Test strategy

The strategy is written at the very beginning. It lays out the order in which work is done, even including what goes into your test plan. For example, the order in which documentation is developed and the tests are actually run.

Working with incoming technical documentation (such as the technical specification)
Generating the test documentation
Choosing the types of testing, creating the test script: Installation testing Configuration testing Security and access control testing Load testing Data and database integrity testing User interface testing Business cycle testing Functional testing Testing tools

Resources

The test plan describes the resources needed to carry out testing within the deadlines you set. The request for resources for your particular project is built from the priority of the task, the deadline, and the real resources of your company.

Resources in testing are of two kinds: human - the roles you will need to work on the project, and technical - all the equipment needed for testing.

Roles Software Engineer Designer Database Administrator Administrator of the System Under Test Tester Test Designer Test Manager
Technical Resources Test DB Test server Test environments Test repository

Test schedule

Defining the scope of testing
Defining the order in which testing is carried out
Defining how the test results are measured
Timeline

Although time is one of our most valuable resources, we usually don't value it enough. To distribute time and effort sensibly, the test plan contains a work timeline.

A distinctive feature of planning in Agile is that estimation is done incrementally, in every iteration. Nobody expects the preliminary estimates to be as accurate as the later ones. Things improve over time, as the team grows more confident in its skills and capabilities.

In addition to the main estimation approach based on historical knowledge, Agile team members often use relative estimation models, in which teams develop narratives (stories) that define user needs. These stories are analyzed by the teams, and each story is assigned a numeric value (Story Points ). Story Points (SP) can be expressed in abstract units of measurement, for example as numeric values, or in the form of Ideal Developer Days (IDDs).

In testing, as in all business processes, the time spent on a project equals the scope of the project (the number of story points) divided by the number of testers working on the project.

First you determine the scope of testing, then you take the order of the testing stages from the strategy, set aside time for the wrap-up work, that is, reporting - and all of this goes into the timeline

Deliverables

Test model
Test logs
Reports on the defects found in the system

I think everything is clear here already. The test plan is delivered at the start of the work, and the bug reports during the testing itself. By logs we mean test cases and checklists with pass/fail marks.

We are closing in on the target

Test plan templates

Me give you templates. You read. Is interesting.

According to Rational Unified Process

According to IEEE (ANSI/IEEE Standard 829-1983)

According to my own version WIX.com (English)

Test design

Design consists of four main stages. Once you get through them, the main part of the test plan will be ready.

Define and describe the test scenarios

At the first stage you think through and outline which test cases you need to write. Then, following this structure, you will write checklists or test cases, depending on how detailed the documents must be.

2. Prepare an analysis of the expected workload (for load testing)

In this case, you agree with management on the expected load of the project:

the number of users, the number of steps in a user story for an average user. Session time, peak load, and so on...

3. Define and structure the test procedures

Here you need to decide which tests will be designed as manual from the start and which as automated. Split them into sections. Define the testing approach. Divide the functionality among your colleagues.

4. Review and evaluate the test coverage

Once your test scripts are ready, you can evaluate how well the project's functionality is covered by tests. Work out whether you've reached the required minimum or whether something still needs to be covered. Time to survey the project and smile with satisfaction at a job well done.

My mission is to help. I will give you comments on each item of the test plan

Test implementation

Record or program the test scripts
Define special test functionality in the design model and the implementation model

Sometimes companies have test functionality that simplifies routine operations. For example, a script that adds n pages to a website so you don't have to do it by hand.

Set up external data sets for testing

Assemble the data set needed for testing, if required. For example, card data for making test payments.

Test execution

Execute the test procedures
Evaluate the test run (completed, not completed)
Fix the "failed" tests
Fix the test procedures, if needed
Verify the results
Analyze unexpected results
Log the defects

Test evaluation

Evaluate how well the test scenarios cover the functionality

Make sure that every important piece of functionality is checked by some test. Don't forget about negative test scenarios.

Evaluate how well the test scenarios cover the code

You assess the % of the code that is covered by tests.

Analyze the defects

Understand where the defects are concentrated and what causes them. If there are a lot of bugs in one particular place, it deserves special attention: increase the level of detail in its coverage and take it into account in regression testing. You may also want to raise the issue of poor code quality from certain programmers.

Determine whether the completion and success criteria for testing have been met

First of all, analyze whether the testing metrics have been met (test coverage, verification of all functionality, etc.). Also ask yourself whether you feel you've checked everything thoroughly and whether critical bugs are still turning up.

Practical tips:

A test script should work in every test run or be removed from the test suite entirely
Test scripts should be reproducible from the moment they are developed
Cover the critical-priority errors you find with automated scripts
Write down the key principles of working with automated testing in the product's Quality Plan
Give the automated coverage metric the priority of a "release blocker"

Don't try to make your test plan exactly like the one proposed. Every project is unique
Try applying the concept of "living documents" Use common sense… and common sense! and ask the right questions :)

Useful articles to read:

Testing metrics

Sense I do that the material you have mastered. Ponder these questions, my student. In understanding this level, the answer you will find.

1. What stages does the testing process consist of?

2. What materials must be delivered?

This level is a very important one on a tester's path. Chewbacca says this level and the next were the hardest of his life!

Well, of course, since you'll have to explore the Death Star at the end of the next level. Take the decisive step in this course: pass the test and do the assignment. Then you'll surely be halfway to becoming a tester.

Test

R2D2, stop pestering the young tester with your tests!

Let him try himself out in practice.

Practice