Процесс оценки по с целью убедиться что оно удовлетворяет потребности пользователя

BYTEX BLOG

Андерклокинг — снижение частоты работы оборудования.

Баг (дефект) — недостаток компонента или системы, который может привести к отказу определенной функциональности.

Приоритет багов — важность той или иной ошибки в ПО:

• Trivial — косметическая малозаметная проблема.
• Minor — очевидная, незначительная проблема.
• Major — значительная проблема.
• Critical — проблема, нарушающая работу c ключевыми функциями ПО.
• Blocker — проблема, нарушающая функционирование ПО.

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

Валидация — определение соответствия разрабатываемого ПО ожиданиям и потребностям пользователя, требованиям к системе.

Верификация — процесс оценки системы или её компонентов с целью определения удовлетворяют ли результаты текущего этапа разработки условиям, сформированным в начале этого этапа.

Спецификация — детальное описание того, как должно работать ПО.

Система отслеживания ошибок (англ. bug tracking system) — программа учета и/или контроля багов:

• Atlassian JIRA
• Bugzilla
• YouTrack
• Redmine
• etc.

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

Обеспечение качества (Quality Assurance, QA) — совокупность мероприятий, охватывающих все технологические этапы разработки, выпуска и эксплуатации программного обеспечения

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

Ошибка (англ.Error) – действие, которое порождает неправильный результат.

Сбой (англ.Failure) – несоответствие фактического результата работы компонента или системы ожидаемому результату.

Классификация по типу тестирования:
Мобильное тестирование — тестирование мобильных приложений.
Консольное тестирование — тестирование приложений предназначенных для консолей.
Web-тестирование (Браузерное тестирование) — тестирование браузерных приложений.

Классификация по запуску кода на исполнение:
Статическое тестирование (англ.Static testing) — тестирование без запуска кода на исполнение.
Динамическое тестирование (англ. Dynamic testing) — тестирование с запуском кода на исполнение.

Классификация по доступу к коду и архитектуре ПО:
Черный ящик (англ. Black box) — тестировщику не известно как устроена тестируемая система.
Белый ящик (англ. White box) — тестировщику известно все детали реализации тестируемой системы.
Серый ящик (англ. Grey box) — тестировщику известно только некоторые особенности устройства тестируемой системы.

Классификация по степени автоматизации:
Ручное тестирование (англ. Manual testing) — тестирование ПО будучи его пользователем.
Автоматизированное тестирование (англ. Automated testing) — тестирование ПО при помощи специальных программ.

Классификация по принципу работы с приложением:
Позитивное тестирование (англ. Positive testing) — тестирование ПО на то, как оно должно работать.
Негативное тестирование (англ. Negative testing) — тестирование ПО на то, как оно не должно работать.

Классификация по уровню детализации приложения:
Интеграционное тестирование — тестирование взаимодействия и связей нескольких компонентов приложения.
Системное тестирование — это тестирование всего приложения от начала и до конца.
Модульное тестирование — тестирование на уровне отдельного функционального компонента приложения.

