QA

Этапы тестирования

1. Анализ 2. Разработка стратегии тестирования и планирование процедур контроля качества 3. Работа с требованиями 4. Создание тестовой документации 5. Тестирование прототипа 6. Основное тестирование 7. Стабилизация 8. Эксплуатация

Уровни Тестирования

1. Модульное тестирование (Unit Testing) 2. Интеграционное тестирование (Integration Testing) 3. Системное тестирование (System Testing) 4. Операционное тестирование (Release Testing). 5. Приемочное тестирование (Acceptance Testing)

Функциональные виды тестирования

• Функциональное тестирование (Functional testing) • Тестирование безопасности (Security and Access Control Testing) • Тестирование взаимодействия (Interoperability Testing) • Регресс • Ретест • Smoke-test

Техники тест дизайна

• Эквивалентное Разделение (Equivalence Partitioning — EP) • Анализ Граничных Значений (Boundary Value Analysis — BVA) • Причина / Следствие (Cause/Effect — CE) • Предугадывание ошибки (Error Guessing — EG) • Исчерпывающее тестирование (Exhaustive Testing — ET)

Нагрузочное тестирование

это автоматизированное тестирование, имитирующее работу определенного количества бизнес пользователей на каком-либо общем (разделяемом ими) ресурсе

«RAD Model» (rapid application development model или быстрая разработка приложений)

RAD-модель — разновидность инкрементной модели. В RAD-модели компоненты или функции разрабатываются несколькими высококвалифицированными командами параллельно, будто несколько мини-проектов. Временные рамки одного цикла жестко ограничены. Созданные модули затем интегрируются в один рабочий прототип. Синергия позволяет очень быстро предоставить клиенту для обозрения что-то рабочее с целью получения обратной связи и внесения изменений. Модель быстрой разработки приложений включает следующие фазы: Бизнес-моделирование: определение списка информационных потоков между различными подразделениями. Моделирование данных: информация, собранная на предыдущем этапе, используется для определения объектов и иных сущностей, необходимых для циркуляции информации. Моделирование процесса: информационные потоки связывают объекты для достижения целей разработки. Сборка приложения: используются средства автоматической сборки для преобразования моделей системы автоматического проектирования в код. Тестирование: тестируются новые компоненты и интерфейсы. Когда используется RAD-модель? Может использоваться только при наличии высококвалифицированных и узкоспециализированных архитекторов. Бюджет проекта большой, чтобы оплатить этих специалистов вместе со стоимостью готовых инструментов автоматизированной сборки. RAD-модель может быть выбрана при уверенном знании целевого бизнеса и необходимости срочного производства системы в течение 2-3 месяцев.

В чем разница между regression testing и re-testing?

Re-testing — проверяется исправление багов Regression testing — проверяется то, что исправление багов не повлияло на другие модули ПО и не вызвало новых багов.

SOAP против REST

SOAP более применим в сложных архитектурах, где взаимодействие с объектами выходит за рамки теории CRUD, а вот в тех приложениях, которые не покидают рамки данной теории, вполне применимым может оказаться именно REST ввиду своей простоты и прозрачности. Действительно, если любым объектам вашего сервиса не нужны более сложные взаимоотношения, кроме: «Создать», «Прочитать», «Изменить», «Удалить» (как правило — в 99% случаев этого достаточно), возможно, именно REST станет правильным выбором. Кроме того, REST по сравнению с SOAP, может оказаться и более производительным, так как не требует затрат на разбор сложных XML команд на сервере (выполняются обычные HTTP запросы — PUT, GET, POST, DELETE). Хотя SOAP, в свою очередь, более надежен и безопасен.

SQL

UPDATE tbl_name SET col_name1=expr1 [, col_name2=expr2, ...] [WHERE where_definition] INSERT INTO tbl_name (col1,col2) VALUES(15,col1*2) DELETE FROM table_name [WHERE where_definition]

Требования к требованиям

• Корректность • Недвусмысленность • Полнота набора требований • Непротиворечивость набора требований • Проверяемость (тестопригодность) • Трассируемость • Понимаемость

«Spiral Model» (спиральная модель)

«Спиральная модель» похожа на инкрементную, но с акцентом на анализ рисков. Она хорошо работает для решения критически важных бизнес-задач, когда неудача несовместима с деятельностью компании, в условиях выпуска новых продуктовых линеек, при необходимости научных исследований и практической апробации. Спиральная модель предполагает 4 этапа для каждого витка: планирование; анализ рисков; конструирование; оценка результата и при удовлетворительном качестве переход к новому витку. Эта модель не подойдет для малых проектов, она резонна для сложных и дорогих, например, таких, как разработка системы документооборота для банка, когда каждый следующий шаг требует большего анализа для оценки последствий, чем программирование.

