1. Корректные значения
2. Некорректные значения (за пределами валидных диапазонов или нелогичные: 200 лет, 88 секунд...)
3. Граничные значения
4. Пограничные значения
5. Дробное число — формат (через запятую и через точку)
6. Дробное число — округление (с кучей знаков после запятой)
7. Ноль
8. Один
9. Пустое поле
10. Очень большое число (поиск технологической границы)
11. Отрицательное число
12. Нечисловые и «не совсем числовые» значения

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

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

Я недавно латала дыры в понимании разницы между Quality Assuarance и Quality Control. Статей на эту тему много, я накидала свой вариант, хотелось по существу. Делюсь с вами. Enjoy, если актуально!

Эта статья является конспектом книги «Принципы юнит-тестирования». Материал статьи посвящен интеграционным тестам.

Юнит-тесты прекрасно справляются с проверкой бизнес-логики, но проверять эту логику «в вакууме» недостаточно. Необходимо проверять, как разные ее части интегрируются друг с другом и внешними системами: базой данных, шиной сообщений и т. д.

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

API (Application Programming Interface, программный интерфейс приложения), является жизненно важным компонентом в современном ландшафте разработки программного обеспечения, обеспечивая строительные блоки для взаимодействия приложений друг с другом. В этой статье рассмотрим пять основных типов API: REST, SOAP, WebSocket, gRPC и GraphQL, чтобы получить более четкое представление об их функциях, особенностях и идеальных сценариях использования.

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

Введение

Терминология

• «Забытый слой пирамиды автоматических тестов» (Майк Кон, 2009)
• «Пирамида тестов» (Мартин Фаулер, 2012)
• «Блог отдела тестирования Google» (Google, 2015)
• «Пирамида тестов на практике» (Хэм Фокке, 2018)

Содержание

• 1. Антипаттерны: плохое обоснование
  
  • 1.1. Очевидно же
  • 1.2. Мамой клянусь!
  • 1.3. Зайчики обиделись
• 2. Хорошие паттерны обоснования
  
  • 2.1. Пруфлинк
    
    • Ссылка на требования
    • Сами требования
    • Ссылка в интернет
    • Письмо заказчика
    • ROI
    • Статистика
  • 2.2. Единообразие
  • 2.3. Проблема, или #жизньболь
• 3. Когда обоснование не нужно
• 4. Итоги

• это действительно баг;
• его необходимо исправить;
• его нужно исправить именно так, как мы сказали.

• Коллеги отвлекают с вопросами «А почему это баг?», вырывая из контекста.
• Спустя месяц ты сам забыл, а, собственно, почему это был баг…

• начинающих тестировщиков — узнайте, как грамотно объяснять свою точку зрения;
• тест-менеджеров — чтобы дать ссылку своим падаванам и потом ссылаться на антипаттерны без дополнительных объяснений.

1. Антипаттерны: плохое обоснование

Сегодня в среде разработчиков часто продвигают GraphQL в качестве замены REST, хотя обе технологии можно использовать одновременно. В этой статье Анастасия Иванова, технический писатель платформы МТС Exolve (входит в экосистему МТС), рассмотрит интерфейсы подробнее, чтобы понять, как выбрать подходящее решение под каждый конкретный проект. Подробности — под катом.

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

Привет, Хабр!

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

Так какие особенности сопутствуют тестированию десктопных приложений?

Проведение анализа дефектов, обнаруженных на продакшене, кажется сложной и трудоемкой задачей. Однако в команде Polymatica мы успешно интегрировали этот процесс в цикл тестирования, сделав его неотъемлемой частью обеспечения качества ПО. Локализация дефектов с прода имеет наивысший приоритет, и мы создали эффективный подход для их анализа и устранения. Данный процесс постоянный и непрерывный, что позволяет нам постоянно совершенствоваться.

Привет, Хабр! Меня зовут Иван, я Full Stack QA. Сегодня поговорим про альтернативы ChatGPT, которые работают на территории РФ без костылей и совершенно бесплатно.

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

Главное правило ручного тестировщика - для начала нагугли проблему спроси у GPT и только после обращайся с вопросом к ментору.

🤖 Первый аналог - Coze.com | Открыть модель

Первый ИИ работает в телеграм-боте и всегда будет у вас под рукой...

Привет! Продолжаем цикл статей про тестирование не-REST-бэкенда, в прошлый раз мы говорили о GraphQL, теперь пришло время WebSocket.

Итак, что такое WebSocket?

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

Что тут важно — что это протокол (со всеми вытекающими последствиями для протокола), который использует постоянное соединение.

Работу по WebSocket в обычной жизни можно представить примерно так.

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

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

ОК, что вам делать в такой ситуации?

Привет! Меня зовут Сергей, я более 11 лет в тестировании, и успел за это время перепробовать множество разных подходов в QA — начинал простым тестировщиком, затем строил и развивал всевозможные отделы тестирования и автоматизации, а сейчас работаю в QIWI.

В этой серии постов я хочу поговорить с вами про тестирование трех популярных так называемых не-REST-бэкендов. Самое главное для начала — определиться с терминами, договоримся, что везде в тексте, где я упоминаю REST — речь идет именно о REST HTTP-бэкенде. Наверняка многие из вас с ним работали и вообще неплохо знакомы.

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

Под катом — разбор тестирования первого из этой тройки, GraphQL. Все примеры в посте я делал с помощью Postman, он достаточно популярен и доступен, чтобы вы при желании могли всё быстро в нём повторить.

Туториал по работе с логами в Kibana для начинающих специалистов по тестированию ПО.

У Kibana имеется свой язык запросов KQL (Kibana Query Language) - официальный источник. С помощью этого языка можно составлять запросы, которые помогают отфильтровывать и найти необходимую информацию.

Подключение к Kibana для просмотра логов.