Как стать QA? На что стоит обратить внимание выбирая этот путь

Привет всем! Стал замечать, что с завидной периодичностью на DTF проскакивают вопросы «как стать QA?» не так часто как про телевизоры, но всё же. Поэтому я хотел бы высказать пару мыслей: кто же такой QA и можно ли так легко влететь в эту профессию. Для этого нужно понять, что должен знать человек и какими качествами обладать, чтобы его карьера в QA не закончилась раньше испытательного срока.

Во-первых давайте разделим все умения и качества человека на софт скилы и хард скилы. Софт скилы, как бы это не звучало, не имеют отношения к софту. Это прежде всего качества человека (например ответственность, инициативность), а также навыки не связанные со знаниями тех или иных программ или языков программирования. Хард скилы — вот это как раз про все те приложения и тулзы, которыми человек владеет, сюда же относятся понимания структуры и взаимодействия каких-либо компонентов (сетевые протоколы, клиент-серверные архитектуры и прочее). В общем хард скилы это то, что можно оценить легко и конкретно (умеешь простой SQL запрос написать — покажи). Оценить ответственность простым вопросом уже не получится (хотя для этого есть непростые вопросы:) . В резюме же каждый второй ответственный, инициативный и коммуникабельный.

И вот что получается: если хард скилы легко подтянуть с помощью каких-либо курсов, тренингов и прочего, то софт скилы меняются не моментально. Если человек не коммуникабельный он с трудом будет общаться с коллегами и максимально избегать диалога, если у человека слабо развита ответственность она не поменяется после курсов QA.

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

Пройдёмся по некоторым софт скилам, которые на мой взгляд очень важны для QA:

Умение анализировать большие объёмы информации. Вся работа QA заключается в анализе информации. Документации, спецификации, разговоры с другими сотрудниками, объект тестирования и его состояние, тест-кейсы, баги. Это всё то, чем оперирует QA каждый день. Просто сесть «и начать всеми силами ломать приложение» не получится. Это не подход QA. А вот прочитать документацию, проанализировать, составить чеклист или набор тест-кейсов, выполнить их, проанализировать результаты, уточнить незадокументированые моменты, проанализировать сказанное, скорректировать документацию, завести баг — вот это уже ближе к реальности. И вообще QA не ломают приложение. Сломать приложение легко — удали любой файл или переименуй директорию. Поздравляю, вы сломали приложение! И что с того? Важно оперировать юзкейсами и контролировать поведение системы прежде всего при стандартном поведении пользователя.

Умение находить информацию.В целом перекликается с предыдущим пунктом. Если первой мыслью человека при появлении проблемы будет «пойду на DTF, напишу вопрос» — у меня для вас плохие новости. Это не лучшее поведение для QA. Нужно уметь искать и находить информацию самостоятельно. Естественно всё зависит от конкретного проекта и качества документации, но поверьте, нет ничего хуже человека который начинает задавать вопросы раньше, чем сам попытается найти ответ. Такой человек будет максимально зависим от всех окружающих, будет постоянно задавать вопросы и естественно ни о каком анализе информации речи не идёт. Такой человек хочет получить готовы ответ не напрягая мозг. Что характерно зачастую ответ не запоминает, чтобы через два дня спросить то же самое, а это безусльвно минус в карму. Учитесь находить информацию.

Умение переключаться между задачами.Если вы любите чтобы вас не отвлекали, посидеть-поработать или как говорят «поколупаться» в одной задаче — такое в работе QA бывает не часто. Чаще бывает такое: сидишь работаешь, тестируешь, что-то не то с приложением, полез искать на конфлюенс так ли должно быть, в это время коллега задал какой-нибудь вопрос, ты вроде знаешь где ответ, полез в соседней вкладке в документцию, в это время тебе пишет разработчик по поводу заведенного тобой бага с просьбой уточнить окружение или шаги, ты открываешь в соседней вкладке баг, а outlook подсказывает, что через 15 минут у тебя планинг или демо, а ты забыл подготовиться… занавес. Да, это утрировано, и новичков касается в меньшей степени, но нужно быть готовым что такие ситуации случаются и вас будут отвлекать у вас очень часто будет не одна задача. И я прекрасно понимаю, что есть люди которых это люто бесит и им не очень комфортно в такой обстановке работать.

