Sdet что это в программировании
SDET Интервью Вопросы
Введение в SDET Интервью Вопросы и ответы
SDET, инженер по разработке программного обеспечения в тестировании или инженер по разработке программного обеспечения в тестировании, обозначает в основном тестирование, выполняемое на программном продукте. На самом деле нужен был какой-то кандидат, способный развиваться и выполнять тестирование. Первоначально это было начато Microsoft, но в настоящее время другие организации осознают то же самое, и они действительно ищут кого-то, кто является экспертом в SDET для участия в полной разработке своего продукта, а также для участия в проекте тестирования, который необходимо выполнить. для этого индивидуального развития. Организация может внедрить один и тот же ресурс в две ключевые задачи, которые всегда будут для них выгодными.
здесь мы обсудим лучшие вопросы интервью SDET.
Теперь, если вы ищете работу, связанную с SDET, вам нужно подготовиться к Вопросам об интервью SDET 2019 года. Это правда, что каждое собеседование отличается в зависимости от профилей работы. Здесь мы подготовили важные вопросы и ответы SDET Interview, которые помогут вам добиться успеха в вашем интервью.
В этой статье 2019 SDET Interview Questions мы представим 10 наиболее важных и часто задаваемых вопросов об интервью SDET. Эти вопросы интервью делятся на две части:
Эта первая часть охватывает основные вопросы и ответы SDET Interview.
Q1. Объясните различия в деталях между разработкой программного обеспечения в тестировании (SDET) и тестированием программного обеспечения вручную?
Ответ:
SDET в основном использует тестирование автоматизации доу. Средства разработки продукта могут тестироваться автоматически без ручного вмешательства. Принимая во внимание, что ручное тестирование совсем не соответствует этим критериям.
Q2. Написать программу для перестановки чисел на любом языке?
Ответ:
public class reverseNumber (
public long reverse(long num)
(
long temp=0;
while(num!=0)
(
temp=(temp*10)+(num%10);
num=num/10;
)
return temp;
)
public static void main(String args())
(
long n= 654312;
reverseNumber inp = new reverseNumber();
System.out.println(“Given number is “+ n);
System.out.println(“Reverse of given number is “+inp.reverse(n));
)
)
Q3. Подробно объясните, как мы можем определить специальное тестирование в современной ИТ-индустрии?
Ответ:
Специальное тестирование является одним из самых популярных в ИТ-индустрии. Этот вид тестирования в основном незапланированный и без документации. Обычно это должно выполняться, когда от клиента поступают специальные требования, разработчик должен разработать их в приоритетном порядке. Теперь тестер должен немедленно проверить его и прийти с надлежащими результатами за очень короткий период времени. Документирование или планирование не всегда возможно для этого, но некоторые организации использовали некоторые специальные инструменты для отслеживания такого рода задач, особенно для дополнительного выставления счетов.
Давайте перейдем к следующим вопросам интервью SDET.
Ответ:
Приоритет и Серьезность являются двумя важными ключевыми словами в ИТ-индустрии, особенно для тех организаций, которые занимаются производственной поддержкой своего продукта или любой существующей системы клиента. В настоящее время все организации болота пытались использовать один конкретный инструмент, для которого была назначена одна группа поддержки. Обычно конечный пользователь обращается к соответствующей группе поддержки для того, чтобы сообщить о своих проблемах, или конечный пользователь может создавать свои проблемы непосредственно в этом конкретном инструменте. Некоторые сотрудники службы поддержки сначала анализируют то же самое, а затем получают приоритет в зависимости от воздействия на конечного пользователя. Сотрудник службы поддержки, тестировщик, разработчик и некоторый бизнес-аналитик в определенный момент времени занимаются этой проблемой и пытаются понять, каково ее конкретное влияние, исходя из того, что они дали серьезность этой проблеме. Таким образом, приоритет определяет, насколько важен этот вопрос, а степень его серьезности определяется способностью воздействия или разрушением этого вопроса.
Q5. Объясните детали объяснение ответственности за работу тестировщика или разработчика программного обеспечения в роли тестера?
Ответ:
Это общие вопросы интервью SDET, задаваемые в интервью. Обычно тестер SDET должен выполнять несколько обязанностей в современной ИТ-отрасли.
Q6. Что такое специальное тестирование?
Q7. Приведете пример с подробностями, касающимися типичного опыта или чрезмерной нагрузки рабочего дня у тестировщика или инженера-разработчика программного обеспечения в тесте (SDET)?
Ответ:
Три ключевые задачи всегда занимают у тестера огромное время в любой день:
Давайте теперь посмотрим на расширенные вопросы и ответы SDET Interview.
Q8. Объясните некоторые комментарии экспертов о том, как один тестировщик может решить, что предоставленный продукт действительно готов к работе в реальной среде?
Ответ:
Это одно из важнейших решений, поэтому оно никогда не принималось ни одним человеком, ни младшими ребятами. Только разработчик и тестировщик не участвуют в принятии этого решения, в этом периодически участвует высшее руководство. Тест управления в основном гарантирует, проверяя ниже для гарантии того, что доставка продукта без ошибок:
Q9. Написать программу для замены двух чисел без использования временной переменной?
ответы:
Программа для замены двух чисел без использования временной переменной выглядит так:
public class swap(
public static void main (String args())
(
int x = 20;
int y =30;
System.out.println(“Numbers before swapping”);
System.out.println(“ number x is “ + x);
System.out.println(“number y is “ +y);
// Swapping numbers
x= x+y;
y=xy;
x=xy;
System.out.println(“Numbers after swapping”);
System.out.println(“ number x is “ + x);
System.out.println(“number y is “ +y);
)
)
В10. Если кому-то нужен один конкретный формат отчетов об ошибках от тестировщика, то какой тестер может предложить лучший способ или подход для его предоставления?
Ответ:
Один отчет об ошибке обычно содержит ниже:
Давайте перейдем к следующим вопросам интервью SDET.
Q11. Объясните подробно о различных видах тестирования под названием Альфа и Бета?
Ответ:
Альфа-тестирование, выполненное тестером, выявило ошибки перед перемещением продукта в живую среду или к конечному пользователю. Бета-ошибка обычно определяется конечным пользователем, который является фактическим пользователем продукта или приложения.
Q12.Что такое риск-тестирование?
Ответ:
Риск-тестирование определяется как тестирование функциональных возможностей продукта на основе приоритета результатов. Тестирование на основе риска включает в себя тестирование важнейших функций продукта, которые окажут влияние на бизнес, и вероятность сбоя этих функций очень высока. Приоритет для всех функциональных возможностей продукта устанавливается на основе бизнес-требований, затем сначала проверяются функциональные возможности с высоким приоритетом, а затем функциональные возможности с низким и средним приоритетом. Проверка на основе риска будет проводиться, когда не будет достаточно времени для проверки всех функциональных возможностей продукта.
Q13. Обычно имеются разные категории, чтобы составить одну конкретную группу из тестовых случаев сортов, учитывая их объяснение?
Ответ:
Это самые популярные вопросы интервью SDET, задаваемые в интервью. Ниже приведены некоторые популярные тестовые примеры в современной ИТ-индустрии:
Q14. Общие проблемы, с которыми обычно сталкивался один тестировщик программного обеспечения, то есть надлежащая документация, не предназначенная для тестирования. В таком случае, как мы можем преодолеть то же самое?
Ответ:
Это один из распространенных сценариев, когда документация не доступна должным образом для всех видов тестовых случаев, но требование должно выполнить и доставить ее клиенту вовремя. В этом случае обычно тестировщик следит за предоставленной клиентом почтой, где описывают все требования должным образом, если это возможно, скриншоты приложения, в которых четко упомянуты те части изменений, или некоторые разговоры по телефону или в устной форме, проведенные с клиентом для понимания точной функциональности этих изменений. этого достаточно для быстрого тестирования и доставки того же в ожидаемые сроки.
Рекомендуемые статьи
Что такое компонентные тесты, и каково быть SDET’ом
Статья рассказывает о нетрадиционном, но полезном виде тестов, а также подводит итоги семилетней работы в разработке тестов.
Ведь есть, скажем, юнит-тесты, которые подробно тестируют потроха компонентов. Они досконально проверяют, что компонент работает в соответствии с замыслом разработчика. Но часто это проверка «пуговиц», а не того, как сидит костюм в целом. И не всегда поведение, задуманное программистом, совпадает с тем что хотел заказчик.
А еще есть, например, приемочные тесты. И они устраняют все указанные недостатки. Но, к сожалению, вносят новые. Они медленные, часто нестабильные, и обычно ручные. При этом они только свидетельствуют о проблеме, но не локализуют ее.
Очевидно, что напрашивается необходимость промежуточных тестов, которые станут золотой серединой между тестами модульными и приемочными. Этой серединой могут стать компонентные тесты.
Что такое компонентные тесты?
Это тесты на публичный API компонента. Соответственно, они пишутся на том же языке, что и компонент. Задача тестов:
Очевидно, что компонентные тесты имеют смысл, когда у вас есть выделенные компоненты с обширным интерфейсом. Например, динамическая библиотека или COM-объект. Тогда компонентные тесты дадут максимальный эффект.
Плюсы к-тестов:
Минусы к-тестов:
Резюме 1
Компонентные тесты хороши, но только если для них у вас есть все условия: широкий публичный API, правильный workflow, и подходящие люди в команде.
Каково быть SDET’ом?
Очевидно, что SDET — Software Development Engineer in Test — идеальный кандидат на написание компонентных тестов. Он умеет писать код, и умеет мыслить тестами. Он же обеспечивает второе мнение, что тоже повышает качество тестов и кода. Все это звучит интересно и заманчиво — возможно, вам уже хочется им быть. Здесь я тезисно расскажу, чем работа SDET’а отличается от работы чистого разработчика.
Плюсы работы SDET’ом:
Минусы работы SDET’ом:
Резюме 2
Как человек, который много лет работал разработчиком, потом на несколько лет ушел в SDET’ы, а затем снова вернулся в разработку, могу сказать следующее.
Я очень рекомендую провести SDET’ом хотя бы год-другой. Это весьма полезный опыт для любого разработчика. Но задерживаться там, на мой взгляд, не стоит.
🚶 Куда уходят тестировщики?
E beda
После 7-10 лет работы в профессии каждый день становится копией предыдущего: опять приходятся писать тест-кейсы или автотесты. Проекты не отличаются друг от друга, и даже все баги, кажется, известны заранее. Во время кризиса жанра душа просит чего-то нового. В статье, подготовленной при поддержке Факультета Тестирования ПО онлайн-университета GeekBrains, мы рассмотрим возможные пути эволюции тестировщика.
Для начала стоит определиться, хотите ли вы связать дальнейший путь с тестированием? Если ответ положительный, попробуйте понять, что вы больше всего любите в работе: анализировать, писать код или управлять проектами. В зависимости от ответа можно планировать карьеру.
Фото с сайта pixabay.com
Если вы успели написать несколько собственных фреймворков для автоматизации тестирования и поняли, что хотите и дальше заниматься чем-то подобным, стоит присмотреться к следующим профессиям.
Automation Test Architect
Должность в России довольно редкая и встречается преимущественно в филиалах иностранных корпораций, где счет идет на десятки тысяч автотестов.
Архитектор автотестов занимается стратегическим развитием автоматизации тестирования. Он может подобрать или разработать наилучшим образом подходящий под решаемые задачи фреймворк и построить инфраструктуру, на поддержку и настройку которой будут затрачиваться считанные минуты.
Архитектор должен внедрить автотесты в общий процесс CI/CD таким образом, чтобы не сломать работу других отделов. В его обязанности входит поиск новых инструментов и консультирование тестировщиков-автоматизаторов из разных команд. Чтобы претендовать на эту должность, желательно хорошо знать несколько языков программирования, а также обладать многолетним опытом работы и собрать портфолио из десятков крупных проектов.
SDET – Software Development Engineer in Test
В России эта профессия только начинает набирать популярность, поэтому за модным названием часто скрывается описание вакансии обычного автоматизатора. В иностранных компаниях это в первую очередь разработчик.
Как правило SDET владеет несколькими языками программирования. Он хорошо знаком с продуктом не только как обычный тестировщик, но и как программист. Уровень SDET позволяет проводить ревью кода, тестировать программу методом «белого ящика» и вносить в нее изменения. SDET тоже пишет автотесты, но это совершенно другой уровень, существенно отличающийся от обычной автоматизации.
Test Architect
Такой специалист великолепно владеет техниками тест-дизайна, прекрасно разбирается в методологиях и видах тестирования. Он способен проанализировать сложные системы, понять их устройство и влияние отдельных компонентов друг на друга. Оценить, какие виды тестирования и для каких систем необходимо провести в случае разработки новой функциональности.
В обязанности архитектора входит определение стратегии, оценка рисков, анализ вносимых в ПО изменений и влияние этих изменений на процесс тестирования. Он помогает командам составлять планы, оценивать временные затраты на проведение тестирования и анализировать полученные результаты. Помимо этого тест-архитектор консультирует отделы разработки и другие департаменты компании.
Test manager
Тест-менеджер контролирует весь процесс: от сбора требований до отчета о результатах тестирования. Если во время тестирования возникают какие-то проблемы (не работает стенд или программисты никак не исправят блокирующий дефект), его задача – устранить ее в максимально сжатые сроки. В обязанности тест-менеджера входит подбор, обучение и развитие тестировщиков. Он помогает подчиненным в налаживании отношений с другими подразделениями, что весьма ценно, поскольку конфликты с разработчиками, мягко говоря, не редкость.
Тест-менеджер отвечает за качество продукта и соблюдение сроков реализации проекта. Если кто-то из команды заболел, он засучивает рукава и подключается к процессу. Конечно у хорошего менеджера такие ситуации возникают редко, потому что он умеет учитывать возможные риски и продумывает варианты действий на случай, если что-то пойдет не так.
Фото с сайта pixabay.com
С развитием в тестировании ситуация более-менее ясна, но как быть в случае, если вы не хотите оставаться в профессии? Не расстраиваться. Есть целый ряд специальностей в которых вчерашний QA может успешно себя реализовать.
Разработка
Чаще всего, тестировщики переходят в разработку. После несколько лет в автотестах специалист может не только писать приличный код, но и находить ошибки в чужом. Вчерашний QA уже написал несколько фреймворков с нуля и реализовал ряд приложений под собственные нужды. Таких, например, как генераторы тестовых данных. С солидным багажом знаний переход в разработчики не составит труда. Ко всем прочему тестировщик будет искать баги в своем коде прежде, чем передать его в тестирование. Это, конечно, плюс.
DevOps
Фото с сайта pixabay.com
В сфере IT существует не только код. Есть целый ряд профессий, которые не требуют наличия технических навыков и при этом востребованы на рынке ничуть не меньше программирования. Если вы считаете, что кодить – это не ваше, обратите внимание на следующие специальности.
Product manager
Кто, как не QA знает все о продукте, над которым работает команда? Тестировщик непосредственно участвует в его развитии, знаком с фидбеком от пользователей и видит, что нравится клиентам, а что вызывает у них раздражение. Он понимает, сколько времени требует доработка и может спрогнозировать сроки реализации новой функциональности, а также знает сильные и слабые стороны продукта по сравнению с конкурирующими. В работе тестировщики опираются в том числе на аналитику и формальные метрики: для начала им стоит попробовать себя в качестве помощника PM на текущем проекте. Если не получится, можно предложить услуги конкурентам.
Project manager
Часто на эту должность тестировщика наталкивает обратная связь от пользователей. Когда видишь, чего не хватает клиенту и понимаешь, как это можно реализовать, рождается проект. Нередки случаи, когда руководство разрешает посвятить ему несколько рабочих часов. Если финансовые показатели подтверждают успех идеи, несколько часов превращаются в полноценную выделенную команду, а ее идейный вдохновитель превращается в PM.
Заключение
Тестирование – хороший старт для карьеры в IT. Перед тестировщиками открывается множество путей дальнейшего развития, если текущая деятельность перестала приносить им удовлетворение. При желании QA всегда может найти работу по душе.
Освоить новую специальность вам поможет Факультет Тестирования ПО от Geekbrains. Преподаватели курса – настоящие профессионалы с многолетним опытом работы в тестировании. Прохождение курса позволит быстро войти в профессию тестировщика и найти работу, которая принесет достойный заработок и массу удовольствия.
Тестирование: зачем тыкать на 1 000 кнопок в секунду
Краткий конспект подкаста
Это краткое содержание выпуска подкаста «Запуск завтра» о тестировании. «Практикум» — партнёр подкаста, а мы — дети «Практикума». Если есть время — послушайте выпуск.
О герое
Максим Садым программировал в СКБ «Контур», но по политическим причинам уехал за рубеж. Потом занимался тестированием в «Амазоне», а мечтал попасть в «Гугл». Несколько лет спустя он осуществил свою мечту.
С чего начинает каждый тестировщик
Ведущий Самат Галимов: Когда я был техническим директором «Медузы», у меня было семь разных телефонов и один компьютер. Чтобы понять, как статья будет вести себя на разных девайсах, я открывал её на всех этих устройствах.
В статье я специально использовал все возможности форматирования и добавлял разные типы контента. Я смотрел, как будет выглядеть длинный заголовок, как отображаются картинка и видео, что происходит, если интегрировать посты из «Твиттера».
Максим Садым: То, что ты описал, это стандартное UI-тестирование — тестирование пользовательского интерфейса. С этого начинают все. Если ты делаешь стартап, первое, что ты делаешь, — тестируешь всё «руками». Вопрос: что ты будешь делать потом, когда появится много клиентов, разработчиков и фичей.
Существуют два пути. Первый — нанять большое количество тестировщиков, которые будут на куче девайсов пробовать воспроизводить разные хитрые сценарии.
Второй — написать программу, которая будет автоматически прогонять тесты. Вместо того чтобы Самат сидел и сам кликал на семи телефонах разные кнопки, мы как бы одновременно запускаем программу на семи, на ста разных телефонах.
Сценарии тестирования — это то, что нужно сделать с программой, чтобы проверить определённую штуку. Например, открыл главную страницу «Медузы», нажал на статью.
В этот момент статья должна открыться. Другой вариант — ты открываешь список товаров, выбираешь конкретный продукт и добавляешь его в корзину. Теперь в корзине должен появиться товар.
Как часто прогонять тесты
Если ты поработал с модулем, то вручную запускаешь тесты, которые касаются этого модуля. Дальше тесты запускаются в обязательном порядке перед тем, как эти модули будут выложены.
Как это было в «Амазоне». Есть несколько стадий выкатывания новой версии, перед каждой обязательно прогоняются все пользовательские сценарии. Если хотя бы один из них «упал» — в нём была ошибка, релиз дальше не идёт.
В «Амазоне» я работал над проектом «Гифт ресивер». Идея такая: тебе приходит подарок с «Амазона», и я как отправитель могу либо прислать тебе ПДФ-файл, либо распечатать листочек, на котором написано: «Вот, пожалуйста, твой подарок. Если подарок тебе не понравится, ты можешь перейти по ссылке и вернуть его. Я об этом ничего не узнаю». Проект был направлен на то, чтобы люди не боялись дарить подарки и меньше выкидывали вещи, которые им не нужны.
Это небольшой проект, всего около восьми страниц на сайте. А UI-тестов было около 200. Конечно, можно сделать один тест, который проверяет все сценарии. В ходе такого теста человек зашёл на сайт, прошёл по всем страницам, сделал всё, что ты можешь представить, и вышел. Такой тест нужен один: если он сломается, не так трудно будет понять, что именно сломалось. Если ещё на сайте что-то изменится, этот тест будет довольно сложно поддерживать.
Тест нужно менять и обновлять так же часто, как обновляешь программу. Например, я сделал более красивую кнопочку, а тест мне говорит: «Наша кнопочка не нашлась, ты всё сломал».
Например, я получил подарок и зашёл на страницу заказов. У меня есть несколько кнопок: «Вернуть подарок», «Написать имейл: „Спасибо за такой великолепный подарок!“». Я выбираю второй вариант и пытаюсь отправить ссылку на вредоносный сайт. Это тоже сценарий, который нужно протестировать.
Разработка по поведению пользователя
Существует подход, например, BDD — Behavior-driven development, разработка по поведению пользователя. Сначала мы описываем, что ожидаем от системы, а потом разрабатываем. Например, есть пользователь, который залогинен на сайте. Когда он нажимает на кнопку «Добавить товар в корзину», товар добавляется в корзину.
Этот сценарий можно описать не только алгоритмом, но и естественным языком. Есть система, которая позволяет на английском языке описать сценарий, а потом превращает текст в сценарий программы для тестирования. Чтобы это сработало, разработчикам нужно описать саму систему. Определить, что означают конкретные слова: глаголы, существительные и так далее.
Как правило, программисты сильно страдают и ругаются оттого, что не могут напрямую написать строчку на языке программирования. Им нужно изгаляться: превращать английский язык в код, потом этот код запускать и так далее.
Люди, которые далеки от программирования, с помощью этой системы приготовят сценарий для тестирования, при этом не написав ни строчки кода. Тестировщики могут не понадобиться: их заменят аналитики или другие люди, которые описывают поведение системы на английском языке. На русском языке таких систем нет.
Почему тестировщики иногда ненавидят разработчиков
Представь, что у тебя есть отдел тестирования, ты делаешь релиз, выкладываешь новую версию. При этом у тебя 500 обычных сценариев поведения пользователей. Чтобы их проверить, отдел должен сидеть неделю, две или три. Десять человек распределяют эти 500 сценариев между собой и воспроизводят их. Это делается перед каждым релизом, тестировщики повторяют одну и ту же работу. Получается, что очень много времени уходит на то, чтобы перепроверить то, что может проверить машина.
Ещё одна проблема выглядит так. Тестировщик нашёл ошибку и сказал об этом разработчику. Разработчик пофиксил проблему и изменил код. Теперь тестировщику нужно заново всё проверять: когда программист менял код в одном месте, могло сломаться где-то в другом.
Несмотря на это, отношения отдела тестирования с отделом разработчиков очень тёплые, иначе им невозможно работать друг с другом — они начнут друг друга взаимно ненавидеть.
Что делать, когда прилетают «чёрные лебеди», и как сделать, чтобы они прилетали реже
Самат Галимов: У меня был проект — интернет-магазин iGoods, мы над ним работали во время начала коронавируса. Конечно, тогда мы ещё не знали, что начнётся пандемия. Потом показали послание Путина про то, что мы две недели будем сидеть по домам: работать не будем, денег платить тоже не будут. А ещё нельзя будет ходить в магазины.
iGooods — сервис, в котором можно заказывать товары на дом. К нам пришёл огромный поток людей — в пять или в десять раз больше, чем обычно. У нас лёг сайт.
Расскажи, что такое нагрузочное тестирование и как оно помогает защититься от таких ситуаций?
Максим Садым: Сценарий, который ты описал, называется «чёрный лебедь». То есть произошло событие, к которому никто не был готов. К счастью, «чёрные лебеди» прилетают очень редко. После того как «чёрный лебедь» прилетел, он перестал быть «чёрным лебедем»: мы уже знаем, что такие сценарии бывают.
Приведу пример с «Амазоном». Рождество наступает каждый год, люди покупают подарки. У нас была по этому поводу шутка: существует единственный дедлайн — Рождество. Мы увеличивали количество серверов в 10 раз.
Представь, что на твой сервис пришло в 10 раз больше пользователей, чем обычно. Уверен ли ты, что система выдержит? Уверен ли ты, что можешь добавить какое-то количество дополнительных компьютеров? Уверен ли ты, что они между собой будут корректно взаимодействовать? Уверен ли ты, что не будет проблем, например, с подключением к интернету или с локальной сетью? Чтобы ответить на все эти вопросы, существует нагрузочное тестирование.
Как это работает: мы пишем программу, которая симулирует большое количество реальных пользователей. Как правило, одна машина не справляется с тем, чтобы симулировать нужное количество, поэтому это делают сразу несколько машин. Они приходят в систему, симулируют реальное действие, проверяют правильный результат и замеряют скорость ответа. Если страница отвечает через минуту, скорее всего, пользователя там уже нет.
«Например, пришло 1 000 человек, и они начали складывать запросы в базу данных. База данных не справляется. Мы должны убедиться, что новые пользователи не топят базу ещё сильнее.
В какой-то момент мы должны принять волевое решение и сказать: „Извините, мы не можем сейчас ничего сделать, подождите, пожалуйста“».
Для этого существует load balancers — промежуточные слои между базой данных и сервисом. Load balancer в определённый момент понимает, что время обработки запросов слишком большое, и говорит: «Извините, мы больше заказов не принимаем».
При этом нам нужно убедиться, что сайт корректно отображается пользователям. Существует сценарий логичного правильного поведения: если не получилось, надо повторить — скорее всего, во второй раз получится. В абсолютном большинстве случаев такая логика приведёт к трагедии. Если мы начнём бездумно повторять запросы, нагрузка на базу данных возрастёт лавинообразно.
Например, сервис просит у базы данных: «Покажи мне всех плюшевых мишек на сайте». Если база данных при этом занята, load balancer отвечает: «Извини, у нас всё слишком плохо, мы не справляемся». Но сервис тут же снова говорит: «Нет, ты мне всё-таки покажи мишек». Тогда уже к load balancer будет очень много запросов. В итоге уже начнёт задыхаться load balancer, а не база данных.
Перед каждым большим событием в «Амазоне» мы должны были обязательно запустить нагрузочное тестирование. Мы тестировали, как большое количество пользователей приходит на сайт и начинает возвращать товары, писать благодарности и так далее. Это и правда так происходит, но мы репетировали, чтобы убедиться, что у нас всё работает хорошо.
Зачем нужен инженер по разработке тестов
Перед каждым большим праздником нужно провести нагрузочное тестирование. Этим занимаются разработчики, по крайней мере в «Амазоне». Но в конце концов тестирование сводится к тыканию в кнопочки.
Самат Галимов: Тебе нужно тыкать кнопочки на десятках компьютеров, 1 000 кнопочек в секунду и при этом замерять скорость ответов кнопочек. Это уже не так просто, как семь телефонов на столе.
Максим Садым: В «Амазоне» существует должность SDET — это инженер по разработке тестов. Он не пишет тесты сам — он пишет программы, чтобы другим разработчикам было проще писать тесты для своих программ.
У SDET более «горизонтальное» покрытие. Один инженер по разработке тестов работает сразу на несколько проектов. Он готовит инфраструктуру, чтобы несколько команд могли делать, например, нагрузочные тестирования. Поскольку мы работаем в одном сете технологий, используем примерно одни сервисы и языки программирования, несколько проектов могут использовать одну инфраструктуру для тестов.
При этом программисты сами пишут UI-тесты и могут запускать нагрузочные тестирования. Но чтобы все подготовить и сделать программистам удобно, существует инженер по разработке тестов.
Работа тестировщика в «Гугле» и «Амазоне»: постоянно неисправные компьютеры и хаос-тестирование
Максим Садым: В «Амазон» я пришёл обычным программистом, но так получилось, что больше занимался тестами. Тестов было мало, а я тупой, не понимаю, как всё работает.
А если я не понимаю, как работает, то хочу это зафиксировать. Хочу, чтобы оно работало так же всегда, а дальше мы разберёмся.
Я начал фокусироваться на тестах и в конце концов перешёл в разработку тестов. Один из проектов SDET, над которым я работал, называется «Хаос-тестирование».
Есть такая шутка: не существует цифрового облака, это всегда чей-то компьютер. Это правда. А если это всегда чей-то компьютер, то у него может случиться проблема: сломаться жёсткий диск, выйти из строя процессор или переполниться память.
Самат Галимов: «Гугл» или «Амазон» — десятки или сотни тысяч серверов. При таких объёмах у тебя постоянно что-то в них будет ломаться. В каждый момент времени у тебя есть компьютер, который сломан. Как жить дальше? Я не хочу давать определение хаос-тестированию, расскажи, как ты это видишь?
Максим Садым: Ты правильно сказал. У нас физически постоянно что-то где-то сломано. Вопрос: как мы с этим работаем? Например, если у нас сломался компьютер, но мы продолжаем к нему ходить, значит, пользователь получает ошибку, потому что он не может получить результат.
Более того — иногда, когда мы привязываем пользователя к конкретному сервису, по какой-то причине он будет дальше получать ошибки. Нам нужно убедиться: если физически компьютер сломался, то мы с этим нормально живём.
Представь, что на компьютере по какой-то причине процессор занят на 100% — неважно чем. Пользователь пришёл и говорит: «Дай мне список мишек». А физический компьютер, который стоит где-то в дата-центре, говорит: «Сейчас дам».
По-прежнему у него 100% загрузки процессора — он не может ничего сделать, но он пообещал. Это неправильно. У нас есть такая штука, называется тайм-аут. Через какое-то время запрос должен прекратиться, а мы должны сказать: «Ой, извини, мы не можем. Мы сильно заняты, сходи к кому-нибудь ещё».
Мы должны протестировать, что тайм-аут работает правильно. Нужно убедиться: если память процессора полностью занята, у нас всё работает хорошо. Нужно убедиться: когда процессор освободится, программа не будет выдавать ошибку.
Самат Галимов: Когда ты пишешь программу, Happy path — когда всё нормально идёт — это 10% твоей программы. А остальные 90% работы — описать, что происходит, когда что-то пошло не так. Очень хорошая аналогия — медицина. В ней одна книжка — анатомия здорового человека, а дальше 10 книг о том, что может пойти не так и что в этой ситуации делать. Здесь ровно такая же проблема.
Максим Садым: Ты сейчас идеально описал мою работу.
С одной стороны, список того, что может пойти не так, бесконечный. С другой — у нас уже есть опыт. Мы смотрим, что шло не так, пытаемся предположить, что может пойти не так, и проверяем сценарии.
Хаос-тестирование — довольно сложная технически штука. Его начал делать Нетфликс: они это сделали открытым кодом, теперь кто угодно может его использовать.
В основном хаос-тестирования проводят большие компании, для маленьких это слишком дорого.
«Мы просто пишем программу, которая воспроизводит такие проблемы и делаем большую красную кнопку „Проверить“. Разработчики перед Рождеством нажимают на эту кнопку и смотрят красивые графики».
Юнит-тесты и мутационное тестирование
Проверка небольшой части кода называется юнит-тест. Расскажу мой любимый пример. У нас была проблема: очень небольшой кусок кода, который проверяет, какой квартал сейчас по дате. Что может пойти не так? Первый квартал начался 1 января, второй — 1 апреля, а 1 июля третий квартал не начался. Так получилось, потому что мы закладывали на квартал четыре месяца, делили на четыре. А чтобы всё сошлось, вычитали где-то единицу.
Если бы мы провели юнит-тест, всё тут же бы выяснилось. У тебя четыре квартала в году, ты проверяешь: здесь начинается и здесь заканчивается.
Юнит-тест выглядел бы так. Есть модуль программы, который проверяет квартал. Задача программы — проверить, что такого-то числа начинается первый квартал, такого-то числа второй, такого-то числа третий. То есть ты подаёшь кусочку своей программы на вход дату и проверяешь — он возвращает: «Да, квартал начался».
Если у тебя нет юнит-тестов, ты узнаёшь о проблемах, которые сам создал, слишком поздно. Потом их сложнее решать.
Моя любимая тема — мутационное тестирование. Например, ты написал модуль и юнит-тест для него. Есть метрика coverage — покрытие тестами. Чтобы её измерить, ты запускаешь программу, которая проверяет каждую строчку кода: заходила ли программа проверки в каждую строчку кода или нет.
Грубо говоря, берём весь текст программы и закрашиваем зелёным те кусочки, по которым прошёл тест. Таким образом мы находим кусочки, которые не были покрыты тестами. Эти кусочки не окрашены зелёным — значит, в них может быть проблема, о которой мы не узнаем, потому что тестов там не было.
Мутационное тестирование делает следующее: если мы прошли через строчку кода, это не значит, что мы её проверили. Чтобы стать уверенными, мы меняем эту строчку.
Существует список мутаторов — элементов на подмену. Программа берёт каждую строчку, каждый элемент и меняет один элемент на другой. У тебя был «плюс» — стал «минус», у тебя было «больше» — стало «больше или равно» и так далее. Программа делает мутанта из твоего кода, добавляет по одному мутанту за раз, прогоняет все юнит-тесты повторно. Тесты должны упасть. Если тест не упал — значит, мутант пробрался на базу, всё плохо.
Иногда, если ты поменял «больше» на «больше или равно», ты говоришь: хорошо, это приемлемый риск, я с этим живу. Тогда ты знаешь, что именно ты протестировал. Это сильно упрощает жизнь разработчика: посмотреть на coverage report после своей работы — обязательное дело. Если ты не посмотрел, откуда ты можешь знать, что сделал. Посмотреть на mutation report — это ещё и получить подсказки о том, что ты протестировал или не протестировал.
Что ещё в подкасте
Что такое Test-Driven Development, как сложилась карьера нашего героя и каково было программировать в эмиграции. Слушайте в «Яндекс-музыке».