Перевод статьи «How Does Test Planning Differ for Manual and Automation Projects?».
Мы все согласны с тем, что проекты с автоматизацией отличаются по своей природе от проектов с ручным тестированием. Хотя автономных автоматизированных проектов на самом деле практически не существует, при планировании и к ним, и к ручным проектам используются разные подходы.
Неправильно спланированный проект неизбежно становится неисполнимым. Это не только негативно влияет на текущий проект и портит репутацию тестировщика, но и порой приводит к потере доверия к команде со стороны клиента/руководства, что негативно сказывается на дальнейшем бизнесе. Тестировщикам всегда лучше перестраховаться, чем потом сожалеть о несделанных вещах.
Подпишитесь на наш ТЕЛЕГРАМ КАНАЛ ПО АВТОМАТИЗАЦИИ ТЕСТИРОВАНИЯ
Прежде чем мы продолжим, определимся, что не будет упоминаться в этой статье.
1. Это не детальное обсуждение фреймворков автоматизации. Различные проекты используют разные инструменты в зависимости от характера их AUT, архитектуры, сложности, опыта команды и т.д.
2. Речь также не пойдет о шаблоне, формате или создании документа Test Plan. Мы собираемся рассмотреть вопросы предварительной подготовки документации для проекта автоматизации, больше в рамках технико-экономического анализа.
3. Мы не будем рассматривать конкретные инструменты. Каждый вид деятельности в SDLC требует времени, усилий, инфраструктуры – другими словами, денег.
Для проекта ручного тестирования наиболее затратными факторами являются:
- люди;
- инструменты – управление тестированием/дефектами;
- инфраструктура – среда;
- время;
- обучение.
Для проекта автоматизации, в дополнение к вышеперечисленным пунктам, необходимо также выделить средства на:
- инструменты автоматизации;
- дополнение для интеграции инструментов управления тестированием;
- надстройки для поддержки AUT (например, SAP, Oracle и т.д.);
- создание структуры;
- обучение по специфике инструмента.
Учитывая эти обстоятельства, зависит ли успех проекта автоматизации от того, насколько качественный ваш код, сколько повторно используемых компонентов вы написали или в скольких строках кода вы достигли желаемого результата?
Нет. Единственный вопрос, который определяет успешность проекта: «Сможете ли вы добиться более высокой рентабельности инвестиций (возврата инвестиций) по сравнению с ручным подходом»?
Если ответ на этот вопрос отрицательный, значит, вы неправильно спланировали проект автоматизации.
Обычно план тестирования состоит из следующих разделов. Мы собираемся обсудить каждый из них, уделив особое внимание конкретным аспектам автоматизации, которые следует учитывать:
Разделы плана автоматизированного тестирования
Раздел 1: Объем
- Выберите тест-кейсы/сценарии, которые будут неоднократно повторяться в течение нескольких циклов.
- Иногда самые простые тестовые случаи в условиях автоматизации требуют множества сложных решений. Если они предназначены только для одноразового использования, то они бессмысленны. Сконцентрируйтесь на тест-кейсах, пригодных для повторного использования.
- Невозможность автоматизации исследовательского тестирования.
Раздел 2: Стратегия тестирования
- Определитесь с конкретным фреймворком. Одни фреймворки чрезвычайно сложны для создания с нуля. Другие достаточно эффективны, но требуют много времени, усилий и компетенции. Всегда ищите золотую середину и делайте все возможное, стараясь избегать чрезмерного использования ресурсов.
- Примите решение о том, какие рекомендации по кодированию будут использоваться, правила именования, места хранения тестовых ресурсов, формат результатов тестов и т. д., чтобы обеспечить единообразие и повысить производительность.
Раздел 3: Ресурсы/роли и обязанности
- Первый шаг в этом направлении – понять возможности команды и заранее предвидеть масштабы автоматизации. Это поможет подобрать команду, которая будет соответствовать требованиям как автоматизации, так и ручного тестирования. Кроме того, выбирайте людей с правильным отношением – тех, кто не считает, что ручное тестирование не достойно их статуса.
- Выбирайте команду, хорошо разбирающуюся в AUT, управлении тестированием, управлении дефектами и других видах деятельности SDLC.
Раздел 4: Инструменты
Выбирайте инструменты автоматизации, руководствуясь следующими правилами:
- Если у компании уже имеются лицензии на определенный инструмент, изучите его и узнайте, сможете ли вы его использовать в своем проекте.
- Выбирайте инструменты с открытым исходным кодом (но надежные).
- Уточните знакомы ли члены команды с этим инструментом или придется привлечь кого-то нового(обучить уже имеющихся)?
Раздел 5: График
- Выделите время на прохождение кода и проверку скриптов автоматизации.
- Своевременно поддерживайте скрипты. Если вы создаете часть кода, которую не собираетесь использовать в течение ближайших 6 месяцев или около того, обязательно периодически обновляйте ее, чтобы уменьшить вероятность сбоя.
Раздел 6: Окружение
- Целевая среда, в которой будет работать ваш AUT, и инструмент автоматизации, который вы хотите использовать, должны быть совместимы. Это один из факторов, который необходимо учитывать при предварительном лицензировании инструмента.
- Проанализируйте, совместимы ли остальные имеющиеся инструменты управления и инструмент автоматизации, который вы хотите использовать, для получения дополнительных преимуществ.
Раздел 7: Результаты
- Ваши тестовые сценарии – это ваши конечные результаты. Однако не все разбираются в языках автоматизации/программирования. Поэтому запланируйте создание документа с практическими рекомендациями, который поможет нынешним пользователям и будущим членам команды понять этот сценарий, даже когда вас нет рядом.
- Включите комментарии в свой сценарий.
Раздел 8: Риски
Если вы собираетесь самостоятельно предложить какой-либо фреймворк для использования в работе, обязательно выбирайте экономически эффективные инструменты, чтобы переход на автоматизацию не обременял проект.
Важно учесть, что окупаемость инвестиций в проекте автоматизации не может быть положительной сразу же, но она может четко просматриваться в течение длительного периода времени.
Поэтому, если вы предлагаете автоматизировать систему, выбирайте ту, которая:
- Стабильна и не требует слишком частого обслуживания.
- Имеет возможности для создания огромных регрессионных наборов.
- Не требует слишком частого ручного вмешательства и не зависит от человека.
Раздел 9: Тестовые данные
- Принимайте во внимание аспекты безопасности данных.
- Не вписывайте тестовые данные в скрипты. Это приведет к слишком частому обслуживанию скриптов и может вызвать ошибки при модификации..
- Будьте очень конкретны. Например, для шага ручного тестирования – “введите имя и фамилию” – вы можете указать “введите любое имя из 5 символов”. Тестировщик может ввести “Swati” или “Seela” или прочие похожие варианты. Но инструмент не может делать такие предположения. Поэтому указывайте точные значения.
Раздел 10: Отчеты/результаты
- Результаты выполнения скрипта также носят технический характер и могут быть не совсем понятны остальным членам команды. В качестве дополнительной меры запланируйте запись подробных результатов в блокнот или таблицы Excel.
- Также важно собрать подробные документы по фреймворку, результаты обзора, отчеты о дефектах, отчеты о состоянии выполнения.
Существует мнение, что клиенты не так легко соглашаются предложения по автоматизации.
Однако, когда нашей конечной целью является максимизация ROI (Return On Investment – возврат инвестиций) посредством автоматизации, это полностью совпадает с целями заказчика. Если мы получаем одобрение на автоматизацию нашего проекта, мы можем сделать это с большим согласием, сотрудничеством и воодушевлением.
Планирование и тщательный анализ всех перечисленных выше факторов могут стать нашими союзниками на этом пути. Рентабельность инвестиций имеет огромное значение.