Классификация по целям и задачам:
Функциональное тестирование — проверка корректности работы функциональности приложения.
Нефункциональное тестирование — проверка нефункциональных особенностей приложения (удобство использования, совместимость, производительность, безопасность).
Инсталляционное тестирование — проверка протекания стадии инсталляции (установки) приложения.
Регрессионное тестирование — проверка на наличие багов, вызванных изменениями в приложении.
Повторное тестирование — выполнение тест-кейсов, которые ранее обнаружили дефекты, с целью подтверждения устранения дефектов.
Приёмочное тестирование — тестирование, направленное на проверку приложения с точки зрения конечного пользователя/заказчика
Тестирование удобства использования — тестирование, направленное на исследование того, насколько конечному пользователю понятно, как работать с продуктом, а также на то, насколько ему нравится использовать продукт.
Тестирование доступности — тестирование, направленное на исследование пригодности продукта к использованию людьми с ограниченными возможностями
Тестирование интерфейса — тестирование, направленное на проверку интерфейсов приложения или его компонентов.
Тестирование безопасности — тестирование, направленное на проверку способности приложения противостоять злонамеренным попыткам получения доступа к данным или функциям
Тестирование интернационализации — тестирование, направленное на проверку готовности продукта к работе с использованием различных языков и с учётом различных национальных и культурных особенностей.
Тестирование локализации — тестирование, направленное на проверку корректности и качества адаптации продукта к использованию на том или ином языке с учётом национальных и культурных особенностей.
Тестирование совместимости — тестирование, направленное на проверку способности приложения работать в указанном окружении (браузер, мобильное ус-во и т.д.).
Тестирование данных и баз данных — тестирование, направленное на исследование таких характеристик данных, как полнота, непротиворечивость, целостность, структурированность и т.д.
Тестирование использования ресурсов — совокупность видов тестирования, проверяющих эффективность использования приложением доступных ему ресурсов и зависимость результатов работы приложения от количества доступных ему ресурсов.
Сравнительное тестирование — тестирование, направленное на сравнительный анализ преимуществ и недостатков разрабатываемого продукта по отношению к его основным конкурентам.
Демонстрационное тестирование — формальный процесс демонстрации заказчику продукта с целью подтверждения, что продукт соответствует всем заявленным требованиям.
Избыточное тестирование — тестирование приложения со всеми возможными комбинациями всех возможных входных данных во всех возможных условиях выполнения.
Тестирование надёжности — тестирование способности приложения выполнять свои функции в заданных условиях.
Тестирование восстанавливаемости — тестирование способности приложения восстанавливать свои функции и заданный уровень производительности, а также восстанавливать данные в случае возникновения критической ситуации.
Тестирование отказоустойчивости — тестирование, заключающееся в эмуляции или реальном создании критических ситуаций с целью проверки способности приложения задействовать механизмы, предотвращающие нарушение работоспособности, производительности и повреждения данных.
Тестирование производительности — исследование показателей скорости реакции приложения на внешние воздействия при различной по характеру и интенсивности нагрузке.
Нагрузочное тестирование — исследование способности приложения сохранять заданные показатели качества при нагрузке в допустимых пределах и некотором превышении этих пределов/
Тестирование масштабируемости — исследование способности приложения увеличивать показатели производительности в соответствии с увеличением количества доступных приложению ресурсов.
Объёмное тестирование — исследование производительности приложения при обработке различных (как правило, больших) объёмов данных.
Стрессовое тестирование — исследование поведения приложения при нештатных изменениях нагрузки, значительно превышающих расчётный уровень.
Конкурентное тестирование — исследование поведения приложения в ситуации, когда ему приходится обрабатывать большое количество одновременно поступающих запросов, что вызывает конкуренцию между запросами за ресурсы (базу данных, память, канал передачи данных, дисковую подсистему и т.д.)
Фокус-тест (англ. Focus test) — тестирование, проводимое с целью получения первичной реакции игроков. Необходимо для оценки удобства использования и того, как продукт принимается целевой аудиторией или сторонними людьми.

Failure — сбой (причём не обязательно аппаратный) в работе компонента, всей программы или системы.

UX (англ. User eXperience — опыт пользователя) — ощущение, испытываемое пользователем во время использования цифрового продукта.

UI (англ. User Interface — пользовательский интерфейс) — это инструмент, позволяющий осуществлять взаимодействие «пользователь — приложение».

Анализ граничных значений (англ. Boundary Value Analysis — BVA). Анализ граничных значений может быть применен к полям, записям, файлам, или к любого рода сущностям имеющим ограничения.

Дымовое тестирование (англ. Smoke test) — короткий цикл тестов для подтверждения, что после сборки кода (нового или исправленного) приложение стартует и выполняет основные функции.

Исследовательское (ad-hoc) тестирование — это разработка и выполнения тестов в одно и то же время, что является противоположностью сценарного подхода.

Конфигурационное тестирование (англ. Configuration Testing) — специальный вид тестирования, направленный на проверку работы программного обеспечения при различных конфигурациях системы (заявленных платформах, поддерживаемых драйверах, при различных конфигурациях компьютеров и т.д.)

Матрица соответствия требований (англ. Traceability matrix) — это двумерная таблица, содержащая соответсвие функциональных требований (functional requirements) продукта и подготовленных тестовых сценариев (test cases).

Операционное тестирование (англ. Release Testing). Даже если система удовлетворяет всем требованиям, важно убедиться в том, что она удовлетворяет нуждам пользователя и выполняет свою роль в среде своей эксплуатации, как это было определено в бизнес модели системы.

Предугадывание ошибки (англ. Error Guessing — EG). Это когда тест аналитик использует свои знания системы и способность к интерпретации спецификации на предмет того, чтобы «предугадать» при каких входных условиях система может выдать ошибку.

Причина / Следствие (англ. Cause/Effect — CE). Это, как правило, ввод комбинаций условий (причин), для получения ответа от системы (Следствие).

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

