Home

Автор: Майкл Болтон (Michael Bolton)
Оригинал статьи
Перевод: Ольга Алифанова

Клара Янова – ответственная тестировщица, которая изучает, практикует и пропагандирует Rapid Software Testing. Недавно она написала на LinkedIn:

"Я могу ОЖИДАТЬ, что что-то произойдет. Но это необязательно значит, что Я ХОЧУ, чтобы это произошло. Я даже могу хотеть, чтобы это произошло, но то, что оно не происходит, вовсе не означает автоматом, что тут есть какая-то проблема.

Смысл заметки: пожалуйста, давайте покончим с "ожидаемыми результатами" в баг-репортах!"

В ответ Дерек Чарльз спросил:

"Но как еще ты сообщишь разработчику или команде, что ДОЛЖНО происходить? Думаю, что ожидаемые результаты необходимы, особенно если в ходе тестирования обнаружен регресс".

Клара ответила:

"Я предлагаю описывать поведение, которое кажется тестировщику проблематичным, и объяснять, ПОЧЕМУ это может быть проблемой для кого-то. Причины, почему поведение воспринимается как баг – вот что самое важное".

Именно так. Клара говорит в терминах проблем и оракулов – способов, благодаря которым мы распознаем проблемы, когда сталкиваемся с ними в ходе тестирования.

Есть закавыка с "тем, что должно произойти": в разработке ПО не всегда ясно, что должно произойти. Более того (и важнее) – тестировщики не руководят проектом или бизнесом, и не диктуют, что должно происходить.

К примеру, в ходе тестирования я могу наткнуться на что-то смущающее меня в продукте – или удивляющее, или неверное. Спецификация говорит о желаемом поведении одно; разработчик утверждает, что спека устарела, и противоречит ей; продакт-оунер подтверждает, что спека устарела. Но также сообщает, что интерпретация желаемого поведения в исполнении разработчика – это не то, чего хочет она. А затем я сверяюсь с RFC, и оказывается, что интерпретация продакт-оунера противоречит тому, что RFC называет подходящим поведением.

К счастью, мне не нужно решать, и я не обязан говорить, что должно произойти. Моя задача как тестировщика – сообщить о явном несоответствии между продуктом и предположительно желаемыми вещами, или между продуктом и чьим-то явно выраженным желанием или требованием. В вышеописанном случае я дал продакт-оунеру знать о расхождении между ее интерпретацией и стандартом, и дальнейшее решение, чего она и бизнес хотят от продукта, за ней.

Даже если у меня есть какие-то ожидания, они могут быть ошибочными, а я могу заблуждаться в своем понимании того, как должно работать. К примеру, она может решить, что наш продукт не будет поддерживать этот стандарт. Она может указать мне на то, что стандарт, к которому я апеллирую, заменен более поздним. В любом случае то, как должно работать, решается не мной, а теми, кто всем рулит. Им за это деньги платят. И это хорошо, а не плохо.

Но я бы все равно хотел ответить на вопрос Дерека: как нам, тестировщикам, сообщать о проблеме, не ссылаясь на "ожидаемые результаты"?

• Вместо того, чтобы говорить "ожидаемый результат" и бросать все вот так, мы можем сказать "несоответствие спецификации".

Несоответствие спецификации – это особый случай более общего способа распознавания и описания проблемы: несоответствие заявлениям. "Несоответствие заявлениям" – это оракул-эвристика (эвристика – это ненадежный способ решения проблемы; оракул – это отдельный вид эвристики, который ненадежно помогает вам решить вопрос идентификации и описания бага). Когда продукт не соответствует заявлению, сделанному кем-то значимым, то это, скорее всего, проблема – или с продуктом, или с заявлением. Но не я, не тестировщик, решаю, в чем именно проблема.

Спецификация – это особая форма заявления о том, как работает продукт, или как он должен работать. Заявления могут делаться на дизайн-сессиях, планировочных митингах, при парном программировании, переговорах в коридоре, на тренингах… Заявления можно встретить в файлах справки, маркетинговых материалах, процессных диаграммах, справочных таблицах, руководствах пользователя, набросках на доске, UML-диаграммах. Заявления могут также содержаться в коде автоматизированной проверки, когда автор создает код, сравнивающий результат работы продукта с ожидаемым и предположительно желаемым результатом. Способность распознавать множество источников заявлений и несоответствий им делает нас лучше как тестировщиков.

Когда вы ссылаетесь на релевантное заявление, сообщая "не соответствует заявлению" (и природа заявления и его автор идентифицированы), вам не нужно говорить об "ожидаемом результате".

• Вместо "ожидаемого результата" вы можете сказать "не соответствует тому, как раньше работало".

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