«Agile Model» (гибкая методология разработки)

В «гибкой» методологии разработки после каждой итерации заказчик может наблюдать результат и понимать, удовлетворяет он его или нет. Это одно из преимуществ гибкой модели. К ее недостаткам относят то, что из-за отсутствия конкретных формулировок результатов сложно оценить трудозатраты и стоимость, требуемые на разработку. Экстремальное программирование (XP) является одним из наиболее известных применений гибкой модели на практике. В основе такого типа — непродолжительные ежедневные встречи — «Scrum» и регулярно повторяющиеся собрания (раз в неделю, раз в две недели или раз в месяц), которые называются «Sprint». На ежедневных совещаниях участники команды обсуждают: отчёт о проделанной работе с момента последнего Scrum'a; список задач, которые сотрудник должен выполнить до следующего собрания; затруднения, возникшие в ходе работы. Методология подходит для больших или нацеленных на длительный жизненный цикл проектов, постоянно адаптируемых к условиям рынка. Соответственно, в процессе реализации требования изменяются. Стоит вспомнить класс творческих людей, которым свойственно генерировать, выдавать и опробовать новые идеи еженедельно или даже ежедневно. Гибкая разработка лучше всего подходит для этого психотипа руководителей. Внутренние стартапы компании мы разрабатываем по Agile. Когда использовать Agile? Когда потребности пользователей постоянно меняются в динамическом бизнесе. Изменения на Agile реализуются за меньшую цену из-за частых инкрементов. В отличие от модели водопада, в гибкой модели для старта проекта достаточно лишь небольшого планирования.

«Incremental Model» (инкрементная модель)

В инкрементной модели полные требования к системе делятся на различные сборки. Терминология часто используется для описания поэтапной сборки ПО. Имеют место несколько циклов разработки, и вместе они составляют жизненный цикл «мульти-водопад». Цикл разделен на более мелкие легко создаваемые модули. Каждый модуль проходит через фазы определения требований, проектирования, кодирования, внедрения и тестирования. Процедура разработки по инкрементной модели предполагает выпуск на первом большом этапе продукта в базовой функциональности, а затем уже последовательное добавление новых функций, так называемых «инкрементов». Процесс продолжается до тех пор, пока не будет создана полная система. Инкрементные модели используются там, где отдельные запросы на изменение ясны, могут быть легко формализованы и реализованы. Когда использовать инкрементную модель? Когда основные требования к системе четко определены и понятны. В то же время некоторые детали могут дорабатываться с течением времени. Требуется ранний вывод продукта на рынок. Есть несколько рисковых фич или целей

Сверху вниз (Top Down Integration)

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

Большой взрыв («Big Bang» Integration)

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

Снизу вверх (Bottom Up Integration)

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

Интеграционное тестирование (Integration Testing)

Направлена на проверку взаимодействия между несколько ми частями приложения, каждая из частей в свою очередь была ранее проверена на стадии модульного тестирования. К сожалению, даже если мы работаем с очень качественными отдельными компонентами, «на стыке» их взаимодействия часто возникают проблемы. Именно эти проблемы и выявляет интеграционные тестирование.

Операционное тестирование (Release Testing)

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

Анализ Граничных Значений (Boundary Value Analysis — BVA)

Если взять пример выше, в качестве значений для позитивного тестирования выберем минимальную и максимальную границы (1 и 10), и значения больше и меньше границ (0 и 11). Анализ Граничный значений может быть применен к полям, записям, файлам, или к любого рода сущностям имеющим ограничения.

Объемное тестирование (Volume Testing)

Задачей объемного тестирования является получение оценки производительности при увеличении объемов данных в базе данных приложения

Тестирование стабильности или надежности (Stability / Reliability Testing)

Задачей тестирования стабильности (надежности) является проверка работоспособности приложения при длительном (многочасовом) тестировании со средним уровнем нагрузки.

«Iterative Model» (итеративная или итерационная модель)

