Тестировщик обязанности

  • автор:

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

1. Анализ документации: бизнес требований и функциональных спецификаций

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

2. Оценка и планирование тестирования

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

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

3. Разработка сценариев тестирования

На данном этапе мы описываем сценарии, по которым будем тестировать продукт. Здесь важны две темы: как определить необходимые сценарии и как их описать.

  • Для того, чтобы определить какие проверки необходимо выполнить существуют множество техник и способов. В этой статье я не буду их описывать (можно по названию найти подробное описание на WiKi), только перечислю некоторые из них:
    • Traceability matrix
    • Decision Table
    • Boundary value analysis and Equivalence partitioning
    • Pairwise Technique
    • Use-Case

Для прохождения интервью самое главное ответить на вопросы:

  1. Как планируете формировать список проверок?
  2. Как поймете насколько полно этот список проверок охватывает функционал, который необходимо проверить?

Если какими-то техниками раньше не пользовались, интервьюеру сразу будет ясно, что знания только теоретические, а вы можете легко запутаться. В этом случае обязательно разберитесь с методом тестирования граничных значений и классами эквивалентности (Boundary value analysis and Equivalence partitioning) и отталкивайтесь от функций ПО. Следите, чтобы на каждую функцию и состояние продукта был как минимум один тест. Если у функциональности сложная логика работы, то делайте проверку на каждое условие алгоритма. Также обязательно ориентируйтесь на бизнес смысл функционала, на то как ПО в реальности будет использоваться (Use-Case), создавая тест на каждый сценарий.

  • Описание сценариев тестирования или тест дизайн, также имеет множество реализаций: от использования специальных программных средств типа HP ALM до описания сценариев в Excel или Word. Здесь важно четко понимать основные параметры теста, которые должны быть всегда, вне зависимости от инструмента. Скорее всего вам зададут примерно следующий вопрос: «Как выглядит идеальный тест кейс? Из чего он состоит?». Собственно основные составляющие теста следующие:
    • Версия тестируемого ПО, ссылка на требования, автор тест кейса
    • Начальные условия, шаги для подготовке к тестированию: состояние системы, настройки среды, данные
    • Заголовок тест кейса с его основной идеей
    • Шаги тестирования, включающие: действие, ожидаемый результат, фактический результат
    • Статус тест (тут также необходимы дата выставления статуса и кто его поменял)
    • Ссылки на обнаруженные ошибки
    • Действия по возвращению системы в исходное состояние

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

4. Выполнение тестирования ПО

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

  • Smoke testing и Sanity testing – предварительная проверка системы и поставки ПО. На этом этапе наша задача убедиться, что тестовая среда настроена и работает, а полученный билд содержит необходимый функционал или изменения и с ним можно продолжать работать. Т.о. мы делаем самые основные, базовые проверки.
  • Functional & non-functional testing – основной этап тестирования, который включает в себя все многообразие проверок разных типов разобранных в разделе «3 — Базовые знания по тестированию», направленных на изменения, добавленные в рамках поставки. На этом этапе мы проводим несколько циклов тестирования, как правило более 2.
  • Regression testing – проводим цикл регрессионного тестирования и проверяем, что новые фичи и изменения не сломали текущий функционал. Тут также несколько циклов. В принципе этот этап можно считать второй фазой предыдущего блока — Functional & non-functional testing.
  • Integration & end-to-end testing – на этом этапе мы проверяем как наш модуль, система или продукт будет взаимодействовать с другими модулями, системами и продуктами. Здесь мы проверяем всю цепочку действий пользователя при работе с системой. Например, пользователь делает заявку через сайт интернет магазина, далее заявка записывается в базу, далее обрабатывается и передается в систему для закупок и т.д. В этом случае мы должны настроить необходимое окружение и проверить весь жизненный цикл заявки, даже если мы доработали только одну систему в цепи.
  • Demo testing & User Acceptance Testing – этап демонстрации ПО заказчику \ пользователям, которые в свою очередь также могут (и в идеале должны) проводить свое тестирование продукта – UAT

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

5. Подведение итогов и подготовка результатов тестирования

На этом этапе мы делаем следующее:

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

В качестве результатов и метрик тестирования мы можем использовать такие показатели как (подробнее про метрики тестирования в отдельной статье):

  • Количество открытых дефектов по уровню их критичности

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

  • Количество открытых дефектов к общему числу дефектов

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

  • Количество дефектов к общему числу тестов

Эта метрика показывает среднюю эффективность одного теста

  • Число раз, которое в среднем переоткрывался дефект

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

6. Поддержка во время установки в продуктив

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

