Что такое тестирование?
Итак, что вообще такое тестирование ПО? Существуют различные варианты ответов на вопросы. Но, поскольку, большая часть ПО создаётся на заказ для Corporate, мы будем рассматривать этот вопрос именно с позиции указанного сектора.
В таком случае мы получим: тестирование ПО – это проверка функционала на соответствие требованиям.
Почему именно такое определение я выбрал? По той причине, что к контракту обычно прикладываются требования (чаще – бизнес-требования, реже – ТЗ/FSD). Соответственно, критерием исполнения контракта будет реализация прикреплённых к договору требований.
Для чего оно вообще нужно?
Из сказанного выше мы видим, что глобальная бизнес-цель тестирования – это подтверждение (в первую очередь для себя, во вторую – для Заказчика) соответствия функционала предъявленным требованиям. Просто чтобы нам деньги заплатили :)
Какие бывают этапы тестирования и для чего они нужны?
Итак, мы теперь знаем – что такое тестирование и зачем оно нам нужно. Теперь надо ответить на оставшиеся вопросы: что, как, где и кем мы собираемся тестировать. Чтобы сразу в этом не запутаться – проще всего разделить процесс на этапы, поставив цели на каждый. Моё видение этапов:
• Анализ: на данном мы определяем порядок действий для последующих этапов.
• Подготовка: тут мы готовимся к проведению тестирования.
• Проведение: здесь мы тестируем.
• Отчётность: а тут говорим «шеф, всё пропало» или «программа идеальна, в релиз».
Анализ
Наш самый первый этап. Он начинается, когда мы узнаём о том, что нам надо что-то делать :)
Тут определяем – что вообще нам надо протестировать. Подбираем исполнителей и инструменты, составляем план работ и общую стратегию. Конечно, в условиях наших реалий данный этап часто не то чтобы сокращается, но и отсутствует вовсе. Тем не менее, он бывает полезен.
Так как этап достаточно большой, его есть смысл так же разбить на ряд активностей:
• Анализируем требования для текущего релиза (или всего функционала, если он не большой): тут мы проверяем, что:
- требования не противоречивы (да, и за аналитиками надо присматривать);
- требования полны и однозначны (так же);
• Определяем верхнеуровневые варианты использования (или business use-case, если кому так привычнее).
• Определяем виды тестирования. Тут могу предложить некоторые типовые варианты (подробнее об уровнях и видах тестирования не буду сейчас писать – статья получится ещё больше):
- Если система новая – функциональное, интеграционное, нагрузка (если указано в требованиях);
- Если система существует, но дорабатывается – функциональное (нового), регрессионное (того, что затронуто), интеграционное, нагрузка (если необходимо);
- Если система связана с другой системой, которая создаётся вновь или изменяется – регрессионное интеграционное;
- Если сама связь (интеграция) создаётся – функциональное компонентное, интеграционное;
- Если сама связь (интеграция) изменяется – функциональное компонентное, регрессионное интеграционное;
- Если система выводится – интеграционное регрессионное для систем, которые ранее с ней взаимодействовали (очень часто не проводится).
- UAT – если бизнес-пользователи тоже участвуют.
• Определяем необходимые инструменты тестирования в соответствии с типами тестирования и требованиями.
• Планируем длительность и ресурсы по этапам.
• Определяем тестовые среды (договариваемся о подготовке сред и контуров, выясняем плановые даты рефрешей, и так далее).
• Составляем стратегию, в которую всё это объединяем:
- Объект тестирования;
- Цели тестирования;
- Критерии начала и завершения этапов;
- Критерии успеха;
- Ресурсы (исполнители, сроки, тестовые среды и контуры);
- План работ;
- Тестовые данные;
- Порядок работы и отчётность;
- Иное.
Самое основное мы определили. Дальше стараемся следовать тому, что мы написали :)
Подготовка
Тут мы готовимся к проведению тестирования. К моменту готовности функционала мы должны быть во всеоружии :)
Итак, что мы делаем:
• На основе Use Case составляем сценарии тестирования (при необходимости – согласуем с аналитиком; часто не делается);
• Готовим тестовые данные (в соответствии с требованиями к тестовым данным, но такие требования так же не всегда определяются);
• Получаем доступ к системам и тестовым средам, необходимые права на действия;
• Получаем подтверждение о готовности сборки (или релиза);
• Проверяем готовность инфраструктуры.
Проведение
Мы подготовились, час настал. Теперь – в бой :)
На данном этапе мы проводим тестирование по тестам в соответствии с планом. На тех средах, что получили:
• Проходим тесты;
• Проставляем статусы;
• Заводим дефекты.
Отчётность
По завершении тестирования, мы должны показать свои результаты работы. Во-первых – это показатель того, что мы что-то делали :) А во-вторых – это информация для менеджера о текущем состоянии функционала. Кроме этого, мы даём свою рекомендацию о выводе/не выводе функционала в ПРОД.
Отчёты бывают разные (жёлтые, синие, красные :) ). Но есть некая общая информация, которая, на мой взгляд, должна быть в каждом отчёте:
• Прохождение тестов по приоритетам (в %, к примеру. Или с указанием all/pass/fail в абсолютных значениях).
• Покрытие требований (сколько % требований с каким приоритетом покрыто успешно пройденными тестами, сколько – провалено, сколько - заблокировано).
• Статистика по дефектам.
• Рекомендация (или не рекомендация) вывода функционала.
Почему ПО выходит с ошибками?
Почему, имея определённый штат тестировщиков, мы не всегда получаем то качество, какое хотели бы получить?
Причин много и они могут быть самыми разнообразными. Давайте определим некоторые, наиболее значимые:
• Бизнес-необходимость: нам не надо всё и хорошо, нам надо эти критичные требования, остальное потом как-нибудь.
• Недостаточность ресурсов: работы на месяц, а до релиза осталась неделя.
• Отсутствие массовой культуры качественного выполнения работ: если бы писали и тестировали ПО для робота, который будет делать операцию на сердце нам же сразу после релиза – это хороший стимул. А если это всего лишь отчётность в ЦБ или выгрузка в налоговую, нарушение которой – штрафы за каждую некорректную запись, ежедневно – миллионы для банка – и так сойдёт.
Что есть и что будет дальше?
Не смотря на пройденные десятилетия, тестирование активно развивающееся направление. У тестирования в сегодняшнем виде есть ряд проблем, которые заставляют искать новые решения и пути совершенствования:
• Отсутствие гарантии выявления 100% ошибок (мы не можем найти все ошибки).
• Принесение объёма в жертву приоритету по причине ограниченности ресурсов (чаще всего мы проверяем наиболее важные пути, оставляя за бортом альтернативные, менее приоритетные для бизнеса варианты, но не менее равнозначные с позиции функционала).
• В указанном подходе – привлечение тестировщиков на этапе готовности функционала (проблема QA).
• Иное.
К чему сейчас движемся:
• К развитию средств автоматизации с тем, чтобы они были всё больше похожи на человека;
• К управлению качеством на более ранних этапах (QM). Как только будет решена проблема сложности, трудоёмкости и ресурсоёмкости тестовых инфраструктур и компания из 20 человек с небольшим бюджетом сможет выделить 1-2 тестировщиков для любой необходимой автоматизации (автотесты автосборок, автоматическое заведение дефектов, отчётность – за 5-10 минут после коммита) – для многих IT компаний (не только самых маленьких, но и лидеров российского IT-сектора) это станет не пустым звуком.
• К росту центров компетенции – специалист по тестированию уже не просто тестировщик, он уже должен разбираться в предметной области Заказчика (если банковское ПО – в банковском деле), законодательстве.
• Как следствие - разделение труда тестировщиков по бизнес-направлениям.
• Прочее.
PS: всё вышесказанное исключительно ИМХО автора и на истину в последней инстанции не претендует… пока :)
