Arapi QA Testing

#HappyTestersDay

Синдром самозванца при поиске работы: почему хороший QA может даже не откликнуться на вакансию

Самая неприятная часть синдрома самозванца - это то, что он не обязательно выглядит как мысль «я ничего не умею».

Чаще он звучит гораздо убедительнее:

«Ну да, я умею тестировать API, но это же не уровень настоящего QA».

«В вакансии написано 3 года опыта, а у меня только 2,5».

«Наверняка там будут вопросы, на которые я не отвечу».

«Сначала надо подтянуть SQL, а потом уже искать работу».

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

Хотя проблема в этот момент не в его профессиональных навыках.

В чем тут дело?

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

Получил хорошую обратную связь - «мне просто повезло с командой».

Разобрался со сложным багом - «ну, там задача была не такая уж сложная».

Прошёл техническое интервью - «просто попался хороший интервьюер».

А вот любую неудачу мозг воспринимает как подтверждение:

«Вот. Я так и знала, что на самом деле недостаточно хороша».

Получается довольно неприятная система. Успехи не считаются доказательством компетентности, а ошибки становятся доказательством её отсутствия.

И это часто проявляется при поиске работы.

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

Но вакансия не экзаменационный билет.

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

Что делать, если узнаёшь себя?

1. Отделять факт от интерпретации.

Например:

Факт: «Я не знаю Kubernetes».

Интерпретация: «Значит, я слабый QA и меня точно не возьмут».

Первое может быть правдой. Второе уже предположение.

И это очень полезно замечать во время поиска работы.

2. Завести папку с доказательствами компетентности.

Не «позитивные аффирмации», а реальные факты.

Например:

🔘какие баги ты находила
🔘какие сложные задачи решала
🔘какие инструменты освоила
🔘какую ответственность брала на себя
🔘какую положительную обратную связь получала
🔘что научилась делать самостоятельно

Когда мозг говорит «я вообще ничего не умею», не нужно спорить с ним.

Можно открыть список и спросить:

«Какие у меня есть факты?»

3. Не ждать ощущения «я готова».

Одна из ловушек синдрома самозванца:

«Вот ещё немного поучусь и тогда начну откликаться».

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

Поэтому полезнее поменять вопрос.

Не «Достаточно ли я хороша для этой вакансии?»

А «Насколько мой текущий опыт соответствует этой вакансии и чему я могу научиться, если получу её?»

4. Разрешить себе не знать ответа на собеседовании.

QA не человек, который знает всё.

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

Гораздо важнее способность рассуждать:

«Я с этим не сталкивалась, но попробую предположить…»

или

«Не знаю точно, но я бы пошла проверять это так…»

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

Это не значит, что Синдром самозванца обязательно нужно «победить», при чем прямо сейчас.

Иногда задача гораздо проще: научиться замечать момент, когда он начинает принимать решения за тебя.

«Я не буду откликаться» - это решение?

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

«Мне нужно ещё подготовиться» - это действительно план развития?

Или способ отложить возможную неудачу?

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

Твоя задача дать рынку возможность выбрать тебя.

А для этого сначала нужно отправить отклик и сходить уже на собеседование.

Arapi QA Testing pinned a video

Как правильно использовать нейросети в тестировании?

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

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

Теперь передовые модели (от Claude, Gemini, ChatGPT и ряда китайских опенсорсов) достаточно умные, чтобы понимать любую херню и выдавать нормальный результат, но без доступа к инструментам нейронки будут работать только с тем, что мы в них напрямую загрузили (а обычно этого недостаточно)

Здесь нам на помощь приходят MCP'шки — это что-то вроде мини-приложений, с помощью которых нейросеть подключается ко всем рабочим инструментам — таск-трекерам, браузерам, базам данных и репозиториям.

Условно, задачу по написанию автотеста с нейросетью, но без MCP можно решить так:
1) Скопировать тест-кейс из тест-менеджмент системы
2) Самостоятельно найти все локаторы через Devtools и четко поделить их по страницам
3) Залезть в документацию, вытащить всю релевантную информацию
4) Передать всю эту информацию нейросети
5) После написания кода скопировать его, запустить, посмотреть есть ли баги и все ли работает
6) Просить нейросеть внести правки, четко говоря, где возникают проблемы
7) Когда код написан, запушить его в репозиторий
8) Написать комментарий в задачу в таск-трекере, проставить статусы и т.д.

