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

👩‍💻 🌐 Покрыть или не покрыть, вот в чём вопрос: используем swagger-coverage
#автоматизация #статьи

Написал статью про мой личный опыт использования swagger-coverage — инструмента для анализа покрытия API тестов:

https://telegra.ph/Pokryt-ili-ne-pokryt-vot-v-chyom-vopros-ispolzuem-swagger-coverage-04-03

🟣 «Тестирование бэкенда» — тема конфы Podlodka QA Crew #9
#podlodka

https://t.me/podlodkanews/1062

Пробежавшись по расписанию отметил для себя следующие темы:

📊 «Баги в базе данных: предотвратить и обезвредить»

Описание: Базы данных есть во многих продуктах. Нужно ли их тестировать? Если да, то как, куда смотреть и на что обратить внимание? В докладе рассмотрим все эти вопросы на примере реальных кейсов разной сложности.

Почему интересно послушать: лично я не часто сталкиваюсь с базами данных, только если нужно изредка там что-то сделать, конкретно я не занимался тестированием баз данных, но интересно было бы послушать, какие там на практике встречаются подвохи 🧑‍🎓

🗳 «Симуляция реальности: мок-сервер - от основ до написания своего»

Описание: Мечтали ли вы когда-нибудь управлять внешними сервером? Превратить 200 в 500 или ...? Так давайте поговорим о магии мок-сервера и его реализации.

Почему интересно послушать: а кто не хочет превратить 200 в 500?😅 Было бы классно рассмотреть в рамках конкретного микросервиса, с базой своей и запросами на сторонний API)

🍻 Бар «FailConf»

Описание: В формате FailConf наши эксперты, а так же участники конференции поделятся неудачными кейсами по теме сезона и как фейл повлиял/изменил процессы в команде.

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

👩‍💻 Новый headless режим
#новости

Просто отличные новости для всех, кто использует headless режим! Начиная с Chrome 112 версии можно будет активировать с помощью аргумента --headless=new новый обновлённый "безголовый" режим, который решает старые проблемы. Теперь всё должно работать, как и в headful режиме. Это прям топчик 👍

В блоге разработчики рассказали более подробно.

P.S. К слову Selenide уже обновился и использует эту настройку по умолчанию 👌

⛴ Предварительные темы для нового сезона Podlodka QA Crew #9
#podlodka

Вовсю идёт подготовка к новому сезону в апреле)
Организаторы проводили опрос, вот какие темы вынесли на обсуждение:

➡️ Тестирование бэкенда
➡️ Автоматизация для неавтоматизаторов
➡️ Метрики

Мне ближе из этих трёх тем тестирование бэкенда, проголосовал за этот топик на максималочку) И подкинул парочку идей про Elastic/RabbitMQ)
Из предложенных докладов по этой теме мне приглянулся про тестирование с помощью mock-серверов (готовые решения vs самописные). Также воркшоп на тему «Тестирование БД» тоже не помешало бы мне, так как в принципе наверное мало с этим сталкиваюсь, но интересно)

По теме для неавтоматизаторов ответил, что как-то это в принципе не для меня. Возможно, прикольно, но не всем зайдёт. Про браузерные расширения? Про Postman? Порой кажется это так просто, что и не замечаешь. Но вдруг, конечно, там есть что-то прям очень интересное... Стоит подумать.

Касаемо темы метрик – безусловно вещь важная. Но столько раз она уже всплывает, что порой кажется это избыточным) Уже скоро QA будут всё про них знать, неплохо)) Все будут ходить к QA и советоваться по поводу метрик))
Я не прочь, но в целом надоедает. Раскручивать тему одних метрик? Короче, тут мой посыл был в смещении немного фокуса с метрик на QA процессы, TestOps как внедряли.
Очень классный был посыл в докладе про фасилитацию в предыдущем сезоне, да и в целом про построение процессов. Что-то такого плана интересно. Leading Quality вот, а не только метрики) Но тут как народ проголосует, может многие хотят метрики, why not как говорится)

Подробности обещают опубликовать на сайте к концу недели:
https://podlodka.io/qacrew

📊 Как я багу фиксил в allure-java
#allure

Периодически натыкаюсь на разные баги в библиотеках, которые активно использую) Например, в Allure Report я уже как-то фиксил багу на фронте.

Вот была такая бага в JUnit 5, что если проверка падала в @BeforeAll методе, то в Allure Report не было возможности посмотреть все шаги (что отправлялось, какой ответ от сервера), был только stacktrace этой ошибки.

В итоге покопавшись в Issues на GitHub я нашёл багу двухлетней давности) И там даже обсуждалось, как исправить эту проблему, но никто ничего не сделал почему-то.
Я решил, что надо как-то решать этот вопрос, исправил ошибку, написал unit-тест, все остальные тесты тоже прошли) Создал PR, отписался главному мэйнтейнеру, что это критичный фикс)
Мой фикс замёрджили и даже сразу выкатили релиз, это прям очень хорошо;)

Ссылка на релиз с моим фиксом

Всем привет!

Как-то в декабре написал небольшую статью, вот она😊

https://telegra.ph/Kak-nachat-pisat-avtotesty-12-21

На конференции Podlodka меня спросили как начать писать автотесты) Потом я решил вернуться к этой теме и как-то её описать своими словами по-простому))

#статьи #автоматизация #автотесты

Тренды в тестировании в 2023 ✨
#тестирование #тренды

#конференции #выступление #podlodka
Podlodka QA Crew #8 «Расширенные навыки для QA»

Очень рад, что посетил именно этот сезон 🔥 Теперь очень жду апреля, чтобы поучаствовать снова!
Мой мини-докладик на «Открытом микрофоне»:

https://youtube.com/watch?v=apuxrVuwrUw&t=1720s

