Каких ответов я жду на собеседовании по тестированию
Долго собирался написать статью… И вот, наконец, выполнил свое намерение. Вопросы, поднимаемые в статье, обсуждались уже не раз и не два, но усердные поиски компиляции ответов на эти вопросы так и не увенчались успехом. Но, как подсказывает мой опыт, такая компиляция очень нужна. Прежде всего она требуется юниорам, ибо в сети по запросу «тестирование» на них (соискателей) обрушивается огромный объем информационного мусора, который плохо структурирован и часто противоречит сам себе.
Вступление
Сначала несколько слов о себе. На данный момент являюсь начальником отдела тестирования и сопровождения компании, занимающейся корпоративными ГИС. До этого работал руководителем группы тестирования в компании, разрабатывающей коммерческие СДО (Системы дистанционного обучения). А еще раньше ведущим инженером по тестированию в компании, которая обеспечивала электронные торги по ФЗ №94. А начинал я свою карьеру более 11 лет назад в роли системного администратора (в трех различных организациях). Стажером-программистом был чуть меньше двух лет (вначале нулевых – VB). Фрилансил инженером-программистом: писал собственный баг-трекер для госкомпании… Исходя из сказанного, можно утверждать, что определенный опыт (тестирования — суммарно более 5 лет) наработан…
Кроме того, по долгу службы мне постоянно приходится подбирать сотрудников в отдел тестирования. И чем больше я этим занимаюсь, тем больше убеждаюсь, что иногда проще взять претендента без опыта, чем человека с опытом тестирования в российской компании (впрочем, не без исключений). Попутно следует отметить, что соискатели без опыта в подавляющей массе используют следующие источники информации о профессии: интернет – ресурсы, книги, мнение знакомых тестировщиков.
- Почему вы решили стать тестировщиком?
- Что такое тестирование? В чем его суть как процесса?
- Что такое ошибка?
- В чем цель тестирования?
- Что вы знаете о жизненном цикле ПО?
- Какие бывают требования?
- Какие виды/типы/классы/методы тестирования вы знаете, и чем они различаются?
- Расскажите о тестовой документации: виды, цели.
- Из каких этапов состоит процесс тестирования?
- Автоматизированное тестирование – отдельный вид тестирования?
- Какой тип/вид класс тестирования имеет смысл автоматизировать?
Может, я слишком требователен к ответам? Нет, я просто жду от соискателя понимания того, чем ему придется заниматься. Вот как проходит собеседование: я начинаю разговаривать с соискателем предпочтительно в форме диалога, задавая ему указанные вопросы. Если получаю ответ, правильный или близкий к правильному, то перехожу к следующему вопросу. Если соискатель «блуждает», приводит заученную формулировку или просто не может ее обосновать, я пытаюсь подвести его к правильному ответу и почему этот ответ правильный. Пытаюсь заставить рассуждать. Последний год вместо собеседований у меня получаются импровизированные лекции. И дело не только в том, что соискатели менее осведомлены или у них мало опыта. Имели место и собеседования на должность ведущего инженера по тестированию с претендентами с 10 летним опытом… результат почти всегда удручает. По-моему, дело в том, что очень много противоречивой информации и «неполезного» опыта, ведь очень многие российские компании строят процесс тестирования по модели С. Канера – когда два – три высококвалифицированных тестировщика полностью генерируют, отбирают и описывают кейсы, а проверки проводят 10 -15,100, 500+ «тестеров» не особо вникая в саму суть процесса.
Этим текстом я попытаюсь немного подвести вчерашних, сегодняшних и завтрашних соискателей на позицию тестировщика к пониманию, а что же все-таки такое «тестирование». Далее я отвечу на некоторые из вопросов собеседования и обосную свое мнение, а также приведу некоторые из наиболее частых ответов соискателей и объясню, почему считаю их неправильными.
Почему вы решили стать тестировщиком?
Наиболее частый ответ: «потому что это просто и интересно (!)». Т. е. кандидат считает, что ему будут платить деньги за щелканье мышкой в вк… Или дадут софт и скажут – сломай его… Или он просто не готовился к этому вопросу и имеет весьма слабое представление о профессии.
Второй по частоте ответ: «потому что я хочу работать в IT и тестирование – самый простой путь» (читай: у IT специалистов высокая зп, а в тестировании не нужно ни знаний, ни навыков, но зп тоже достаточно высокая!).
Бывали и ответы: «меня мама/муж/жена заставила идти на собеседование».
Единственно правильного ответа нет, но вот указанные три и их производные – точно неправильные, т. к. тестирование – это сложно и однообразно, оно требует определенных навыков, по которым нет учебников, и ведет к профессиональной деформации мировоззрения.
Что бы я хотел услышать? Возможно, что-то вроде: «потому что без тестирования невозможно выявить истинное состояние производимого продукта, и насколько он соответствует ожиданиям потребителя».
Что такое тестирование? В чем его суть как процесса?
Наиболее частый ответ (напрямую прописан у С. Канера и Р.Савина) – «поиск ошибок». И во всей литературе по тестированию почему-то никто не указывает, что это упрощение и весьма грубое, и вообще, этот ответ просто неверен!
Тестирование – комплекс мероприятий, направленный на проведение проверок на соответствие производимого продукта требованиям, к нему предъявляемым (прямым и косвенным).
Да, действительно, в ходе проверок выявляются ошибки/инциденты/замечания, но это лишь побочный продукт процесса. Основным является информация о соответствии продукта требованиям, которые к нему предъявляются.
Что такое ошибка?
Ну, здесь, слава Богу, почти все отвечают: «некорректная работа программы…». А вот дальше начинается хаос, когда спрашиваешь: «а как мы узнаем корректная работа или нет?»
Правильный ответ есть почти на всех известных мне ресурсах о тестировании:
Ошибка – несоответствие производимого продукта требованиям, прямым или косвенным.
Чтобы не блуждать в противоречиях/предположениях и т. п., – это единственно правильный ответ.
В чем цель тестирования?
Здесь люди начинают повторять ответ на второй вопрос с разными вариациями. Наиболее внимательные соискатели пытаются пересказать то, что я им подсказывал при ответе на второй вопрос. А ответ крайне простой:
Цель тестирования – предоставление актуальной информации о соответствии производимого продукта требованиям.
Всё. Не больше и не меньше. Ну, конечно же, можно еще сказать, что цель тестирования – предоставление информации о количестве ошибок в продукте. А именно это и неправильно. Почему? Вот просто-таки каждодневный кейс многих тестировщиков/ПМ/аналитиков: звонок заказчика – «как там мой продукт?». «Вы знаете, в нем еще 60 багов!» – ответ тестировщика/ПМ… И что дальше? Это много? Мало? Нормально? Можно, конечно, рассказать подробно о критичности этих багов, их приоритетах, но это не ответ на вопрос заказчика, это выдача сырой необработанной информации ДВП. Теперь тот же кейс. «Как там мой продукт?», – спрашивает заказчик. «35% процентов требований реализовано полностью, еще 5% – с замечаниями и еще 2% – сейчас в реализации», – отвечает ПМ/тестировщик. Как Вам кажется, такой ответ понятнее? И пусть в эти 5% входят, уже упомянутые 60 багов-замечаний… Ответ на вопрос дан настолько точный, насколько это вообще возможно в данном формате. Вот именно это и является целью тестирования. А, соответственно, и сам процесс по своей сути должен сводиться к достижению этой цели.
Что вы знаете о жизненном цикле ПО?
Про ЖЦ ПО сказано много, да и он сильно зависит от организации процесса реализации в целом. Все же есть некоторая «золотая середина», но и здесь умудряются фантазировать дикие вещи, то сводя все к трем пунктам, то разрисовывая схему на три страницы… Всем, кто проводил/проходил собеседование, и так ясно, какие ошибки совершаются и сколько вариантов у правильных ответов. Останавливаться подробнее не буду, скажу только, что есть целый пул кандидатов, которые намертво стопорились на этом вопросе (примерно 7%).
Какие бывают требования?
До этого вопроса за полтора часа доходят только процентов 50 соискателей… Хотя я и не требую ответов «буква в букву», главное, как это называют юристы, сохранить «дух».
Самый частый кейс: соискатели начинают перечислять виды технической документации, которые они знают или о которых слышали… Обязательно выслушаю, покиваю и спрошу: «что-нибудь еще?». Редко кто вспоминает про деление на «функциональные»/«нефункциональные», а кто вспоминает, часто не может объяснить разницу.
Но есть одна категория, про которую забывают. Я в этой статье уже несколько раз упоминал о «…требованиях прямых и косвенных…». На собеседовании я эту фразу произношу раз пять-шесть. Очень малый процент соискателей переспрашивает и тем самым исключает этот вопрос из собеседования. А полный ответ таков: «Требования бывают прямыми (т. е. формализованными в технической документации, спеках, юзер-стори и прочих формальных артефактах) и косвенными (т. е. проистекающими из прямых, либо являющимися негласным стандартом для данной продукции или основывающиеся на опыте и здравом смысле использования данного продукта или продуктах, подобных ему). Все требования также подразделяются на функциональные (описывающие какие функции должен выполнять продукт) и нефункциональные (требования к окружению, поддерживаемости, надежности и прочим характеристикам продукта). Прямые требования всегда приоритетнее косвенных.»
Самый очевидный и «простой» пример: в ТЗ — «кнопка должна быть красного цвета» – прямое требование, из него проистекают косвенные – она не должна быть синей, зеленой, серой или черной и т. д… Естественно, это сильное упрощение, но очень показательное. А главное – такой подход отсекает излишне формальное отношение к тестированию и поднимает планку квалификации тестирования как такового, ибо для грамотного тестирования мало знать только ТЗ и юзер-стори, надо еще изучить прикладную область и специфику потребления производимого продукта. Такое тестирование значительно эффективнее.
- их тяжело обосновать перед руководством,
- на них трудно получить время,
- их практически невозможно обосновать экономически перед заказчиком при составлении сметы на тестирование.
Какие виды/типы/классы/методы тестирования вы знаете, и чем они различаются?
О классификации тестирования имеется очень много информации, вариантов правильных ответов тоже очень много. Я задаю этот вопрос, чтобы увидеть, готовился соискатель хоть в малой степени или вообще не удосужился. Дело в том, что на предыдущие вопросы можно ответить, просто рассуждая и имея общее представление о сфере в целом. Данный вопрос требует элементарного знания терминов. Возможно, я рассмотрю его в других статьях, ибо он достаточно большой и заслуживает отдельной статьи.
Расскажите о тестовой документации: виды, цели.
Тестовая документация – пожалуй, самая большая проблема. По ней идут такие битвы в сообществах, фирмах и т. д.! Про нее столько противоречивой информации. О ней изданы многотомники на разных языках. О ней такая каша в головах… Каких только ответов не приходилось слышать (да-да, включая ТЗ и проектное решение – это тоже тестовая документация)… Поэтому выскажу свои мысли по этому поводу.
Тестовая документация бывает двух видов: внешняя и внутренняя. И та, и другая – инструмент, облегчающий жизнь проектной команде. Не более и не менее.
- Замечание – короткая записка, комментарий о небольшой неточности в реализации продукта.
- Баг-репорт – описание выявленного случая несоответствия производимого продукта требованиям, к нему выдвигаемым – ошибки или ее проявления. Он обязательно должен содержать следующие элементы:
- Идею тестового случая, вызвавшего ошибку.
- Описание исходного состояния системы для выполнения кейса.
- Шаги, необходимые для того, чтобы выявить ошибку или ее проявление.
- Ожидаемый результат, т. е. то, что должно было произойти в соответствии с требованиями.
- Фактический результат, т. е. то, что произошло на самом деле.
- Входные данные, которые использовались во время воспроизведения кейса.
- Прочую информацию, без которой повторить кейс не получится.
- Критичность и/или приоритет.
- Экранный снимок (скрин).
- Версию, сборку, ресурс и другие данные об окружении.
- Тест-план (план тестирования) – формализованное и укрупненное описание одной сессии тестирования по одному или нескольким направлениям проверок. Т.е. перечень направлений проверок, которые должны быть проведены в рамках сессии тестирования (и, сообразных этим направлениям, требований). Также может содержать в себе необходимую информацию об окружении, методике, прочих условиях важных для показательности данной сессии тестирования. Под направлением проверок также может пониматься более детализированная тестовая документация (в виде ссылки на нее): чек листы, тестовые комплекты, тестовые сценарии, на которую необходимо опираться при проведении сессии тестирования. Основная цель документа – описать границы сессии тестирования, стабилизировать показательность данной сессии.
- Тестовый сценарий – последовательность действий над продуктом, которые связаны единым ограниченным бизнес-процессом использования, и сообразных им проверок корректности поведения продукта в ходе этих действий. Может содержать информацию об исходном состоянии продукта для запуска сценария, входных данных и прочие сведения, имеющие определяющее значение для успешного и показательного проведения проверок по сценарию. Особенностью является линейность действий и проверок, т.е. зависимость последующих действий и проверок от успешности предыдущих. Цель документа – стабилизация покрытия аспектов продукта, необходимых для выполнения функциональной задачи, показательными необходимыми и достаточными проверками. Фактически при успешном прохождении всего тестового сценария мы можем сделать заключение о том, что продукт может выполнять ту или иную возложенную на него функцию.
- Тестовый комплект – некоторый набор формализованных тестовых случаев объединенных между собой по общему логическому признаку.
- Чек-лист (лист проверок) – перечень формализованных тестовых случаев в виде удобном для проведения проверок. Тестовые случаи в чек-листе не должны быть зависимыми друг от друга. Обязательно должен содержать в себе информацию о: идеях проверок, наборах входных данных, ожидаемых результатах, булевую отметку о прохождении/непрохождении тестового случая, булевую отметку о совпадении/несовпадении фактического и ожидаемого результата по каждой проверке. Может так же содержать шаги для проведения проверки, данные об особенностях окружения и прочую информацию необходимую для проведения проверок. Цель – обеспечить стабильность покрытия требований проверками необходимыми и достаточными для заключения о соответствии им продукта. Особенностью является то, что чек-листы компонуются теми тестовыми случаями, которые показательны для определенного требования.
- Тестовый случай (тест-кейс) – формализованное описание одной показательной проверки на соответствие требованиям прямым или косвенным. Обязательно должен содержать следующую информацию:
- Идея проверки.
- Описание проверяемого требования или проверяемой части требования.
- Используемое для проверки тестовое окружение.
- Исходное состояние продукта перед началом проверки.
- Шаги для приведения продукта в состояние, подлежащее проверке.
- Входные данные для использования при воспроизведении шагов.
- Ожидаемый результат.
- Прочую информацию, необходимую для проведения проверки.
- Обеспечить стабильность покрытия требований проверками.
- Обеспечить показательность всех проводимых проверок.
- Обеспечить необходимость и достаточность проводимых проверок.
- Сэкономить время на этапах тестирования, сводя их к проведению проверок и анализу и передаче результатов.
- Снизить входной уровень квалификации тестировщика для проведения проверок.
- Повысить прогнозируемость сессий тестирования в части затрат времени и ресурсов.
- Повысить прозрачность процесса тестирования для других участников процесса производства продукта.
- Обеспечить базу знаний о продукте и истории его развития.
- Стабильность покрытия. Со стремящейся к бесконечности долей вероятности, если проводится тестирование по документации, то будут проведены только те проверки, которые есть в данной документации. Вероятность пропуска ошибки (чаще всего несоответствие косвенному требованию, непокрытому документацией) возрастает.
- Плохая локализация ошибки тестировщиком. Либо полное отсутствие локализации. Фактический результат не совпал с ожидаемым – ошибка. А что это на самом деле: ошибка; проявление ошибки; инцидент, уже описанной ошибки, тестировщик не проверит (в подавляющем количестве случаев).
- Высокий требуемый уровень квалификации специалиста для создания и поддержания тестовой документации.
- Большие временные затраты на создание и поддержание тестовой документации.
- Слабо прогнозируемое время актуальности тестовой документации.
Естественно, видов документации в тестировании гораздо больше, но без понимания назначения и особенностей этих документов работать в этой профессии очень сложно. И чтобы совсем не увеличивать размеры статьи, рассмотрим последний (для этой статьи) вопрос.
Из каких этапов состоит процесс тестирования?
- инициация,
- выявление требований прямых и косвенных,
- генерация тестовых случаев,
- отбор показательных тестовых случаев,
- проведение проверок,
- фиксация результатов,
- анализ результатов,
- передача информации о соответствии проверенного продукта требованиям.
Инициация – событие, которое извещает команду тестирования о необходимости сессии тестирования, а также гарантирует выполнение требований к продукту для проведения тестирования.
- доступно необходимое тестовое окружение,
- доступен билд/ресурс/предмет тестирования,
- код, БД, прочие компоненты объекта тестирования «заморожены», т. е. не изменяются в период всей сессии тестирования,
- модификация требований (хотя бы прямых) «заморожена»,
- известно направление тестирования,
- известны сроки на сессию тестирования.
Выявление требований – пожалуй, один из главных шагов в процессе тестирования. Неизвестны требования – нет тестирования. Необходимо собрать всю доступную информацию о предмете тестирования, вариантах использования и т. п. Первый источник – техническая документация и юзер-стори – это прямые требования. Качество же косвенных требований во многом зависят от добросовестности, ответственности, квалификации тестировщика и всей команды проекта.
Генерация тестовых случаев – выявление всех возможных случаев использования продукта, его характеристик и особенностей в процессе эксплуатации. Это значит: всех случаев, которые тестировщик может «придумать» на основе прямых и косвенных требований, известных ему. Этот этап требует высокой квалификации специалиста по тестированию.
Отбор тестовых случаев – отбор наиболее показательных, значимых и воспроизводимых тестовых случаев. От этого этапа зависит, насколько тестирование будет полезным, эффективным и анализируемым. Например, в «простом» примере с красной кнопкой понятно, что количество косвенных требований стремится к бесконечности, и проверять их все подряд – полный абсурд, но подобные кейсы должны быть сгенерированы хотя бы в голове проверяющего. А для того чтобы они не вошли в проверки, необходимо выполнить соответствующий отбор и проверить только, действительно ли кнопка красная.
Пример примитивный, но после его озвучивания соискатели перестают первым делом пытаться налить в стакан радий на тестовом задании J (кто принимал участие в собеседовании на должность тестировщика, тот знает это нехитрое задание на генерацию и отбор тестовых случаев).
Проведение проверок – тут все понятно. Либо согласно документации, либо ad hoc (интуитивно, свободный поиск, без документации). В любом случае это проводится согласно списку отобранных проверок. Почему-то большинство именно этот пункт называет тестированием. И в голове обывателя, незнакомого с профессией, только один этот пункт и содержится J.
Фиксация результатов – создание внутренней и внешней тестовой документации в формализованном виде или в виде записей и т. п. На данном этапе отчет о тестирование даже если и создается, то не считается законченным.
Анализ результатов – вынесение решения о соответствии проверенного продукта требованиям. Формализация данного решения и его обоснование в виде отчета о тестировании. Сюда также входят процедуры по оценке покрытия требований проверками, тайм-шитинг и пр. Таким образом, проводится анализ не только результатов, но и самой сессии тестирования.
Передача информации о соответствии продукта требованиям. Формально: передача внешней тестовой документации заинтересованным в ней сторонам, зачастую инициатору сессии тестирования. В общем случае: помимо документации предоставляется информация о рисках, которые были выявлены в продукте, требованиях, процессах, передаются рекомендации по отработке этих рисков и т. п. Но это – уже QA J!
Вместо послесловия
Внимательный читатель заметил, что вопросы набирают сложность от начала к концу беседы. Вместе с тем, стоит отметить, что все эти вопросы не должны затруднить специалистов по тестированию, то есть тех, кто не «просто кликал мышью – тестировал», а пытался разобраться в сути того, чем он занимается, тех, кто не остановился на одной книжке или одном ресурсе, а продумал и обосновал свои действия… хотя бы для самого себя.
На этом я завершаю данную статью. Если уважаемый читатель найдет предмет для дискуссии в моих утверждениях, буду рад в ней поучаствовать. Если появятся вопросы, то они станут темами для будущих статей. Всегда рад конструктивной критике. В любом случае пишите мне. Если к статье будет проявлен интерес, то продолжу разбор собеседований, а, возможно, попробую осветить и другие аспекты профессии, о которой слышали почти все, но мало тех, кто знает ее изнутри.
- Тестирование IT-систем
- Тестирование веб-сервисов
- Тестирование мобильных приложений
Почему один из критериев выбора начинающего тестировщика — наличие платного обучения?
Вы можете сказать, что платное обучение — это не показатель. Что кандидат, который обучался самостоятельно, может понимать в тестировании больше, чем тот, который прошел платное обучение.
И я не буду даже с этим спорить, такое может быть. Ведь платное обучение — это не гарант.
Так почему же многие работодатели приглашают на собеседование только тех, кто имеет на руках “волшебную бумажку”? Разберемся.
1. Серьезность намерений.
Да, вот такая обычная бумажка показывает работодателю, что вы серьезно настроены найти работу и стать тестировщиком. Что это не просто ваше желание, в которое вы не готовы вкладываться, а желание, которое подкреплено конкретными действиями. То есть вы как минимум для себя решили, что точно хотите работать тестировщиком, и поэтому пошли и обучились.Потратить свое время и деньги на обучение — это серьезный шаг. Он означает, что вы все взвесили и относитесь к данной профессии серьезно. Она для вас не какой-то легкий способ войти в IT и сбежать через пару месяцев в программисты. И это не просто мимолетное желание попробовать себя в чем-то новом.
Это ваше осознанное решение, на осуществление которого вы уже потратили определенные ресурсы. И именно это показывает сертификат.
Конечно, вы и без него можете тратить много времени и ресурсов. Но чем докажете? Продумайте, чем и как это отразить в резюме.
2. Теоретический минимум.
Наличие сертификата — это показатель того, что вы обладаете минимальными теоретическими знаниями, необходимыми для начала работы. Откуда такая уверенность? Большинство школ готовит тестировщиков не по выдуманным программам, а подстраивает обучение именно под требования, которые предъявляет рынок к начинающим тестировщикам. На это и ориентируется работодатель.То есть он понимает, что данный кандидат знаком с теорией в том объеме, которого будет достаточно для начала работы, и что не нужно будет ему заново рассказывать о каких-то азах.
Вы и без платного обучения знаете необходимый теоретический минимум? Думайте, чем это доказать.
3. Практический опыт.
Многие учебные площадки (не все, конечно) не просто выдают теорию, но еще и проводят практические занятия. Почему? Потому что сейчас редко где встретишь работодателя, который не выдаст тестовое задание. Поэтому необходимо дать ученику не только теоретические знания, но и практический опыт. Ведь именно практический опыт больше всего интересен работодателю и именно его “прощупывают” во время собеседования и при выполнении тестового задания.То есть если вы не просто прошли теоретическое обучение, а прошли обучение, в котором есть практика (и чем больше, тем лучше), то это еще больше упрощает работодателю задачу вашего дальнейшего “вливания” в тестирование.
Да, работодатель, который берет на работу начинающего тестировщика, прекрасно понимает, что его нужно учить больше, чем специалиста с опытом. Но ему проще взять человека, который уже где-то получил этот опыт (пусть и под наставничеством более опытного тестировщика-преподавателя), но он его получил. А это значит, что он быстрее вникнет в работу и начнет выполнять рабочие задачи.
Хотите снова возразить и сказать, что у вас тоже есть такой практический опыт и без сертификата? Отлично, снова думайте, как продемонстрировать его работодателю.
4. Побег.
Взяли мы на работу начинающего тестировщика. Поработал он у нас 2-3 дня и сбежал со словами “это не мое, я ожидал другого”. Такие ситуации встречаются хоть и не часто, но очень неприятны. И такие “побеги” чаще совершают тестировщики, которые обучались самостоятельно и у которых не было возможности попробовать себя в роли тестировщика на практике.А тестировщик, который прошел обучение с практикой, уже понимает, что его ждет на работе. Он уже делал это своими руками и решил для себя, точно ли это его. Вероятность того, что такой тестировщик убежит, крайне мала (что показывает, в том числе и практика).
Важный вывод
Сам факт наличия сертификата не гарантирует трудоустройства. Но наличие этого сертификата — один из критериев отбора для работодателей. И с каждым годом количество таких работодателей растет. Это просто факт. Им выгоднее взять уже более-менее подготовленного человека с определенным набором практических навыков, чем человека, который просто что-то знает о тестировании в теории и то не совсем до конца разобрался. Поэтому работодатели отсеивают кандидатов без сертификатов и проводят дальнейший отбор именно из их числа.
И как раз на дальнейшем этапе уже и выясняется, у кого этот сертификат действительно подтверждает практические знания и умения, а у кого просто получен за просмотр видео. Поэтому не просто важно получить сертификат, а именно обучиться на курсе/тренинге/практикуме, который даст как можно больше практических навыков. И такое обучение есть. Нужно просто его найти и выбрать подходящее именно для вас. Может, наш 8-недельный тренинг с практикой на реальном проекте станет таким подходящим обучением именно для тебя. А может, и нет. Но если интересно, то загляни на наш сайт https://sedtest-school.ru/training
Еще раз: я не говорю, что нельзя обучиться самостоятельно и устроиться на работу. Я просто говорю о том, что для многих работодателей наличие сертификата — обязательный критерий для рассмотрения резюме. И этот критерий они могут даже не обозначать в вакансии.
Вы можете соглашаться с такой ситуацией на рынке или не соглашаться. Это ничего не меняет. Ситуация все равно остается именно такой. И только вам решать, как обучаться и получать работу в таких условиях.
7 шагов в тестирование: вы спрашивали — мы отвечаем
Тестировщик ПО – очень модная и востребованная профессия, которая уже успела обрасти множеством слухов и легенд. Развеиваем мифы, рассказываем, с чего начать и к чему готовиться на пути к должности «специалист по тестированию ПО » в компании EPAM.
Миф №1 : Начать карьеру в IT через тестирование легко и просто.
Реальность : Сделать это сложнее, чем почему-то принято считать. Работа в тестировании предполагает наличие специфических навыков, хоть и не требует обязательного технического бэкграунда. Однако, справедливости ради, нужно отметить, что порог вхождения в IT через тестирование действительно ниже, чем через разработку.
Миф №2 : Стать тестировщиком может каждый.
Реальность : Освоить профессию тестировщика так же, как и профессию педагога или бухгалтера, под силу далеко не каждому. Чтобы преуспеть в тестировании, нужно иметь аналитический склад ума, быть внимательным к деталям, уметь находить эффективные решения проблемы вместо привычного следования алгоритму, быть готовым много и постоянно учиться.
Миф №3 : Чтобы стать тестировщиком, достаточно просто закончить соответствующие курсы.
Реальность : Если вы всерьёз решили начать карьеру в тестировании, первым делом вам, и правда, нужно пройти базовый курс обучения, но это лишь первый шаг на долгом и непростом пути.
А теперь подробнее о том, что этот самый путь в тестирование собой представляет.
Обучиться основам тестирования можно на различных курсах – сегодня в Минске их насчитывается порядка 50. Один из вариантов получения базовых знаний – бесплатный курс Software Testing Introduction , к оторый помимо обучения предоставляет ещё и реальную возможность влиться в команду EPAM .
Шаг первый – регистрация на курсы Software Testing Introduction на сайте training.by .
Новый тренинг стартует каждые два-три месяца, приём заявок начинается за полтора-два месяца до его начала. Прежде чем подать заявку, кандидатам нужно ознакомиться с базовыми требованиями и соотнести их со своими навыками и умениями:
- Прочтение книг Романа Савина «Тестирование.com», Святослава Куликова«Тестирование программного обеспечения. Базовый курс»и понимание основ тестирования.
Если книги кандидат не осилил или пролистал, не особо при этом обогатив свой багаж знаний, скорее всего его карьера тестировщика закончится, так и не начавшись. От кандидатов не требуется глубинных знаний в тестировании, но основные термины и общее понимание процессов до начала занятий на курсах должны быть усвоены.
- Уровень разговорного английского языка – не ниже B1.
Без соответствующего уровня английского шансы на зачисление на курсы стремятся к нулю. Объясняется это очень просто: EPAM – интернациональная компания. Проектные команды сегодня зачастую распределённые, т.е. тестировщику приходится постоянно общаться по-английски с остальными (зачастую не русскоговорящими) участниками проекта как с помощью писем, так и посредством аудио- и видеосвязи. Более того, работа тестировщика подразумевает общение с клиентом, а подавляющее большинство заказчиков EPAM – из США и стран Западной Европы.
- Хорошие навыки работы с компьютером, знание основ баз данных и сетей, понимание интернет-технологий и работы веб-приложений.
Никто не говорит о необходимости досконального владения темами, и умения настраивать сеть на 8000 ПК на интервью требовать от кандидата не станут. А вот общее понимание того, как всё это работает, у будущего инженера по тестированию должно быть.
- Отличные коммуникативные способности.
Здесь все ещё прозрачнее: работа тестировщика подразумевает постоянное общение с проектной командой и заказчиком, соответственно, умение эффективно коммуницировать – абсолютная необходимость.
Все пункты являются одинаково важными. Если соискатель не может поставить галочку напротив хотя бы одного из них, пазл, скорее всего, не сложится.
Среди слушателей курсов мы одинаково рады видеть как студентов или недавних выпускников вузов, так и тех, кто уже успел поработать в другой сфере. Главное – при заполнении анкеты максимально полно указать всю потенциально значимую информацию о своём образовании и опыте работы. Например, хорошую службу уже на начальном этапе отбора может сослужить указанное в анкете знание какой-либо предметной области – финансовой, страховой, медицинской и т.д. – такие знания очень полезны на проектах соответствующей направленности. Ещё один вариант – прикрепить резюме с детальным описанием предыдущего опыта работы и учёбы.
Шаг второй – отбор заявок и телефонная беседа.
Со всеми кандидатами, подавшими заявки, проводится короткая телефонная беседа. Общие вопросы и короткий диалог на английском – в подавляющем большинстве случаев этого достаточно, чтобы понять, стоит ли приглашать кандидата на личное интервью. После общения со всеми соискателями специалист по подбору персонала лично сообщает каждому из них о принятом решении.
Шаг третий – личное интервью .
В ходе интервью кандидаты демонстрируют уровень владения английским, проходят тест на общую компьютерную грамотность и отвечают на вопросы, связанные с тестированием. Предполагается, что к этому моменту, после изучения необходимой литературы, общее представление о тестировании у кандидатов уже есть.
Шаг четвёртый – формирование группы .
После личных интервью со всеми соискателями команда специалистов по подбору персонала совместно с менеджерами компании принимает решение о зачислении на курсы. Учебная группа формируется из 30 кандидатов, показавших лучшие результаты.
Стоит отметить, что специалисты по подбору персонала всегда дают обратную связь кандидатам. Соискатели, соответствующие большинству критериев, но чуть-чуть «не дотягивающие» в какой-то из областей, могут воспользоваться вторым шансом.
Шаг пятый – курсы Software Testing Introduction (STI).
Курсы длятся пять недель: три-четыре занятия по четыре академических часа в неделю. Задача STI – систематизировать и расширить знания, полученные при изучении необходимых книг. И главное – за время обучения слушатели курсов выполняют множество практических заданий, которые тренер оценивает. Тренинг охватывает такие темы как: анализ документации, разработка тест-кейсов, поиск и документирование дефектов, а также основы автоматизации тестирования и оптимизации производительности.
Шаг шестой – пост-тренинговое собеседование.
После окончания курсов Software Testing Introduction всех выпускников ждёт собеседование с менеджерами компании. Кандидатам важно показать накопленные за время прохождения курсов знания в области тестирования, пообщаться на английском языке и проявить коммуникативные навыки. Все слушатели тренинга, успешно прошедшие пост-тренинговое собеседование, начинают обучение в EPAM Software Functional Testing Lab .
Шаг седьмой – EPAM Software Functional Testing Lab.
В лаборатории выпускников тренинга ждут в среднем два-три месяца непрерывной учёбы и практики: 5-дневная 40-часовая рабочая неделя – условия, максимально приближенные к рабочим. При этом возможен гибкий график, который позволяет совмещать обучение в лаборатории и вузе. В течение этого времени учащимся предоставляется шанс показать то, чему они уже успели научиться, и узнать много нового. А самое главное – им предстоит попробовать себя в роли тестировщиков на учебном проекте.
Через 2-3 месяца интенсивной учёбы учащиеся лаборатории проходят собеседования на проекты. После успешного прохождения интервью они становятся сотрудниками компании EPAM в должности Junior Software Testing Engineer .
Карьерный путь в EPAM
Важно понимать, что прохождение одного или нескольких этапов ещё не гарантирует трудоустройства. 100% гарантии того, что кандидат станет сотрудником EPAM, нет, даже если он уже зачислен в EPAM Software Functional Testing Lab .
Резюмируя всё вышесказанное: у желающих есть все шансы начать карьеру в тестировании при наличии требуемых исходных данных, достаточной мотивации и стремления к цели. Если вам интересно тестирование как дисциплина, и вы хотите развиваться в ней, дерзайте! Руководство к действию у вас теперь есть.
Почему решили попробовать себя в тестировании
22 НОЯБРЯ 2021
Как начать тестировать?IT-профессии и раньше манили молодых людей, которые только начинают свой карьерный путь, а также манили тех, кто хотел поменять профессию аки Иван Васильевич. С наступлением пандемии к преимуществам IT-сферы добавилась стабильность. IT-специалисты, как и все, разошлись по домам, но при этом остались на своих рабочих местах. Немудрено, что все больше и больше людей пытаются найти этот ключ от двери в «большое IT», а предложить его пытаются и популярные образовательные проекты, и крупные IT-компании, организовывающие курсы переподготовки, и даже национальные государственные программы. Что их всех объединяет?
Тимур Мироненко
Старший программист в тестировании ПО- В 2020 году возглавил работу команды в новой локации Компании;
- разработал сетевые интерфейсы для эмуляторов;
- по итогам 2019 года награжден в корпоративной ежегодной номинации «Командный игрок» за успешный и плодотворный вклад в развитие команды, готовность содействовать и передавать свои знания и опыт;
- разработал фреймворк для разработки автотестов UI и API.
- HTML, CSS, C/C++, C# Java Jscript, Microsoft Access, SQL, MS SQL, ORACLE, Linux, Windows, Ruby, XML, Git.
Они все пытаются донести мысль о том, что «самый лёгкий способ попасть в IT — идти в тестирование». Так ли это на самом деле? Что нужно знать о профессии и что нужно знать, чтобы войти в профессию? Попытаемся найти ответ в этой статье.
А самый ли лёгкий путь?
Вышеуказанный тезис я слышу в 70% случаев, когда задаю вопрос «Почему вы решили попробовать себя в тестировании?» кандидатам на позицию Junior QA Engineer. Я не планирую разрушать этот миф, ведь это и не совсем миф. Однако считаю важным пролить свет на этот вопрос, дабы взглянуть на него пошире. Является ли тестирование самым легким способом попасть в IT? Конечно же, нет. Образ IT-компании как места, в котором сидят 20 человек, жмут кнопки, пьют кофе и говорят на смеси русского с техническим английским, уже давно пора похоронить. На этих предприятиях также трудятся маркетологи и юристы, бухгалтеры и кадровики. Это лишь краткий список сотрудников, и если вы уже состоялись как специалист в этой отрасли, то путь в IT-мир для вас может быть гораздо проще, чем изучение новой профессии тестировщика.
Можно много спорить о терминах, но в большом количестве вакансий «Тестировщик» и «QA Engineer» пишутся через косую черту и используются как взаимозаменяемые. И тестировщик — это действительно техническая должность, должность инженера. Но, пожалуй, действительно с самым низким порогом вхождения среди всех инженерных позиций в IT-компаниях. Отсюда и пошла вот эта легенда про «самый лёгкий путь». В тестирование действительно можно прийти без знаний алгоритмов сортировки на C++ или умений администрировать сервер на Linux. Однако уровень технической базы должен быть высоким, и нужно быть готовым регулярно повышать её. Тем, кто обучался на IT-специальностях в университете, конечно, будет проще, но это не значит, что профильное образование является обязательным условием для начала карьеры в тестировании.
Кроме того, рекомендую изучить вакансии тестировщиков на уровнях Junior и Middle еще до того, как вы решитесь окунуться в освоение новых навыков. Это даст вам понимание заработной платы младшего инженера, и сколько времени занимает рост до уровня Middle. Это зачастую всё индивидуально: кто-то развивается быстрее, кто-то медленнее, но получить какие-то средние цифры это вам поможет. Возможно, вы просто не окажетесь готовы сделать сейчас шаг назад в своем ежемесячном доходе, даже если в перспективе через какое-то время он превысит ваш текущий.
А что нужно знать и уметь?
На заводе хорошо, а в трамвае — лучше,
я б кондуктором пошел, пусть меня научат.
В. МаяковскийНа собеседованиях я неоднократно слышал формулировку, напоминающую цитату из стихотворения Маяковского. Что-то по типу «ну примерно кто такой тестировщик я почитал, готов обучаться». Стремление к обучению — несомненный плюс, и этим вы будете заниматься всю свою карьеру, но в начале пути уже надо что-то знать и уметь. Дальше я буду описывать, что IT-компании ожидают от кандидата на должность младшего инженера по тестированию.
Я начну именно с soft skills, так как считаю их даже более важными. Технические недочёты можно закрыть с помощью усердия и свободного времени, а вот «переделать себя» будет уже сложнее. Именно через эти навыки можно понять, подходит ли вам работа в тестировании.
1. Усидчивость
Уже утомились читать эту статью? Очень плохо. В тестировании вам придется читать очень много технической документации, понятной и не понятной, актуальной и не очень. Кроме того, придется повторять одни и те же действия для проверки одной и той же функциональности. Деятельность тестировщика очень монотонна, и надо быть к этому готовым.2. Внимательность
Тестировщик — это человек, ответственный за качество конечного продукта. Стоимость исправления дефекта, обнаруженного при тестировании, и обнаруженного при опытной эксплуатации существенно отличается, поэтому невнимательный тестировщик — это слишком большая роскошь для бизнеса. Вы должны уметь концентрироваться на задачах, которые выполняете, иначе будете пропускать ошибки/затягивать процесс тестирования, что сведет пользу вашей работы к нулю.3. Коммуникабельность
Один мой знакомый сказал мне, что решил изучать тестирование для последующего переезда за границу, так как «английский мой не очень, поэтому выбрал там, где надо общаться поменьше». Конечно, коммуникаций у менеджера по продажам поболее, чем у тестировщика. Но тестировщик — это человек, который не может работать по принципу «взял задачу — решил задачу — закрыл задачу». Тестировщик ежедневно коммуницирует с разработчиками, аналитиками, другими тестировщиками из смежных команд. Кроме того, так как тестировщики становятся самыми опытными пользователями разработанных продуктов, они так же могут общаться с бизнес-заказчиками, проводить демонстрации доработок и так далее. Если вам неуютно много общаться на работе, то работать в тестировании вам не понравится.4. Адаптивность
Умение переключаться между задачами без потери концентрации очень ценится. Меняются проекты, продукты, платформы, процессы, и нужно успевать перестраиваться под новые условия.Вышеуказанные навыки — не просто стандартная отписка в резюме, это действительно важные характеристики. Если по ним вы узнаёте себя, то можно перейти к технической составляющей знаний и умений кандидата.
1. Методологии разработки ПО
Разработка ПО — непрерывный процесс, практически живой организм, и важно понимать в нём свое место. Зачастую тестировщики попадают на проект, где разработка идет уже активно. Именно поэтому нужно понимать: когда задачи попадают к тестировщику, когда нужно проводить этапы приемочного и регрессионного тестирования, как созданные баг-репорты будут попадать к разработчикам.2. Теория тестирования ПО
Считается, что без практики теория бесполезна. Но обратное утверждение может быть еще более справедливым. Если вы собираетесь работать в тестировании, то вы просто обязаны знать, что же такое тестирование, какие существуют виды тестирования и зачем вообще их как-либо делить, какими бывают требования к продукту. Отдельно стоит разобраться с техниками тест-дизайна. Ведь на самом деле, хоть при первом прочтении они кажутся достаточно примитивными и слишком теоретическими, это является основой всех проверок, которые проводит тестировщик.3. Виды тестовой документации
Весь труд тестировщика должен быть зафиксирован с помощью различных видов тестовой документации. Тестировщик на теоретическом уровне должен быть знаком с понятиями тест-плана, отчёта о проведении тестирования. А вот с тест-кейсами, чек-листами и баг-репортами желательно быть знакомым и на практике. На собеседованиях я часто слышу: «Не было практики, так как нечего было тестировать». Вздор! Работа тестировщика — это не значит найти баг, это значит убедиться, что багов нет. А вот как вы это будете проверять, можно вполне описать на любом доступном примере. Откройте форму авторизации на одной из соседних вкладок или же посмотрите на чайник на вашей кухне и попробуйте описать проверки для корректной работы этой формы/прибора. Найдёте ошибку — супер. Попробуйте её грамотно расписать по всем правилам оформления баг-репорта. Кроме того, приятным бонусом будет, если вы изучите, какие системы используют IT-компании для заведения баг-репортов и тест-кейсов.4. Базы данных
Каждому тестировщику приходится сталкиваться с понятием тестовых данных. Как их добыть/создать может быть несколько способов, часто это можно сделать с помощью пользовательского интерфейса используемого продукта. Но зачастую это а) долго, б) невозможно. И тогда появляется необходимость обратиться напрямую к базе данных. Младший инженер по тестированию должен знать о том, что такое база данных, какие типы этих баз данных бывают, из чего эти базы данных состоят. Несомненно, нужно владеть минимальными навыками написания запросов на языке SQL. В первую очередь, это SELECT на уровне выборки из нескольких таблиц, с возможностью группировки данных, применения функций агрегирования и сортировок. Кроме того, вашим преимуществом будет умение применять запросы INSERT, UPDATE и DELETE.5. API
На самом деле этот вопрос немного шире. Кандидат должен понимать, что такое клиент-серверная архитектура, как взаимодействуют между собой различные модули веб-приложения, что такое frontend и backend. Желательны практические навыки работы c SOAP и REST в популярных приложениях: SOAP UI, Postman, Insomnia; понимать, чем такие виды веб-сервисов отличаются. Термины «WSDL» и «HTTP-метод» зачастую будут звучать на собеседованиях, так что нужно изучить эту тему заранее. Бонусом будет, если вы также сможете рассказать о MQ-очередях, как об ещё одном способе передачи данных.Как обучаться тестированию?
Список солидный, не правда ли? Всё ещё считаете тестирование лёгким путём в IT? Если не испугались, то давайте рассмотрим способы обучения.
1. Курсы
Сейчас в Сети и не только достаточно много курсов по обучению профессии «тестировщик ПО». У многих из них действительно хорошие программы. Как выбрать самый лучший? При выборе обращайте внимание на то, насколько она соответствует тому, что ожидается от кандидата — это я описал выше. Важным фактором также является наличие практических заданий. Это даст вам не только полезный опыт, но и сформирует у вас окончательное понимание, насколько вам подходит эта профессия. Рекомендую также почитать отзывы выпускников, чтобы понимать, удаётся ли с полученным багажом знаний устроиться на работу. Подходящая вам стоимость обучения определяется исключительно вами. Курсы отлично подходят тем людям, которым проще обучаться в группах, в формате «преподаватель — ученик», чем изучать самостоятельно. Но помните: сам факт прохождения курса не гарантирует вам получение высокооплачиваемого места работы. Главное — это ваши знания и умения, которые вы с этих курсов должны вынести.2. Литература
Тут я имею в виду буквально книги. Книг по тестированию меньше, чем по программированию, но и тут есть что почитать. В книгах информация изложена весьма структурировано, что позволяет эту информацию, как кирпичиками, выложить у себя в голове. Конечно, недостаток книг — это то, что они дают только теоретические знания, но как я писал выше, практические навыки вы можете получить, просто тестируя то, чем пользуетесь ежедневно. Хотите контроль? Попросите друзей повторить действия из ваших проверок. Чем меньше у них возникнет вопросов — тем понятней и правильней составлен тест-кейс.3. Интернет
В интернете много текстовых и видеоматериалов по тестированию, базам данных и веб-сервисам. Впрочем, я советую прибегать к этим материалам исключительно дополнительно к тому, что вы услышите на курсах или прочитаете в книгах. Прошли занятия по тест-дизайну? Прочитайте 2−3 статьи об этом, чтобы углубиться в тему. Почему плохо готовиться, исключительно обращаясь к Гуглу с тем или иным термином? Вы не получите целостного понимания того, что вам нужно изучить, и несколько уточняющих вопросов на собеседовании вас поставят в тупик.Какой способ обучения лучше всего? Все вместе, разумеется. Изучили новую тему — пошли почитали в Интернете, забежали на онлайн-тренажёр для написания SQL-запросов, параллельно попробовали поработать в Postman. И помните: освежать знания нужно постоянно. Я часто слышу фразу: «Да, SQL пробовал, но это было пару месяцев назад, чуть подзабыл». Забывать — это нормально, но преимущество всегда будет у кандидата, который не забыл. Намёк, я думаю, понятен.
После того как вы почувствовали, что готовы начинать работу, все необходимые навыки у вас есть, нужно заполнить резюме. Тут важным моментом является, какие навыки указывать. Практически все кандидаты делятся на два лагеря. Первые пишут в навыки всё то, что слышали краем уха, а когда начинаешь задавать им вопросы об этом, оказывается, что «я в курсе про это, но практических навыков нет». Другие же думают: «Ну я об этом только читал, указывать это не буду», и по итогу просто не доходят до собеседования, так как у них не указано необходимых для работы навыков. Так что же делать? Указывать те навыки, изучению которых вы уделили достаточно времени, чтобы рассказать, что это такое, для чего применяется и с какими инструментами. Глубину ваших знаний можно честно указать в разделе «О себе». Если вы претендуете на должность младшего специалиста, то никто от вас не будет ждать экспертных знаний в этом. Пишите честно.
Когда вам назначат собеседование, то очень важно на это собеседование прийти вовремя. Если собеседование проводится удалённо, то включите камеру. В остальном же это банальные и понятные, но при том важные вещи по типу: выглядеть опрятно, исключить из речи нецензурную лексику и так далее. Поверьте, бывали разные случаи. Не стоит волноваться: держите в голове мысль, что первые 2−3 собеседования для вас важны как получение опыта, исследование недочётов в вашей подготовке. В конце концов, вы не проситесь на работу, а предлагаете свою кандидатуру для сотрудничества, и как вы можете не подойти компании, так и компания может не подойти вам.
Помимо вопросов, которые работодатель задаёт вам, важной частью являются ваши вопросы работодателю. Это стандартные вопросы об оформлении, графике работы, размере заработной платы, но также узкие вопросы, которые могут дать вам понимание вашего развития.
1. Сколько сотрудников компании работают в тестировании? Есть ли политика менторства?
Для начинающего тестировщика очень важно присутствие опытного инженера, который может сделать период адаптации более комфортным и быстрым. Кроме того, работа со сформировавшимися профессионалами делает вас как специалиста лучше. Несколько раз я собеседовал тестировщиков из веб-студий с опытом работы в 1−1,5 года, но их уровень навыков был не лучше Junior’ов. Почему так? Они были там единственными, кто занимался тестированием, их никто не контролировал, не давал оценку их работе. Задачи были монотонными, поэтому отдельные навыки типа SQL не применялись и забылись.2. На каком проекте мне работать? Какие технологии там применяются и по какой методологии разрабатывается ПО?
Кроме того, что такой вопрос демонстрирует вашу заинтересованность в работе для работодателя, ответ на этот вопрос даст вам понять, с чем вам предстоит столкнуться на проекте, какие технологии сейчас востребованы. Часто бывает так, что есть вакансии на разных проектах и уже по итогам собеседования становится понятно, какие навыки у кандидата развиты лучше и на какой проект он подходит больше. Чем больше применяется технологий, тем лучше для вас как для специалиста. Снова приведу пример из собеседований. Был период, когда в одно время собеседовал 3−4 ребят из геймдева. Работа мечты, казалось бы: играй в игры, проверяй, что доработка работает, дальше исследовательским путём ищи ошибки. Их навыки тестирования были хороши, но на вакансии, где требуется знание тестирования интеграции, они не подходили, так как не были к этому готовы. Зато подошли кандидаты вообще без опыта, но со свежими знаниями и умениями в Postman и SOAP UI.3. Какие у меня есть пути развития в компании? Есть ли практика внутреннего обучения?
На этапе подготовки к первому собеседованию обучение не заканчивается. Чем больше вы будете учиться, тем крепче вы будете стоять на ногах на рынке IT-специалистов. Впрочем, не со всеми технологиями мы можем столкнуться на проекте, а на следующем они будут нужны (пример геймдева выше). Внутреннее обучение позволяет открыть «второй фронт» для развития ваших навыков. Кроме того, вам нужно понимать, как ваше развитие как специалиста будет коррелировать с вашим развитием в компании, когда вы сможете изменить свой уровень заработной платы, должность, сложность проекта. Некоторые стесняются задавать такие вопросы, но в этом нет ничего стыдного и наглого, это абсолютно деловой вопрос двух заинтересованных сторон.Я получил оффер!
Когда вы получите оффер на желаемую должность тестировщика, то еще раз вам стоит всё обдумать. Смена профессии не такой уж лёгкий шаг, а работа не так уж проста. Поэтому оцените еще раз все риски и преимущества, которые вам даёт это решение, и тогда принимайте/не принимайте предложение о сотрудничестве.
Тестирование — это очень интересная и важная отрасль IT-сферы. Если вы после прочтения этой статьи готовы посвятить себя этой профессии и знаете, что у вас есть все необходимые навыки для этого, то составляйте резюме и присылайте его через форму обратной связи Logrocon. Наши эксперты в тестировании готовы пообщаться, дать обратную связь и предложить интересные проекты достойным кандидатам.