Что не выполняет тестировщик в v модели
Перейти к содержимому

Что не выполняет тестировщик в v модели

  • автор:

Модели и методологии разработки ПО

Существуют модели разработки ПО. И существуют методологии. В интернете много противоречивой информации о том, что есть что и как их отличать. Начинающему специалисту бывает сложно в этом разобраться. В этой статье мы расставим все точки над i.

Этапы жизненного цикла ПО

У любого программного обеспечения есть жизненный цикл — этапы, через которые оно проходит с начала создания до конца разработки и внедрения. Чаще всего это подготовка, проектирование, создание и поддержка. Этапы могут называться по-разному и дробиться на более мелкие стадии.

Рассмотрим эти этапы на примере жизненного цикла интернет-магазина.

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

Проектирование. Иван выбрал компанию-подрядчика и обсудил с её специалистами архитектуру и дизайн будущего интернет-магазина.

Создание. Иван заключил с разработчиками договор. Они начали писать код, отрисовывать дизайн, составлять документацию.

Поддержка. Иван подписал акт сдачи-приёмки, и подрядчик разместил интернет-магазин на «боевых» серверах. Пользователи начали его посещать и сообщать о замеченных ошибках в поддержку, а программисты — оперативно всё исправлять.

Модель разработки программного обеспечения описывает, какие стадии жизненного цикла оно проходит и что происходит на каждой из них.

А методология включает в себя набор методов по управлению разработкой: это правила, техники и принципы, которые делают её более эффективной.

Основные модели разработки ПО

  • Code and fix — модель кодирования и устранения ошибок;
  • Waterfall Model — каскадная модель, или «водопад»;
  • V-model — V-образная модель, разработка через тестирование;
  • Incremental Model — инкрементная модель;
  • Iterative Model — итеративная (или итерационная) модель;
  • Spiral Model — спиральная модель;
  • Chaos model — модель хаоса;
  • Prototype Model — прототипная модель.

Из этих моделей наиболее популярны пять основных: каскадная, V-образная, инкрементная, итерационная и спиральная. Разберём их подробнее.

Waterfall (каскадная модель, или «водопад»)

В этой модели разработка осуществляется поэтапно: каждая следующая стадия начинается только после того, как заканчивается предыдущая. Если всё делать правильно, «водопад» будет наиболее быстрой и простой моделью. Применяется уже почти полвека, с 1970-х.

Преимущества «водопада»

  • Разработку просто контролировать. Заказчик всегда знает, чем сейчас заняты программисты, может управлять сроками и стоимостью.
  • Стоимость проекта определяется на начальном этапе. Все шаги запланированы уже на этапе согласования договора, ПО пишется непрерывно «от и до».
  • Не нужно нанимать тестировщиков с серьёзной технической подготовкой. Тестировщики смогут опираться на подробную техническую документацию.

Недостатки каскадной модели

  • Тестирование начинается на последних этапах разработки. Если в требованиях к продукту была допущена ошибка, то исправить её будет стоить дорого. Тестировщики обнаружат её, когда разработчик уже написал код, а технические писатели — документацию.
  • Заказчик видит готовый продукт в конце разработки и только тогда может дать обратную связь. Велика вероятность, что результат его не устроит.
  • Разработчики пишут много технической документации, что задерживает работы. Чем обширнее документация у проекта, тем больше изменений нужно вносить и дольше их согласовывать.

«Водопад» подходит для разработки проектов в медицинской и космической отрасли, где уже сформирована обширная база документов (СНиПов и спецификаций), на основе которых можно написать требования к новому ПО.

При работе с каскадной моделью основная задача — написать подробные требования к разработке. На этапе тестирования не должно выясниться, что в них есть ошибка, которая влияет на весь продукт.

V-образная модель (разработка через тестирование)

Это усовершенствованная каскадная модель, в которой заказчик с командой программистов одновременно составляют требования к системе и описывают, как будут тестировать её на каждом этапе. История этой модели начинается в 1980-х.

Преимущества V-образной модели

  • Количество ошибок в архитектуре ПО сводится к минимуму.

Недостатки V-образной модели

  • Если при разработке архитектуры была допущена ошибка, то вернуться и исправить её будет стоить дорого, как и в «водопаде».

V-модель подходит для проектов, в которых важна надёжность и цена ошибки очень высока. Например, при разработке подушек безопасности для автомобилей или систем наблюдения за пациентами в клиниках.

Incremental Model (инкрементная модель)

Это модель разработки по частям (increment в переводе с англ. — приращение) уходит корнями в 1930-е. Рассмотрим её на примере создания социальной сети.

  1. Заказчик решил, что хочет запустить соцсеть, и написал подробное техническое задание. Программисты предложили реализовать основные функции — страницу с личной информацией и чат. А затем протестировать на пользователях, «взлетит или нет».
  2. Команда разработки показывает продукт заказчику и выпускает его на рынок. Если и заказчику, и пользователям социальная сеть нравится, работа над ней продолжается, но уже по частям.
  3. Программисты параллельно создают функциональность для загрузки фотографий, обмена документами, прослушивания музыки и других действий, согласованных с заказчиком. Инкремент за инкрементом они совершенствуют продукт, приближаясь к описанному в техническом задании.

Преимущества инкрементной модели

  • Не нужно вкладывать много денег на начальном этапе. Заказчик оплачивает создание основных функций, получает продукт, «выкатывает» его на рынок — и по итогам обратной связи решает, продолжать ли разработку.
  • Можно быстро получить фидбэк от пользователей и оперативно обновить техническое задание. Так снижается риск создать продукт, который никому не нужен.
  • Ошибка обходится дешевле. Если при разработке архитектуры была допущена ошибка, то исправить её будет стоить не так дорого, как в «водопаде» или V-образной модели.

Недостатки инкрементной модели

  • Каждая команда программистов разрабатывает свою функциональность и может реализовать интерфейс продукта по-своему. Чтобы этого не произошло, важно на этапе обсуждения техзадания объяснить, каким он будет, чтобы у всех участников проекта сложилось единое понимание.
  • Разработчики будут оттягивать доработку основной функциональности и «пилить мелочёвку». Чтобы этого не случилось, менеджер проекта должен контролировать, чем занимается каждая команда.

Инкрементная модель подходит для проектов, в которых точное техзадание прописано уже на старте, а продукт должен быстро выйти на рынок.

Iterative Model (итеративная модель)

Это модель, при которой заказчик не обязан понимать, какой продукт хочет получить в итоге, и может не прописывать сразу подробное техзадание.

Рассмотрим на примере создания мессенджера, как эта модель работает.

  1. Заказчик решил, что хочет создать мессенджер. Разработчики сделали приложение, в котором можно добавить друга и запустить чат на двоих.
  2. Мессенджер «выкатили» в магазин приложений, пользователи начали его скачивать и активно использовать. Заказчик понял, что продукт пользуется популярностью, и решил его доработать.
  3. Программисты добавили в мессенджер возможность просмотра видео, загрузки фотографий, записи аудиосообщений. Они постепенно улучшают функциональность приложения, адаптируют его к требованиям рынка.

Преимущества итеративной модели

  • Быстрый выпуск минимального продукта даёт возможность оперативно получать обратную связь от заказчика и пользователей. А значит, фокусироваться на наиболее важных функциях ПО и улучшать их в соответствии с требованиями рынка и пожеланиями клиента.
  • Постоянное тестирование пользователями позволяет быстро обнаруживать и устранять ошибки.

Недостатки итеративной модели

  • Использование на начальном этапе баз данных или серверов — первые сложно масштабировать, а вторые не выдерживают нагрузку. Возможно, придётся переписывать большую часть приложения.
  • Отсутствие фиксированного бюджета и сроков. Заказчик не знает, как выглядит конечная цель и когда закончится разработка.