7. Поддержка во время сопровождения продукта

  • Анализ и воспроизведение ошибок, найденных на продуктивной среде
  • Выполнения регрeсcионных проверок после исправления ошибок

Описание профессии тестировщика ПО

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

Название профессии образовано от английского слово “Test”, переводящееся как «проверка», «испытание» или же просто уже устоявшееся в русском языке «тестирование».

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

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

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

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

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

Возможные места работы

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

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

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

Плюсы

  • Перспективная, развивающаяся профессия с возможностью карьерного роста
  • Творческий, исследовательский характер работы
  • Получение практических знаний и навыков из мира IT
  • Широкие возможности для работы фрилансером
  • Возможность переквалифицироваться в программиста или другую смежную специальность
  • Высокая заработная плата

Минусы

  • В некоторых случаях работа бывает монотонной и однообразной
  • Необходимость постоянно учиться новым технологиям и заниматься саморазвитием

Обязанности тестировщика

  • Поиск, выявление и анализ ошибок в программном обеспечении
  • Разработка сценариев для тестирования
  • Разработка автоматических тестов и регулярное их проведение
  • Заполнение базы данных тестовой информацией
  • Документирование найденных дефектов для их исправления программистами
  • Контроль исправления выявленных ошибок
  • Контроль качества разрабатываемого продукта

Где учиться на тестировщика

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

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

Лучшие курсы тестировщиков онлайн

На образовательном IT-портале GeekBrains можно освоить профессию «Тестировщик ПО» всего за 4 месяца. Во время обучения предусмотрены домашние задания, общение с живыми преподавателями, контрольные и тестовые работы. После окончания обучения выдаётся именной сертификат и возможность стажировок в настоящих IT компаниях. Средняя заработная плата тестировщика по Москве и Московской области составляет 64 000р.

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

Всем пользователям нашего сайта предлагаем скидку в 10% на обучение любым профессиям. Для активации скидки достаточно нажать на баннер или перейти по ссылке — получить скидку 10% на обучение любым современным IT-профессиям.

Спешите начать обучение. Скидка на обучение профессии «Тестировщик ПО» действует для Вас всего 3 дня!

Необходимые личные качества

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

Также профессия «Тестировщик ПО» предполагает наличие терпения, целеустремлённости, усидчивости и готовности работать в команде.

Требования к тестировщику ПО

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

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

Знание технического английского языка, представление о языке SQL, знание баз данных типа MySQL и знание программ для автоматизированного тестирования (при необходимости использования) будут Вашими преимуществами на собеседовании.

Зарплата тестировщика

Новичок Специалист Профессионал
30 000 55 000 80 000+

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

Интересное видео о тестировщиках

Интересные факты о профессии тестировщик ПО

День тестировщика отмечается 9 сентября. День выбран не случайно, так как именно в этот день в 1945 году учёными Гарварда при проверке вычислительной машины был найден мотылёк, попавший между контактами и мешающий работе компьютера. Насекомое было приклеено в журнал обслуживания и помечено как первый обнаруженный баг (bug — жучок).

Похожие профессии

  • Программист
  • QA-инженер
  • SEO-специалист
  • Веб-программист

Тестирование: что, как и зачем

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

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

Зачем нужно тестирование? Тестирование решает несколько основных задач:

  • Дает уверенность в качестве конечного продукта, подтверждает что все заявленные функциональные требования реализованы, приложение им соответствует и не имеет ошибок в программном коде;
  • Подтверждает, что приложение способно выполняться во всех заявленных режимах и на всех поддерживаемых ОС или Web-браузерах корректно;
  • Гарантирует, что хранимые и обрабатываемые данные надежно защищены от постороннего доступа и «взлома»;
  • Определяет, какая максимальная нагрузка на сервер, локальную сеть, БД может быть корректно обработана приложением;
  • Позволяет убедиться в том, что пользователь может «интуитивно» использовать ваш продукт или услугу не путаясь в сложных переплетениях интерфейсов.

Различают следующие виды тестирования:

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

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

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

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

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

Вы не боитесь, что в один прекрасный день злоумышленник может испортить вашу БД или остановить работу сайта? Что Вы сделали для того, чтобы предотвратить это? Не успокаивайте свою совесть, проверьте безопасность!

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

Вы готовы к росту популярности вашего ресурса? Вы знаете, что будет, если реклама «выстрелит» и количество ваших посетителей возрастет в 10 раз? Было бы очень обидно, если бы сервер не справился с работой как раз в этот момент.

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

Достаточно ли прост и понятен ваш сайт? Каждый ли пользователь сможет разобраться, как заказать товар? А как его найти? Не уйдет ли он к вашим конкурентам, потому что их сайт простой и понятный?

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

Скачать в .doc

