Разработка программного обеспечения невозможна без контроля качества, а в этом ключевую роль играет процесс тестирования. Надо заметить, что тестирование ‒ это не единственная и тем более не достаточная мера для создания качественного ПО, но совершенно необходимая.

Что такое тестирование? Упрощенно, это процесс проверки того, что программа соответствует всем поставленным требованиям. Еще более упрощенно ‒ тестирование есть поиск ошибок. При этом обычно программа рассматривается как “черный ящик”, и проверка производится многократным запуском с разными исходными данными и в разных условиях.
Мы убеждены, что полноценное тестирование программного продукта в компании может выполнять только обособленное подразделение ‒ собственно, отдел тестирования. Перекладывание функций тестировщиков на разработчиков, бизнес-аналитиков или даже менеджеров ‒ путь неэффективный. В этой статье мы расскажем, как можно построить отдел тестирования.

Глоссарий

Тест-кейс ‒ шаги по достижению ожидаемого результата.
Тест-план ‒ запланированные и назначенные тест-кейсы.
Прогон ‒ выполнение тест-плана.
Регрессионный тест ‒ тест старого функционала программы, работоспособность которых могла быть нарушена после внедрения новых функций.

Люди

Самое важное ‒ найти правильных людей. Первое, с чем вы столкнетесь ‒ на тестировщиков у нас не учат, и найти человека не так уж просто. У вас два пути: “сделать тестировщиком” кого-то из ваших сотрудников или нанять со стороны человека в опытом работы.
Определенно, человек из компании уже знает особенности вашего продукта, требования клиентов и коллектив (это тоже важно). Вероятно (если вы уж занимаетесь разработкой), что кто-то из программистов свой код все же тестировал и кто-то это делал лучше и более тщательно, чем другие?
Однако, хотя переход из программистов в тестировщики возможен, никак нельзя быть уверенным, что ваши сотрудники, которым нравится своя работа, согласятся полностью посвятить себя тестированию. Я бы предположил, что они вообще не будут в восторге от такого предложения — слишком разные это профессии. Поэтому, найм со стороны также рассматривайте.
Хороший тестировщик — это не просто “выполнятель тестов”, это тот человек, который будет каждый день использовать ваш продукт и быть самым преданным его пользователем. А иметь такого человека в команде — многого стоит.

Планирование времени

Тестирование ‒ это трудоемкий и затратный по времени процесс. Один прогон регресс-тестов чего стоит! Поэтому при тестировании крайне важно планирование времени. Например, проектов у вас много, а отдел тестирования ‒ только один. Возникает много проблем при одновременных релизах.
Для решения очень удобно использовать google-календарь (про использование сервисов google я как-то уже писал), то есть создать календарь, в который можно вносить планируемые релизы, и расшарить его менеджерам и тестировщикам. Можно просматривать даты релизов и в системе управления проектами, например, Redmine, но наиболее наглядно использовать единый календарь для планирования.

Тестирование ‒ это учет и контроль

Чем иметь очень “злой” тест-кейс, намного важнее его “прогонять” регулярно и фиксировать результаты. Можно, конечно, все держать в голове или заносить результаты выполнения тестов в блокнот, но это не эффективно. Пользуйтесь TMS (Test Management System). Они позволяют использовать системный подход при тестировании ‒ когда мы изначально садимся и описываем план своих тестов, чтобы не получилось так: потестировали тут, там и, в результате, не можем сказать, каково же состояние проекта/продукта.
Самое важное при использовании TMS ‒ это анализ полученных результатов и выявление динамики развития проектов. Мы начинаем видеть от релиза к релизу, что, например:

• Увеличивается количество багов, и следует разобраться, в чем же проблема.
• Один из тестировщиков находит больше багов, чем остальные. Как поднять скиллы тестировщиков?
• Время на прогон регресс-тестов неуклонно растет с развитием проекта, но мы это наглядно видим и можем планировать.
• …… в общем, информации для анализа вполне достаточно.

Мы используем TMS Testlink. Вы можете выбрать и другие системы. Свой опыт и советы один из моих коллег рассказал в статье. Возьмите на заметку ‒ поможет в трудный момент. В TMS мы вносим все наши тесты, а потом просматриваем отчеты.

Ручное тестирование

Ручное тестирование — это то, с чего все начинается. Тесты выполняются вручную, без использования особых средств автоматизации (за исключением TMS). Тестировщик обычно просто следует заранее написанному плану действий, фиксируя результат — было ли поведение ожидаемым, или нет (в этом случае записывается, что пошло не так).
В большинстве случаев, ручное тестирование — это функциональное тестирование, а также тестирование на программную и аппаратную совместимость. Ручное тестирование наиболее распространено для проверки пользовательских интерфейсов — здесь автоматизация иногда экономически неэффективна или вообще невозможна.
Сотрудника на ручное тестирование следует искать кропотливого, пытливого и терпеливого, который “на ты” с объектами тестирования — сайтами, мобильными устройствами, SmartTV и т.п.

Автоматизированное тестирование

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

Часто бывает так, что затраты на поддержание автотестов значительно превышают затраты на ручное тестирование. Поэтому надо действовать без фанатизма.
Требования к сотруднику практически такие же, как к программисту-администратору. Почему администратору? Потому что автотестирование тесно связано с релиз-инжинирингом.
То есть мы, как правило, либо собираем пакеты для тестирования, либо выкатываем релиз в тестовое окружение (staging environment или “карантин” в нашей терминологии). В определенный момент мы приходим к тому, что надо минимизировать время тестирования перед релизом.

Нагрузочное тестирование

О нагрузочном тестировании зайдет речь после первого пика пользователей. Если все затормозило и упало, то как только перестанут искры сыпаться из глаз, поднимая проект, разработчики сами начнут произносить эту мантру, и вам повезет, если в ТЗ к проекту вы найдете цифры нагрузок, которые ваш проект/продукт должен выдерживать. Как ни странно, и сам заказчик зачастую не знает, чего можно ожидать от пользователей. Обычно эти цифры из менеджера будут выбивать разработчики, а менеджер ‒ у потустороннего менеджера, то есть со стороны заказчика.
Каким инструментом проводить тестирование? Мы используем yandex-tank.
Требования к сотруднику, проводящему тестирование:

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

Тестирование отказоустойчивости

Вам понадобится этот вид тестирования, как только вы начнете строить отказоустойчивые системы (например, с резервированием элементов или с graceful degradation). Печальный опыт показывает, что при отказе одно элемента в таких системах падает вообще все поведение других элементов труднопредсказуемо.
Как мы проводим тест отказоустойчивости? Анализируем техническую структуру проекта, тщательно планируем действия и в часы наименьшей загрузки выводим некоторые элементы системы из работы, изучаем последствия, вносим улучшения и корректировки. Потом повторяем.

Заключение

Подведу итоги, что же надо сделать, чтобы создать отдел тестирования:

• Выбрать правильных людей — из компании или извне;
• Завести инструмент планирования времени на тестирование релизов;
• Организовать работу с TMS для формирование тест-кейсов и учета результатов тестирования;
• Собственно, регулярно проводить тесты и анализировать результаты;
• Начать с ручного тестирования и по необходимости внедрять автоматизацию; по мере развития проектов добавлять нагрузочное тестирование и тестирование отказоустойчивости.

Автор:

Источник