Итеративная модель подходит для работы над большими проектами с неопределёнными требованиями, либо для задач с инновационным подходом, когда заказчик не уверен в результате.

Spiral Model (спиральная модель)

Используя эту модель, заказчик и команда разработчиков серьёзно анализируют риски проекта и выполняют его итерациями. Последующая стадия основывается на предыдущей, а в конце каждого витка — цикла итераций — принимается решение, продолжать ли проект. Эту модель начали использовать в 1988 году.

Рассмотрим, как функционирует эта модель, на примере разработки системы «Умный дом».

  1. Заказчик решил, что хочет сделать такую систему, и заказал программистам реализовать управление чайником с телефона. Они начали действовать по модели «водопад»: выслушали идею, провели анализ предложений на рынке, обсудили с заказчиком архитектуру системы, решили, как будут её реализовывать, разработали, протестировали и «выкатили» конечный продукт.
  2. Заказчик оценил результат и риски: насколько нужна пользователям следующая версия продукта — уже с управлением телевизором. Рассчитал сроки, бюджет и заказал разработку. Программисты действовали по каскадной модели и представили заказчику более сложный продукт, разработанный на базе первого.
  3. Заказчик подумал, что пора создать функциональность для управления холодильником с телефона. Но, анализируя риски, понял, что в холодильник сложно встроить Wi-Fi-модуль, да и производители не заинтересованы в сотрудничестве по этому вопросу. Следовательно, риски превышают потенциальную выгоду. На основе полученных данных заказчик решил прекратить разработку и совершенствовать имеющуюся функциональность, чтобы со временем понять, как развивать систему «Умный дом».

Спиральная модель похожа на инкрементную, но здесь гораздо больше времени уделяется оценке рисков. С каждым новым витком спирали процесс усложняется. Эта модель часто используется в исследовательских проектах и там, где высоки риски.

Преимущества спиральной модели

  • Большое внимание уделяется проработке рисков.

Недостатки спиральной модели

  • Есть риск застрять на начальном этапе — бесконечно совершенствовать первую версию продукта и не продвинуться к следующим.
  • Разработка длится долго и стоит дорого.

На основе итеративной модели была создана Agile — не модель и не методология, а скорее подход к разработке.

Что такое Agile?

Agile («эджайл») переводится с английского как «гибкий». Включает в себя практики, подходы и методологии, которые помогают создавать продукт более эффективно:

  • экстремальное программирование (Extreme Programming, XP);
  • бережливую разработку программного обеспечения (Lean);
  • фреймворк для управления проектами Scrum;
  • разработку, управляемую функциональностью (Feature-driven development, FDD);
  • разработку через тестирование (Test-driven development, TDD);
  • методологию «чистой комнаты» (Cleanroom Software Engineering);
  • итеративно-инкрементальный метод разработки (OpenUP);
  • методологию разработки Microsoft Solutions Framework (MSF);
  • метод разработки динамических систем (Dynamic Systems Development Method, DSDM);
  • метод управления разработкой Kanban.

Различия между Agile и традиционным подходом к разработке мы свели в таблице:

Не всё перечисленное в списке — методологии. Например, Scrum чаще называют не методологией, а фреймворком. В чём разница? Фреймворк — это более сформированная методология со строгими правилами. В скраме все роли и процессы чётко прописаны. Помимо Scrum, часто используют Kanban.

Kanban

Сегодня это одна из наиболее популярных методологий разработки ПО. Команда ведёт работу с помощью виртуальной доски, которая разбита на этапы проекта. Каждый участник видит, какие задачи находятся в работе, какие — застряли на одном из этапов, а какие уже дошли до его столбца и требуют внимания.

В отличие от скрама, в канбане можно взять срочные задачи в разработку сразу, не дожидаясь начала следующего спринта. Канбан удобно использовать не только в работе, но и в личных целях — распределять собственные планы или задачи семьи на выходные, наглядно отслеживать прогресс.

Совсем скоро мы организуем трёхдневный онлайн-интенсив по Agile-методологиям. На нём вы научитесь использовать все преимущества этого подхода, управлять разработкой и выпускать проекты любой сложности. Ждём вас!

Урок 23 — Методологии и модели разработки ПО. Scrum, Kanban, Agile, Водопадная модель, V-model

Модель разработки ПО описывает, какие стадии жизненного цикла проходит ПО от начала и до конца и что происходит на каждой из них.

Существует Водопадная модель, V-Модель, Итеративная модель, Спиральная модель и т д

Методология разработки ПО описывает набор методов по управлению разработкой: это правила, техники, принципы, которые делают разработку более эффективной.

То есть методология — это более обширный набор принципов и практик, который определяет способ выполнения каждого этапа разработки.

Самые популярные методологии, которые существуют — это Scrum и Kanban.

Важно отметить, что эти два понятия часто используются совместно и могут быть взаимозависимыми.

Водопадная модель (waterfall model)

Водопадная модель — это один из самых старых и простых способов разработки программного обеспечения.

В ней все похоже на водопад: вода падает сверху вниз, и на каждом этапе что-то происходит.

Требование

Сначала собирают требования, просто спрашивают, что должна делать программа, какие функции в ней должны быть.

Проектирование

Здесь уже решают, как все будет устроено внутри программы. Какие будут кнопки, какие функции они будут выполнять и так далее.

Кодирование

Программисты начинают писать код, который будет выполнять все эти задачи

Тестирование

Проверяют, работает ли все, как надо. Если есть ошибки, их исправляют.

Внедрение

Когда все готово и проверено, программу запускают или устанавливают там, где она будет использоваться.

Поддержка

Если в программе что-то сломается или понадобятся новые функции, их добавляют или исправляют.

Главное в этой модели — каждый этап идет строго один за другим, и начать следующий можно только тогда, когда предыдущий закончен. Тесть мы начинаем тестирование только на этапе тестирования. Это как строительство дома: сначала ложат фундамент, потом стены, потом крышу. Нельзя поставить крышу, если нет стен.

V-Модель

«V» модель — это расширение водопадной модели разработки программного обеспечения.

Она называется «V», потому что процесс разработки тут похож на букву V: сначала идём вниз по одной стороне — это разработка, потом вверх по другой — это тестирование.

Идем вниз по «V» (Разработка)

Собираем требования:
Понимаем, что должна делать программа.

Системное проектирование:
Решаем, как будут взаимодействовать разные части системы.

Архитектурное проектирование:
Разбиваем систему на модули или компоненты.

Детальное проектирование:
Прорабатываем, как каждый модуль будет работать.

Потом Кодирование:
Программисты пишут код для каждого модуля.

Теперь идем вверх по «V» (Тестирование)

Модульное тестирование:
Проверяем, работает ли каждый отдельный модуль правильно.

Интеграционное тестирование:
Смотрим, как модули работают вместе.

Системное тестирование:
Проверяем всю систему в целом.

Приемочное тестирование:
Убеждаемся, что программа делает то, что от неё требовалось изначально.

По сути, каждый этап тестирования связан с определенным этапом разработки. Перед тем как двигаться дальше, мы убеждаемся, что все предыдущие этапы выполнены правильно. Это делает «V» модель более строгой и организованной по сравнению с простой водопадной моделью. Простыми словами,»V» модель помогает не просто сделать программу, но и удостовериться, что она работает так, как нужно, на каждом этапе разработки.

KANBAN

Kanban — это метод управления рабочим процессом, который помогает легко видеть, над чем в данный момент работает команда, что уже готово, и что предстоит сделать.

