Главная проблема объяснения — проклятие знания. Мы работаем с чем-то достаточно давно, разбираемся во всех тонкостях, поэтому искренне не понимаем, как можно этого не знать. "Это же элементарно!". Да. Для нас.
Посмотрим на проявления этого феномена в разных ситуациях.
Junior тестировщик
Наша система умеет работать по протоколу SOAP. Матерые тестировщики давно к этому привыкли. И вот на проект выходит junior qa. Ему даются на проверку самые простые баги, "отправить запрос, выверить ответ по документации". Только выглядят они примерно так:
Отправить SOAP-запрос {тело запроса}.
В ответе получаем А, а ожидаем В.
Делов на 1 минуту.
Но у начинающего от такой постановки начинается паника "какой запрос? Что такое SOAP? Как отправлять такие запросы?!".
При этом, если он задаст вопрос "как отправить запрос?", коллега, подверженный проклятию знания, пожмет плечами "через SOAP UI". Только что такое объяснение даст новичку?
В такой ситуации проявляется умение начинающего коллеги гуглить (кстати, по SOAP рекомендую эту статью). Потому что если он найдет минимум информации, скачает и установит себе SOAP UI, ему останется только спросить у коллеги "А где мне взять WDSL? И какие логин-пароль использовать?".
И такие вопросы вызовут у коллег большее уважение. Потому что такое поведение говорит о том, что новенький уважает время своих коллег и минимум информации в состоянии найти сам.
Замыленный взгляд
Раз за разом проводя одни и те же тесты, мы смиряемся с неудобством использования нашей программы. Более того, мы привыкаем использовать обходные пути и костыли.
Поэтому когда приходит новый человек и говорит "я не пониманию, как мне сохранить файл", мы сильно удивляемся. Как так? Это же так просто!
Нет, это не просто. Просто мы уже привыкли. Именно поэтому, когда на проекте появляется новый человек, важно выслушивать все его претензии к удобству использования программы или чтению документации.
Точно так же потом и пользователь не поймет, что ему делать. Только пользователи жалуются далеко не всегда. Часто они не могут понять, что делать, плюют и уходят с сайта к конкурентам. А все "проклятие знания" и, как следствие, "замыленный взгляд"!
Описание новой фичи
Когда к нам приходит Заказчик и говорит "прикрутите мне вот сюда синенькую кнопочку", всегда стоит задать вопрос "а зачем?".
Иногда ответ кажется нам слишком очевидным. Поэтому мы не задаем вопросы, а просто делаем, как нам кажется правильным. И это большая ошибка!
НИКОГДА не додумывайте требования! Задача тестировщика - уточнить все моменты, которые могут быть восприняты двояко, которые не описаны в документации.
Просто Заказчик, когда просит что-то сделать, дает мало информации. Ведь он погружен в контекст проблемы. Поэтому он говорит нам "отправьте SOAP-запрос", предполагая, что мы тоже в контексте и прекрасно понимаем, о чем идет речь.
Додумывание требований приводит к страшным последствиям. Вплоть до того, что разрабатывается система, которая вообще не решает проблему Заказчика (вот отличный пример).
Иногда мы угадываем, да. Но иногда Заказчик страдает от какой-то проблемы и думает, что "синенькая кнопочка" все исправит. Если мы просто реализуем кнопочку, Заказчик быстро поймет, что проблема не решена, она была глубже и поверхностное исправление только все испортило.
Но если мы выяснили, для чего нужна эта кнопочка, какую проблему хочет решить Заказчик с ее появлением, то мы, как тестировщики, на этапе тестирования требований сможем сказать "ага! А вот про это то вы и забыли! А что будет с этим отчетом?".
Иногда уточнение информации по вопросам тестировщика может сильно удивить. Если исходно требования додумали и додумали неправильно. Именно поэтому так важно начинать тестирование на ранних стадиях разработки новой фичи. И ничего не принимать на веру. Все уточнять и прояснять!
Кто, если не мы?
Поэтому всегда при тестировании документации помните о проклятии знания. И задавайте вопросы. Не додумывайте, не надо. Пусть додумывают остальные. Задача тестировщика - найти корень зла. Для этого иногда приходится 5 раз задать вопрос "почему?", но оно того стоит!
