📌 Шпаргалка V-модели

V-модель – это усовершенствованный вариант каскадной модели, где каждому этапу проектирования соответствует свой уровень тестирования.

Принципы V-модели:

🔜 Контроль и тестирование на каждом этапе

🔜 Четкая последовательность действий

🔜 Определение критериев входа и выхода

Когда использовать:

🔹 При жестких сроках и бюджете

🔹 В проектах с высоким уровнем тестового покрытия

🐸 Библиотека тестировщика

#буст

🔥 Сколько времени нужно, чтобы войти в IT: реальные цифры

Мы спросили подписчиков, сколько у них занял переход «хочу в IT» → первая работа. Вот результаты.

🔵 38,4% справились за год
🔵 30,4% потребовалось 1-2 года
🔵 17,9% шли 2-3 года
🔵 13,4% учились и пробивались больше 4 лет

Как входили в IT
🔵 53,4% изучали самостоятельно
🔵 24,1% учились на курсах
🔵 Остальные — через вуз, наставников, стажировки

У всех путь разный, но главное — не останавливаться. Кто-то заходит в IT за 6 месяцев, кто-то — за 3 года. Но если идти — дойдёшь.

Азбука айтишника #мотивасьон

📌 Как создать тест-кейсы для нового функционала

Рассмотрим детально этапы создания тест-кейсов:

1️⃣ Анализ требований

Шаги:

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

• Обсуждение с заинтересованными сторонами: проведите встречи с бизнес-аналитиками, разработчиками и конечными пользователями, чтобы уточнить детали и ожидания.

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

2️⃣ Определение тестируемых аспектов

Шаги:

• Приоритизация функций: Определите, какие части функционала наиболее важны для бизнеса и пользователей, и должны быть протестированы в первую очередь.

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

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

3️⃣ Разработка тест-кейсов

Шаги:

• Создание структуры тест-кейса: Оформите тест-кейсы с обязательными атрибутами:

• Идентификатор: Уникальный номер или код теста.

• Название: Краткое и ясное описание цели теста.

• Предусловия: Условия, которые должны быть выполнены перед запуском теста.

• Шаги выполнения: Последовательность действий, которые необходимо выполнить.

• Ожидаемый результат: Описание того, что должно произойти после выполнения шагов.

• Приоритет: Степень важности теста, влияющая на порядок его выполнения.

• Фактический результат: Реальный результат после выполнения теста (заполняется после исполнения).

• Статус: Результат прохождения теста (успешно/неуспешно).

• Разработка различных типов тестов:

• Позитивные тесты: Проверяют корректную работу функционала при вводе правильных данных.

• Негативные тесты: Оценивают реакцию системы на некорректные или неожиданные данные.

• Граничные тесты: Тестируют поведение системы на границах допустимых значений.

• Использование шаблонов: Применяйте стандартизированные формы для обеспечения единообразия и полноты тест-кейсов.

4️⃣ Ревью и утверждение

Шаги:

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

• Сбор обратной связи: Получите комментарии и предложения по улучшению тестов.

• Внесение корректировок: Обновите тест-кейсы с учетом полученной обратной связи, устранив выявленные недостатки.

• Утверждение тест-кейсов: После доработки представьте тест-кейсы на утверждение руководству или ответственным лицам.

🐸 Библиотека тестировщика

#буст

💬 Как оставлять комментарии в чате нашего канала

В нашем чате работает бот Shieldy — он защищает от спама, запрашивая у новых участников решение простой капчи.

⚠️ Проблема, с которой сталкиваются многие: вы нажимаете под постом «Прокомментировать», пишете что-то, а потом получаете бан и не можете писать комментарии.

❓Почему так: Shieldy отправляет капчу в сам чат, а не в комментарии под конкретный пост. Из-за этого капчу можно не увидеть, не отправить ответ на нее, и бот автоматически заблокирует вас.

✅ Как присоединиться к чату, чтобы бот вас не забанил

— Зайдите в описание канала с телефона и нажмите кнопку Discuss / Чат
— Нажмите Join / Присоединиться
— Сразу обратите внимание на сообщение от бота Shieldy
— Решите простой пример и отправьте ответ в чат