Очень много ручной работы! Но если на проект подключить нейросеть и дать ей все инструменты, работа может выглядеть так:
1) Написать нейросети "автоматизируй тест-кейс 1234"
2) Через несколько минут получить готовый результат

Нейросеть сама:
- Подключится к тест-менеджмент системе
- Изучит нужную документацию
- Откроет сайт, запустит Devtools и найдет локаторы
- Напишет тест
- Запустит и протестирует его работоспособность
- Запушит в репозиторий
- Внесет необходимую информацию в таск-трекер и закроет задачу

На своей учебной платформе я использую нейросети похоже:
- Передаю id задачи
- Она получает всю информацию, задает мне доп. вопросы (если нужно) и приступает к работе
- После завершения задачи отчитывается в трекере, и, если нужно — пишет письмо автору задачи

Починка багов и исправление опечаток/ошибок в материалах для меня теперь вообще не проблема.

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

Это я к тому, что на днях нашёл отличную статью по MCP для тестировщика — в ней рассказывается, какие MCP для всего этого могут пригодиться, и показывается, как это использовать.

P.S. если мне еще кто-нибудь расскажет "а у меня ваши chatgpt/claude не работают, чо ты мне про это затираешь", я забаню 😡. Если проблема решается тремя буквами — это не проблема.

Всем привет!

Давно не выходила на связь так как брала паузу после проекта, чтобы перевести дух. 🔋 (потребовалось больше времени, чем планировала).

Сейчас снова в строю и активно смотрю на рынок труда.
Делюсь находкой, (не реклама, вдруг будет полезно). Записалась на мастер-класс от agilefluent "Как пробить AI-фильтры". Тема сейчас очень актуальная, так как при поиске работы хочется избежать автоотказов и понять как AI и ATS реально отбирают кандидатов в 2026.

Делюсь ссылкой, вдруг кому-то из вас тоже актуально:
📅 8 июля | 19:00 МСК
🔗 Ссылка для регистрации

Собеседование QA: что важнее знания конкретной технологии или подхода?

Вот спрашивают тебя на собеседовании: "Как бы ты организовал на проекте кратное тестирование?".

Возможные варианты:
- ты знаешь, что такое "кратное тестирование" и блестяще отвечаешь;
- ты НЕ знаешь, что такое "кратное тестирование", и честно это признаёшь;
- ты НЕ знаешь, что такое "кратное тестирование", и задаёшь уточняющие вопросы, чтобы выяснить, что под этим понимается на проекте, какие есть ограничения, условия применения и тд

Ещё возможна четвёртая опция: "крайнего тестирования" не существует, но ИИ уже расписал тебе 10 инструментов для него.

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

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

Хай, гайс! Давно не слышались

Я тут вчера в одном из видео на около айтишную тематику нашла одну интересную мысль:

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

И если вдуматься - это реально так. Главный инструмент этой иллюзии - дедлайн

Работодатели часто манипулируют этим слово, очень искусно подменяя понятия

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

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

Звучит уже не так страшно, правда?

Есть один лайфах как понимать реальный ли это дедлайн или это просто манипуляция - достаточно задать инициатору задачи, простой вопрос:

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

Скорее всего ответ будет «нет». И тут уже на дедлайн ситуация не тянет

Допускаю, что не все делают это (или не все делают осознанно), но я предпочитаю придерживаться такой позиции, пока другая сторона не докажет обратного

О том, почему я пропала (и почему это может быть важно для вас)

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

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

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

Как я всегда вам говорила ошибки наши учителя. В ближайшее время здесь выйдет серия постов-разборов. Мы будем говорить честно и без прикрас о том:

Как распознать звоночки токсичности в самом начале. Я пропустила их, приняв за высокий темп работы.

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

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

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

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

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

Скоро начну рассказывать подробно. Будет больно, будет честно, но точно полезно. Я всегда открыта к обсуждению, и мнение каждого из вас мне интересно знать.

Всем привет!