Обычно всё это отображается на доске, которая разделена на колонки, каждая из которых представляет разный этап работы. Колонки могут быть названы совершенно по разному.

Каждая задача — это карточка, которую мы ставим в первую колонку.

Когда кто-то начинает работать над задачей, он переносит её карточку в колонку «В процессе» как правило

Когда задача выполнена, карточка передвигается в соответствующую колонку. Пример доски ниже:

Чтобы не перегрузить команду, можно установить ограничение на количество задач, которые могут быть в колонке «В процессе». Смысл в том, чтобы задачи постоянно двигались с лева направо, создавая непрерывный поток работы

Важно периодически смотреть на доску, анализировать, как идет работа, и при необходимости что-то менять.

Плюсы:
Простота и наглядность: всё видно на одной доске
Гибкость: легко менять процесс и адаптироваться.
Фокус на текущих задачах: команда сосредоточена на том, чтобы завершить начатое, а не браться за новое.

Минусы:
Канбан не всегда подходит для сложных проектов с зависимыми задачами.
Может создаться иллюзия производительности, если просто перекидывать карточки, не углубляясь в детали.

SCRUM

Scrum является формой гибкой Agile модели разработки и используется для управления проектами и разработки программного обеспечения.

Роли

  • Product Owner, что в переводе владелец продукта и он отвечает за определение требований и приоритетов
  • Скрам мастер это такой защитник команды разработки, помогает устранять препятствия, решать различные разногласия.
  • Команда разработки, обычно 3-9 человек, которые выполняют задачи, у эту команду входит и qa

Артефакты

  • Product Backlog: Список всех функций, улучшений и исправлений ошибок, которые должны быть реализованы.
  • Sprint Backlog: Список задач, выбранных для выполнения в текущем спринте.
  • Цель спринта: Допустим это работающая версия продукта, разрабатываемая в спринте, или работающая версия какой то небольшой функциональности.

Спринт

Планирование спринта (Sprint Planning): В начале каждого спринта команда и Product Owner собираются, чтобы определить задачи для следующего спринта. Задачи с скраме обычно представленные в виде «User Stories».

User Story в переводе обозначает, пользовательская история — это описание функциональной возможности простыми словами, составленное с точки зрения пользователя.

И оцениваем мы такие в задачи в так называемых стори поинтах.

Стори поинт — это условная единица, которая позволяет спрогнозировать объем трудозатрат на выполнение конкретной задачи и придать вес задачам в бэклоге. То есть это оценка не в часах, не в минутах а именно в сторипоинтах. Общее количество сторипоинтов для выбранных задач не должно превышать «спринтовую мощность» команды,

которая обычно рассчитывается на основе исторических данных о производительности.

Что это значит, к примеру на основе опыта, скрам команда выявила, что за 2 недельный спринт они выполняют 30 сторипоинтов, не больше.

И значит при планировании спринта им нужно набрать столько задач, чтобы у них вышло не больше 30 сторипоинтов на все задачи.

Scrum poker

Это интерактивная и часто веселая игра, которая помогает команде договориться о том, насколько трудоемкой или сложной является каждая задача. Это делается для более точного планирования времени и ресурсов.

Как это работает:

У каждого участника есть набор карт с числами. Эти числа обычно следуют определенной последовательности

(например, Фибоначчи: 1, 2, 3, 5, 8, 13, 21 и так далее). Владелец продукта или другой член команды описывает задачу,

которую нужно оценить. Команда обсуждает задачу, задает вопросы и выясняет детали. После обсуждения каждый член команды выбирает карту с числом, которое, по его мнению, отражает сложность задачи. Все показывают свои карты одновременно. Если оценки сильно различаются, проводится дополнительное обсуждение. Те, кто дал наибольшую и наименьшую оценку, объясняют свой выбор. Далее после обсуждения проводится новое голосование. Процесс повторяется, пока команда не придет к консенсусу.

Зачем вообще это нужно:

  • Снижение риска ошибок в оценке: Когда все члены команды участвуют в оценке, вероятность учесть все факторы и трудности увеличивается.
  • Обмен опытом: Младшие члены команды быстро учатся у более опытных, понимая, как они оценивают сложность задач.
  • Командная работа: Это отличный способ улучшить коммуникацию внутри команды и узнать, как другие думают.

Планирование спринта может происходить довольно долго, оно может запросто идти пол дня иди даже весь рабочий день, если вдруг спринт не двух недельный, а скажем месячный. После того как запланировали спринт, у нас идут ежедневные созвоны (их называют Daily Stand-ups или Daily Scrum):

Это краткие ежедневные встречи (обычно 15 минут), на которых команда обсуждает, что было сделано, что планируется сделать и какие препятствия есть. В конце двух недельного спринта спринта команда демонстрирует выполненные задачи на внутренних демках компании и получает обратную связь.

И далее у нас идет завершающая часть спринта — это Ретроспектива спринта (Sprint Retrospective):

команда анализирует, что прошло хорошо, что можно улучшить, и планирует улучшения на следующий спринт, как правило это происходит по пятницам. И в понедельник на следующей неделе стартует следующий спринт с планированием и всеми последующими процессами.

И этот процесс повторяется до тех пор, пока продукт или система не будет завершена или не будет достигнута какая-то другая точка остановки.

Тестировщик — больше, чем профессия

За время своей работы в сфере тестирования, у меня сложилось своё, особое мнение об этой области, начиная с позиции младшего тестировщика (junior tester) до руководителя отдела тестирования (test manager). И, в целом, это мнение достаточно критичное с долей любви и обожания к этой замечательной профессии.

В качестве вступления

Я никогда не собирался становиться тестировщиком — меня больше привлекала разработка. Со школьной скамьи я писал программы, которые уже обкатывались моими одноклассниками, а затем одногруппниками: мне было интересно решать задачи и оживлять вещи, а уж решением возникающих проблем и багов я занимался после того, как мне о них сообщали пользователи. К версии я приписывал минорную циферку, и… и в каком-то балансе между функциональностью и качеством программа оставалась навсегда, уступая место новым проектам и программам.

Забегая вперёд, скажу, что отчасти в этом кроется ключ к успешному ведению проектов — в нахождении баланса между затратами на разработку продукта и его качеством. Любой продукт схож с биологическим организмом, в формировании которого участвуют не один человек, а многие — прямым или косвенным образом. В формировании хорошего продукта должны участвовать все заинтересованные стороны, и каждая из них должна делать весомый вклад в общее дело. Но, к моему удивлению, тестировщики в этом отношении занимают особую нишу: во-первых, они являются связующим звеном в процессе, а во-вторых, они одни единственные из инженеров имеют право вето на выпуск версии продукта.

Обо всём об этом я узнал на первом своём месте в качестве тестировщика с неугасшими амбициями разработчика. В первую очередь, меня очаровала возможность получения доступа к управлению продуктом, власть, на которую я не особо рассчитывал. Это было здорово, что-то особенное, выше написания очередной функциональности. Во-вторых, тестировщики в силу особенностей профессии имеют большее представление о процессах и целях продукта, отчасти транслируют бизнес цели разработчикам, а результат разработчиков —руководителям. К сожалению, в мире и, тем более, в России, представление о роли тестировщика весьма сумбурное, и её значение сильно преуменьшается. А те компании, которые всё-таки находятся в тренде, стараются развить направления тестирования и управления качеством, хотя и ставят несколько завышенные цели: «найти все ошибки, снизить до минимума стоимость разработки через тестирование».

Эта статья, в первую очередь написана по мотивам общения с различными компаниями, является квинтэссенцией ответов на их вопросы. Во-вторых, обращена к начинающим тестировщикам и тем людям, которые хотят узнать о тестировании побольше с точки зрения внутренней кухни. В- третьих, базируется исключительно на моём (субъективном) опыте.

