Где ошибка дешевле
Самая дешёвая ошибка — та, которую нашли в тексте. Дефект требования, замеченный при чтении, стоит разговора на десять минут; тот же дефект, доживший до выпуска, стоит правки кода, повторной проверки, объяснений людям и иногда возврата денег.
| Где нашли | Что нужно, чтобы исправить |
|---|---|
| в требовании | разговор и правка строки |
| в коде | правка и повторная проверка |
| в тестировании | то же плюс возврат задачи и сдвиг срока |
| у людей | то же плюс потери и репутация |
Поэтому первое умение тестировщика — не кликать, а читать. Причём читать не так, как читает автор («да, всё понятно»), а так, как читает исполнитель: можно ли понять это иначе, чем задумано.
Требования бывают написаны по-разному: подробный документ, пользовательская история в одну строку, переписка, макет, а иногда только устная договорённость. Формат не так важен: важно, есть ли вообще зафиксированное «как должно быть». Если его нет, то и дефекта нет — есть разные мнения, и спор о них бесконечен.
Четыре вопроса
Читают требование по четырём вопросам. Они простые, но их редко задают все четыре подряд — а дыры обычно в том, который пропустили.
| Вопрос | Что проверяем | Плохой пример |
|---|---|---|
| однозначно? | читается одним способом | «система должна работать быстро» |
| проверяемо? | можно придумать проверку | «интерфейс должен быть удобным» |
| полно? | сказано и про неудачный случай | «при оплате списываются деньги» |
| непротиворечиво? | не спорит с другим требованием | «поле обязательно» и «поле можно пропустить» |
Самый частый провал — полнота. Требования пишут по удачному пути: человек всё заполнил правильно, деньги списались, письмо ушло. А работа программы наполовину состоит из неудачных путей, и именно там живут дефекты, которые видит человек.
Поэтому к каждому требованию полезно задать три вопроса про «а если»: а если пусто, а если слишком много, а если не получилось. Ответы на них либо уже есть в тексте, либо это и есть та работа, которую вы только что сэкономили команде.
Что делать с дырой
Третье — что делать с найденной дырой. Вопрос к требованию задают до кода и письменно, иначе он теряется: устный ответ помнят двое и по-разному.
| Шаг | Как это выглядит |
|---|---|
| найти неясность | «при повторном нажатии платёж уйдёт дважды?» |
| предложить вариант | «предлагаю: второй раз не отправлять, показать сообщение» |
| записать ответ | решение попадает в задачу или в требование |
| сделать проверку | по решению появляется пункт чек-листа |
Второй шаг стоит отдельного слова. Вопрос с предложенным вариантом отвечается за минуту, а без варианта висит днями: автору требования проще согласиться или поправить, чем заново придумывать решение. Это не вежливость, а способ сэкономить себе неделю ожидания.
И про границы. Тестировщик не придумывает требования за аналитика: он находит место, где решения нет, и добивается, чтобы решение приняли и записали. Разница видна на исходе: придуманное вами решение никто не считает договорённостью, а записанное — считают все.
И привычка, которая окупается всегда: читая требование, сразу записывайте будущие проверки. Пока текст перед глазами, вопросы «а если пусто» приходят сами; через неделю придётся вчитываться заново.
И отдельно про то, чего от требований ждать не стоит. Полных требований не бывает: любой текст можно дочитать до места, где решения нет, и это нормально — описать все случаи заранее невозможно ровно по той же причине, по которой нельзя перебрать все проверки. Задача не в том, чтобы добиться полноты, а в том, чтобы дыры находились до кода, а не после выпуска, и чтобы решения по ним принимались осознанно.
Отсюда и мерка собственной работы на этом шаге: не «сколько неясностей я нашёл», а сколько решений было принято благодаря вопросам. Десять вопросов, оставшихся без ответа, — это не работа, а список претензий; три вопроса, превратившиеся в записанные решения, меняют продукт.