#конференции #статьи@qa_relia
Всем привет!)

Вот статьи, которые я упоминал в своём докладике на Podlodka QA Crew в «Открытом микрофоне»:

https://telegra.ph/Kak-QA-mozhet-vesti-komandu-k-uspehu-02-18-2

https://habr.com/ru/post/654959/

#каналы #топ
10 полезных каналов про тестирование

🔹 Канал по тестированию
https://t.me/protestinginfo
Здесь вы можете пройти различные опросы, почитать познавательную теорию, очень советую

🔹 Тестировщик с нуля, канал Артёма Русова
https://t.me/qachanell
В канале есть полезные статьи, а также ссылки на другие полезные чатики

🔹Серьёзный тестировщик
https://t.me/serious_tester
Пожалуй самый большой канал по тестированию в русскоязычном сегменте. В выборку попадают довольно интересные статьи

🔹 QAread
https://t.me/QAreadRU
https://t.me/QARead
Здесь несколько экспертов по тестированию высказывают свою оценку выбранным статьям, есть русскоязычная и англоязычная версия

🔹 Заметки тестировщика
https://t.me/qanote
В канале можно найти различные истории, полезные ссылки, интересный канал

🔹Протестировал
https://t.me/sqaunderhood
Годный канал от тестировщика из Tarantool. Порой есть специфические кейсы, но интересно почитать даже их

🔹 Тестирование и жизнь
https://t.me/testing_and_life
Здесь мне нравится в целом особой взгляд на работу тестировщика, какие-то менеджерские темы и темы про софт-скиллс

🔹 Тестировщики нужны
https://t.me/qa_chillout
Интересный канал от тим лида из VK. По бОльшей части встречается контент по мобильному тестированию

🔹 Short QA Ideas
https://t.me/short_QA
Есть некоторые интересные темы, можно почитать

🔹 Yet another QA
https://t.me/yetanotherqa

#истории #tms
Про TMS-ки

В жизни почти каждого тестировщика рано или поздно появляется Test Management System (TMS) a.k.a. ТМСка или гуглдрайв или просто “место для хранения тестов”.

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

Но вот ТМСкам повезло не по-детски. То есть у них там есть свой процесс тестирования, а потом ещё и куча тестирощиков пользуются этим. Но от этого не легче, особенно когда в ТМСке куча багов. К такой ТМСке относится, например, Зефир (кстати, никогда не понимал, почему он так называется). Периодически там всплывают разного рода баги (неожиданно), бесячие и надоедливые. К примеру, нельзя было нормально растянуть список папок в дереве справа. Не знаю, сколько они фиксили эту проблему, но как будто бы всё равно натыкаешься на это ;) Я уж не говорю про документацию по API, просто шик.

Хочу уже попробовать "тест-кейс как код", может что и улучшится

#статьи #баги
🏔Ошибки, которые могут привести к блокерам

По мотивам моего комментария к статье "ТОП-10 ошибок тестировщиков, что приводят к блокерам".

▫️Не тестировать во всех версиях

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

Как можно избежать этого? Необходимо создавать чек-лист для тестирования; создавать отдельный таск на тестирование.

▫️Протестировать не во всех местах

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

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

▫️Слепо верить ТЗ и другим источникам

Тестировщик поверил тех. заданию/описанию и протестировал как там указано. В итоге фича реализована неверно, баг не пофикшен.

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

▫️Тестировать без открытой консоли (не всегда ошибки явно всплывают)

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

Что можно тут сделать? Включить автооткрытие консоли, настроить мониторинги на ошибки в консоли и следить за ними, назначая на ответственных.

▫️Незнание ценностей и приоритетов пользователей, из-за чего можно пропустить серьезные баги, хотя казалось бы

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

▫️Проверить один раз. А второй раз уже не работает;) Не забывать про стабильность.

Последний пункт на сегодня ;) Тут скорее больше исходя из опыта, да и остальные пункты тоже. Бывают такие штуки, которые отрабатывают 1-2 раза, но впоследствии работать не будут.

⏳Динамические среды для E2E тестов
#автоматизация

При встраивании автотестов в пайплайн часто возникает вопрос, а на каком конкретном инстансе (стенде, сайте, контуре и т.п.) будут запускаться наши автотесты. Как вариант использовать статические инстансы, но в этом подходе есть свои минусы, например, проблемы с тестовыми данными, перформансом и т.д.

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

Реализация зависит уже от самого приложения. Если ваше приложение уже как-то деплоится в облаке, используя подход "инфраструктура как код", то в принципе больших проблем быть не должно.


Про проблемы статичных сред: https://pipelinedriven.org/article/the-four-biggest-issues-with-having-static-environments

Более подробно про данный подход:
https://ephemeralenvironments.io/
https://pipelinedriven.org/article/ephemeral-environment-why-what-how-and-where

#статьи
✅ Как правильно (не) использовать тестировщиков

https://habr.com/ru/company/jugru/blog/661623/

Недавно наткнулся на текстовую статью от создателя Allure Report’а, смотрел этот доклад в записи.

Главные поинты:

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

Да, в целом это круто, если есть такая команда и всё работает как часы.
Скорее всего основной проблемой будет написание нативных тестов в одном репозитории, а также запуск автотестов на каждый PR (MR). Это не делается по щелчку пальцев, это требует усилий всей команды.
Если вы используете Allure Report / Allure TestOps, то по сути вы уже получаете live-документацию. С этим особо нет проблем.
Командное развитие - в принципе одно из важных направлений, тут нужно с самого начала прививать хорошие практики, проходить обучение, просто учиться у коллег или у других людей.


❓И вопрос ко всем, слышали ли вообще про данный подход? Или может быть вы уже стараетесь приблизиться к идеальной команде?😊