что такое глубина тестирования
Классификация видов тестирования
Учил студентов предмету «Тестирование и отладка программного обеспечения» в ИжГТУ. Структуру курса обучения построил на основе классификации видов тестирования. 
Карту можно скачать тут.
Карта с видами тестирования на каждое занятие
Пословица разных народов мира.
Каждый раз для выбора вида тестирования использовалась карта. Каждый раз использовался опорный список видов работ.
Попарное сравнение
Всё познаётся только в правильно выполненном сравнении.
Автор мне неизвестен, возможно, Фридрих Ницше или Рене Декарт.
На конкретных примерах рассматривали, какая техника тест-дизайна при подготовке сценариев более применима к функциональному тестированию, а какая к конфигурационному. Разбирали в чём отличия выполнения тестов для основного функционального исследовательского тестирования, от основного функционального тестирования по тестам. Чем будут отличаться планы тестирования. Как при этом, выглядят проекты тестов (чеклист или mind-карта, против инструкций с порядком действий и ожидаемым результатом). Что является общим — процесс отслеживания дефектов.
Рассматривали, чем отличаются отчёты по конфигурационному тестированию и тестрованию масшабируемости, или отчёты по нагрузочному и объёмному.
Приносил примеры отчётов, несекретных и старых, сокращал их до 3-х страниц, удалив конфиденциальную информацию. Разбирали, что в отчётах общего (структура: цели, основа, краткие результаты, детали). В чём отличия. Как их читать. Как составлять. Как формировать автоматически.
Так, перебирая попарно виды тестирования формировал представление о выборе инструментов, подходов, целей и задач изучаемой деятельности.
Список работ по тестированию взял из SWEBOK (v3), глава 4 «Software Testing», раздел «Test Process», подраздел «Test Activities».
Эти виды работ выполняют инженеры по тестированию постоянно. Каждый вид работ важен. Для каждого есть хорошие и плохие рекомендации, инструменты, техники. Целью лекционных занятий было донесение до студентов видов тестирования и видов работ по тестированию. Относительно небольшой перечень знаний, и этих знаний достаточно, чтобы начать улучшать качество программного обеспечения.
Зачем карта
Фёдор Иванович Тютчев, 27 февраля 1869.
Карта является опорным конспектом для преподавателя. Напоминает о чём, надо успеть сказать. Помогает не сказать лишнего. Ведь времени так мало, а рассказать надо так много.
Ранее преподавал в учебном классе, где были только парты доска и мел. На занятия приходил точно к началу, доску не готовил. Стоять спиной и рисовать изучаемую предметную область во время занятий не хотел. Объяснить взаимосвязи на схемах удобно. Поэтому для каждой темы делал mind-карту. Распечатывал в нескольких экземплярах, раздавал студентам на занятии. Доску и мел использовал для изображения примеров. Рисовали как байтики движутся по схеме системы и приводят к SQL-инъекции, или как работает горизонтальное масшабирование. Так сформировалась привычка готовить mind-карты.
Особенность этой карты с видами тестирования — наличие определений для каждого узла. Если сохранить карту в формате html, получится объёмное чтиво.
Есть ограничения использования mind-карт в подготовке темы занятия. При большом количестве узлов, карта плохо читается на формате альбомного листа. И тогда лучше использовать доску и мел — дублировать части схемы на доске.
О доске и меле
Нужно тренировать красивый почерк и стараться рисовать схемы как произведения искусства. Первое время рисовал быстро, писал неровно. Думаю, выглядел, как сумашедший учёный с взъерошенными волосами. 
Потом стал стараться писать и рисовать, как в начальных классах. Ровно, красиво, чётко («как слоги в пионерской речёвке»). Студенты стали задавать больше вопросов. Стало понятнее, что занятия стали понятнее.
О преподавании
Готовился основательно. Случались технические сбои и заминки, не всё удавалось показать и объяснить. О каждом случае можно отдельную историю рассказать. Так подготовка лабораторных работ по тестированию — дорога на Эверест, уложенная граблями. Отладить работу автоматического теста в идеальном окружении, бывает, непросто. А если окружение неидеальное, на каждом учебном компьютере оно своё, и тест написан студентом на скорую руку, то лишь телепатия и «эффект разработчика», в которого ты перевоплощаешься, могут помочь.
Преподавание позволяет научиться лучше рассказывать, писать, видеть. Выбирать основное и простое. И будет, что вспомнить, с улыбкой.
Стоит попробовать.
Тестирование или управление качеством? Часть 2. Типы тестирования
В предыдущей статье «Часть 1. Что такое тестирование?» я поделилась с читателями мыслями о том, в чем заключается суть тестирования. Во второй части моих рассуждений о тестировании и управлении качеством я подробно рассмотрю различные типы тестирования и проанализирую модели, которые помогают разработчикам визуализировать процесс тестирования, чтобы вовлечь в него всех участников команды.
Тестирование — это не только поиск багов. Также оно заключается в поиске различной информации, которая помогает выявить риски. Собранные данные облегчают принятие решений по устранению этих рисков.
Типы тестирования
Существуют разные способы разделения процессов тестирования на категории. Вот один из вариантов:
Постановка вопросов
Тестировщики умеют формулировать правильные вопросы, поскольку они привыкли рассматривать такие сценарии «что, если?», о которых зачастую не задумываются остальные. Умение задавать вопросы — тема обширная и заслуживает отдельного поста. Но самое важное — задав вопрос, внимательно выслушать и понять ответ. Нужно побороть соблазн просто поблагодарить и не тратить время на уточняющие вопросы.
Кроме того, лучше задавать вопросы открытого типа вместо тех, которые требуют ответа «да» или «нет». Например, вместо вопроса «Пользователем системы будет X?» лучше спросить «Кто будет пользователем системы?» — в этом случае мы оставим задел под уточняющие вопросы.
Задание направления разработки
Разработка на основе приемочных испытаний (ATDD) или на основе поведения (BDD) — это две распространенные методологии ведения разработки на основе примеров.
Команда рассматривает какую-то пользовательскую историю (user story) — возможно, обсуждая в формате «трех амиго» на понятных примерах, чтобы донести ее суть до каждого участника дискуссии. Отталкиваясь от этих примеров, они составляют приемочные испытания и проводят дополнительные обсуждения. По мере детализации они продолжают составлять тесты для бизнес-правил в исполняемом формате под API или уровень служб.
Взяв получившиеся тесты, программист может вести разработку на основе тестирования (TDD) — писать модульные тесты, затем сам код и постепенно дорабатывать его, чтобы все тесты завершались успешно. Если организовать работу команды таким образом, тесты на уровне модулей и API будут автоматизироваться в процессе разработки кода, и в нужных местах будут предусмотрены проверки, удостоверяющие, что результаты работы системы соответствуют ожиданиям команды. Тестировщик сможет направлять в нужное русло процесс автоматизации, применяя свои навыки проектирования тестов, помогая создавать оптимальные тесты — не только для благоприятных сценариев, но и для нештатного поведения и других случаев «что, если?».
Углубленное тестирование
Разумеется, нам не обойтись без углубленного тестирования, которое всецело опирается на возможности человеческого интеллекта. Большинство тестировщиков занимаются этим видом тестирования с большим энтузиазмом. Опираясь на свой опыт и критическое мышление, они пытаются найти менее очевидные баги в коде, которые остались незамеченными на предыдущем этапе. Если команда прорабатывала все аспекты тестирования с ранних этапов, обнаружится лишь незначительное число не самых критичных багов.
Но недостаточно просто находить баги и докладывать о них. Следует также разъяснять риски, описывать сценарии тестирования, предлагать потенциальные решения, расспрашивать клиентов об их впечатлениях и на основе этих дискуссий предлагать команде различные пути улучшения.
Проверка
Не буду слишком вдаваться в подробности автоматизации в целом, но скажу пару слов об автоматизации регрессионного тестирования, с помощью которого мы убеждаемся, что сегодня система по-прежнему правильно делает все то, что она делала вчера. Такое тестирование эффективно для валидации любых изменений, поскольку оно проверяет одни и те же аспекты снова и снова абсолютно идентичным образом, с чем не очень хорошо справляются люди.
Автоматизация дает нам возможность убедиться в согласованности кода, а также отслеживать и документировать результаты на протяжении всего процесса разработки. Если тесты автоматизированы должны образом, тестировщики могут сосредоточиться на описанных выше типах тестирования, требующих более деятельного участия человека.
Квадранты гибкого тестирования
Давайте посмотрим на схему квадрантов гибкого тестирования, где приведены примеры типов тестов, которые может выполнять команда. Хотя типов здесь указано немало, схема далеко не полная, да и контекст каждой команды по-своему уникален, поэтому я рекомендую рассматривать ее как инструмент, который облегчает выбор подходящих тестов в процессе дискуссии. К вопросу контекста я вернусь в этой статье немного позже.
Слева располагаются тесты ранних этапов, выполняемые до написания кода. Благодаря им вскрываются риски и любые случаи недопонимания, которые являются частой причиной недоработок и ошибок. Если заранее исключить недопонимание, можно избежать серьезных ошибок в коде.
Вот пример из моего личного опыта:
Во время встречи с разработчиком я сказала ему, что все автоматизированные тесты API внесены в систему и готовы к реализации. Он взял их из системы контроля версий, проглядел и сказал, что продукт не сможет пройти ни одного теста. Я посмотрела на него с удивлением, поскольку мы вместе присутствовали на всех встречах и вместе согласовывали метод тестирования. Почему же тесты оказались непригодными? Он ведь даже еще не написал код. Выяснилось, что у нас было разное представление о том, как должна работать функция поиска. Именно после этого случая я стала оперировать более конкретными примерами во время обсуждений. Но я хотела подчеркнуть другое: если бы я не написала эти тесты и мы бы их вместе не изучили, разработчик написал бы код с серьезной ошибкой. А поскольку нам удалось выяснить суть проблемы на раннем этапе, устранить ее было довольно легко. Код еще не был написан, и я помогла предотвратить появление бага.
Вернемся к нашим квадрантам. Справа располагаются тесты, сфокусированные на критике продукта. Сверху справа находятся бизнес-тесты, то есть те, которые понятны представителям бизнеса. Кроме того, бизнес может принимать участие в их проведении — например, в приемочном пользовательском тестировании. Снизу справа приведены тесты, критикующие техническое исполнение продукта. Этот квадрант включает большинство тестов, связанных с атрибутами качества развертывания и эксплуатации. Даже если команда заранее обсудила самые важные моменты с точки зрения клиента и самой команды, в том числе подходы к написанию кода, которые помогут в их реализации, или различные способы повышения безопасности, мой опыт подсказывает, что реальные тесты невозможно провести, не имея на руках готового кода. Такое углубленное тестирование заключается не только в поиске дефектов, но и в анализе тестируемого приложения и предоставлении команде обратной связи.
Тестирование в различном контексте
Подобно тому, как существует множество видов тестирования, есть и множество контекстов тестирования. И один человек попросту не может учесть все комбинации этих двух факторов.
До этого момента я не упоминала гибкую (agile) методологию разработки, DevOps, непрерывное развертывание ПО, каскадную (водопадную) модель и вообще любой другой процесс организации разработки, которому может следовать ваша команда. В каскадных проектах обычно существует команда тестировщиков, между которыми распределяется ответственность за тестирование предоставленного им ПО. Основная часть их тестов сосредоточена на отлове багов.
Последние 20 лет я провела в коллективах, работающих короткими циклами с частой выдачей результатов; компаниях, где тестировщики входили в команды разработки продуктов; командах, которые тесно взаимодействовали с бизнесом. Если кратко, то это agile, DevOps, непрерывное развертывание — для простоты я буду называть все это гибкой разработкой. Даже если в команде есть отдельный тестировщик, он не способен сам полностью оттестировать продукт. Он просто не может обладать всем спектром необходимых навыков. Он может оперировать базовыми методами тестирования и иметь опыт в применении одной или нескольких специфических методологий. Он может пополнять и углублять свои знания в предметной области. Но в зависимости от разрабатываемого продукта ему могут понадобиться другие навыки: например, при работе с хранилищами данных нужно хорошо разбираться в базах данных и целостности информации.
Невозможно найти такого универсального тестировщика, который будет все уметь, поэтому ответственность за организацию тестирования ложится на всю команду. И вся команда отвечает за качество.
Итоги
Основная задача тестирования — выявление рисков и их устранение, притом в самой разной форме, будь то правильная постановка вопросов на ранних этапах прототипирования, формирование тестов до написания кода для направления разработки в нужное русло, исследование продукта на предмет неизвестных и неучтенных факторов либо анализ результатов тестирования в поисках тенденций, которые могут быть полезны для улучшения продукта или процесса. Все эти мероприятия вносят свой вклад в повышение качества продукта, но задачи тестировщика этим не ограничиваются.
Тестировщикам приходится выступать в роли наставников, налаживать связи, убеждать, мыслить нестандартно, относиться ко всему критически, предлагать способы устранения багов и последствий инцидентов, генерировать идеи для новых продуктов, которые решают более глобальные проблемы в программных и других продуктах, узнавать у клиентов и пользователей их впечатления и извлекать из собранной информации идеи для разработки и тестирования, управлять различными средами тестирования, участвовать в управлении релизными версиями и так далее. Список можно продолжать бесконечно, но все эти задачи сами по себе не решают проблему качества.
О ней и других важных аспектах мы поговорим в следующей статье.
В преддверии старта курса QA Lead приглашаем всех желающих на бесплатный двухдневный интенсив в рамках которого изучим теоретические основы методов тестирования требований. Рассмотрим использование User Story и критериев приемки для тестирования бизнес-требований. Изучим Example Mapping как способ протестировать технические требования. А также попрактикуемся в построении Example Mapping.
Классификация видов тестирования
Вы решили дать новый виток своей карьере и попробовать силы в QA? Это отличная идея! И начать своё знакомство с тестированием ПО стоит с основ.
Поиск багов в программных продуктах отличается в зависимости от конечной цели. Алгоритм выявления дефектов сайта при переводе страницы на иностранный язык и определении предельной нагрузки будет отличаться методами, инструментами и привлекаемыми к процессу специалистами.
Многие тестировщики со временем приобретают специализацию, но обучение неизменно начинается с базовых знаний и навыков. Итак, чтобы вам было проще разобраться во всём многообразии QA-областей, мы расскажем о ключевых видах тестирования.
1. Цель
Каждый программный продукт должен выполнять одну или несколько ключевых задач. От приложения с гео-картами мы ожидаем точной ориентации в пространстве, от сайта интернет-магазина ― корректного поиска товаров по заданным параметрам и т. д. Но те же программные продукты мы можем протестировать и с точки зрения дизайна.
Таким образом, анализ ПО с позиции его ключевых или вспомогательных функций определяет тип тестирования:
Функциональное тестирование направлено на проверку того, какие функции ПО реализованы, и того, насколько верно они реализованы.
Нефункциональное – проверка корректности работы нефункциональных требований. Оценивается, КАК программный продукт работает. Эта проверка включает в себя следующие виды:
2. Степень автоматизации
В зависимости от того, используют ли тестировщики дополнительные программные средства для тестирования приложений или программ, тестирование бывает:
Каждый из подходов имеет свои преимущества и недостатки. Ручное тестирование проще освоить, оно широко применяется на проектах всех типов, но мануальные проверки отличаются монотонностью. А вот написание тестов даёт больше возможностей для творческой реализации, но автоматизация требует базовых навыков программирования.
Подробнее о плюсах и минусах этих типов тестирования мы рассказали в нашей статье.
3. Позитивность сценария
Этот подход определяет поведение системы в привычных и экстремальных условиях.
Эти типы тестирования нередко проводятся параллельно. Ведь работая над некоторой функциональностью, тестировщику проще оценить её поведение и в стандартных, и в нестандартных условиях.
4. Доступ к коду программного продукта
В процессе тестирования инженер может работать с ПО, не обращаясь к его коду, а может определить правильность работы, взглянув на код. По доступу к коду программного продукта тестирование делится на:
Проверка программного продукта по каждому из сценариев требует достаточно глубоких знаний. К примеру, об особенностях тестирования «чёрного ящика» в своей книге подробно рассказал Борис Бейзер. Это фундаментальная работа, с которой полезно ознакомиться каждому на старте работы в QA. Об этой и других полезных книгах мы рассказали в статье.
5. Уровень
Этот пункт определяет объект тестирования.
Переход на каждую новую ступень – движение от микроуровня к макро. Это важный этап тестирования, ведь безошибочно написанные модули могут просто не работать вместе.
Узнать больше об особенностях каждого из уровней тестирования вы сможете на базовом курсе Академии, а закрепить навыки – на продвинутом курсе.
6. Исполнитель
От объекта тестирования движемся к его субъекту. Вы могли слышать об альфа- и бета-тестировании. А поучаствовать в одном из них можно, даже не будучи тестировщиком. Итак, по исполнителю тестирование делится на:
7. Формальность
Этот пункт определяет подготовленность тестировщика перед началом проверки.
Начинающие тестировщики редко работают на свободном уровне. А вот опытные QA-специалисты могут позволить себе проверку без дополнительной подготовки. Мастерство растёт со временем, как и оплата труда тестировщика. О том, сколько получают инженеры, читайте в нашем блоге.
8. Важность
QA-область очень многообразна. Помимо отличий в технологии оценки качества, тип тестирования может отличаться индустрией или видом программного продукта. К примеру, начинающий тестировщик может выбрать для себя специализацию:
Надеемся, с этой статьёй вам будет проще ориентироваться в самом начале пути в тестировании программного обеспечения. А что ещё поможет на старте карьеры? Обучение на курсе QA Academy. Записывайтесь прямо сейчас!
Что такое глубина тестирования
Тема 12. Классификация тестирования на уровни, виды и типы
Тесты существенно различаются по задачам, которые с их помощью решаются, и по используемой технике. Различие задач тестирования приводит, естественным образом, к необходимости использовать весьма разнообразные типы (виды) тестирования. Принято подразделять тестирование на виды по следующим категориям:
Тем не менее, основная классификация тестов на виды производится в соответствие с традиционными показателями качества, которые проверяются с их помощью.
12.1. Уровни тестирования
Модульное тестирование (Автономное или Unit-тестирование)
Входные требования — Архитектура компонентов или модель “нижнего уровня” системы (Component Design или Low Level Design)
Объект тестирования — Разработанные компоненты
Определение: На данном уровне тестируются по отдельности небольшие элементы системы, максимально отделенные от других элементов и, в то же время, пригодные для тестирования. Такое тестирование обычно проводится сразу же вслед за разработкой каждого из элементов и направлено на оценку соответствия функциональности каждого из компонентов спроектированной “модели компонентов”.
Комплексное тестирование (Сборочное тестирование, integration testing или interface testing)
Входные требования — Архитектура системы или модель “верхнего уровня” системы (System Design или High Level Design)
Объект тестирования — Собранная из компонентов система или подсистема
Определение: На данном уровне тестируются объединенные элементы (компоненты или подсистемы) общей системы, чаще всего некоторая взаимодействующая между собой группа элементов.
Комплексное тестирование направлено не на проверку функционирования каждого из компонентов, а на проверку взаимодействия компонентов в соответствии с «Архитектурой системы».
Тесты данного уровня обычно проверяют все интерфейсы взаимодействия между компонентами, определенные в системной архитектуре, до тех пор, пока все компоненты не будут разработаны, отлажены и проинтегрированы друг с другом в единую систему.
Системное тестирование (system testing)
Входные требования — Системные спецификации (System Specification)
Объект тестирования — Разработанная система
Определение: После того, как система собрана из составляющих компонентов, она должна быть протестирована на соответствие “Системным спецификациям” – реализованы ли все функциональные и нефункциональные требования к разрабатываемой системе.
На данном уровне тестируется приложение или система (одно или более приложений) целиком.
Приемочное тестирование (Приемо-сдаточное тестирование или acceptance testing)
Входные требования — Требования (Requirements)
Объект тестирования — Разработанная система
Определение: На данном уровне завершенное приложение (система) тестируется Заказчиком, конечными пользователями или соответствующими уполномоченными с целью определения соответствия системы “Требованиям Заказчика” и готовности системы к внедрению. Приемосдаточные испытания оформляют процесс передачи продукта от Разработчика Заказчику. В зависимости от особенностей продукта и от требований Заказчика они могут проводиться в различной форме. Например, в виде альфа- или бета-тестирования.
Приемочное тестирование схоже с системным тестированием, но со следующим различием:
Операционное тестирование (Release Testing)
Входные требования — Бизнес модель (Business Case или Business Model)
Объект тестирования — Разработанная система
Определение: Даже если система удовлетворяет всем требованиям, важно убедиться в том, что она удовлетворяет нуждам пользователя и выполняет свою роль в среде своей эксплуатации, как это было определено в бизнес-модели системы. Следует учесть, что и Бизнес модель может содержать ошибки. Поэтому так важно провести операционное тестирование как финальный шаг Валидации.
Кроме этого, тестирование в среде эксплуатации позволяет выявить и нефункциональные проблемы, такие как: конфликт с другими системами, смежными в области бизнеса или в программных и электронных окружениях; недостаточная производительность системы в среде эксплуатации и др.
Очевидно, что нахождение подобных вещей на стадии внедрения – критичная и дорогостоящая проблема. Поэтому так важно проведение не только верификации, но и валидации, с самых ранних этапов разработки ПО.
Основное разделение тестов на виды по объектам тестирования, или, точнее, на уровни тестирования, было произведено нами при определении обобщенной модели ЖЦ ТП. Уровни тестирования приведены ниже. Для каждого уровня тестирования могут использоваться различные виды тестирования, для каждого из которых, в свою очередь, могут использоваться различные типы тестовых испытаний.
12.2. Виды тестирования
Инсталляционное тестирование (Installation testing)
Определение: В процессе инсталляционного тестирования проверяется корректность установки и деинсталляции программного продукта в среде максимально приближенной к эксплуатационной. Проверка правильности установки программного продукта должна быть обязательным элементом проекта по тестированию любого продукта.
Цель: Основная цель состоит в том, чтобы убедиться, что продукт может быть установлен/деинсталлирован при различных условиях – таких как: новая инсталляция, усовершенствование системы (upgrade), установка по умолчанию, полная установка, установка по выбору.
Дымное тестирование (проверка на дым, Smoke testing)
Определение: Первый прогон программы (после написания или после внесения существенных изменений). Как правило, используется для определения, готова ли программа для проведения более обширного тестирования.
Цель: Выявление проблем «лежащих на поверхности» – тестируется чаще всего основная бизнес логика программы
Функциональное тестирование (Functional testing)
Определение: Проверка соответствия продукта функциональным требованиям и спецификациям
Цель: Проверка соответствия продукта функциональным требованиям и спецификациям
Определение: Повторное тестирование после внесения изменений в программное обеспечение или в его окружение (в новой версии приложения), чтобы убедиться в том, что функции, которые работали в предыдущей версии системы, по-прежнему работают так, как ожидалось, а найденные дефекты успешно исправлены (все протестированное ранее тестируется повторно)
Цель: Выявление потенциальных проблем, которые могли возникнуть в результате изменений. Проверка исправления найденных ранее дефектов.
Интеграционное тестирование (Integration testing)
Определение: Проверка скомбинированных компонентов прикладной программы с целью определения корректности их совместного функционирования
Цель: Выявление потенциальных проблем в совместном функционировании компонент
Тестирование графического интерфейса пользователя (User Interface testing)
Определение: Тестирование интерфейса – экранов, кнопок и т.д. Большая часть функциональности ПО реализуется, как правило, через пользовательский интерфейс.
Цель: Обнаружение ошибок в интерфейсе и поиск ошибок в функциональности посредством интерфейса
Тестирование производительности (Performance testing)
Определение: Проверка скорости работы системы (время отклика, частота транзакций и другие зависящие от времени) в имитационной и реальной средах
Цель: Установить реальную производительность программного продукта
Нагрузочное тестирование (Load testing)
Определение: Это те же тесты производительности, при которых система подвергается различным нагрузкам; при этом цель этого тестирования – оценить способность системы правильно функционировать при некотором превышении планируемых нагрузок при реальной эксплуатации (система имеет некоторый «запас прочности»)
Цель: Убедиться в том, что система работает соответственно ожидаемым рабочим нагрузочным параметрам (какой предел работоспособности)
Стресс тестирование (Stress testing)
Определение: Является одним из разновидностей тестирования на производительность. Проверяется поведение системы при недостатке ресурсов (дискового пространства, обрывов сети и т.д.).
Цель: Проверка того, что система адекватно реагирует на те или иные стрессовые ситуации
Конфигурационное тестирование (Configuration testing)
Определение: Конфигурационное тестирование – тестирование работы на различных платформах. Различные варианты аппаратной конфигурации, версии операционной системы и окружения.
Цель: Проверить работоспособность системы при различных конфигурациях
Тестирование интернационализации (Internationalization testing)
Определение: Этот вид тестирует насколько продукт готов к тому, чтобы быть адаптированном для работы в других локалях с другим языком пользовательского интерфейса, отличном от языка по умолчанию (как правило, это английский)
Цель: Проверить способность продукта быть быстро локализованным под необходимую локаль потенциальных пользователей системы
Локализационное тестирование (Localization testing)
Определение: Локализационное тестирование, в свою очередь, проверяет, правильно ли локализован продукт. То есть, переведен на другой язык и корректно работает с учетом национальных особенностией страны или региона, в котором будет продаваться и использоваться продукт.
Цель: Проверить, правильно ли локализован продукт
Классификация тестов на виды производится в соответствие с традиционными показателями качества, которые проверяются с их помощью. Иными словами, разделение тестирования на виды происходит в зависимости от типа требований (функциональные, нефункциональные), проверяемых с помощью тестов.
Для проверки функциональности (functionality) ПО необходимо испытать приложенние на выполнение функциональных требований к нему (сценариев использования и др.). Для этого используются собственно функциональные тесты, а также тесты безопасности, объема и другие.
Тестирование надежности (reliability) ПО производится с целью проверки нефункциональных требований, что приложение работает, как и ожидалось, устойчиво к падениям и т.п. Здесь применяются интеграционные тесты, тесты структуры, стрессовые тесты и другие.
Тестирование удобства использования (usability) ПО (нефункциональные требования) производится с целью удостовериться в том, что приложение удобно для использования его конечным пользователям. Включает в себя тесты на человеческий фактор, эстетику интерфейса и его непротиворечивость, наличие и качество оперативной и контекстной помощи, руководств и учебных материалов.
Тестирование производительности (performance) ПО выполняется с целью удостовериться, что функционирование приложения обеспечивается в то время, когда выполняются нефункциональные требования к приложению по работе в реальных условиях. Включает в себя оценку временных профилей, времени отклика, операционной надежности и некоторых других характеристик. Основные виды тестирования приведены ниже.
12.3. Типы тестовых испытаний по глубине тестирования.
Приемочный тест (Smoke test) – первый и самый короткий тест, призванный проводить проверку основных элементов программного продукта и его работоспособности в целом. В случае функционального тестирования – проверяется основной функционал приложения. Тест занимает 1-4 часа в зависимости от сложности тестируемого продукта. На основе результатов данного теста принимается решение о приемке версии программного продукта и продолжении тестирования текущей версии продукта более серьезными тестовыми испытаниями.
Критический тест (Critical path test) – основной тип тестовых испытаний, во время которого значимые элементы и функции приложения проверяются на предмет правильности работы при стандартном их использовании. Как правило, на данном уровне тестирования проверяется основная масса требований к продукту.
Расширенный тест (Extended test) – вид углубленного тестирования, при котором проверяется нестандартное использование программного продукта, границы переполнения массивов данных, ввод специальных символов и т.п.