Checklist for beginner testers

Start learning to test

For the first steps of testing, you need to know the basic test set. This may include:

1. Fundamentals of testing (basic goals of testing, testing and debugging, why testing is necessary, the contribution of testing to success, quality assurance, and testing);
2. What is the difference between errors, defects, and failures. This also includes the root causes of the defect and what effect happens from the root causes (for example, the customer incorrectly wrote the calculation formula, the project manager did not notice this root cause, then the analyst, tester, and developer did not see it, and as a result, an incorrect calculation is reproduced already on the user's side).

Testing process

Returning to the software development process, the test process (STLC) plays a key role, and at what stage it is delivered (depending on the project management methodology). Typically, more experienced testers begin the testing process with a requirement trace to identify and eliminate the root causes of defects.

The testing process has a different look - for example, in an agile project management methodology, it is significantly simplified because building a complete testing process for each sprint (usually lasting 2 weeks) becomes not only costly but also meaningless.

API testing

At one stage of the development life cycle, programs do not have a graphical interface, so knowing how to do API testing with Postman or other similar software products is a must-have for every novice tester. It is especially necessary to know what the CRUD method is and what requests it involves, and also why such a method is not always effective in API testing.

Levels and types of testing

To build an STLC, it is important to know what levels and types of testing are included in the process. For example, the task was set to test one component of the program, which does not have any integration - then in this case the construction of the testing process will be based on only one level. Test levels include:

1. Component testing (unit testing - one or more modules of one program are tested without interacting with each other);
2. Integration testing (tested for interaction between program modules or systems);
3. System testing (larger testing that tests the integration of components or a group of components between different programs, and also focuses on the behavior and capabilities of the whole system);
4. Acceptance testing (understood testing before the release of the release, which usually focuses on the behavior and capabilities of the system or program as a whole).

It is also important to be able to distinguish between types of testing:

1. Functional testing;
2. Non-functional testing;
3. White box testing;
4. Change-related testing.

Test Design Techniques

This part of testing is responsible for the test documentation, which usually includes various test design techniques of the three methods (black box, white box, and experience-based method). Here we consider only two methods:

1. The following tests should be classified as a black box:

• Analysis of boundary values ​​(for example, a field that takes 20 values ​​has boundaries: lower 0 (empty field) and 1; upper: 20 and 21);
• An equivalent split that helps to exclude some tests to prevent exhaustive testing (for example, in a field that takes 20 values, it makes no sense to test the boundary values ​​​​of 2 and 19, because there were no errors when entering the boundary values ​​\u200b\u200bof 1 and 20. PS if this field is to run all 22 tests (from an empty field to 21 characters) - then this is already exhaustive testing, which is unattainable);
• Testing with a table of alternatives helps to identify bugs in software modules that have conditions. For example, is there a user registration when buying a product in an online store:
• Testing with the help of a diagram (table) of state transitions. For example, what state will the site of an online store have if the purchase operation is canceled at the stage of payment? Or what state will the web application take if incorrect details are specified when paying for the goods?
• Testing with use cases. For example, will a registered user (participant) be able to enter the personal account of an online store (subject)? Or will an unregistered user be able to open the personal account page? Or, if an already registered user provided incorrect data at the entrance, will he open the personal account page?

2. Method based on experience, including three types:

• Error guess;
• Exploratory testing (usually without the use of any tests);
• Testing based on checklists.

Testing Tools

Every novice tester needs to know what functional testing tools and test management should be used in testing and be able to master these tools, as well as their classification:

1. Test and test environment management tools (test plan, requirements management tools - trace table, defect management - Jira, YouTrack, etc., configuration management - Git);
2. Static testing tools (peer review - planning and control of the review process, data transfer, joint review for the collection of indicators and reporting);
3. Test design and implementation tools (test design techniques, mind-map, test data preparation);
4. Test coverage and execution tools (trace table, TestRail, test cases, TestManagement, etc.).

Bug

Bug report

For a novice tester, a must-have here is not only a bug found but also its correct design. After all, a bad description can impair the effectiveness of a developer fixing a bug (at least a programmer will spend much more time understanding the steps in a bug report than fixing a bug). Therefore, the bug report should contain a description of the SMART technique:

1. S - (specific) concreteness, transparency;
2. M - (measurable) measurability;
3. A - (attainable) achievability, realism;
4. R - (relevant) relevance;
5. T - (time-bound) time limits

The bug report consists of:

1. ID number of the bug;
2. Name (a good name is a step towards a quick understanding of the bug by the developer);
3. Specification (software version, links, browser, test environment, etc.);
4. Precondition (not always used, but sometimes necessary when you need to fulfill some condition before playing the bug);
5. Reproduction steps (which should have specificity, transparency, and locality);
6. Expected result (it is important to remember that expected result = required result);
7. The result obtained (a description of the bug itself or the behavior of the program);
8. Attachments (INI settings, screenshots, files, logs, etc. that help reproduce the bug);
9. Contractor (developer who must fix the defect);
10. Priority;
11. Comments (they are not always used, but more experienced testers describe moves on how to fix a particular bug).