Подборка наших постов, которые набрали больше всего охватов и реакций 👍

Вы точно захотите их перечитать! Либо вообще пропустили)

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

📎Гайд «Резюме». Как преподнести свои навыки, чтобы работодатель выбрал именно тебя.

📎Как протестировать лягушку?

📎Подборка полезных чит-листов

📎Разница между аутентификацией и авторизацией

📎Как появились тестировщики и баги?

📎Подборка шпаргалок для айтишников

📎ТОП-14 книг для тестировщика на русском языке

📎Если бы я вернулся в начало своей карьеры и мог снова выбрать язык программирования, какой бы я выбрал?

📎Вход в IT через тестирование: почему не у всех получается

📎9 признаков, что профессия QA подходит вам по психотипу

Приятного чтения, ваш QApedia !

Если не ушёл в автоматизацию — ты застрял 😢

У тестировщиков есть свои темы-триггеры, которые мы обсуждаем с огоньком, болью, сарказмом и долей тревожности. И эта одна из них)

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

Но для начала напомню и расскажу новеньким, что мой стаж работы QA Auto 10 лет, практически с самого начала карьеры я выбрал путь автотестирования. Работал с разными языками программирования: Java, Go, JavaScript, последний 5 лет пишу на Python.

Аргументы «ЗА»
1️⃣Во многих компаниях автотесты воспринимаются как долгосрочная инвестиция: пишется один раз, используется регулярно и ускоряет релизы. А manual - это человеко-часы и зависимость от конкретного человека. И когда встает вопрос о росте продукта, то поднимается вопрос и о расширении QA-команды. И вот тут рано или поздно появится «потолок».
2️⃣В нынешних реалиях компании хотят все больше автоматизировать, так проще оцифровать результат. Поэтому все больше я вижу вакансии, где требуются fullstack тестировщики, либо ручные, но хотя бы с минимальными навыками автоматизации или с желанием развиваться в эту сторону.
3️⃣Исходя из пункта выше умение автоматизировать снижает риск быть «вытесненным».

Поэтому, в целом, тезис кажется логичным и «рациональным», но точно не является окончательным приговором. Потому что:
1️⃣Автоматизация не является ростом сама по себе. Когда человек не понимает, что и зачем автоматизирует, просто клепает тесты ради галочки - это не рост.
2️⃣Manual обычно знает продукт намного лучше, чем автотестировщик. Я часто вижу, как в компаниях повышают до позиции лида не тех, у кого лучше навыки (в том числе и навык автотестирования), а тех, кто лучше знаком с продуктом!
3️⃣Хороший manual, который плотно работает с продуктом, лучше определит риски и приоритеты. Такие специалисты могут влиять на решения и находят баги, которые авто никогда не поймет)
4️⃣Я уже ранее писал пост «Автоматизировать нельзя вручную тестировать», где объяснял, что автоматизация нужна не всем. Есть проекты, где авто не окупается и даже тормозит.

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

Гораздо важнее не «ушел ли ты в автоматизацию», а «растешь ли ты как QA или повторяешь одно и то же последние несколько нет?» Застой - это отсутствие развития, а не отсутствие Java/Python.

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

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

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 обязан понимать, как его решения влияют на деньги, пользователей и репутацию.

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

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