Текст книги "Как тестируют в Google"

Автор книги: Джеймс Уиттакер

Соавторы: Джефф Каролло,Джейсон Арбон
сообщить о нарушении

Текущая страница: 17 (всего у книги 26 страниц)

Бесплатное тестирование

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

Почему нам это интересно? Работает простая схема: если тестирование бесплатно, маленькие компании и стартапы смогут позволить себе тестирование. Если тестирование бесплатно, интернет становится лучше, а это интересах пользователей и Google.

Мы представляем, что бесплатное тестирование это:

– почти нулевые затраты;

– мгновенное получение результатов;

– минимум человеческих ресурсов;

– супергибкость. Мы не верим, что всем может подойти одно и то же.

Чтобы задача соответствовала времени и остальным проектам Google, мы решили начать с веб-тестирования, надеясь, что к моменту завершения работы весь мир все равно будет работать в облаке, а драйверы и COM останутся в прошлом. Мы знали, что если будем создавать бесплатный продукт, то при любом исходе получим что-то интересное.

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

1. Планирование с GTA.Основанное на анализе рисков, быстрое и автоматически обновляемое планирование тестирования.

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

3. Оценка багов.Обнаруженные различия автоматически передаются специалистам для оценки. Итак, регрессия или новая фича? Здесь поможет BITE, который показывает информацию о заведенных багах в контексте этой оценки.

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

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

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

7. Развертывание новой версии и возвращение к шагу 1.Повторяем все заново.

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

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

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

Рис. 3.49. Сквозной процесс бесплатного тестирования

Инновации и эксперименты в тестировании
Джеймс Арбон

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

Когда Джеймс Уиттакер пришел в Google, первым делом он организовал внутреннюю встречу технических специалистов и рассказал, каким он видит будущее тестирования. В его понимании тестирование должно напоминать видеоигры: как и в шутерах от первого лица, на тестируемое приложение должна накладываться полная контекстная информация. Мало кто мог представить, что его доклад на конференции GTAC [61]61
  Презентация Джеймса Уиттакера на конференции GTAC, посвященная будущему тестирования, доступна на YouTube по адресу http://www.youtube.com/watch?v=Pug_5Tl2UxQ


[Закрыть]задаст тон работе на несколько лет вперед. Конечно, на слайдах его идеи смотрелись хорошо, но построение общего решения для всех клиентских приложений казалось делом очень дорогим и сложным.

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

Вскоре у меня была рабочая демоверсия с расширением Chrome, которая работала с Python App Engine [62]62
  App Engine – облачный сервис Google для размещения сайтов и сервисов. Тестировщики часто используют App Engine для инструментов и инфраструктуры, так как App Engine может очень быстро наладить работу приложения и дать возможность пользоваться Google Scale бесплатно. Можно посмотреть на http://appengine.google.com. В настоящее время поддерживаются языки Java, Python и Go.


[Закрыть]и моделировала обращения к базе данных багов. Мне удалось продемонстрировать несколько интересных моментов:

– наложение информации о багах на страницу и даже на ее конкретные элементы;

– наложение тест-кейсов на тестируемую страницу с одной кнопкой для результата теста (рис. 3.50);

– тепловую карту, на которой было видно, чем раньше занимались другие тестировщики и какие значения использовали (рис. 3.51).

Рис. 3.50. Пользовательский интерфейс тестовых примеров

Рис. 3.51. Тепловая карта тестового покрытия

Технология заработала на google.com, и я начал пробовать ее на нескольких других сайтах, чтобы убедиться в ее работоспособности. Я назначил короткую неформальную встречу с Джеймсом, чтобы показать результаты своей работы и узнать, что он о них думает. Мы исписали всю доску тем, что потом стало планом для экспериментов, описанных в этой книге. Я отправил Пату Коупленду и Джеймсу письма, в которых сообщил, что теперь буду заниматься этой работой и отчитываться перед Джеймсом. Никаких вопросов не было – изменения были согласованы по почте.

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

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

Внешние тестировщики

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