Умение расставлять приоритеты и абстрагиваться.Типичная ситуация, когда новичок может завести баг, что кнопка Login смещена на один пиксель и тень имеет не такой цвет как в документации, но пропустить, что приложение крашится при повторном логине. Нужно расставлять приоритеты, понимать их самому или советоваться с более опытными коллегами. Ты молодец (нет) если весь день потратишь на попытку воспроизвести краш и в итоге напишешь баг в 15 шагов который в реальной жизни недостижим адекватным юзерфлоу… По поводу абстрагирования: может так случаться что билд на тест приходит без текстур с кучей заглушек, кривым текстом, но функционально рабочий. Тут обязательно нужно уметь абстрагироваться и проверять то что нужно, не смотря на творящийся вокруг хаос.

Грамотная речь, умение формулировать мысли устно и письменно. QA это сотрудник работа которого на достаточно большой процен состоит из общения с другими членами команды: разработчик, другие QA, ГД-шник, лид, менеджер. Если человек не может связать два слова с ним будет тяжело. Еще тяжелее читать его поток текста в описании багов или тест-кейсов. Ну а к документации его вообще нельзя подпускать. К формулированию мыслей также стоит отнести умение задавать правильные вопросы. Приведу абстрактный пример. Вы дали задачу человеку открыть пять дверей. Через пол часа он задаёт вопрос «а где взять топор». Мы вроде помним что дали задачу двери открывать… переспрашиваем. Оказалось одна из дверей закрыта и человек решил расхерачить ее топором. «Почему не взять ключ?» спрашиваете вы. «Я как-то не подумал» отвечает человек. А если бы вы не уточнили зачем ему топор? Ему нужно дверь открыть, а он сделал неправильный вывод про топор и уже этот вопрос задал. Так делать не стоит.

Можно перечислять и дальше, всякую там внимательность и ответственность, но это совсем уже базовые понятия. Так что перейдём к следующему пункту.

Прежде всего всё зависит от конкретного проекта и его направленности: web, standalone, mobile могут сильно отличаются инструментарием и необходимой глубиной знаний. Но стоит сразу сказать: не пишите в резюме того, чего не знаете. Если вы у друга видели установленный Windows Server и запускали в нем Total Commander — не пишите что у вас есть опыть работы с Windows Server. Если пишете «знание SQL», пожалуйста, не говорите потом «я сейчас не помню, но если загуглю — сразу напишу», да обучаемость это одно из важных свойств, но это касается новых знаний, а не тех, о которых говорится у вас в резюме.

В любом случае выбирая направленность своей первой работы QA старайтесь определиться со скилами и знаниями, которые вам наверняка понадобятся. Пролистайте вакансии, почитайте что от вас хотят, но кроме этого освойте очевидные вещи. Приходя на собеседование moblie QA человек может сказать «я пользуюсь Android телефоном» и даже не сможет ответить на вопрос как делается скриншот на iPhone X, да, это гуглится моментально, но это нужно делать _до_ собеседования. Это показатель того, что человек не просто случайно с улицы пришел чаю попить, погреться, а заинтересован в получении работы.

Для Web и standalone — соответственно другие знания, которые также необходимо заранее освоить хотя-бы на базовом уровне. Это не какие-то специфические «навыки и знания QA», это просто понимание того как всё работает. Знаю существуют люди которые на курсах web QA вдруг начинают тестировать браузер (!) потому что на базовом уровне не понимают где заканчивается сайт и начинается браузер. Сюда же можно отнести хотя-бы базовые знания какого-нибудь багтрекера, например jira.

Теории тестирования касатья не будем. Это как ПДД: просто нужно выучить и понимать. Виды, типы тестирования, покрытия и хотя-бы примерное представление как заведенный баг обрабатывается на проекте. Многие люди даже после курсов уверены, что после исправления бага программист просто его закрывает.

Старайтесь, развивайтесь и добивайтесь успеха!
QA замечательная профессия сама по себе, а не только для старта в IT.