TESTOREST

⚛️ Оказывается тут вышел бесплатный интерактивный учебник на 700 страниц по тестированию 🤓

Учебник с практическими занятиями и позиционируется как углубленная теория + практика.
Чтобы поднять свой уровень до твердого джуна или pre-midle.


Работа, конечно грандиозная и такой большой объем информации!
Скажем спасибо тем, кто ее проделал🙏

Кто готов, прошу исследовать: https://clck.ru/35roTP

#учебник #обучение
@testorest

⚛️Сложный случай на проекте глазами QA-лида и как мы это победили

Часть 2

Что было сделано в нашем проекте?

Как и обещала, ловите пост продолжение.

Когда мы поняли, что дальше так продолжаться не может, то решили:

🔹посчитать мощность команды за спринт(чтобы знать сколько задач сможем закрыть)

🔹проводить планирование спринта и следовать намеченому курсу

🔹поговорить с заказником о приоретизации фич

🔹договорились провести более длительный регресс для отлова и фикса багов

🔹оставшиеся баги согласовывались с заказчиком(иногда,за счет этого, удавалось выделить на багфикс еще больше времени)

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

🔹договорились о ближайшем графике выпуска релизов и старались ему следовать


Что изменилось:

🔹понемногу ушли жесткие дедлайны

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

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

🔹в пределах вменяемых сроков каждый специалист смог проявить себя в лучшем качестве(начали внедрять улучшения в каждом этапе разработки)

🔹удалось сохранить большую часть команды

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


Какие изменения помогли выжить вашему проекту?
Делитесь, в комментариях к посту.


@testorest

⚛️Сложный случай на проекте глазами QA-лида и как мы это победили

Часть 1

Однажды, работая на проекте сложилась следующая ситуация:

🔹релизы выпускались без графика - хаотично
🔹от новости о необходимости выпуска релиза до выпуска проходило 1-3 дня,
как следует готовиться мы в таком режиме не успевали
🔹было очень много багов на регрессе
🔹много багов уходило с релизом заказчику
🔹отзыв о качестве продукта был, мягко говоря, не лучший

Команда:

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

Ошибки:

🔹брали на себя много обязательств, которые заведомо не могли выполнить в нужный срок
🔹не могли сказать «нет» заказчику
🔹не договаривались о нужных сроках, а просто брали все, что поступало от заказчика в ближайший релиз

Как следствие, ситуация только ухудшалась:

🔹не было времени на более тщательное тестирование
🔹баги расти в геометрической прогрессии

Ставьте реакции, кто сталкивался или сейчас находится в подобной ситуации🤕

Что было сделано в нашем проекте?
Опишу сегодня во 2ой части после 17:00.

@testorest

⚛️ Контрактное тестирование

Уровень сложности-->🤓🤓🤓🤓🤯
(4 из 5)
А кто говорил, что будет легко?))

Что это?

Позволяет проводить тестирование взаимодействия нескольких компонентов отдельно друг от друга.
Представьте, что два микросервиса обмениваются данными.
Один из них потребитель (клиент).
Второй - поставщик.

Например

Сервис №1 вызывает api сервиса №2.
В ответ сервис №1 ожидает получить статус выполнения - Код 200.

В данном случае:

сервис №1 - потребитель(клиент, consumer)
сервис №2 - поставщик(provider)

Разница между обычным интеграционным и контрактным тестированием.

При обычном интеграционном тестировании нам нужно было, чтобы оба сервиса были установлены/ включены на стенде тестирования.

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

Как?

Делается это обычно с помощью моков(заглушек).

В нашем примере, сервис №2 заменяется заглушкой(моком).

В тестах проверяется реакция сервиса №1 на присланный код 200.

Как вы могли догадаться, делается это с помощью автотестов.

Моки знают как отвечать на заранее известные http-запросы.

И тогда схема тестирования выглядит так:

1️⃣Сервис №1 (потребитель) проверятся с помощью моков

2️⃣Взаимодействие фиксируется в виде контракта

3️⃣Контракт передается в команду Сервиса №2

4️⃣Запросы из контракта вызывают апи сервиса №2, проверяются ответы апи и соответствуют ли они ожиданиям потребителя.

5️⃣Сервис №2 (поставщик) публикует результат проверки

Таким образом удается независимо проверить каждую сторону взаимодействия.

🔆🔆🔆

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

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

Такой подход контрактный тестов относительно потребителя называется еще Consumer Driven Contract.
Бывает противоположный подход, когда пишут контрактные тесты со стороны поставщика, но такое можно встретить не часто.

Так же есть специальные инструменты, помогающие в контрактном тестировании: PactFlow
Spring Cloud Contracts

#контрактное_тестирование #cdc #contract_test

@testorest

⚛️ Развеиваем миф, что тестирование это однообразная и монотонная работа👨‍💻

Приходишь очередной день на работу, а там:

1️⃣Обновили какую-нибудь библиотеку для проекта😲
Вы может быть о ней и не знали до этого.
Но теперь придется проверять, что все работает.
Перед этим, конечно, нужно ознакомится с данной библиотекой и на что она влияет.

2️⃣Перешли на новую версию БД😲
Выясняем на что влияет- тестируем.

3️⃣Перестали формироваться тест-сеты в системе управления тестами, так как поставили обновление🔭
Разбираемся что к чему. Гуглим, откатываемся на прошлую версию или ставим обновление.
А может теперь тест-сеты формируются по другому? Нужно будет изучить и попробовать.

4️⃣Внедряем автоматизацию тестирования в части тест-кейсов🤖
🤓 тут придется много читать и гуглить тоже))
Какую IDE ставить, как ее ставить. Какие зависимости нужны проекту?
Что автоматизируем в первую очередь, как отслеживаем прогресс, какой фремворк автотестирования используем?
И т.д.

5️⃣Соседняя команда просит помочь с интеграционным тестированием🆘
Планируем деятельность, изучаем влияние, тестируем.

6️⃣Попросили рассказать о своем опыте раннего отлова ошибок🎤
Пишем презентацию, рассказываем коллегам)

И т.д.

P.S. А если вы думаете, в какие направления можно равиваться тестировщику, посмотрите пост 👉 https://t.me/testorest/198

#qa_миф #развитие

@testorest

⚛️ Долгожданный, а может и нет, ответ на вопрос "Почему стало так сложно устроиться тестировщиком"..

Всем привет!
Накатала статью 👨‍💻 - кто готов - можете ознакомится👇

https://telegra.ph/Pochemu-stalo-tak-slozhno-ustroitsya-testirovshchikom-08-14

@testorest