Тема 1. Основы тестирования программного обеспечения

Тестирование программного обеспечения — это ключевой процесс обеспечения качества (QA), который заключается в проверке соответствия работы программы заявленным требованиям. Основная задача тестирования — выявить несоответствия между тем, что программа должна делать, и тем, что она делает на самом деле. По сути, тестирование представляет собой процесс сравнения “что есть” с “как должно быть”. Это помогает выявить дефекты, которые могут негативно сказаться на конечном продукте и его пользователях.

Что такое тестирование?
По международным стандартам, тестирование определяется как процесс наблюдения за выполнением программы в специальных условиях с целью оценки её работы. Эти условия обычно задаются в виде тестовых сценариев — конкретных последовательностей действий, направленных на проверку той или иной функциональности системы. Качественно созданный тестовый сценарий включает в себя три ключевых элемента:
 • Входные данные: это данные, которые вводятся в программу для проверки её поведения;
 • Ожидаемый результат: это результат, который должен быть получен при корректной работе программы;
 • Порядок выполнения: это точная последовательность шагов, необходимых для выполнения теста.

Читать статью целиком.
———
Цикл статей на основе перевода книги Ли Копланда “A Practitioner's Guide to Software Test Design”.
———
#qa #pro_qa #qa_чтиво #qa_знания

Тема 2. Процесс тестирования ПО: Этапы и ключевые задачи

Процесс тестирования программного обеспечения (ПО) — это структурированный и систематический подход к оценке качества разрабатываемой системы. Он включает несколько этапов, начиная с планирования и проектирования тестов и заканчивая анализом результатов и отчетностью. Каждый этап процесса важен для достижения главной цели — выявления и устранения дефектов, которые могут повлиять на работу программы. В этой статье, основанной на материалах книги Ли Копланда "A Practitioner's Guide to Software Test Design", рассмотрим основные шаги процесса тестирования и его ключевые задачи.

Этапы процесса тестирования
1. Планирование тестов
2. Проектирование тестов
3. Исполнение тестов
4. Анализ результатов тестирования
5. Отчет о тестировании

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

Ключевые задачи этапа планирования:
* Определение объектов тестирования: что именно будет тестироваться — конкретные модули, функциональные блоки или вся система.
* Определение целей тестирования: основная цель тестов — это выявление дефектов и повышение уверенности в том, что система работает корректно.
* Оценка рисков: возможные проблемы, такие как нехватка времени, ресурсов или изменяющиеся требования.
* Определение методов тестирования: выбор подходов, таких как тестирование "черного ящика" или "белого ящика".
* Планирование инструментов и ресурсов: решение, какие инструменты и тестовые среды потребуются для выполнения тестов.

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

Читать статью целиком.
———
Цикл статей на основе перевода книги Ли Копланда “A Practitioner's Guide to Software Test Design”.
———
#qa #pro_qa #qa_чтиво #qa_знания

Тема 3. Типичные проблемы в тестировании программного обеспечения

Тестирование программного обеспечения (ПО) — это сложный и многогранный процесс, который сталкивается с множеством вызовов и проблем. Независимо от уровня зрелости организации, тестировщики часто сталкиваются с типичными трудностями, которые могут существенно усложнить работу и повлиять на качество тестирования. В этой статье, основанной на материалах книги Ли Копланда “A Practitioner’s Guide to Software Test Design”, мы рассмотрим наиболее распространённые проблемы в тестировании ПО и предложим способы их решения.

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

Причины:
• Неэффективное планирование.
• Постоянные изменения в требованиях и разработке.
• Давление со стороны менеджмента для ускоренного выпуска продукта.

Решения:
• Приоритизация тестов: Сосредоточьтесь на тестировании критически важных функций и наиболее рискованных областей. Это позволит максимально эффективно использовать ограниченное время.
• Автоматизация тестов: Автоматизация рутинных задач тестирования позволяет сэкономить время на более сложные проверки.
• Раннее начало тестирования: Включайте тестирование на самых ранних стадиях разработки (Shift-Left Testing), что позволит выявлять дефекты до того, как они повлияют на весь проект.

