Добрый день, коллеги!) Часто на собеседованиях спрашивают про принципы тестирования, но в работе теория забывается!) И все же об этом важно помнить и информация усваивается, когда есть простой пример из жизни, а не сухая теория. Сегодня разберем принципы тестирования на примере электрического чайника 🫖

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

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

3️⃣ Раннее тестирование экономит время и деньги. Допустим, на заводе неправильно рассчитали длину шнура. Если это заметили на этапе прототипа, то просто меняют чертёж. Если заметили после выпуска 100 000 чайников, то это влечет за собой возвраты, убытки, упадок репутации. Проще говоря: чем раньше нашли проблему, тем дешевле её исправить.

4️⃣ Скопление дефектов. Большинство проблем у чайника в кнопке включения, крышке, датчике автоотключения. Основные дефекты концентрируются в сложных и часто используемых частях. Их тестируют особенно тщательно.

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

6️⃣ Тестирование зависит от контекста. Допустим, мы покупаем чайник для дома: важна работоспособность, дизайн и цена. И также покупаем чайник в офис на кухню. Меняются условия: чайник включают чаще (по 10-20 раз в день), пользуются разные люди, могут быть невнимательны, забыть налить воду или хлопать крышкой, или дергать за шнур. Значит, и тестировать эти два чайника нужно по-разному.

7️⃣ Отсутствие дефектов не значит, что продукт хороший. Условно, чайник не ломается, безопасен, кипятит воду, но тяжелый, неудобно держать, плохо видно уровень воды. Формально дефектов нет, но пользоваться неудобно.

Если было полезно, ставь реакцию👇

Сопроводительное письмо к отклику на вакансию - надо или нет?🤷‍♂️

Давайте разбираться, коллеги) Скажу сразу, что это мое субъективное мнение, но я исхожу из своего опыта в IT. Я работал в разных компаниях, проходил множество собеседований, менторил ребят, помогал им составить резюме и трудоустроиться, поэтому у меня сложилось мнение на этот счет.

Начну с того, что многие HR читают сопроводительное письмо, а это уже весомая причина писать его❗️

Еще несколько причин, почему я советую писать СП:
🔵 Это первое впечатление о вас и опрометчиво им пренебрегать;
🔵 В нём можно сжато подчеркнуть ключевые навыки, релевантный опыт и выделить себя среди других кандидатов;
🔵 Хорошее СП помогает заинтересовать HR и повышает шансы, что резюме прочитают внимательнее;
🔵 И, в конце-концов, если человек не постарался над СП, то HR может сделать вывод, что соискатель скорее всего или не достаточно заинтересован в этой работе, или просто ленив.

Если вы сейчас в поиске работы и у вас нет письма, то советую засесть вечерком и написать его) А вот несколько рекомендаций по составлению от меня:
1️⃣ Упомяни инструменты и типы тестирования, с которыми работаешь.
2️⃣ Кратко опиши, как твоя работа влияла на качество продукта. Упомяни, если улучшал тестовую документацию, внедрял чек-листы, автотесты или оптимизировал процессы.
3️⃣ По возможности используй цифры, менеджеры это любят и очень обращают на это внимание))
4️⃣ Адаптируйся под вакансию: небольшая персонализация под компанию или продукт может сильно повысить отклик. Это говорит о том, что ты реально ознакомился с вакансией и продуктом, а не просто «откликнулся», а, значит, уже подчеркнул свое мышление QA - внимательность к деталям.
5️⃣ Объясни, почему хочешь трудоустроиться именно на эту позицию, именно в эту компанию.
6️⃣ Пиши кратко и по делу: 5–7 предложений достаточно, избегай общих фраз и «воды».

Если было полезно, ставь реакцию👇

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

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

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

Условно, если первый кандидат имеет большой опыт и сильные навыки, умеет управлять командой, системно мыслит, а второй - отлично знает продукт, но слабее в процессах, скорее всего лидом выберут первого, а второй пригодится как «правая рука лида» в качестве эксперта по продукту. К тому же знания по проекту можно подтянуть за 1-2 месяца.

❗️НО… Есть исключения, когда выбор будет в пользу более экспертного тестировщика:
1️⃣ Если проект критически сложный доменный (например, финтех, медицина). В таком случае доменная экспертиза очень важна.
2️⃣ Если команда уже зрелая. И нужен не стратег, а тот, кто сохранит качество продукта.
3️⃣ Если проект в кризисе. В таком случае важно, чтобы на позиции лида был человек, который хорошо знаком с продуктом и знает «где болит».

Подводя итоги, хочу сказать, что не всегда важен просто «опыт» или «знание проекта», все зависит от контекста и конкретных обстоятельств. Но если вы планируете вырасти до позиции лида, то должны честно оценить свои навыки:
1️⃣ Вы умеете вести за собой людей?
2️⃣ Вы можете давать фидбек?
3️⃣ Вы способны принимать непопулярные решения?
4️⃣ Вы видите критичные зоны, умеете приоритизировать и нести за это ответственность?
5️⃣ Вы умеете переводить «технический» на «бизнес-язык»? Если QA говорит: «Это баг, надо исправить» - это уровень тестировщика. Если QA говорит: «Этот дефект может привести к потере пользователей на этапе оплаты, поэтому рекомендую не выпускать релиз без фикса» - это уровень лида. QA Lead обязан понимать, как его решения влияют на деньги, пользователей и репутацию.

Ответьте себе честно на эти вопросы, объективно оцените свои сильные и слабые стороны и прокачивайте свои навыки!

Если было полезно, ставь реакцию 👇