Testing. Errors in certification or ISTQB I really need

The article is useful to those who are not indifferent to their qualifications and want to become better. It's never too late to learn.

Any tester sooner or later thinks about the quality not only in the working process, but also in relation to himself, the quality of his education and abilities. At the moment, not all universities are able to prepare such a specialist. All kinds of courses, usually remote ones, remain, so that there is an opportunity to learn from people from the same field who have achieved success. But there is another way to assert themselves. These are certificates. There are many, to list, it makes no sense. But in almost all areas they are, and getting them is rather a plus than a minus.

I would like to write about ISTQB, the so-called. International Software Testing Qualifications Board. This is a globally recognized certification for testers. If you got this, then in theory you possess basic knowledge and theory, that is, you can get a plus for you at the interviews, and in general you assert yourself.

In the article I would talk about errors. Oh stupid and not very. About those that I personally committed in such a test or could. And I would not want anyone to get caught like that either.

Exhaustive Testing

I would like to begin with, to remember the following, “exhaustive testing is impossible, no matter how much effort is spent on testing (the so-called Principle # 2)”. This principle will have to remember. I will not throw many references to materials for preparation; I will quote one at the end of the article. The point at which I began to doubt was “With enough effort and instrumental support, exhaustive testing is possible for any software.” First thoughts were that patience and hard work would be fine. This is true only for trivial situations, in any real system to foresee everything situations can not, it remains only to minimize the number of problems.

Stages and Tasks

Information to remember. The main testing process can be divided into stages, activities:

• Planning (Stage 1)
• Analysis and Design (Stage 2)
• Implementation and Implementation (Stage 3)
• Evaluation of exit criteria and reporting (Stage 4)
• Actions to complete the tests (Stage 5)

These are all stages worth knowing. They are allocated not by chance, all have features. But this does not mean that they cannot overlap or occur simultaneously in a particular situation.

The question I faced, in fact, was the kind of tasks that we perform during the analysis and design phase. There were different answers.

• Definition of testing purposes
• Reviewing the basis of testing
• Creation of test sets from test procedures
• Analysis of lessons learned to improve the process

Grabbing the word design, I assumed that it was at this stage that all test plans were designed, so creating procedures and test sets seemed like a great answer. As I was wrong.

Therefore, I will briefly review all the stages so that after reading my article one could not read huge manuals. Specially numbered steps for reference to each.

So, stage number 1, planning. At this stage, the most important thing is to determine the purpose of testing and describe for yourself (or the person superior) the tasks that will help achieve this goal. Here and the volume, and risks, and approaches, and people. This stage also includes testing management. We not only made a plan, but throughout the entire process we see that it is being carried out, task after task. Thus, they not only set tasks, but also monitor them.

On the second - we analyze and deal with the project. What does this include? Just reviewing the basis of testing. It includes requirements for project integrity, a risk analysis report, architecture, design, tech. interface requirements. At this stage, as a matter of fact, we compile reports on risks, evaluate characteristics, set priorities, and the project draws on architecture. Select the test environment and install all the tools.

Just at the third stage, the will is given for writing test scenarios, all the most important work is immediately performed to perform them in manual or automatic mode. I would like to attribute the stage of implementation and implementation to the most important in the life of a tester, it will undoubtedly hold the most time, most problems will be found that, unfortunately, we are inspired for further work.

At the fourth stage, we mainly deal with the report, evaluate the characteristics we can, look at the found bugs, analyze what else tests we could carry out, form all this into a report for interested parties.

And finally, the fifth stage, it is rather a set of experience. We look at what results we have obtained, what goals we have been able to achieve, analyze data for future releases and use further. At this stage, too, can not do without documentation, which must be done in detail to give to the maintenance stage.

Testing during maintenance

What was my mistake, I suggested that at this stage it is possible to deal with the complaints on the system during the acceptance procedures. And this is the main task. In fact, testing during the maintenance period refers to the operation of the system after changing the environment. That is, this item refers to the impact of these changes on the current system or any additional modifications.

For example, a change of platform. What will be maintenance testing? All operational tests, testing of changes, should also add to the list of plans regression testing of those areas that were not affected. In this case, the main problem is the boundaries of the area that should be included in the testing. If time and resources allow, then it is worth including them all. But this time is not always enough. Therefore, to make a decision, it is necessary to assess the risk and the ratio of the size of the system to the size of the changes made.

System and component testing

The main thing to remember is that component testing is usually the responsibility of the developers, while system testing is the typical responsibility of testers.

In component testing, we do all the same search for defects, only in different pieces of the system, as far as possible, divide the system into these parts. It is important that each of these parts can be tested in isolation. There are many ways and approaches, but this is too broad a topic that will lead away from the essence, the difference between the types of testing. Another feature of component testing is that it includes not only functional testing, but also non-functional characteristics are checked. For example, these include testing the behavior of resources, memory leaks are tracked. As a rule, when component testing code is available.

Opposite testing is systemic. If in the component we considered each part as a separate part, then here we look at the system as a single object. We use a variety of methods for tests, and investigate both functional and non-functional requirements. Here, test descriptions, system usage options and other various ways to search for bugs are already suitable for research, but the system itself is considered as a “black box” without access to the code.

Formal review and its steps

When a set of requirements for the code, requirements for input data are formed for the system, some legal aspects must be taken into account, and so on and so forth, then the review is added to the testing stage. In fact, there is a list that we must take into account to complete each module in the system. It is possible that in this process we will have to resort to experts in the field we need.

The main phases of a formal review are planning, start-up, individual preparation, study / assessment / recording of results, re-processing, tracking. The stages are in fact all consistent and logical. They planned what criteria are needed, and selected people, shared their plans at start-up, prepared individually, taking into account all the features and requirements of this particular system. Then we got the results that showed our experts, and all the problems that surfaced, corrected. And then we follow that nothing is broken anywhere.

Conclusion

This material is not created to resolve all issues related to the upcoming certification. I hope at least the little that I managed to light up will be in my head for sure. If at least to some extent the article was useful, then I can continue the analysis of the most, in my opinion, non-obvious errors, which were easy to avoid.

Always ready for constructive criticism. If any questions arise or in my statements there is a subject for discussion, there will be an occasion to return to theory once again.

useful links

Materials for preparation
Good article about testing from Natalia Rukol