Бизнес требования для тестировщиков

Введение

Требования – это первое, на что смотрит команда проекта, это фундамент для проектирования и разработки продукта. Допущенная в документации ошибка или неточность может проявиться в самый неподходящий момент. Очевидно, что гораздо проще устранить дефект в паре строк требований, чем позже «перелопачивать» несколько сотен (или даже тысяч) строк кода.

Тестирование требований направлено на то, чтобы уже на начальных этапах проектирования системы устранить максимально возможное количество ошибок. В перспективе, это позволяет:

• значительно снизить итоговую стоимость проекта;
• улучшить качество продукта;
• сохранить нервы всей команде.

Отношение к тестированию требований на проектах

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

Тестировщик с нуля / Урок 26. Как тестировать требования? Тестирование требований

1. Группа А: лучшие практики в деле

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

Вопросы сводятся к минимуму.

2. Группа Б: успеть все

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

3. Группа В: все усилия на разработку

Если указаны требования трехлетней давности – ты счастливчик, даже если этот функционал менялся уже 3 раза; у команды есть хоть какое-то понимание, как должна работать система. Большую же часть требований, раскиданных по чатам, приходится долго и упорно их искать (при этом со временем и сообщения из чата теряются, особенно при использовании бесплатной версии Slack).

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

Тестировщик с нуля / Урок 4 / Тестирование требований

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

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

Параметры тестирования документации

1. Четкость и ясность

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

Вы начали читать требования, и уже с первых строк у Вас возникает масса вопросов к автору (например, «Каков ожидаемый результат после нажатия на эту кнопку?» или «Что будет, если я отменю заказ?»). Это плохо. После прочтения документации не должно быть вопросов. Совсем. Требования – это как свод законов для продукта, а законы не допускают двусмысленность, «воду» и неточности.

Документация должна давать предельно ясную информацию о том, как должен работать каждый отдельный модуль и весь продукт в целом. К сожалению, после прочтения большинства требований остается целый ряд вопросов.

Пример. В требованиях было записано: «В поле «Имя пользователя» могут быть введены буквы и цифры». Разработчик начал выяснять у аналитика, какие именно буквы (кириллица, латиница или арабские) и какие цифры (целые, дробные, римские) имеются в виду. После уточнения требований разработчик реализовал функционал согласно комментариям аналитика. Задача перешла в тестирование.

Тестировщик не понимал, по каким критериям проверять данное поле, и тоже начал расспрашивать аналитика.

Последствия:

• затраченное время нескольких членов команды;

• несовпадение итогового и изначально планируемого функционалов.

Как тестировать:

• если у Вас после прочтения требований остались вопросы – значит, необходима доработка;
  если разработчики часто уточняют детали в чатах – это плохой знак.

Дальнейшее («более глубокое») исследование требует гораздо больших временных затрат.

2. Актуальность
Необходимость поддержания актуальности требований кажется очевидной. Однако, на некоторых проектах требования не обновляются месяцами, а то и годами. Это может быть связано с тем, что в штате нет аналитика, а у исполняющего его обязанности сотрудника просто не хватает времени. Случается и другое: требования обновляют только при наличии действительно значимых изменений, при этом различные «мелочи» в виде изменения кнопок или текстов ошибок игнорируются.

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

Другой разработчик вернул кнопки на прежние позиции согласно документации.

Последствия:

• время нескольких членов команды потрачено впустую;

• итоговая позиция кнопок не соответствует ожидаемому результату.

Как тестировать:

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

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

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

Если пользователь понимал, что в документе есть ошибки, то исправить он их уже не мог: у него была возможность только подписать этот документ. Закрытие приложения или его переустановка не помогали – при входе пользователя в аккаунт сразу отображался тот же документ на подпись.

Последствия:

• пользователь в бешенстве;

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

Как тестировать:

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

