QA + Обучение

Итак, ты наконец-то успешно прошел собес, подписал оффер и завтра твой первый рабочий день на позиции Инженер по тестированию.

Ждать, когда тебе позвонит коллега и скажет что делать?

Да!

Но только на 10% ДА.

Тебе должны дать доступы к корпоративным софтам. Обычно это занимает от 2-7 дней и далеко не в каждой компании ты можешь на это повлиять.

За это время ты должен познакомиться с командой. Лично напиши тимлиду и договорились о звонке. Тема звонка: «Расскажи кратко о проекте, что делаем, на какой стадии, какие есть нюансы. Расспроси немного о команде». Собери у него пул источников, которые ты можешь начать изучать уже сейчас, касаемо проекта.

Спроси контакт тех админа, к кому обращаться в случае технических вопросов.

Найди тимлида по QA и запроси документацию по особенностям флоу тестирования в данной компании.

Спроси контакт того, к кому можно обращаться по вопросам тестирования.

Доступы получены.

Открывай ТМС систему, где тестеры пишут тест-кейсы. Почитай, пройди несколько ТК с целью выявления нюансов работы.

Проведи исследовательское тестирование своего проекта (если до тебя уже что-то было написано). Найди баги, предложи фича реквесты, попробуй хотя бы.

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

Не понимание концепции инструктивной речи

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

Неумение демонстрировать доказательства некорректной работы ПО

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

Путаница в показаниях при непонимании устройства системы

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

• Во-первых, ChatGPT может дать вам базовые знания по теории тестирования. Это безусловно поможет новичкам быстрее влиться в профессию, а Джунам и мидлам закрыть пробелы.

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

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

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

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

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

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

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

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

Весь курс разбит на спринты по 1 неделе и мини-группы

Курс рассчитан на 4 месяца, поэтому всего представлено 16 спринтов (16 недель), в рамках которых обучаются ребята. Ребята занимаются в группах, и пока что у нас только одна группа, но в будущем группа будет содержать максимум 10 человек с персональным ментором. Пока что у всех ментором выступаю я :)