Многие считают, что тестирование ПО — это поиск ошибок.

Source: Тестирование — это не поиск ошибок!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Но в долгосрочной перспективе всё не так радужно:

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

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

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

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

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

Что они дают:

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

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

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

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

ВСЕГДА есть что улучшать, и отсутствие непрерывного процесса совершенствования — неизбежное болото.

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

Многие считают, что у тестирования есть какие-то мифические цели. И что они всегда одинаковы.

Как бы не так!

В каждом проекте, компании, команде цели свои собственные. Все ли их понимают одинаково? Проговаривали ли вы их вслух?

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

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

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

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

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

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

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

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

Выводы

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

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

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

* * *

Source: Чек-листы — один из фундаментальных инструментов тестирования. Они позволяют не забывать о важных тестах, фиксировать результаты своей работы и отслеживать статистику о статусе программного продукта. Дальше

Иногда чек-листами называют подробные инструкции о тестируемом продукте, содержащие последовательность действий, множество деталей и т.д. Это не так! Главный принцип чек-листов заключается в том, что каждый тестировщик по-своему проходит их, расширяя тестовый набор своей экспертизой. Какие преимущества чек-листов по сравнению с тест-кейсами:

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

При этом, чек-листы сохраняют множество плюсов, за которые так популярны детальные тест-кейсы:

  • статистика: кто, когда, что проходил (с детализацией по сборке продукта и окружению, на котором проводилось тестирование)
  • памятка, которая помогает не забыть важные тесты
  • возможность оценить состояние продукта, его готовность к выпуску

Конечно, было бы нечестно рассказать про плюсы и умолчать о минусах чек-листов:

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

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

Комментарии:

А чек-листы лучше составлять по каждому модулю, если система модульная. Это удобно. Можно прямо по репозиторию смотреть, изменили ли разработчики код модуля к текущему релизу. Если да, то, очевидно, нужно прогнать тесты этого чек-листа.
Ну и должен быть глобальный чек-лист, который проверяется для КАЖДОГО релиза. Там должен быть самый главный и важный функционал, который ни в коем случае не должен сломаться.

Тут еще частенько возникает проблема в том что народ иногда забывает про четыре Q и месит вме в одну кучу: Quality assurance, Quality Approval, Quality Control, Quality check. (Я даже не лезу в ITIL, там веселее).
В общем виде: обеспечение качества продукта (не только ПО) состоит в контроле производственного процесса (Quality assurance при производстве элементной базы должно контролировать даже уровень загрязнения воздуха в рабочих зонах, а при разработке ПО в эти процедуры как раз входит code review и сверка накарябанного кода с проектной документацией), проверке работоспособности полученного продукта (Quality Approval), Quality Control отлавливает недокументированный функционал типа нажатия 144 раза на вершний правый угол кнопки в IE 2.0 когда Луна в тротике Рака, и элементарная операция это Check (Quality Check), эта операция имеет свой номер и лицо ответственное за ее проведение, которое можно бить если в заданном чеке у клиента чтото вылезло.
Так вот… К чему это я. QA engineer — это лицо занимающееся инженерной деятельностью (в идеале), то есть планирование операций по Quality Assurance, Approval & Control для технического персонала, а технический персонал это либо tester, либо QA-tech.
Хотя это не идеал к сожалению. Введение адекватных процессов тестирования и отладки продукта в IT сфере это мечты :) Так как требуется адекватное начальство, адекватный HR, адекватные разрабы(как инженеры-планировщики, так и техники-кодеры) и адекватные тестеры(опять же как и постановщики-планировщики, так и эмуляторы клацательных скриптов). Одновременно все эти люди в одной компании резко работают :)

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

* * *

Не так давно на Хабре была статья про навороченный стартап, заточенный на сбор ошибок JavaScript. Далеко не всегда нужно столько возможностей, но оказалось, что многие просто не знают про старый бородатый способ с Google Analytics. Про него я и попытаюсь кратенько рассказать.

Первое, что вам нужно, это сам установленный Google Analytics (далее просто GA) на сайте, здесь всё стандартно и менять ничего не надо:

<script> var _gaq = _gaq || []; _gaq.push(['_setAccount', 'UA-XXXXXX']); _gaq.push(['_trackPageview']); (function() { var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true; ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js'; var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s); })(); </script> 

Далее, желательно ещё до подгрузки

каких-либоскриптов, т. е.в head, выше всех поставить следующее:

<script> var _gaq = window._gaq || []; window.onerror = function(msg, url, line) { var preventErrorAlert = true; _gaq.push(['_trackEvent', 'JS Error', msg, navigator.userAgent + ' -> ' + url + " : " + line]); return preventErrorAlert; }; </script> 

preventErrorAlert — возвращая true, мы предотвращаем появление раздражающего окна с ошибками в старых версиях IE и Opera.
msg — сообщение об ошибке.
url — файл скрипта в котором произошла ошибка.
line — на какой строчке произошла ошибка.
navigator.userAgent — простенькие данные браузера, чтобы понятно было где копать.

Практически все современные браузеры поддерживают onerror:

  • Chrome 13+
  • Firefox 6.0+
  • Internet Explorer 5.5+
  • Opera 11.60+
  • Safari 5.1+

Таким образом, можно смело собирать критические ошибки. Но ошибки бывают разные, если вы используете jQuery, то рекомендую добавить ещё следующий код, после её инициализации:

jQuery.error = function (message) { _gaq.push(['_trackEvent', 'jQuery Error', message, navigator.userAgent]); } 

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

Заходим в GA в наш проект, выбираем «Стандартные отчёты»:
image

В панели слева находим «Содержание» → «События» → «Обзор»:
image

Видим график событий и снизу справа сами типы событий:
image

Выбираем нужное нам событие «JS Error»:
image

Переходим в «Действие по событию»:
image

Выбираем интересующую нас ошибку и наблюдаем отладочную информацию. Уходить глубже смысла особого не имеет:
image

Зная, как работают события GA, где они находятся и как выглядят, вы без проблем сможете настроить тот вид отчётов об ошибках, который наиболее подходит под ваш проект.

Comments:

Я.Метрику тоже ведь можно использовать?
Просто я к метрике больше привык :)

Если вы сами пишите код, что вам мешает самостоятельно провести тестирование?
Пользуясь случаем, хочу дать ссылку на свой инструмент тестирования Suitest

Комментарии запрещены.