К списку должностных инструкций

Должностная инструкция тестировщика ПО

УТВЕРЖДАЮ
Генеральный директор
Фамилия И.О.________________
«________»_____________ ____ г.

1. Общие положения

1.1. Тестировщик ПО относится к категории специалистов.
1.2. Назначение на должность тестировщика ПО и освобождение от нее производится приказом генерального директора организации по представлению руководителя службы тестирования.
1.3. Тестировщик ПО подчиняется непосредственно руководителю службы тестирования.
1.4. На время отсутствия разработчика тестировщика ПО его обязанности выполняет другой специалист, назначенный приказом генерального директора организации, который приобретает соответствующие права и несет ответственность за надлежащее исполнение возложенных на него обязанностей.
1.5. На должность тестировщика ПО назначается лицо, имеющее высшее техническое образование и опыт работы в сфере информационных технологий от 1 года.
1.6. Тестировщик ПО должен знать:
— основные технологии построения ПО и структуры программных комплексов;
— знание операционных систем семейства Windows на уровне продвинутого пользователя;
— язык запросов SQL;
— скриптовые языки;
— принципы программирования;
— специальное ПО для автоматизированного тестирования и регистрации ошибок (WinRunner, TestComplete, TestExecute, TestRecorder);
— английский язык (как минимум — на уровне чтения технической документации);
— принципы создания тест-кейсов;
— правила и нормы охраны труда, техники безопасности, производственной санитарии и противопожарной защиты.
— локальные нормативные акты организации.
1.7. Тестировщик ПО руководствуется в своей деятельности:
— законодательными актами РФ;
— уставом организации, правилами внутреннего трудового распорядка, другими нормативными актами организации;
— приказами и распоряжениями руководства;
— настоящей должностной инструкцией.

2. Функциональные обязанности тестировщика ПО

Тестировщик ПО выполняет следующие должностные обязанности:

2.1. Разрабатывает планы, графики, методики и описания тестирования.
2.2. Моделирует ситуации, которые могут возникнуть в условиях эксплуатации программного обеспечения.
2.3. Выполняет тестирование программных продуктов.
2.4. Выполняет нагрузочные тестирования.
2.5. Составляет документацию для проведения функционального тестирования.
2.6. Участвует в проведении опытных эксплуатаций программных продуктов.
2.7. Заполняет таблицы баз данных тестовыми данными.
2.8. Анализирует результаты, полученные во время прохождения тестов.
2.9. Классифицирует выявленные ошибки и заносит их в базу данных для текущего программного продукта.
2.10. Контролирует процесс ликвидации выявленных ошибок разработчиком ПО.
2.11. Общается с разработчиками.
2.12. Консультирует клиентов.
2.13. Работает в связке с разработчиком.
2.14. Создает тест-планы, тест-кейсы.

3. Права тестировщика ПО

Тестировщик ПО имеет право:

3.1. Создавать организационно-технические условия для выполнения должностных обязанностей, предусмотренных настоящей инструкцией.
3.2. Участвовать в подготовке принимаемых решений в соответствии с должностными обязанностями, приказами и распоряжениями.
3.3. Требовать от руководства организации обеспечения организационно-технических условий, необходимых для исполнения должностных обязанностей.
3.4. Знакомиться с документами, определяющими его права и обязанности по занимаемой должности, критерии оценки качества исполнения должностных обязанностей.
3.5. Вносить на рассмотрение руководства организации предложения по совершенствованию работы, связанной с предусмотренными настоящей должностной инструкцией обязанностями.
3.6. В установленном порядке запрашивать и получать необходимые для исполнения своих должностных обязанностей материалы и информацию.

4. Ответственность тестировщика ПО

Тестировщик ПО несет ответственность за:

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

К списку должностных инструкций

Тестировщик — больше, чем профессия

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

В качестве вступления