Итерационная модель жизненного цикла не требует для начала полной спецификации требований. Вместо этого, создание начинается с реализации части функционала, становящейся базой для определения дальнейших требований. Этот процесс повторяется. Версия может быть неидеальна, главное, чтобы она работала. Понимая конечную цель, мы стремимся к ней так, чтобы каждый шаг был результативен, а каждая версия — работоспособна. На диаграмме показана итерационная «разработка» Мона Лизы. Как видно, в первой итерации есть лишь набросок Джоконды, во второй — появляются цвета, а третья итерация добавляет деталей, насыщенности и завершает процесс. В инкрементной же модели функционал продукта наращивается по кусочкам, продукт составляется из частей. В отличие от итерационной модели, каждый кусочек представляет собой целостный элемент. Примером итерационной разработки может служить распознавание голоса. Первые исследования и подготовка научного аппарата начались давно, в начале — в мыслях, затем — на бумаге. С каждой новой итерацией качество распознавания улучшалось. Тем не менее, идеальное распознавание еще не достигнуто, следовательно, задача еще не решена полностью. Когда оптимально использовать итеративную модель? Требования к конечной системе заранее четко определены и понятны. Проект большой или очень большой. Основная задача должна быть определена, но детали реализации могут эволюционировать с течением времени.

Эквивалентное Разделение (Equivalence Partitioning — EP)

Как пример, у вас есть диапазон допустимых значений от 1 до 10, вы должны выбрать одно верное значение внутри интервала, скажем, 5, и одно неверное значение вне интервала — 0.

Traceability matrix

Матрица соответствия требований — это двумерная таблица, содержащая соответсвие функциональных требований (functional requirements) продукта и подготовленных тестовых сценариев (test cases). В заголовках колонок таблицы расположены требования, а в заголовках строк — тестовые сценарии. На пересечении — отметка, означающая, что требование текущей колонки покрыто тестовым сценарием текущей строки. Матрица соответсвия требований используется QA-инженерами для валидации покрытия продукта тестами. МСТ является неотъемлемой частью тест-плана.

Системное тестирование (System Testing)

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

Модульное тестирование (Unit Testing, Component Testing)

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

«Waterfall Model» (каскадная модель или «водопад»)

Одна из самых старых, подразумевает последовательное прохождение стадий, каждая из которых должна завершиться полностью до начала следующей. В модели Waterfall легко управлять проектом. Благодаря её жесткости, разработка проходит быстро, стоимость и срок заранее определены. Каскадная модель будет давать отличный результат только в проектах с четко и заранее определенными требованиями и способами их реализации. Нет возможности сделать шаг назад, тестирование начинается только после того, как разработка завершена или почти завершена. Продукты, разработанные по данной модели без обоснованного ее выбора, могут иметь недочеты (список требований нельзя скорректировать в любой момент), о которых становится известно лишь в конце из-за строгой последовательности действий. Стоимость внесения изменений высока, так как для ее инициализации приходится ждать завершения всего проекта. Тем не менее, фиксированная стоимость часто перевешивает минусы подхода. Исправление осознанных в процессе создания недостатков возможно, и, по нашему опыту, требует от одного до трех дополнительных соглашений к контракту с небольшим ТЗ. Когда использовать каскадную методологию? Только тогда, когда требования известны, понятны и зафиксированы. Противоречивых требований не имеется. Нет проблем с доступностью программистов нужной квалификации. В относительно небольших проектах.

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

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

Принципы тестирования

Принцип 1 — Тестирование демонстрирует наличие дефектов (Testing shows presence of defects) Тестирование может показать, что дефекты присутствуют, но не может доказать, что их нет. Тестирование снижает вероятность наличия дефектов, находящихся в программном обеспечении, но, даже если дефекты не были обнаружены, это не доказывает его корректности. Принцип 2 — Исчерпывающее тестирование недостижимо (Exhaustive testing is impossible) Полное тестирование с использованием всех комбинаций вводов и предусловий физически невыполнимо, за исключением тривиальных случаев. Вместо исчерпывающего тестирования должны использоваться анализ рисков и расстановка приоритетов, чтобы более точно сфокусировать усилия по тестированию. Принцип 3 — Раннее тестирование (Early testing) Чтобы найти дефекты как можно раньше, активности по тестированию должны быть начаты как можно раньше в жизненном цикле разработки программного обеспечения или системы, и должны быть сфокусированы на определенных целях. Принцип 4 — Скопление дефектов (Defects clustering) Усилия тестирования должны быть сосредоточены пропорционально ожидаемой, а позже реальной плотности дефектов по модулям. Как правило, большая часть дефектов, обнаруженных при тестировании или повлекших за собой основное количество сбоев системы, содержится в небольшом количестве модулей. Принцип 5 — Парадокс пестицида (Pesticide paradox) Если одни и те же тесты будут прогоняться много раз, в конечном счете этот набор тестовых сценариев больше не будет находить новых дефектов. Чтобы преодолеть этот «парадокс пестицида», тестовые сценарии должны регулярно рецензироваться и корректироваться, новые тесты должны быть разносторонними, чтобы охватить все компоненты программного обеспечения, или системы, и найти как можно больше дефектов. Принцип 6 — Тестирование зависит от контекста (Testing is concept depending) Тестирование выполняется по-разному в зависимости от контекста. Например, программное обеспечение, в котором критически важна безопасность, тестируется иначе, чем сайт электронной коммерции. Принцип 7 — Заблуждение об отсутствии ошибок (Absence-of-errors fallacy) Обнаружение и исправление дефектов не помогут, если созданная система не подходит пользователю и не удовлетворяет его ожиданиям и потребностям.

