Pseudo code for testing
It is generally accepted that pseudocode is a “tool” mainly for developers, although it is used infrequently. If we turn to theory, then pseudocode is a kind of prototype, template, or even the skeleton of a ready-made functional solution. In this case, why not use its capabilities for testing?
I do not set out to teach you how to write pseudocode, we will look at its use in practice with a basic understanding already available.
So, how can pseudocode help in testing? It would be more correct to consider its effectiveness on the example of various stages of product quality control. If you do not go into details, then the life cycle of testing (specifically testing) includes the following stages:
requirements analysis,
planning,
design,
preparation of data and environment,
execution of testing and summarizing its results.
Let’s imagine that the following extremely simple requirements came from the customer to our testing department:
“It is necessary to check the correctness of displaying the color scheme of payment lines in the corresponding table (list) on the Customer Payments page in accordance with the status of such payments and the amounts of such payments.
Canceled payment should be filled in red.
Payments that have not been canceled should be highlighted in green.
Canceled payments may also be filled in yellow if the amount on them is ≤ 10 rubles.”
Pseudocode in this case maybe have the following general form (without claiming the best possible quality):
READ Платежи
IF Платежи.отмена = 0:
PRINT “Зеленый” (будем использовать Print для упрощения)
ELIF Платежи.отмена = 1 and Платежи.сумма <=10 рублей (отрицательные суммы не могут присутствовать в данных; валидационные проверки не являются целью текущего тестирования):
PRINT “Желтый”
ELSE:
PRINT “Красный”
ENDIF
So, having got acquainted with the requirements and having compiled such a simple pseudo-code, we can create our own documentation for further testing and decide on the range of issues. For example, what color should be used if the payment amount is missing? Upon receiving from the customer, say, such an answer: “If there is no amount, then we color it in colorless,” we can supplement our pseudocode with one more condition:
ELIF Платежи.отмена = 1 and (Платежи.сумма = NULL или Платежи.сумма = ‘ ’):
PRINT “Бесцветный”
Thus, other requirements can be taken into account, we consider only the general mechanism of work.
Further, moving on to planning, we can again refer to the pseudocode we previously compiled, the volume of which does not exceed 10 lines, in order to determine how much time is needed for test design and test execution. Usually at this stage (and at many subsequent ones), the requirements lowered from the customer are re-read several times, forgotten, their understanding is lost, and so on. We save not only time, but also our nerves.
Pseudocode is also useful when preparing test data, since the cases that should be covered by tests are clearly displayed in the conditions.
It will also be easy to sum up the results of testing, which in most cases includes communication with other team members. Using pseudocode, you can quickly and easily describe problem areas, the incorrect operation of which was revealed by testing using pseudocode.
Using pseudocode in testing our projects, we came to the following conclusions:
1. it is visual;
2. it’s convenient: pseudocode is very easy to maintain;
3. it’s fast.
Of course, the use of pseudocode is not justified and possible in all cases. This is not a universal tool, but often it saves a lot of effort and time.