Я никогда не собирался становиться тестировщиком — меня больше привлекала разработка. Со школьной скамьи я писал программы, которые уже обкатывались моими одноклассниками, а затем одногруппниками: мне было интересно решать задачи и оживлять вещи, а уж решением возникающих проблем и багов я занимался после того, как мне о них сообщали пользователи. К версии я приписывал минорную циферку, и… и в каком-то балансе между функциональностью и качеством программа оставалась навсегда, уступая место новым проектам и программам.
Забегая вперёд, скажу, что отчасти в этом кроется ключ к успешному ведению проектов — в нахождении баланса между затратами на разработку продукта и его качеством. Любой продукт схож с биологическим организмом, в формировании которого участвуют не один человек, а многие — прямым или косвенным образом. В формировании хорошего продукта должны участвовать все заинтересованные стороны, и каждая из них должна делать весомый вклад в общее дело. Но, к моему удивлению, тестировщики в этом отношении занимают особую нишу: во-первых, они являются связующим звеном в процессе, а во-вторых, они одни единственные из инженеров имеют право вето на выпуск версии продукта.
Обо всём об этом я узнал на первом своём месте в качестве тестировщика с неугасшими амбициями разработчика. В первую очередь, меня очаровала возможность получения доступа к управлению продуктом, власть, на которую я не особо рассчитывал. Это было здорово, что-то особенное, выше написания очередной функциональности. Во-вторых, тестировщики в силу особенностей профессии имеют большее представление о процессах и целях продукта, отчасти транслируют бизнес цели разработчикам, а результат разработчиков —руководителям. К сожалению, в мире и, тем более, в России, представление о роли тестировщика весьма сумбурное, и её значение сильно преуменьшается. А те компании, которые всё-таки находятся в тренде, стараются развить направления тестирования и управления качеством, хотя и ставят несколько завышенные цели: «найти все ошибки, снизить до минимума стоимость разработки через тестирование».
Эта статья, в первую очередь написана по мотивам общения с различными компаниями, является квинтэссенцией ответов на их вопросы. Во-вторых, обращена к начинающим тестировщикам и тем людям, которые хотят узнать о тестировании побольше с точки зрения внутренней кухни. В- третьих, базируется исключительно на моём (субъективном) опыте.

Тезис №1: Тестировщик — не обезьяна

В Android SDK входит замечательный инструмент под названием MonkeyRunner, который позволяет автоматизировать процесс тестирования Android приложений в идеале без исходного кода, без особых знаний языков программирования (лишь общего представления о скриптовых языках достаточно) и, главное — имитировать любое поведение настоящего пользователя. В итоге получается эдакая скриптовая обезьяна, которая тыкает, печатает, читает приложение. Самое то, что можно «отдать на аутсорс» машине. Для меня такое понимание тестирования в порядке вещей. Но, к моему удивлению, когда я искал работу в первый раз после своей первой должности в роли тестировщика, выяснилось, что на рынке существуют (и по сей день!) странное разделение на «ручных» и «автоматических» тестировщиков, более того, лестница грейдов и вовсе столь смешана и растянута, что диву даёшься. Не говоря уже о том, что от компании к компании одни и те же должности подразумевают разные должностные обязанности, особенно это актуально для старших должностей.
В мои должностные обязанности входило: составление тест-дизайна, тест-кейсов, стратегии тестирования (если это был назначенный на меня проект), репорт багов, проверка документации и создание тестовой документации. Это было само собой разумеющимся для меня, хотя несколько удивляло, что у западных коллег эти обязанности были разделены. На рынке же оказалось, что вполне обычным явлением считается, что дизайн пишется с помощью CTE/UML (в лучшем случае) Test Lead/Senior Tester/Test Designer. Тест кейсы (разнообразные стратегии проверки границ, интерфейсное тестирование, нагрузочное, стендовые кейсы) — Senior Tester’ы. И, наконец, существуют низшие должности «исполнителей» — Tester. В некоторых компаниях и отделах их число может доходить до 20 и более человек! Другими словами, в штате проекта числились обезьяны, в лучшем случае, обладающие навыками пользователя компьютером и каким-то продуктом.