После этого бот отправит приветственное сообщение и вы сможете оставлять комментарии. Эту проверку нужно пройти только один раз при вступлении в чат.

❗️ Если вас все-таки забанили

— Это временная блокировка на несколько минут
— Подождите и попробуйте зайти позже, бот снова отправит вам капчу

Админы канала никак не могут ускорить процесс, бот автоматически снимает с вас блокировку через пару минут. Мы понимаем, что эта система неидеальна, и ищем более удобное решение.

👾 Спасибо, что активно участвуете в обсуждении наших постов!

🔫🔫

🐸 Библиотека тестировщика

#развлекалово

😱 Сломай, если сможешь

Сегодняшний промпт поможет вам находить уязвимости в системе, еще до того, как пользователи успеют их эксплуатировать.

Промпт:

«Представь, что ты хакер (но белый), который ищет самые изощренные способы сломать систему. Разбери функционал [описание функционала] и найди потенциальные уязвимости, нестандартные сценарии и неожиданные точки отказа. Также предложи стратегии тестирования, чтобы обнаружить эти слабые места раньше, чем ими воспользуется кто-то другой.»

Как использовать:

1️⃣ Подставьте нужный функционал, например, «обработка платежей через сторонний сервис».

2️⃣ Прогоните промпт через ChatGPT или другой AI.

Добавьте уточнение вроде «учти баги безопасности» или «предложи хаос-тестирование», чтобы получить еще более глубокий анализ.

Какой самый коварный баг удалось найти благодаря этому методу? Делитесь в комментариях! 🔽

🐸 Библиотека тестировщика

#буст

🏗 7 основных стратегий обеспечения устойчивости распределенных систем

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

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

🔗 Читать статью
🔗 Зеркало

🐸 Библиотека хакера

😎 .fill() vs .type(): кого выбрать и почему это важно

Если ты до сих пор используешь .type() для ввода текста в поля — пора пересмотреть привычки.

Да, .type() симулирует «настоящий» ввод, по буквам.

Звучит реалистично, но:

➡️ медленно, особенно в больших тестах;

➡️ может сломаться, если на странице сработает автофокус, маска или задержка между символами;

➡️ анимации, валидации, вся эта магия может среагировать не так, как надо.

Лайфхак: используй .fill() вместо .type().

Пример:

// Было:
await page.type('input[name="username"]', 'QA_warrior_3000');

// Стало:
await page.fill('input[name="username"]', 'QA_warrior_3000');

Чем это лучше:

1️⃣ Быстрее.

2️⃣ Стабильнее.

3️⃣ Тесты меньше флапают (да, именно ты, flaky test, мы на тебя смотрим).

Вывод: fill() — твой новый дефолт. type() — только когда нужен эффект «печатания» от пользователя.

🐸 Библиотека тестировщика

#буст

👍 Тест-кейсы, которые не спасли от бага

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

В Библиотеке тестировщика мы знаем, что лучшие истории — это те, которые учат нас быть ещё внимательнее.

Делитесь своими случаями, когда ⬇️

— Все тесты пройдены, но баг оказался в неожиданном месте.
— Тест-кейсы были идеальными, но реальный пользователь нашёл дыру.
— Логика проверена, но один особенный браузер решил иначе.
— Автотесты радовались жизни, а на проде разразился ад.

Начнём с истории нашего тест-лида:

Когда-то мы тестировали обновление профиля пользователя. Форма работала идеально: валидация, кнопки, автотесты — всё чётко. Выпустили в прод, и тут посыпались жалобы, что сменить имя невозможно. Оказалось, что у некоторых пользователей были в именах эмодзи, а новый бэкенд их не пропускал. Конечно, у нас были тестовые данные, но никому не пришло в голову проверить, что кто-то реально зовёт себя "🦄✨". Первый хотфикс в моей карьере был про эмодзи.

🐸 Библиотека тестировщика

#междусобойчик

Баг в пятницу — это как гость без приглашения, который пришел с чемоданом… и настроением остаться до понедельника 🥲

🐸 Библиотека тестировщика

#развлекалово

📣 Дайджест материалов за неделю

🔘 Жизненный цикл ПО: этапы и что на них происходит

