Профессия тестировщик что это – Профессия тестировщик — актуальные тренды и свежие новости от Олега Солозобова

Содержание

Как стать тестировщиком — профессия QA-инженер

Профессия тестировщик ПО — один из вариантов, как попасть в IT-сферу. Опыт работы и уровень тестировщика определяет его зарплату. В Беларуси QA-инженер с опытом 1−3 года может рассчитывать на вознаграждение от 700 USD. Хороший заработок и возможность перейти в эту деятельность из нетехнических профессий привлекают многих соискателей. Но все ли могут стать хорошими тестировщиками? Разберёмся, кому подходит эта профессия и как научиться премудростям тестирования.

Чем занимается тестировщик?

QA-инженер (Quality Assurance engineer) — специалист, который проверяет качество созданного разработчиками продукта и соответствие его изначальным требованиям заказчика. Фактически он берёт на себя ответственность за решение, готов продукт или нет. Чем раньше тестировщик подключится к проекту, тем быстрее будет реализован программный продукт.

Пока разработчики заняты воплощением идеи заказчика, QA-инженер продумывает, что и как он будет тестировать. В идеале заказчик предоставляет спецификацию — список требований к продукту, например, цвет кнопок, всплывающие подсказки, последовательность действий и т. д. На её основе тестировщик создаёт чек-лист для проверки. Затем к каждому из пунктов чек-листа (конкретной функции продукта) он пишет тест-кейсы: перечисляет все шаги, которые необходимо сделать, чтобы проверить работоспособность данной функциональности.

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

Кому подходит профессия тестировщика?

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

«Почему QA нужны, почему QA важны» рассказывает Татьяна Сандригайло — преподаватель курсов тестирования ПО в Адукар

Что нужно изучить претенденту, если он входит в профессию с нуля?

К слову, существует около 100 видов тестирования. Изучить их все самостоятельно и разобраться в сопутствующей терминологии очень сложно. А ещё почти вся актуальная информация представлена на английском языке. Как быть в таком случае? Обратиться к специалистам, которые научат азам профессии и помогут сделать первый шаг в IT. Но, прежде чем сменить профессию, стоит хорошенько разобраться, подходит ли вам эта работа.

в
Попробуй найти все баги на картинке. А ответ ищи в видео нижеОксана Скиндер, QA-директор iTechArt, поделится историей тестировщика Аркадия. Ещё спикер поможет протестировать ваши склонности к профессии QA-инженер

Что дают курсы тестирования ПО?

Обычно курс тестирования длится 3−4 месяца. За это время слушатели успевают изучить базовые принципы и стратегии работы с конкретными техниками тестирования, документацией, багами, базами данных, web-сервисами. На выходе человек умеет составлять различную тестовую документацию (тест-планы, чек-листы, тест-кейсы, баг-репорты, отчёты о результатах тестирования), использовать различные методы и приёмы тестирования, анализировать результаты тестирования и оценивать качество ПО, тестировать мобильные, веб-ориентированные приложения и веб-сервисы.

Присмотреться к курсам и преподавателю можно на пробном занятии, которое проводится для будущих слушателей бесплатно.

в

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

Бажена Ровнейко, Team lead, Senior QA Engineer в компании IT Top и преподаватель курсов тестирования ПО Адукар

Чтобы учёба на курсах была продуктивной, мало посещать занятия, ещё придётся выполнять домашнее задание, готовиться к контрольным, а в конце пройти итоговый тест. Зато тех слушателей, которые успешно окончили курс, Адукар рекомендует в компанию-партнёр. Перспектива привлекательная, не так ли? Но когда есть семья и основная работа, не просто сидеть на уроке, а ещё разбираться в том, что говорит преподаватель, удаётся не всем.

Надеемся, этот материал помог составить общее впечатление о профессии тестировщика и соотнести свои качества с требованиями IT. Если вы хотите стать QA-инженером, осталось записаться на пробное занятие в Адукар.

***

Если материал был для тебя полезен, не забудь поставить «мне нравится» в наших соцсетях ВКонтакте, Instagram, Facebook, ASKfm и поделись постом с друзьями. А мы сделаем ещё больше материалов, которые пригодятся тебе для учёбы.

Перепечатка материалов с сайта adukar.by возможна только с письменного разрешения редакции. [email protected]

в

adukar.by

Ваш идеальный тестировщик / Habr

Время от времени нам нужно найти тестировщика. Рамки поиска могут быть разными: срочно или нет, несколько или один, с определенными скиллами или просто адекватный джуниор. Вопросы сводятся к одному — как понять, что перед нами нужный человек?

Здесь поможет очерк из психологии.

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

Следующий слой — ценности и убеждения. Это те характеристики, которые отвечают на вопрос “почему?” и “зачем?”. Это чувство прекрасного или желание общаться с хорошими людьми. Это важно знать, но вам об этом не расскажут. За час собеседования это не удастся раскрыть, ведь надо ещё поговорить о компании и о позиции.

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

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

Следующий слой: знания и навыки. Это то, чему человек научился, что он умеет. Если мы ищем junior QA, то знаний и навыков у него нет. Но это и не страшно, ведь их можно нарастить.

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

Какие качества ищем?


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

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

Как выбрать?


Всё зависит от целей и методов компании. В молодом коллективе обычно доминирует принцип «как угодно, лишь бы было сделано». Здесь нужен подвижный и командный тестировщик, который нацелен на результат.

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

Давайте перечислим самые востребованные черты характера для профессии тестировщика.

Внимательный / Бдительный


Такой тестировщик всегда начеку и всё записывает. У него всегда под рукой набор для конспекта: блокнот с ручкой, ноутбук с текстовым редактором или смартфон с заметками. Чтобы сразу записать мимолётное озарение или неожиданное замечание.