Исследовательское / ad-hoc тестирование

Простейшее определение исследовательского тестирования — это разработка и выполнения тестов в одно и то же время. Что является противоположностью сценарного подхода (с его предопределенными процедурами тестирования, неважно ручными или автоматизированными). Исследовательские тесты, в отличие от сценарных тестов, не определены заранее и не выполняются в точном соответствии с планом. Разница между ad hoc и exploratory testing в том, что теоретически, ad hoc может провести кто угодно, а для проведения exploratory необходимо мастерство и владение определенными техниками. Обратите внимание, что определенные техники это не только техники тестирования.

Cтатическое и динамическое тестирование

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

«V-Model»

Унаследовала структуру «шаг за шагом» от каскадной модели. V-образная модель применима к системам, которым особенно важно бесперебойное функционирование. Например, прикладные программы в клиниках для наблюдения за пациентами, интегрированное ПО для механизмов управления аварийными подушками безопасности в транспортных средствах и так далее. Особенностью модели можно считать то, что она направлена на тщательную проверку и тестирование продукта, находящегося уже на первоначальных стадиях проектирования. Стадия тестирования проводится одновременно с соответствующей стадией разработки, например, во время кодирования пишутся модульные тесты. Когда использовать V-модель? Если требуется тщательное тестирование продукта, то V-модель оправдает заложенную в себя идею: validation and verification. Для малых и средних проектов, где требования четко определены и фиксированы. В условиях доступности инженеров необходимой квалификации, особенно тестировщиков.

Приемочное тестирование (Acceptance Testing)

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

Предугадывание ошибки (Error Guessing — EG)

Это когда тест аналитик использует свои знания системы и способность к интерпретации спецификации на предмет того, чтобы «предугадать» при каких входных условиях система может выдать ошибку. Например, спецификация говорит: «пользователь должен ввести код». Тест аналитик, будет думать: «Что, если я не введу код?», «Что, если я введу неправильный код? », и так далее. Это и есть предугадывание ошибки.

Причина / Следствие (Cause/Effect — CE)

Это, как правило, ввод комбинаций условий (причин), для получения ответа от системы (Следствие). Например, вы проверяете возможность добавлять клиента, используя определенную экранную форму. Для этого вам необходимо будет ввести несколько полей, таких как «Имя», «Адрес», «Номер Телефона» а затем, нажать кнопку «Добавить» — эта «Причина». После нажатия кнопки «Добавить», система добавляет клиента в базу данных и показывает его номер на экране — это «Следствие».

Тестирование установки

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

Стрессовое тестирование (Stress Testing)

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

Тестирование программного обеспечения

проверка соответствия между реальным и ожидаемым поведением программы, осуществляемая на конечном наборе тестов, выбранном определенным образом. Техника контроля качества, включающая в себя активности по планированию работ (Test Management), проектированию тестов (Test Design), выполнению тестирования (Test Execution) и анализу полученных результатов (Test Analysis).

Тестирование на отказ и восстановление (Failover and Recovery Testing)

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

Функциональное тестирование

рассматривает заранее указанное поведение и основывается на анализе спецификаций функциональности компонента или системы в целом.

Конфигурационное тестирование (Configuration Testing)

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

Тестирование сборки или Build Verification Test

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

Дымовое (Smoke)

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

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

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

Тестовый случай (Test Case)