🔘 Шпаргалка V-модели: принципы, когда использовать

🔘 Как создать тест-кейсы для нового функционала

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

🔘 .fill() vs .type(): кого выбрать и почему это важно

🐸 Библиотека тестировщика

#свежак

💻 День, когда компьютеры начали думать быстрее нас

22 марта 1993 года Intel показала миру Pentium — процессор, с которого началась новая эра.

Изначально хотели назвать его просто «586» и запатентовать, но цифры патенту не поддаются.
Пришлось креативить — так появилось благородное имя Pentium (намёк на «пятое поколение»).

С ним люди поняли: мегагерцы — это не болезнь, а скорость.
Pentium стал не просто культовым — он дал старт безумной гонке за мощностью,
благодаря которой ты сейчас читаешь это мгновенно, а не ждёшь, пока загрузится каждая строчка 😎

🐸 Библиотека тестировщика

#свежак

🥰 Тестирование API в Postman с использованием коллекций запросов

Создание коллекции запросов и написание для каждого из них тестов позволяет быстро проверять корректность работы API и находить ошибки ещё до попадания в прод.

Как это сделать:

1️⃣ Создайте новую коллекцию в Postman

Назовите её по назначению, например, ”Product API Tests”.

2️⃣ Добавьте в коллекцию основные типы запросов:

• GET — получение информации о товаре.

Тесты: проверка статус-кода 200, структура и содержание ответа.

• POST — добавление нового товара.

Тесты: проверка статус-кода 201, наличие ID нового товара в ответе, корректность переданных данных.

• PUT — обновление информации о товаре.

Тесты: проверка статус-кода 200, соответствие обновлённого объекта ожидаемым данным.

• DELETE — удаление товара.

Тесты: статус-код 204 или 200, проверка отсутствия товара при последующем GET-запросе.

3️⃣ Добавьте тесты в каждый запрос.

В Postman можно использовать встроенный JavaScript, чтобы написать проверки:

pm.test("Status code is 200", function () {
pm.response.to.have.status(200);
});

🔜 Пишите тесты на:

• Статус-коды

• Структуру и содержимое тела ответа

• Логические проверки (например, цена не может быть отрицательной)

Такая структура делает тестирование системным и позволяет быстро находить проблемы при изменениях в API.

🐸 Библиотека тестировщика

#буст

☸️ CKAD 2025. Самый свежий гайд по сдаче сертификации Certified Kubernetes Application Developer

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

➡️ Читать статью

🐸Библиотека devops'a

⭐️ Testcontainers

Testcontainers — это библиотека с открытым исходным кодом, позволяющая создавать временные, изолированные контейнеры для интеграционного тестирования.

Она поддерживает различные языки программирования, включая Java, .NET, Go, Node.js, Python и другие .

📍Для чего используется:

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

📍Преимущества:

• Изоляция окружения: каждый тест запускается в своем собственном контейнере, что предотвращает конфликты и обеспечивает чистоту состояния.

• Гибкость: поддержка множества технологий, включая реляционные и NoSQL базы данных, системы кэширования, брокеры сообщений и другие сервисы .

• Автоматизация: контейнеры автоматически создаются перед запуском тестов и удаляются после их завершения, что упрощает настройку и управление тестовым окружением.

📍Пример использования на Java:

Допустим, вы хотите протестировать взаимодействие с PostgreSQL:

import org.testcontainers.containers.PostgreSQLContainer;

public class Demo {
public static void main(String[] args) {
try (PostgreSQLContainer<?> postgres = new PostgreSQLContainer<>("postgres:15")) {
postgres.start();

String url = postgres.getJdbcUrl();
String user = postgres.getUsername();
String password = postgres.getPassword();

System.out.println("Подключение: " + url);
// Тут можно подключиться к БД и выполнить тестовые запросы

// PostgreSQL остановится автоматически при выходе из try
}
}
}

В этом примере контейнер с PostgreSQL версии 15 поднимается перед выполнением теста и автоматически завершается после его завершения .

📍Когда применять:

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

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

• Для упрощения процесса настройки и управления зависимостями в тестовом окружении.

🐸 Библиотека тестировщика

#буст