Хорошим примером такой работы служит Chrome OS. Мы с самого начала поняли, что сетевые подключения Wi-Fi и 3G – очень рискованная область, потому что она зависит от производителя устройства. Облачное устройство без связи с интернетом теряет свой смысл как продукт. Более того, все обновления безопасности и версий программных продуктов тоже происходят по Сети, и если возникают проблемы с передачей данных по 3G, наша работа обесценивается. Это не та вещь, которую можно оставить на откуп неспециалистам, пусть и с благими намерениями.

Когда мы только начинали работать с устройствами, своих специалистов с нужным тестовым оборудованием у нас еще не было. Впрочем, даже если бы оно было, правильно его использовать все равно никто не умел. Поэтому тестирование проводили внешние специалисты, которые вручную переключались между 20 современными роутерами Wi-Fi. За пару недель эти ребята сообщили нам о многочисленных проблемах при переключении роутеров и о снижении скорости передачи, если квартира пользователя находится в зоне действия нескольких роутеров. [63]63
  Спасибо Райану Хоупсу и Томасу Флинну из Allion Test Labs за помощь с тестированием и сертификацией оборудования и сетевой поддержки.


[Закрыть]Конечно, были и другие проблемы, обнаруженные тестированием, но не такие важные. Мы получили графики, которые свидетельствовали о серьезном падении скорости передачи (примерно как на рис. 3.52 и 3.53).

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

Рис. 3.52. Ожидаемый график зависимости скорости передачи от диапазона

Рис. 3.53. График зависимости скорости передачи от диапазона в ранних прототипах Chrome OS

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

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

Интервью с инженером по тестированию Google Docs Линдси Уэбстер

Линдси Уэбстер – инженер по тестированию проекта Google Docs в нью-йоркском офисе Google. В компании ее знают как инженера-практика, способного привести в порядок процедуру тестирования в любой команде разработчиков. Ее подход к работе и умение влиять на команду и качество продукта сделали ее символом инженеров по тестированию в Google.

Недавно авторы пообщались с Линдси, чтобы узнать о ее методах работы.

– Как ты начинаешь работу с новым проектом? Какие первые вопросы ты задаешь? Что ты делаешь в первую очередь?

Линдси:Когда я приступаю к новому проекту, прежде всего я смотрю на него глазами пользователя. Если возможно, я сама начинаю им пользоваться через свой аккаунт и свои данные. Я пытаюсь испытать те же чувства, которые появляются у пользователя при работе с продуктом. Взгляд на программу полностью меняется, когда вы видите в ней свои личные данные. Освоившись, я начинаю изучать продукт «от»и «до». Если есть проектная документация, то я изучаю ее, а если есть отдельные описания основных фич, я и за них возьмусь. Дайте мне документ, и я его прочитаю.

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

– Число багов на разработчика или на всю команду?

Линдси:На всех! Если честно, чтобы достигнуть максимальных результатов, команду надо знать как свои пять пальцев.

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

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

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

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

– Нам даже думать тяжело о такой работе. Хорошо, что у нас есть такие тестировщики! Итак, ты расправились с документами и командой, но что-то же осталось на десерт? Само приложение?

Линдси:Точно! Как только я получаю необходимые данные, наступает пора заняться делом. Обычно я разбиваю приложение на функциональные куски. Нестрашно, если между ними будет небольшое перекрытие. Моя главная задача – создать не слишком подробную, но и не слишком общую картину, чтобы я могла перечислить все компоненты и фичи.

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

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

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

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

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

– Какое место занимает пользователь в твоей работе как тестировщика?

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

– Как разработчики оценивают твою работу? Если они недооценивают тестирование, как ты себя ведешь?

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

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

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

– Расскажи немного о своем тестировании Google Sites. Как ты подошла к проекту? Какие документы ты создавала и в каком формате? Как подала свои выводы и результаты разработчикам?

Линдси:Тестирование Sites стало настоящим испытанием. Продуктом пользовалось огромное количество людей, продукт был куплен, а не разработан в Google, и к тому же существовал в Google намного дольше остальных.

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

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

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

