Home

Автор: Наталья Руколь

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

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

Что такое поиск ошибок?

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

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

Что будет, если я столкнусь со сложновоспроизводимым багом? ROI на его исследование считается в голове очень быстро. Зачем мне с ним возиться, если я за это же время смогу завести 3 менее критичных, зато простых в заведении?

Какие тесты я буду проводить в первую очередь? Конено, самые нестандартные. Ввести в поле логина «Войну и мир», поделить на ноль, вставить в профиль фотографию в формате .exe.
Скажу по секрету — иногда на собеседованиях тестировщики в ответ на просьбу «протеструйте калькулятор» перечисляют интересные и дельные тесты, но в числе первых тридцати нет теста «проверить сложение» и другие базовые операции.

Именно так выглядит поиск ошибок — не имеющий ничего общего с тестированием.

Что такое тестирование?

Я тестирую продукт. Моя задача — пропустить как можно меньше приоритетных для пользователя багов. Чем меньше багов пропущено, чем меньше недовольства клиентом выражено — тем выше я оцениваю эффективность своей работы.

Какие области я буду тестировать в этом случае? Естественно, я начну с самых приоритетных для пользователя. Даже если они стабильно и успешно работают, я всё равно буду проверять основные пользовательские сценарии, чтобы ни в коем случае не пропустить серьёзных проблем.

Что будет, если я столкнусь с трудностями? К примеру, со сложновоспроизводимым дефектом, или непониманием бизнес-процесса пользователя, или нехваткой требований? Если это важный функционал, то я буду выяснять «что не так», «как правильно». На заведение дефекта в итоге может уйти немало времени, и с точки зрения баг/время результат эффективности тестирования будет не очень высок, зато у меня появятся более глубокие знания о продукте, архитектуре, пользователях.

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

Результаты тестирования и поиска ошибок

В случае с поиском ошибок, в краткосрочной перспективе результаты выше: багов заводится больше и сразу.
Но в долгосрочной перспективе всё не так радужно:

• из-за отсутствия глубоких знаний о продукте, постепенно начинает расти % пропущенных дефектов
• команда разработки занята исправлением страшных-ужасных-немыслимых багов, полученных путём клика на одну и ту же кнопку 144 раза под IE в полнолуние
• в релиз попадают некоторые ужасно неприятные и очевидные для пользователя баги
• количество находимых ошибок в ДОЛГОСРОЧНОЙ перспективе падает

Как перейти от поиска ошибок к тестированию?

Чтобы тестирование было эффективным и полезным в долгосрочной перспективе, необходимо следовать простым правилам и использовать ключевые инструменты тестирования:

1. Анализ продукта и документирование тестов

Кликая на кнопки, можно завести много багов — но нельзя сказать, что было проверено. Единственное решение — документирование тестов. Подробные тест-кейсы, удручающие тестировщиков и отнимающие уйму времени, бывают нужны очень редко. А вот чек-листы с перечнем «что нужно проверить» — необходимы.
Что они дают:

• Вы анализируете продукт, выписываете основные фичи, действия, их параметры. Таким образом существенно снижается риск что-либо забыть.
• Чек-листы — отличная напоминалка «здесь надо вникнуть глубже». Есть какая-то невнятная фича с недостаточным описанием. Как её тестировать? В тестировании без тестов проще всего сказать «я вернусь к этому позже», и уже никогда не вернуться. А с тестами — у вас будет висеть тест, в котором непонятно как и что проверять, вы будете такие тесты видеть и не забудете необходимость выяснения.
• Чек-листы можно и НУЖНО согласовывать. С разработчиками, аналитиками. Вся команда включается в процесс тестирования, тестировщики узнают много нового о продукте, коллективный разум улучшает качество тестирования. И помимо однократного повышения качества отдельно взятого чек-листа, повышается качество тестирования в целом: тестировщики начинают больше учитывать в тестировании, развиваться, эти знания со временем окупаются в виде более результативного тестирования.

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

2. Оценка тестирования

Чтобы не быть слепыми котятами, необходимо оценивать эффективность тестирования. Анализировать пропущенные ошибки и причины их пропуска. Покрытие функционала и кода тестами. Уровень удовлетворения пользователей, через анкеты и сбор обратной связи. Качество заведения ошибок, опрашивая разработчиков.
ВСЕГДА есть что улучшать, и отсутствие непрерывного процесса совершенствования — неизбежное болото.

3. Обсуждение целей тестирования с командой

Многие считают, что у тестирования есть какие-то мифические цели. И что они всегда одинаковы.
Как бы не так!
В каждом проекте, компании, команде цели свои собственные. Все ли их понимают одинаково? Проговаривали ли вы их вслух?
Чтобы приносить максимум пользы, надо хорошо понимать, в чём эта самая польза заключается. И не удивляйтесь, если мнение РМов и разработчиков не будет соответствовать вашему. Надо не переубеждать их, а подстраиваться под текущие проектные цели!

4. Понимание пользователей и их бизнес-процессов

Для меня загадка, как это возможно, но тем не менее это факт: зачастую тестировщики проверяют продукт, ничего не зная о пользователе.

• Как этот продукт используется?
• Зачем он вообще нужен, какие проблемы решает?
• Какая средняя квалификация у пользователей?
• В каких условиях работают пользователи? На каких окружениях, оборудовании?

Не надо догадок и додумок про «в среднем про отрасли»! Тестировщики должны ИДЕАЛЬНО знать СВОИХ пользователей. Часто им эту информацию не предоставляют аналитики. Одумайтесь! Не зная пользователя, тестировать продукт по-нормальному невозможно.

5. Техническая квалификация и понимание архитектуры

Для иллюстрации приведу баг, который на меня недавно завели в баг-трекере:
Зайти на сайт тестируемого продукта http://****.ru в браузере Firefox
Ввести логин и пароль
Зайти с того же компьютера в браузере Opera
Просит повторно ввести логин и пароль, автоматически не логинится.

Такие баги не просто бесполезны, они позорят тестировщиков и дискредетируют отрасль в целом! Чтобы заводить дефекты правильно, необходимо понимать платформу, на которой написан тестируемый продукт. Если мы говорим про веб-тестирование, то можно хотя бы указать в баг-репорте возвращаемый сервером код ошибки, посмотреть подробности файрбагом, предоставить подробную информацию и сэкономить разработке массу времени!

Выводы

Очень многие разработчики не любят тестировщиков. И правильно делают!

Зато хороших тестировщиков любят и ценят все. Но тестировщиков, а не кликеров и багозаводильцев!

Учитесь узнавать, что не так, что не нравится другим участникам команды разработки. Обязательно исследуйте пропущенные ошибки и делайте всё для того, чтобы больше их не пропускать. Не гонитесь за заведением багов — вашей мантрой должны быть «счастье пользователя», «качественный продукт» и «успешный проект», а не «завести как можно больше багов» — ОЧЕНЬ часто эти 2 цели оказываются слишком далеки друг от друга.

И да пребудет с вами сила!

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