Серьезность (англ. Severity) — это атрибут, характеризующий влияние дефекта на работоспособность приложения.

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

Пре-альфа (англ. Pre-alpha) — начальная стадия разработки. Период времени со старта разработки до выхода стадии Альфа. Также так называются программы, прошедшие стадию разработки, для первичной оценки функциональных возможностей в действии.

Альфа-тестирование (англ. Alpha testing) — имитация реальной работы с системой штатными разработчиками, либо реальная работа с системой потенциальными пользователями/заказчиком на ранней стадии разработки продукта, но в некоторых случаях может применяться для законченного продукта в качестве внутреннего приёмочного тестирования.

Бета-тестирование (англ. Beta testing) — интенсивное использование почти готовой версии продукта с целью выявления максимального числа ошибок в его работе для их последующего устранения перед окончательным выходом (релизом) продукта на рынок, к массовому потребителю.

Релиз-кандидат или RC (англ. Release candidate), Пре-релиз, иногда «гамма-версия» — стадия-кандидат на то, чтобы стать стабильной.

Релиз или RTM (англ. Release to manufacturing — промышленное издание) — издание продукта, готового к тиражированию.

Пост-релиз или Post-RTM (англ. Post-release to manufacturing) — издание продукта, у которого есть несколько отличий от RTM и помечается как самая первая стадия разработки следующего продукта.

Таблица принятия решений (англ. Decision table) — инструмент для упорядочения сложных бизнес требований, которые должны быть реализованы в продукте.

Тест-дизайн (англ. Test design) — это этап процесса тестирования ПО, на котором проектируются и создаются тестовые случаи (тест кейсы).

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

Тестирование взаимодействия (англ. Interoperability Testing) — это функциональное тестирование, проверяющее способность приложения взаимодействовать с одним и более компонентами или системами.

Тестирование сборки (англ. Build Verification Test) — тестирование направленное на определение соответствия, выпущенной версии, критериям качества для начала тестирования.

Тестирование пользовательского интерфейса (англ. UI Testing) — тестирование, выполняемое с целью определения, удобен ли некоторый искусственный объект (такой как веб-страница, пользовательский интерфейс или устройство) для его предполагаемого применения.

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

Чек-лист (англ. Check list) — это документ, описывающий что должно быть протестировано.

Эквивалентное Разделение (англ. Equivalence Partitioning — EP). Как пример, у вас есть диапазон допустимых значений от 1 до 10, вы должны выбрать одно верное значение внутри интервала, скажем, 5, и одно неверное значение вне интервала — 0.

Z-конфликт (англ. Z-fighting) — наложение текстур друг на друга.

Оверклокинг (англ. Overclocking) — процесс увеличения частоты (и напряжения) компонента компьютера сверх штатных режимов с целью увеличения скорости его работы.

Зачем вам нужен QA и как это позволит сэкономить деньги

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

В этой статье речь пойдёт не о том, как QA-инженеры делают свою работу. Мы поговорим о том, почему обеспечение качества (Quality Assurance, QA) — незаменимая часть процесса разработки.

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

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

Так чем занимаются QA-инженеры? Они:

• Выявляют слабые места и несоответствия в продукте на всех этапах разработки;
• Помогают определить требования к проекту;
• Предоставляют исчерпывающую информацию о качестве продукта;
• Тестируют продукт на протяжении всех фаз жизненного цикла разработки системы (software development lifecycle, SDLC).

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

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

Когда вам нужен QA?

В этой части статьи мы опишем, что и когда делают QA. Этапы, описанные ниже, являются общими (и обобщёнными) частями цикла тестирования программного обеспечения (software testing life cycle, STLC).

Сбор требований

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

Во многих компаниях анализ требований к функциональности является обязанностью бизнес-аналитиков. Однако они не могут гарантировать совместимость технических компонентов. Поэтому на этом этапе кроме бизнес-аналитиков заняты и другие специалисты, включая QA. Задачи последних включают:

1. Анализ и принятие решения о том, совместимы ли между собой требования, и могут ли они быть реализованы в рамках одной системы.
2. Оценка того, какие решения будут работать, а какие — нет.
3. Планирование необходимых методов тестирования (подробнее об этом ниже).

Валидация — процесс оценки проекта до начала разработки с целью выяснить, удовлетворяет ли потенциальный продукт требованиям пользователей и стоит ли вкладывать в эту идею усилия.

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

До прохождения валидации продукт может и не дойти до потребителя, даже если он отлично сделан с технической точки зрения. Также на этом этапе проверяется, принесёт ли продукт пользу клиенту. Иначе зачем вообще этим заниматься?