С момента как такой QA узнаёт про задачу он сразу фиксирует для себя всё что собирает по крупицам — из требований, от разработчиков, из своего опыта или опыта коллег. Он может даже сразу накидать примерный чек-лист для проверок, ведь главное уловить суть, а расписать детали можно и позже.


Создать чеклист — это быстро

Почему?

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

Критичный / Логичный


Как говорил доктор Хаус — “Все люди лгут”. Разработчик завершил работу над мелкой ошибкой, тестировщик сразу проверил. Если есть время, то проверил дважды. Тестировщик ни за что не поверит, что можно что-то исправить с первого раза и до конца. Ошибаются все. А чем опытнее разработчик, тем загадочнее его ошибки.
Критически мыслящий QA выявляет не явные ошибки, а логичные с точки зрения технического задания. Его тест-кейсы не повторяют требования, а проверяют их.


«Нелогичное» и «невозможное» — разные вещи

Почему?

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

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

Любознательный / Дотошный


Тестировщик часто работает в условиях нехватки входных данных и нечётких требований. Порой приходится самостоятельно лезть в код, чтобы понять как работает система.

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

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


Подробные шаги тест-кейса внушают спокойствие

Почему?

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

Чтобы избежать неприятных разговоров, надо на основе задачи создать свой тест-кейс. В нём детально расписать всё, что должно быть проверено. Последним шагом в тестировании стоит составить отчёт, понятный даже не посвящённому человеку. ПМ увидит результат тестирования и найдёт слабые места. Педантичность поможет детально следить за процессом тестирования.

Коммуникабельный / Сговорчивый


В тестировщике ценится умение рассказать про проблему. Донести до команды серьёзность и критичность положения, а иногда и наоборот — классическая задача этой профессии.

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


Чем раньше рассказать о проблеме, тем дешевле её исправить

Почему?

Тестировщику не нужна коммуникабельность менеджера продаж или харизматичность лидера. Акцент не на то, как хорошо он говорит, а на умение обмениваться информацией, коммуницировать. Хватит способности давать обратную связь и внятно просить помощи, когда она потребуется.

Ответственный / Исполнительный


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


Готовь сани летом, а тест-кейс с кодом

Почему?

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

В заключение


Найти хорошего тестировщика — большая проблема. Цели QA инженера балансируют на грани желаний бизнеса и желаний пользователей. О чём он постоянно напоминает заинтересованным лицам. Это позиция для человека, который решает и технические проблемы и коммуникационные.

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

habr.com

