Принято считать, что псевдокод — это «инструмент» преимущественно разработчиков, хотя и используемый нечасто. Если обратиться к теории, то псевдокод представляет собой своего рода прототип, шаблон или даже скелет готового функционального решения. В таком случае почему бы не использовать его возможности для тестирования?

Я не ставлю своей целью научить вас написанию псевдокода, мы рассмотрим его использование на практике при уже имеющемся базовом понимании. 

Итак, чем же может помочь псевдокод в тестировании? Правильнее будет рассматривать его эффективность на примере различных этапов проверки качества продукта. Если не углубляться в тонкости, то жизненный цикл тестирования (именно тестирования) включает в себя следующие стадии: 

• анализ требований, 

• планирование, 

• дизайн, 

• подготовка данных и окружения, 

• исполнение тестирования и подведение его итогов. 

Представим, что от заказчика в наш отдел тестирования пришли следующие крайне простые требования:

«Необходимо проверить корректность отображения цветового оформления строк платежей в соответствующей таблице (списке) на странице Платежи клиентов в соответствии со статусом таких платежей и суммами по таким платежам. 

• Отмененный платеж должен быть залит красным цветом.

• Неотмененные платежи должны быть залиты зеленым цветом.

• Отмененные платежи могут также быть залиты желтым цветом, если сумма по ним ≤ 10 рублям.”

Псевдокод в данном случае может иметь следующий общий вид (без притязаний на лучшее возможное качество):

READ Платежи

    IF Платежи.отмена = 0:

        PRINT “Зеленый” (будем использовать Print для упрощения)

    ELIF Платежи.отмена = 1 and Платежи.сумма <=10 рублей (отрицательные суммы не могут присутствовать в данных; валидационные проверки не являются целью текущего тестирования):

        PRINT “Желтый”

    ELSE: 

        PRINT “Красный” 

    ENDIF

Итак, познакомившись с требованиями и составив подобный простенький псевдокод мы можем сформировать свою собственную документацию для последующего тестирования и определиться с кругом вопросов. Например, какой цвет должен быть использован в случае, если сумма платежа отсутствует? При получении от заказчика, скажем, такого ответа: «Если суммы нет, то красим в бесцветный», мы можем дополнить наш псевдокод еще одним условием:

    ELIF Платежи.отмена = 1 and (Платежи.сумма = NULL или Платежи.сумма = ‘ ’):

        PRINT “Бесцветный”

Таким образом могут быть учтены и иные требования, мы рассматриваем лишь общий механизм работы. 

Далее, переходя к планированию мы можем вторично обратиться к ранее составленному нами псевдокоду, объем которого не превышает 10 строк, чтобы определить, сколько нужно времени для тест-дизайна и исполнения тестирования. Обычно на этом этапе (да и на многих последующих) требования, спущенные от заказчика, перечитываются по несколько раз, забываются, теряется их понимание и так далее. Мы же экономим не только время, но и свои нервы. 

Пригодится псевдокод и при подготовке тестовых данных, поскольку случаи, которые следует покрыть проверками, четко отображены в условиях. 

Легко будет и с подведением итогов тестирования, которое в большинстве случаев включает в себя коммуникацию с другими участниками команды. С помощью псевдокода можно быстро и доступно описать проблемные места, некорректную работу которых вскрыло тестирование с использованием псевдокода. 

Применяя псевдокод в тестировании своих проектов мы пришли к следующим выводам: 

1. это наглядно;

2. это удобно: псевдокод очень легко поддерживать;

3. это быстро. 

Безусловно, не во всех случаях использование псевдокода оправдано и возможно. Это не универсальный инструмент, но зачастую он позволяет экономить много сил и времени. 

UPD: Грустно писать об этом, но это последняя статья Ситимобил на Хабр. Было здорово, спасибо за все!