Какие языки программирования и софт-скилы нужны QA-инженеру

IT-профессии продолжают волновать умы и привлекают в свои ряды новых сотрудников. Одна из таких профессий — Quality Assurance engineer или QA-инженер. Это специалист, который тестирует ПО на этапе разработки и еще до релиза минимизирует риск ошибок и проблем продуктов и решений. Но есть заблуждение, что для работы в должности QA-инженера не нужны технические знания, ведь он просто “жмет на кнопки и записывает ошибки”. Чтобы узнать больше, поговорила с Александром, QA-инженером Smartex.

Статья будет полезна junior/middle QA-инженерам и всем, кто думает о входе в IT.

Ключевые навыки

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

Грамотная речь

Человек может четко, без воды и ответвлений, донести свою мысль с первой попытки в письменной форме. Стиль, изложение, оформление должны быть максимально понятными для окружающих. Различные виды “дислексии” несовместимы с профессией инженера по качеству.

Пусть это и “soft skill”, но этот навык можно и нужно развивать

Работа с браузером

(все вкладки в панели разработчика, с акцентом на вкладку Network). Часто встречаются сотрудники (включая разработчиков), которые при уже функционирующем UI+API не могли понять по Swaggerу или иной доке, как составить корректный запрос к серверу. Вкладка network отличное подспорье к тому, чтобы избежать этой проблемы. Также есть кейсы, когда console вынужденно выступает клиентом для отправки запроса на сервер.

Работа с API (REST)

клиент при этом не важен, хоть CURL. Множество вакансий для QA включает в себя тестирование WEB-приложений и/или Мобильных приложений. Этот навык – основа того, что человек будет не просто заводить дефекты на основании документации (QA), но действительно будет следить за качеством продукта (QC). Имея большой опыт в тестировании API и насмотренность в разных реализациях задач, специалист сможет указывать на потенциально некорректные решения со стороны разработчиков, а также с большей вероятностью сможет овладеть техникой предугадывания ошибки (Error Guessing).

SQL

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

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

Быть уверенным пользователем своей ОС

Linux/Windows/MacOS не так важно. Но не должно возникать проблем с настройкой своей ОС под нужды проекта. Файлики .hosts/впны/развернуть виртуалку при необходимости, прописать переменную окружения, выполнить какой-то bash или powershell скрипт – всё это нужно уметь.

Если вы начинающий специалист в поисках работы – обязательно изучайте теорию тестирования. Специалисты по подбору персонала любят проверять познания в этой области. ¯\_(ツ)_/¯

Книги по теме:

1. Как тестируют в Google. Авторы: Джеймс Уиттакер, Джейсон Арбон, Джефф Кароло.
2. Тестирование программного обеспечения. Авторы: Сэм Канер, Джек Фолк, Енг Кек Нгуен.
3. Тестирование DOT COM, или Пособие по жестокому обращению с багами в интернет- стартапах. Автор: Роман Савин.
4. Тестирование программного обеспечения. Базовый курс. Автор: Святослав Куликов Искусство тестирования программ. Авторы: Гленфорд Майерс, Том Баджетт, Кори Сандлер.
5. A Practitioner’s Guide to Software Test Design. Автор – Lee Copeland.
6. Lessons Learned in Software Testing. Авторы: Cem Kaner, James Bach, Bret Pettichord.
7. Agile Testing. Авторы: Lisa Crispin, Janet Gregory.

Добавляйте в комментариях свои любимые книги по тестированию и QA.

Умение хорошо локализовывать и оформлять дефекты

Учитесь, применяйте и все члены команды будут вам благодарны:

• Используйте форматирование.
• Потренируйтесь в навыках составления summary для багов. 
• Оставляйте по возможности данные для воспроизведения в физическом виде, чтобы коллегам не приходилось создавать данные по шагам с нуля. 
• Убедитесь что найденная проблема это ДЕЙСТВИТЕЛЬНО баг, составьте грамотный ожидаемый результат, основанный на документации/комментарии аналитика/чего-то ещё. Не заставляйте разработчика придумывать, как система в итоге должна работать, и быть может в процессе поиска корректного ожидаемого результата вы поймёте, что найденное не является багом. Вдруг это фича?

Что по языкам

Озвучу крамольную мысль – язык программирования инженеру по качеству знать не обязательно.

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

1. Типы данных
2. Условия
3. Циклы
4. Функции
5. Обработка исключений
6. ООП

Изучать это можно вне контекста какого-либо конкретного языка.

Гораздо полезнее ознакомиться с HTML/CSS и знать термины, которые в них применяются. Это позволит не пугаться, когда слышите от коллег про hover/debounce/протокол/background/toast/modal и пр. В интернете огромное множество источников, в которых можно почерпнуть информацию.

Самые сложные навыки в тестировании – это софт скилы. По техническим навыкам много гайдов и обучающих видео в свободном доступе. Есть люди, которые могут подсказать тот или иной момент, есть понимание конечной цели, путь к ней. С софт-скилами всё эфемерно. Сложно выделить алгоритм изучения эмпатии или адекватной реакции на критику. Работа с soft-skill мне напоминает обучение нейронной сети: скармливаешь мозгу кучу информации и надеешься, что на выходе получится что-то стоящее.

Советы

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

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

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

В порядке вещей услышать диалог в IT:

• Сколько нужно времени на тестирование нового метода API. 40 часов. Почему так много? Там же просто get запрос на получение регионов России.. А-а-а! Ну тогда хватит 20 часов

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

В мире IT важно постоянно знакомиться с новыми решениями/подходами/технологиями. Я бы рекомендовал хотя-бы раз в месяц читать дайджест заботливо собранный хорошим человеком. Если какая-то информация заинтересует – выделите время на её более глубокое изучение. Если компания не выделяет времени на изучение новых технологий (такие ещё есть?), вкладывайте свое время – это в ваших интересах.