Последние пару недель я полностью погружен в процесс собеседований. Хожу на интервью в международные компании на позиции уровня Head of QA или QA Director. И, скажу честно, это занимательный опыт.

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

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

Я всегда спрашиваю обратную связь на собеседованиях (с обеих сторон), особенно когда речь идет о позициях уровня QA Lead или выше. Это просто необходимость. Умение дать четкий, развернутый фидбэк — показатель зрелости и профессионализма.

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

Иногда случается так, что именно рекрутеры ломают процесс, который сами же и построили. А потом не очень появляются отзывы на Reddit, LinkedIn или QA - Bad Companies о том, как плохо организован процесс найма в тех или иных компаниях. Я не обобщаю — не все рекрутеры такие, но иногда от отдельных случаев просто хочется взорваться, особенно когда речь идет о людях уровня HRD или HRBP. Вместо того чтобы дать нормальный честный фидбэк, они выдают откровенную чушь. Это выглядит как детский сад и непрофессионализм, особенно когда речь идет о найме на руководящие позиции, а кандидат сам имеет довольно обширный опыт найма и может определить такие штуки на раз-два.

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

А какие у вас были кейсы с подачей на вакансии, во время интервью или при общении с рекрутерами?

#qa #pro_qa #рекрутинг #найм #софт_скиллы #обратная_связь

Прошел отбор и стал ментором в программе Women in Tech (WiT) 6.0 по QA направлению. Если кто не в курсе, то это Бесплатная программа наставничества для женщин в IT.

Программа 6-го потока продлится с 1.10.2024 по 1.02.2025. Заходите на огонек! 😎

@womenintechrus
https://women-in-tech.ru

#qa #pro_qa #ментор #wit #womanintech

Прислали мне тут на днях приглашение в сервис для построения генеологического древа famiry.ru, зашел по почте и мне сразу тут подсовывают банер «купи премиум», ну ок - норм поведение. Закрываю окошко, нажав на ✖️ в правом верхнем углу. На что мне снова показывают список платных тарифов. А что, прикольная бага/фича - закрыть банер нельзя даже по нажатию на закрыть. Такое вот занимательное навязывание.

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

А как вы относитесь к подобным вещам?

#qa #pro_qa #багивокругнас #famiry #ux #ui

Наступил октябрь, я успел поболеть/выздороветь и снова готов взять одного человека по программе бесплатных консультаций #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 после консультации

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

#qa #pro_qa #ментор

Решил провести небольшой эксперимент.

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

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

Решил взять всем известную книгу “A Practitioner's Guide to Software Test Design”.
И не смотря на то, что к ней есть конспект, решил сам разбить ее на 25 тем и выкладывать их здесь по одной - так для поиска и восприятия информации удобнее будет. А если эксперимент зайдет, то можно будет онлайн-интерактивную книжку сделать и туда примеров из практики накидать. Надо будет только с лицензированием разобраться.

#qa #pro_qa #qa_books #тест_дизайн #эксперимент

Цикл статей на основе перевода книги Ли Копланда “A Practitioner's Guide to Software Test Design”

Темы
1. Основы тестирования ПО. Определения, цели и ключевые аспекты.
2. Процесс тестирования ПО. Шаги тестирования, создание тест-кейсов.
3. Типичные проблемы в тестировании. Основные вызовы, с которыми сталкиваются тестировщики.
4. Методы тестирования “черного ящика”. Принципы и примеры.
5. Эквивалентное разделение классов. Методика и практическое применение.
6. Тестирование граничных значений. Что такое граничные значения и как их тестировать.
7. Тестирование таблиц решений. Когда и как использовать таблицы решений.
8. Попарное тестирование. Алгоритм Allpairs и ортогональные массивы.
9. Тестирование состояний и переходов. Использование диаграмм состояний.
10. Тестирование вариантов использования (Use Case Testing). Как тестировать сценарии использования.
11. Методы тестирования “белого ящика”. Применение и недостатки.
12. Тестирование потока управления: Графы потока управления и уровни покрытия.
13. Тестирование потока данных. Статическое и динамическое тестирование.
14. Модульное тестирование. Особенности и ключевые подходы.
15. Интеграционное тестирование. Проверка взаимодействий между модулями.
16. Системное тестирование. Функциональное, безопасность, производительность.
17. Приемочное тестирование. Роль и критерии для успешного завершения.
18. Альтернативные уровни тестирования для веб-систем. Подходы для быстрых циклов разработки.
19. Тестирование GUI. Особенности и сложности.
20. Роль автоматизации в тестировании. Как автоматизировать тесты для повышения эффективности.
21. Документирование результатов тестирования. Как составлять отчеты и вести записи.
22. Методы улучшения тестирования. Как минимизировать ресурсы и максимизировать результат.
23. Инструменты для тестировщиков. Обзор инструментов, которые могут улучшить процесс тестирования.
24. Практические советы для начинающих тестировщиков. Ошибки, которых стоит избегать.
25. Тренды в тестировании ПО. Куда движется индустрия тестирования.
———
#qa #pro_qa #qa_books #qa_чтиво #qa_знания #тест_дизайн

Тема 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 #ментор