Я участвовала в написании курса по ручному тестированию. Первый поток стартует 14 мая 2026 и я невероятно горжусь тем что получилось. О том как сильно актуализировался курс можно посмотреть по бесплатной части.

Это был интересный опыт, может быть я напишу свой курс вместе с Стейси "QA и AI в новых реалиях"

https://practicum.yandex.ru/qa-manual/

#SQL The 4 Types of SQL Joins Explained with Examples

Про обесценивание

Однажды я объясняла человеку суть своей профессии — чем я занимаюсь в своем ежедневном труде. Внимательно выслушав, он подытожил: а, ты просто кликаешь по кнопкам? Такое упрощение обескураживает даже бывалых.

Хочется откинуть эмоциональность и поговорить об обесценивании. Эта штука встречается чаще, чем кажется.

Обесценивание тестировщика может быть не только явным, но и скрытым. Вот несколько примеров:

1. Принижение сложности работы

«Ты же просто выполняешь тестовые сценарии»

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

2. Непропорциональная нагрузка

«Разработчик сделал фичу в последний момент, теперь тестируйте быстрее»

Тестирование воспринимается как что-то второстепенное, а не полноценный процесс, требующий времени.

3. Исключение из важных процессов

«Ой, мы уже всё обсудили»

Тестировщика не зовут на созвоны, не спрашивают мнение при планировании, а потом ждут, что он спасёт релиз.

4. Смещение ответственности

«Если баг ушёл в прод — это вина тестировщика»

Тестирование превращают в «громоотвод», хотя качество продукта — это ответственность всей команды.

5. Неуместные комментарии

«Почему так долго возитесь, там же задачка на 5 минут»

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

Как бороться с обесцениванием?

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

🔵Вовлекать разработчиков и менеджмент в процесс тестирования, чтобы они видели, как это работает

🔵Говорить на одном языке с бизнесом: объяснять, как тестирование влияет на прибыль, а не просто «ищет баги»

Для кого-то тестирование — это «тыкать кнопки». Для тестировщиков — это анализ рисков, построение тестовых стратегий, автоматизация, поиск уязвимостей на разных уровнях системы.

В общем, тестирование — важно, сложно, нужно.

Не обижайте тестировщиков ❤️

#куашная

С международным женским днём!

Желаю всем женщинам в QA и IT: интересных задач, сильных команд и уважительного профессионального окружения. Пусть ваша работа ценится, решения слышат, а карьерный рост зависит только от ваших навыков и интереса к делу. И пусть рядом всегда будут коллеги, которые поддерживают, а не конкурируют. 💛

🧪 Test implementation: подготовить всё, чтобы тесты можно было запустить

Если test design отвечает на вопрос
как мы будем тестировать?,
то test implementation задаёт более приземлённый, но критичный вопрос:
у нас вообще всё готово, чтобы начать выполнять тесты?

Именно здесь идеи превращаются в исполнимую реальность.

В ISTQB test implementation включает
разработку и приоритизацию test procedures(или тест-скриптов);

объединение тест-кейсов в test suites;

подготовку test execution schedule
в каком порядке и когда будут запускаться тесты;

настройку и проверку тестового окружения(инфраструктура, сервисы, симуляторы, виртуализация);

подготовку и загрузку test data;

проверку и обновление двусторонней traceability между test basis, test conditions, test cases, test procedures, test suites.

Проще говоря,
test implementation это всё, что нужно сделать,чтобы тесты можно было выполнить без сюрпризов.


❔ Почему этот этап часто недооценивают ISTQB приводит показательный пример

часть команд теряет до 25% времени выполнения тестов на так называемый environmental shakedown
спешную настройку окружения уже после старта тестирования.

Это не проблема тестирования как такового, а проблема плохой подготовки.

📌 Всё, что можно сделать до старта test execution,
нужно делать до старта test execution.

🧪 Про границы между активностями

Формально test design и test implementation разные активности.
На практике они часто выполняются вместе, перекрываются и идут параллельно.

Особенно это заметно в exploratory testing, где анализ, дизайн, реализация и выполнение происходят практически одновременно.