Читать статью целиком.
———
Цикл статей на основе перевода книги Ли Копланда “A Practitioner's Guide to Software Test Design”.
———
#qa #pro_qa #qa_чтиво #qa_знания

Сегодня ровно 3 месяца как я начал писать здесь. Уже 400+ подписчиков. И это здорово!

С одной стороны несколько организует (например последний эксперимент с книгой по тест-дизайну, которую разбил на 25 тем в кратком изложении 😎), с другой стороны в виду того, что сайт до сих пор в разработке - есть что показать наружу, да и на менторство народ стал активно заходить.

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

В любом случае, хочу поблагодарить всех читателей и тех кто оставляет комментарии к постам! 🍹

#qa #pro_qa

Тема 4. Методы тестирования “черного ящика”

Тестирование “черного ящика” — это метод проверки программного обеспечения, при котором тестировщики работают исключительно с внешними функциями системы, не имея доступа к её внутренней структуре или коду. Этот подход сфокусирован на поведении программы при различных входных данных и результатах, и, в отличие от тестирования “белого ящика”, тестировщик не знает, как именно реализованы внутренние алгоритмы системы. В книге Ли Копланда “A Practitioner’s Guide to Software Test Design” рассматриваются различные методы тестирования “черного ящика”, которые позволяют эффективно проверять функциональность программы на соответствие требованиям.

Основы тестирования “черного ящика”
Тестирование “черного ящика” ориентировано на проверку того, как система обрабатывает входные данные и какие результаты она выдает. Тестировщики создают тесты на основе требований и спецификаций, которые определяют допустимые и недопустимые сценарии использования программы.

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

Основные методы тестирования “черного ящика”
Тестирование “черного ящика” включает несколько методик, каждая из которых предназначена для эффективной проверки системы с разных сторон. Вот основные из них:

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

Пример: Если у вас есть поле ввода для возраста, в котором программа обрабатывает значения в пределах от 18 до 60 лет, то можно создать классы эквивалентности:
• Один класс для допустимых значений (например, 25, 45),
• Другой для недопустимых (например, 16 или 65).
Преимущества: Позволяет значительно уменьшить количество тестов, сохраняя при этом высокий уровень покрытия тестов.

Читать статью целиком.
———
Цикл статей на основе перевода книги Ли Копланда “A Practitioner's Guide to Software Test Design”.
———
#qa #pro_qa #qa_чтиво #qa_знания

А есть у меня среди подписчиков те, кто занимается AI? Встал тут вопрос - а как тестировать AI тулзы/инструменты. Не как использовать AI для тестирования, а именно тестирование AI штук 🤔

#ai #qa #pro_qa #ai_testing

Самокритика в AI — это механизмы или алгоритмы, которые позволяют модели анализировать и оценивать собственные ответы или действия. Цель самокритики — улучшить работу модели, выявляя ошибки, предвзятости или недостатки в ее ответах. Этот подход можно считать частью более широкой области, известной как “самоанализ” или “самомониторинг” в AI.

Как это работает

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

Плюсы

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

Минусы

• Высокая вычислительная нагрузка: Использование самокритики требует дополнительных ресурсов.
• Сложность: Добавление самокритических механизмов усложняет модель и может породить новые проблемы.
• Риск чрезмерной корректировки: Чрезмерная самокритика может привести к тому, что модель станет менее решительной и начнет избегать четких ответов.

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

#qa #pro_qa #ai #ai_самокритика

Внезапно юбилей 🎉

Информация про сам курс и 10% скидка на любой курс в OTUS в этом посте.

#qa #pro_qa #otus

Тема 5. Эквивалентное разделение классов

