Home

Автор: Джо Колантонио

Оригинал статьи: http://www.joecolantonio.com/2015/11/03/were-all-testers-now/

Перевод: Ольга Алифанова

Когда я готовил презентацию "Ведущие тренды 2016 года" для шведской конференции OreDev, я задумался о том, как сильно изменилась индустрия разработки ПО за последние 15 лет. Я помню времена, когда специалисты по тестированию и обеспечению качества считались вторым сортом, а миром правили разработчики. И тут меня осенило: ведь сейчас все мы - тестировщики.

Смещение влево

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

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

Программа пяти шагов

Эти пять шагов очень помогли командам, с которыми я работал:

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

1. Сделайте разработчиков ответственными за тестирование

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

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

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

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

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

Я бы еще порекомендовал сделать разработчика, вносящего изменения в приложение (например, изменяющего название поля на экране авторизации), ответственным за соответствующую правку автотестов для объекта LoginPage.

2. Проводите ревью кода

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

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

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

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

3. Научите тестировщиков программировать.

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

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

4. Используйте единые инструменты.

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

Это всегда было основным препятствием для внедрения автоматизации с нуля. В этой ситуации очень сложно использовать широко известные, объектно-ориентированные принципы. К тому же это усложняет сотрудничество разработки и тестирования при автоматизации тестов. За 15 лет моей практики мне ни разу не удалось уговорить разработчика установить и использовать инструменты, которые использую я.

Но есть хорошая новость: популярные инструменты тестирования все чаще и чаще поддерживают такие языки программирования, как Java и C#. Многие из них способны интегрироваться с популярными IDE и системами контроля версий. Если вы находитесь в начале пути внедрения автоматизации - выбирайте инструменты, которые легко впишутся в экосистему вашей разработки.

5. Начинайте проект, держа в уме его тестируемость.

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

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

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

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

Обсудить в форуме