Процесс - это ключ к отличному программному обеспечению.
В целом отрасль сделала большой шаг вперед в процессах разработки программного обеспечения. Но процессы тестирования по-прежнему остаются архаичными.
Инженеры-тестировщики вынуждены вручную обрабатывать тесты и ошибки в конце каждого цикла разработки.
Результат? Тонна потраченного впустую времени и энергии на протяжении всего процесса.
Гибкая разработка кардинально отличается от водопада, который представляет собой более старую и более жесткую методологию разработки программного обеспечения.
Наша команда практикует agile. Но как руководитель группы инженеров-тестировщиков я заметил, что наш процесс контроля качества больше похож на водопад.
QA Waterfall
Начинаем тестирование по окончании процесса разработки. Это оставляет инженеров-испытателей тесными и ограниченными во времени. Можно сказать, что QA-тестирование в Agile - это сжатая версия водопада.
Хотя в Agile-методике тестирования за сеанс меньше, чем в водопадном, этот процесс мог бы быть намного более эффективным. Во-первых, когда тестирование проводится в конце, оно часто бывает очень срочным и требует времени. Это заставляет инженеров-тестировщиков оптимизировать скорость, что обычно означает тестирование продуктов вручную.
Очевидно, ручное тестирование работает. Но есть так много аспектов этих тестов, которые можно было бы автоматизировать, если бы у инженеров-тестировщиков было больше времени для написания сценариев для тестирования программного обеспечения.
В последующие недели затраты времени на ручное тестирование увеличиваются, так как QA вручную тестирует новые сборки того же программного обеспечения. Вместо этого они могли бы создать автоматизированные сценарии для тестирования большего количества программного обеспечения, что сняло бы его с тарелки инженеров-тестировщиков и обеспечило бы более быструю обратную связь для инженеров-программистов.
В Flipp мы пробовали тестировать программное обеспечение вручную, старомодным способом. Но мы столкнулись с собственными неудобствами и проблемами.
Например, любая задержка в системе или выпуск функции повлияет на команду QA через неделю. Такие задержки усугублялись бы до такой степени, что команда разработчиков программного обеспечения была бы намного впереди QA, а QA отчаянно пыталась бы наверстать упущенное.
Одним из распространенных решений проблемы, когда команда разработчиков слишком далеко опережает команду тестирования, является запуск бага. Таким образом, команда разработчиков может протестировать все ошибки, чтобы помочь команде QA наверстать упущенное до конца спринта.
Мы реализовали еще более простое решение: команды разработчиков с самого начала включают инженеров-тестировщиков.
Таким образом, инженеры по тестированию могут определять сценарии и писать сценарии для тестирования, с помощью которых будет тестироваться новый код группы разработчиков. По мере того, как разработчики создают реальное программное обеспечение, инженеры-тестировщики могут создавать сценарии для тестирования этого программного обеспечения, которые можно использовать снова и снова каждую неделю. Что наиболее важно, это в совокупности экономит массу времени, внимания и энергии при последующем тестировании.
В Flipp наша команда QA задает множество вопросов о точности и тестируемости проекта на ранней стадии, поэтому нам не нужно проходить цикл QA, чтобы обнаружить ошибки в системе. Мы ставим это под сомнение с самого начала. Некоторые стандартные примеры наших вопросов о точности:
- «Какую нагрузку мы ожидаем?»
- «На какие аналитические маяки мы полагаемся, чтобы измерить успех проекта?»
- «Как мы собираемся сделать его тестируемым, чтобы его можно было легко развернуть?»
Вот преимущества, которые мы заметили при внедрении этого решения, и почему мы считаем, что каждой компании необходимо переосмыслить методы проверки качества.
Более быстрая обратная связь, чем Agile
В целом продолжительность цикла спринта варьируется от проекта к проекту. Но, например, скажем, каждый спринт состоит из пяти дней.
В первые три дня инженеры-программисты пройдут через систему тикетов - построят функции и заполнят тикеты. По завершении они передают свою сборку QA. У инженеров по тестированию есть последние пару дней, чтобы изучить эти билеты.
Это будет типичный цикл спринта как в Agile, так и в каскаде: планирование, разработка, код и тестирование.
Я упоминал об этом ранее, но я действительно хочу четко сформулировать:
Вместо того, чтобы оставлять тестирование в конце, мы должны внедрить тестирование с самого начала (на этапе «планирования») и начать задавать вопросы. Как инженеры-тестировщики, нам нужно будет выяснить, как тестировать и какие системы нам нужно построить, чтобы мы могли протестировать это с самого начала.
Обычно инженеры-программисты отправляли сборку инженерам-тестировщикам, которые затем вручную проводили тестирование и отправляли обратно разработчикам программного обеспечения, если в коде возникали какие-либо проблемы или ошибки. Будет задержка в 1-2 дня, поскольку QA может работать над предыдущими заявками. Разработчикам программного обеспечения придется подождать, пока эта заявка не будет заполнена. Итак, если QA-тестирование проводится вручную:
- Инженеры-испытатели назначают время для проведения тестов
- Программные инженеры теряют время и силы на переключение контекста между разными тикетами
- Инженеры-испытатели тратят время на тесты
Довольно неуклюжий, правда? Давайте посмотрим, как может работать автоматический тест:
Инженер по тестированию создает сценарий, в котором каждый раз, когда кто-то вносит изменение и развертывает его на серверах, тест гарантирует, что не будет ошибок 500 или ошибок JavaScript. Если тест обнаружит любую из этих ошибок, сборка не прошла этот тест, и инженеры-программисты будут уведомлены через несколько минут. Никому не нужно ждать 2–3 дня, это происходит автоматически. Эта чрезвычайно быстрая обратная связь позволяет команде разработчиков программного обеспечения действовать намного быстрее.
Быстрая обратная связь дает значительную экономию, особенно в случае простых и очевидных ошибок. Это также сводит к минимуму переключение контекста, на что не обращают внимания.
Подумайте о том, что думают инженеры-программисты, когда им нужно вернуться к сборке, которую только что отправил инженер-тестировщик. «Что это была за особенность снова? Что это за ошибка? Как мне это исправить? »
Здесь в течение пяти минут они узнают, что этап тестирования завершен и требует ли он дополнительной работы.
Естественно, что по мере усложнения ПО усложняются и тесты.
Минимум чрезвычайных ситуаций
Поскольку QA рассматривает ситуации с самого начала процесса разработки программного обеспечения и не ждет до конца, чтобы вручную протестировать сценарии и ситуации, у них будет больше времени для прогнозирования чрезвычайных ситуаций или рассмотрения более широкого круга обстоятельств.
Это настолько близко к нулю аварийных ситуаций, насколько это возможно для инженеров по программному обеспечению и тестированию. Очевидно, что непредвиденные ошибки все равно возникают. Но теперь у команды есть лучшее представление о том, как собирать и понимать данные, а также о том, как ошибка влияет на пользователей.
Например, предположим, что пользователи сообщают об ошибке с ползунком скидки в приложении Flipp. Инженер-тестировщик посчитает, что аналитические маячки необходимы для быстрой проверки масштабов и значимости ошибки. Из-за этих мер они могут просмотреть данные и уведомить команду: «Это влияет только на 1% наших пользователей». Они могут определить, что то, что казалось чрезвычайной ситуацией, на самом деле не так.
Стандартная команда QA негибка и не допускает ошибок. Здесь есть толерантность, позволяющая пропускать более мелкие ошибки, чтобы инженеры-тестировщики могли сосредоточиться на более приоритетных и более широких ошибках. Они могут более точно оценить риск ошибок и то, что происходит. Если воздействие минимально, инженеры-тестировщики могут отметить это и попросить инженеров-программистов исправить это в следующем спринте.
Изобретая культуру вашей команды разработчиков программного обеспечения
В конечном итоге включение инженеров-тестировщиков в процесс разработки программного обеспечения - один из симптомов более значительного сдвига в культуре. Перспективы инженеров-испытателей теперь будут рассмотрены на более раннем этапе процесса.
Что касается разработки тестов, инженерам-тестерам нужно быть более любопытными, чтобы увидеть, как они могут улучшить систему и улучшить ее качество.
Сдвиг будет в том, что все - владельцы продуктов, мастера схватки, инженеры по тестированию и разработчики программного обеспечения - примут эти вопросы раньше и рассмотрят их.
Это объединит команду и поможет лучше понять, как выглядит успешная функция.
Как правило, ведущим разработчикам и владельцам продуктов требуется x дней, чтобы довести что-то до конца. Но их определение «готово» отличается от определения QA. Их определение «готово» - это отправить программное обеспечение в QA. В отличие от этого, QA определяет «готово», когда программное обеспечение может быть выпущено для пользователей.
Подробное описание того, как мы делаем QA в Flipp
В заключение я приведу вам конкретный пример того, как это может выглядеть, когда ваша команда разработчиков программного обеспечения создает и тестирует функцию. Давайте пройдемся по различным этапам двухнедельного спринта и определим роль, цели и приоритеты инженера-испытателя на каждом из них.
Обратите внимание, что в Flipp мы называем наших инженеров-тестировщиков «тестируемыми инженерами-программистами». Для ясности в этой статье мы называем их инженерами-тестировщиками, но этот сдвиг в формулировках в нашей организации отражает то, насколько на самом деле встроен QA в команду разработчиков программного обеспечения.
Этап 1: Концепция
Этот этап происходит в первый день, когда функция еще не более чем идея. У команды нет особой ясности в отношении этой функции (около 10%). Они знают об этом, но не знают точно, как это будет построено.
Самая важная задача инженера-тестировщика на этом этапе - досконально понять и, возможно, помочь определить, что означает успех для владельца продукта. Некоторые компании называют эти определения «критериями приемлемости».
В любом случае я предпочитаю использовать наводящий вопрос: «Что выигрывает?»
Выяснение ответа - и соответствующих ключевых показателей - станет основной задачей всей команды на этапе разработки концепции.
Этап 2: макеты и дизайн
Этот этап также происходит в начале спринта (обычно в первый день), когда функция была определена немного более четко (около 30%). Понимание инженером-тестировщиком функции изменит способ ее тестирования, а понимание желаемого поведения пользователя будет влиять на процесс тестирования.
Владелец продукта может определить победу как выполнение пользователем определенного действия. В таком случае инженер-тестировщик должен помочь определить, как провести пользователя туда. Когда команда начинает готовить мокапы, некоторые потоки или концепции могут не иметь смысла. Работа тестировщика и команды состоит в том, чтобы создавать мокапы, которые не соответствуют пользовательскому потоку или не приводят к победе.
Инженер по тестированию не обязательно выполняет функции обеспечения качества, но все же вносит свой вклад в качестве члена команды. Они должны помочь идентифицировать разные профили пользователей и разные способы использования приложения (например, персонажи). Самым важным для инженера по тестированию на этом этапе по-прежнему является понимание: понимание функции в целом, а не отдельных элементов заявки.
Этап 3: билеты
Билеты на программное обеспечение составляют основную часть спринта. Потенциально это могло произойти с 1 по 10 день. Билеты делают эту функцию более понятной (около 60%).
По мере того, как инженеры-программисты работают над функцией и разрешают заявки, инженеры-тестировщики создают небольшие тесты, чтобы убедиться, что функция будет построена правильно. Билеты делают функцию более конкретной. По мере того, как функция становится более определенной, методы тестирования становятся понятнее. Инженер-испытатель должен также построить конвейеры, чтобы обеспечить более быструю обратную связь.
Это много информации, поэтому я рекомендую инженеру-тестировщику начинать буквально с создания одного теста, который будет запускаться после каждой фиксации или любого изменения. Я бы порекомендовал сначала построить сценарий счастливого пути, а затем перейти к более подробным тестам.
Когда инженер-тестировщик выполняет эти другие более подробные тесты, он также должен определить другие пути: что произойдет, если пользователь повернет экран? Что будет, если они отменит? Что произойдет, если у них будет странная комбинация функций? Как насчет потенциальных критических сбоев функции (например, обеспечение загрузки страницы и предотвращение ужасной ошибки 500 или обеспечение точной записи действия на веб-странице в базу данных).
Некоторые из этих путей будут частыми, другие - менее распространенными. Инженер-тестировщик должен расставить приоритеты в отношении тех, которые он должен тестировать. Я рекомендую оценивать по этим двум критериям:
Как это повлияет на выручку или ключевые бизнес-показатели? Инженер-испытатель должен упростить людям возможность добраться туда, куда они хотят. Например, в Flipp мы хотим максимально упростить пользователям доступ к желаемому флаеру. Любое препятствие снижает качество.
Влияет ли это на удержание? Инженер по тестированию должен убедиться, что приложение не аварийно завершает работу или пользователи не закрываются по незапланированной причине. Им также следует подумать о том, как вернуть пользователей или побудить их снова открыть приложение.
Самым важным для инженеров-тестировщиков является то, что они расставляют приоритеты в том, что обнаруживается, исходя из своего определения победы. Они также должны идентифицировать риски по всей функции на основе использования, воздействия и вероятности реализации этого сценария. На скольких людей повлияет билет? Насколько глубока проблема? Если приложение все-таки выйдет из строя, восстановить его будет сложно?
Этап 4: Обеспечение качества и тестирование
Гарантия качества и тестирование проходят с 5 по 10 день (вплоть до выпуска). К этому моменту функция должна быть ясна на 90–100%.
Когда заявки решены, инженеры-тестировщики должны взглянуть на свою стратегию, которую они разработали на предыдущих этапах, и приступить к реализации своего плана. Они будут работать с разработчиками программного обеспечения для большей ясности или устранения ошибок.
Здесь важнее всего для инженеров-тестировщиков убедиться, что все функции, связанные с победой, понятны. То, что нужно сделать или что нужно сделать, не будет исправлено, если не будет дополнительного времени.
Этап 5: Выпуск / развертывание
Выпуск происходит в последний день (гипотетический день 10). Работа инженера-испытателя должна гарантировать плавность выпуска. Перед выпуском они должны протестировать эту функцию на реплике производственной системы. У нас есть специальный контрольный список после релиза, который мы используем, чтобы поддерживать последовательность. Не буду утомлять вас подробностями.
Когда функция запускается, инженеры-тестировщики должны внимательно следить за данными, чтобы убедиться, что они в рабочем состоянии, и просматривать журналы сбоев. Мы люди, поэтому все мы иногда что-то упускаем даже после тестирования. Могут произойти события, которых не предвидят даже самые внимательные инженеры по тестированию.
Более продуманная гарантия качества начинается с рассмотрения возможности тестирования в начале процесса разработки программного обеспечения. Это означает, что инженеры-испытатели знакомятся с разработчиками программного обеспечения в начале цикла тестирования и рассматривают сценарии и возможности с самого начала. Это сделает процесс разработки более интеллектуальным и, что наиболее важно, приведет к созданию лучшего программного обеспечения.
Я Дервин, директор по тестированию компании Flipp. Частичную версию я опубликовал в блоге Flipp. Если вы хотите изменить то, как люди покупают вещи, ознакомьтесь с нашими текущими объявлениями о вакансиях.
