Джеймс Уиттакер. Как тестируют в Google
Основные мысли, краткий конспект.
Кто занимается тестированием?
Разработчик - пишет юнит-тесты, проводит код-ревью
Разработчик в тестировании - обеспечивает инфраструктуру для тестирования, помогает разработчику тестировать код. При необходимости может редактировать код программы. Анализирует архитектуру, уделяя особое внимание рискам проекта
Инженер по тестированию - занимается организацией работы по тестированию. Пишет код автотестов, управляет выполнением тестов и интерпретирует их результаты. Максимально ориентирован на пользователей продукта.
В чем особенность тестов?
Вместо того, чтобы разделять тестирование на модульное, интеграционное и системное, все тесты делятся на малые, средние и большие.
Малые тесты проверяют код 1 функции или модуля, чаще всего автоматизируются.
Средние тесты покрывают 2 или больше функции. Фокусируются на том, чтобы проверить взаимодействие между функциями, которые вызывают друг друга или контактируют напрямую (“ближайшие соседи”).
Большие тесты задействуют 3 и более функции и близки к реальным пользовательским сценариям.
Каждый тест должен быть независим от других, чтобы тесты могли выполняться в любом порядке.
После завершения теста среда должна возвращаться в то же состояние, в котором она находилась при запуске.
Некоторые команды предпочитают более общие пользовательские истории частным тест-кейсам. Слишком конкретные тест-кейсы, выполняемые тестировщиком многократно, вызывают скуку, в то время как пользовательские истории дают больше свободы действий.
Тест, который обнаружил баг, становится частью регрессионного пакета и автоматизируется, чтобы было проще ловить регрессионные баги.
Тестирование проводится в порядке уменьшения рисков. Если не можешь протестировать все - протестируй сначала самое важное. Самое важное - это то, что больше всего подвержено самым серьезным рискам.
Какие требования предъявляются к сотрудникам от тестирования?
Тестировщики должны уметь программировать. С одной стороны, он обладает техническими навыками, а с другой - умеет фокусироваться на потребностях пользователя.
Работа тестировщика в проекте начинается с вопросов, связанных с выявлением рисков при выпуске продукта.:
- где у продукта слабые места?
- есть ли проблемы с безопасностью, конфиденциальностью, производительностью, надежностью, пригодностью использования, совместимостью?
- работают ли первичные пользовательские сценарии?
хорошо ли работают средства диагностики проблем?
В чем должен разбираться тестировщик:
- планирование тестирования и анализ рисков
- анализ документации
- исследовательское тестирование
- пользовательские сценарии
- разработка и выполнение тест-кейсов
- работа с обратной связью от пользователей.
Какие задачи выполняют сотрудники от тестирования?
Тест-менеджер координирует работу тестировщиков и разработчиков в тестировании.
Он должен знать свой продукт и быть готовым ответить на любые вопросы по его использованию. Он должен знать своих людей и их навыки, чтобы работа выполнялась эффективно.
Инженер должен влиять на работу команды, а его работа должна влиять на продукт. Решения о повышении основываются на том, какое влияние специалист оказал на проект. Управлять влиянием команд тестировщиков и разработчиков в тестировании - работа тест-менеджера.
Каковы особенности тест-дизайна?
Тест-план составляется на основе АСС-анализа
А (атрибуты) - это качества и характеристики, которые продвигают продукт и отличают его на рынке.
С (components, компоненты) - элементы, из которых построена система.
С (capabilities, возможности) - это действия системы, которые она выполняет под руководством пользователя. Лежат на пересечении атрибутов и компонентов.
Компоненты выполняют какую-то функцию, чтобы соответствовать атрибуту продукта, а результатом станет предоставление пользователю возможности.
Основные принципы АСС-анализа:
- меньше воды и неважных подробностей
- движение от общего к частному. Каждый раздел плана должен расширять предыдущий, чтобы у читателя оставалась общая картина в голове.
- движение от высокоуровневых концепций к низкоуровневым деталям.
- итог - создание тест-кейсов. Если план нн приводит к созданию тест-кейсов, то время потрачено зря.
Best-practice
Из интервью Линдси Уэбстер - инженера по тестированию Google Docs
Приступая к проекту, я смотрю на него глазами пользователя . Если возможно, то начинаю им пользоваться. Если есть проектная документация, то изучаю ее. Далее изучаю состояние качества проекта.
Обычно я разбиваю приложение на функциональные куски, чтобы создать не слишком подробную, но и не слишком общую картину компонентов. После этого я могу их приоритезировать.
Далее создаю для каждого компонента пользовательскую историю и связанные с ней тест-кейсы. Как только есть список тест-кейсов, ищу пробелы в покрытии. После этого стараюсь поддерживать тесты в актуальном состоянии.
С самого начала я стараюсь стать пользователем тестируемого продукта.
Я открыто отмечаю те области, которые не собираюсь тестировать и обосновываю, почему.
“Починялки” - элемент культуры Google. Это мероприятие собирает людей для починки чего-то, что работает неправильно или сломано. Цель встречи не ограничивается технической областью, и “починялки” могут проводиться для улучшения качества блюд в кафе или схемы проведения собраний. По сути, это любое мероприятие, на котором люди собираются для решения общей проблемы.
Ценные мысли
Не нужно делать то, что не принесет ценности.
Пусть машина выполнить 90% работы, а человеческие ресурсы мы подключим только на последних 10% цикла проверки, которые мы называем “последней милей”. Человеческий разум слишком ценен, чтобы тратить его на то, с чем справится компьютер. Оставьте однообразные задачи машинам, человек нам еще пригодится.
Тестировщики часто ставят артефакты тестирования выше самого продукта. Ценность тестирования - в действиях, а не в артефактах.