Тезис №1: Тестировщик — не обезьяна

В Android SDK входит замечательный инструмент под названием MonkeyRunner, который позволяет автоматизировать процесс тестирования Android приложений в идеале без исходного кода, без особых знаний языков программирования (лишь общего представления о скриптовых языках достаточно) и, главное — имитировать любое поведение настоящего пользователя. В итоге получается эдакая скриптовая обезьяна, которая тыкает, печатает, читает приложение. Самое то, что можно «отдать на аутсорс» машине. Для меня такое понимание тестирования в порядке вещей. Но, к моему удивлению, когда я искал работу в первый раз после своей первой должности в роли тестировщика, выяснилось, что на рынке существуют (и по сей день!) странное разделение на «ручных» и «автоматических» тестировщиков, более того, лестница грейдов и вовсе столь смешана и растянута, что диву даёшься. Не говоря уже о том, что от компании к компании одни и те же должности подразумевают разные должностные обязанности, особенно это актуально для старших должностей.

В мои должностные обязанности входило: составление тест-дизайна, тест-кейсов, стратегии тестирования (если это был назначенный на меня проект), репорт багов, проверка документации и создание тестовой документации. Это было само собой разумеющимся для меня, хотя несколько удивляло, что у западных коллег эти обязанности были разделены. На рынке же оказалось, что вполне обычным явлением считается, что дизайн пишется с помощью CTE/UML (в лучшем случае) Test Lead/Senior Tester/Test Designer. Тест кейсы (разнообразные стратегии проверки границ, интерфейсное тестирование, нагрузочное, стендовые кейсы) — Senior Tester’ы. И, наконец, существуют низшие должности «исполнителей» — Tester. В некоторых компаниях и отделах их число может доходить до 20 и более человек! Другими словами, в штате проекта числились обезьяны, в лучшем случае, обладающие навыками пользователя компьютером и каким-то продуктом.

На деле же это… несколько неправильно. Потому что тестировщик не обезьяна. Если это не так, то либо вы, как компания, выпускаете разные продукты в короткий срок, без последующей поддержки и качества, прогоняя формальные smoke-тесты, либо, что более вероятно, ваш менеджер/архитектор — баран.

Затраты на автоматизацию тестирования окупаются далеко не сразу.

Для знакомых с теорией тестирования (коих, как показывает практика, не так уж и много), вполне очевидно, что необходимость автоматизации сильно зависит от специфики проекта (его сроков, поддержки, повторяемости, и пр.). В некоторых случаях куда предпочтительнее обойтись smoke тестами и пользовательским бета-тестированием и выполнять приёмку через product owner’a, чем усложнять процессы. Так же должно быть чёткое понимание приёмки продукта: верхнеуровневая и низкоуровневая. В первом случае, внутри проекта, можно определить роли и принять продукт владельцу продукта, во втором возможно ограничиться, если допускают это требования, приёмкой самими инженерами-разработчиками с выпуском release notes. В случае, когда тестирование требуется всё-таки отдельное, то куда проще и эффективнее иметь поставленный менеджментом процесс жизненного цикла продукта и человека или команду инженеров, способных самостоятельно покрыть задачи развёртывания и тестирования продукта, т. е. людей, которые априори знают область, инструменты и методы, а не стадо обезьян, которых повесили на разработчиков или одного руководителя проекта.

Ремарка №1

Как ни удивительно, но этот простой тезис зачастую сознательно нарушается. Например, для аутсорсинговых компаний это хороший способ получить дополнительные FTE. В плане бизнеса попросту выгоднее продать побольше, что-то, имеющее низкую себестоимость. В опыте моей работы на Auriga, где заказчикам предоставлялись на почасовую оплату соответствующие ресурсы в количестве десятков человек — не единичный случай. Более того, такой план хорошо покрывает цели стаффирования проекта для клиента при минимальных затратах. Несмотря на то, что нагрузка на менеджера проектов значительно возрастает, при грамотном руководстве это пусть к созданию «кузницы кадров» за счёт проекта, привязки кадров к компании (обучение и рост навыка) при сравнительно большей цене покупке специалиста с рынка, и последующая перепродажа, ротация персонала на более требовательные проекты.

Ещё одной причиной такой стратегии является возможность покупки нецелевых кадров для клиента. Так уж получается, что требования к кадрам ваших работодателей или клиентов иногда бывают недальновидны (о чём речь пойдёт ниже), и меньшими затратами для компании (по деньгам и времени) является возможность покупки фиктивных кадров. Скажем, покупка такого рода «обезьян» на проект с параметром «20 лет стажа» (но, возможно будучи весьма посредственным специалистом). Это особо актуально в системе грейдов Junior/Standard/Senior многих компаний, особенно за пределами России, где требования к стажу и реалии немного иные.

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

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

Тезис №2: Тестировщик — это инженерная профессия

Из-за мешанины с обезьянами в профессии тестировщиков хватает людей, далёких от инженерной сферы, и не имеющих подчас даже соответствующего технического образования. Это действительно грустно и печально, т. к. квалифицированных ресурсов на рынке тестировщиков сегодня действительно не хватает — грамотные специалисты предпочитают уходить в разработку (в лучшем случая близкую к теме аналитику), а те, что остаются, имеют скудное представление о жизненном цикле ПО, тестировании и языках программирования.

На мой взгляд, любой тестировщик должен обладать техническими знаниями, уверенным владением и хотя бы базовыми навыками администрирования прикладных программ и популярных ОС. Кроме того, тестировщик должен иметь хотя бы базовое представление о языках программирования, уметь читать код хотя бы на интуитивном уровне, а также быстро адаптироваться к новым языкам и программам/средам. Вообще, главные особенности тестировщика — это гибкость и обучаемость. Поэтому, имея опыт в программировании и общее представление о скриптовых языках и языках высокого уровня, человек сможет обучиться и адаптироваться без особых проблем. В идеале требуется знание скриптового языка и основ языка разработки, на котором и базируется проект.

Из всего этого вытекает, что тестировщик обязан уметь работать с кодом. Хотя, в идеале, хороший процесс должен исполняться по модели чёрного ящика. Тем не менее в него, в этот ящик Пандоры, тестировщик должен не бояться заглянуть и помочь разобраться с проблемой разработчику. То есть быть как рыба в воде в системе не только багтрекера, но и контроля версий кода, и быть способным провести ревью кода.

Несмотря на то, что я в подавляющем большинстве случаев слышу мнение, что процесс ревью кода, отладки (дебаггинг) и юнит-тестирования — прерогатива исключительно разработчиков, возьму на себя смелость утверждать, что это неправильный подход. Проблема исходит из недостаточной квалификации тестировщиков и неверного управления жизненным циклом ПО. Возможно, этот подход хорошо работает в маленьких проектах по TDD, но главная сила и возможность обеспечить высокое качество продукта — разбить сферы влияния, ответственности, обеспечить принцип раздельности (dissimilarity).Это сделает процесс разработки более прозрачным, отслеживаемым и позволит скомпенсировать «эффект замыленности глаза» у разработчиков, избежать «трюков» с их стороны.

Ремарка №2

В компании Liebherr Aerospace жёстко выстроены процессы и роли в компании. Чёткое следование специфичным для отрасли итеративным моделям. Тем не менее, инженерное крыло, инженерные должности называются для всех одинаково — Software Engineer. Акцент делается на том, что сотрудник в компании в первую очередь — специалист, инженер в области ПО. Значит, сотрудник должен разбираться в инженерных процессах, процессе разработки, тестирования, схемотехники и т.д. Тем не менее, среди инженеров присутствует обязательное разделение на специализацию: in Test, in Development, in Requirements, и пр.

