Home

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

Страшный сон любого ответственного тестировщика – пропуск ошибки. Вы стараетесь-стараетесь, проверяете продукт, тестируете его по 8+ часов ежедневно, а после выпуска пользователь в течение недели сообщает о критичной проблеме. Как такое может быть, почему и как исправить?

Вариант 1: Какой-либо влияющий фактор на работу нашего ПО был нам неизвестен.

В нашем продукте есть красивая формочка, заливающая файлы на сервер. Мы её протестировали с разными типами файлов, разными названиями файлов, разными размерами файлов. Всё успешно работало. После выпуска продукта оказалось, что 80% пользователей не могут залить свои файлы! Оказалось, что файлы успешно заливаются только с локального диска, но не загружаются с флешек, а пользователи в основном используют продукт именно с такими файлами.

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

Рецепт:

• Перед началом тестирования тщательно обдумываем: какие факторы могут влиять? Для удобства структуризации, анализируйте такие факторы применительно к каждому действию, которое выполняет ваш продукт
• Общайтесь с разработчиками! Узнавайте у них, что может влиять на работу продукта?
• Показывайте свои результаты исследований (табличками, майнд-картами, чек-листами) разработчикам, аналитикам, архитекторам. Кто чем может дополнить?
• Старайтесь узнать максимум о своих пользователях. Если сами с ними не общаетесь – узнавайте у внедренцев, бизнес-аналитиков, техподдержки. Кто, как, в каких условиях использует продукт? Эта информация может привнести новые идеи в тестирование.

Вариант 2: Не учли все возможные комбинации

На этот раз наш продукт – онлайн-магазин. После выпуска продукта многие пользователи жалуются, что не добавляются товары в корзину. Чуть позднее мы выясняем, что не добавляется определённый тип товаров, однако сами воспроизвести проблему не можем. Ещё позже выясняем, что они не добавляются только если добавлять несколько товаров одновременно. Недоумеваем. Другие типы товаров по нескольку сразу добавляются. Этот тип по одной штуке добавляется. А этот тип по нескольку сразу не хочет!

Диагноз: непроверенные комбинации. Чаще всего нам недостаточно проверить все влияющие факторы, опции продукта – нам надо проверить комбинацию их использования!

Рецепт:

• Выясняйте, какие проверки являются взаимосвязанными. Чаще всего для этого необходимо знание архитектуры продукта, а с этой информацией смогут помочь разработчики или тестирование белого ящика
• Используйте различные методы комбинирования проверок, описанных в библии тест-аналитка Ли Копланда
• Из комбинаторных методов уделите особое внимание pairwise, особенно в случае когда «что с чем связано?» неизвестно

Вариант 3: Не хватило времени на тестирование

Если честно, я не сталкивалась с такой ситуацией когда на тестирование достаточно времени. Поэтому сжатые временные рамки необходимо считать данностью, а не причиной для пропуска критичных дефектов. Давайте рассмотрим по отдельности два основных сценария нехватки времени:

3-1: Сборка – протестировали – нашли критичные дефекты – новая сборка – протестировали – критичные дефекты – новая сборка – времени на тестирование ноль, критичных дефектов не успели найти – выпустили – упс…

Решение:

• В спешке очень сложно выделять самое важное, поэтому тесты, которые необходимо проверять на RC (Release Candidate, сборка-кандидат на релиз) необходимо определить заранее, выделить в них наиболее критичные проверки
• Договариваться с руководством. Заранее обсуждать срок тестирования RC. День, два, неделя – срок зависит от размера продукта. Но этот срок должен быть чётко известен и всем понятен, иначе разработчики и РМ будут надеяться на «авось»
• Автоматизация. Самые-самые важные для релиза тесты – одни из самых актуальных с точки зрения автоматизации. Роботы быстрее человека!

3-2: В каждую новую сборку включается новый функционал, тестируем только его, на регрессионное тестирование физически нет ресурсов, всё время занято на проверку нового функционала. С вероятностью в 99%+ после релиза всплывут ошибки, которые были внесены в смежные области при добавлении нового функционала.

Решение:

• Автоматизация регрессионного тестирования
• Оптимизируем тестовые наборы. Используем подходы тест-анализа с минимальным набором проверок (максимум проверок в одном тесте, pairwise и т.д.). Успеваем проводить регрессионное тестирование за счёт небольших затрат.
• Ведём проектные риски качества. Документируем потенциальные проблемы, расцениваем исходя из нашего опыта их вероятность и критичность. Ведём риски аккуратненько, красивенько. Показываем руководству табличку и объясняем, какие большие проблемы нас ждут если не выделить ещё ресурсов на тестирование.

Вариант 4: Не заметили, упс…

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

4-1: Не заметили!! Да-да, может звучать странно, однако происходит очень часто. Простые невнимательность и отвлечённость приводят к тому, что, несмотря на ответственность и стремление ничего не пропустить, баг всё равно от нас прячется.

Решение: Развивать внимательность! В интернете есть интерактивные упражнялки, да и в реальной жизни можно неприрывно тренироваться. Высматривайте все круглые, или жёлтые, или высокие предметы. Когда едете в общественном транспорте, считайте количество чего-нибудь: шарфов, телефонов, ремней. Выйдя из автобуса, постарайтесь вспомнить что-нибудь, что вы НЕ считали. Внимательность – это навык, и его можно развивать!

4-2: Не знали, что это баг. Чаще всего такое происходит в недостаточно документированных областях функционала. А в каких областях функционала обычно меньше всего требований? Либо в самых сложных (и многие вещи непонятны, оттого и не документируются), либо самых очевидных (которые понятны только в случае, если вы хорошо понимаете специфику работы своих пользователей).

Решение:

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

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

Выводы

• Какие-то баги будут пропущены ВСЕГДА, и это нормально. Но пожалуйста, только не критичные!!! Приоритезируйте тестирование, не отвлекайтесь на третьесортные фичи, всегда отслеживайте ГЛАВНОЕ.
• Анализируйте причины пропуска дефектов. Каждый промах – информация к размышлению: «Как мы можем улучшить наш процесс таким образом, чтобы такое больше не повторялось?». Подходите ко всем проблемам конструктивно.
• Постарайтесь не использовать какие-то решения просто потому что «так привыкли». Спрашивайте себя КАЖДЫЙ ДЕНЬ: «Я точно использую самые лучшие инструменты, техники, подходы для решения своих задач? Что я могу улучшить СЕГОДНЯ?»

И главное – радуйтесь своей работе, тогда и результаты будут отличными

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