Я сделала общий сайт (конечно, на базе Google Sites!), где собрала всю документацию для тестирования: пользовательские истории, информацию о среде и команде тестирования, данные по выпускам и т.д. Чтобы быстро планировать тестирование для новой сборки, я использовала простую электронную таблицу со списком всех компонентов и субкомпонентов, упорядоченных по приоритету тестирования.

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

– А можешь рассказать о самом интересном баге, который ты находила, и как это произошло?

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

– Как ты оцениваешь результат своей работы?

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

– Как ты понимаешь, когда тестирование пора завершать?

Линдси:Трудно сказать. Когда тестируешь новые версии, то дата выпуска и есть финишная черта проекта. А если появляется новая версия браузера или устройства, на которых открывается наше приложение, даже если оно сейчас активно не разрабатывается, то это всегда серьезная причина продолжить тестирование. О’кей, если вы уверены, что если какие-то баги и остались, то они находятся в компонентах, фичах, браузерах, устройствах, которыми пользуются очень редко, а значит, не сильно помешают пользователям, то вы можете приостановить тестирование. Руководствуйтесь приоритетами фич и окружений, которые вы поддерживаете.

– А как исправляются баги?

Линдси:Важная часть моей работы – подталкивать разработчиков исправлять баги. Я постоянно пытаюсь оторвать разработчиков от работы над новыми фичами и отправить их исправлять баги. Чем больше жалоб на баг от пользователей мне удается собрать, тем легче мне убедить разработчика, что нужно уничтожить дефект, вместо того чтобы прикручивать новую функцию. У корпоративных продуктов в Google, таких как Sites, есть специальные службы поддержки клиентов. Я обязательно работаю с ними, чтобы быть в курсе, на что чаще всего жалуются клиенты.

– Если бы ты могла взмахнуть волшебной палочкой и изменить один аспект твоей работы, что бы это было?

Линдси:Если я скажу «все», то мое желание не исполнится? Хорошо, если бы могла, я бы создала простые, примитивные тест-кейсы или пользовательские сценарии, которые бы не надо было документировать, потому что они чудесным образом стали бы известны каждому тестировщику. Скажем, операции создание-чтение-обновление-удаление используются везде, поэтому каждый раз описывать их для каждой новой фичи утомительно. Я думаю, переход на высокоуровневые пользовательские истории вместо формализованных тест-кейсов частично решил проблему, но я бы все равно предпочла полностью избавиться от нее.

– Как твоя работа влияет на решение о выпуске продукта?

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

– Что тебе больше всего нравится или не нравится в твоей работе?

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

– Чем тестирование в Google отличается от других компаний?

Линдси:Независимостью. Я свободна в выборе проектов, над которыми хочу работать как в основное время, так и в «двадцатипроцентное», – это такая концепция в Google, позволяющая нам проводить один день в неделю, или 20% общего времени, работая над любым проектом. Это расширяет мой кругозор и поддерживает мой энтузиазм, когда кажется, что работа превратилась в сплошной «День сурка».

– Как разработчики в тестировании относятся к твоей работе?

Линдси:Разработчики в тестировании часто не считают важной работу с репозиторием багов и тестирование каждой версии, пока сами не увидят, как это влияет на продукт. Даже если они думают, что автоматизация покрывает все тестовые сценарии (да, как же!), кто-то должен заниматься исследовательским тестированием для разработки новых тест-кейсов. А еще этот кто-то должен отслеживать все баги, найденные автотестами, сравнивать их с более старыми и менее серьезными багами и отзывами от пользователей. Так как я поднимаю эти вопросы, то разработчики в тестировании обычно понимают ценность изменений, которые я приношу в проект. Если и есть такие, кто не очень уважительно относится к моей работе, это те, с кем мы еще не поработали. После совместной работы отношение разработчиков всегда быстро меняется.

– Как организовано твое взаимодействие с разработчиками в тестировании?

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