Так как компания следует жёстко инженерным процессам с целью соблюдения высочайшего качества, каждая часть процесса разделена на независимых участников. На практике это означает, что каждый уровень требований пишется отдельным человеком (группой), дизайн другими, код пишется третьими, юнит-тестирование четвёртыми, функциональное тестирование — пятыми и так далее. При этом, чтобы не дать «заскучать» и «увязнуть» в рутине, людей в проекте стараются вращать по функциям, и, вполне возможно, даже на одном проекте, в разных итерациях инженер, по мере своих возможностей будет покрывать разные обязанности, и охватит различные этапы разработки ПО.

То, что каждый из этапов и типов разработки и тестирования должен покрывать разные люди следует из требований международных стандартов, таких как DO-178B (для авиации), EN 50128 (для железнодорожного транспорта) или ГОСТ Р МЭК 60880 (для атомных электростанций), и обеспечивает, в конечном итоге высочайшую отказоустойчивость на уровне процессов и в том числе в части тестирования ПО.

Тезис №3: Метрики — ерунда, если нет работы в команде

Во время почти каждого собеседования на должность тест менеджера можно услышать вопрос по поводу того, как соискатель собирается выстраивать процесс тестирования и какие метрики с проекта он собирается снимать, какие метрики будет использовать по отношению к себе. На самом деле, вариантов метрик — количественных и качественных — можно придумать немало, но особого смысла они не будут иметь до той поры, пока не будет в проекте эффективности в команде. В команде в широком смысле слова, т. е. как внутри отдела/команды тестирования, так и при взаимодействии с командой разработчиков и заказчиков из бизнеса.

На практике это означает, что бесполезно считать количество разработанных тестов (это метрика прогресса), найденных багов (в худшем случае) показателем эффективности команды тестирования, даже рейт регрессий, даже синтетических метрик на проекте (с использованием критериев важности и трудоймкости), не говоря уж о идиотских (но по-прежнему применяемых и для команды тестирования KSLOC\hour). Для менеджера проекта, возможно, будет неплохой метрикой CPI/SPI как KPI проекта, которая может базироваться на всех обозначенных и собранных тест-менеджером метриках. То есть, достаточно абстрактная и высокоуровневая оценка в зависимости от затраченных усилий и полученного результата. Но при условии, что команды работают как единый организм.

Для тестировщиков это означает, что они связующее, ведущее колесо процесса, которое сделает программное обеспечение работоспособным и соответствующим требованиям. В процессе тестирования это означает как само тестирование, так и предоставление теста повторяемости, документируемости, возможных проблем и решений проблемы (если это видно со стороны тестирования, если хватает квалификации), а так же перепроверку тестирования (VoV). Другими словами, задачей тестирования является как перепрогон и перепроверка всех возможных состояний, так и (в необходимом и достаточном случае) покрытие полной тест-стратегии и тест-плана (по крайней мере то, что обозначено в Quality Gates), вынесение багов и их разрешение через разработчиков ПО и спецификации. Т. е., с момента проверки и обнаружения бага ответственность на нём не «перекидывается» на разработчика, а сопровождается тестировщиком до его разрешения. Грубо говоря, тестировщик отвечает за баги, а разработчик — за фичи.

Тут мы подошли к ключевым различиям между тестировщиком и разработчиком, кои в моей статье получаются очень близки и похожи. Тем не менее, по стилю работы разработчики обычно либо перфекционисты, либо «фичеделы» (которые любят кодить ради кода, функциональности и алгоритмов); тестировщики же — либо педанты, либо автоматизаторы (стремящиеся автоматизировать автоматизацию). Поэтому в проекте тестировщик знает, как правильно сделать, а разработчик — как именно.

Исходя из этого, повторюсь, что главное — это результат, зависящий от единой команды, а не только от метрик в одном прогрессе, скажем, разработки дизайна. И где процесс проседает больше — там и кроется проблема, там и падают реальные метрики, которые уже в контексте работающего синергического проекта обретают смысл. Вполне возможно, что долгая разработка тестов не вина дизайнера, а вина аналитика, транстировавшего требования слишком сложно.

Ремарка №3

Несмотря на то, что описанная мною модель говорит о единстве и взаимосвязанности всех этапов процессов, сегодня тестировщиков правильнее классифицировать всё-таки на разработчиков самих тестов (акцентирующих силы и знания на методологии тестирования) и devops инженеров, обслуживающих инфраструктуру. Сегрегация функций имеет свои плюсы при достаточно большом размере проекта и хорошем финансировании, когда развитие, поддержку и тестирование инфраструктуры можно разнести между инженерами, в идеале — между экспертами-специалистами. Важным моментом является то, что тест-инженер всё-таки в первую очередь инженер, разработчик в тестировании, способный использовать различные инструменты для разрешения поставленной задачи. И только во вторую очередь — эксперт в какой-то определённом инструменте и программе. Знатоков инструментария, возможностей фреймворков правильнее классифицировать как отдельных инженеров, инженеров-инструменталистов (tool engineer).

Тезис №4: Тестировщик — центр процесса разработки ПО

В V-модели разработки ПО наглядно видно, что тестировщик участвует на всех этапах жизненного цикла.

Схожесть разработчика и тестировщика, размазанность границ области при наличии хорошей квалификации — главный показатель интереса в работе тестировщика. Конечно, можно утверждать, что причастность к продукту и его качеству в случае тестирования чёрного ящика является мотивационным фактором, но, на мой взгляд, человек, пришедший в техническую, инженерную область сделал это осознанно, с желанием развиваться и работать над собой. Поэтому возможность расширять свой кругозор, влиять на качество продукта, (пусть даже небольших вещей), проявлять активность, а также накладывать вето на выпуск продукта у тестировщика, по моему мнению, более весомые аргументы за профессию. А раз так, раз хороший тестировщик — не обезьяна, а инженер-исследователь, знаток, принимающий участие на почти на всех этапах жизненного цикла по (в отличие от ролей аналитиков, дизайнеров, разработчиков, и технических писателей), ответственный за качество продукта (не процесса, это к QA, так что под «качеством продукта» будем подразумевать соответствие заявленным и утверждённым требованиям и стандартам, чеклистам и прочая), то для поднятия качества продукта и развития себя, как специалиста, тест-инженер должен проявлять активную позицию. Он знает, как улучшить продукт. Знает, что такое «достаточно хорош», и как его, продукт или процесс, таким сделать, инициировать движение как инженера-разработчика, так и других команд и даже компаний. Например, в любых проектах бывают моменты простоя, который может быть допустим со стороны руководства. Обычно в это время сотрудники решают личные проблемы или занимаются самообразованием. В отношении работы разработчик может заняться рефакторингом, поизучать алгоритмы и перенести на свои проекты. А что делать тестировщику? Осваивать новые средства тестирования? Он-то ничего не делает без изначального пакета от разработчиков/аналитиков. В действительности, он может заняться автоматизацией своей деятельности или улучшением продуктов, им используемых, даже если он далёк от инфраструктуры и devops.

Ремарка №3

В Liebherr Aerospace жёсткий процесс резко ограничивал использование любых инструментов и жёстко формализовал процесс разработки и тестирования, т. е. простора для автоматизации оставалось не так много — даже вмешательство в багтрекер было запрещено. Тем не менее, такой процесс, как подготовка документации, был в такие периоды автоматизирован, пусть и с использованием не находящегося под запретом VBA для MS Office. А для процесса код ревью можно было улучшить статические анализаторы кода. Они не совсем удовлетворяли стандартам на проекте и порождали лишние сообщения, которые не фильтровались даже элементарным grep. Тем не менее, чтобы уменьшить время на ручное ревью кода, в рамках простоя мы работали на перспективу, улучшая сторонний продукт, такой как статический анализатор, подготавливая набор кейсов для него для имплементации нужных нам проверок.

