Автор: Ханиша Арора (Hanisha Arora)
Оригинал статьи
Перевод: Ольга Алифанова

Вы — начинающий тестировщик? Работать над приложением в команде из пяти и более разработчиков может показаться надёжным способом создать продукт без багов. Но правда в том, что количество разработчиков в проекте никоим образом не влияет на итоговое число ошибок.
Как бы ни был опытен разработчик — баги всё равно случаются. Не существует такого понятия, как «идеальный продукт».

Со временем разработчики начинают понимать, какие баги вы чаще всего находите, и в продукте становится меньше багов определённого типа — по сравнению с тем, что было ещё пару спринтов назад. Однако это не повод расслабляться. Именно тестировщик должен продолжать искать новые способы находить баги — до того, как они попадут на прод.

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

Вот несколько таких техник, которые, по моему опыту, приносят хорошие результаты.

Каждый раз — по-новому: Monkey Testing

Вы когда-нибудь видели, как разработчики добавляют новую функциональность и при этом ломают уже существующую? Скорее всего — да. А если нет, то ещё увидите.

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

Слабое место: вы тестируете каждую функцию по отдельности, выполняя минимально достаточный набор проверок, чтобы убедиться, что эта функция в изоляции работает без ошибок.

Что можно попробовать?
После того, как вы протестировали функцию отдельно, попробуйте попасть к ней разными путями. Например, начните взаимодействие с другого места в приложении и приходите к нужной функции по альтернативному маршруту. Это разновидность так называемого monkey testing — тестирования, при котором вы, словно «обезьяна за пишущей машинкой», случайным образом взаимодействуете с приложением и наблюдаете за результатами.

Тестировать быстро, или находить баги? Ищите баланс

Иногда тестирование ощущается как бег наперегонки в шлёпанцах — хочется бежать быстро, но в итоге падаешь лицом вперёд.

Скорость — это хорошо (нужно же успеть выучить все тест-примочки), но спешка может привести к тому, что вы пропустите даже самые очевидные баги.

Слабое место: вы стараетесь не отставать от темпов разработки, но при этом не обсуждаете с командой, что вам нужно как тестировщику. В результате вы жертвуете качеством своих тест-планов. А молчание здесь — не золото.

Что можно попробовать?
Посмотрите, как можно улучшить ваши тест-планы и сколько времени займёт выполнение новых тест-кейсов. Затем обсудите с разработчиками и продакт-менеджером, как можно заложить в график немного дополнительного времени специально на тестирование.

Создание правильного продукта — задача всей команды
Будьте добры к себе (и к продукту): делайте перерывы

Допустим, у вас жёсткий дедлайн, и вы боитесь не использовать всё доступное время. Поэтому вы тестируете, тестируете… и ещё раз тестируете.

Чувствуете усталость? Слишком много задач? Постоянно переключаетесь между тестами и задачами?

Слабое место: вы тестировали без остановки — или вам так казалось. Вы чувствовали усталость и раздражение. А потом оказалось, что 50% фич в продакшене — с багами.

Что можно попробовать?
Делайте короткий перерыв после каждого теста. Это поможет снизить усталость и уменьшить влияние когнитивных искажений (да, у тестировщиков они тоже есть!).

Определите, в какое время дня вы наиболее креативны. Утро? Поздний вечер после чая? Используйте эти «пиковые» моменты — именно тогда вы с наибольшей вероятностью найдёте баги.

P.S. Это, пожалуй, самый трудный для реализации совет— но он может принести отличные результаты. Помните: если вы устали, вы не заметите баги. Лучше сделать перерыв и продолжить с новыми силами.

Ходите в (когнитивный) спортзал: решайте головоломки
Звучит глупо, знаю. Но держать разум открытым к новому — полезно.

Когда вы начинаете тестировать продукт, спустя месяц всё начинает казаться скучным и рутинным. Новых фич нет, а баги — баги всё ещё просачиваются в прод.

Слабое место: вы застряли в рутине, и мозг перестал замечать новое.

Что можно попробовать?
Решение головоломок помогает сохранять гибкость мышления. Если вы не умеете иногда мыслить «вне коробки» — как тестировщик вы обречены.

Вот пара моих любимых сайтов с задачками:

• blackboxpuzzles
• testingchallenge

Наша память подводит нас! Используйте чек-листы
Играли в GTA: Vice City? Если да, то наверняка у вас был лист с чит-кодами.

Почему вы его делали, если и так знали коды? Потому что так у вас был к ним мгновенный доступ — не нужно было держать все в голове.

То же самое работает и в тестировании. Неважно, используете ли вы Jira, автотесты или классические тест-кейсы.

Слабое место: во время новой задачи мы не всегда можем вспомнить всё необходимое.

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

Подводим итоги
Иногда, чтобы найти скрытые проблемы, достаточно сделать что-то нестандартное ещё до начала тестирования. Это как заглянуть под диван в поисках потерянной игрушки.

Использование лайфхаков тестирования может помочь выйти за рамки подготовленного тест-плана и найти критические баги. Такие быстрые фишки могут настолько улучшить ваше тестирование, что вы сами начнёте бросать себе вызов: скажем, «найти баг за первые 10 минут тестирования».

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