Профессия тестировщик ПО с 0 до PRO

  • Основы тестирования веб-приложений

    • Кто такой тестировщик.
    • Основы архитектуры клиент-сервер.
    • Тестирование веб-страницы.
    • Оформление отчета об ошибке.
  • Тестирование текстовых полей

    • Понятие баг-репорта.
    • Веб-формы и какие они бывают.
    • Тестирование формы с одним полем.
    • Проверка вводимых данных.
  • Тестирование текста, чисел и дат с граничными значениями

    • Откуда брать информацию для тестирования.
    • Граничные значения.
    • Техника анализа граничных значений, чисел и текста.
    • Тестирование дат.
  • Что такое хорошая спецификация. Правильное оформление баг-репорта

    • Какими бывают спецификации.
    • Что такое хорошая спецификация.
    • Как оформлять свою работу: правила написания баг-репорта.
  • Тестирование форм регистрации

    • Основы тестирования форм регистрации.
    • Тестирование поля «e-mail».
    • UX-тестирование. Проверяем понятность формы регистрации.
  • Тестирование форм авторизации и восстановления паролей

    • Введение в тестирование форм авторизации.
    • Чит-лист по проверке формы авторизации.
    • Тестирование формы восстановления паролей.
    • Углубленное тестирование формы авторизации.
  • Тестирование дополнительных элементов интерфейса

    • Сложные элементы веб-форм: checkbox, radio button, select.
    • Чит-лист для проверки checkbox, radio button, select.
    • Тестирование кнопок.
    • Тестирование формы выбора даты.
  • Расширенные техники тестирования

    • Углубленное тестирование текстовых полей.
    • Тестирование способов ввода.
  • Тестовые сценарии: позитивные и негативные

    • Работа со сложными задачами тестирования.
    • Как составлять чек-лист.
    • Тестовые сценарии как инструмент тестирования.
    • Позитивные и негативные тесты.
  • Кроссплатформенное и кроссбраузерное тестирование

    • Пользователь мобильных устройств.
    • Тестирование сайтов на мобильных устройствах.
    • Тестирование сайтов на разных операционных системах.
    • Тестирование в разных браузерах.
  • Дополнительные инструменты тестирования

    • Техника тест-дизайна.
    • Сервисы для тестирования.
    • Полезные приложения для тестировщика.
  • Курс «Веб-верстка для начинающих 2.0» 

  • Курс «Язык запросов SQL»

  • Курс «Система контроля версий Git» 

  • Chrome DevTools, часть 1

    • Что такое Chrome DevTools.
    • Вкладка Elements.
    • Вкладка Console.
    • Вкладка Source.
  • Chrome DevTools, часть 2

    • Вкладка NetWork.
    • Вкладка Security.
  • Chrome DevTools, часть 3

    • Вкладка Performance.
    • Вкладка Application.
    • Вкладка Network Conditions.
  • Тестирование безопасности

    • Что такое тестирование безопасности.
    • Виды уязвимостей.
    • Что такое SQL-инъекция.
    • Поиск SQL-инъекций.
    • Что такое HTML-инъекция.
    • Поиск HTML-инъекций.
    • Что такое XSS-уязвимость.
    • Поиск XSS-уязвимостей.
    • Что такое CSRF-уязвимость.
    • Поиск CSRF-уязвимостей.
  • Нагрузочное тестирование

    • Что такое нагрузочное тестирование.
    • Задачи нагрузочного тестирования.
    • Пример нагрузочного тестирования через loadimpact.com.
    • Основные метрики нагрузочного тестирования.
    • Пример нагрузочного тестирования через pro.loadstorm.com.
  • Тестирование UI, UX, юзабилити

    • Что такое UI и UX.
    • Метрики тестирования для UX.
    • Простое UX-тестирование интерфейса.
    • Методы проведения UX-тестирования.
    • Составление требований UX.
    • Составление карты приложения как один из показателей UX.
  • Приемочное тестирование

    • Что такое приемочное тестирование. 
    • Отличие приемочного тестирования от функционального.
    • Что проверять во время приемочного тестирования.
    • Составляем план приемочного тестирования.
  • Курсовая работа по тестированию веб-приложений

  • Тестирование мобильных приложений — ТМП

    • Знакомство с приложением на Android.
    • Особенности мобильного тестирования.
    • Выбор особенностей для приложения.
    • Регистрация на ферме.
    • Особенности для карт.
  • ТМП: выбор девайсов

    • Фрагментация и device-specific bugs.
    • Признаки различия девайсов.
    • Версии ОС, производители и бюджет.
    • Подбор девайсов по версии.
    • Экраны.
    • Подбор девайсов по экрану.
    • Статистика. Подбор девайсов по статистике.
    • Эмуляторы/симуляторы, фермы и свой парк.
    • Выбор девайсов для приложения.
  • ТМП: Android 1

    • Android SDK и Android Studio.
    • Установка и настройка Android Studio.
    • Установка и настройка эмулятора.
    • Установка приложения на девайс и эмулятор.
    • Настройка ADB.
    • Создание эмулятора для тестирования.
  • ТМП: Android 2

    • Функции эмулятора.
    • Скриншоты и видео.
    • Что такое GPS.
    • Работа с GPS в эмуляторе и реальном приложении.
    • Сторонние эмуляторы.
    • Функции режима разработчика.
  • ТМП: Android 3

    • Функционал ADB.
    • Логи и уровни логирования.
    • Просмотр логов: AS и adb.
    • Monkey testing и самостоятельный запуск.
  • Курсовая работа по тестированию мобильных приложений

  • Введение в автоматизированное тестирование

    • Автоматизация тестирования.
    • Задачи автоматизации тестирования.
    • Необходимый набор знаний для автоматизации.
    • Selenium IDE — автотесты без программирования.
    • Проектирование тест-кейсов.
  • Введение в программирование

    • Первый проект и программа.
    • Изменения для первой программы.
    • Типы переменных.
    • Работа с типами переменных.
    • Условные выражения.
    • Практика на условные выражения.
    • Циклы.
    • Область видимости.
    • Практика на циклы.
    • Массивы.
    • Работа с массивами и циклами.
  • Введение в ООП

    • Что такое ООП и какие у него возможности.
    • Создание класса.
    • Создание объекта класса.
    • Статические методы класса.
    • Модификаторы доступа.
    • Наследование классов.
    • Полиморфмизм в ООП.
    • Инкапсуляция.
  • Тестовый фреймворк на примере JUnit

    • Понятие фреймворка.
    • Установка Maven и JUnit.
    • Простой тест на JUnit.
    • Предусловия и постусловия JUnit.
    • Типы assert.
  • UI-тесты: простые тесты для веб

    • Понятие Selenium и запуск сервера.
    • Обзор драйверов для браузеров.
    • Capabilities для веба.
    • Открытие страницы.
    • Локаторы: xpath-локатор, css-локатор.
    • Первый UI тест: переход по URL и поиск элемента.
    • Клик элемента.
  • UI-тесты: сложные тесты для веб

    • Паттерн PageObject.
    • Ожидание элемента.
    • Составление PageObject-класса.
    • Работа с фокусом.
    • Ожидание URL, работа с редиректами.
    • Универсальный метод: выполнение кастомного JS.
    • Сложный Selenium-тест.
  • UI-тесты: простые тесты для Android и iOS

    • Установка Appium Desktop.
    • Запуск эмулятора Android.
    • Capabilities для Android.
    • Простой тест для Android.
    • Запуск симулятора iOS.
    • Capabilities для iOS.
    • Простой тест для iOS.
  • UI-тесты: сложные тесты для Android и iOS

    • Ожидание и получение элемента.
    • Тест на sendKeys.
    • Тест на touch.
    • Тест на swipe.
    • Тест на scroll.
    • Тест на background приложения.
  • Работа с CI

    • Понятие CI и возможности.
    • Виды CI и их отличия.
    • Установка консольного Appium и Jenkins.
    • Запуск тестов для веб.
    • Настройка билда для автозапуска Android и iOS.
  • API тесты

    • Понятие API и REST API.
    • Тестирование с помощью CURL.
    • Понятие Postman и установка.
    • Автоматизация с помощью Postman.
    • Автоматизация с помощью библиотеки Rest Assured.
    • Тест для API на Rest AssuredI.
  • Нагрузочные тесты

    • Нагрузочное тестирование и стресс-тестирование.
    • Установка JMeter.
    • Простой тест на JMeter.
    • Сложный тест на JMeter.
  • Курсовая работа по автоматизированному тестированию

  • skillbox.ru

    Половина тестировщиков — лингвисты, юристы, историки

    Onliner.by продолжает выпытывать у профессионалов из IT секреты их специальностей. Мы уже общались с сисадминами и веб-разработчиком. На очереди тестировщики. Александр уже девятый год работает в этой сфере и прошел путь от «джуниора» с гуманитарного факультета до должности «сеньора» и QA-лида. Он рассказал нам о важности английского и усидчивости, зарплатах и смене профессии.

    В тестировщики Александр пришел девять лет назад после гуманитарного вуза и работы в общепите. За это время он сменил несколько компаний. Говорит, что в IT нет проблем с местом работы, а в конце «нулевых» требования к начинающему тестировщику были совсем низкие.

    — Когда все только начиналось, необязательно было быть семи пядей во лбу. Было достаточно хорошего английского и понимания работы с компьютером. Многие компании брали без какого-то профильного образования. Профильным мог быть какой-нибудь мехмат, РТИ, но там-то конкретно тестированию не учили.

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

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

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

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

    — Это достаточно скучно и монотонно, если не любишь такую работу. Когда растешь, тебе предлагают взять на себя дополнительные обязанности, управление командой тестировщиков, составление тестовой документации. Для «сеньоров» уже добавляется какая-то отчетность перед клиентом, построение тестовых стратегий.

    — От чего зависит карьерный рост тестировщика?

    — Многое зависит от стечения обстоятельств. Ты можешь быть классным тестировщиком, абсолютно трезво мыслящим… Но если ты застрянешь в компании, которая не заинтересована в твоем росте, которая хочет оставить на конкретном проекте, потому что ты здорово работаешь и больше некому… То ты вряд ли сильно вырастешь. Но ты и не привязан намертво к одной компании. Ты можешь попросить перевода на другой проект или даже уйти из компании. Главное, чтобы было желание развиваться.

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

    — Да и те люди, которые тестируют игры… Вряд ли им слишком весело. Они ведь там не играют весь день. Могут просто тестировать локализацию, логику игры, выполнять нагрузочное тестирование.

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

    Если тестировщик будет думать исключительно как пользователь, он может упустить некоторое количество дефектов. Допустим, пользователю не придет в голову ввести в поле ввода заведомо неверный символ.

    — Какими знаниями должен располагать тестировщик?

    — Все зависит от ситуации. Конечно, на собеседовании наниматель хочет увидеть универсального солдата. Как в анекдоте про собеседование водителя фуры, от которого требуется понимание вождения болида «Формулы-1». Все хотят заполучить в команду уникального человека.

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

    — Многие говорят о высоких требованиях к английскому языку. Насколько важен уровень Intermediate?

    — Наверное, это все-таки «мастхэв». Абсолютное большинство компаний в Беларуси ориентируются на зарубежного заказчика. Многие работали на российского заказчика, но после коллапса российского рубля таких стало значительно меньше.

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

    — Может ли тестировщик со временем эволюционировать в другую профессию?

    — Знаю достаточно примеров, когда тестировщики становились разработчиками. Дойдя до стадии «сеньора», достигнув потолка, задаешься вопросом, куда двигаться дальше. И тут два варианта: изучать техническую сторону проектов или идти в менеджмент. Можно и в свой стартап податься. Все зависит от человека.

    Потихоньку «ручной» тестировщик в своем изначальном виде вымирает. Он не знает языка баз данных, того же HTML, чтобы лучше понять, откуда растут ноги ошибки. Нужно шагать в ногу со временем, постигать новые знания.

    Да, бывают и те, кто спустя пару месяцев хлеба тестировщика уходит из этой сферы. Для полного «джуниора» это ведь еще не та зарплата, за которую стоит держаться. А работа довольно монотонная и требовательная, несмотря на бонусы по медстрахованию, оплате бассейнов, спортзалов.

    — Есть ли дефицит тестировщиков на рынке труда и на какую зарплату может рассчитывать хороший «джуниор»?

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

    «Джуниор», наверное, может рассчитывать на $400—450. Притом у многих компаний хотя бы раз в год проходит пересмотр зарплат. Хороший специалист, который выполняет свои задачи и может взять какие-то дополнительные активности, может рассчитывать на надбавку в $150. Это, конечно, примерные цифры, которые зависят от компании и руководства.

    Читайте также:

    Перепечатка текста и фотографий Onliner.by запрещена без разрешения редакции. [email protected]

    tech.onliner.by

    «Нужно быть ленивым, чтобы стать хорошим тестировщиком» / Binary District corporate blog / Habr

    С тестированием связано много стереотипов: к нему относятся как к быстрому старту в IT с перспективой высокой зарплаты, но не видят в этом серьезной профессии. Кажется, что тестирование — сплошная рутина, где нет места творчеству и реализации собственных идей.

    Вместе с руководителем отдела QA/QC в Redmadrobot и куратором нашего курса Software Testing Marishunya_QA мы разобрались, какими навыками нужно обладать тестировщику, куда можно развиваться в тестировании, с чем на самом деле связана текучка кадров и почему даже хорошим программистам не следует брать на себя обязанности тестировщика.

    Чем занимается отдел тестирования?


    Многие говорят, что тестировщик должен «сломать продукт» — найти уязвимость, которая сделает использование приложения невозможным. Это в корне неверно. Тестировщик должен рассмотреть систему со всех сторон, подумать, как может себя повести приложение в различных ситуациях, проверить «защиту от дурака» — что будет, если ввести вместо фамилии числа, например.

    Если говорить о мобильных приложениях, многим кажется, что тестирование ограничивается поворотом экрана, то есть стандартными сценариями использования. Инженер в процессе тестирования задается вопросом: «На что новая фича может повлиять? В каких ситуациях что-то может пойти не так?». Возьмем интернет-магазин: программист реализует функцию скидки по промокоду. Если он станет сам проверять, то войдет в корзину, допустим, через главное меню — убедится, что все работает, и не подумает, что это можно сделать еще тремя способами, для которых тоже надо прописать вызов функции. Тестировщик же должен идти по пути всех пользователей, написать тест-кейсы по нескольким сценариям и потом к ним возвращаться. Поэтому отдел тестирования сопровождает продукт на всем протяжении его разработки и находится в центре V-образного жизненного цикла программного обеспечения.

    Тестировщик должен знать бизнес-требования и технические нюансы, поскольку тестирует как спецификации, так и use cases; ему также нужно наравне с другими членами команды выставить свои оценки, чтобы правильно спланировать delivery, иногда пнуть разработчика, потому что в конце спринта project-менеджер придет в отдел QA/QC, чтобы спросить протестировано ли приложение.

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

    QA и QC: в чем разница?


    В России путают понятия Quality Assurance (обеспечение качества) и Quality Control (контроль качества). Часто можно встретить схематичное изображение, где внутри QA находится QC, а внутри QC — само тестирование.

    Гораздо правильнее изобразить так:

    На самом деле QA и QC — разные вещи и они идут параллельно друг другу. Простому тестированию, грубо говоря, можно научить практически любого: посадить за стол, дать бета-сборку приложения и сказать: «Проверь, как это работает». QC — это инженер, который знает подходы, видит продукт вживую, разрабатывает стратегию тестирования и знает основные принципы, то есть контролирует качество самого продукта. QC работает непосредственно с разработчиками, составляет базу кейсов и организует тестирование.

    QA — человек, который обеспечивает качество не на уровне выпускаемого продукта, а всей компании в целом, то есть отвечает за процессы и обеспечивает условия для правильной работы QC, координирует отделы по ряду продуктов и составляет планы тестирования. Ответственность QA начинается с переговоров с заказчиками, работы со смежными отделами и выстраивания взаимодействий, продолжается в процессе разработки и заканчивается уже на презентации продукта. Она затрагивает не только технические, но и юридические аспекты. В компании все отделы сами по себе могут работать хорошо: сейлзы продают, программисты кодят, project-менеджеры контролируют процессы. Однако, чтобы механизм действовал без пробуксовок, взаимодействие отделов между собой было четким, а на выходе получался первоклассный продукт, нужно обеспечение качества — это и есть Quality Assurance.

    Как стать тестировщиком?


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

    Чаще всего в вакансиях для тестировщика можно встретить следующие требования:

    Главное требование к кандидату — мыслить алгоритмами и системами. Желательно иметь какой-то технический бэкграунд и знать теорию. Что такое testing, QC, QA и чем они отличаются? Какие есть виды тестирования и как их комбинировать? Что такое тест-дизайн, тест-кейс, тест-план? Надо знать хотя бы один объектно-ориентированный язык программирования, основы баз данных, клиент-серверной архитектуры и работы в различных ОС.

    Если раньше с этим были проблемы, то сейчас в интернете полно специализированных ресурсов, как например форум на Software Testing. Если говорить о книгах, то ниже список литературы:

    • “Testing Computer Software”, Cem Kaner, Jack Falk, Hung Q. Nguyen
    • «Ключевые процессы тестирования. Планирование, подготовка, проведение, совершенствование», Рекс Блэк
    • «Тестирование программного обеспечения. Базовый курс», Святослав Куликов

    На рынке сейчас большая проблема с кадрами, потому что кроме технических hard skills важно иметь пытливый ум, уметь донести свою точку зрения и отстоять ее на любом уровне. Также тестировщику очень важно погрузиться в предметную область, чтобы на равных дискутировать с бизнес-аналитиками и объяснять им, почему какие-то их идеи будут работать не так. Хорошее качество для тестировщика — быть «достаточно ленивым», поскольку ленивые люди склонны оптимизировать процессы, чтобы не тратить на них в будущем лишние силы и время.
    «Обеспечение и контроль качества — что-то новое для России. Проблема состоит в непонимании цели и задачи тестирования в целом. Создают отдел, но что с ним делать, не знают. Нет четко поставленной задачи, из-за чего отсутствует мотивация работать на результат. Семь лет назад я начинала работать в тестировании в Украине и сейчас я сталкиваюсь с таким же непониманием, с каким встречалась тогда. В России большая часть заказчиков — госсектор и банкинг со своей тяжелой и неповоротливой бюрократией. В Украине же на них приходилось только около 20% рынка, все остальные — частные компании, которые умеют считать свои деньги».

                                                                        Марина Куликова, Head of QA/QC, Redmadrobot


    Как быть тестировщиком?


    Войти в профессию просто, а вот расти и развиваться дальше намного сложнее. Если сравнивать тестировщиков с программистами, то последние по ходу своей карьеры уходят «вглубь». Тестировщик же находится в центре цикла жизни продукта, поэтому ему необходимо видеть картину в целом, иногда перехватывать функции project-менеджера и заниматься продуктовой аналитикой, то есть развиваться «вширь». Тестировщик получает много навыков из смежных направлений, зачастую плохо понимает масштабы своей области, смотрит по сторонам и уходит во что-то другое: программирование, product owner или аналитику. В итоге специалисты в области тестирования часто меняют профессию, а отделы QA/QC страдают от нехватки высококвалифицированных кадров.

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

    Больше узнать о тестировании и получить практический опыт вы сможете на нашем курсе Software Testing, где Марина Куликова расскажет о техниках тест-дизайна и как обеспечить качество вашего ПО в любых условиях.

    habr.com

    почему тестировщика нужно ценить не меньше, чем программиста / Badoo corporate blog / Habr


    Здравствуйте. Меня зовут Илья Кудинов, мне 27 лет, и я тестировщик.
    Все: Здравствуй, Илья!

    Мы уже много писали о том, как здорово мы в Badoo тестируем наши продукты. А сегодня я (внезапно!) расскажу о том, как круто тестировать ВООБЩЕ. И когда я встречаю представителей нашей профессии, которые не разделяют эту точку зрения, я всегда стараюсь открыть им глаза на истину. Например, этой самой статьёй.

    О чём она будет? Я поделюсь своим личным опытом, расскажу, как развивалась индустрия в течение шести с небольшим лет, что я за ней наблюдаю, и опишу своё видение карьерного пути тестировщика. Устраивайтесь поудобнее, настало время (неразборчиво, зачёркнуто) занимательных историй…

    Дисклеймер


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

    Если вы со мной в чём-то не согласны — добро пожаловать в комментарии. Я всегда открыт к диалогу.

    Про меня


    Моя история как тестировщика началась в 2011 году. К этому времени я уже успешно бросил учёбу в МГТУ имени Н. Э. Баумана, побывал в армии и поработал курьером техническим специалистом. После всех этих приключений я искал работу программистом, потому что кое-что в этой области умел и мне это нравилось. Но из-за отсутствия высшего образования и, мягко говоря, небольшого официального опыта работы очередь из радостных работодателей за мной не выстроилась (по крайней мере, именно этим мне объясняли отказы). Поэтому, когда мне предложили «А давай ты поработаешь у нас тестировщиком веб-сайтов, и если всё будет хорошо, мы переведём тебя в программисты», я с радостью согласился. Спойлер: всё было хорошо, но программистом меня так и не сделали.

    Всё начиналось очень скучно и обыденно. Я был единственным тестировщиком на семь программистов. Разработчики писали код на локальных машинах, скидывали его на тестовый сервер, просили меня его там потестировать, а потом вручную заливали код на продакшн (я наивно полагал, что все так делают). Что-то заливали на прод без моего ведома ( «Забыл сказать, извини!» ), что-то делали сразу на проде по требованию менеджмента. В общем, тихий ужас.

    Спустя несколько недель я узнал про существование систем контроля версий. Мир перевернулся. Несколько людей могут работать над одним и тем же кодом, и это будет УДОБНО! Я прожужжал все уши начальнику и добился установки SVN. Всего через месяц после этого мы начали работать в ветках (!), заливать изменения на продакшн организованными протестированными пачками (!!) и даже заимели какое-то подобие расписания релизов (!!!). Когда я смотрел на это всё, у меня начало зарождаться ощущение, что разработка и тестирование — это не хаотичный процесс, у всего этого может быть какая-то организация. Почитать интернеты? Вы что, я был молод и горяч, мне было не до этого.

    Итак, помимо тестировщика, я стал ещё и релиз-инженером. Работа стала более интересной и менее топорной. Из-за снижения уровня хаоса у меня появилось больше свободного времени, и я стал интересоваться, что же это за зверь такой — «Автоматизированное тестирование». Нашёл в интернете информацию о только-только вышедшем Selenium WebDriver, и мои глаза снова полезли на лоб: можно заставить программу ТЫКАТЬ КНОПОЧКИ НА САЙТЕ ЗА ТЕБЯ??? Воображение рисовало идиллическую реальность, в которой человеку не нужно заниматься регрессионным тестированием (нет, этого термина в тот момент я не знал). И я тут же начал тратить всё свободное время на разработку тестов. Честно говоря, написаны они были ужасно, но свою функцию выполняли.

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

    Но представитель менеджмента, скучающим взглядом окинув возделанные мною поля, сказал: «Да вроде бы и безо всей этой мишуры всё нормально было, зря только время тратили».

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

    Я начал снова искать работу. Разуверившись в тестировании, опять стал смотреть в сторону программирования. Даже успел получить оффер на позицию младшего С-разработчика в одной брокерской фирме… А потом мне позвонили из Badoo.

    Про Badoo я впервые услышал буквально за несколько месяцев до этого — на мастер-классе Алексея Рыбака на DevConf 2012. Компания тогда моментально встала для меня в один ряд с Google и Facebook. Мне казалось, Badoo — это что-то невероятно крутое, куда я, простой смертный, никогда не попаду. Поэтому на собеседование я согласился исключительно ради опыта. Я ни на что не рассчитывал — просто излил Илье Агееву всю свою фрустрацию по поводу того, чего я хотел добиться и чего меня лишили. А через несколько дней я уже стал частью этой компании, которую, к слову, всем сердцем люблю по сей день.

    «А как же твоё желание быть программистом?» — спросите вы. С ним всё в порядке. В Badoo я занимаюсь разработкой систем автоматизации тестирования и оптимизации рабочих процессов. А в свободное время потихоньку разрабатываю компьютерные игры. Это моё хобби, дело для души. Нет, идти работать программистом мне больше не хочется.

    Про индустрию


    В первые дни работы в Badoo я испытывал культурный шок. И дело вовсе не в катающихся по офису на самокатах и кричащих во всё горло разработчиках. Хорошо, не только в них. А ещё и в том, что здесь старались организовать, оптимизировать и автоматизировать каждый шаг. Я подумал: «Так вот как должно быть!» — и всеми силами старался соответствовать: участвовал в разработке процессов и средств тестирования, неустанно искал места, где можно что-то улучшить.

    А потом я начал ездить и рассказывать о наших решениях на конференциях. Боялся, что для всех всё будет очевидно — ведь все вокруг тестируют так же круто, как мы в Badoo! Но на деле…

    Внушительная часть российских компаний, а особенно IT-департаменты крупных неайтишных компаний, видели процесс тестирования примерно так же, как мои предыдущие работодатели. Вопросы после докладов ставили меня в тупик.
    «А как вы заставляете разработчиков писать тесты?»
    «Как это, вы можете отложить релиз фичи? Вот прям достаточно баг найти?»
    «Автотесты вы пишете сами? Если вы умеете программировать, почему вы не программист?»

    Проблема была в первую очередь в восприятии профессии тестировщика в нашей стране. Стыдно сказать, я тогда даже не любил слово «тестировщик» — считал, что оно приближает меня к тому образу низкоквалифицированного работника, который представляют себе консервативные бизнесмены. Я предпочитал претенциозное «QA-инженер».

    Я и мои коллеги год за годом старались донести одну и ту же мысль: тестировщик — это не wannabe-программист, тестировщик — это полноценная специальность. Она не проще программирования. Она не сложнее. Просто это совершенно другое занятие. Оно требует других навыков. Оно требует высокой квалификации. И опытный тестировщик — не менее ценный (и редкий) кадр, чем опытный разработчик. Путь тестировщика не заканчивается на бездумном клацании кнопок и следовании инструкциям — он с него только начинается.

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

    Про путь тестировщика


    Карьера тестировщика — история развития технических, личностных и многих других навыков. Как и в любой другой профессии, да. Сразу хочу сказать: я не считаю движение от ручного тестировщика до автоматизатора путём развития. Навыки автоматизации важны и полезны любому тестировщику, но это лишь вариации должности, а не прямая эволюция. Итак, приступим.
    • Уровень 0. Не тестировщик. На этом уровне находится любой пользователь программного обеспечения. Казалось бы, если это не тестировщик, то зачем я его сюда добавил? А затем, что все эти люди могут выполнять часть работы тестировщика. Они могут находить баги. Не специально, они не старались, просто так вышло. Именно такого человека, на самом деле, и ожидали увидеть в должности тестировщика на моём первом месте работы. И любой специалист с этого начинает. Вот только у некоторых баги вызывают раздражение и злость на разработчиков, а у некоторых — праведный гнев и желание сделать так, чтобы в нашем мире багов больше не было. Из последних и рождаются начинающие тестеры.
    • Уровень 1. Почти тестировщик. Человек, которому доверили работу тестировщика и который пытается её выполнять. Не просто пользуется приложением, а настырно им пользуется. Иногда даже нажимает на одну и ту же кнопку несколько раз. Он всё ещё не обладает никакими навыками, в его действиях нет никакой системы — есть только желание найти баг. Либо чтобы не уволили с работы, либо из врождённой ненависти к несовершенствам — так сразу и не скажешь.
    • Уровень 2. Тестировщик. Понимает, что он делает. Может быть, прочитал пару книжек об основах тестирования. Берясь за каждую новую задачу, может построить план своих действий (либо прочитать документацию и следовать ей). Цель постепенно смещается от «найти какой-нибудь баг» к «контролировать качество продукта». Примерно на этом уровне я находился в свои лучшие дни на предыдущем месте работы.
    • Уровень 3. Продвинутый тестировщик. Действительно понимает, что он делает. Прекрасно знает проект и может проанализировать влияние на него тех или иных изменений. Может оценить, насколько тестируемый функционал соответствует остальному проекту не только в плане качества, но и в плане UX и прочих важных вещей. Может не только найти баги, но и предупредить возникновение ошибок в планировании и дизайне того или иного функционала.
    • Уровень 4. Инициативный тестировщик. Он не просто работает в организованной среде и процессах — он старается их улучшить. Цель из «контроля качества» превращается в «обеспечение качества». Развитие и разработка средств оптимизации и автоматизации, бесконечные идеи об улучшении рабочего процесса — вся эта прелесть начинается где-то здесь.
    • Уровень 5. Профессиональный тестировщик. Бессовестно и беззастенчиво располагаю себя на этом уровне. Понимание используемых на проекте технологий позволяет принимать решения и разрабатывать план тестирования не только по описанию задачи, но и по её решению. Иногда для обнаружения ошибок прочтения кода и списка изменений бывает более чем достаточно. Тестировщик начинает видеть опутывающие проект связи, о которых он ранее и не подозревал.
    • Уровень 6. Гуру-тестировщик. Как вы можете заметить, квалификация предыдущих уровней сильно завязана на проект. Переходя в другую компанию, а тем более на другой стек технологий, обычный тестировщик теряет часть своего профессионализма. Её придётся восстанавливать. Гуру-тестировщики же смотрят на вещи с более высокой точки. Они могут в кратчайшие сроки разобраться с любой системой, найти как явные, так и скрытые связи между компонентами за счёт своего опыта и понимания работы IT-систем (и IT-специалистов). Волшебные люди. Вот бы мне так.

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

    Про навыки хорошего тестировщика


    «Наверное, достаточно прочитать десяток известных книг от именитых тестировщиков!» Не-а, вообще ни разу не согласен.

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

    А вот те определяющие качества, которые вижу я:

    • Любовь к тестированию. Да, к тестированию вообще. Не нужно считать тестирование побочным занятием в IT, не надо мечтать сбежать в разработку или руководство — надо в первую очередь получать удовольствие от работы. «Это относится вообще к любой специальности, спасибо, кэп!» — скажете вы и будете правы. Однако это не делает данный пункт менее значимым.
    • Любовь к проекту. Вы не будете радеть за качество проекта, на который вам наплевать. Даже если вы будете исправно делать свою работу (деньги же надо как-то зарабатывать), вы будете закрывать глаза на замеченные вне своего компонента недостатки («Не моё дело, да и вообще проблема на вашей стороне»). Вы не будете предлагать улучшения и проявлять инициативу («Если полить г**но одеколоном, оно будет пахнуть как г**но под одеколоном!»).
    • Знание проекта. Очень красивая кнопка! Прям как в ТЗ написано! И делает она всё, что от неё требуется, замечательная кнопка! Очень жаль, что она выглядит совсем не так, как все остальные кнопки на сайте, ломает шесть критических фич и вызывает Сатану в профиле пользователя. Но откуда мне было про это знать?!
    • Понимание технологий проекта. Нет, не обязательно иметь возможность самостоятельно переписать весь проект с нуля, только лучше. Но хотя бы в общих чертах понимать, КАК работает то, что ты тестируешь, просто необходимо. Это позволяет находить неочевидные баги, делать подмены кода для воспроизведения тех или иных кейсов и видеть дополнительные зависимости внутри проекта.
    • Соблюдение баланса между качеством и скоростью. Качество не бывает абсолютным. Каждая единица времени, которую тестировщик проводит за задачей, теоретически приближает её качество к асимптоте в 100%. В какой момент нужно остановиться? Всё зависит от проекта. Если на вашем софте будут летать самолёты с сотнями пассажиров, не стоит жалеть на тестирование ещё час-другой. А если вы разрабатываете проект с несколькими релизами в неделю и возможностью доставлять патчи пользователям за секунды, можно остановиться и раньше. Нет, я не поощряю выпуск багов на продакшн — просто скорость развития проекта иногда бывает важнее. Можно прочитать это качество как «Умение ориентироваться в приоритетах бизнеса».

    Совсем же не необходимыми я вижу следующие часто приписываемые тестировщикам качества:

    • Перфекционизм. Ненавидеть баги и несоответствия — это хорошо. Зацикливаться на этом — плохо. Будет страдать скорость тестирования, а требования менеджера выпустить недотестированный функционал будут вгонять в депрессию. Тестировщики софта для самолётов, не слушайте меня, будьте перфекционистами! Пожалуйста.
    • Любовь к бюрократии. Ах, тестовая документация. О ней уже столько рассказано и написано, я и сам рано или поздно доберусь до этой темы. Сейчас же ограничусь тем, что скажу, что эффективное тестирование бывает и без подробной всеобъемлющей тестовой документации при условии наличия толковой технической документации. Честное слово!
    • Радость от нахождения бага. Нет, хвалить себя за хитровыдуманный кейс, который сломал систему, — это нормально. Любить себя тоже надо. Но это не самоцель — не нужно надеяться на ошибку в каждой попавшейся задаче, не нужно глумиться над разработчиками, которые пропустили баг, и чувствовать своё превосходство, когда вы нашли неточность в компоненте, уже проверенном вашим коллегой. Гораздо лучше радоваться тому, что задача уехала на продакшн без ошибок и в срок. Вот это — ваше настоящее достижение, даже если вы ни разу не переоткрывали задачу.

    И в заключение…


    Я люблю свою работу. Это включает в себя всё — и мои собственные обязанности, и проект, и моих дражайших коллег. Я знаю множество тестировщиков, которые испытывают те же чувства. Но знаю и много других, которые на своей позиции несчастны, по своей ли вине, или по вине руководства — неважно. А ещё знаю людей, которые хотят работать в IT, но не хотят идти в тестирование, потому что считают эту работу недостойной и неинтересной. Если хотя бы один из этих людей благодаря моей статье сможет стать счастливее и успешнее в собственных глазах, я всё это писал не зря.

    habr.com

    Профессия тестировщик. Описание профессии. Карьера в ИТ. Работа в ИТ

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

    Контроль за качеством ПО — важный этап в работе над проектом, поэтому поиском багов занимается целая команда тестировщиков. Одни подготавливают тесты, другие анализируют их полноту, логичность и соответствие требованиям, третьи, собственно, тестируют. Руководитель группы (Test Manager) следит за выполнением графика, оценивает сроки, даёт указания сотрудникам. Он больше управленец со знанием специфики программирования. С небольшими по объёму заданиями справляется и один тестировщик, причём работать он может удалённо.

    ТестировщикТестировщик знает ответ на три вопроса: что не работает? что работает? и что работает не так, как было задумано?

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

    Если ты усидчивый, терпеливый, ответственный, коммуникабельный, обладаешь критическим складом ума и аналитическими способностями, присмотрись к этой профессии. Обеспечение работой Test Engineer гарантировано: это молодая и быстро развивающаяся специализация. Место для тестировщика найдётся в ИТ-компаниях, в независимых группах тестирования, в организациях, имеющих собственные системы автоматизации. Карьерный рост и развитие в этой профессии возможны в трёх направлениях: далее совершенствовать мастерство тестировщика, стать QA Automation engineer (программист и тестировщик в одном лице), уйти в управленцы (Test Manager, Project Manager).

    ТестировщикПрежде чем попасть на рынок любой продукт появляется сначала в руках Test Engineer

    Помни, знание английского обязательно. Куда поступать, чтобы получить профессию тестировщика? В БГАС после 9 классов. Или для начала стать программистом (эту специальность получишь во многих колледжах и вузах — БГУ, БГУИР, БНТУ, БГТУ, БарГУ, ВГТУ, БрГТУ, ПГУ, БТЭУ, ГрГУ имени Янки Купалы и др.) Или приходи на курсы Адукар «Тестирование ПО» с последующим трудоустройством в компании-партнёры.

    Предварительно вникнуть в суть работы тестировщика поможет следующий курс лекций.

    Перепечатка материалов с сайта adukar.by возможна только с письменного разрешения редакции. [email protected]

    Тестировщик

    adukar.by

    Отправить ответ

    avatar
      Подписаться  
    Уведомление о