For the test plan, put in the word
Greetings to members of a respected community.
I work as a tester (online store). Vector - test case management, QA - management, JUnit - testing, automation, Java programming. I would like to share my experience with my colleagues. Maybe someone will come in handy.
The subject of the article is a testing plan and tools for its preparation.
So, there is a task - to test the mobile version of the site at the front. I have my own desire - to leave to the descendants and colleagues a sane manual for testing, when it will not be necessary to come up with something to test. I am for interchangeability, versatility and clarity! Postulate - the site structure should be presented in the form of a tree to facilitate perception and gain perspective.
The step-by-step process of building a tree for the test plan:
1. First level: indicating the "Pages" section and global elements (through elements - header elements, footer).
2. Second level: listing of pages.
3. Third level: listing the general properties of the page and its special states (for example, a full or empty basket).
4. The fourth level:
- indicating the section "Elements",
- indicating the section "Events" for the page,
- listing large blocks of elements (for example, a block of product subcategories with a large number of elements),
5. Fifth level: listing types of elements (text blocks, links, fields, buttons, checkboxes, counters, forms, photos, banners, icons, badges, captcha ...).
6. Sixth level: listing the names of elements related to the corresponding type of element (for example, field names for the element type "Field").
7. 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,
- the correct text format,
- the correct layout,
- the element cannot be changed,
...
7.2. Links:
- the correct location,
- the ability to click,
- the presence of the desired text,
- clicking does not cause an error,
- the link leads to the desired page,
- the element cannot be changed,
...
7.3. Fields:
7.3.1. Correct location,
7.3.2. The correct format is
7.3.3. Element cannot be changed,
7.3.4. Actions (the set depends on the types of data contained in this field - for example, numbers, - and the functionality of the element - for example, an input field):
7.3.4.1. It takes the correct value.
7.3.4.2. It 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 a number in another calculus.
7.3.4.7. Does not accept formulas and operations of division by 0.
7.3.4.8. Does not accept / interpret into a fractional integer,
...
7.4. Buttons:
7.4.1. Correct location,
7.4.2. Ability to click,
7.4.3. The presence of the desired text,
7.4.4. The item cannot be changed,
7.4.5. Actions:
7.4.5.1. Invokes the required form / starts a specific process.
7.4.5.2. Pressing does not cause an obvious error of the current page or in the results of the process.
7.4.5.3. Pressing does not move to another page.
7.4.5.4. Pressing does not freeze
...
7.5. Checkboxes / flags:
7.5.1. Correct location,
7.5.2. Ability to select / deselect,
7.5.3. Element cannot be changed,
7.5.4. Actions:
7.5.4.1. Highlighting does not cause an error on the current page.
7.5.4.2. Isolation does not start an extraneous process.
7.5.4.3. Allocation does not lead to freezing,
...
7.6. Counters:
- the correct location,
- the display of an integer (the number of units of goods),
- the correct display format,
- the element cannot be changed,
- the correspondence of the numerical value of the counter to the original value,
...
7.7. Forms:
7.7.1. Correct location,
7.7.2. Correct display format,
7.7.3. Element cannot be changed,
7.7.4. Elements:
7.7.4.1. Fields
7.7.4.2. Buttons
7.7.4.3. References
...
7.7.5. Events:
7.7.5.1. Clearing form fields after submitting data.
7.7.5.2. Clear form fields after page refresh.
...
7.8. Photo (with a mechanism for viewing an enlarged photo):
7.8.1. The correct location,
7.8.2. Correct display,
7.8.3. Ability to click,
7.8.4. Element cannot be changed,
7.8.5. Events:
7.8.5.1. Pressing leads to the appearance of 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 checking the properties of the specified elements.
Here, in the “Events” and “Actions” sections, I add test cases for functional testing:
- the fact that the selected product was added to the basket after clicking on the “Add to Cart” button,
- correct calculation of shipping costs when choosing different regions, etc.
What will give me a convenient view of the test plan?
- perspective (forthcoming scope of work);
- understanding of the structure of the tested object (and not necessarily the site - even rockets);
- understanding of the degree of coverage with test cases of the test object;
- an idea of what testing I can automate;
- in the end, +1 to FGP (joke).
As you know, even a good pilot needs an airplane with wings.
My airplane with wings is XMind 6.
I create a file where I indicate, for example, a small square with the text “Test Plan (mobile version)” as the central element. After some time, the outline of the plan in accordance with the construction principle described above, the plan becomes similar to the root system:
Yes, I already have some idea about the amount of testing. There will be a lot of it ...
The first thing I started with is the indication of the “Pages” section and global elements (through elements - header elements, footer):
Next - listing of pages:
Next (see Third level - above) - listing the general properties of the page and its special states (for example, a full or empty basket):
Next (see. The fourth level) - listing the general properties of the page, events for it:
Next is a listing of the types of elements (text blocks, links, fields ...):
Next is a listing of the names of the elements related to the corresponding type of element:
And the last main level is the seventh: an indication of the subject of testing for a particular element and the section “Actions” / “Events "To describe functional testing:
Such an element as a form requires additional levels of investment, because contains simple elements - fields, buttons, etc.
And so for every page. Yes, it takes time to compile. But what else? But now I have on my hands a map that I can project onto the mobile version if it is updated - I will slightly correct it. And what will give me a convenient presentation of the test plan - please read above.
Green flag - test passed, red - bug. If at least one test is overwhelmed, a red flag is affixed to all parents - so that you can understand from the very opening of the plan that there are problems.
All changes to the program file can be taken into account using Git.
You can put a colleague or a new one into the place of a tester and give him such a plan to familiarize yourself with the structure of the site and the testing process. My method in no way replaces the test case management system, but just adds it.
All of these publications regarding the description of the structure of the plan are common to most sites of online stores, therefore, do not carry any trade secrets.
Thank you all for your attention!
I work as a tester (online store). Vector - test case management, QA - management, JUnit - testing, automation, Java programming. I would like to share my experience with my colleagues. Maybe someone will come in handy.
The subject of the article is a testing plan and tools for its preparation.
So, there is a task - to test the mobile version of the site at the front. I have my own desire - to leave to the descendants and colleagues a sane manual for testing, when it will not be necessary to come up with something to test. I am for interchangeability, versatility and clarity! Postulate - the site structure should be presented in the form of a tree to facilitate perception and gain perspective.
The step-by-step process of building a tree for the test plan:
1. First level: indicating the "Pages" section and global elements (through elements - header elements, footer).
2. Second level: listing of pages.
3. Third level: listing the general properties of the page and its special states (for example, a full or empty basket).
4. The fourth level:
- indicating the section "Elements",
- indicating the section "Events" for the page,
- listing large blocks of elements (for example, a block of product subcategories with a large number of elements),
5. Fifth level: listing types of elements (text blocks, links, fields, buttons, checkboxes, counters, forms, photos, banners, icons, badges, captcha ...).
6. Sixth level: listing the names of elements related to the corresponding type of element (for example, field names for the element type "Field").
7. 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,
- the correct text format,
- the correct layout,
- the element cannot be changed,
...
7.2. Links:
- the correct location,
- the ability to click,
- the presence of the desired text,
- clicking does not cause an error,
- the link leads to the desired page,
- the element cannot be changed,
...
7.3. Fields:
7.3.1. Correct location,
7.3.2. The correct format is
7.3.3. Element cannot be changed,
7.3.4. Actions (the set depends on the types of data contained in this field - for example, numbers, - and the functionality of the element - for example, an input field):
7.3.4.1. It takes the correct value.
7.3.4.2. It 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 a number in another calculus.
7.3.4.7. Does not accept formulas and operations of division by 0.
7.3.4.8. Does not accept / interpret into a fractional integer,
...
7.4. Buttons:
7.4.1. Correct location,
7.4.2. Ability to click,
7.4.3. The presence of the desired text,
7.4.4. The item cannot be changed,
7.4.5. Actions:
7.4.5.1. Invokes the required form / starts a specific process.
7.4.5.2. Pressing does not cause an obvious error of the current page or in the results of the process.
7.4.5.3. Pressing does not move to another page.
7.4.5.4. Pressing does not freeze
...
7.5. Checkboxes / flags:
7.5.1. Correct location,
7.5.2. Ability to select / deselect,
7.5.3. Element cannot be changed,
7.5.4. Actions:
7.5.4.1. Highlighting does not cause an error on the current page.
7.5.4.2. Isolation does not start an extraneous process.
7.5.4.3. Allocation does not lead to freezing,
...
7.6. Counters:
- the correct location,
- the display of an integer (the number of units of goods),
- the correct display format,
- the element cannot be changed,
- the correspondence of the numerical value of the counter to the original value,
...
7.7. Forms:
7.7.1. Correct location,
7.7.2. Correct display format,
7.7.3. Element cannot be changed,
7.7.4. Elements:
7.7.4.1. Fields
7.7.4.2. Buttons
7.7.4.3. References
...
7.7.5. Events:
7.7.5.1. Clearing form fields after submitting data.
7.7.5.2. Clear form fields after page refresh.
...
7.8. Photo (with a mechanism for viewing an enlarged photo):
7.8.1. The correct location,
7.8.2. Correct display,
7.8.3. Ability to click,
7.8.4. Element cannot be changed,
7.8.5. Events:
7.8.5.1. Pressing leads to the appearance of 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 checking the properties of the specified elements.
Here, in the “Events” and “Actions” sections, I add test cases for functional testing:
- the fact that the selected product was added to the basket after clicking on the “Add to Cart” button,
- correct calculation of shipping costs when choosing different regions, etc.
What will give me a convenient view of the test plan?
- perspective (forthcoming scope of work);
- understanding of the structure of the tested object (and not necessarily the site - even rockets);
- understanding of the degree of coverage with test cases of the test object;
- an idea of what testing I can automate;
- in the end, +1 to FGP (joke).
As you know, even a good pilot needs an airplane with wings.
My airplane with wings is XMind 6.
I create a file where I indicate, for example, a small square with the text “Test Plan (mobile version)” as the central element. After some time, the outline of the plan in accordance with the construction principle described above, the plan becomes similar to the root system:
Yes, I already have some idea about the amount of testing. There will be a lot of it ...
The first thing I started with is the indication of the “Pages” section and global elements (through elements - header elements, footer):
Next - listing of pages:
Next (see Third level - above) - listing the general properties of the page and its special states (for example, a full or empty basket):
Next (see. The fourth level) - listing the general properties of the page, events for it:
Next is a listing of the types of elements (text blocks, links, fields ...):
Next is a listing of the names of the elements related to the corresponding type of element:
And the last main level is the seventh: an indication of the subject of testing for a particular element and the section “Actions” / “Events "To describe functional testing:
Such an element as a form requires additional levels of investment, because contains simple elements - fields, buttons, etc.
And so for every page. Yes, it takes time to compile. But what else? But now I have on my hands a map that I can project onto the mobile version if it is updated - I will slightly correct it. And what will give me a convenient presentation of the test plan - please read above.
Green flag - test passed, red - bug. If at least one test is overwhelmed, a red flag is affixed to all parents - so that you can understand from the very opening of the plan that there are problems.
All changes to the program file can be taken into account using Git.
You can put a colleague or a new one into the place of a tester and give him such a plan to familiarize yourself with the structure of the site and the testing process. My method in no way replaces the test case management system, but just adds it.
All of these publications regarding the description of the structure of the plan are common to most sites of online stores, therefore, do not carry any trade secrets.
Thank you all for your attention!