📌 Но даже если активности смешиваются,
полезно понимать, какую задачу ты решаешь в данный момент: придумываешь проверку или обеспечиваешь возможность её выполнения.

📘 Основа: Foundations of Software Testing, ISTQB, 4th Edition
✍️ Пересказ и комментарии

🧪 Test design: превратить что тестировать в конкретные проверки

Если test analysis отвечает на вопрос
что тестировать?, то test design отвечает на другой, не менее важный
как именно это тестировать?

Именно здесь абстрактные идеи превращаются
в конкретные проверки.

🔖 Что происходит в test design.
test conditions разворачиваются в: test cases, наборы тест-кейсов, другую тестовую документацию.
определяется и приоритизируется,
какие кейсы нужны в первую очередь,
подбираются или создаются test data.
проектируется тестовое окружение
(настройки, инфраструктура, инструменты).

фиксируется двусторонняя traceability
между test basis, test conditions, test cases, test procedures.

Проще: test analysis говорит о чём мы думаем, test design как именно мы будем это проверять.


❔ Интересный момент, который подчёркивает ISTQB дефекты часто обнаруживаются и на этапе test design.

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

Например:есть условие проверить граничные значения, но нигде не указано максимальное допустимое значение.

Это дефект test basis, и очень удачно, если он найден до выполнения тестов, а не в продакшене.

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

Какие именно задачи test design будут выполняться, зависит от проекта, продукта, рисков, уровня тестирования, ограничений по времени и ресурсам.

Как и весь тест-процесс,
test design адаптируется под контекст,
а не существует в универсальной форме.

📘 Основа: Foundations of Software Testing, ISTQB, 4th Edition
✍️ Пересказ и комментарии

🧪 Test analysis решить, что именно тестировать

Это точка, где тестирование перестаёт быть абстрактным и начинает отвечать на конкретный вопрос
что мы будем проверять и почему.

В ISTQB test analysis это активность, в которой: анализируется test basis,
выявляются testable features,
формулируются test conditions,
определяется, где и насколько глубоко тестировать.

Test basis это всё, на что мы опираемся при анализе:
требования и user stories,
спецификации,
дизайн и архитектура,
информация о реализации,
отчёты по рискам,
ожидания пользователей и стейкхолдеров.

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

В рамках анализа тестировщик:
оценивает test basis и test items,
ищет потенциальные дефекты ещё до тест-кейсов:
неоднозначности,
пропуски,
несоответствия,
неточности,
противоречия,
лишние требования.

определяет фичи и наборы фич, которые нужно тестировать.

формирует и приоритизирует test conditions с учётом функциональных, нефункциональных, структурных характеристик, бизнес-факторов, технических факторов и конечно же рисков.

обеспечивает двустороннюю traceability между test basis и test conditions.

📌 Traceability здесь нужна не для галочки, а чтобы понимать что не\покрыто и почему.

🔖Test conditions выявляются с помощью техник тест-дизайна (black-box, white-box), опыта, анализа рисков, exploratory testing (через test charters).

Чёткие test conditions снижают риск пропустить важные проверки, делают дальнейший тест-дизайн точнее, помогают осознанно управлять coverage.

🔖 Один из самых ценных эффектов test analysis дефекты находят до выполнения тестов. Если требования противоречат друг другу или описывают поведение, которое не имеет смысла, это лучше исправить сразу, чем превращать в баги позже.

📌 Хороший test analysis это профилактика дефектов,
а не подготовка к их поиску.

📘 Основа: Foundations of Software Testing, ISTQB, 4th Edition
✍️ Пересказ и комментарии

🧪 Активности и задачи тест-процесса

В ISTQB тестирование описывается не как один этап, а как набор взаимосвязанных активностей.

Формально их семь, но они часто группируются и перекрываются.
1. Test planning
2. Test monitoring and control
3. Test analysis
4. Test design
5. Test implementation
6. Test execution
7. Test completion

Эти активности выглядят последовательными, но на практике почти всегда выполняются параллельно и итеративно. Особенно в Agile.

🔖 Test planning это не написать тест-план ради документа.
Это определение целей тестирования, выбор подходов и техник, решение, что именно тестировать, а что нет, определение задач, сроков и ресурсов.