На деле же это… несколько неправильно. Потому что тестировщик не обезьяна. Если это не так, то либо вы, как компания, выпускаете разные продукты в короткий срок, без последующей поддержки и качества, прогоняя формальные smoke-тесты, либо, что более вероятно, ваш менеджер/архитектор — баран.
Затраты на автоматизацию тестирования окупаются далеко не сразу.
Для знакомых с теорией тестирования (коих, как показывает практика, не так уж и много), вполне очевидно, что необходимость автоматизации сильно зависит от специфики проекта (его сроков, поддержки, повторяемости, и пр.). В некоторых случаях куда предпочтительнее обойтись smoke тестами и пользовательским бета-тестированием и выполнять приёмку через product owner’a, чем усложнять процессы. Так же должно быть чёткое понимание приёмки продукта: верхнеуровневая и низкоуровневая. В первом случае, внутри проекта, можно определить роли и принять продукт владельцу продукта, во втором возможно ограничиться, если допускают это требования, приёмкой самими инженерами-разработчиками с выпуском release notes. В случае, когда тестирование требуется всё-таки отдельное, то куда проще и эффективнее иметь поставленный менеджментом процесс жизненного цикла продукта и человека или команду инженеров, способных самостоятельно покрыть задачи развёртывания и тестирования продукта, т. е. людей, которые априори знают область, инструменты и методы, а не стадо обезьян, которых повесили на разработчиков или одного руководителя проекта.
Ремарка №1Как ни удивительно, но этот простой тезис зачастую сознательно нарушается. Например, для аутсорсинговых компаний это хороший способ получить дополнительные FTE. В плане бизнеса попросту выгоднее продать побольше, что-то, имеющее низкую себестоимость. В опыте моей работы на Auriga, где заказчикам предоставлялись на почасовую оплату соответствующие ресурсы в количестве десятков человек — не единичный случай. Более того, такой план хорошо покрывает цели стаффирования проекта для клиента при минимальных затратах. Несмотря на то, что нагрузка на менеджера проектов значительно возрастает, при грамотном руководстве это пусть к созданию «кузницы кадров» за счёт проекта, привязки кадров к компании (обучение и рост навыка) при сравнительно большей цене покупке специалиста с рынка, и последующая перепродажа, ротация персонала на более требовательные проекты.
Ещё одной причиной такой стратегии является возможность покупки нецелевых кадров для клиента. Так уж получается, что требования к кадрам ваших работодателей или клиентов иногда бывают недальновидны (о чём речь пойдёт ниже), и меньшими затратами для компании (по деньгам и времени) является возможность покупки фиктивных кадров. Скажем, покупка такого рода «обезьян» на проект с параметром «20 лет стажа» (но, возможно будучи весьма посредственным специалистом). Это особо актуально в системе грейдов Junior/Standard/Senior многих компаний, особенно за пределами России, где требования к стажу и реалии немного иные.
Следующей, и, на мой взгляд, главной причиной, являются риски. Постановка задач на проекте для тестирования — это покрытие определённой функциональности и действий. Зачастую процессы можно автоматизировать, особенно в отношении регулярных активностей, регрессионного тестирования, т. е. в процессе тестирования создать ферму, процесс и инфраструктуру, часто масштабируемую, портируемую и переносимую на другие продукты и проекты с минимальными издержками. Сокращение «непосредственной» работы на проекте для тестировщика ведёт к двум следующим следствиям:

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

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

Тезис №2: Тестировщик — это инженерная профессия

Из-за мешанины с обезьянами в профессии тестировщиков хватает людей, далёких от инженерной сферы, и не имеющих подчас даже соответствующего технического образования. Это действительно грустно и печально, т. к. квалифицированных ресурсов на рынке тестировщиков сегодня действительно не хватает — грамотные специалисты предпочитают уходить в разработку (в лучшем случая близкую к теме аналитику), а те, что остаются, имеют скудное представление о жизненном цикле ПО, тестировании и языках программирования.
На мой взгляд, любой тестировщик должен обладать техническими знаниями, уверенным владением и хотя бы базовыми навыками администрирования прикладных программ и популярных ОС. Кроме того, тестировщик должен иметь хотя бы базовое представление о языках программирования, уметь читать код хотя бы на интуитивном уровне, а также быстро адаптироваться к новым языкам и программам/средам. Вообще, главные особенности тестировщика — это гибкость и обучаемость. Поэтому, имея опыт в программировании и общее представление о скриптовых языках и языках высокого уровня, человек сможет обучиться и адаптироваться без особых проблем. В идеале требуется знание скриптового языка и основ языка разработки, на котором и базируется проект.
Из всего этого вытекает, что тестировщик обязан уметь работать с кодом. Хотя, в идеале, хороший процесс должен исполняться по модели чёрного ящика. Тем не менее в него, в этот ящик Пандоры, тестировщик должен не бояться заглянуть и помочь разобраться с проблемой разработчику. То есть быть как рыба в воде в системе не только багтрекера, но и контроля версий кода, и быть способным провести ревью кода.
Несмотря на то, что я в подавляющем большинстве случаев слышу мнение, что процесс ревью кода, отладки (дебаггинг) и юнит-тестирования — прерогатива исключительно разработчиков, возьму на себя смелость утверждать, что это неправильный подход. Проблема исходит из недостаточной квалификации тестировщиков и неверного управления жизненным циклом ПО. Возможно, этот подход хорошо работает в маленьких проектах по TDD, но главная сила и возможность обеспечить высокое качество продукта — разбить сферы влияния, ответственности, обеспечить принцип раздельности (dissimilarity).Это сделает процесс разработки более прозрачным, отслеживаемым и позволит скомпенсировать «эффект замыленности глаза» у разработчиков, избежать «трюков» с их стороны.
Ремарка №2В компании Liebherr Aerospace жёстко выстроены процессы и роли в компании. Чёткое следование специфичным для отрасли итеративным моделям. Тем не менее, инженерное крыло, инженерные должности называются для всех одинаково — Software Engineer. Акцент делается на том, что сотрудник в компании в первую очередь — специалист, инженер в области ПО. Значит, сотрудник должен разбираться в инженерных процессах, процессе разработки, тестирования, схемотехники и т.д. Тем не менее, среди инженеров присутствует обязательное разделение на специализацию: in Test, in Development, in Requirements, и пр.
Так как компания следует жёстко инженерным процессам с целью соблюдения высочайшего качества, каждая часть процесса разделена на независимых участников. На практике это означает, что каждый уровень требований пишется отдельным человеком (группой), дизайн другими, код пишется третьими, юнит-тестирование четвёртыми, функциональное тестирование — пятыми и так далее. При этом, чтобы не дать «заскучать» и «увязнуть» в рутине, людей в проекте стараются вращать по функциям, и, вполне возможно, даже на одном проекте, в разных итерациях инженер, по мере своих возможностей будет покрывать разные обязанности, и охватит различные этапы разработки ПО.
То, что каждый из этапов и типов разработки и тестирования должен покрывать разные люди следует из требований международных стандартов, таких как DO-178B (для авиации), EN 50128 (для железнодорожного транспорта) или ГОСТ Р МЭК 60880 (для атомных электростанций), и обеспечивает, в конечном итоге высочайшую отказоустойчивость на уровне процессов и в том числе в части тестирования ПО.