Планирование тестирования

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

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

Разработка тестов

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

Выполнение тестов

Этот этап многие считают единственной задачей QA — выполнение всех тест-кейсов по плану. Если какая-то часть системы работает хорошо, мы отмечаем её как прошедшую тестирование. Таким образом мы можем удостовериться, что ничего не пропустим и на выходе получим качественный продукт.

Если тест-кейс прошёл неудачно, значит в коде есть ошибка, и QA отправляют отчёт разработчикам, чтобы они проверили, что не так.

Отчёт о результатах

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

Что такое цикл тестирования? Это частота, с которой мы проводим эти пять этапов тестирования.

Особенности работы QA

Множество компаний-разработчиков программного обеспечения работают спринтами — даётся список задач и две недели на их выполнение. Во время каждого спринта мы реализуем определённую часть требований к продукту и проходим через все пять стадий тестирования. Важно понимать, что тестирование не подразумевает только проверку каждого способа взаимодействия с продуктом. Конечно, и это тоже, но зачастую с системой можно сделать гораздо больше.

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

Теперь, когда мы знаем о циклах тестирования, можно вкратце рассказать, почему каждой команде нужен QA:

• Безопасный бизнес. У вас есть платёжная система, и она работает нормально. Пользователь платит за услугу и получает её. Однако вы не проверили все возможные случаи, и деньги идут не вам, а на случайный банковский счёт. Такой недочёт может очень дорого обойтись;
• Экономия денег. На приведённой ниже диаграмме хорошо видна взаимосвязь между этапами жизненного цикла и затратами. Гораздо дороже исправить ошибку, чем предотвратить её. Исправление одной ошибки может повлечь за собой другие, поэтому количество ваших проблем будет быстро увеличиваться;
• Защита репутации. Если выпустить багованный продукт и пользователи не будут довольны работой с ним, в дальнейшем их будет сложно убедить, что проблема решена и они могут снова им пользоваться. Первое впечатление сложно изменить, поэтому предоставьте качественный продукт. Если он не был протестирован вдоль и поперёк, то продукт может работать неправильно или не работать вовсе. Тестирование требует теоретических знаний, поэтому будет сложно обеспечить качество, если вы не профессионал;
• Контроль процесса. Если процесс разработки не контролируется и идёт вразрез с установленными требованиями, итоговый продукт может сильно отличаться от запланированного.

Вы могли заметить, что часто упоминается тестирование. Это потому, что есть такая отдельная дисциплина, как контроль качества (Quality Control, QC). Далее мы поговорим о работе QA, о разнице QA и QC, взаимосвязи SDLC и STLC, а также дадим детальное описание некоторых методов тестирования, используемых QA-инженерами.

QA

Обеспечение качества и контроль качества

Контроль качества (Quality Control, QC) охватывает всю деятельность, направленную на то, чтобы убедиться, что продукт хорошего качества и отвечает заданным требованиям. QC-инженеры занимаются поиском дефектов в продукте до его выпуска. Можно сказать, что обеспечение качества включает в себя контроль качества.

Есть случаи, когда продукт не требует QA, а только QC. Например, если команда получает продукт, разрабатываемый другими людьми, с целью проверить, соответствует ли код требованиям.

В некоторых командах QA и QC совмещаются с другими ролями. Иногда разработчики пытаются проверить свой собственный код. Тем не менее, это сказывается на качестве, так как гораздо сложнее найти ошибки в своём коде, чем в чужом.

Цикл разработки программного обеспечения и цикл тестирования

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

Надеемся, нам удалось вас убедить в важности одновременного проведения SDLC и STLC. Теперь мы перейдём к некоторым популярным методам составления тестов, которые QA-инженеры используют для обеспечения качества.

Методы составления теста

Тест-кейс (или просто тест) — пошаговый подход к тестированию функциональности программного продукта. По сути сюда входят тестируемый объект и способ тестирования.

Метод составления теста — процесс выбора тестов, которые подтвердят, что продукт соответствует спецификациям до его релиза.

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

На картинке ниже представлены основные методы составления теста:

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

Статический. Этот метод тестирует исходный код, функциональные спецификации и спецификации требований до выполнения кода (до выхода в релиз). Этот метод определяет структурные недостатки. Это не одноразовая работа, поэтому мы стараемся начать её на ранних этапах процесса разработки.

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

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

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

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

В заключение