4. Возможные сценарии
В документации должны быть подробно описаны как очевидные, так и неочевидные варианты использования системы. К очевидным (позитивным) вариантам, например, можно отнести ввод корректной пары логин/пароль. К неочевидным (негативным) – ввод некорректной пары логин/ пароль или отсутствие этих данных вовсе.

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

Последствия:

• при потере связи система ведет себя некорректно (отсутствие ошибок, зависание);
• сообщения об ошибках не очевидны;

• в худшем случае возможны репутационные или финансовые потери.

Как тестировать:

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

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

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

Последствия:

• задержка разработки функционала на неделю.

Как тестировать:

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

Основные принципы тестирования требований

• тестирование требований лучше проводить до старта разработки. Для этого нужно рассчитать необходимое время на проверку и заморозить тестируемую документацию до окончания проверки;
• проводить тестирование требований могут как аналитики, так и тестировщики. Однако, для достижения лучшего результата описание и проверку требований следует поручать разным людям;
• заведение дефектов по документации ничем не отличается от заведения дефектов по продукту: баги следует заносить в систему баг-трекинга как обычно;
• в том случае, когда проверка требований ведется параллельно с разработкой, крайне желательно предупредить команду разработки о найденных дефектах (чтобы они могли вовремя исправить ошибку);
• уровень детализации требований (как и глубина тестирования) сильно зависит от уровня проекта. Нет смысла проверять время реакции на кнопку на проекте, который только запустился (если это, конечно, не относится к ключевому функционалу).

Итог

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

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

Источник: quality-lab.ru

Home

Спонсор: Compuware
Перевод: RedRoxx Technologies

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

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

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

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

Как повысить качество требований?

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

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

Как повысить качество требований?

IDC придерживается далеко не нового взгляда на процесс разработки ПО, согласно которому определение требований и тестирование выполняется одновременно. За счет чего достигается эффект?

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

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

Рыночные тенденции требуют визуализировать требования

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

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

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

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

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

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

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

Решения Compuware

Compuware присоединилась к группе поставщиков современных средств управления требованиями во втором квартале 2006 года, когда она приобрела ирландскую компанию SteelTrace. Будучи уже хорошо зарекомендовавшей себя в сфере тестирования, компания очень быстро интегрировала приобретенный продукт со своей линейкой инструментов для тестирования QACenter и переименовала SteelTrace в OptimalTrace (в 4-м квартале 2006).

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

Проектные шаблоны обеспечивают соблюдение корпоративных стандартов, которые, в свою очередь, нацелены на поддержание процессов анализа, их качества и скорости выполнения.

Настраиваемый словарь терминов обеспечивает однозначное понимание терминов всеми участниками процесса.

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

В Optimal Trace можно видеть все изменения, а также видеть влияние изменений на связанные требования.

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

Продукт интегрируется как с родными продуктами Compuware, так и со сторонними решениями в области тестирования и UML-моделирования. Это облегчает управление тестированием, технический дизайн и генерацию кода.

Кроме того, OptimalTrace автоматизирует документирование, облегчая использование и поддержку приложения.

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

Интеграция с QACenter способствует использованию тестирования, основанного на оценке рисков, за счет связи тестов с требованиями; обеспечивает прозрачность и автоматизацию процесса управления тестированием — выполнение тестов, результаты выполнения, регистрация дефектов, отчетность.

Compuware всегда сопровождает свои продукты описанием процесса, т.е. предоставляет шаблон действий, в данном случае, от определения проектных требований до формального принятия их реализации. На высоком уровне процесс выглядит так: в OptimalTrace заносятся проектные требования, из которых затем автоматически генерируются тестовые требования с учетом всех альтернативных сценариев и иерархии требований. Далее эти тестовые требования импортируются в QACenter, где они покрываются тестовыми скриптами. После выполнения скриптов те требования, для которых тесты пройдены успешно, являются реализованными.

IDC предполагает, что приобретение SteelTrace усилит позиции Compuware на рынке продуктов для ИТ-подразделений компаний.

Резюме

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

Объединение бизнеса и ИТ в совместной работе над требованиями — ключевой фактор успеха в условиях высокой конкуренции, усложнения и глобализации рынка.

