CC BY
226
УДК 797.561
Г
\
БО! 10.21685/2307-4205-2017-3-16
МЕТОДОЛОГИЯ И ПРОЦЕСС РУЧНОГО ТЕСТИРОВАНИЯ
Д. А. Моисеев
/
Актуальность
Современный мир с каждым годом становится все технологичнее и технологичнее. Появляются новые информационные устройства, гаджеты, новые сервисы, программы и электроника. Прогресс в сфере информационных технологий шагает огромными шагами и все больше вещей в современном мире мы стараемся сделать, не выходя из дома, будь то покупка чего-либо, оплата коммунальных услуг, налогов и т.д. Технология же всех программ и сервисов становится все сложнее, и современного человека уже трудно удивить каким-то нововведением. И естественно, каждый человек хочет этим пользоваться, не боясь потерять свои деньги, он хочет, чтобы приложение работало правильно, чтобы оно было удобным и не вызывало у него никаких проблем. Но в нынешнее время сложность этих сервисов настолько большая, что зачастую выпустить продукт, в котором все работает корректно и не вызывает никаких нареканий, практически невозможно. Хотя каждый производитель максимально к этому стремится. Ведь в современном мире конкуренция настолько большая, что одна ошибка может заставить перейти пользователя к прямому конкуренту, что означает большие потери. Программисты, которые раньше отвечали не только за разработку конкретного приложения, но и за его качество, со временем из-за сложности систем не успевают не только разрабатывать, но и проверять приложения на качество. Однако качество при этом не должно страдать. Поэтому начал развиваться новый вид деятельности, а именно, тестирование программного обеспечения. На начальных этапах данная деятельность обозначала просто соответствие конечного результата тому, что должно было быть. Но с развитием программного обеспечения и его сложности активно развивалось и тестирование. Постепенно тестирование становилось все сложнее и объемнее, поэтому окончательно отделилось от программирования и стало называться «Обеспечение качества ПО». Оно стало в себя включать не только тестирование, но и планирование, проектирование, поддержку, создание и выполнение тестов.
В наше время представить разработку хотя бы одного самого простого приложения, сайта или программы без обеспечения качества уже невозможно. Этот процесс начинается вместе с разработкой и является не менее важной частью в цикле разработки программного обеспечения. Потому что плохое обеспечение качества может привести к очень печальным последствиям, начиная от потери денег и заканчивая расшифровкой каких-либо личных, а иногда и государственных данных. Именно поэтому процесс обеспечения качества очень важен и должен проходить по всем правилам. К сожалению, многие заблуждаются, думая, что обеспечение качества заключается лишь в нахождении ошибок.
Все ручное тестирование делится на три группы:
1) функциональное;
2) нефункциональное;
3) связанное с изменениями.
Функциональное тестирование - это тестирование непосредственно функций и задач продукта. Оно происходит на всех уровнях тестирования: модульном, интеграционном, системном и приемочном [1].
На модульном уровне тестирования [1] проверяется корректная работа одного отдельного модуля внутри себя. Тесты для такого тестирования обычно пишутся еще до написания основного кода программы. Код модуля считается написанным успешно, когда он проходит на соответствие всем проверкам, которые были описаны до его написания. Обычно тестированием модульного уровня (или иш1>тестированием) занимается сам разработчик, который пишет этот код.
Функциональное тестирование
Интеграционный уровень тестирования делится на модульный интеграционный уровень и системный интеграционный уровень [1].
В модульном интеграционном уровне проверяется взаимодействие между модулями системы после проведения модульного тестирования. Все написанные модули объединяют и происходит проверка на соответствие корректной работы не одному модуля, а взаимодействия нескольких.
В системном интеграционном уровне [1] проверяется взаимодействие между разными системами после проведения системного тестирования. Это проверка на соответствие корректной работы разных приложений, программ, сайтов между собой.
На системном уровне [1] полностью проверяется работа всей системы, взаимодействия всех ее модулей и всех программ между собой. Это тестирование должно вестись на контуре, который максимально приближен к контуру, на котором будет реальный продукт. Это тестирование должно вестись как на базе требований (для каждого требования свой тестовый случай), так и на базе случаев использования (проверяются сценарии использования данного продукта, на каждый сценарий свой тест-кейс).
На приемочном уровне [1] тестирования продукт показывается непосредственному заказчику. Вместе с ним проходятся тестовые сценарии, и он выносит решение, либо пропускать продукт в промышленное использование, либо возвращать на доработку.
В функциональное тестирование также входит тестирование безопасности [2] (проверка системы на конфиденциальность, целостность и доступность данных), а также тестирование взаимодействия (проверка системы на возможность работы с другими системами и совместимость).
Нефункциональное тестирование
Нефункциональное тестирование [1] описывает тесты, необходимые для определения характеристик программного обеспечения, которые могут быть измерены различными величинами. В нефункциональное тестирование входят такие виды тестирования, как тестирование производительности, тестирование установки, тестирование удобства пользования, тестирование на отказ и восстановление, конфигурационное тестирование.
Тестирование производительности [3] должно выявить, насколько система корректна работает при одновременном использовании данного продукта многими пользователями. Не «упадет» ли твой продукт, не потеряются ли данные пользователи и т.д. Также оно позволяет определить максимальное число пользователей, которые могут одновременно пользоваться вашим продуктом.
Тестирование установки проверяет, корректно ли продукт устанавливается и удаляется на рабочую машину пользователя [3].
Тестирование удобства пользования [2] является одним из самых важных и сложных видов тестирования. Этот вид тестирования определяет, насколько удобно и приятно будет конечному пользователю пользоваться вашей программой. У каждого человека есть свое мнения, что где должно находиться, чтобы продуктом было удобно пользоваться. Однако есть некие негласные правила, которые соблюдаются почти всегда (например, то, что меню должно быть сверху). Тестирование удобства может проводить не только тестировщик, но и группа конечных пользователей в тестовых режимах продукта. Это помогает собрать нужную и общую информацию о том, как именно конечным клиентам будет удобно пользоваться вашим приложением.
Тестирование на отказ и восстановление [4] заключается в проверке конечного продукта на возможность восстановиться после какого-то сбоя (отключение электричества, отказ сети). Это очень специфический вид тестирования и надо предусмотреть все возможные виды отказа системы и адекватную реакцию на эти отказы.
Конфигурационное тестирование [4] должно определить набор конфигураций, которые будут достаточны для работы системы на конкретном устройстве (самый популярный пример такого тестирования - это минимальные и подходящие системные требования для игр).
Тестирование, связанное с изменениями
Эта группа является одной из наиболее часто используемых на практике. Оно проверяет систему после каких-либо внесенных изменений в ней (будь то исправление багов или разработка новых функциональных требований). На практике оно встречается чаще всего и именно это тестирование является ключевым в качестве обеспечения продукта. Ведь любое даже малейшее из-
менение в коде продукта может потянуть за собой ошибки, которых не было до изменений. Основными видами этого тестирования являются дымовое тестирование, регрессионное тестирование, тестирование сборки, санитарное тестирование.
Дымовое тестирование [4] проверяет, как после установки новой версии или сборки продукт запускает и выполняет свои основные функции. Обычно это тестирование происходит после выкладки кода в продуктивный контур (версию в промышленной эксплуатации) и проверяет корректность работы основного функционала продукта после обновления версии на реальных пользователях или данных.
Регрессионное тестирование - это полное тестирование продукта (как функциональными видами, так и не функциональными) для того, чтобы убедиться, что новые изменения не в коде не создали новых багов в других местах [3]. Обычно это самое длительное и трудозатратное тестирование, так как даже после исправления одного бага необходимо пройти все сценарии тестирования данного продукта. Обычно именно на этапе регрессионного тестирования находится большинство багов и несоответствий системы и технического задания. Еще одна трудность заключается в том, что если в самом конце тестирования нашелся баг, который является критичным или блокирующим, то после его исправления необходимо заново и полностью провести цикл регрессионного тестирования.
Тестирование сборки [3] очень напоминает дымовое тестирование. Однако если в дымовом тестировании проверяется только основной функционал, то при тестировании сборки есть возможность учитывать какие-то спецификации и пожелания на данном этапе тестирования.
Санитарное тестирование [4] является узконаправленным тестированием, проверяющим работу конкретной функции или блока. Является подвидом регрессионного тестирования и определяет работоспособность части продукта после изменения.
Очень многие путают понятия, говоря, что дымовое и санитарное тестирование является одним и тем же. Однако это неправильно. Это два совершенно разных вида тестирования. Если дымовое тестирование - это больше тестирование вширь, для проверок «вширь» основного функционала, то санитарное тестирование, это тестирование «вглубь» одной конкретной функции или модуля.
Модель идеального процесса ручного тестирования
Если говорить о какой-либо идеальной модели тестирования, то у разных тестировщиков в разных компаниях будет очень много споров, потому что идеальной модели нет. Ручное тестирование очень сильно зависит от конкретных задач, конкретных специалистов и конкретного приложения. Таким образом, необходимо создать модель тестирования.
Этапы тестирования
Этапами тестирования являются следующие:
1) написание тест-плана;
2) разработка тест-кейсов;
3) дымовое тестирование;
4) проверка дефектов;
5) регрессионное тестирование;
6) санитарное тестирование;
7) написание отчета о тестировании;
8) дымовое тестирование на продуктивном контуре
Написание тест-плана. Многие думают, что тестирование начинается только после того, как какая-то часть программы уже написана. Это большое заблуждение. Тестирование начинается с момента первых упоминаний о возможном приложении. В этот момент команда тестирования должна начать обдумывать подходы и варианты тестирования данного приложения. Далее составляется один из ключевых артефактов тестирования - «Тест-план». В тест-плане тестировщи-ки обязаны указать, что именно надо тестировать (приложение, программа), что будем тестировать (список функций), какими видами будет тестироваться приложение (интеграционное, регрессионное и т.д.), сроки тестирования, критерии начала и окончания тестирования. Это необ-
ходимая информация, которую надо указывать в тест-плане. Все остальное зависит от проекта. Например, в веб-приложениях можно указывать браузеры, в которых проводилось тестирование, список доработок и исправленных дефектов и т.д.
Разработка тест-кейсов. Одна из самых сложных и нелюбимых задач любого специалиста по обеспечению качества, однако при этом и самая важная. В момент, как только тестировщик получает первую документацию и техническое задание по системе, ему необходимо начинать писать тест-кейсы или тестовые случаи. Это необходимые шаги, которые должны привести к какому-либо ожидаемому результату. Эти шаги должны быть описаны максимально подробно и максимально опираться на документацию, чтобы не возникало споров о том или ином действии системы.
Дымовое тестирование. Это первое тестирование, которое проходится на новой вышедшей версии. Если проверка новой сборки на основные функции выявила какие-то несоответствия в работе, то сборка признается неуспешной и возвращается на доработку.
Проверка дефектов. Все дефекты, которые были выявлены в предыдущих версиях, а в новой версии находятся в статусе «Готово для тестирования», должны быть проверены в первую очередь. Потому что после их проверки может оказаться, что одно исправление задело другое и этот дефект необходимо возобновлять в новой версии. Если такие дефекты есть, то тестирование начинается с п. 3. Если же нет, то все дефекты закрываются.
Регрессионное тестирование. После того, как дымовое тестирование и проверка дефектов прошли успешно, необходимо начинать регрессионное тестирование. Именно для этого и нужны были тест-кейсы из п. 2. В регрессионном тестировании система полностью проверяется на наличие дефектов и новые найденные дефекты заводятся в следующую версию, если не являются стопперами в работе системы.
Если же дефект является критичным, то тестирование надо начинать с п. 3, в том числе и заново проходить все регрессионное тестирование. Хотя обычно в фазе «Дымовое тестирование» все критичные дефекты выявляются.
Санитарное тестирование. Санитарное тестирование проводиться в случаях, когда стоп-пер удалось обнаружить слишком поздно и нет времени на полноценное регрессионное тестирование. В этом случае после исправления критичного дефекта проявляется вся функциональность, каким-либо образом связанная с функциональностью, которая использовалась в месте обнаружения дефекта.
После проведение п. 5 и при необходимости п. 6 пишется отчет о тестировании. В нем указывается: какие виды тестирования были проведены, какие новые дефекты были заведены, сроки выполнения тестирования, критические проблемы при тестировании и др. Но главное - в конце отчета должен быть вывод о результатах тестирования, готова ли текущая сборка уходить в промышленную эксплуатацию или не готова.
Дымовое тестирование на продуктивном контуре. Последний этап тестирования проводится уже в продуктивной версии. Этот этап тестирования выявляет, что приложение работает с реальными данными, пользователями без сбоев [5].
В целом этот процесс может сильно меняться от количества времени, проекта, количества людей и других факторов. Однако именно эта модель и последовательность, по мнению авторов, максимально подходит для эффективного определения качества продукта. Однако для того, чтобы все виды тестирования прошли успешно, необходимо соблюдать несколько основных принципов. Первое и одно из самых важных - это изолированность тестирования. Во время начала тестирования продукта программист не имеет права выкладывать что-либо на тестовый контур. Потому что любое, даже самое незначительное изменение в коде может привести к ошибкам в тех местах, которые уже были проверены. Поэтому после любого изменения тестового контура программистом необходимо заново начинать тестирование с п. 3. Во-вторых, это универсальность те-
стировщика. Каждый из команды тестирования данного проекта должен обладать полными знаниями по системе. Когда ты изо дня в день, из года в год выполняешь одни и те же тест-кейсы, твой взгляд начинает «замыливаться», и ты можешь пропустить часть дефектов. Для этого функционал, который проверяет каждый тестировщик, должен меняться, чтобы тестирование оставалось качественным. В-третьих, устраивающий всех жизненный цикл дефектов. Это позволит избежать конфликтов и уменьшить количество разговоров между программистом и тестировщиком. В-четвертых, общий шаблон ведения баг-трекеров и дефектов. Это облегчит задачу по созданию, обновлению, понятию и исправлению дефектов.
Заключение
В этой статье описываются методологии тестирования и процесс тестирования, которые максимально приближены к идеалу. Тестирование, а если быть корректным, то оценка качества ПО является большой и обособленной работой для оценки качества продукта и удовлетворение конечных результатов клиента. Без тестирования нельзя представить ни одно серьезное приложение, сайт, технику или еще что-либо. Однако это профессия еще молода и ей есть куда расти.
Библиографический список
1. Лайза, Криспин. Гибкое тестирование: практическое руководство для тестировщиков ПО и гибких команд / Лайза Криспин, Джанет Грегори. - М. : Вильямс, 2010. - 464 с. - (Addison-Wesley Signature Series).
2. Синицын, С. В. Верификация программного обеспечения / С. В. Синицын, Н. Ю. Налютин. - М. : БИНОМ, 2008. - 368 с
3. Канер, Кем. Тестирование программного обеспечения. Фундаментальные концепции менеджмента бизнес-приложений / Канер Кем, Фолк Джек, Нгуен Енг Кек. - Киев : ДиаСофт, 2001. - 544 с
4. Калбертсон, Роберт. Быстрое тестирование / Калбертсон Роберт, Браун Крис, Кобб Гэри. - М. : Вильямс, 2002. - 374 с.
5. Гленфорд, Майерс. Искусство тестирования программ / Гленфорд Майерс, Том Баджетт, Кори Сандлер. -М. : Диалектика, 2012. - 272 с.
Моисеев Даниил Александрович аспирант,
Пензенский государственный университет (440026, Россия, г. Пенза, ул. Красная, 40) E-mail: [email protected]
Аннотация. Актуальность и цели. Обеспечение качества любого продукта в настоящее время невозможно переоценить. Для того, чтобы продукт полностью соответствовал всем ожиданиям пользователя, необходимо провести продукт через все стадии тестирования. Оценка качества продукта является задачей, к которой нужно подходить, соблюдая все стадии тестирования. Материалы и методы. Для качественного тестирования программного обеспечения необходимо использовать все накопленные знания и методологии тестирования, такие как функциональное тестирование, нефункциональное тестирование, тестирование, связанное с изменениями. Результаты. Предложенный процесс тестирования программного обеспечения является максимально близким к идеалу. Если пройти все этапы тестирования, которые описаны, то в качестве программного продукта можно будет не сомневаться. Адекватность данной схемы тестирования программного обеспечения проверена эксперименталь-
Moiseev Daniil Aleksandrovich
postgraduate student,
Penza State University
(440026, 40 Krasnaya street, Penza, Russia)
Abstract. Background. Ensuring the quality of any product at present can not be overemphasized. In order for the product to fully meet all the expectations of the user, it is necessary to carry out the product through all the testing stages. Evaluation of product quality is a task that must be approached, observing all stages of testing. Materials and methods. For qualitative software testing, it is necessary to use all the accumulated knowledge and testing methodologies, such as functional testing, nonfunctional testing, testing related to changes. Results. The proposed process of software testing is the closest to the ideal. If you go through all the stages of testing that are described, then as a software product you can have no doubt. The adequacy of this software testing scheme has been verified experimentally. Conclusions. Proper testing of any product is a guarantee that the user or buyer will be satisfied with it. Improving product quality and quality testing is one of the most important tasks that now faces any manufacturer.
но. Выводы. Правильное тестирование любого продукта является гарантией того, что пользователь или покупатель останутся им довольны. Повышение качества продукции и качественного тестирования является одной из важнейших задач, которая сейчас стоит перед любым производителем.
Ключевые слова: функциональное тестирование; нефункциональное тестирование; тестирование, связанное с изменениями; этапы тестирования.
Key words: functional testing, non-functional testing, testing related to changes, testing stages.
УДК 797.561
Моисеев, Д. А.
Методология и процесс ручного тестирования / Д. А. Моисеев // Надежность и качество сложных систем. - 2017. - № 3 (19). - С. 107-112. БО! 10.21685/2307-4205-2017-3-16.