Тезис №3: Метрики — ерунда, если нет работы в команде

Во время почти каждого собеседования на должность тест менеджера можно услышать вопрос по поводу того, как соискатель собирается выстраивать процесс тестирования и какие метрики с проекта он собирается снимать, какие метрики будет использовать по отношению к себе. На самом деле, вариантов метрик — количественных и качественных — можно придумать немало, но особого смысла они не будут иметь до той поры, пока не будет в проекте эффективности в команде. В команде в широком смысле слова, т. е. как внутри отдела/команды тестирования, так и при взаимодействии с командой разработчиков и заказчиков из бизнеса.
На практике это означает, что бесполезно считать количество разработанных тестов (это метрика прогресса), найденных багов (в худшем случае) показателем эффективности команды тестирования, даже рейт регрессий, даже синтетических метрик на проекте (с использованием критериев важности и трудоймкости), не говоря уж о идиотских (но по-прежнему применяемых и для команды тестирования KSLOC\hour). Для менеджера проекта, возможно, будет неплохой метрикой CPI/SPI как KPI проекта, которая может базироваться на всех обозначенных и собранных тест-менеджером метриках. То есть, достаточно абстрактная и высокоуровневая оценка в зависимости от затраченных усилий и полученного результата. Но при условии, что команды работают как единый организм.

Для тестировщиков это означает, что они связующее, ведущее колесо процесса, которое сделает программное обеспечение работоспособным и соответствующим требованиям. В процессе тестирования это означает как само тестирование, так и предоставление теста повторяемости, документируемости, возможных проблем и решений проблемы (если это видно со стороны тестирования, если хватает квалификации), а так же перепроверку тестирования (VoV). Другими словами, задачей тестирования является как перепрогон и перепроверка всех возможных состояний, так и (в необходимом и достаточном случае) покрытие полной тест-стратегии и тест-плана (по крайней мере то, что обозначено в Quality Gates), вынесение багов и их разрешение через разработчиков ПО и спецификации. Т. е., с момента проверки и обнаружения бага ответственность на нём не «перекидывается» на разработчика, а сопровождается тестировщиком до его разрешения. Грубо говоря, тестировщик отвечает за баги, а разработчик — за фичи.
Тут мы подошли к ключевым различиям между тестировщиком и разработчиком, кои в моей статье получаются очень близки и похожи. Тем не менее, по стилю работы разработчики обычно либо перфекционисты, либо «фичеделы» (которые любят кодить ради кода, функциональности и алгоритмов); тестировщики же — либо педанты, либо автоматизаторы (стремящиеся автоматизировать автоматизацию). Поэтому в проекте тестировщик знает, как правильно сделать, а разработчик — как именно.
Исходя из этого, повторюсь, что главное — это результат, зависящий от единой команды, а не только от метрик в одном прогрессе, скажем, разработки дизайна. И где процесс проседает больше — там и кроется проблема, там и падают реальные метрики, которые уже в контексте работающего синергического проекта обретают смысл. Вполне возможно, что долгая разработка тестов не вина дизайнера, а вина аналитика, транстировавшего требования слишком сложно.
Ремарка №3Несмотря на то, что описанная мною модель говорит о единстве и взаимосвязанности всех этапов процессов, сегодня тестировщиков правильнее классифицировать всё-таки на разработчиков самих тестов (акцентирующих силы и знания на методологии тестирования) и devops инженеров, обслуживающих инфраструктуру. Сегрегация функций имеет свои плюсы при достаточно большом размере проекта и хорошем финансировании, когда развитие, поддержку и тестирование инфраструктуры можно разнести между инженерами, в идеале — между экспертами-специалистами. Важным моментом является то, что тест-инженер всё-таки в первую очередь инженер, разработчик в тестировании, способный использовать различные инструменты для разрешения поставленной задачи. И только во вторую очередь — эксперт в какой-то определённом инструменте и программе. Знатоков инструментария, возможностей фреймворков правильнее классифицировать как отдельных инженеров, инженеров-инструменталистов (tool engineer).

