Реальное тестирование | О работе и росте тестировщика

#fun 😉 Есть ли ситуации в которых это было бы оправдано?

🔺 #ПонятьПросто: пирамида автоматизации тестирования

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

Сначала коротко о видах автотестов из этой пирамиды:

🧩 Unit-тесты проверяют маленький кусочек кода, например одну функцию, отдельно от всего остального. Обычно их пишут разработчики.

🔌 API-тесты проверяют систему через запросы, без визуального интерфейса: отправили запрос - проверили ответ.

💻 UI-тесты проверяют через визуальный интерфейс: нажимают кнопки и заполняют поля почти как пользователь.

Почему вообще пирамида, а не просто список? Потому что у пирамиды есть ширина, и она тоже кое-что сообщает.

Пирамида в удобной форме показывает, чем эти тесты отличаются по некоторым важным характеристикам. Каждый слой - это вид тестов, а ширина слоя показывает, сколько таких тестов рекомендуют иметь по сравнению с другими: внизу много unit-тестов, в середине меньше API-тестов, наверху совсем немного UI-тестов. Чем ниже слой, тем тесты быстрее выполняются, дешевле в поддержке, стабильнее, а еще и точнее показывают, где именно сломалось. UI-тесты хоть и ближе всего к пользователю, но прогон с ними идёт долго, тесты чаще падают из-за мелочей (поменяли вёрстку - тесты упали), а причину поломки искать дольше.

⚠️ Важно: пирамида - не правило и не готовый ответ, а подсказка, которая помогает думать. Она не говорит, сколько каких тестов нужно именно вам, зато помогает задать правильные вопросы: почему у нас так много медленных тестов? Можно ли проверить это на слое ниже? Может оказаться, что у вас разумнее иметь больше UI-тестов, чем API, - и это нормально, если вы понимаете почему.

Где здесь тестировщик? Чаще всего на двух верхних слоях. И когда нужно решить, проверить что-то через API или через визуальный интерфейс, универсально лучшего варианта нет. API - быстрее и стабильнее, UI - ближе к тому, что видит пользователь. Взвешиваем, что важнее в этой проверке и что больше подходит именно вашему проекту, с учётом его контекста.

Например, расчёт скидки с тридцатью комбинациями условий. Через API - тридцать проверок за секунды. А через визуальный интерфейс часто достаточно одного теста: что скидка вообще показывается в корзине.

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

🧩 Unit - кусочек кода, как и в первом варианте.

🔗Integration (интеграционные тесты) - связка частей: например, как два сервиса работают друг с другом.

🚩 E2E (end-to-end) - весь сценарий целиком, от начала до конца: например, найти товар, оформить заказ, оплатить.

Логика та же: внизу быстрых тестов больше, наверху медленных меньше. Разница только в том, по какому признаку разделены слои.

📌 Если вы только-только начали знакомиться с автотестами, достаточно запомнить три вещи:

1. в первую очередь нас интересуют такие автотесты:
🔌 API - проверяют систему через запросы
💻 UI - через визуальный интерфейс
2. API-тесты обычно быстрее и стабильнее, а UI-тесты ближе к тому, что видит пользователь
3. пирамида - не правило, а подсказка, которая помогает думать.

❓ А у вас на проекте каких автотестов больше: API или UI? Или автотестов пока нет совсем?

✉️ #ПисьмаИзЯщика
Пришло первое письмо в ящик 🌱

Я тестировщик с 9+ годами опыта. Попал в тестирование случайно за свой мощный технический бекграунд. Я хреновый тестировщик, так и еду на технической экспертизе которая ещё в большем отрыве стала. А для программирования я ленивый/тупой/не могу решить как перейти. ПАМАГИТИ

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

Просто потому, что на плохом отношении к себе далеко не уедешь. Когда я заранее решила, что я тупая и ленивая, мне уже незачем разбираться, что на самом деле происходит, - ответ-то готов. А когда отношусь к себе по-доброму, появляются силы: на любопытство, на то, чтобы честно посмотреть, что получается, а что нет, и двигаться дальше. Немного психологии, да, но без неё тут никуда.

То же самое можно сказать и честно, и без ярлыков. Например так:

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

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

1️⃣ «Хреновый тестировщик» - по каким фактам? Не по ощущению, а по конкретике: какие баги пропустила, что сделала хорошо, какие задачи мне доверяют. Ощущения и факты часто расходятся.

2️⃣ Мне хочется программировать - или кажется, что так надо?

3️⃣ Что конкретно мешает перейти? Не знаю, с чего начать? Страшно потерять уровень и деньги? Не уверена, что понравится? Это очень разные причины, и решаются они по-разному.

4️⃣ А что, если не решать сразу, а проверить? Написать скрипт для своей рутины, автотест, маленькую утилиту для команды - прямо на текущей работе. Так быстрее понять, тянет в программирование или нет.

И ещё: между «тестировщик» и «разработчик» не пустота. Автоматизация, нагрузочное тестирование, тестирование безопасности, работа с CI и инфраструктурой - везде сильная техническая база как раз большой плюс. Но выбирать дорогу, мне кажется, лучше из спокойного «мне интересно», а не из «я тупой» 😉

Ящик для анонимных писем открыт: https://t.me/questianonbot?start=272728370

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