Перевод статьи «How the Testers Can Ask Questions The Smart Way: The Step-By-Step Guide».
Мозговой штурм с командой – это всегда познавательный опыт.
В этот раз у нас была необычная идея. Мы разделили команду на две группы и решили задавать друг другу вопросы о продукте, который мы разрабатываем. Единственным условием было то, что вопросы должны были касаться тестирования этого продукта.
В итоге мы научились одной важной вещи – задавать вопросы, иногда даже странные, но именно этот навык в конечном итоге помог сделать наш продукт лучше и качественнее.
Почему тестировщики задают вопросы, и насколько это важно? В этой статье мы постараемся дать ответы на эти вопросы.
БЕСПЛАТНО СКАЧАТЬ QA КНИГИ можно в телеграм канале "Библиотека тестировщика"
Содержание:
Почему тестировщики задают вопросы?
Будучи тестировщиком, мы знаем, что в реальной жизни часто приходится сталкиваться с давлением, связанным со сроками и временными ограничениями.
Зачастую тестировщики не имеют четкий и понятный документ с требованиями для тестирования продукта. В таких ситуациях, когда информация о проекте ограничена или неполна, тестировщики вынуждены делать предположения, чтобы продолжать работу.
Примеры
В документе с требованиями упоминается, что приложение для написания эссе должно отображать имя автора. Однако во время тестирования выяснилось, что у одного и того же эссе может быть несколько авторов, и они могут создавать разные версии одного и того же эссе.
Вопрос: как правильно отображать имя автора в такой ситуации? В требованиях нет ясности, и нет человека, который мог бы предоставить дополнительную информацию. Разработчик предположил, что следует показывать имя автора, который владеет последней версией эссе, и тестировщик согласился с этим решением.
Теперь возникают такие вопросы:
- Что если несколько авторов обновляют эссе одновременно?
- Что если есть несколько авторов с одинаковым именем?
- Что если автор хочет вернуться к предыдущей версии эссе?
Приложение крашнулось, когда пользователь попытался обновить одну и ту же страницу в седьмой раз. Найти причину этой проблемы и доложить о ней – это хорошо, но когда существует сильное давление по срокам, нам нужны дополнительные данные, чтобы оценить серьезность этой проблемы и выявить причину.
В данной ситуации, если у нас нет достаточной информации о проблеме, тестировщик, возможно, должен предположить, что такие случаи являются редкими и ими можно будет заняться позже.
Исходя из таких предположений возникают следующие вопросы:
- Можно ли пойти на риск и отложить данную проблему?
- Можно ли найти временное обходное решение?
Как правильно задать вопрос?
Шаг 1: Исследуйте
Любопытный тестировщик, наблюдая неожиданное поведение приложения, начинает исследовать, и это исследование приводит к появлению вопросов.
Пример
После обнаружения проблемы, при которой пользователь выходил из системы каждые 5 секунд, выяснилось, что причиной этой проблемы был автоматический запрос к базе данных, выполняющийся каждые 5 секунд и очищающий все текущие сессии.
Возникают следующие вопросы:
- Зачем нам понадобился этот запрос?
- С какой целью он запускался каждые 5 секунд?
Таким образом, в результате исследования возникает еще больше вопросов, что на самом деле помогает найти правильный ответ.
Шаг 2: Применяйте прошлый опыт
Когда мы сталкиваемся с той же проблемой, что и раньше, наш разум сразу же активирует информацию о прошлых случаях.
Пример
Основываясь на опыте работы с Linux, я знал, что перезагрузка сервера может автоматически устранить множество ошибок. Применяя тот же метод к текущей ситуации, где код был развернут на Linux сервере, я заметил, что производительность приложения улучшилась.
Возникли вопросы:
- Что было бы, если бы сервер не был перезагружен?
- Не упустили ли мы что-то важное при оценке производительности приложения?
Шаг 3: Анализируйте данные
Опытный тестировщик всегда анализирует данные и задается вопросом о том, как найти во всем закономерности.
Пример
После запуска первой версии продукта было зарегистрировано только 3 сбоя системы, во всех остальных случаях продукт работал хорошо. При запуске второй версии продукта количество сбоев увеличилось до 17, а при запуске третьей версии – до 47. Существенных изменений не вносилось. Так почему количество сбоев увеличилось?
При детальном рассмотрении выяснилось, что причиной проблем не были изменения в продукте, а низкая скорость сети в сельских районах. Таким образом, анализ данных помог нам выявить закономерность в проблеме.
Возникают следующие вопросы:
- Каково влияние скорости сети на систему?
- Как можно исправить ситуацию?
- Какие меры предосторожности следует предпринять в будущем?
- Какие показатели скорости сети следует учитывать при тестировании?
Таким образом, тестировщик задает вопросы не потому, что хочет задать много вопросов. Причин может быть много, например:
- Постоянное исследование
- Отсутствие конкретной информации
- Уточнение деталей
- Разъяснение сделанных предположений
- Оценка общего риска
- Принятие решений
Но, как говорится, задавать вопросы – это искусство.
Вывод
Задавать вопросы всегда важно и необходимо. Но если вы видите негативный или холодный ответ на свои вопросы, возможно, вам стоит переформулировать свой вопрос или научиться более грамотно задавать вопросы.
Лично я поддерживаю идею задавать вопросы, но ожидаю, что люди сначала попробуют найти ответ самостоятельно. Ведь никто не хочет слышать вопрос типа “где скачать Skype”, когда есть Google :).
- Разбирайтесь в вопросах, потому что ответы не всегда могут быть однозначными.
- Будьте готовы слушать и не перебивайте собеседника.
- Попросите предоставить вам дополнительную информацию – полезные ссылки, книги или другие источники.
- Выражайте свою точку зрения и выслушивайте другие мнения.
Как говорится, задать вопрос – это ключ к открытию мира, полного знаний. Если вы понаблюдаете за детьми, то увидите, что они задают больше вопросов, чем взрослые. Почему? Потому что они не понимают, как можно что-то предположить.
Продолжайте спрашивать, будьте любопытными, получайте ответы на свои вопросы, и тогда тестирование станет проще, продуктивнее и интереснее.