Данная статья написана специально для OTUS преподавателем курса «QA Lead» — Анастасией Шариковой.

---

Всем привет! Меня зовут Анастасия Шарикова, я руковожу отделом тестирования в Bookmate и веду телеграм канал Yet another QA.

Уверена, что многие, когда приходили на позицию QA Lead’a, ожидали сложных и интересных задач по выстраиванию процессов, настройке системы автотестов, налаживанию функционального и нефункционального тестирования, в конце-концов — задач по управлению сотрудниками. Но в итоге оказалось, что все это есть, но сочетается с такими бытовыми штуками, как расчет зарплат, определение бюджета на отдел и прочих проблем, связанных с финансами — и зачастую от этого никуда не деться, особенно в маленьких и средних компаниях. Тем не менее, внимательность к таким темам — отличный способ дополнительно повысить качество вашего продукта и найти и предотвратить проблем уже на самых ранних этапах.

Мы изучаем использование Sentry с React.

Эта статья является частью серии, начинающейся с сообщения об ошибках Sentry на примере: Часть 1.

Привет!

Меня зовут Тимофей, я Python-разработчик в команде Платформа компании Циан. Наша команда занимается разработкой инструментов для продуктовых разработчиков. Это и библиотеки: HTTP-клиент, веб-сервер, библиотеки доступа к базам данных, и средства мониторинга микросервисов и сайта в целом, и интеграция с CI/CD и многое другое.

Сегодня я расскажу про новый инструмент, который мы не так давно разработали — фреймворк для функциональных тестов.

Но для начала...

Я принял участие в проекте с двухлетней кодовой базой и Symfony 3.4 в качестве веб-фреймворка. Это был не самый новый и блестящий проект, но у него было большое достоинство: тесты покрывали самые важные действия приложения.

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

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

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

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

• Распил приложения на более мелкие продукты со своими релизными циклами.
  
• Покрытие продукта тестами в соответствии с тестовой пирамидой.
  

Последний пункт и стал темой моей статьи.

Перевод статьи подготовлен в преддверии старта нового курса от OTUS — «Нагрузочное тестирование».

---

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

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

Ниже приведены 6 советов актуальных для нагрузочного тестирования в целом и особенно в контексте Черной пятницы.

Сервис Sentry позволяет удаленно мониторить баги в фронтенд-приложениях, написанных на JavaScript.

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

Как Web Scraping помог собрать нам данные по официальным коллекциям как у Белгазпромбанка.

Web Scraping — один из самых популярных методов считывания различных данных, расположенных на веб-страницах, для их систематизации и дальнейшего анализа. По сути, это можно назвать “парсингом сайтов”, где информация собирается и экспортируется более удобный для пользователя формат будь то таблица или API.

Для кого это статья

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

Для QA Engineer без опыта, лишь бы не пугаться страшных технических слов, которые будут в статье. Первый раз устраиваться на работу сложнее, потому что меньше отвечают на резюме, но цитирую: «Не бьешься — не добьешься» (к/ф “Ловец Снов”).

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

Для QA Engineer с опытом работы в полгода, когда ты уже знаком HR-ам, у тебя на руках отзыв от первого работодателя и толковая причина смены компании.

Есть задача нагрузочно потестировать фронтальные веб рест апи. Ресты защищены OAuth с Authorization Code Grant. Значит появляется необходимость наличия валидного токена для Authorization: Bearer TOKEN.
Вопрос — как его взять? И так это сделать красиво и правильно? Вот тут я не знаю.

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

Есть обычная типовая система с веб рест фронтом и типовым Single-Page-Application браузерным клиентом на JS. Аутентификация и авторизация — KeyCloak с Authorization Code Grant + brokering.

Надо обеспечить регулярное нагрузочное тестирование фронтовых рест сервисов.

Это снова Владимир Гриненко, тимлид в поисковом портале Яндекса. Я решил рассказать, как у нас устроено тестирование интерфейсов: о формате описания сценариев, способах их актуализации, о нашем собственном опенсорсном проекте и тестировании силами внешних тестировщиков. А ещё пофантазировал о неожиданных способах применения этой системы.


— Сергей Бережной veged уже несколько раз поднимал эту тему и рассказывал про тестирование в Поиске. Вот ссылки на доклады в 2016-м и 2017-м. Многое из того, что он тогда рассказывал, де-факто стало стандартом для большинства компаний. Но несмотря на это, все еще остаются вещи, которые пока нигде особо не применяются. Именно на них я и сосредоточусь.

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

Приглашаем на онлайн-митап DINS QA EVENING, он состоится 9 июля в 19:00.

Этим вечером Дмитрий Красильников из DINS расскажет, почему именно тестировщик должен построить CI/CD, и объяснит, как это сделать. Дмитрий Борисов из Nexign поговорит об эволюции инструментов и подходов обеспечения качества на большом проекте.

Для участия, пожалуйста, зарегистрируйтесь.

Подробная программа и информация о спикерах — под катом.