Эквивалентное разделение классов — это техника тестирования, которая помогает уменьшить количество тестов, сохраняя высокий уровень покрытия и качества. Метод применяется для сокращения числа проверок, выделяя ключевые наборы данных, которые можно тестировать как эквивалентные. Эта методика — одна из базовых и наиболее часто используемых в тестировании “черного ящика”, о которой подробно рассказывает Ли Копланд в своей книге “A Practitioner’s Guide to Software Test Design”. В этой статье рассмотрим методику эквивалентного разделения классов и её практическое применение для повышения эффективности тестирования.

Что такое эквивалентное разделение классов?
Эквивалентное разделение классов (ЕРК) — это метод, при котором входные данные программы разделяются на классы (группы), обрабатываемые системой одинаково. Для каждого класса выбирается одно или несколько значений, которые тестируются на корректность. Предполагается, что если одно значение из класса успешно проходит тест, то и остальные значения этого класса будут работать корректно, и наоборот.

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

Читать статью целиком.
———
Цикл статей на основе перевода книги Ли Копланда “A Practitioner's Guide to Software Test Design”.
———
#qa #pro_qa #qa_чтиво #qa_знания

Тема 6. Тестирование граничных значений. Что такое граничные значения и как их тестировать.

Тестирование граничных значений — это ключевая методика в тестировании программного обеспечения, которая фокусируется на проверке крайних границ значений входных данных. Поскольку ошибки часто возникают именно на границах допустимых диапазонов, тестирование граничных значений позволяет обнаруживать дефекты, связанные с неверной обработкой предельных значений. Эта методика детально описана в книге Ли Копланда “A Practitioner’s Guide to Software Test Design”, где автор объясняет, как эффективно использовать её для повышения качества тестирования. В этой статье мы рассмотрим, что такое граничные значения, почему они важны и как их тестировать.

Что такое граничные значения?
Граничные значения представляют собой крайние точки диапазона допустимых входных данных, с которыми работает программа. Для любого набора данных существуют минимальные и максимальные пределы, и система должна правильно обрабатывать эти значения, не выходя за границы допустимых диапазонов. Именно на этих “границах” часто проявляются дефекты, такие как ошибки переполнения, недопустимые значения и неверные логические проверки.
Пример: Если программа работает с возрастом пользователей и принимает значения от 18 до 60 лет, то граничными значениями являются 18 и 60, а также значения на границе допустимого диапазона, например, 17 и 61.

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

Основные причины тестирования граничных значений:
• Высокая вероятность дефектов: На границах диапазонов вероятность ошибки выше, чем при средних значениях ввода.
• Экономия времени и ресурсов: Тестирование граничных значений позволяет сосредоточиться на наиболее уязвимых точках системы, сокращая количество тестов и сохраняя их эффективность.
• Анализ крайних сценариев: Границы представляют собой крайние случаи, и проверка этих сценариев помогает тестировщику убедиться, что система устойчива к экстремальным значениям.

Читать статью целиком.
———
Цикл статей на основе перевода книги Ли Копланда “A Practitioner's Guide to Software Test Design”.
———
#qa #pro_qa #qa_чтиво #qa_знания

Уже середина ноября и я только-только разгреб основную кучу дел и снова готов взять одного человека по программе бесплатных консультаций #qa_mentoring_free 😎

Для тех кто недавно на канале:
Немного обо мне: https://t.me/pro_qa/6
С чем могу помочь в качестве ментора и наставника: https://t.me/pro_qa/8
Отзывы в @qa_advisor_feedback.

Условия участия:
1. быть подписанным на @pro_qa
2. поставить эмодзи ❤️ к этому сообщению
3. быть джуном или мидлом
4. скинуть информацию о своем бэкграунде или свое резюме мне в личку @qa_advisor
5. сформулировать запрос или дать вводные, если запроса нет
6. написать отзыв в @qa_mentors после консультации

Сбор заявок провожу до 15 ноября 23:59 CEST, а в выходные их разбираю и выбираю финального кандидата.

#qa #pro_qa #ментор

Интересное наблюдение про программу #qa_mentoring_free.

Вроде бы и сообщество в @qa_mentors большое (я там объяву тоже закидываю, как и в линкедин) и читателей здесь почти 5 сотен, но в самой программе с лета участвует каждый раз менее 10 человек.