Хорошая метафора из книги:
планирование это не рисование маршрута по готовой карте, а иногда прокладывание пути там, где карты ещё нет.

🔖 Test monitoring and control

monitoring - наблюдение и постоянный ответ на вопрос где мы сейчас относительно плана?

Сюда входят отслеживание прогресса,
анализ отклонений, отчётность.

Control это действия когда меняется приоритет, появляются риски, план перестаёт работать, нужно корректировать подход,
а иногда остановить тестирование или проект, если цели больше не достижимы.

Важный инструмент здесь exit criteria
по каким условиям мы считаем этап завершённым.

ISTQB подчёркивает test process, а не жёсткий the test process.

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

📌 Если тест-процесс не подстраивается под продукт,
он перестаёт помогать и начинает мешать.

📘 Основа: Foundations of Software Testing, ISTQB, 4th Edition
✍️ Пересказ и комментарии.

🧪 Немного про coverage

coverage - частичная мера того, насколько полно мы протестировали систему.

Coverage показывает, какая доля выбранных элементов была реально проверена:
требований, user stories, путей взаимодействия, модулей или веток кода, конфигураций окружения, устройств, пользовательских сценариев.

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

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

📘 Основа: Foundations of Software Testing, ISTQB, 4th Edition
✍️ Пересказ и комментарии

🧪 Тест-процесс всегда зависит от контекста

Не существует одного “правильного” тест-процесса для всех.
Каждая команда и каждый продукт вынуждены адаптировать тестирование под свой контекст.
И этот контекст складывается из множества факторов.

Вот что на него влияет:
Модель разработки и методология ->
Agile-приложение для мобильных устройств и медицинское ПО
не могут тестироваться одинаково.

Уровни и типы тестирования ->
Чем сложнее система, тем больше уровней и типов тестов и тем сложнее сам процесс.

Риски продукта и проекта -> Низкие риски меньше формализации.
Высокие риски больше проверок, документации и контроля.

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

📌 Из этого следует важная мысль:
хороший тест-процесс это не самый формальный и не самый лёгкий, а тот, который адекватен своему контексту.

🧪 Процесс тестирования не шаблон, а система решений

Когда говорят тест-процесс, часто представляют жёсткую последовательность шагов.

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

И ключевая мысль здесь - контекст.

Нет универсального тест-процесса,
который одинаково подойдёт всем продуктам, командам, организациям и
стадиям жизненного цикла.

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

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

Отдельный акцент ISTQB делает на traceability связь между тестовой базой (требования, user stories, дизайн) и тестовыми артефактами (кейсы, условия, наборы тестов).

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

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

📘 Основа: Foundations of Software Testing, ISTQB, 4th Edition
✍️ Пересказ и комментарии

🧪 Семь принципов тестирования

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

1. Тестирование показывает наличие дефектов, а не их отсутствие
Тестирование может доказать, что дефекты есть.
Но оно не может доказать, что их нет.
Отсутствие найденных багов ≠ отсутствие проблем.

2. Исчерпывающее тестирование невозможно
Проверить всё и все комбинации нельзя.
Поэтому тестирование это всегда выбор,
основанный на рисках, приоритетах и контексте.

3. Раннее тестирование экономит время и деньги
Чем раньше найден дефект,
тем дешевле и проще его исправить.
Ошибки, найденные на этапе требований,
стоят несравнимо меньше, чем те же ошибки в продакшене.

4. Кластеризация дефектов
Большинство дефектов обычно сосредоточено
в небольшом количестве компонентов.
Это не случайность,
а повод внимательнее смотреть именно туда.

5. Парадокс пестицида
Если постоянно запускать одни и те же тесты,
они перестают находить новые дефекты.
Тесты нужно пересматривать, обновлять и дополнять.

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

7. Заблуждение об отсутствии ошибок
Даже если дефектов нет,
это ещё не значит, что система полезна.
Продукт может быть без багов
и при этом не решать задачу пользователя.

📌 Эти принципы не про технику, а про мышление.
И почти каждый серьёзный конфликт вокруг качества
можно свести к игнорированию одного из них.

📘 Основа: Foundations of Software Testing, ISTQB, 4th Edition
✍️ Пересказ и комментарии