Тезис №5: Тестирование — не место для фиксации на ключевых словах

Последней и самой странной темой, на мой взгляд, является весьма смутное представление о тестировании (даже о теории, не говоря о практике). Во многих компаниях отделы тестирования не оправдывают надежд, в некоторых даже дискредитировали себя и функционируют на малую часть от своей потенциальной эффективности по ряду факторов. Проблема проистекает как из-за отсутствия школы, так и из-за некомпетентности менеджмента. Ситуация весьма плачевная в отраслях, отдалённых от IT, даже где «деньги — не проблема» — там задачи ставятся по принципу «повысить качество продукта». Даже в IT-компаниях, где есть общее представление о процессах, есть целый ряд проблем, связанных с фиксацией на определённых ролях или инструментах, хотя к тестированию, повторюсь, такой подход плохо применим.

В одном из крупных инвестиционных банков, в котором у меня проходило собеседование, было схожее требование на позицию тест-менеджера: «повысить качество и уменьшить брак». Любую задачу можно решить. Хотя под покровом задач скрывается координация отделов по ряду различных продуктов, составление планов тестирования, организация тестирования, работа с разработчиками, составление базы кейсов и прочая. В действительности, ответственность за качество продуктов в компании логично взять на себя какому-нибудь «директору по качеству», оно же QA Director, а не просто руководителю отдела тестирования. Однако тут дело упирается в полномочия, которых на этой позиции нет, и в отсутствие группы, которая не планировалась вовсе (которая могла бы помочь тому-тому тому-то). То есть в компанию нужен человек-оркестр без команды. Разгадка тут простая: менеджмент ищет по ключевым словам, и считая качество в аббревиатуре QA панацеей от всех проблем, хотя она лежит в сфере стратегического топ-менеджмента и процессов, которые нужно спускать сверху с соответсвующими полномочиями и ресурсами.

В идеале управление качеством (QA) и тестирование две непересекающиеся сущности.

Проблема системная, т. к. весьма неплохо, когда HR ищут по ключевым словам вроде «нагрузочное тестирование», «функциональное». Но когда в процессе рассмотрения делается акцент не на навыки тестирования, не на активность и гибкость кандидата, а на конкретный инструмент — это уже проблема, особенно когда никакого тестирования нет в помине (есть обезьянничество), и не факт, что требуемый инструмент эффективнее того, который знает соискатель. Проблема в том, что знание мелкого нюанса или инструмента, на освоение которого уйдёт несколько часов, ставится во главе угла, выше знания языков программирования или теории. В одном из интервью было достаточно смешно было отвечать на вопросы: «назовите какую-нибудь книгу по тестированию» и, ответив про Сэма Канера, услышать: «мы такого не знаем, а про жизненный цикл бага что-нибудь читали?». Это было бы смешно, если бы не было так грустно. Грустно, когда HR сообщает об отказе из-за отсутствия опыта у кандидата, хотя дело к неправильном расставлении акцентов.

Найти хорошего тестировщика — большая проблема, т. к. инженер-тестировщик — это, в идеале, человек, который разрешает технические проблемы, связанные с разработкой ПО, эдакий problem solver. Такому человеку, помимо технических навыков очень важно иметь внимательность, пытливый ум, быть активным и уметь донести мысль и отстоять свою точку зрения на любом уровне.В каком-то роде, тестировщики — это исследователи из мира разработки ПО. Поэтому в руках инженера-тестировщика легко узнаваемый символ — лупа (линза), наблюдающая за жучками. Как нельзя лучше характеризует она работу тестировщика: используется как по прямому назначению для выявления дефектов, так и для «прожигания дырочек», с её помощью можно добывать огонь и даже, имея целую систему линз, наблюдать за звёздами. Главное — уметь это делать.

Ремарка №5

В компании Intel главенствует подход, в котором инструменты выбираются из предпочтений сотрудников на проекте. Это означает, что, в целом, неважно, какой инструмент и язык выбрать для решения задачи, главное — её решить. Сосуществование трёх разных тест инженеров, пишущих на трёх разных языках вполне допустимо, если проблема решается, решается эффективно и накладные расходы на поддержку разумны, а процесс документируется. Кроме того, многие используемые инструменты являются бесплатными, open-source или собственной разработки. На сегодняшний день существует огромное количество инструментов, с помощью которых возможно решать разнообразные задачи, и выбор инструментов не должен ограничивать возможности инженера. Однако, если для задачи действительно требуется использовать какой-то инструмент, отличный от свободно доступного, то при наличии чёткого понимания и обоснования, можно купить и использовать его. Это опять-таки соответствует целям бизнеса — не забивать гвозди микроскопом, не работать эффективно, выжимая максимум из инструментов, если квалификация инженеров позволяет обойтись «малыми потерями». Хорошей альтернативой является также участие в открытых проектах и инвестиции в них для последующего использования для собственных нужд. Такой подход убивает двух зайцев (свои нужды) и задачи и создаёт инструменты для всего общества в свободном использовании.

Вместо выводов

Тестировщик — это больше, чем профессия. Это образ проактивной жизни и стремления эту жизнь сделать лучше для всех посильными и эффективными средствами. Цели тестировщика в отношении продукта наиболее близки к целям бизнеса и стратегической цели компании в отношении этого продукта, и в то же время глубоки внутри компании в роли исследователя. А раз так, то главные его качества — это энергия, знания и гибкость. Но в тоже время работа тестировщика – это не всеобщее знание и ответственность за качество продукта и качество услуг. У тестирования есть границы: с одной стороны ограниченные проектом и требованиями в нём (менеджмент проекта и установленный жизненный цикл программы), и с другой – процессами, за которые отвечает QA. Но о различия QA от тестирования совсем другой разговор.

  • тестирование приложений
  • тестирование
  • управление проектами
  • qa management

Боль тестировщика: с какими проблемами сталкиваются QA‑инженеры

Инженер по тестированию разрушает миф о том, что QA — это легко и весело.

Фото: StockLite / Shutterstock

Редакция «Код» Skillbox Media

Редакция «Код» Skillbox Media

Онлайн-журнал для тех, кто влюблён в код и информационные технологии. Пишем для айтишников и об айтишниках.

Автор статьи:

Сергей Мурашов

За последние двадцать лет программист перестал быть восьмируким божеством, которое выполняет функции целой фабрики. Роль «‎одного незаменимого» ушла за кулисы. Ны рынке IT появилось множество специализаций, а старые профессии были модифицированы и потребовали освоения новых навыков. Теперь тестировщик не просто monkey cliсker . Он стал QA-инженером — специалистом по обеспечению качества. Такой сотрудник занимается проверкой продукта на всех этапах работы — от составления документации до финального релиза.

В этой статье я не буду рассказывать о том, какие языки программирования надо знать тестировщику и почему ему нужно уметь работать с базами данных. Вместо этого мы поговорим о кризисных ситуациях, с которыми специалист может встретиться в работе. Я поделюсь своим опытом: как из них правильно выходить, чтобы сохранить репутацию надёжного сотрудника и не навредить рабочему процессу.

Советы будут особенно актуальны для тестировщиков, которые трудятся в стартапах и аутсорсных командах — мой опыт получен именно на таких проектах. В этой статье поговорим:

  • о неприятном сценарии, который может возникнуть в работе QA-инженера;
  • о том, почему в команде иногда придётся брать на себя роль проджект-менеджера;
  • как не стать крайним, если проект отстаёт по срокам;
  • почему тестировщику иногда важно побыть оратором и даже психологом;
  • как рассчитать сроки реализации проекта, чтобы снизить риск срыва дедлайнов.

