Базовые вопросы о тестировании

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

Что такое тестирование ПО?

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

Чтобы протестировать абсолютно все места системы (учитывая все входные данные, комбинации данных и окружения) понадобится слишком много времени, что, соответственно, негативно скажется на сроках выпуска продукта. Зачастую проводить доскональное тестирование абсолютно всех участков системы и вовсе не требуется. Поэтому, как правило, тестированию, в первую очередь, подлежат наиболее приоритетные функции приложения. Чтобы сократить время тестирования и сделать его наиболее эффективным перед проведением тестирования специальным образом создаются сценарии тестирования приложения (тест-кейсы, чек-листы, чит-листы и другие). Чем более качественно тестовые сценарии будут продуманы, тем выше вероятность обнаружения наибольшего количества дефектов. Существует целый ряд практик (Equivalence Partitioning, Pairwise, Boudary Value Analysis и другие) по проектированию тестовых случаев и по их выполнению: данная дисциплина называется тест-дизайном. Тестирование должно начинаться как можно раньше. На ранних стадиях разработки приложения тестированию подлежит документация (спецификация, требования) к приложению, также можно начинать подготавливаться к самому тестированию — разрабатывать стратегию, план тестирования и автоматизации, готовить тестовое окружение, анализировать возможные риски, обучать персонал, разрабатывать тестовую документацию и прочее. Тестирование само по себе не самодостаточная отрасль, цели и задачи тестирования вытекают от целей и задач проекта в целом.

Существует несколько видов тестирования и у каждого из них свои цели и приоритеты. Также, в тестировании существует ряд подходов и практик, выделяется несколько ярко выраженных школ тестирования.

Тестирование является только первой ступенькой к качеству программного обеспечения. Тестирование — составляющая часть более весомого понятия  Quality Control (контроль качества). QC отвечает за измерение качества продукта, анализ результатов тестирования и качества релизов или сборок продукта, сбор и анализ метрик качества. Другими словами, QC обрабатывает и упорядочивает информацию, полученную в ходе разработки и тестирования, с целью улучшения качества продукта. В свою очередь QC является составной частью Quality Assurance (обеспечение качества). QA решает более глобальные задачи, главная из которых — управление качеством самого процесса. QA старается предвидеть и предотвратить возможные проблемы (так сказать сработать на опережение). В обязанности QA входит подбор практик, методов, подходов, инструментов и прочее.

Несмотря на относительно небольшой возраст данной отрасли, думаю, тестирование уже вполне можно считать формирующейся инженерной наукой, очень интересной и перспективной. Неприятно, когда тестирование сводят к обычному «манки кликанью». Хотя, к сожалению, большая часть тестировщиков именно этим и занимается, вместо того, чтобы попытаться найти ответы на вопросы — зачем? как? почему? и т.д. Помимо этого, несомненно, тестирование – это в достаточной мере креативная деятельность, где много возможностей для применения своего таланта и творческого размаха :-). Областей тестирования хватает, выбирайте самое близкое для себя. Лично я свою команду сформировал по принципу «универсальных бойцов», людей с внушительным кругозором, технических подкованных, а также постоянно стремящихся развить свои знания и умения, ну и, конечно, просто отличных ребят. Под данным термином я подразумеваю специалистов готовых и умеющих закрыть большой спектр задач (кроссфункциональность сотрудников). Естественно, это не означает, то что все занимаются одним и тем же, и обладают одинаковым набором знаний. За каждым человеком закреплена его основная специализация в тестировании (автоматизация, тест-дизайн, безопасность и т.д.), все остальные должны быть готовы придти на помочь и закрыть часть работ по не профильной специализации. Да, и конечно, все всегда готовы к закрытию задач по ручному функциональному тестированию, так как это одна из основных задач в тестировании.

Кто должен заниматься тестированием?

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

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

Что должен знать начинающий тестировщик?

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

Я бы выделил следующие навыки, которыми должен обладать начинающий тестировщик:

  • Технический кругозор. Понимать как устроено приложение (веб, мобайл, десктоп в зависимости от выбранного направления), на теоретическом уровне разбираться в технологиях;
  • Теоретические знания из области тестирования;
  • Уверенно разбираться и применять техники тест-дизайна (классы эквивалентности, граничные значения, попарное тестирование и прочее);
  • Работа с тестовой документацией (тест-кейсы, чек-листы, отчеты о дефектах и прочее);
  • Общее понимание процессов разработки ПО, всех этапов работы над проектом;
  • Как минимум, общее представление об инструментарии тестировщика (система управления дефектами, система управления проектами, дев консоль, инструменты автоматизации и прочее);
  • Хороший эстетический вкус, понимание базовых основ проектирования интерфейсов приложений.
  • Хороший письменный и устный английский язык.
  • Мышление экспериментатора. Критическое мышление. Далеко не всем подходит эта профессия;

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

Что подпадает под тестирование?

Тестированию подлежит абсолютно все! Как в реальной жизни можно проверить на качество любой предмет, так и в разрабатываемом продукте можно проверить любой его аспект. Начинать тестирование следует с проверки требований, спецификации и прочей проектной документации. В данном случае мы проверяем полноту требований, их непротиворечивость, дублирование и прочее специфические аспекты. В качестве ориентира рекомендую использовать стандарт качества ISO 9126. Согласно данному стандарту проекты должны обладать следующими характеристиками (соответственно, это те аспекты, которые подлежат тестированию):

  • Функциональность. Работа функций приложения, их пригодность к использованию;
  • Надежность. Отсутствие дефектов. Устойчивость к отказам, работа под нагрузкой и способность к восстановлению;
  • Практичность. Удобство пользователя, не забываем, что продукт мы делаем для наших клиентов, они должны с удовольствием работать с нашим приложением;
  • Эффективность. Скорость работы приложения;
  • Сопровождаемость. Возможность внесения изменений и дальнейшее развитие системы;
  • Мобильность. Совместимость, адаптируемость приложения к различным конфигурациям и.д.

Каким образом происходит тестирование?

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

  • Анализ и планирование;
  • Тестирование документации. В данном случае мы проверяем полноту требований, их непротиворечивость, дублирование и прочее специфические аспекты;
  • Подготовка к тестированию. Установка тестового окружения, настройка инструментария, подготовка плана/стратегии тестирования и автоматизации (предварительно оценив, требуется ли ее внедрение), разработка необходимой тестовой или иной вспомогательной документации, знакомство с архитектурой приложения, обучение;
  • Выполнение тестирования. Тестирование нового функционала по разработанной документации или методом свободного поиска, исследовательского тестирования. Проверяем различные аспекты качества разрабатываемого приложения (см. выше ISO 9126);
  • Производим анализ проведенного тестирования.

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

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

Какие программы используются для тестирования?

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

  • Системы управления дефектами (MantisBT, Jira, FogBugz и множество других);
  • Инструменты для управления тест-кейсами, чек-листами (TestLink, Zephyr, Sitechco, Jite);
  • Инструменты автоматизации.

На данный момент существует ряд крупных систем (все они платные) для тестирования, в которых собран целый комплекс инструментария тестировщика. Примеры — HP Quality Center, Team Foundation Server.

Часто используемые вспомогательные инструменты:

Различные текстовые редакторы (Microsoft Word, Notepad), генераторы тестовых данных (generate data), захват экрана (Snagit, FireShot), Fidler, Firebug (плагин к FF), Web Developer Tools (плагин к FF), IE Developer Toolbar (инструментарий к IE), проверка битых ссылок (Xenu’s Link Sleuth), кроссбраузерное тестирование (IETester, Resize My Browser, SpoonBrowser).

Какие бывают виды тестирования?

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

По типу тестов:

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

По уровням тестирования:

  • Компонентное (модульное) тестирование (component/unit testing). Проверка отдельных модулей программы, тестирование носит изолированный характер. Включает в себя как функциональные, так и нефункциональные виды тестирования;
  • Интеграционное тестирование (integration testing). Тестирования взаимодействия между компонентами (модулями) системы. Включает в себя как функциональные, так и нефункциональные виды тестирования;
  • Системное тестирование (system/end-to-end testing). Проверяется поведение системы в целом. Включает в себя как функциональные, так и нефункциональные виды тестирования;
  • Приемочное тестирование (acceptance testing). Целью приемочного тестирования является оценка готовности системы для ее выпуска.

По знанию системы (доступности кода):

  • Тестирование чёрного ящика (black box). Тестирование проводится без доступа к исходному коду;
  • Тестирование белого ящика (white box). Тестирование проводится с доступом к исходу коду и с возможностью модификации кода;
  • Тестирование серого ящика (grey box). Представляет собой объединение двух выше перечисленных видов тестирования. Для всех вышеперечисленных видов тестирования применяются практики статического (анализ программы происходит на основе исходного кода, который тестируется вручную, либо анализируется специальными инструментами) и динамического тестирования (происходит запуск исходного кода).

По объекту тестирования:

  • Функциональное тестирование (functional testing). Проверка функций и характеристик разрабатываемого ПО на основе проектной документации;
  • Тестирование производительности (performance testing). Проверка работоспособности системы под нагрузкой. Может служить для проверки и подтверждения других атрибутов качества системы, таких как масштабируемость, надёжность и потребление ресурсов. Выделяются следующие подвиды: нагрузочное тестирование (load testing), стресс-тестирование (stress testing), тестирование стабильности (stability testing);
  • Юзабилити-тестирование & Тестирование интерфейса пользователя (usability testing & UI testing). Цель данного вида тестирования заключается в определении степени удобства и практичности пользовательского интерфейса;
  • Тестирование безопасности (security testing). Проверка надежности системы от возможных рисков и угроз (потеря, конфиденциальность, целостность и доступность данных);
  • Тестирование локализации (localization testing). Корректность перевода и работы отдельных компонентов системы (форматы дат, единицы измерения и т.д.);
  • Тестирование совместимости (compatibility testing) Проверка возможности приложения взаимодействовать с различными программными продуктами, операционными системами и окружением.

По степени автоматизации:

  • Ручное тестирование (manual testing). Тестирование проводится без инструментов автоматизации;
  • Автоматизированное тестирование (automated testing). Тестирование на всех уровнях выполняется с использованием средств автоматизации;
  • Полуавтоматизированное тестирование (semiautomated testing). Предполагается, что для определенных целей применяется автоматизации (автоматизации развертки окружения, автоматизация функционального тестирования, автоматизация генерации данных и т.д.)

По времени проведения тестирования:

  • Тестирование при приёмке (smoke testing). Минимальный набор тестов на явные ошибки;
  • Тестирование новой функциональности (new feature testing). Тестируется новые функции системы;
  • Регрессионное тестирование (regression testing). Проверка изменений сделанных в системе для подтверждения того факта, что существующая ранее функциональность работает как и прежде;
  • Тестирование при сдаче (acceptance testing). Целью приемочного тестирования является оценка готовности системы для его выпуска на рынок или передачи клиенту. Может включать в себя альфа-тестирование (alpha testing) и бета-тестирование (beta testing).

По признаку позитивности сценариев:

  • Позитивное тестирование (positive testing). Проверка позитивных (правильных) пользовательских сценариев. На вход подается разрешенные (ожидаемые) данные;
  • Негативное тестирование (negative testing). Проверка реакции системы на ввод негативных (не разрешенных) данных.

По степени подготовленности к тестированию:

  • Тестирование по документации (formal testing). Тестирование приложения проводится по заранее подготовленным данным (тест-кейсы, чек-листы, чит-листы, спецификация и т.д.)
  • Тестирование ad hoc или интуитивное тестирование (ad hoc testing) — тестирование проводится при полном отсутствии документации, без плана и цели;
  • Тестирование методом свободного поиска или исследовательское тестирование (exploratory testing) — предполагается наличие минимально необходимой для тестирования документации.

Какие бывают школы тестирования?

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

  • Аналитическая школа. Упор делается на анализ, измерение и покрытие тестами спецификации. Представители данной школы делают упор на математический анализ тестирования. Главные характеристики данной школы — логика и точность;
  • Стандартная школа. Тестирование представляется в виде конвейера (завода) , главная задача которого — выполнение установленных норм и стандартов. Процесс максимально регламентирован и прозрачен. Представители данной школы стараются выстроить тестирование на основе стандартов;
  • Школа контроля (качества). Фактически, то же самое, что и стандартная школа. Главное отличие — качество выходит на первый план, задача QA приложить максимум усилий по выпуску качественного продукта, только QA имеет право на отмашку — выпускать или не выпускать продукт;
  • Контекстная школа. Представители данной школы проповедуют контекстно-ориентированный подход (манифест смотри в пункте «Что попадает под тестирование?»). Главная практика данной школы — исследовательское тестирование.
  • Школа гибкого тестирования. Имеет сходство с контекстной школой. Главное отличие — тестировщики должны иметь глубокие технические знания, процесс тестирования строится на тотальной автоматизации на всех уровнях приложения.

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

Что такое автоматизация тестирования и зачем она применяется?

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

Какую литературу следует прочитать начинающим тестировщикам?

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

  • «Тестирование Дот Ком, или Пособие по жестокому обращению с багами в интернет-стартапах», Роман Савин (так сказать «нетленка», с данной книги начинало большое количество моих знакомых тестировщиков);
  • «Введение в тестирование программного обеспечения”, Луиза Тамре;
  • «The Little Black Book On Test Design», Rikard Edgren;
  • «A Practitioner’s Guide to Software Test Design», Lee Copeland;
  • «How to write better test cases», Dianne Runnels

Этой литературы будет достаточно, чтобы

Удачи в освоении тестирования!