QArelia | Блог про тестирование, QA 🧩

Какие реальные проблемы возникают при E2E тестировании микросервисов? Или всё просто и нет никаких проблем? Конечно, без проблем никуда 😈

Давайте для начала вспомним, что же такое микросервис, а точнее микросервисная архитектура:

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

И определение E2E (end-to-end) тестирования:

E2E тестирование — вид тестирования, при котором бизнес-процессы тестируются от начала и до конца в условиях, аналогичных производственным.

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

Недавно наткнулся на статью по этой теме:
https://chroniclesofapragmaticprogrammer.substack.com/p/end-to-end-testing-in-microservices

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

Для экономии вашего времени рассмотрим ключевые моменты статьи:
➡️ Тестирование является гарантией того, что продукт на выходе будет соответствовать ожиданиям и потребностям пользователей и бизнеса
➡️ Продукт тестируется в различных ситуациях, чтобы убедиться, что он справляется с реальными задачами
➡️ Тестирование существует не для того, чтобы препятствовать или замедлять разработку
➡️ Медленные, нестабильные и сложные в обслуживании E2E тесты могут стать серьёзной проблемой и вот почему:
🔸 при падении сложно разобраться, в чём действительно была проблема (где-то в микросервисе, их взаимодействии или ещё где-то)
🔸 долгое ожидание обратной связи
🔸 отсутствие уверенности в результатах из-за flaky (нестабильных) тестов
🔸 для обслуживания необходимо много ресурсов
🔸 задержка деплоя
🔸 низкая эффективность выявления багов
➡️ Вспоминаем пирамиду или кубок тестирования: E2E тестов не должно быть много
➡️ Очереди сообщений RabbitMQ или Kafka привносят определённые трудности
➡️ Не заменяйте критические части системы моками/стабами и прочими симуляциями, а также понимайте ограничения, которые они накладывают. В некоторых ситуациях симуляция может быть полезна
➡️ Одна команда не может выкатиться без фиксов тестов другой команды – это тормозит работу. Написание контрактных и интеграционных тестов должны помочь проверить функциональность сервиса и взаимодействие сервисов более изолированно
➡️ Контрактные тесты всё усложняют? Нет. Рассматривайте их как уменьшение нагрузки на E2E тесты и способ проверки связи между сервисами
➡️ Пишите контрактные тесты, даже если микросервисов пока ещё мало. В дальнейшем это поможет. И внедряйте постепенно, начиная с наиболее важных сервисов
➡️ Используйте комбинированный подход: контрактные, приёмочные тесты и E2E.
Приёмочные тесты предназначены для проверки того, соответствует ли система или функциональность бизнес-требованиям и ожиданиям заинтересованных сторон.

✅ Подводя итоги, автор говорит, что при неправильном использовании E2E тестов они могут создавать проблемы, особенно в сложных архитектурах.

✍ Основываясь на своём опыте хочу согласится в целом с идеями и мыслями автора.
Действительно, даже без микросервисов нужно опираться на пирамиду тестирования, пытаться избавиться от flaky тестов и ускорять прогоны тестов.
🧐 В тоже время меня смутил пример про подсчёт времени длительности тестов с пятью ручками у сервиса. В данный момент это не является проблемой, ведь можно запускать тесты в параллели в десятки-сотни потоков, что уменьшает длительность выполнения тестов в разы.

#микросервисы #тестирование #e2e

🚀 Обеспечиваем качество

🔹 На Saint HighLoad++ рассказывали про наш релизный поезд:
https://t.me/vkjobs/2144?single

🔹 Хотелось бы вспомнить статью, в которой наш директор по качеству рассказывает, как мы обеспечиваем качество релизов, сохраняя и качество и скорость:
https://habr.com/ru/companies/vk/articles/703230/

🔹 И видео-доклад о том, как QA может улучшать релизные процессы:
https://vk.com/video-84585194_456239144

Обзор автотестов №2 (17.07 — 13.08)

Собрал для вас последние обновления в мире автотестов =)
Поднакопилось много всего, надеюсь будет полезно всем, кто занимается автотестами =)