Неважно, каким простым кажется продукт, ведь в основе его качества лежит тонна проделанной работы. Как заметил Дон Норман, «Хороший дизайн гораздо сложнее заметить, чем плохой». В большинстве случаев QA-инженеры дают людям возможность наслаждаться продуктом, проверив, что всё работает хорошо.

Обеспечение качества включает много всего, от тестирования до анализа результатов. Большинству программных продуктов нужны QA-инженеры, чтобы:

1. Контролировать процесс разработки.
2. Предотвращать ошибки в системе до того, как их найдут пользователи.
3. Обеспечивать качество выпускаемого продукта.

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

РУБРИКА «ЭКСПЕРТЫ SOLAR INRIGHTS»: Тестировщик – это адвокат пользователя!

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

О важности процесса тестирования и о работе подразделения тестирования в Solar inRights рассказывает руководитель отдела тестирования Алёна Зубкова.

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

Тестирование ПО – это проверка соответствия между реальным поведением программы и ее ожидаемым поведением.

В широком смысле слова тестирование – это одна из техник контроля качества, включающая активности:

• По планированию работ
• Разработке тестов
• Выполнению самого тестирования
• Анализу полученных результатов

Если говорить о целях тестирования, то это прежде всего повышение вероятности:

• что система, которую мы разработали, решает заявленные пользователем проблемы и не создает новых;
• что система будет работать правильно при известных предлагаемых обстоятельствах;
• что система будет соответствовать описанным требованиям.

Помимо этого, тестирование предоставляет нам актуальную информацию о состоянии системы на данный момент.

Чем грозит заказчику исключение тестирования из процесса поставки ПО?

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

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

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

Отсутствие тестирования конкретно решений IdM несет риски непредоставления, несвоевременного предоставления или ошибочного предоставления доступов, что, безусловно, скажется на работе компании.

Таким образом, тестирование дает нам уверенность в корректности и безопасности работы системы. А отсутствие такой уверенности обессмыслило саму ее разработку.

Почему сам разработчик не может проводить тестирование ПО?

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

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

На каких этапах жизненного цикла ПО необходим тестировщик?

Если говорить коротко, то на всех.

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

С какими артефактами работает тестировщик?

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

Первая группа – это требования, инженерная документация, документация разработчиков и дизайн-проекты:

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

В процессе труда тестировщик создает следующие артефакты:

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

Есть ли какие-то особенности в подходе к тестированию в Solar inRights?

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

Отличается ли тестирование IdM-систем от тестирования другого ПО?

Главная особенность в тестировании IdM-решений заключается в том, что оно строится на стыке профессии тестировщика, как изначально междисциплинарной сферы, и специфики нашего продукта. IdM-система – это априори сложный продукт, и его тестирование требует целого ряда навыков. И не только технических – hard skills, но и тех, которые принято назвать soft-skills. Управление доступом с помощью IdM – это управление доступом в интегрированных c нашим решением информационных системах. Это означает, что нам необходимы знания как теоретические, так и практические по работе конкретных систем (объектной модели, конфигурирования, скриптовых языков и т. д.). Наши доработки, которые могут изначально показаться простыми и очевидными, в итоге оказываются достаточно многогранными и требуют всеобъемлющего тест-анализа, применения различных техник тестирования, подходов, технических навыков. Помимо этого, важны навыки коммуникации, планирования, разрешения проблем, управления рисками. У нас тестировщик – это всегда командный игрок, причем достаточно самоотверженный.

На проектах IdM применяется ручное или автоматизированное тестирование?

Когда мы говорим о ручном и автоматизированном тестировании, я предпочитаю примять именно союз «и», потому что проблемы начинаются там, где потерян баланс. Часто в подходе к тестированию сознательно или неосознанно делается крен: или в сторону мануального тестирования, или автоматизированного тестирования. Мы в своей работе руководствуемся принципом разумной достаточности и считаем, что затраты на организацию автоматизированного тестирования и его поддержку должны быть оправданны и целесообразны. У нас, как правило, ручное тестирование нацелено на то, чтобы найти дефекты по сложным сценариям использования. Автотесты – это небольшой кластер проверок, который позволяет удостовериться в том, что в целом по основным сценариям система работает корректно, и облегчить регресc, это значительный набор проверок, который позволяет нам убедиться, что после внесения изменений система целиком работает корректно. Такой подход помогает нам экономить время и повышать мотивацию. Потому что тестировщики высвобождаются от рутинных задач по регреcсу для выполнения более сложной, интересной и творческой работы и своего развития.

В каких случаях выгодно применение автотестов?