Возможно многим просто не сильно нужно, хотят только за деньги (что тоже имеет смысл) или думают, что участников дофига и шансы не велики 🤪

Хотя были те кто не один раз участвовал и таки получил желаемое. А были и те, кто после бесплатной брал пакет сопровождения.

Решил вот поделиться мыслями 🤔

#qa #pro_qa

Тема 7. Тестирование таблиц решений: Когда и как использовать таблицы решений

Тестирование таблиц решений — это мощная методика тестирования программного обеспечения, которая используется для проверки сложных систем с множеством условий и логических ветвлений. Эта техника помогает систематизировать и организовать тесты для комплексных бизнес-правил и логики принятия решений. В книге Ли Копланда “A Practitioner’s Guide to Software Test Design” подробно рассматривается, как создавать таблицы решений и эффективно их применять для тестирования. В этой статье мы разберем, что такое таблицы решений, когда их стоит использовать и как они помогают улучшить качество тестирования.

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

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

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

Читать статью целиком.
———
Цикл статей на основе перевода книги Ли Копланда “A Practitioner's Guide to Software Test Design”.
———
#qa #pro_qa #qa_чтиво #qa_знания

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

Решил вынести саммари в отдельный пост.

1. Процесс найма
Мой любимый формат в качестве консультанта, когда я выстраиваю процесс найма: прескрининг экспертов (производительность от 50 до 70 cv в час, в зависимости от языка и уровня вакансии) -> скрининг с рекрутеров (если такой есть) -> тех.интервью с нанимающим менеджером или экспертом -> culture fit или финальное интервью -> оффер

Важные замечания:
Получение резюме кандидата - отписаться кандидату о том, что мы получили его CV.
Отказ на каждом этапе - отписаться кандидату, в заивимости от этапа, текст отличается.
Фидбэк давать всегда, если его попросят.
Все уведомления и отписки автоматизируются HR системами, а если все делается руками в каком-нибудь trello или notion - то не забывать это делать )

2. Резюме
Не смотря на большое кол-во менторов, статей, видео на тему как улучшить свое резюме - при отсмотре большого кол-ва CV процентное соотношение хорошо сделанных резюме не более 10%. Каказлос бы - тонна информации "как сделать хорошо и читабельно", но нет. Используют эту инфу немногие.

3. Тестовые задания
Для меня это всегда и было остается инструментом, который используется для 2х целей:
1) сузить воронку кандидатов - отсеять тех кому лениво, не хочется тратить свое время и тд на выполнение тестового, в общем, вполне себе неплохой фильтр; Но тут может быть нюанс, если куча народу таки написали тестовое - то его надо проверять и тратить свое время - так что тут надо быть осторожным )))
2) для помощи выбора одного из нескольких кандидатов после тех.интервью, чаще всего только для автоматизаторов;

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

4. Большой конкурс, кол-во кандидатов
Особенно если вакансия предполагает удаленку. Со стороны найма - важно настроить и отфильтровать поток каандидатов. Со стороны кандидата сделать такое CV, которое пройдет первычный фильтр (AI, обязательные поля и вопросы при отклике, пре-скрининг и тп). Тут много нюансов, причем от стране к стране они разные.

5. Долгие сроки поиска работы
Здесь все очень зависит от страны, позиции, кол-ва этапов в процессе найма.
Джуны - мало вакансий, дофига кандидатов после курсов или с небольшим опытом работы. Поиск может быть долгим.
Мидлы - много вакансий и кандидатов. Поиск обычно быстрый.
Синьоры - много вакансий, но хороших кандидатов мало. Поиск очень быстрый.
Лиды - мало кандидатов, вакансий немного. Соотв вакансию могут закрыть как за пару недель, так и полгода искать кандидата. Со стороны кандидата аналогично.
Head of / Директор - вакансии редки, кандидатов мало, претендентов на позиции довольно много (из лидов и менеджеров). Из-за этого как повезет, можно за месяц закрыть, а можно и год искать.

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