https://telegra.ph/Dajdzhest-mira-avtotestov-1707--1308-08-14

#дайджест #автотесты #selenide #cypress #playwright #appium #ultron #k6 #selenium #moon #karate #testcontainers

Как всё успеть?

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

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

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

Есть задачи разной степени срочности: краткосрочные, средние, долгосрочные. Вот например краткосрочная задача — проверить поведение фичи, так как было замечено странное поведение перед релизом. То, что было протестировано, не всегда это остаётся статичным, а автотестами всё не покроешь. Потенциально это может быть заведённый баг и отложенный релиз, до починки этого бага.
Есть такая метрика Time-to-market (TTM), её стараются уменьшить, чтобы фичи доходили до пользователей быстрее, при работе всегда надо задаваться вопросом «Не увеличится ли TTM, если сделать так, а не иначе?».
Надо ли из-за этого делать всё быстро, не взирая на качество? Ни в коем случае. Надо соблюдать Quality Gates на каждом участке пайплайна.

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

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

Становится сильным специалистом — правильное движение вперёд, которое также помогает успевать делать всё, ведь улучшаются умения, появляются знания, как и что делать. Вообще качественное вкладывание в своё обучения и развитие даёт большие плоды в будущем. Я много читал/смотрел и старался узнать как можно больше полезной информации по автотестам, по ручному, по QA процессам, и сейчас стараюсь для себя открывать новые точки роста, к примеру, в мобильном автотестировании.

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

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

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

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

Обзор изменений в инструментах для автоматизации тестирования (01.07 — 16.07)
🧬 💎 🎭 🌐 🤖 📱 📊🤖

https://telegra.ph/Obzor-izmenenij-v-instrumentah-dlya-avtotestov-0107---1607-07-16

#дайджест #автоматизация #автотесты

📚 ✍️ Джанет Грегори, Лайза Криспин «Agile-тестирование. Обучающий курс для всей команды»
#книги

Есть разные книги на тему тестирования, эта запомнилась мне особенно, в ней я нашёл для себя несколько интересных историй из компаний HP, Dell и других про построение Agile-тестирования)
Несомненно запомнилась фраза про то, что «нам нужны не разработчики в тестировании, а тестировщики в разработке» 🫡

В целом рекомендую к прочтению, так как книжка передаёт правильные подходы:
— командный подход к качеству
— автоматизация регрессионных тестов, пирамида тестирования
— быстрая обратная связь
— непрерывное обучение
— исследовательское тестирование
— тесное сотрудничество внутри команды

PDF версию можно посмотреть тут: https://t.me/lib_analyst/136

📣 2024 год, разбираемся в процессах QM, QA, QC, Testing
#qa #qm #qc #тестирование

На Хабре уже образовалась целая плеяда статей про процессы QA/QC:

«Перестань называть себя QA»
https://habr.com/ru/companies/tochka/articles/826152/

«Кто ты, QA-инженер или тестировщик?»
https://habr.com/ru/companies/dododev/articles/497014/

«Tester. Или почему важно, изменить свою роль в команде»
https://habr.com/ru/articles/698448/

«от Тестирования к Обеспечению качества»
https://habr.com/ru/articles/671874/

Серия статей «Как встроить качество в процессы производства ПО?»
https://habr.com/ru/articles/590639/
https://habr.com/ru/articles/591993/
https://habr.com/ru/articles/592041/

В Библии QA тоже можно почитать про QA/QC/Testing (внутри есть ссылки на другие статьи):
https://vladislaveremeev.gitbook.io/qa_bible/obshee/qa-qc-testing

👀 State Of Testing 2024
#тестирование #stateoftesting

Ежегодный отчёт о состоянии тестирования в мире от PractiTest:
https://www.practitest.com/state-of-testing

— выросло число использующих подход TDD (Test Driven Development) с 18% до 23%

— растёт вовлечённость тестировщиков в процессы CI/CD (непрерывная интеграция и непрерывный деплой)