Сценарий, к которому должен быть готов тестировщик

Представим себе картину. Вы приходите на проект в совершенно новую команду. Знакомитесь с аналитиками, разработчиками, девопс-инженерами. Все на удивление оказываются очень приятными людьми. Вас знакомят с задачами, обозначают их сроки, после чего вы с нетерпением и энтузиазмом, засучив рукава приступаете к…

Нет. Не к тестированию. Вы начинаете заниматься всем чем угодно, кроме проверки качества ПО. Просто потому, что доступов нет, аналитики ещё не подготовили спецификацию, а разработчика на проект нашли только в последний момент.

«Хорошо», — думаете вы и, сделав всё от вас зависящее, с нетерпением ждёте следующего спринта . Пока, наконец, программист не выложит вам первую сборку на тестовый стенд , и вы не начнёте проходить ранее написанные сценарии.

Проходит ещё две недели, и вы понимаете, что тест-кейсы уже не актуальны — требования поменялись. Разработчик внешнего сервиса полностью изменил API, и вообще — ждать выкладки на UAT не стоит.

Вы пожимаете плечами и продолжаете, словно зритель в кинотеатре, следить за развязкой остросюжетного триллера. Вот только, в отличие от купившего билет киномана, вы не подозреваете, что являетесь не только зрителем, но и участником этого фильма.

Всё чаще вы начинаете слышать слово «‎тестирование», хотя эстафетную палочку вам ещё не передали. И тут вы понимаете: что-то пошло не так. Конечно, вы знали это ещё месяцем ранее, когда руководитель проекта вдруг разрешил разработчикам не писать unit-тесты . И сказал, что пользовательское тестирование вы будете проводить уже на следующей неделе, даже без проведения smoke . Но именно сейчас вы поняли, что совершили промах. Но где именно?

Ведь вы обозначали риски, вовремя говорили о необходимости регресса и о доработках кейсов, которые понадобятся в связи с изменением документации. И всё равно тень недовольства бросилась на вас. Давайте разбираться почему.

Почему иногда придётся быть проджектом

Представим логичное продолжение нашей истории. К вам приходит руководитель проекта и недовольным голосом спрашивает: «Почему нужно так много времени на тестирование, и по какой причине оно ещё не начато?»

Вы делаете круглые глаза и говорите, что ещё неделю назад не было даже готовой документации. А разработка не загрузила итоговую сборку на стенд.

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

Пытаясь оправдаться, вы распинаетесь про важность тестирования E2E-кейсов , и говорите что вы вообще такую информацию не получали. На что руководитель заявляет: «Промах твой, так как ты недосмотрел за проектом и не довёл его до логического завершения. А в качестве кнута вот тебе минус 50% премии». Занавес опустился, в зале тишина…

«Карикатурный пример и не имеет ничего общего с реальностью», — скажет читатель и будет наполовину прав. Настолько сильную концентрацию несправедливости вы вряд ли встретите на реальном проекте. С другой стороны, с этими проблемами по отдельности вы столкнётесь не раз. Что делать в этой ситуации? Действовать самостоятельно.

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

На вашем проекте может потребоваться даже нагрузка или автоматизация. И вы узнаете об этом в самый последний момент. Как и о том, что демо должны будете проводить именно вы. И будьте уверены: ни руководитель проекта, ни кто-то другой вам об этом не скажет.

И это будет справедливо, так как именно вы ответственны за итоговый результат продукта. Вы — последний оплот благоразумности во всех смыслах: должны донести информацию и предостеречь о возможных проблемах сами.

При этом вы не должны быть дирижёром симфонического оркестра — для этого есть руководитель проекта. Но вам нужно быть концертмейстером, задавать общий темп команде и подстёгивать её там, где руководитель не видит необходимости или не может этого сделать.

Чувствуете, что разработка захлёбывается в задачах и молчит в тряпочку, — обозначаете это на статусе. Понимаете, что техническая документация не соответствует разработке, — помечайте все моменты и выносите их на обсуждение. Видите, что программист не может наладить контакт с вендором , а у вас есть для этого свободные руки — устраивайте общий конф-кол с коллегами.

Многие подумают, что такой человек в команде занимается не своими обязанностями, пытается изобразить что-то непонятное и вообще… Однако всё вышеперечисленное есть не что иное, как роль QA в команде (не путать с QC ). А это нечто большее, чем два притопа, три прихлопа. Ведь свободную неделю, пока пишется документация, можно потратить на написание тест-кейсов . Понимая, что они через две недели опять поменяются. Либо наладить коммуникацию, сделать часть работы за аналитиков и разработчиков, получив бесценный опыт.

Тут, конечно же, стоит добавить два больших «‎НО». Если у вас есть лид в команде, то все шишки полетят на него, а не на вас. Но ведь мы хотим вырасти профессионально и достичь карьерного роста? Значит, рано или поздно придётся брать ответственность на себя.

Ну и второй момент. Руководитель проекта всё равно виноват так же, как и вы. Даже если вы оба не виноваты. Бессмыслица? А вот и нет. Руководитель выбирает себе сотрудника, ответственного за проект, который будет ведущей скрипкой всего тестирования. Соответственно, если ведущий инженер не тянет позицию, значит, сплоховал именно начальник — выбрал слабое звено. Хотя, стоит признать, что иногда выбор и вовсе отсутствует.

Отслеживать работу коллег — важно

Но вернёмся к нашим нехорошим коллегам. Выдуманным аналитику Кларе и разработчику Пете, которые взяли да и свалили всю вину на нас. Можно ли винить их за это? Наверное, можно. Но так уж ли они неправы в том, как поступили?

Ведь первая сказала, что документация была готова ещё неделю назад, а второй — что нужно всё это дело тестировать на моках, пусть даже и шёпотом. Суть в том, что вам нечем крыть. Вы можете апеллировать к неправильности подходов к тестированию, разработке ПО в целом и к нечестности ваших коллег. Однако все ваши призывы без подтверждения будут не более чем сотрясанием воздуха.

Вспоминаем фразу из одного известного кинофильма: «Какие ваши доказательства?» А они должны быть. Причём всегда и на каждый случай. Хороший тестировщик не тот, кто находит все до единого бага перед релизом — это невозможно. Хороший тестер — тот, кого нельзя уличить в его виновности.

Завтра на проект придёт новый аналитик и попытается переложить всю вину на вас, но во второй раз этот фокус провернуть не удастся. Просто потому, что у вас на руках будет доказательная база — спецификация неделю назад не была готова. И вы на просьбу получить вменяемые сроки о готовности получили в письме «будет готово, когда будет готово».

И в следующий раз разработчик подумает трижды, прежде чем заявлять вам о тестировании на моках, когда увидит письмо с просьбой подтвердить готовность фронтенд-части сервиса на тестовом контуре.

Иногда нужно быть оратором и даже психологом

Мы уже поняли, что тестировщик должен быть проактивным, немного параноиком и обладать качествами лидера. Или хотя бы к ним стремиться. Дальше — больше. Для следующего примера придётся обратиться к игровому опыту читателя — в жанре классических RPG. Обычно в подобного рода играх у персонажа можно улучшать различные характеристики. В реальности такой характеристикой будет красноречие.

А зачем инженеру по обеспечению качества красиво говорить? Возможно, десять лет назад такой вопрос был бы логичен. Но не теперь, когда появилось новомодное словосочетание soft skills.

Agile привнёс не только гибкую модель разработки, но и ежедневные совещания и конференции, которые требуют коммуникативных навыков. Если вы услышите где-то шутку, что разработчик днём разговаривает, а ночью работает — знайте, это не шутка.

