1. Твои ежедневные рабочие обязанности?
Моя главная обязанность: следить за тем, чтобы изменения компонентов не приводили к возникновению кроссбраузерных проблем.
Каждый человек, который заходит на сайт Twitter, должен иметь плавный опыт, независимо от браузера.
2. Разве это не делает тебя обычным тестировщиком?
Не уверена. Может быть. Честно говоря, я не могу дать четкое определение ни на одного технаря, работающего в Долине сейчас, кажется, мы «делаем всё».
Пишем код. Тестируем код. DevOps. Митинги по продукту. И всё прочее.
3. Как узнать, когда тестирование пора завершать?
Зависит от ситуации. Есть 2 типа ситуаций.
В одной из них вам нужно исчерпывающее тестирование, в другой — нет.
Исчерпывающее тестирование должно применяться только для критически важного программного обеспечения, где вы рискуете потерять жизнь или нанести другой серьезный ущерб.
В других ситуациях оно не имеет смысла, поскольку затраты слишком высоки.
4. Что большинство тестировщиков делает неправильно?
Я вижу, что некоторые разработчики уделяют особое внимание доступности, но, похоже, они не понимают эту концепцию правильно.
Идея Accessibility заключается в том, чтобы сделать ваш сайт доступным для как можно большего количества людей.
Но я вижу узкий фокус на инвалидности пользователей.
Не говорите о доступности, если вы не тестируете сайт в Firefox и Safari.
У вас может быть 0,01 % пользователей, которым требуются программы чтения с экрана, но у вас, например, 24 % пользователей, которые не используют Chrome.
К вашему сведению, Safari — второй по популярности браузер для настольных компьютеров во всем мире.
Вам нужно тестировать на Safari, это и есть Accessibility.
5. Какие инструменты используете в Twitter? Подойдут ли они и нам?
Мы используем очень много инструментов и сервисов тестирования.
Инструмент полезен только в том случае, если он помогает экономить время и деньги.
Вот два моих любимых: Postman и Endtest.
Мне нравится, что ни один из них не требует скиллов программирования.
6. Почему тестирование пользовательского интерфейса везде переходит на JavaScript?
Это не так. Кто вам это сказал?
Существует два основных способа функционального тестирования пользовательского интерфейса.
Через слой JavaScript или через слой WebDriver.
Вы всегда должны стремиться проводить функциональное тестирование через WebDriver, потому что он имитирует реального пользователя.
Тестирование через JavaScript имеет следующие недостатки:
1. Оно не может работать с несколькими вкладками браузера.
Как вы собираетесь сделать проверку электронной почты из потока «Регистрация»?
Вам нужно перейти по ссылке из письма, чтобы убедиться, что она работает.
2. Он едва справляется с iframe.
Как вы собираетесь тестировать интеграцию со Stripe?
3. И что хуже всего, он не имитирует реального пользователя.
Вы когда-нибудь пытались сделать клик с помощью JavaScript?
Этот клик сработает, даже если элемент скрыт или закрыт другим элементом.
Ваши тесты будут зелеными, но у пользователей будут проблемы.
Используйте JavaScript для модульных тестов, но не для функциональных UI-тестов.
Помните, что браузер — это не просто интерпретатор JavaScript.
7. Инструменты тестирования: создавать самим или покупать?
Опять же. Зависит от ситуации.
У нас огромный штат R&D, но даже мы обычно избегаем создания собственных инструментов тестирования.
Так или иначе, вам все равно придется платить.
Если вы покупаете инструмент, у него есть ценник.
Если же вы создаете свой собственный, то деньги и время, вложенные вами и вашими коллегами, выльются в значительные расходы для компании.
Вы же не работаете бесплатно?
8. Какой процесс стоит за этим? Как вы принимаете это решение?
Начинаем с составления списка требований.
Есть ли на рынке хотя бы один инструмент, который отвечает этим требованиям?
Хорошо. Подпишитесь на бесплатную пробную версию. Проведите POC. Посмотрите, подойдет ли он вам.
Если ваш кейс использования уникален, возможно, вам придется действительно собрать фреймворк.
В обоих случаях необходимо рассчитать возврат инвестиций.
Сколько времени и ресурсов вы вкладываете в эту инициативу и какую отдачу получаете?
Если мне нужен инструмент, я хочу начать использовать его сегодня. Я не хочу ждать полгода, чтобы попробовать инструмент, который всегда находится в состоянии «почти готов».
Ожидание в течение полугода означает, что я не получу никакой пользы за это время.
9. Но почему я вижу людей, постоянно создающих собственные инструменты для тестирования?
Не думаю, что в Кремниевой долине вы найдете кого-то, кто этим занимается.
Эта практика устарела.
Возможно, тестировщики — это такие любители, им нравится что-то создавать.
Или, может быть, у них уникальные ситуации, связанные с IoT или умными устройствами.
Но создание классического внутреннего фреймворка тестирования с помощью библиотек Selenium и неоптимизированного кода со StackOverflow не приведет вас к успеху.
10. Как узнать, достаточно ли хороши мои автоматизированные тесты?
Идея автоматизации заключается в том, что она помогает экономить время и деньги.
Ваши тесты должны выполняться в фоновом режиме, в облаке. Параллельное выполнение нескольких тестов. Полная регрессия менее чем за 15 минут.
Они должны быть тесно интегрированы с вашей системой CI/CD, но не зависеть от нее.
Если вы (все еще) запускаете их вручную или просматриваете результаты вручную, ваши процессы нуждаются в совершенствовании.
11. Дай какой-нибудь общий совет.
Начните тестировать свой сайт в Safari.
Он превзошел Firefox и не собирается останавливаться на достигнутом.
И Apple не собирается использовать Chromium в ближайшее время.
