Джеймс Бах и Майкл Болтон периодически пишут и рассказывают о такой штуе, как Test Framing (а вот здесь есть перевод оригинальной статьи). В рамках этой модели они предлагают всегда держать в голове множество ключевых факторов, влияющих на тестирование (среда, продукт, цели, риски и т.д.). В описанном Майклом Болтоном формате мне такой подход показался очень правильным, но при этом слишком сложным. Методом проб и ошибок я выработала более простую схему для фрейминга тестирования, которая не путает своей сложностью, и при этом добавляет осознанности в тестирование. Read more
Архив метки: процессы тестирования
Subject:
Сила в процессе, брат!
Я часто слышу слова «процесс», «строить процесс», «улучшать процесс» и т.д.
А что это такое? Зачем это нужно? Как это делать?
Давайте разбирать поэтапно. Read more
Subject:
Тестирование – это решение чужих проблем
Жила-была компания, разрабатывавшая программные продукты. И были в ней тестировщики. И тестировали они денно и нощно, а продукт был отстойным. То они какое-то требование пропустят и не заметят, а пользователь жалуется, и тестировщики виноваты: надо внимательнее требования читать. То багу критичную, возникшую за 2 часа до релиза, не найдут, и снова это их вина: тестировать надо больше. Пользователь не доволен даже реализованными требованиями: а почему вы их не протестировали? Продукт работает медленно в окружении заказчика: а почему вы это не выявили? Выпущенные ошибки беспокоят пользователя: а почему вы не донесли достаточно внятно информацию об их критичности? Долго команда и тестировщики так и сосуществовали. И всем, даже тестировщикам, казалось такое положение вещей правильным. Они всё время работали над собой, ища, как они могут решить ту или иную проблему. Потому, что считали такие проблемы СВОИМИ. Но как-то раз древний мудрец по разработке ПО проходил мимо их офиса. Заглянул он к ним, увидел происходящее, и заявил: “Ребята, вы, конечно молодцы… Но вы решаете чужие проблемы!”. “Как так?”, – удивились тестировщики. “А вот так», – ответил мудрец, – “давайте я покажу, как это работает в более зрелых компаниях”. И вместе с ними нарисовал примерно следующую табличку:
| Проблема | Как её решать правильно | Как её могут компенсировать тестировщики |
| Недостаточно хорошо выявляются требования | На проекте обязательно должна быть роль бизнес-аналитика, который общается с пользователями, анализирует целевую аудиторию, и прорабатывает наилучшие способы решения пользовательских задач. | Тестировщики могут тестировать требования, и, не имея достаточного контакта с пользователями, придумывать, что в этих требованиях не так, и как это можно улучшить. |
| Недостаточно точно фиксируются требования, в результате чего их тяжело понимать разработчикам и тестировщикам | Ввести управление требованиями в соответствие с ключевыми критериями хороших требований: атомарностью, трассируемостью, измеримостью и т.д. В этом случае прямо по требованиям можно помечать их статус готовности и качество их работы. | Ходить по всей команде и выяснять, что и как должно правильно работать. Создавать чек-листы, чтобы нивелировать риски пропуска функционала в тестировании. Поддерживать в актуальном состоянии тестовую документацию, чтобы обрабатывать изменения в ПО. |
| Сборки часто плохого качества, в них много ошибок | Внедрить юнит-тесты и TDD, ревью кода. Контролировать стабильность каждой сборки на уровне разработки. | Тестировать 100500 раз одно и то же, проверяя, что ничего не сломалось. Максимально сокращать сроки тестирования за счёт автоматизации. |
| Продукт сложно поддаётся системной (высокоуровневой) автоматизации | Заложить тестируемость на уровне архитектуры продукта. Предоставлять стабильные интерфейсы для автоматизированного тестирования. | Писать плоход в плохотестах, разрабатывать множество костылей, делать неэффективные автотесты и тратить на них уйму своих ресурсов. Разрабатывать модульные и юнит-тесты за разработчиков, у которых нет на это времени, а интерфейсные тесты кликать мышкой. |
| Маленькое тестовое покрытие, нехватка комбинаторных тестов и тестов на нестандартные ситуации | Глубокое юнит-тестирование. Совместное обсуждение архитектуры продукта тестировщиками и разработчиками для понимания необходимости тех или иных тестов. | Фигачить больше тестов, в надежде, что какие-то из них окажутся полезными. Повторять их запуски многократно. Расширять команду тестирования за счёт студентов. |
| Большая длительность релизного цикла, медленная разработка | Чистый код и грамотный техлид, внедряющий инженерные практики. Совместная командная работа над качеством. | Быстрее тестировать. Раньше находить ошибки. Расширять команду. Приоритизировать тесты и отбрасывать всё на что не хватает времени, зажав кулачки “лишь бы это не оказалось важным”. |
Тестировщики смотрели на табличку, которая получилась у мудреца, и удивлялись. — Но если в нашем процессе всё будет, как ты предложил в колонке с “правильным” решением, то мы будем не нужны? — Будете, – ответил мудрец. – Но вы не будете выполнять мартышечий и бессмысленный, малоэффективный труд. Вы сможете больше внимания уделять исследовательскому тестированию нового функционала, разработке грамотных и стабильных автотестов, и внедрению метрик и практик качества. — Но ведь такого “хорошего” процесса не бывает! Это же миф! — Хи-хи, – улыбнулся мудрец. — Я видел такие компании. Я знаю, какой тяжёлый путь они прошли, и эти сложности были связаны в основном с кашей в головах участников процесса, а не с реальными проблемами. В этих компаниях работать приятно, а продукты вызывают гордость команды. — Но как нам найти такую компанию? — Не надо искать. Сделайте это в своей компании! Да, вы просто тестировщики. Но вы и так уже достаточно давно занимаетесь тем, что решаете ЧУЖИЕ проблемы. Так начните их решать правильно! Промойте мозги своему начальнику, покажите ему эту статью. Отправьте его на конференцию, пусть отвлечётся от своей псевдополезной деятельности. Выявите, какая проблема у вас самая сильная – и предложите её решения, познакомьтесь с правильными действиями в этой ситуации, и начните это внедрять сами. Иначе вы так навсегда и останетесь козлами отпущения, виноватыми за чужие проблемы – и ни капельки не влияющими на качество продукта!
Subject:
Грустная сказка о тестировщике, которая не скажу как закончилась
Жил да был один тестировщик, и звали его не скажу как, а тестировал он сайт покупки билетов, который назывался http://censoredsite.ru.
Он был грамотным опытным тестировщиком, хорошо разбирался в продукте, отлично заводил ошибки, разрабатывал грамотные приёмочные автотесты, дружил с разработчиками и аналитиками.
Как-то раз к нему пришёл тест-менеджер, и сказал: «Нескажукак! Тебе надо писать тесты, чтобы точно описать, что именно нужно проверить, и не пропускать их».
Нескажукак был в шоке. Он хорошо выполнял свою работу, зачем ему эта лишняя бюрократия?
Тест-менеджер, далёкий от жизни нормальных тестировщиков, начал выдумывать всякие странности:
- шаблон тестов
- шаблон отчёта о результатах прохождения
- метрики покрытия, проверявшие наличие тестов на каждый элемент формы, каждое действие в системе и т.д.
Нескажукак был на грани истерики: «Нам нужно работать, а не все эти ваши дурацкие тесты писать!»
Он уже начал искать другую работу, но т.к. заставляли, тесты начал писать. Использовал шаблон, предоставленный ТМом, описывал стандартные проверки для каждого поля.
А потом началось тестирование. Он проверял как любил, он был в потоке, баги сыпались рекой, и все были счастливы. Когда ошибки были исправлены, он ответил «ДА» на священный вопрос: он сказал «да, можно выпускать наш продукт пользователям!».
А потом был релиз. И были пользователи, которые пытались использовать censoredsite. В первый день в техподдержку обратилось 40 человек из 200 посетителей. Оказалось, что при смене адреса после сохранения, неправильно отображались реквизиты. А при вводе слишком длинного емейла, падал весь сайт. И время в одном из полей, о существовании которого Нескажукак даже не знал, отображалось не в правильной часовой зоне…
Все эти ошибки казались сущими пустяками! Но руководство было в ярости, клиенты в шоке, пользователи недовольны.
К депрессирующему Нескажукаку пришёл тест-менеджер. И открыл список тестов. И нашёл там все эти мелкие проверки, которые казались такими неважными, потому и были пропущены.
Для начала, они вместе выпили. И только после этого тестировщик смог признаться: да, поток — это хорошо. Творчество в работе — тоже. Но нужно ещё что-то!
Что?
Subject:
QA (Quality Assurance) на конкретном примере
Примерно 3 года назад (ой-ёй, как давно-то!) я написала статью про разницу между тестировщиками, QC и QA.
А теперь хочу на примере конкретной вакансии рассказать про самого настоящего QA и задачи, которые решают такие самураи. Read more
Subject:
Ода скриптовому тестированию
Последнее время тестирование по заранее написанным тестам (назовём такое тестирование скриптовым) выходит из моды. У противников скриптового тестирования много аргументов, хотя в большую часть из них я, увы, не верю. В этой статье я хочу рассказать о своём взгляде на скриптовое тестирование и его существенных плюсах. Вполне вероятно, что эти плюсы окажутся вам незакомыми. Не потому, что подход неправильный! Возможно, вы просто сталкивались с его неудачной реализацией? Для этого вторая часть статьи: о том, как внедрять скриптовое тестирование наиболее эффективно. Read more