В любом случае, если вы говорите "не соответствует тому, как раньше работало" (и описываете это в терминах проблемы), вам не нужно говорить об "ожидаемом результате".

• Вместо "ожидаемого результата" вы можете сказать "не соответствует самому продукту".

Несоответствие самому себе – это оракул-эвристика. Это может принимать различные формы: продукт возвращает разные результаты при разных запусках; продукт в одной части демонстрирует чистый, бесшовный интерфейс, а в другой – раздражающий и запутывающий. В одной части продукта выводится точный результат, а в другой – неточный; один компонент логирует результаты в формате, отличающемся от логов другого компонента, и это затрудняет анализ…

Это несоответствие может быть нежелательным (из-за проблемы надежности), или совершенно нормальным (веб-страница новостного сайта должна меняться ежедневно), или оно может быть желательным и нежелательным по причинам, о которых вы не знаете (так как, как и я, вы не можете знать все).

В целом люди предпочитают вещи, ведущие себя согласованно. Тривиальный пример из Microsoft Office (Office 365): для поиска текста в Word команда клавиатуры – Ctrl+F. В Outlook, части того же самого пакета, Ctrl+F стартует функцию пересылки сообщения, а поиск запускается через F4. Если бы Outlook и Word одновременно разрабатывались одной и той же командой, это было бы, скорее всего, определено как баг и исправлено. В результате программный менеджер пакета Office решил, что соответствие истории продукта важнее, чем несоответствие продукта самому себе, и нам приходится с этим жить. Ну что ж.

В любом случае, когда вы говорите "не соответствует какому-то аспекту того же самого продукта" (и идентифицируете специфику несоответствия), вам не нужно говорить об "ожидаемых результатах").

• Вместо "ожидаемого результата" вы можете сказать "не соответствует похожему продукту" (и указать продукт и причину несоответствия).

Несоответствие похожему продукту – это оракул-эвристика. Любой продукт (то, что кто-то произвел), дающий релевантные точки сравнения – это по определению похожий продукт. Это, конечно же, включает в себя продукты-конкуренты: Microsoft Word и Google Docs в этом смысле похожие продукты. Microsoft Word и WordPad – тоже похожие продукты, у них много общих функций. Если Word не может открыть RFT-файл, сделанный в WordPad, есть причины подозревать проблему в одном или другом из них. Если WordPad правильно печатает RFT, а Word – нет, есть повод подозревать проблему в Word/

Сравнима ли Unix-программа wc (подсчет слов) с Microsoft Word? Все, что делает wc – это считает слова в текстовых файлах, поэтому нет, хотя… У Word есть функция подсчета слов. Если подсчет слов Word в текстовом файле необъяснимо отличается от числа в wc, есть причина подозревать проблему в том или другом продукте.

Тест-инструменты и наборы автоматизированных проверок – это тоже сравнимые продукты. Если результат работы продукта не соответствует определенным желаемым результатам, выданным вашим тест-инструментом, или обрабатываемым для достижения этих результатов данным – есть причина подозревать проблему.

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

Это всего лишь несколько примеров. Преподавая Rapid Software Testing, мы даем набор оракулов-эвристик, которые идентифицируют принципы желаемого (и нежелательного) соответствия (и несоответствия) для идентификации багов – подробнее можно узнать здесь.

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

Почему это важно? По ряду причин, как думается мне.

Во-первых, "ожидаемый результат" прямо-таки вымогает вопрос, откуда взялись ожидания. Это просто посредник для чего-то более конкретного. Почему бы не перейти сразу к делу и не сказать об этом, оставаясь профессионалом? Потому что…

Во-вторых, четкое объяснение, откуда пришли ожидания, бережет время и фокусирует разговор на (не)желательных (не)соответствиях, которые имеют значение, когда разработчики и продакт-оунеры решают, баг ли это и надо ли это исправлять. Это также помогает фокусировать починку на нужном заявлении (к примеру, если продукт в порядке, а спека – нет, это намек на исправление спеки).

В-третьих, это помогает помнить, что наша задача как тестировщиков – не подтверждать, что продукт работает "как ожидается", а спрашивать "есть ли в этом проблема?" Продукт может соответствовать ожиданиям и вне зависимости от этого кишеть жуткими проблемами. Наша работа – искать, находить и описывать несоответствия и проблемы, которые имеют значение, прежде чем не стало слишком поздно.

И, наконец…

В-четвертых, разговор в терминах оракулов вместо "ожидаемых результатов" помогает избежать патронизирования, снисходительности, потерь времени, и прочих элементов баг-репорта, которые заставляют разработчиков оскорбляться или закатывать глаза.

Результат: продукт падает.

Ожидаемый результат: продукт не падает.

Не будьте такими тестировщиками.

Обсудить в форуме