Say a word for a test plan

Greetings to the members of the respected community.

I work as a tester (online store). Vector - test case management, QA - management, JUnit - testing, automation, programming in Java. I would like to share my experience with my colleagues. Maybe someone will come in handy.

The subject of the article is a test plan and tools for its compilation.
')
So, there is a task - to test the work of the mobile version of the site on the front. I have my own desire - to leave to descendants and colleagues a sane manual for testing, when it will not be necessary to invent what to test. I am for interchangeability, versatility and visibility! Postulate - the structure of the site should be presented in the form of a tree to facilitate the perception and obtaining perspectives.

Step-by-step process of building a tree for a test plan:

1. First level: indication of the “Pages” section and global elements (end-to-end elements - header elements, basement).
2. Second level: listing pages.
3. The third level: an enumeration of the general properties of the page and its special states (for example, a full or empty basket).
4. The fourth level:
- indication of the “Elements” section,
- specifying the "Events" section for the page,
- enumeration of large blocks of elements (for example, a block of product subcategories with a large number of elements),
5. Fifth level: enumeration of element types (text blocks, links, fields, buttons, checkboxes, counters, forms, photos, banners, icons, icons, captcha ...).
6. The sixth level: the enumeration of the names of the elements relating to the corresponding type of element (for example, the names of the fields for the type of the element "Field").
7. The seventh level: an indication of the subject of testing for a specific element and the section "Actions" / "Events" to describe functional testing:
7.1. Text block (specific):
- the correct location on the page,
- correct text format,
- correct layout display,
- the item cannot be changed,
...
7.2. References:
- right location
- the ability to click
- availability of the desired text,
- pressing does not cause an error,
- link leads to the desired page,
- the item cannot be changed,
...
7.3. Fields:
7.3.1. The right location
7.3.2. Correct format
7.3.3. Item cannot be changed,
7.3.4. Actions (the set depends on the data types contained in this field - for example, numbers, - and the functional of the element - for example, the input field):
7.3.4.1. Accepts the correct value.
7.3.4.2. Takes a false value.
7.3.4.3. Does not accept text.
7.3.4.4. Does not accept special characters.
7.3.4.5. Does not take injections.
7.3.4.6. Does not accept / interpret the number in another system of calculation.
7.3.4.7. Does not accept formulas and division operations by 0.
7.3.4.8. Does not accept / interprets a fractional integer
...
7.4. Buttons:
7.4.1. The right location
7.4.2. The ability to click
7.4.3. Having the right text,
7.4.4. Item cannot be changed,
7.4.5. Actions:
7.4.5.1. Invokes the required form / starts a specific process.
7.4.5.2. Clicking does not cause an obvious error on the current page or in the process results.
7.4.5.3. Clicking does not move to another page.
7.4.5.4. Pressing does not hang
...
7.5. Checkboxes / flags:
7.5.1. The right location
7.5.2. The ability to highlight / deselect,
7.5.3. Item cannot be changed,
7.5.4. Actions:
7.5.4.1. Selection does not cause an error on the current page.
7.5.4.2. Allocation does not trigger the extraneous process.
7.5.4.3. Selection does not cause a hang,
...
7.6. Counters:
- right location
- display of an integer (the number of product units),
- correct display format,
- the item cannot be changed,
- compliance of the numerical value of the counter with the initial value,
...
7.7. Forms:
7.7.1. The right location
7.7.2. Correct display format,
7.7.3. Item cannot be changed,
7.7.4. Items:
7.7.4.1. Fields
7.7.4.2. Buttons
7.7.4.3. Links
...
7.7.5. Developments:
7.7.5.1. Clearing form fields after sending data.
7.7.5.2. Clear form fields after refreshing the page.
...
7.8. Photo (with a mechanism for viewing an enlarged photo):
7.8.1. The right location
7.8.2. Correct mapping,
7.8.3. The ability to click
7.8.4. Item cannot be changed,
7.8.5. Developments:
7.8.5.1. Pressing results in an enlarged photo,
7.8.5.2. Clicking does not lead to any error
...

This is a description of the test plan, which mainly covers the verification of the properties of the specified elements.
Here, in the sections "Events" and "Actions" I add test cases for functional testing:
- the fact of adding the selected item to the cart after clicking on the “Add to cart” button,
- correct calculation of the cost of delivery when choosing different regions, etc.

What will give me a convenient presentation of the test plan?
- prospect (forthcoming scope of work);
- understanding of the structure of the test object (and not necessarily the site - even the rocket);
- Understanding of the extent of coverage with test cases of the test object;
- the idea of ​​testing what I can automate;
- in the end, +1 to ChSV (joke).

As you know, even a good pilot needs a plane with wings.

My airplane with wings is XMind 6.

I create a file where the central element indicates, for example, a box with the text “Plan Testing (mobile version)”. After some time, the outline of the plan in accordance with the principle of construction described above, the plan becomes similar to the root system:



Yes, I already have some idea of ​​the amount of testing. It will be a lot ...
The first thing I started with is the indication of the “Pages” section and global elements (cross-cutting elements are header elements, basement):



Next is the listing of pages:



Further (see the Third level - above) - an enumeration of the general properties of the page and its special states (for example, a full or empty basket):



Next (see the Fourth level) - an enumeration of the general properties of the page, the events for it:



Next - an enumeration of element types (text blocks, links, fields ...):



Next - an enumeration of the names of the elements relating to the corresponding type of element:



And the last main level - the seventh: an indication of the subject of testing for a specific element and the section "Actions" / "Events" to describe the functional testing:



Such an element as a form requires additional levels of investment, since contains simple elements - fields, buttons, etc.

And so for each page. Yes, it takes time to compile. But what else? But now I have on hand a map that I can project onto the mobile version in case it is updated - I will correct it a little. And what will give me a convenient presentation of the test plan - please read above.

Green flag - the test passed, red - a bug. If at least one test is littered, a red flag is put down for all parents - so that you can understand from the very beginning of the plan: there are problems.

All changes to the program file can be taken into account with Git.

You can put a colleague or a new one in the place of a tester and give him such a plan to get acquainted with the structure of the site and the testing process. My method does not in any way replace the test case management system, but merely adds it.

All these publications relating to the description of the structure of the plan are common to most online shopping sites, and therefore do not carry any trade secrets.

Thank you all for your attention!