Тезис №4: Тестировщик — центр процесса разработки ПО

В V-модели разработки ПО наглядно видно, что тестировщик участвует на всех этапах жизненного цикла.
Схожесть разработчика и тестировщика, размазанность границ области при наличии хорошей квалификации — главный показатель интереса в работе тестировщика. Конечно, можно утверждать, что причастность к продукту и его качеству в случае тестирования чёрного ящика является мотивационным фактором, но, на мой взгляд, человек, пришедший в техническую, инженерную область сделал это осознанно, с желанием развиваться и работать над собой. Поэтому возможность расширять свой кругозор, влиять на качество продукта, (пусть даже небольших вещей), проявлять активность, а также накладывать вето на выпуск продукта у тестировщика, по моему мнению, более весомые аргументы за профессию. А раз так, раз хороший тестировщик — не обезьяна, а инженер-исследователь, знаток, принимающий участие на почти на всех этапах жизненного цикла по (в отличие от ролей аналитиков, дизайнеров, разработчиков, и технических писателей), ответственный за качество продукта (не процесса, это к QA, так что под «качеством продукта» будем подразумевать соответствие заявленным и утверждённым требованиям и стандартам, чеклистам и прочая), то для поднятия качества продукта и развития себя, как специалиста, тест-инженер должен проявлять активную позицию. Он знает, как улучшить продукт. Знает, что такое «достаточно хорош», и как его, продукт или процесс, таким сделать, инициировать движение как инженера-разработчика, так и других команд и даже компаний. Например, в любых проектах бывают моменты простоя, который может быть допустим со стороны руководства. Обычно в это время сотрудники решают личные проблемы или занимаются самообразованием. В отношении работы разработчик может заняться рефакторингом, поизучать алгоритмы и перенести на свои проекты. А что делать тестировщику? Осваивать новые средства тестирования? Он-то ничего не делает без изначального пакета от разработчиков/аналитиков. В действительности, он может заняться автоматизацией своей деятельности или улучшением продуктов, им используемых, даже если он далёк от инфраструктуры и devops.
Ремарка №3В Liebherr Aerospace жёсткий процесс резко ограничивал использование любых инструментов и жёстко формализовал процесс разработки и тестирования, т. е. простора для автоматизации оставалось не так много — даже вмешательство в багтрекер было запрещено. Тем не менее, такой процесс, как подготовка документации, был в такие периоды автоматизирован, пусть и с использованием не находящегося под запретом VBA для MS Office. А для процесса код ревью можно было улучшить статические анализаторы кода. Они не совсем удовлетворяли стандартам на проекте и порождали лишние сообщения, которые не фильтровались даже элементарным grep. Тем не менее, чтобы уменьшить время на ручное ревью кода, в рамках простоя мы работали на перспективу, улучшая сторонний продукт, такой как статический анализатор, подготавливая набор кейсов для него для имплементации нужных нам проверок.

Тезис №5: Тестирование — не место для фиксации на ключевых словах

