QA

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

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

Да!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

То, что переполнен - факт! Насчет дальнейшего не согласен, некоторые факты говорят обратное:

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

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

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

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

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

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

Часто по окончанию курсов по тестированию, выясняется, что о многих инструментах, необходимых для тестов выпускники просто не знают или не слышали.

Давайте перечислим несколько программ, которыми мы пользовались с самого начала:

1️⃣Jira - популярная система управления проектами, их разработкой и отслеживания ошибок. Можно создавать задачи, двигать по статусам, декомпозировать задачи, просчитывать загруженность команды, проставлять приоритеты задач и многое другое.

2️⃣TestIT - система управления и хранения тестовой документации. Тест-планы, тест-кейсы, чек-листы - все это можно создавать создавать, хранить можно там.

3️⃣Postman (куда без него) - один из самых популярных инструментов тестирования API. Он облегчает процесс создания, проверки и описания API. При помощи данного инструмента тестировщик может выполнять различные виды HTTP-запросов, такие как GET, POST, PUT, PATCH, а также автоматически генерировать код для языков программирования, таких как JavaScript и Python.

4️⃣Kibana - это удобный инструмент, позволяющий просмотреть логи системы (чаще всего сервера), например по той или иной ошибке, понять по какой причине она могла произойти, проанализировать их и передать разработчику.

5️⃣Jmeter - инструмент для нагрузочного тестирования, довольно простой и понятный. Как симулировать большой приход пользователей на сайт? как нагрузить один запрос? Как выгрузить отчеты по нагрузке? - ответы в Jmeter