Здесь нужно понять, через какое количество итераций начнет окупаться автоматизированное тестирование, т. е. окупятся затраты на его разработку, организацию и внедрение. Есть ряд требований к критериям, которым должны соответствовать сценарии тестирования для того, чтобы быть пригодными для автоматизации. Это сценарии частого использования или сценарии, по которым в ближайшее время не планируется изменений. У нас автоматизирована бо́льшая часть регресса, и это нам здорово помогает экономить время.

Можно ли переиспользовать автотесты из проекта в проект?

В зависимости от того, о каком проекте мы говорим. У нас есть два подхода. Есть типовые проекты, которые основаны на продуктовом ядре, и здесь, конечно, можно говорить о том, что часть автотестов может быть переиспользована для стандартных сценариев работы IdM. Но есть и уникальные крупномасштабные проекты со своими особенностями, для которых уже автотесты должны разрабатываться отдельно. В любом случае, даже если говорить не только о тестировании, всегда, когда можно что-то переиспользовать – подход, процесс, автотест, инструкции, компетенции и т. д., – нужно это делать. И мы к этому стремимся.

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

Мы не отходим от методик и стандартов индустрии в целом. Но это нам не мешает и применять собственные наработки. Они проходят апробацию и, если показывают хорошие результаты, мы их масштабируем. У нас любой тестировщик, будь то стажер или уже зрелый специалист, может выйти с предложением по улучшению и будет услышан. Все лучшие практики мы обязательно описываем и делаем доступными не только подразделению тестирования, а всей нашей большой команде направления inRights. Это помогает нам сокращать время на решение задач.

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

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

Какими качествами должен обладать тестировщик?

Главные качества — это адаптивность, любознательность и неравнодушие. Что людей толкает становиться тестировщиками? Я считаю, что это обостренное чувство справедливости, т. е. когда ты хочешь, чтобы все было правильно, чтобы мир становился лучше, и сам желаешь принимать активное участие в его улучшении.

Качества, которые можно назвать ключевыми для тестировщика в inRights – это заточенность на общее дело, на результат, на эффективные коммуникации внутри команды и на процессы. У нас отсутствует классическое противостояние между разработкой и тестированием, когда, например, тестировщик, найдя дефект, радуется. А мы слегка расстраиваемся, потому что наш подход к процессу производства заставляет нас понимать, сколько сил затрачено всей командой. Производство – это командная игра, и найденный дефект – это повод для всей команды подумать над тем, как в следующий раз на ранних этапах производства подобную ошибку не допустить. Этому способствует высокий уровень вовлеченности и личной ответственности тестировщика и значимость тестирования в процессе производства. У нас тестирование не формальное, оно встроено в систему обеспечения качества, влияет на него, и доводы тестирования учитываются и в целом в процессе, и в разработке конкретного функционала. Такое встречается не всегда и не везде. Это возможно, когда мы понимаем, что мы все в одной лодке и плывем к общей цели. Т. е. создаем продукт, за который мы можем испытывать гордость и радость от удовлетворения заказчика.

Цель верификации и валидации в тестировании программного обеспечения

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

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

Что такое верификация?

При верификации команда разработчиков изучает документы для создания программного обеспечения или приложения. Цель состоит в том, чтобы убедиться, что разработчик, которому поручен проект, соблюдает все изложенные требования. Логика кода должна соответствовать проектной документации независимо от языка программирования.

Процесс верификации

Он включает следующие этапы:

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

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

После того как команда подтверждает, что все вышеперечисленное соответствует требуемым стандартам, начинается процесс верификации:

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

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

Что такое валидация?

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

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

Процесс валидации

Он включает следующие этапы:

На этом этапе команда описывает все бизнес-требования конечного пользователя. Затем составляется план валидации для каждого пункта, прежде чем подтвердить готовность программного обеспечения к разработке. После этого команда может получить одобрение от высшего руководства перед началом тестирования.

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

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

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

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

Зачем проводится верификация и валидация?

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

Уменьшить количество дефектов в реальном продукте

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

Убедиться, что дизайн соответствует техническим условиям

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

Заметные различия между верификацией и валидацией

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

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

Когда следует выбрать верификацию?

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

Когда следует выбрать валидацию?

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

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

Преимущества верификации

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

Преимущества валидации

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

• software testing
• verification
• validation
• тестирование по
• тестирование веб-приложений
• тестирование мобильных приложений

• Тестирование IT-систем
• Тестирование веб-сервисов
• Тестирование мобильных приложений
• Тестирование игр