Цель статьи: объяснить с чего начать применение теории тестирования на практике, попутно раскидывая всё по полочкам. Это не истина в последней инстанции, ибо информации тонны на вкус и цвет для каждого, но именно из-за неё и каши в головах новичков и появилась статья в качестве краткого руководства, потому что большинство говорят ЧТО нужно сделать, а не КАК это сделать. Кто-то и так все это знает, а кому-то уже надо начинать тестировать, ведь от тебя уже ждут результатов, желательно, вчера. Пишется это все для тестировщика, у которого ничего нет: документации/онбординга/один или новичок на проекте/вообще без опыта/мне бы чисто black box и т.д. Для меня лично, выбранная здесь терминология, на сей день лучше всего передает суть происходящего в тестировании. Правда я не смогу указать авторов идей и высказываний, т.к. приходилось сортировать горы информации, чтобы отсеять лишнее, да и подобная статья не планировалась вовсе, поэтому выписывались только идеи

Тестирование — проверка соответствия фактических и ожидаемых результатов поведения ПО, проводимая на конечном наборе тестов, выбранных определённым образом

Задача тестирования — предоставить информацию о том, как работает ПО

Верификация — проверка ПО на соответствие требованиям. Проводит тестировщик. Результат верификации — это ответ на вопрос «Соответствует ли продукт требованиям?»

Валидация — проверка ПО на соответствие потребностям пользователей. Проводит заказчик. Результат валидации — это ответ на вопрос «Можно ли использовать продукт под определенные цели?»

Для понимания разницы: verification — проверка, validation — придание законной силы. Например, выпускается лекарство, и оно соответствует заданным требованиям, но только врач может подтвердить: подходит ли оно для больного в его конкретной ситуации или нет?

С чего начать?

Вообще, выспись. Сон для тебя теперь дороже всего :) А потом с STLC. Ах, да… у нас же ничего нет

1. Определить, что именно тестируется

Иначе велика вероятность потратить кучу времени на совершенно ненужные вещи. Например, если говорят протестировать ручку, первым вопросом должно быть: “Что это за ручка?”. Вопрос не кажется таким уж и глупым, когда ты написал документацию и автотесты на шариковую ручку, о которой сейчас подумал, а она оказалась дверной… Или от пакета

2. Собрать максимум информации

Тестирование – это в первую очередь про сбор максимального количества информации о ПО и разработке и только потом верификация. Так ты узнаешь: на каком стеке работает проект, кто владеет всей информацией, чего от тебя вообще ждут, а в конце будет понимание: какой объем работ предстоит. Для получения как можно большей информации, задаем открытые вопросы.
Например:
— Функционал работает? – закрытый вопрос, предполагающий только однозначный ответ
— Как именно работает этот функционал? – открытый вопрос, предполагающий развернутый ответ
Чтобы понять какой вопрос задаёшь, протестируй его. Если предполагается развернутый ответ – это то, что надо. А то еще и сам себе на вопрос ответишь в процессе размышлений

Так как большая часть общения происходит в мессенджерах, то желательно знать


3. Уточнять, не додумывая самостоятельно
В тестировании нет никаких “Ну, это ж и так очевидно!”. Нет, не очевидно. Понимание одного и того же предложения у всех может быть разным. Отсюда и реализация. Не заданный вовремя, кажущийся глупым, вопрос, часто имеет плачевные последствия

4. Тестирование всегда начинается с позитивного и проверяет основной функционал
Никому не нужны мегахитрые негативные кейсы, если не работает основной функционал. Для ручки он будет таким: шариковая – пишет, дверная – открывает дверь, от пакета – позволяет держать пакет и т.д.

Какие вопросы задавать?

Самые главные вопросы, которые задаются постоянно, пока проходит SDLC (потому что ПО развивается и вводится новый или меняется старый функционал):

1. Какие проблемы пользователя решает внедряемый функционал?
   
   Этот вопрос вызовет цепочку других и в конце будет куда более четкое понимание, нежели скудное описание задачи
2. Что ожидается от тестирования?
   
   Этот вопрос задается себе неоднократно и по ответу на него станет понятно: какой объем работы тебя ожидает на основе уже полученной информации. Также его можно задать один-два раза заказчику/продакт оунеру. И это будет либо простое “нууууу, чтобы все работало”, либо “надо предоставить отчёт по критам и блокерам в текущем релизе в графике и ёмким описанием почему это произошло со ссылкой на Sentry/Kibana”. Но чаще всего ты будешь получать первый вариант

Документация

Начинается с оценки того, что дали тестировать:

1. Определив элементы с повторяющимся функционалом, выносишь их в чит-лист

2. Функционал элемента, который имеет некоторую логику, заносишь в расширенный чек-лист, который составляется на основе чит-листа

Например, есть некоторое поле ввода, которое имеет небольшую логику. Тогда чек-лист будет таким:
— Обязательное
— По умолчанию — Пустое
— При указании числа вне диапазона от 1 до 99 / сохранении пустого поля
> Подсвечивать поле красным
> Выводить под полем текст с ошибкой «Неверный диапазон. Введите число от 1 до 99»

В расширенный чек-лист вносится только заложенная логика. Глянув на такой чек-лист, можно быстрее определить правила работы элемента. И если что-то не записано – значит не предусматривалось. Например, не надо заносить в чек-лист ограничение по количеству символов в поле, если оно не было предусмотрено, т.к. это ты и так проверишь с помощью чит-листа и укажешь на это. В примере выше нет пунктов типа “введите 0” или “введите больше 2 цифр”, потому что это и так проверяется третьим пунктом, что делает чек-лист ёмче и проще для восприятия. И прежде, чем составлять тест-кейсы, подумай: сможет ли чек-лист описать логику работы быстрее, чем ТК? Потому что чек-лист используется не только как список покупок для декомпозированных элементов


3. И только то, что действительно не укладывается в чек-лист, выносится в тест-кейсы
Это те самые пользовательские сценарии с подробным описанием сложных проверок. И если у тебя на проекте настолько ничего нет, что нет даже TMS, то смело открывай Excel. Только помни про


Есть еще великое множество иных атрибутов. Они используются в зависимости от проекта. Но на первое время хватит и этих. Например, среду тестирования лучше вообще в отдельный документ вынести и ее, как и версионность стенда, указывать при регрессе


На практике же эти требования гибкие и исключение можно создать для любого из них, но надо быть твёрдо уверенным, что оно необходимо. Иерархию ТК можешь выстроить от GUI (если сайт/приложение простое и не имеет или мало повторяющегося функционала в разных местах) или по функционалу (если есть повторяющийся функционал. Например, при авторизации есть три типа пользователей – администратор, модератор, пользователь. Создаешь папку вида “права пользователей”, внутри неё можешь положить ТК по общему функционалу, а также создать три тест-сьюта, которые уже будут содержать различия между администратором, модератором и пользователями). Комбинировать тоже не запрещено

Багги

Отклонение фактического результата от ожидаемого — самое распространённое определение. Да вот только у нас нет документации. Откуда ж у нас ожидаемый результат? Что же тогда такое “баг”? А это проблема для тех, чье мнение имеет значение для проекта
И вот ты находишь дефект и вспоминаешь: как же там учили их заводить? Вроде бы суть должно отражать. Ок. “Не работает стейдж” (и докажи мне, что это неправильное название). Открываешь свою эксельку (боже, беги с этого проекта. Заводить баги и ТК в excel уже лютая дичь. 21 век на дворе) и пробуешь составить баг-репорт




Еще в баг-репорт можно впихнуть окружение и версию стенда, а можно и комментарием оставить

Что дальше?

Используй артефакты — это все то, что задействовано в тестировании: документация (тест-планы, тест-кейсы, чек-листы, баги и т.п.), инструментарий (программы), автоматизированные проверки (автотесты) и т.д. В чьем-то понимании укоренилось что артефакты – это чисто документация. Но ничто не стоит на месте

Рисуй майндмап проекта и таблицу состояний и переходов, как только будет время. Спасает от замыливания глаз. Дает идеи для новых тест-кейсов

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

Ну и тест-дизайн. Понимание техник даст сокращение документации, времени на тестирование и снова подкинет идей

Итого: тестирование – это просто только тогда, когда ты понимаешь, что делаешь. Как только в голове устаканится база, можешь изучать API, 7 уровней OSI, SQL и всё то, что разом вываливают на курсах. Надеюсь, стало чуточку полегче войти в айти. Ведь правда?