Предположим, что вы — создатель продукта — изучили целевую аудиторию, наняли опытную команду разработчиков и аналитиков, заняли долю рынка, маркетологи привлекают партнеров, менеджеры по работе с клиентами обстоятельно консультируют, вы регулярно запускаете рекламные акции.
Казалось бы, у вас есть всё. Но платежи пользователей и аудитория стали сокращаться, а заказчики — отказываться от продукта.
Возможно, дело в производстве? Загляните внутрь и, быть может, вы увидите, как:
И, даже выявив проблемы на этом этапе, не всегда возможно понять, как отрегулировать процесс целиком, ведь зачастую каждый элемент цепи в отдельности выполняет свою работу хорошо, а конечный результат не радует. Подумайте, возможно, пришло время нанять тестировщиков?
Тестировать может каждый участник команды. Согласно Agile-принципам эту деятельность официально выполняют все, не только тестировщики. Аналитики лучше других знают, какие функции ожидает заказчик, и как они должны работать. Юнит-тесты, ревью кода, парное программирование и обычные самопроверки разработчика обеспечивают качество кода. Но есть случаи, когда этого тестирования становится недостаточно для конечного качества. В этот момент на «сцену» приходит независимое тестирование.
Тестирование, выполняемое самостоятельной профессиональной группой, называется независимым. Чем меньше команда влияет на проводимые тестировщиками процедуры и выводы, тем более оно независимое. Б. Бейзер в работе «Тестирование черного ящика» писал: «Цель независимого тестирования — взглянуть на продукт с другой точки зрения, а следовательно, выполнить другие тесты; таким образом, выполняется более разностороннее тестирование, чем если бы тестированием занимались только разработчики».
Профессиональное тестирование начинается с тест-анализа и дизайна тестов:
Необходимость в профессиональном независимом тестировании возникает при следующих условиях:
Успех продукта в конкурентной борьбе — отличное событие, а также неожиданная нагрузка на производство. Новые пользователи, новые требования, масштабные изменения вынуждают команду выполнять больше задач в меньшие сроки. В итоге у команды не остаётся времени на тестирование либо интуитивное тестирование (Ad-hoc testing) пропускает критичные дефекты.
Тестирование развивается параллельно с другими областями знаний производства ПО.
Подходы и методологии не так изменчивы, последнее новшество в области тест-дизайна было опубликовано в 2009 году, Джеймсом А. Уиттакером в книге «Exploratory Software Testing». Тем временем новые инструменты для проведения тестирования разрабатывают непрерывно, среди них:
Профессиональные тестировщики улучшают и ускоряют тестирование с помощью актуальных техник и инструментов, уделяют особое внимание поиску эффективных решений, позволяя при этом команде сосредоточиться на модернизации бизнес-процессов.
Программный продукт-долгожитель говорит о стабильности бизнеса. С другой стороны, в течение нескольких лет продукт адаптировался под рынок, заказчиков, пользователей, накапливал разнообразный функционал, в том числе логически противоречивый. Статистика HR-портала показывает, естественный уровень текучести персонала в IT — 8-10% в год, значит за 5 лет команда разработки может обновиться почти на половину. За время жизни продукта в команде может поменяться архитектор и ключевые разработчики, люди, знавшие изначальную архитектуру и логику ее масштабирования.
По мнению Ф. Брукса в работе «Мифический человеко-месяц», любая система стремится к разрушению структуры и увеличению энтропии с каждым новым исправлением. Со временем продукт обрастает так называемым legacy-кодом, унаследованным от несовместимого функционала, быстрого багфикса, неопытного разработчика. Вместе с тем под давлением сроков команда не всегда успевает покрывать код юнит-тестами. В таких условиях невозможно предсказать, на какие участки кода повлияет то или иное исправление и какой дефект породит.
Профессиональные тестировщики проверяют не только новые функции, но и регресс всей системы. Содержание и способ проведения регрессионного тестирования — предмет отдельного фокуса.
Хорошо, когда продукт получает новые когорты пользователей, масштабируется на города и страны, специализирует функционал для разных ролей, адаптируется под время жизни пользователей в системе. С позиции системы это увеличивает количество критически важного функционала и способы его использования. Одна и та же функция может использоваться в разных целях и в различных условиях когортами пользователей. В большой сложной системе ролей и условий так много, что аналитик может забыть про одну из них во время разработки требований. На деле killer-feature для одной роли может стать блокирующим дефектом для другой, не менее значимой.
Профессиональное тестирование проверяет использование системы на соответствие целям пользователей, задает уточняющие вопросы, корректирует содержание регрессионного тестирования в соответствии с новыми приоритетами и бизнес-задачами системы. Актуализация набора и приоритетов тестов — предмет отдельного внимания тестировщика.
IT-среда сегодня предоставляет бесконечные возможности выбора, микро-сервисная архитектура, облачные дата-центры, распределенные проектные команды. Цельные продукты, с точки зрения пользователя, на деле расщепляются на микро-приложения, написаны на разных языках разработки, размещены на разных континентах, созданы разными проектными командами и компаниями.
К примеру, покупка безделушки в интернет-магазине, с одной стороны, действие из нескольких кликов, с другой — обработка и передача данных, по крайней мере, в трех приложениях — на веб-сайте магазина, в платежном шлюзе и платежной системе. Каждое приложение разрабатывает проектная команда со своими целями, оргструктурой, планами.
В этих условиях вероятен результат «пуля вылетела, проблема на вашей стороне»: когда каждая команда разработала свою часть в соответствии с требованиями, но вместе они не складываются в рабочую функцию.
Профессиональные тестировщики перед сдачей в эксплуатацию консультируют, курируют, выполняют настройку сред для прогона интеграционного тестирования, выполняют проверки с позиции конечного пользователя, а не только требований к отдельным компонентам.
Таким образом, крупные, возрастные, востребованные, стремительно изменяющиеся продукты обязывают тестирование быть отдельным родом деятельности. Эффективное тестирование вооружено специализированными методологиями, инструментами и конкретной целью, отличной от целей остальной команды. Цель аналитика — выяснить реальные потребности заказчика, цель разработчика — выполнить доставку заказанных изменений в полном объеме, цель тестировщика — испытать систему целиком, изучить пользователя и столкнуться с дефектами вместо него.
Делегирование тестирования отдельной роли под управлением команды — второй шаг к независимому тестированию. Тестировщиков можно нанять самостоятельно или воспользоваться аутсорсингом тестирования в независимой организации.
От аутсорсинг-тестирования на этом шаге компания получает:
Компании, занимающиеся аутсорсинг-тестированием, работают на репутацию: она тем выше, чем качественней предоставляемая услуга. Как обстоят дела с тестированием в вашей компании? Делитесь опытом :)
Казалось бы, у вас есть всё. Но платежи пользователей и аудитория стали сокращаться, а заказчики — отказываться от продукта.
Возможно, дело в производстве? Загляните внутрь и, быть может, вы увидите, как:
- хотфиксы выходят чаще, чем релизы;
- или служба поддержки завалена запросами и непрерывно разбирает критичные дефекты;
- или значимые когорты пользователей не могут получить ключевые функции сервиса.
И, даже выявив проблемы на этом этапе, не всегда возможно понять, как отрегулировать процесс целиком, ведь зачастую каждый элемент цепи в отдельности выполняет свою работу хорошо, а конечный результат не радует. Подумайте, возможно, пришло время нанять тестировщиков?
***
Тестировать может каждый участник команды. Согласно Agile-принципам эту деятельность официально выполняют все, не только тестировщики. Аналитики лучше других знают, какие функции ожидает заказчик, и как они должны работать. Юнит-тесты, ревью кода, парное программирование и обычные самопроверки разработчика обеспечивают качество кода. Но есть случаи, когда этого тестирования становится недостаточно для конечного качества. В этот момент на «сцену» приходит независимое тестирование.
Тестирование, выполняемое самостоятельной профессиональной группой, называется независимым. Чем меньше команда влияет на проводимые тестировщиками процедуры и выводы, тем более оно независимое. Б. Бейзер в работе «Тестирование черного ящика» писал: «Цель независимого тестирования — взглянуть на продукт с другой точки зрения, а следовательно, выполнить другие тесты; таким образом, выполняется более разностороннее тестирование, чем если бы тестированием занимались только разработчики».
Профессиональное тестирование начинается с тест-анализа и дизайна тестов:
- отбор минимального набора проверок, чтобы убедиться в работе максимального количества функционала;
- установка очередности прогона тестов в соответствии с критичностью функционала и рисками выпуска дефектов.
Необходимость в профессиональном независимом тестировании возникает при следующих условиях:
1. Стремительный рост
Успех продукта в конкурентной борьбе — отличное событие, а также неожиданная нагрузка на производство. Новые пользователи, новые требования, масштабные изменения вынуждают команду выполнять больше задач в меньшие сроки. В итоге у команды не остаётся времени на тестирование либо интуитивное тестирование (Ad-hoc testing) пропускает критичные дефекты.
Тестирование развивается параллельно с другими областями знаний производства ПО.
Подходы и методологии не так изменчивы, последнее новшество в области тест-дизайна было опубликовано в 2009 году, Джеймсом А. Уиттакером в книге «Exploratory Software Testing». Тем временем новые инструменты для проведения тестирования разрабатывают непрерывно, среди них:
- Инструменты для быстрой проверки верстки на разных браузерах и девайсах, сверки с макетами, проверки орфографии, времени отклика страницы и т. д.;
- Инструменты для выполнения, перенаправления, изменения, декодирования, отслеживания API-запросов;
- Инструменты для подготовки тестовых данных и условий в web, desktop, mobile, api приложениях.
Профессиональные тестировщики улучшают и ускоряют тестирование с помощью актуальных техник и инструментов, уделяют особое внимание поиску эффективных решений, позволяя при этом команде сосредоточиться на модернизации бизнес-процессов.
2. Энтропия
Программный продукт-долгожитель говорит о стабильности бизнеса. С другой стороны, в течение нескольких лет продукт адаптировался под рынок, заказчиков, пользователей, накапливал разнообразный функционал, в том числе логически противоречивый. Статистика HR-портала показывает, естественный уровень текучести персонала в IT — 8-10% в год, значит за 5 лет команда разработки может обновиться почти на половину. За время жизни продукта в команде может поменяться архитектор и ключевые разработчики, люди, знавшие изначальную архитектуру и логику ее масштабирования.
По мнению Ф. Брукса в работе «Мифический человеко-месяц», любая система стремится к разрушению структуры и увеличению энтропии с каждым новым исправлением. Со временем продукт обрастает так называемым legacy-кодом, унаследованным от несовместимого функционала, быстрого багфикса, неопытного разработчика. Вместе с тем под давлением сроков команда не всегда успевает покрывать код юнит-тестами. В таких условиях невозможно предсказать, на какие участки кода повлияет то или иное исправление и какой дефект породит.
Профессиональные тестировщики проверяют не только новые функции, но и регресс всей системы. Содержание и способ проведения регрессионного тестирования — предмет отдельного фокуса.
3. Кастомизация
Хорошо, когда продукт получает новые когорты пользователей, масштабируется на города и страны, специализирует функционал для разных ролей, адаптируется под время жизни пользователей в системе. С позиции системы это увеличивает количество критически важного функционала и способы его использования. Одна и та же функция может использоваться в разных целях и в различных условиях когортами пользователей. В большой сложной системе ролей и условий так много, что аналитик может забыть про одну из них во время разработки требований. На деле killer-feature для одной роли может стать блокирующим дефектом для другой, не менее значимой.
Профессиональное тестирование проверяет использование системы на соответствие целям пользователей, задает уточняющие вопросы, корректирует содержание регрессионного тестирования в соответствии с новыми приоритетами и бизнес-задачами системы. Актуализация набора и приоритетов тестов — предмет отдельного внимания тестировщика.
4. Распределённость
IT-среда сегодня предоставляет бесконечные возможности выбора, микро-сервисная архитектура, облачные дата-центры, распределенные проектные команды. Цельные продукты, с точки зрения пользователя, на деле расщепляются на микро-приложения, написаны на разных языках разработки, размещены на разных континентах, созданы разными проектными командами и компаниями.
К примеру, покупка безделушки в интернет-магазине, с одной стороны, действие из нескольких кликов, с другой — обработка и передача данных, по крайней мере, в трех приложениях — на веб-сайте магазина, в платежном шлюзе и платежной системе. Каждое приложение разрабатывает проектная команда со своими целями, оргструктурой, планами.
В этих условиях вероятен результат «пуля вылетела, проблема на вашей стороне»: когда каждая команда разработала свою часть в соответствии с требованиями, но вместе они не складываются в рабочую функцию.
Профессиональные тестировщики перед сдачей в эксплуатацию консультируют, курируют, выполняют настройку сред для прогона интеграционного тестирования, выполняют проверки с позиции конечного пользователя, а не только требований к отдельным компонентам.
Таким образом, крупные, возрастные, востребованные, стремительно изменяющиеся продукты обязывают тестирование быть отдельным родом деятельности. Эффективное тестирование вооружено специализированными методологиями, инструментами и конкретной целью, отличной от целей остальной команды. Цель аналитика — выяснить реальные потребности заказчика, цель разработчика — выполнить доставку заказанных изменений в полном объеме, цель тестировщика — испытать систему целиком, изучить пользователя и столкнуться с дефектами вместо него.
***
Делегирование тестирования отдельной роли под управлением команды — второй шаг к независимому тестированию. Тестировщиков можно нанять самостоятельно или воспользоваться аутсорсингом тестирования в независимой организации.
От аутсорсинг-тестирования на этом шаге компания получает:
- профессиональное тестирование своего продукта с актуальными инструментами;
- гарантированно квалифицированные кадры. Аутсорсинг специализируется на подборе и выращивании компетенций сотрудников;
- возможность воспользоваться тестированием на ограниченный срок, привлечь дополнительный вид тестирования или заменить его;
- прозрачную работу тестировщиков.
Компании, занимающиеся аутсорсинг-тестированием, работают на репутацию: она тем выше, чем качественней предоставляемая услуга. Как обстоят дела с тестированием в вашей компании? Делитесь опытом :)
gleb_l
«СоответСвует» и «РеализоваННо» в посте от представителя компании — это провал. Градус отношения к остальному тексту уже сразу понижен. Требования к качеству материала от компаний должны быть гораздо выше, чем от частников, имхо.
Как обстоит дело с тестированием выпускаемого в публичное пространство текста? ;)