#qa #pro_qa #найм

Тему про AI и тестирование: как применять одно в другом и как тестировать сами модели копать продолжаю. И вот в меня прилетела интересная статья на хабре.

Как ухватить LLM за хвост: эффективные стратегии тестирования AI-моделей

Тем кто смотрит в эту тему, рекомендую к прочтению. И заодно хотелось бы обсудить (может какой-нибудь открытый стол или эфир замутить?).

#qa #pro_qa #ai #llm #ai_testing #llm_testing

Еще одна статья в копилку полезностей

Как LLM может валидировать данные

#qa #pro_qa #llm #data #data_validation #llm_testing

Тема 8. Попарное тестирование. Алгоритм Allpairs и ортогональные массивы.

Попарное тестирование (Pairwise Testing) — это техника оптимизации тестирования программного обеспечения, которая фокусируется на проверке всех возможных пар комбинаций входных параметров системы. Данная методика значительно снижает количество тестов, необходимых для проверки сложных систем, сохраняя при этом высокий уровень покрытия тестируемых комбинаций. В книге Ли Копланда “A Practitioner’s Guide to Software Test Design” подробно описывается, как использовать попарное тестирование, а также его реализация с помощью алгоритма AllPairs и ортогональных массивов. В этой статье мы разберем принципы попарного тестирования, преимущества метода, а также практические примеры его применения.

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

Основные принципы:
1. Сокращение количества тестов: Вместо проверки всех возможных комбинаций параметров, попарное тестирование проверяет только их пары.
2. Фокус на взаимодействии: Тестирование направлено на выявление дефектов, вызванных взаимодействием двух параметров, что покрывает большинство сценариев.
3. Эффективность: Методика позволяет минимизировать усилия, не теряя качества тестирования.

Читать статью целиком.
———
Цикл статей на основе перевода книги Ли Копланда “A Practitioner's Guide to Software Test Design”.
———
#qa #pro_qa #qa_чтиво #qa_знания

С Рождеством всех тех кто отмечает этот праздник!

Тема 9. Тестирование состояний и переходов. Использование диаграмм состояний

Тестирование состояний и переходов — это методика тест-дизайна, которая фокусируется на проверке системы, представленной в виде конечного автомата с различными состояниями и переходами между ними. Эта техника помогает убедиться в корректной работе сложных систем, которые изменяют свое поведение в зависимости от текущего состояния и выполняемых действий. В книге Ли Копланда "A Practitioner's Guide to Software Test Design" тестирование состояний и переходов описывается как мощный инструмент для тестирования таких систем, как банкоматы, системы бронирования, и приложения с динамическими интерфейсами. В этой статье мы рассмотрим основы тестирования состояний и переходов, использование диаграмм состояний и их применение в реальных проектах.

Что такое тестирование состояний и переходов?
Тестирование состояний и переходов основывается на представлении системы как конечного автомата, который:

1. Находится в одном из конечного числа состояний.
2. Изменяет своё состояние в ответ на событие.
3. Следует определённым правилам перехода между состояниями.

Ключевые элементы модели состояний:
1. Состояния: Определяют текущую конфигурацию системы.Пример: "Активный пользователь", "Ожидание авторизации", "Ошибка входа".
2. События: Это входные данные или действия, которые вызывают изменение состояния.Пример: Нажатие кнопки "Вход", введение неправильного пароля.
3. Переходы: Связи между состояниями, которые активируются определёнными событиями.Пример: При вводе неправильного пароля система переходит из состояния "Ожидание авторизации" в "Ошибка входа".
4. Действия: Операции, выполняемые системой при переходе между состояниями.Пример: Показ сообщения "Неправильный пароль".

Читать статью целиком.
———
Цикл статей на основе перевода книги Ли Копланда “A Practitioner's Guide to Software Test Design”.
———
#qa #pro_qa #qa_чтиво #qa_знания

Всех поздравляю с наступающим 2025 годом!

Из пожеланий: ценить то, что имеешь и уметь радоваться этому 😎