Последней и самой странной темой, на мой взгляд, является весьма смутное представление о тестировании (даже о теории, не говоря о практике). Во многих компаниях отделы тестирования не оправдывают надежд, в некоторых даже дискредитировали себя и функционируют на малую часть от своей потенциальной эффективности по ряду факторов. Проблема проистекает как из-за отсутствия школы, так и из-за некомпетентности менеджмента. Ситуация весьма плачевная в отраслях, отдалённых от IT, даже где «деньги — не проблема» — там задачи ставятся по принципу «повысить качество продукта». Даже в IT-компаниях, где есть общее представление о процессах, есть целый ряд проблем, связанных с фиксацией на определённых ролях или инструментах, хотя к тестированию, повторюсь, такой подход плохо применим.
В одном из крупных инвестиционных банков, в котором у меня проходило собеседование, было схожее требование на позицию тест-менеджера: «повысить качество и уменьшить брак». Любую задачу можно решить. Хотя под покровом задач скрывается координация отделов по ряду различных продуктов, составление планов тестирования, организация тестирования, работа с разработчиками, составление базы кейсов и прочая. В действительности, ответственность за качество продуктов в компании логично взять на себя какому-нибудь «директору по качеству», оно же QA Director, а не просто руководителю отдела тестирования. Однако тут дело упирается в полномочия, которых на этой позиции нет, и в отсутствие группы, которая не планировалась вовсе (которая могла бы помочь тому-тому тому-то). То есть в компанию нужен человек-оркестр без команды. Разгадка тут простая: менеджмент ищет по ключевым словам, и считая качество в аббревиатуре QA панацеей от всех проблем, хотя она лежит в сфере стратегического топ-менеджмента и процессов, которые нужно спускать сверху с соответсвующими полномочиями и ресурсами.
В идеале управление качеством (QA) и тестирование две непересекающиеся сущности.
Проблема системная, т. к. весьма неплохо, когда HR ищут по ключевым словам вроде «нагрузочное тестирование», «функциональное». Но когда в процессе рассмотрения делается акцент не на навыки тестирования, не на активность и гибкость кандидата, а на конкретный инструмент — это уже проблема, особенно когда никакого тестирования нет в помине (есть обезьянничество), и не факт, что требуемый инструмент эффективнее того, который знает соискатель. Проблема в том, что знание мелкого нюанса или инструмента, на освоение которого уйдёт несколько часов, ставится во главе угла, выше знания языков программирования или теории. В одном из интервью было достаточно смешно было отвечать на вопросы: «назовите какую-нибудь книгу по тестированию» и, ответив про Сэма Канера, услышать: «мы такого не знаем, а про жизненный цикл бага что-нибудь читали?». Это было бы смешно, если бы не было так грустно. Грустно, когда HR сообщает об отказе из-за отсутствия опыта у кандидата, хотя дело к неправильном расставлении акцентов.

Найти хорошего тестировщика — большая проблема, т. к. инженер-тестировщик — это, в идеале, человек, который разрешает технические проблемы, связанные с разработкой ПО, эдакий problem solver. Такому человеку, помимо технических навыков очень важно иметь внимательность, пытливый ум, быть активным и уметь донести мысль и отстоять свою точку зрения на любом уровне.В каком-то роде, тестировщики — это исследователи из мира разработки ПО. Поэтому в руках инженера-тестировщика легко узнаваемый символ — лупа (линза), наблюдающая за жучками. Как нельзя лучше характеризует она работу тестировщика: используется как по прямому назначению для выявления дефектов, так и для «прожигания дырочек», с её помощью можно добывать огонь и даже, имея целую систему линз, наблюдать за звёздами. Главное — уметь это делать.
Ремарка №5В компании Intel главенствует подход, в котором инструменты выбираются из предпочтений сотрудников на проекте. Это означает, что, в целом, неважно, какой инструмент и язык выбрать для решения задачи, главное — её решить. Сосуществование трёх разных тест инженеров, пишущих на трёх разных языках вполне допустимо, если проблема решается, решается эффективно и накладные расходы на поддержку разумны, а процесс документируется. Кроме того, многие используемые инструменты являются бесплатными, open-source или собственной разработки. На сегодняшний день существует огромное количество инструментов, с помощью которых возможно решать разнообразные задачи, и выбор инструментов не должен ограничивать возможности инженера. Однако, если для задачи действительно требуется использовать какой-то инструмент, отличный от свободно доступного, то при наличии чёткого понимания и обоснования, можно купить и использовать его. Это опять-таки соответствует целям бизнеса — не забивать гвозди микроскопом, не работать эффективно, выжимая максимум из инструментов, если квалификация инженеров позволяет обойтись «малыми потерями». Хорошей альтернативой является также участие в открытых проектах и инвестиции в них для последующего использования для собственных нужд. Такой подход убивает двух зайцев (свои нужды) и задачи и создаёт инструменты для всего общества в свободном использовании.

Вместо выводов

Тестировщик — это больше, чем профессия. Это образ проактивной жизни и стремления эту жизнь сделать лучше для всех посильными и эффективными средствами. Цели тестировщика в отношении продукта наиболее близки к целям бизнеса и стратегической цели компании в отношении этого продукта, и в то же время глубоки внутри компании в роли исследователя. А раз так, то главные его качества — это энергия, знания и гибкость. Но в тоже время работа тестировщика – это не всеобщее знание и ответственность за качество продукта и качество услуг. У тестирования есть границы: с одной стороны ограниченные проектом и требованиями в нём (менеджмент проекта и установленный жизненный цикл программы), и с другой – процессами, за которые отвечает QA. Но о различия QA от тестирования совсем другой разговор.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *