Здравствуйте, любители качества и его контроля. Хочу поделиться своим опытом входа в новый проект. Здесь будет список основных проблем, с которыми сталкиваются QA, на новом проекте. В первой части я расскажу с чего я начинал и расскажу как решал проблемы с ТЗ.
"Откуда начать кусать этот пирог"
Здесь очень важно понять, в каком состоянии находится проект.
Очень часто, в голове возникают мысли вида: "Я вот сейчас ознакомлюсь с ТЗ. Потом посмотрю макеты и мне все станет ясно. Еще почитаю тест-кейсы и тем более все пойму".
Но если мы отойдем от "мира с розовыми поняшами", то эта логическая конструкция разбивается о такие факторы:
ТЗ может быть устаревшим
ТЗ может быть неполным
ТЗ написано с большим количеством грамматических ошибок и его логическую конструкцию понять невозможно.
Макеты не соответствуют реальности
Части макетов попросту нет
Тест-кейсов нет
Вместо тест-кейсов там чек-листы и без контекста непонятно что в них
Тест-кейсы написаны частично
Тест-кейсы написаны так, что их проще сжечь чем понять что они выполняют
Здесь нам поможет комбинация исследовательского тестирования + маппинг его результатов на то что в ТЗ/макетах/тест-кейсах
"Это не документация, а какой-то ад. Я ничего не понимаю."
Начнем с того, на какие логический блоки разбито ТЗ. Исследовательское тестирование разобьем на такие же блоки. Если же такой разбивки нет или она кажется не очевидной, то можно попробовать разбить блоки, например, постранично(если мы говорим про веб) или пользовательские сценарии.
Проходим сценарии. Но сразу оговорюсь - без фанатизма. На этом этапе нам не надо экспериментировать и пытаться накидать как можно больше негативных сценариев и наловить багов. Ведь на этом этапе наша главная задача: "Разобраться как это все работает". А большое количество негативных сценариев, нас попросту может запутать и отвлечь от главной цели. В процессе такого исследования мы можем понять, какой из 3х пунктов, указанных выше, описывает состояние ТЗ(а может и несколько пунктов, что бывает чаще).
Устаревшее ТЗ. Ну тут все достаточно просто. Мы сравниваем ожидаемое поведение продукта, с фактическим. Для большего удобства здесь можно использовать таблицы. В которой укажем пункт требований/описание сценария, ожидаемый результат, фактический результат.
Чем эта таблица нам будет полезна? На то есть несколько причин:
Мы будем иметь информацию о актуальности/неактуальности тех или иных пунктов требований.
Информация о том, что уже проверено, чтобы не держать в голове.
Это информация для руководства, чтобы понять чем ты занимаешься. И это не просто задача в jira и указание потраченного времени. А список того что ты проверил и какие несоответствия ты нашел. Это дает руководству то, что они любят - "Прозрачность". А взамен вы получаете + в карму, на испытательном сроке.
Неполное ТЗ. Тут приблизительно так же как и с устаревшим ТЗ, но есть пара отличий:
Сценарии, как мы формировали из устаревшего ТЗ, придется придумывать самому
Ожидаемого результат - нет. И нам его надо будет узнать.
Путем исследовательского тестирования готовим кейсы. Тут мы так же, используя аналогичную таблицу, можем собрать список "наших" кейсов с фактическим результатом. А ожидаемый результат оставляем пустым.
ТЗ с большим кол-вом грамматических ошибок.(Мое самое любимое). Самое главное что надо делать с таким ТЗ - "Не читать по 10-20 раз и понять его суть". Я на это тратил много часов, но толку от этого мало. А если мы сложим "ТЗ с грамматическими ошибками" + "Новый проект/компания" = "Огромная неуверенность в себе и внутреннее ощущение собственной некомпетенции". Потому что ты всего лишь не можешь прочитать ТЗ.
Давайте вернемся к ТЗ.
В каждом пункте ТЗ мы помечаем те предложения или словосочетания, которые мы не можем понять и....выбрасываем их из наших кейсов. Потому что это ровно то, что нам надо будет выяснить. Проходим по пунктам требований и записываем все в таблицу. Отдельным цветом помечаем то, что нам не удалось понять.
"Что дальше? Куда идти с таблицами?"
Давайте будем отталкиваться от того, есть ли у нас аналитик в команде.
Если у нас есть аналитик, который его писал, то тут все очевидно. Назначаем встречу и обсуждаем все что мы нашли. Возможно будет даже не одна и не две встречи. По результатам встречи заводим задачу или баги, в зависимости как того как принято на проекте это делать. И назначаем на них аналитика. Возможно стоит обсудить дедлайны на это дело. Так как для аналитиков эти задачи могут буть далеко не на самом верху приоритетов.(что чаще всего и бывает)
Если аналитика нет. Можно попробовать подключать разработчиков, чтобы понять как кто это реализовал, так как других вариантов нет. После чего сверяем с тем что у нас получилось. Этот вариант занимает гораздо больше времени, так как часто каждый пункт ТЗ - отдельная задача. Так что придется побегать по всей команде. Если же мы смогли выянить несоответствия того что сказал нам разработчик, с нашим фактический результатом, то заводим баг.
Если у нас новый аналитик, который как и вы видит "это". Ну, тут вам придется быть вдвоем в состоянии "Че тут происходит? Где я?". Вдвоем такое уже не решить. Тут надо подключать разработчиков или их лида, чтобы понять как это работает/должно работать. Если найдены несоответствия - заводим баги/задачи.
Хочу сразу подчеркнуть, это очень трудоемкое задание. И это решение только конкретного состояния ТЗ. То есть, разобравшись с этим, надо озадачится системным решением, чтобы в будущем такого не возникало.
Возможно кому-то могут показаться вещи весьма очевидными, но когда ты только пришел в новую компанию/проект, то порой очевидные вещи таковыми не являются. Да и в каждом проекте все иначе.
P.S. Надеюсь, этот пост будет полезен.