Источник: www.software-testing.ru

Профессия тестировщик: какая зарплата у тестировщика и что нужно уметь?

Тестировщик или QA-инженер (от английского quality assurance — «обеспечение качества») —специалист, который тестирует различные программы, приложения и сервисы, чтобы убедиться, что они работают корректно, выявить возможные ошибки и уязвимости в защите.

Время чтения: 13 мин.

Тестировщик — обзор профессии

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

Вот как выглядит работа тестировщика:

1. Изучение документации по продукту: инструкции и рекомендации от разработчиков и продуктовых аналитиков.
2. Составление тест-кейсов для тестирования: какие функции нужно проверить и в какой последовательности, с учетом всех возможных сценариев поведения пользователя.
3. Тестирование.
4. Сбор и анализ полученных результатов: ошибки, сбои, некорректная работа, уязвимости.
5. Оформление полученных результатов в виде отчета с рекомендациями для разработчиков.

Тестирование проводят двумя способами:

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

И ручное, и автоматическое тестирование может быть поведенческим или по методу «черного ящика».

Поведенческое тестирование учитывает технические требования и условия, при которых нужно использовать продукт. Для этого он изучает инструкции от разработчиков и проверяет, все ли работает так, как в них написано.

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

Среди тестировщиков есть разные специалисты:

• Тестировщики ПО.
• Тестировщики веб-приложений.
• Тестировщики мобильных приложений.
• Тестировщики игр.

По тому, какие именно параметры тестируются, различают:

• Security-тестировщики — тестируют сервисы и ПО на возможные утечки данные и устойчивость к хакерским атакам;
• Performance-тестировщики — тестируют продукты при возрастающих нагрузках.
• Usability-тестировщики — тестируют сервисы на удобство использования.

Плюсы и минусы профессии тестировщика

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

• Высокая конкуренция.
• Более низкие зарплаты (по сравнению с другими профессиями в отрасли), особенно на старте.
• Достаточно монотонная работа, в которой не так много творчества.
• Есть жесткие рамки — по срокам, последовательности действий и результатам работы.

Какие качества, навыки и инструменты необходимы тестировщику?

Вот личные качества, которые играют важную роль для этой профессии:

• Аналитический склад ума. Вам придется работать с большими объемами информации, разрабатывать четкую последовательность действий и анализировать результаты.
• Внимание к деталям. Тестировщик должен обращать внимание на малейшее отклонение от того, каким видят продукт разработчики и проверять любые возможные варианты.
• Усидчивость. Приходится выполнять большой объем рутинных операций и тщательно следить за малейшими ошибками.
• Критическое мышление. Даже если продукт выглядит идеальным, важно убедиться в этом на практике.
• Ответственность и системный подход. Важно соблюдать регламенты и сценарии работы, добиваться поставленного результата и предоставлять итог своей работы в виде четких и понятных рекомендаций. Не просто найти ошибку, а подробно описать, при каких обстоятельствах и почему она возникает.
• Эмпатия и внимание к людям. Это нужно, чтобы абстрагироваться от сугубо технических сценариев и инструкций и понять, как действует обычный человек, удобно ли ему будет работать с продуктом, с какими сложностями он столкнется.
• Навыки коммуникации. Нужно уметь общаться и убеждать разработчиков и других участников команды в вашей правоте и необходимости внести правки.
• Стремление к саморазвитию. В профессии тестировщика важно постоянно осваивать новые методы и технические приемы, чтобы хорошо разбираться в продукте, его слабых и сильных сторонах.

Технические навыки и инструменты, которыми должен владеть тестировщик:

• Основы программирования и редакторов кода: VScode, Pytest, Gitlab, XML, CSS, JavaScript.
• Знание ключевых систем управления проектами в разработке — Waterfall, Scrum и Kanban.
• Представление о том, как создаются пользовательские интерфейсы — в плане разработки, UX UI-дизайна.
• Работа с системами баг-трекинга (обнаружения ошибок): Redmine, Jira.
• Знание инструментов мониторинга HTTP/HTTPS-трафика.
• Навыки работы с базами данных — такими, как MySQL, PostgreSQL, MS SQL.
• Навыки составления тест-планов и тест-кейсов с помощью TestRail, Zephyr, TestLink и других сервисов.
• Знание особенностей всех популярных ОС и браузеров — мобильных и десктопных.
• Представление о клиент-серверной архитектуре.
• Умение работать с системами контроля версий — например, CVS или Git.
• Умение работать с системами автоматического тестирования веб-приложений, тестирования нагрузки и функционала — такими, как HP-UFT, Sahi, Selenium.
• Хороший технический английский.

Какова зарплата в профессии тестировщика и востребованность профессии

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

• HeadHunter — более 4 500.
• Trud.com — около 90 000.

Однако и отбор достаточно жесткий: придется выполнить тестовое задание и подтвердить свои навыки.

Средняя зарплата тестировщика в регионах — от 35 до 50 тыс. рублей, в Москве — 80–150 тыс., на топовых позициях — около 300 тыс.

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

Как получить профессию тестировщика

Согласно опросу на Software-Testing.ru, в тестировщики приходят из самых разных сфер: ИТ-администраторы, программисты, дизайнеры, юристы, экономисты. Проще всего тем, кто уже знаком с основами программирования и веб-разработки, остальные могут научиться с нуля. Однако после стажировки или самостоятельного обучения вы можете рассчитывать максимум на позицию junior, и то — при большом везении. Это значит, что вам придется вручную проводить тестирование по готовым тест-планам — самая рутинная и монотонная работа.

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

Профессия тестировщика — с чего начать

Вот подборка полезных книг, которые помогут новичкам:

1. «Как тестируют в Google», Джеймс Уиттакер, Джейсон Арбон и Джефф Каролло. «Тестирование ПО», Рон Паттон.
2. «Практическое руководство по тест-дизайну», Ли Коупленд.
3. «Искусство тестирования программ», Гленфорд Майерс, Том Баджетт и Кори Сандлер.
4. «Быстрое тестирование», Роберт Калбертсон, Крис Браун и Гэри Кобб.
5. «Agile-тестирование. Обучающий курс для всей команды», Джанет Грегори и Лайза Криспин.
6. «Дневник охотника за ошибками. Путешествие через джунгли проблем безопасности программного обеспечения», Тобиас Клейн.
7. «Автоматизация тестирования ПО», Марк Фьюстер и Дороти Грэхем.

Будущее профессии тестировщик программного обеспечения

В исследовании IDC говорится, что в 2020 рынок устройств и сервисов в рамках интернета вещей достиг $7,1 трлн. По данным App Annie за 2017 год, мы, в среднем, используем от 9 приложений в день. При этом, согласно данным TechBacon, половина пользователей ожидает, что приложение обработает запрос не дольше, чем за 2 секунды. 80% больше не воспользуются сервисом после трех ошибок. Все это говорит о том, что роль тестировщиков ПО и приложений будет только расти.

Вот главные тренды профессии в ближайшем будущем:

1. Автоматизация выходит на первый план. В будущем все тест-кейсы будут полностью автоматизированы, однако это приведет к проблемам контроля качества.
2. ИИ и машинное обучение позволят вывести автоматизацию на новый уровень: когда алгоритмы сами будут составлять тест-кейсы, проводить основную работу и анализировать результаты. Контроль со стороны человека останется, но в минимальном объеме.
3. Гибкие подходы к разработке продуктов. Помимо DevOps, Scum и Kanban появятся новые методы ведения проектов, и тестировщикам важно следить за тенденциями в этой области.
4. Слияние разработки и тестирования. В будущем разработчики и тестировщики будут связаны еще теснее, а их работа станет практически параллельной. С ростом автоматизации и внедрения ИИ-инструментов эти профессии можно будет и вовсе объединить в одну.

Источник: myacademy.ru