это артефакт, описывающий совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части. PreConditions Список действий, которые приводят систему к состоянию пригодному для проведения основной проверки. Либо список условий, выполнение которых говорит о том, что система находится в пригодном для проведения основного теста состояния. Test Case Description Список действий, переводящих систему из одного состояния в другое, для получения результата, на основании которого можно сделать вывод о удовлетворении реализации, поставленным требованиям PostConditions Список действий, переводящих систему в первоначальное состояние (состояние до проведения теста — initial state) Виды Тестовых Случаев: Тест кейсы разделяются по ожидаемому результату на позитивные и негативные: • Позитивный тест кейс использует только корректные данные и проверяет, что приложение правильно выполнило вызываемую функцию. • Негативный тест кейс оперирует как корректными так и некорректными данными (минимум 1 некорректный параметр) и ставит целью проверку исключительных ситуаций (срабатывание валидаторов), а также проверяет, что вызываемая приложением функция не выполняется при срабатывании валидатора.

Регрессионное тестирование

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

Тест план (Test Plan)

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

Чек-лист (check list)

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

Исчерпывающее тестирование (Exhaustive Testing — ET)

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

Тестирование удобства пользования

это метод тестирования, направленный на установление степени удобства использования, обучаемости, понятности и привлекательности для пользователей разрабатываемого продукта в контексте заданных условий. Сюда также входит: Тестирование пользовательского интерфейса (англ. UI Testing) — это вид тестирования исследования, выполняемого с целью определения, удобен ли некоторый искусственный объект (такой как веб-страница, пользовательский интерфейс или устройство) для его предполагаемого применения. User eXperience (UX) — ощущение, испытываемое пользователем во время использования цифрового продукта, в то время как User interface — это инструмент, позволяющий осуществлять интеракцию «пользователь — веб-ресурс».

Дефект (он же баг)

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

Валидация (validation)

это определение соответствия разрабатываемого ПО ожиданиям и потребностям пользователя, требованиям к системе. Оценка соответствия продукта ожиданиям и требованиям пользователей — есть валидация (validation). Validation — 'is this the right specification?'.

Подходы к интеграционному тестированию

• Снизу вверх (Bottom Up Integration) • Сверху вниз (Top Down Integration) • Большой взрыв («Big Bang» Integration)

Верификация (verification)

это процесс оценки системы или её компонентов с целью определения удовлетворяют ли результаты текущего этапа разработки условиям, сформированным в начале этого этапа. Т.е. выполняются ли наши цели, сроки, задачи по разработке проекта, определенные в начале текущей фазы. Процесс оценки соответствия продукта явным требованиям (спецификациям) и есть верификация (verification). Verification — 'is the system correct to specification?'.

Веб-сервисы

это реализация абсолютно четких интерфейсов обмена данными между различными приложениями, которые написаны не только на разных языках, но и распределены на разных узлах сети. - SOAP (Simple Object Access Protocol) — по сути это тройка стандартов SOAP/WSDL/UDDI - REST (Representational State Transfer) - XML-RPC (XML Remote Procedure Call)

Качество программного обеспечения (Software Quality)

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

Требования

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

Тестирование безопасности

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

Санитарное тестирование

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

Тестирование взаимодействия (Interoperability Testing)

это функциональное тестирование, проверяющее способность приложения взаимодействовать с одним и более компонентами или системами и включающее в себя тестирование совместимости (compatibility testing) и интеграционное тестирование

Тест дизайн

это этап процесса тестирования ПО, на котором проектируются и создаются тестовые случаи (тест кейсы), в соответствии с определёнными ранее критериями качества и целями тестирования. Роли, ответственные за тест дизайн: • Тест аналитик — определяет «ЧТО тестировать?» • Тест дизайнер — определяет «КАК тестировать?»

Стадии разработки ПО

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

Нефункциональные виды тестирования

• Все виды тестирования производительности: - нагрузочное тестирование (Performance and Load Testing) - стрессовое тестирование (Stress Testing) - тестирование стабильности или надежности (Stability / Reliability Testing) - объемное тестирование (Volume Testing) • Тестирование установки (Installation testing) • Тестирование удобства пользования (Usability Testing) • Тестирование на отказ и восстановление (Failover and Recovery Testing) • Конфигурационное тестирование (Configuration Testing)

Связанные с изменениями виды тестирования

• Дымовое тестирование (Smoke Testing) • Регрессионное тестирование (Regression Testing) • Повторное тестирование (Re-testing) • Тестирование сборки (Build Verification Test) • Санитарное тестирование или проверка согласованности/исправности (Sanity Testing)