И если вы думаете, что в подобного рода конференциях сможете только мыкать и укать, периодически отчитываясь о проделанной работе, автор спешит огорчить — сделать этого не получится. Либо получится — но ценой подрыва качества продукта и срока его релиза.

Нужно определиться сразу: любая аудио-/видеоконференция есть не что иное, как поле битвы. Иногда оно может напоминать непринуждённый ежедневный статус, иногда — обсуждение проблемы или фичи, ещё реже — разбор полётов и пути решения проблем. Но суть игры при этом не меняется: вам нужно оставить последнее слово за собой.

Узнали, что разработка сдвигает планы по выкладке доработки на стенд? Обозначаем сроки сдвига начала тестирования и риски. Узнали, что заказчик захотел новую фичу, никому об этом не сообщив? Разработка возмущена. Но вашему возмущению нет предела. Стуча кулаком по столу, требуйте прислать письмо, чтобы зафиксировать новые требования.

Руководитель проекта говорит, что можно тестировать функциональность без фронтенда? Вы тут же парируете, что само API ещё даже не описано.

Вы не должны поддаваться на указания и просьбы смежных подразделений. Ни аналитика, ни разработка, ни руководитель проекта не могут напрямую вмешиваться в процесс тестирования и диктовать условия. Они могут лишь предложить свой вариант. Но принимать его или нет — тестировщик решает сам, опираясь на свои возможности и ресурс.

Только представьте реакцию, если QA начнёт учить разработчика писать код или будет управлять проектом за начальника. Чтобы всё это объяснить, завернуть в красивую обёртку и никого не обидеть, и нужно обладать пресловутыми soft skills.

Рассмотрим ещё одну ситуацию. Вы узнаёте, что необходимо пойти в релиз к определённому сроку. И у вас всё шло по плану до тех пор, пока разработчик не уволился, а на его место не пришёл другой. И вот проблема за проблемой, и вы теряете месяц, который нужен как воздух. И вам тут же хотят предложить альтернативу решения проблемы.

Вы выслушиваете её и где-то глубоко в сознании одобряете, но… нет, не соглашаетесь с ней. Скажите сейчас «‎ок», а завтра получите недовольство от вышестоящих, что сами на это подписались. А не подписаться вы уже не сможете. Парадокс, однако.

Зато вы можете поступить как бывалый торговец и произвести сделку наилучшим для вас образом. В психологии есть такой приём, называется «‎От большего к меньшему». Апеллируйте к возможным ошибкам на проде , к первоначальному плану, который пошёл под откос, к обозначенному ранее сроку тестирования и опасности выпуска задачи в релиз. Говорите об огромном количестве времени, которое на всё это уйдёт. А затем непринуждённо переходите к путям решения, к рискам и тем самым альтернативам.

Появляется резонный вопрос. В чём отличие от того, что предложил сам руководитель проекта пятью минутами ранее? Как минимум в том, что вы постелили себе немного соломы. И теперь, в случае обнаружения багов на проде (а они будут, это неизбежно — вспоминаем один из главных принципов тестирования), вы произнесёте своё долгожданное «‎я же говорил». И упрекнуть вас будет не за что. Ведь вы не забудете после обсуждения задокументировать всё это дело письмом.

К тому же люди легче и даже с радостью воспримут ваши предложения после пятиминутного спича, в котором вы нагоните страху и пообещаете вагон и маленькую тележку критов на продуктиве .

Можно сказать точно: поработав таким образом пять лет вы научитесь, словно заправский шпажист, с лёгкостью парировать атаки всех ваших оппонентов, будь то коллеги или заказчики. Правда, стоит предостеречь. Не пытайтесь навешать лапши всей команде. Ваши обоснования и опасения должны быть адекватны и подкреплены здравой аргументацией, которую вы сможете отстоять.

Как рассчитать сроки, чтобы не сорвать дедлайны

Ещё одно занятие, с которым вы столкнётесь (или уже столкнулись), — оценка ваших и чужих трудозатрат. С этим неизбежно работает каждый лид и не только. Первый и один из главных навыков профессионала в любой сфере — оценка своего труда. И казалось бы, что может быть проще, чем прикинуть человеко-часы по функциональному тестированию?

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

К вам приходят на тест первые три формы. Вы начинаете тестировать и вдруг понимаете, что что-то пошло не так. Формы совершенно не соответствуют спецификации, часть данных с бэкенда не подтягивается. Вы пытаетесь всё сделать по фэншую: прогоняете тест-ран с уже заготовленными тест-кейсами и заводите с десяток багов.

В итоге выясняется, что разработчик не успел посмотреть последние изменения по спецификации и внести их в последнюю сборку. Все три формы по большей части возвращаются на доработку. Вы потратили целый день, а в итоге не протестировали ничего. На деле, конечно, протестировали, но это не отменяет того, что изменения будут большими и вам придётся прогонять тест-ран с нуля.

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

Но вот незадача. Вечером того же дня к вам приходит руководитель проекта и спрашивает, заложили ли вы время на исправление дефектов? Написана ли тестовая документация для пользователей с подготовкой тестовых данных? Заложено ли проведение обязательного регресса на дополнительном стенде? Выпучив глаза, вы понимаете, что первый пункт вы, допустим, закладывали, но о вторых двух слышите впервые.

Как не допустить такой ситуации? Задавать правильные вопросы. Представьте, что вы пришли на новый проект и заказчик хочет, чтобы вы провели тестирование. Ваши вопросы не должны ограничиваться запросами на предоставление доступов к тестовым контурам и банковским системам. Вот темы для беседы:

  • общий процесс разработки ПО;
  • жизненный цикл релиза и из чего он состоит;
  • возможность тестирования на заглушках ;
  • подготовка тестовых данных пользователя;
  • процесс сопровождения пользовательского тестирования;
  • необходимость нагрузочного тестирования, автоматизации и регресса.

Это лишь вершина айсберга. Без этих знаний вы не сможете дать вменяемую оценку трудозатрат. Помимо этого, не стоит забывать ещё о двух вещах. Они встречаются практически на каждом проекте. Разработка часто оценивает своё время без учёта накладок. Когда они случаются, несут ответственность именно те, кто стоит с правого края цепочки разработки программного продукта.

И вот до выпуска в прод у вас остаётся две недели, разработчики только сегодня выложили свою часть доработки, глубоко выдохнув. Затем прибегает руководитель проекта, рвёт на себе волосы и что-то кричит про тестирование, а у вас на тестовом контуре ещё конь не валялся.

Можно ли избежать такой ситуации? Разумеется — нет. Вы не Господь Бог, вы не можете отвечать за действия всей проектной команды, за неожиданные хотелки заказчиков и скупой менеджмент с коммуникацией.

Однако, даже если вы не Господь Бог, вам можно и нужно надеть на себя мантию пророка. Ибо просчитать аховую ситуацию, в которую катится проект, вы запросто сможете. Достаточно просто посмотреть на дорожную карту проекта со сроками окончания разработки.

Главное, что стоит понять сразу, — оценка и риски неразрывно идут друг за другом. Аналитика и особенно разработка не будет волноваться о рисках — просто потому, что ни первым, ни вторым не сдавать продукт в релиз. И не они будут находиться у финишной черты перед его выпуском в продакшен. Думать о рисках — именно ваша задача. Желаю успехов в тестировании!

Читайте также:

  • Сколько зарабатывают тестировщики и QA-инженеры в России: исследование Skillbox Media
  • Тест для олдскульщиков: как хорошо вы помните старые компьютерные технологии?
  • 15 книг по тестированию программного обеспечения

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *