В наших веб-проектах перед выпуском мы делаем минимальное тестирование: смотрим в разных браузерах, сжимаем окна, открываем с мобилки. Но в крупных проектах этого явно недостаточно. Рассказываем, как тестируют боевые коммерческие сайты и зачем это нужно делать.
Коротко про тестирование
Тестирование — это когда программу, сайт или что угодно ещё проверяют на работу в стандартных и нестандартных условиях.
Тестированием занимаются отдельные люди — инженеры по тестированию, или QA (quality assurance, ОТК, отдел контроля качества). Они вручную или с помощью других программ проверяют работу продукта. Например:
- запускают его на разных устройствах — от супербыстрых до очень медленных;
- вводят все возможные значения в поля ввода;
- нажимают на все кнопки подряд;
- запускают сотню копий программы и входят по очереди в каждую из них;
- отключают интернет во время работы программы;
- выключают питание в любой момент, а потом пробуют запустить всё снова;
- смотрят, что будет, если нажать кнопки не в той последовательности, что предполагалось;
- и делают ещё сотню других проверок.
Это тестирование внешнего контура. А ещё есть тестирование внутренних модулей программы — им чаще всего занимаются сами разработчики. Например, они вешают автоматические тестирующие функции на каждый смысловой блок программы. И потом, когда что-то меняется в коде, достаточно одним движением запустить все автотесты, чтобы проверить, что ничего внутри программы не сломалось.
Тестирование НА ПРИМЕРЕ | Тестирую DEVBY
Цель тестирования — найти слабые места и исправить их заранее, до того, как продукт выйдет в свет. Если интересно погрузиться в тестирование подробнее, то вот с чего можно начать:
- Кто такой инженер по тестированию и стоит ли на него учиться
- Зарплата 113 тысяч за то, чтобы ломать программы
- Тестируем и исправляем калькулятор на JavaScript
- Словарь тестировщика: автотесты, юнит-тесты и другие важные слова
- Какой софт нужен, чтобы стать тестировщиком
Зачем тестировать сайты
На сайт может зайти кто угодно и с любого устройства: быстрого, медленного, устаревшего, с большим экраном, с очень маленьким экраном, напрямую, через VPN или отключив показ рекламы в браузере. Было бы здорово, если бы во всех этих случаях сайт выглядел так, как задумал разработчик.
Чтобы всё это проверить, тестировщики моделируют все эти условия и смотрят, что получилось. Например, вот как выглядит наш проект с игрой Wordle в браузере на компьютере:
А вот так он будет выглядеть, если его открыть со старого айфона:
Ещё все пользуются разными браузерами. В редакции мы проверяем работу сайтов только в Хроме и Сафари (потому что пользуемся ими сами), но кроме них есть ещё Opera, Opera Mini, Edge, Mozilla Firefox и Internet Explorer. По-хорошему нам надо бы проверять все проекты ещё и в них.
Что делает тестировщик, мой рабочий день | тестирование ПО | Тестировщик | QA Engineer
В жизни такое бы не прокатило — тестировщики проверяют работу сайта во всех браузерах и на всех доступных устройствах.
А ещё разные браузеры по-разному реагируют на некоторые CSS-настройки и команды скриптов — одни что-то поддерживают, другие нет. Из-за этого некоторые кнопки могут перестать работать или могут делать не то, что нужно.
Если вы видите сайт, который одинаково хорошо выглядит и работает с любого устройства и в любом браузере, то знайте, что это, в числе прочего, заслуга инженеров по тестированию.
Что тестируют
Параметров тестирования может быть много — смотря что мы хотим проверить в работе сайта. Вот основные направления, которые попадают в работу к тестировщикам:
- вёрстка (совпадает всё с макетами или нет);
- адаптивность;
- скорость загрузки;
- работа в стресс-условиях (например, при нехватке оперативной памяти);
- скрипты на странице;
- взаимодействие по API с другими сервисами.
Вручную или автоматически
Как тестировать — зависит от задачи и от количества тестов.
Визуальные штуки, например отступы, размеры шрифтов и адаптивность, тестируют вручную, открывая сайт на разных устройствах. Ещё вручную проверяют последовательность элементов на странице, цвета, анимацию и всё, что влияет на внешний вид сайта.
У некоторых компаний внедрены автотестеры вёрстки: они автоматически снимают скриншот с эталонной рабочей страницы и потом сличают его со скриншотами этой же страницы в разных браузерах.
Автотесты используют для тестирования скриптов, особенно когда они сложные и внутри много функций. Для этого пишут специальный код, который виртуально вызывает нужные команды и смотрит, как они работают. Если тест выдаёт ошибку, функция отправляется на доработку.
Сколько нужно устройств
Никто не мешает завести себе много устройств для тестирования сайта на всём — от смарт-часов до смарт-ТВ. Но в большинстве случаев это не нужно.
В Google Chrome встроено множество инструментов для отладки и тестирования страниц:
- симуляция устройств с разными размерами экрана;
- симуляция медленного процессора, медленного интернета и сброса кэша;
- график загрузки разных ресурсов: сколько ждали ответа на запрос, сколько получали ответ, кто за чем что загрузил, кто где затупил;
- определение момента, когда страницу пришлось жёстко перерисовать из-за внезапной прогрузки чего-то большого и важного.
Вот как выглядит наша учебная страничка в этом симуляторе:
Надо помнить, что это всё равно симуляция на базе движка «Хрома» и со всеми его нюансами. В Safari, Edge, Firefox и Opera могут быть другие нюансы, поэтому дополнительно нужно прогонять свой сайт в других браузерах.
Есть сервисы, которые дают погонять сразу несколько браузеров в одном окне — например BrowserStack. Там прямо обещают, что у них лежат настоящие устройства, подключённые к облаку, и вы смотрите на картинку прямо из их настоящего браузера.
Ничто не мешает установить на свой компьютер несколько виртуальных машин и проверять работу сайта в них, например работать в Mac OS и иметь виртуальные машины с Windows и Linux. То есть в теории можно управиться со всем на одном устройстве. Но, говорят, ощущения не те.
Валидация страницы
Кроме тестов есть ещё валидация — то есть техническая сверка страницы с текущими веб-стандартами. В частности:
- соответствие кода стандартам HTML5;
- скорость загрузки;
- все ли ресурсы загружаются на страницу (картинки, стили и скрипты);
- как загружается мобильная версия и достаточно ли она мобильная;
- есть ли альтернативный текст у картинок;
- слабые места при загрузке — например, когда вся загрузка стопорится из-за одного скрипта на чужом сервере.
Все эти проверки можно сделать через онлайн-сервисы. Поищите HTML 5 Validation или Webpage validation.
Если поисковая машина зайдёт на страницу, которая не адаптируется под мобилку и долго грузится, такой странице будет назначен низкий рейтинг и пользователи не будут её видеть в результатах поиска. Валидация нужна, среди прочего, чтобы поисковикам нравилась страничка.
Где научиться
Самый простой способ научиться всему этому и стать инженером по тестированию — пойти в «Практикум» на курс «Инженер по тестированию». После него вы сможете тестировать не только сайты, но и мобильные приложения, базы данных, API и другие системы.
Тестирование — это билет в ИТ
Простой вход в мир ИТ, ваша первая работа и быстрый старт в профессии. Изучите основы — и за дело. Мы поможем с обучением и трудоустройством. Старт бесплатно.
Получите ИТ-профессию
В «Яндекс Практикуме» можно стать разработчиком, тестировщиком, аналитиком и менеджером цифровых продуктов. Первая часть обучения всегда бесплатная, чтобы попробовать и найти то, что вам по душе. Дальше — программы трудоустройства.
Источник: thecode.media
Тестирование программного продукта
Тестирование – ряд мероприятий, связанных с различного рода испытаниями объекта тестирования с целью установления соответствия или несоответствия его характеристик определенным требованиям и выявления дефектов. Дефектами, в свою очередь, могут быть как ошибки в работе, так и неприемлемое качество функционирования в определенных условиях эксплуатации.
Результаты тестирования — это список выявленных несоответствий и дефектов, но, как правило, без указания их причин, хотя, опытный специалист по качеству продукции в состоянии провести первичную диагностику некорректного поведения объекта и сообщить диагноз его разработчикам.
Тестирование программного продукта проводят как на этапах его создания, так и на этапах технического сопровождения и дальнейшего развития. Виды тестирования программных продуктов и их краткое описание я постараюсь представить в этом материале.
Тестирование на этапе создания программного продукта
Виды тестирования на этапе создания программного продукта классифицируют по преследуемым этим процессом целям. Функциональное тестирование — проверка корректного выполнения программой заложенных в нее функций. Нефункциональное тестирование — все прочие виды испытаний, такие как тестирование производительности в различных режимах эксплуатации, тестирование эргономики пользовательского интерфейса, тестирование отказоустойчивости и т.д.
Функциональное тестирование
Для проведения функционального тестирования персоналом отдела технического контроля разрабатывается документ программа и методика испытаний функционала приложения (ПМИ). Документ ПМИ содержит перечень сценариев тестирования программного продукта (test cases) с подробным описанием шагов. Каждый шаг сценария тестирования характеризуется действиями пользователя (специалиста по тестированию) и ожидаемыми результатами – ответной реакции программы на эти действия. Программа и методика испытаний обязана имитировать эксплуатацию программного продукта в реальном режиме. Это означает, что сценарий тестирования должен быть построен на основе анализа операций, которые будут выполнять будущие пользователи системы, а не быть искусственно составленной последовательностью понятных только разработчику манипуляций. Функциональное тестирование может проводиться на различных уровнях тестирования, перечень которых зависит от сложности приложения:
- Компонентное (модульное) тестирование. Тестирование отдельных компонентов программного продукта, сфокусированное на их специфике, назначении и функциональных особенностях.
- Интеграционное тестирование. Данный вид тестирования проводится после компонентного тестирования и направлен на выявление дефектов взаимодействия различных подсистем на уровне потоков управления и обмена данными.
Каждый компонент системы может быть рассмотрен, как отдельная подсистема, и внутри этой подсистемы могут быть выделены ее компоненты. В этом случае для таких подсистем отдельно проводятся компонентное и интеграционное тестирование. Таким образом, для сложных программных продуктов получаем иерархическую структуру процесса тестирования, на каждом уровне которой объектом тестирования является определенная часть программного комплекса.
Пример иерархической структуры процесса тестирования программного продукта.
Выделение уровней может происходить по принципу общей функциональности (подсистема ввода/вывода данных, подсистема расчетов и аналитики, подсистема хранения данных и т.п.), по принадлежности к конкретной части проектного решения (сервер, клиент, посредник), по используемым технологиям, либо по всему сразу. В этом случае тестирование может проводиться снизу вверх, и при каждом переходе на более высокий уровень, протестированные ранее части программы уже выступают в качестве компонентов подсистемы более высокого порядка. Бывает, что проводят тестирование сверху вниз, начиная от испытаний, связанных с общим поведением программы и заканчивая деталями. В этой ситуации может оказаться так, что на высоких уровнях абстракции реализация деталей еще отсутствует и заменяется различного рода имитаторами – функциональными заглушками, которые только со временем, при переходе на более низкие уровни заменяются реальными функциональными компонентами. Такой процесс на ранних этапах является ни чем иным как тестированием прототипа программного продукта.
Нефункциональное тестирование
Нефункциональное тестирование, как следует из самого названия, в первую очередь оценивает второстепенные качества функционирования программного продукта. Второстепенные не в том смысле, что эти качества программного продукта менее важны, чем корректное выполнение им своих основных функций, а в том, что они никому не интересны, если продукт, в принципе, не выполняет то, что должен.
Кому, например, интересны результаты замеров производительности подсистемы расчетов, если сами результаты этих расчетов не верны? Для кого имеет значение удобство пользовательского интерфейса программы, если его работа не приводит к ожидаемым от него результатам? Ну а насчет важности нефункционального тестирования можно сказать так: иногда его результаты имеют более серьезный вес в общей оценке работы программного продукта, чем результаты функционального тестирования. Например, для системы, работающей в реальном времени куда как более важно успевать взаимодействовать со всеми наблюдаемыми внешними объектами, чем корректно, с точки зрения функциональных требований, обрабатывать события от конкретного источника. Повторюсь, что это вовсе не означает, что можно некорректно взаимодействовать с отдельно-взятым объектом в угоду производительности.
Тестирование производительности
Достаточно интересные виды тестирования с точки зрения условий их проведения и оценки результатов. В ходе этапа тестирования производительности в первую очередь проводят нагрузочное тестирование, целью которого является проверка, будет ли система адекватно реагировать на внешние воздействия в режиме, близком к режиму реальной эксплуатации.
Адекватная реакция – это время отклика в пределах, установленных требованиями к программному продукту. Внешние воздействия (нагрузка) – это, чаще всего, запросы пользователей. Ну а режим реальной эксплуатации подразумевает то, что система развернута на соответствующем требованиям аппаратном обеспечении, а самих пользователей примерно столько, сколько и планировалось. Кроме нагрузочного тестирования проводят испытания в условиях минимальных аппаратных средств и максимальной нагрузки – стрессовое тестирование, а также, испытания в условиях предельных объемов обрабатываемой информации – объемное тестирование. Выделяют еще один вид тестирования: тестирование стабильности и надежности, которое включает в себя не только длительное испытание программного продукта в нормальных условиях, но и способность его возвращаться в нормальный режим функционирования после непродолжительных периодов стрессовых нагрузок.
Прочие виды нефункционального тестирования
К прочим видам тестирования относят тестирование процесса установки или развертывания программного продукта, тестирование эргономики пользовательского интерфейса (не корректной его работы, а именно удобства использования), тестирование способности системы к восстановлению нормальной работы после серьезных сбоев, вызванных отказами аппаратного или системного программного обеспечения. Отдельно проводят испытания системы на различных конфигурациях, если требованиями они предусмотрены. Конфигурации могут отличаться вплоть до операционных систем серверной и клиентской частей программного комплекса. Тестирование отдельной конфигурации может сводиться к проведению для нее всего комплекса испытаний программного продукта.
Тестирование на этапе сопровождения программного продукта
Регрессионное тестирование
Регрессионное тестирование проводят по результатам исправления выявленных на этапе эксплуатации программного продукта ошибок и дефектов. Также, к этому виду тестирования относят испытания программного продукта после внесения в него незначительных изменений, которые не должны влиять на общую функциональность, а вызваны такими обстоятельствами, как необходимость перехода на новую версию операционной системы или новый набор прикладных библиотек стороннего производителя. Цель регрессионного тестирование проста: доказать, что “ничего не сломалось”, и что программный продукт по-прежнему соответствует всем заявленным ранее требованиям.
Предварительное тестирование новой версии программного продукта
Комплекс предварительных мероприятий, направленный на то, чтобы быстро показать жизнеспособность новой версии программного продукта или отправить ее на доработку, выявив в максимально короткие сроки наиболее серьезные дефекты. Ключевое слово в определении – быстро. Подобный вид тестирования еще называют дымовым тестированием по аналогии с испытаниями печниками новых печей: если дым не повалил оттуда, откуда не положено, значит все в порядке. Если предварительное тестирование заканчивается успешно, новую версию программного продукта отправляют на более детальное “обследование”, которое включает функциональное и нефункциональное тестирование.
Заключение
Виды и структура процесса тестирования определяются сложностью самого объекта тестирования. То же самое с теми, кто тестирует программный продукт. Ими могут быть и сами программисты (предварительное тестирование), могут быть сотрудники отдела качества компании разработчика, а могут быть и привлеченные ресурсы.
Например, если программа является серийным продуктом, то все ее основные испытания заканчиваются системным тестированием, а потом уже начинаются рекламные кампании и продажи. Если программный продукт – частный заказ, то после системного тестирования проводят еще и приемочное тестирование. И системное тестирование, и приемочное тестирование направлены на комплексное испытание системы (все виды предусмотренного для нее функционального и нефункционального тестирования), но проводятся на разных площадках и с участием разного персонала. Системное тестирование проводится на стороне разработчика, а приемочное на стороне заказчика и на его же аппаратном и системном программном обеспечении. Что касается процесса тестирования на этапе сопровождения, то он может длиться намного дольше, чем сам процесс создания программного решения и прерываться только выпуском абсолютно новой версии программного продукта, после чего все начинается заново.
Курс для начинаю..html»рограммистов на C# и VB.NET.
Построение SQL запросов и работа с базой данных.
Примеры программной Plug-in архитектуры.
Язык разметки XML и его расширения с примерами.
Языки HTML, XHTML и CSS с примерами разметки.
Основы веб-дизайна: решения типовых задач верстки.
Руководство по программированию на PHP для начинающих.
Шаблоны проектирования
Каталог шаблонов проектирования программных компонентов.
Рефакторинг кода
Каталог приемов рефакторинга программного кода.
Источник: codingcraft.ru
Техники тест-дизайна и их предназначение
При создании IT-продукта большую роль играет обеспечение качества – Quality Assurance (QA). Для того, чтобы устранить ошибки и «баги», QA-инженеры в числе прочих инструментов применяют техники тест-дизайна.
Тест-дизайн – это разработка, создание тестов. Каждый тест направлен на проверку конкретного предположения. Например: «Что будет, если пользователь по ошибке кликнет здесь не левой, а правой кнопкой мыши».
QA моделирует набор тестовых случаев (тест-кейсов), чтобы проверить, как приложение ведет себя в разных условиях. Задача специалиста – найти баланс и выявить максимальное количество ошибок при необходимом минимуме тестовых сценариев. При этом нужно проверить все наиболее важные кейсы, поскольку время тестирования ограничено.
Типы тестирования
Статическое тестирование, как следует из названия, не требует запускать программу или приложение и позволяет находить самые очевидные ошибки еще на ранних этапах создания продукта. Например, частью статического тестирования является проверка параметров ПО на соответствие требованиям технического задания, вычитка кода.
Динамическое тестирование требует проверять ПО в действии. Этот вид, в свою очередь, также делится на две обширные группы:
- Техники белого ящика (они же структурное тестирование) применяют в том случае, если специалист хорошо знает архитектуру продукта, его код, «начинку» – то есть может ориентироваться в самой программе.
- Техники черного ящика позволяют проверять работу продукта, не зная внутреннего устройства системы. При этом тестирование проводится на основе требований, указанных в спецификации проекта или в ТЗ.
- Техники серого ящика позволяют тестировать продукт, когда специалист частично знает его внутреннее устройство. Для выполнения тестирования «серого ящика» не нужен доступ к исходному коду.
Этапы тестирования
1. Подготовка. На этом этапе QA-инженер читает проектную документацию, выясняет требования к продукту, прорабатывает план, продумывает стратегию, расставляет задачи по приоритетности и анализирует возможные риски.
2. Непосредственно тестирование. Предварительно специалисты анализируют собранную ранее информацию, составляют список тестируемых функций, знакомятся с уже известными багами, если они есть, пишут тест-кейсы.
Еще раз подчеркнем: принципиально важно стремиться к минимально возможному числу тестов, при этом необходимо, чтобы сценарии находили наибольшее число высокоприоритетных дефектов.
3. Анализ результатов и составление отчетов.
При работе над созданием тестов QA-специалист ориентируется не только на документацию, но и на устные сведения от других QA, аналитиков, разработчиков, менеджеров проекта.
Техники тест-дизайна на примерах
Рассмотрим несколько основных методик, однако, будем помнить, что зачастую их используют в комплексе. Одной техники может быть недостаточно, поскольку она не обеспечит максимальный охват тестовых сценариев.
Эквивалентное разбиение
Метод эквивалентного разбиения позволяет минимизировать число тестов, не создавая сценарий для каждого возможного значения, а выбрав только одно значение из целого класса и приняв за аксиому, что для всех значений в данной группе результат будет аналогичным.
Например, мы тестируем функциональность приложения, позволяющего покупать авиа- и железнодорожные билеты онлайн. Стоимость билета будет зависеть от возраста пассажира, так как дети, студенты и пенсионеры относятся ко льготным категориям.
У нас есть четыре возрастных группы: младше 15 лет, от 15 до 25 лет, старше 25 и младше 60 лет и люди старше 60. При этом, в поле для ввода возраста помещается всего два символа, поэтому указать возраст более 99 лет технически невозможно.
QA-специалисту не нужно писать 99 тестов для каждого возраста, хватит пяти: по одному для каждой возрастной группы (скажем, 10, 18, 35 и 75 лет) и один для случая, если возраст человека превышает 99 лет. Да, последний тест на практике невыполним (поскольку в поле возраста невозможно ввести более двух знаков), и все же не следует забывать об этой проверке.
Граничные значения
Техника граничных значений основана на предположении, что большинство ошибок может возникнуть на границах эквивалентных классов. Она тесно связана с вышеописанной техникой эквивалентного разбиения, из-за чего часто используется с ней в паре. Тогда для примера из предыдущего пункта границами будут являться значения 0, 15, 25, 60 и 99. Граничными значениями будут 0, 1, 14, 15, 16, 24, 25, 26, 59, 60, 61, 98, 99, 100.
Часто сложности возникают, если возрастные категории указаны «внахлест», например, 0-12, 12-25 лет и т.д.
Таблица принятия решений
Другое название метода – матрица принятия решений. Эта техника подходит для более сложных систем, например – двухфакторной аутентификации. Предположим, чтобы войти в систему, пользователю нужно ввести сначала логин и пароль, а затем еще подтвердить свою личность присланным в смс кодом.
Какие возможны сценарии:
1. Правильный логин и правильный пароль.
2. Правильный логин, неправильный пароль.
3. Неправильный логин, правильный пароль.
4. Неправильный логин, неправильный пароль.
Первый из этих сценариев сопровождается либо правильным, либо неправильным вводом смс-кода, итого у нас получается 5 тестов. При этом только один из сценариев приведет к положительному результату (пользователь успешно авторизуется), а остальные закончатся неудачей.
Однако, может быть так, что система выдает разные сообщения в зависимости от того, на каком этапе была допущена ошибка, скажем: invalid login, invalid password. Соответственно, групп потребуется больше, а таблица станет обширнее.
Этот метод хорош тем, что он показывает сразу все возможные сценарии в форме, понятной даже неспециалисту.
Пример таблицы принятия решений
Попарное тестирование
Суть этого метода, также известного как pairwise testing, в том, что каждое значение каждого проверяемого параметра должно быть протестировано на взаимодействие с каждым значением всех остальных параметров. После составления такой матрицы мы убираем тесты, которые дублируют друг друга, оставляя максимальное покрытие при минимальном необходимом наборе сценариев.
Попарное тестирование позволяет обнаружить максимум ошибок без избыточных проверок.
Pairwise testing: пример
Для Parwise достаточно, чтобы каждое значение всех параметров хотя бы единожды сочеталось с другими значениями остальных параметров. Таким образом, матрицу можно значительно сократить. Например:
| № | Браузер | Операционная система | Язык |
| 1 | Opera | Windows | RU |
| 2 | Google Chrome | Linux | RU |
| 3 | Opera | Linux | EN |
| 4 | Google Chrome | Windows | EN |
При составлении матрицы принятия решений для двух браузеров, двух ОС и двух языков было бы нужно 8 сценариев. При попарном тестировании достаточно четырех.
Все это можно просчитать и вручную, но не обязательно – гораздо удобнее автоматизировать процесс. Для этого существует программа попарного независимого комбинированного тестирования – Pairwise Independent Combinatorial Testing (PICT). Для проведения тестирования специалист создает текстовый файл с перечислением и их возможных значений, а затем запускает PICT через cmd – командную строку. Скомбинированные тесты отображаются в виде таблицы в самой консоли. Так же результаты по желанию можно выгрузить в файл Excel.
Пример содержимого файла для программы PICT:
Браузер: Chrome, Opera
ОС: Windows, Linux
Язык: RU, ENG
Пример попарного тестирования
Причина и следствие
Простая проверка базовых действий и их результата. Например, если нажать крестик в правом верхнем углу окна (причина), оно закроется (следствие), и т.д. Этот метод позволяет проверить все возможности системы, а также обнаружить баги и улучшить техническую документацию продукта.
Примерный алгоритм использования техники:
1. Выделяем причины и следствия в спецификациях.
2. Связываем причины и следствия.
3. Учитываем «невозможные» сочетания причин и следствий.
4. Составляем «таблицу решений», где в каждом столбце указана комбинация входов и выходов, т.е. каждый столбец – это готовый тестовый сценарий.
5. Расставляем приоритеты.
Эта техника помогает:
- Определить минимальное количество тестов для нахождения максимума ошибок.
- Выяснить все причины и следствия – таким образом, мы убедимся, что на любые манипуляции с системой у системы будет ответ.
- Найти возможные недочеты в логике описания приложения (что, в свою очередь, поможет улучшить документацию).
Например, QA-специалист тестирует приложение типа “записная книжка”. После ввода всех данных нового контакта и нажатия кнопки Создать (причина) приложение должно автоматически создать карточку с номером телефона, фотографией и ФИО человека (следствие). Тесты покажут, можно ли оставлять одно или несколько полей пустыми, распознает ли система кириллицу, латиницу или оба алфавита, а также другие параметры.
Предугадывание ошибок
Используя свои знания о системе, QA-специалист может «предугадать», при каких входных условиях есть риск ошибок. Для этого важно иметь опыт, хорошо знать продукт и уметь выстроить коммуникации с коллегами.
Например, в спецификации указано, что поле должно принимать код из четырех цифр. В числе возможных тестов:
- Что произойдет, если не ввести код?
- Что произойдет, если не ввести спецсимволы?
- Что произойдет, если ввести не цифры, а другие символы?
- Что произойдет, если ввести не четыре цифры, а другое количество?
Преимущества:
1. Эта проверка эффективна в качестве дополнения к другим техникам.
2. Выявляет тестовые случаи, которые “никогда не должны случиться”.
Недостатки:
1. Техника в значительной степени основана на интуиции.
2. Необходим опыт в тестировании подобных систем.
3. Малое покрытие тестами.
Итоги
Разумеется, этот список далеко не полон и дает только самое общее представление о принципах тестирования и техниках тест-дизайна. Например, исчерпывающее тестирование, покрывающее все возможные сценарии и обнаруживающее все ошибки, существует только в теории. Это связано с тем, что проверка всех параметров и состояний займет слишком много времени. Однако, чем опытнее QA-специалист, тем лучших результатов он может добиться, и для этого важно уметь правильно подбирать и комбинировать техники.
Источник: www.simbirsoft.com