Home

Автор: Катрина Клоки (Katrina Clokie)

Оригинал статьи: http://katrinatester.blogspot.ru/2016/12/take-control-of-your-test-environment.html

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

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

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

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

Стабильность билда

Иоана говорила про техники, способствующие стабильности автоматически собираемых билдов. Она сравнила подход, когда результат сломанного билда – это наказание (например, носить смешную шляпу или заплатить штраф, если по твоей вине сломался билд) с более позитивным подходом: к примеру, счетчик дней, прошедших с того момента, когда билд в последний раз падал. Не раздувайте из ошибок слонов, отмечайте своих успехи!

Мы начали говорить о том, как мы работаем над стабильностью своих билдов в наших командах и коллективах.

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

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

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

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

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

Автоматизация

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

Мнения, честно говоря, были смешанными.

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

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

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

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

Ключи к тестовому окружению

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

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

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

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

Люди

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

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

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

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

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

Заключение

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

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

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

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

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