Ошибки и баги могут возникнуть в любых программах, поэтому тестировщиков нанимают многие крупные компании, которые разрабатывают программное обеспечение. А еще — небольшие фирмы, которые предоставляют услуги тестирования на аутсорс. Сегодня мы публикуем подборку из 14 бесплатных курсов по тестированию из нашего раздела Образование. Да, они, скорее, помогут вам получить базовые знания или освежить то, что вы уже и так знали, чем прокачаться до уровня синьора или лида. Но это не умаляет их полезности! Если вы видели что-то интересное, чего нет в этом выпуске — делитесь ссылками в комментариях.

Кейси Розенталь (Casey Rosenthal), CEO и сооснователь Verica.io, выступил на митапе Test in Production. Кейси развенчал некоторые мифы о надёжности и объяснил, что многие интуитивные действия по увеличению надёжности систем на самом деле контрпродуктивны. Более того, он объяснил, как концепция непрерывной проверки (Continuous Verification) помогает разработчикам избегать таких подводных камней.

Полное выступление Кейси:

Было ли у вас ощущение, что ради тестирования вы делаете код труднее для чтения? Допустим, у вас есть код, который ещё не тестировался. У него есть ряд побочных эффектов, и вас просят сначала прогнать тесты. Вы начинаете следовать советам вроде передачи глобальных переменных в виде параметров или извлечения проблемных побочных эффектов, чтобы сделать вместо них заглушки в тестах.

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

Вы останавливаетесь и задумываетесь: «Допустимо ли менять сигнатуры кода ради тестирования? Тестирую ли я реальный код или совершенно другой класс, в котором не происходит то, что нужно?» Перед вами может возникнуть дилемма. Вы уверены, что стоит и дальше придерживаться этого подхода? Или это потеря времени?

Вопрос на миллион: для устаревшего кода нужно писать модульные тесты или интеграционные?

CI (Continuous Integration) — в дословном переводе «непрерывная интеграция». Имеется в виду интеграция отдельных кусочков кода приложения между собой. Чем чаще мы собираем код воедино и проверяем:

• Собирается ли он?
• Проходят ли автотесты?

Тем лучше! CI позволяет делать такие проверки автоматически. Он используется в продвинутых командах разработки, которые пишут не только код, но и автотесты. Его спрашивают на собеседованиях — хотя бы понимание того, что это такое. Да, даже у тестировщиков.

Поэтому я расскажу в статье о том, что это такое. Как CI устроен и чем он пригодится вашему проекту. Если вы больше любите видео-формат, можно посмотреть мой ролик на youtube на ту же тему.

Sentry — трекинг java exception в Java

Стандартно Java разработчики мониторят ошибки, exception через логи. Но есть и другой способ, а именно отправка exception в Sentry.

Sentry — инструмент мониторинга исключений (exception), ошибок в ваших приложениях.

Преимущества использования Sentry:

• не нервничать при размещении приложений на боевом сервере,
• быстро находить причины возникших проблем,
• устранять баги раньше, чем о них вам сообщат тестировщики, коллеги из саппорта, пользователи, ПМ или директор,
• выявлять незаметные остальной команде проблемы, которые портят жизнь пользователям и снижают эффективность вашего продукта,
• бесплатен,
• легко интегрируется в проект,
• ловит ошибки и в браузере пользователя, и на вашем сервере.
• Если в ELK один и тот же exception происходит несколько раз, то они идут как отдельные записи, занимают место на диске и в ОЗУ. Если в Sentry один и тот же exception происходит несколько раз, то поле EVENTS увеличивается, тем самым экономя место на диске и в ОЗУ.
  
  Пример
  
  

И снова здравствуйте. В июле Otus запускает новый курс «Нагрузочное тестирование». В преддверии старта курса традиционно делимся с вами полезным материалом.

---

Поскольку 5 миллиардов человек во всем мире самоизолируются, все больше и больше наших ежедневных взаимодействий происходят через интернет. Ритейлеры по всему миру переводят обслуживание своих клиентов из офисов в онлайн, школы и учебные заведения пытаются находить альтернативы в интернете, и даже общение в кругу семьи переносится на Zoom и Webex вместе с нашими рабочими встречами (с детьми и домашними животными на фоне).

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

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

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

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

• Плагин Gatling SBT позволяет очень просто запускать тесты из CI-систем.
• Gatling хорошо подходит для командной работы над проектами. Cкрипты представляют собой человекочитаемый код на Gatling DSL, его удобно хранить в git и версионировать.
• В дополнение к стандартному функционалу Gatling существует возможность использовать любой Scala/Java-код внутри проекта, а также подключать зависимости от любых доступных библиотек Scala/Java, что позволяет создавать тесты для специфичных протоколов и выполнять дополнительные действия по подготовке тестовых данных или расширенному анализу результатов.

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

Какие проблемы решаем

Перевод статьи подготовлен в преддверии старта курса «Python QA Engineer».

---

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

Самое плохое в визуальных ошибках это то, что их нельзя «поймать» с помощью обычного автоматизированного тестирования. Так происходит потому, что большинство инструментов автоматизированного тестирования сверяются с DOM (document object model), чтобы сообщить о состоянии приложения.