— 42% респондентов неуверенно себя чувствуют при написании автотестов. Это говорит о том, что нужно лучше проводить онбординги, больше обучать автоматизации, чтобы оставаться конкурентоспособными

— у 60% организаций есть проблемы с тест-кейсами. Проблемы возникают из-за дублей, а также поддержании тест-кейсов в актуальном состоянии

— топ-3 инструментов:
👩‍💻 Jira 💎 Selenium 📪 Postman

— внедрение DevOps практик в организациях демонстрирует тенденцию к мониторингу систем во время развёртывания и после выкатки на прод, но команды QA не всегда участвуют в этих важных процессах. Необходимо более глубокое участие в этом важном аспекте качества в жизненном цикле продуктов

— ❓ Несмотря на популярность  AI (инструментов искусственного интеллекта), 60% респондентов сообщили, что они вообще не используют инструменты AI для тестирования

— 50% организаций не измеряют финансовые затраты, связанные с багами, которые попадают на продакшн. Штош, нужно повышать уровень понимания качества

— метрики дефектов и покрытие автотестами — основные метрики, за которыми следят

— 19% тестировщиков не участвуют в принятии решений о готовности продукта к релизу. Нужно взять инициативу и принимать участие в этом процессе

— основные навыки, которые стоит развивать: коммуникации, паттерны/принципы/практики автоматизации, а также ML (machine learning) и AI для тестирования

— 3 основные темы улучшений в QA:

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

Больше времени на обучение. С появлением новых технологий нужно давать людям время на обучение новому.

Адаптация AI. Освоение новых AI инструментов. Лучшая интеграция между AI и рабочими инструментами.

💬❓ Вот такие пироги, а как вы считаете, какие сейчас есть проблемы в тестировании? Напишите плиз в комменты) 👇

👨‍💻 Плюсы и минусы работы Fullstack QA инженером
#статьи@qa_relia #fullstack_qa

Вот уже более года я работаю на позиции Fullstack QA инженера и решил выделить некоторые плюсы и минусы 🚀

Из плюсов я бы отметил:
➕ развитие навыков программирования на всех языках, на которых пишешь автотесты (в моём случае это 👩‍💻 Java, 👩‍💻 Kotlin, 👩‍💻 Swift)
➕ полное погружение в фичу, в её особенности во время разработки и тестирования
➕ влияние на качество продукта и на покрытие автотестов
➕ становишься сильным специалистом, который может решать различные задачи
➕ улучшается понимание продукта целиком на разных платформах, это даёт преимущество при анализе багов и обсуждениях
➕ нет недопонимания, которое обычно бывает между ручными и авто тестировщиками

Из минусов:
➖ сложности из-за особенностей платформ, разные правила и подходы
➖ нехватка времени на всё, а ведь хочется везде успеть 😅
➖ нет фокуса на чём-то одном, распыление на несколько платформ

✔️ В целом, работа на позиции Fullstack QA инженера подходит тем, кто готов к непрерывному обучению и развитию в различных направлениях, обладает хорошими аналитическими способностями и хочет активно участвовать в улучшении качества продукта на всех этапах разработки

🖱 В Selenide подправили сообщение при клике на некорректную ссылку
#opensource

https://ru.selenide.org/2024/04/28/selenide-7.3.1/#fix-error-message-for-invalid-link

В ходе моих личных экспериментов было найдено поведение в Firefox, которое отличалось от хрома и сафари. Решил спросить у селенида и они сразу исправили))
По стандарту вебдрайвера ссылка должна проверяться на статус код, но не все драйверы это проверяют, а вот в Firefox как раз и проверяли) И проблема была в том, что selenide делает переповтор при неуспешном клике, но в данном случае переповтор был лишним, т.к. скрывал истинную ошибку) В selenium всё было ок, возвращалась WebDriverException: Reached error page: about:neterror?e=dnsNotFound

🚀 Стабильность автотестов
#автотесты #советы

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

Как можно улучшить стабильность автотеста? Вот некоторые советы:

🎯 позапускать локально/удалённо свой автотест несколько раз в несколько потоков, тем самым проверив на работу под небольшой нагрузкой и в параллели

❔ позадавать вопросы "А что произойдёт, если ... ?", проверив на места, где могут быть какие-то моменты, влияющие на стабильность (к примеру, в тесте закрывается какой-то баннер, но он иногда может не появится, сможет ли автотест это корректно обработать или нет)

🔄 делать переповторы запросов/действий там, где это возможно (возьмём асинхронные обработки в API, делаем перезапросы, чтобы дождаться нужного ответа)

📥 проверяем подготовку тестовых данных, что она выполняются стабильно (к примеру, для пользователя перед тестом выставлялся рандомный язык и это могло повлиять на сам тест)

♻️ делать хотя бы минимальное количество перезапусков самого теста, с возможностью перезапустить на другом окружении (если это возможно технически), так можно уберечься от случайных падений из-за сети/инфраструктуры

🖲 делать стабильные локаторы, менее склонных к изменениям, то есть, например, для web'а это будет aria-* атрибуты, а также data-* (test, testid, как угодно тут), на которые можно договариваться с разработкой и опираться на них

🎭 использовать моки там, где нужно подменить какой-то ответ от сервера

✅ Выбирайте также надёжные и стабильные фреймвоки для автотестов, чтобы не было сюрпризов) И, разумеется, тестируемые приложения и инфраструктура должны быть стабильны, это всё напрямую влияет на автотесты)

🔧 Фикс в Allure в @BeforeAll() при падении в JUnit 5
#allure #opensource

Больше года назад я пофиксил одну проблемку, из-за которой было сложно расследовать падения:
https://github.com/allure-framework/allure-java/pull/878

Если кратко, то в отчёте не было шагов из @BeforeAll() при падении в нём, что затрудняло анализ происходящего в самом HTML отчёте) Сам натыкался на это много раз и уже не выдержал, решил подправить сам) Уже не помню, получилось ли у меня сгенерировать и проверить в самом отчёте, но юнит-тесты были написаны и проходили успешно) Благо для @BeforeEach() это работало и можно было опираться)

#android #ultron
Для написания автотестов на Android рекомендую посмотреть на фреймворк Ultron:

https://youtu.be/m7QpqVqc4YY?si=RmWvo9xx2OvbcEkY

А вы знали, что делать, когда разраб говорит не баг, а фича?
Написал статью как QA действовать в нестандартных ситуациях:

Всем обязательно к прочтению!
https://habr.com/ru/articles/797795/

#тестирование #процессы_тестирования

#видеозаписи

Какой подвид тестирования ни возьми, в нем найдутся свои «лучшие практики». Поэтому тематический блок «best practices» на Heisenbug зачастую получается разношерстным, в нем могут найти что-то актуальное для себя самые разные специалисты.

И сегодня в рубрике #ТестоваяСреда открываем записи сразу всех докладов этого блока с весеннего Heisenbug — так что смотрите, есть ли тут что-то для вас:

• Значимость технических и продуктовых метрик в тестировании (Иван Левиков)

• How to Write Reusable Tests (Mesut Durukal)

• Что должен знать мобильный тестировщик в 2023 году (Александр Петров)

• Перепись «ферменных лет», или Опыт построения фермы девайсов ВКонтакте (Даниил Смирнов)

• Аналитика и метрики качества на основе найденных багов (Иван Щербинин)

• Как приручить автотестового монстра, или Dependency Injection в автотестах (Артём Сидорук)

Топ 🔥

📚 Первые впечатления от книги «Тест-дизайн. Практическое руководство для начинающих»
#книги

Почему я решил прочитать эту книгу? Хотелось больше примеров и каких-то советов по применению техник тест-дизайна, плюс сам подход к написанию текста в сочетании с иллюстрациями — восхитительно!

И ессно спасибо @links_from_testbase за эту замечательную книгу =)

Фреймворки/инструменты для автоматизации тестирования глазами нейросети

Узнали что-нибудь? 😁