Принято считать, что псевдокод — это «инструмент» преимущественно разработчиков, хотя и используемый нечасто. Если обратиться к теории, то псевдокод представляет собой своего рода прототип, шаблон или даже скелет готового функционального решения. В таком случае почему бы не использовать его возможности для тестирования?
Я не ставлю своей целью научить вас написанию псевдокода, мы рассмотрим его использование на практике при уже имеющемся базовом понимании.
Итак, чем же может помочь псевдокод в тестировании? Правильнее будет рассматривать его эффективность на примере различных этапов проверки качества продукта. Если не углубляться в тонкости, то жизненный цикл тестирования (именно тестирования) включает в себя следующие стадии:
анализ требований,
планирование,
дизайн,
подготовка данных и окружения,
исполнение тестирования и подведение его итогов.
Представим, что от заказчика в наш отдел тестирования пришли следующие крайне простые требования:
«Необходимо проверить корректность отображения цветового оформления строк платежей в соответствующей таблице (списке) на странице Платежи клиентов в соответствии со статусом таких платежей и суммами по таким платежам.
Отмененный платеж должен быть залит красным цветом.
Неотмененные платежи должны быть залиты зеленым цветом.
Отмененные платежи могут также быть залиты желтым цветом, если сумма по ним ≤ 10 рублям.”
Псевдокод в данном случае может иметь следующий общий вид (без притязаний на лучшее возможное качество):
READ Платежи
IF Платежи.отмена = 0:
PRINT “Зеленый” (будем использовать Print для упрощения)
ELIF Платежи.отмена = 1 and Платежи.сумма <=10 рублей (отрицательные суммы не могут присутствовать в данных; валидационные проверки не являются целью текущего тестирования):
PRINT “Желтый”
ELSE:
PRINT “Красный”
ENDIF
Итак, познакомившись с требованиями и составив подобный простенький псевдокод мы можем сформировать свою собственную документацию для последующего тестирования и определиться с кругом вопросов. Например, какой цвет должен быть использован в случае, если сумма платежа отсутствует? При получении от заказчика, скажем, такого ответа: «Если суммы нет, то красим в бесцветный», мы можем дополнить наш псевдокод еще одним условием:
ELIF Платежи.отмена = 1 and (Платежи.сумма = NULL или Платежи.сумма = ‘ ’):
PRINT “Бесцветный”
Таким образом могут быть учтены и иные требования, мы рассматриваем лишь общий механизм работы.
Далее, переходя к планированию мы можем вторично обратиться к ранее составленному нами псевдокоду, объем которого не превышает 10 строк, чтобы определить, сколько нужно времени для тест-дизайна и исполнения тестирования. Обычно на этом этапе (да и на многих последующих) требования, спущенные от заказчика, перечитываются по несколько раз, забываются, теряется их понимание и так далее. Мы же экономим не только время, но и свои нервы.
Пригодится псевдокод и при подготовке тестовых данных, поскольку случаи, которые следует покрыть проверками, четко отображены в условиях.
Легко будет и с подведением итогов тестирования, которое в большинстве случаев включает в себя коммуникацию с другими участниками команды. С помощью псевдокода можно быстро и доступно описать проблемные места, некорректную работу которых вскрыло тестирование с использованием псевдокода.
Применяя псевдокод в тестировании своих проектов мы пришли к следующим выводам:
1. это наглядно;
2. это удобно: псевдокод очень легко поддерживать;
3. это быстро.
Безусловно, не во всех случаях использование псевдокода оправдано и возможно. Это не универсальный инструмент, но зачастую он позволяет экономить много сил и времени.
UPD: Грустно писать об этом, но это последняя статья Ситимобил на Хабр. Было здорово, спасибо за все!
