🏆 Рейтинг ІТ-роботодавців 2018: вже зібрано більше 14 000 анкет. Оціни свою компанію!
×Закрыть

Тестирование. Фундаментальная теория

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

Ниже основы основ для повторения перед собеседованием для Trainee and Junior: определение тестирования, качество, верификация / валидация, цели, этапы, тест план, пункты тест плана, тест дизайн, техники тест дизайна, traceability matrix, test case, чек-лист, дефект, error/deffect/failure, баг репорт, severity vs priority, уровни тестирования, виды / типы, подходы к интеграционному тестированию, принципы тестирования, статическое и динамическое тестирование, исследовательское / ad-hoc тестирование, требования, жизненный цикл бага, стадии разработки ПО, decision table, qa/qc/test engineer, диаграмма связей.

Вторая часть про методологии здесь.

Все замечания, корректировки и дополнения очень приветствуются.

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

Качество программного обеспечения (Software Quality) — это совокупность характеристик программного обеспечения, относящихся к его способности удовлетворять установленные и предполагаемые потребности. [Quality management and quality assurance]

Верификация (verification) — это процесс оценки системы или её компонентов с целью определения удовлетворяют ли результаты текущего этапа разработки условиям, сформированным в начале этого этапа[IEEE]. Т.е. выполняются ли наши цели, сроки, задачи по разработке проекта, определенные в начале текущей фазы.
Валидация (validation) — это определение соответствия разрабатываемого ПО ожиданиям и потребностям пользователя, требованиям к системе [BS7925-1].
Также можно встретить иную интерпритацию:
Процесс оценки соответствия продукта явным требованиям (спецификациям) и есть верификация (verification), в то же время оценка соответствия продукта ожиданиям и требованиям пользователей — есть валидация (validation). Также часто можно встретить следующее определение этих понятий:
Validation — ’is this the right specification?’.
Verification — ’is the system correct to specification?’.

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

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

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

Основные пункты тест плана
В стандарте IEEE 829 перечислены пункты, из которых должен (пусть — может) состоять тест-план:
a) Test plan identifier;
b) Introduction;
c) Test items;
d) Features to be tested;
e) Features not to be tested;
f) Approach;
g) Item pass/fail criteria;
h) Suspension criteria and resumption requirements;
i) Test deliverables;
j) Testing tasks;
k) Environmental needs;
l) Responsibilities;
m) Staffing and training needs;
n) Schedule;
o) Risks and contingencies;
p) Approvals.

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

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

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

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

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

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

• Исчерпывающее тестирование (Exhaustive Testing — ET) — это крайний случай. В пределах этой техники вы должны проверить все возможные комбинации входных значений, и в принципе, это должно найти все проблемы. На практике применение этого метода не представляется возможным, из-за огромного количества входных значений.

• Парное тестирование (Pairwise Testing) — это техника формирования наборов тестовых данных. Сформулировать суть можно, например, вот так: формирование таких наборов данных, в которых каждое тестируемое значение каждого из проверяемых параметров хотя бы единожды сочетается с каждым тестируемым значением всех остальных проверяемых параметров.

Допустим, какое-то значений (налог) для человека рассчитывается на основании его пола, возраста и наличия детей — получаем три входных параметра, для каждого из которых для тестов выбираем каким-то образом значения. Например: пол — мужской или женский; возраст — до 25, от 25 до 60, более 60; наличие детей — да или нет. Для проверки правильности расчётов можно, конечно, перебрать все комбинации значений всех параметров:

пол возраст дети
1 мужчина до 25 детей нет
2 женщина до 25 детей нет
3 мужчина 25-60 детей нет
4 женщина 25-60 детей нет
5 мужчина старше 60 детей нет
6 женщина старше 60 детей нет
7 мужчина до 25 дети есть
8 женщина до 25 дети есть
9 мужчина 25-60 дети есть
10 женщина 25-60 дети есть
11 мужчина старше 60 дети есть
12 женщина старше 60 дети есть

А можно решить, что нам не нужны сочетания значений всех параметров со всеми, а мы хотим только убедиться, что мы проверим все уникальные пары значений параметров. Т.е., например, с точки зрения параметров пола и возраста мы хотим убедиться, что мы точно проверим мужчину до 25, мужчину между 25 и 60, мужчину после 60, а также женщину до 25, женщину между 25 и 60, ну и женщину после 60. И точно так же для всех остальных пар параметров. И таким образом, мы можем получить гораздо меньше наборов значений (в них есть все пары значений, правда некоторые дважды):

пол возраст дети
1 мужчина до 25 детей нет
2 женщина до 25 дети есть
3 мужчина 25-60 дети есть
4 женщина 25-60 детей нет
5 мужчина старше 60 детей нет
6 женщина старше 60 дети есть

Такой подход примерно и составляет суть техники pairwise testing — мы не проверяем все сочетания всех значений, но проверяем все пары значений.

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

Тестовый случай (Test Case) — это артефакт, описывающий совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части.
Пример:
Action Expected Result Test Result
(passed/failed/blocked)
Open page «login» Login page is opened Passed

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

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

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

Error — ошибка пользователя, то есть он пытается использовать программу иным способом.
Пример — вводит буквы в поля, где требуется вводить цифры (возраст, количество товара и т.п.).
В качественной программе предусмотрены такие ситуации и выдаются сообщение об ошибке (error message), с красным крестиком которые.
Bug (defect) — ошибка программиста (или дизайнера или ещё кого, кто принимает участие в разработке), то есть когда в программе, что-то идёт не так как планировалось и программа выходит из-под контроля. Например, когда никак не контроллируется ввод пользователя, в результате неверные данные вызывают краши или иные «радости» в работе программы. Либо внутри программа построена так, что изначально не соответствует тому, что от неё ожидается.
Failure — сбой (причём не обязательно аппаратный) в работе компонента, всей программы или системы. То есть, существуют такие дефекты, которые приводят к сбоям (A defect caused the failure) и существуют такие, которые не приводят. UI-дефекты например. Но аппаратный сбой, никак не связанный с software, тоже является failure.

Баг Репорт (Bug Report) — это документ, описывающий ситуацию или последовательность действий приведшую к некорректной работе объекта тестирования, с указанием причин и ожидаемого результата.
Шапка
Короткое описание (Summary) Короткое описание проблемы, явно указывающее на причину и тип ошибочной ситуации.
Проект (Project) Название тестируемого проекта
Компонент приложения (Component) Название части или функции тестируемого продукта
Номер версии (Version) Версия на которой была найдена ошибка
Серьезность (Severity) Наиболее распространена пятиуровневая система градации серьезности дефекта:
• S1 Блокирующий (Blocker)
• S2 Критический (Critical)
• S3 Значительный (Major)
• S4 Незначительный (Minor)
• S5 Тривиальный (Trivial)
Приоритет (Priority) Приоритет дефекта:
• P1 Высокий (High)
• P2 Средний (Medium)
• P3 Низкий (Low)
Статус (Status) Статус бага. Зависит от используемой процедуры и жизненного цикла бага (bug workflow and life cycle)

Автор (Author) Создатель баг репорта
Назначен на (Assigned To) Имя сотрудника, назначенного на решение проблемы
Окружение
ОС / Сервис Пак и т.д. / Браузера + версия / ... Информация об окружении, на котором был найден баг: операционная система, сервис пак, для WEB тестирования — имя и версия браузера и т.д.
...
Описание
Шаги воспроизведения (Steps to Reproduce) Шаги, по которым можно легко воспроизвести ситуацию, приведшую к ошибке.
Фактический Результат (Result) Результат, полученный после прохождения шагов к воспроизведению
Ожидаемый результат (Expected Result) Ожидаемый правильный результат
Дополнения
Прикрепленный файл (Attachment) Файл с логами, скриншот или любой другой документ, который может помочь прояснить причину ошибки или указать на способ решения проблемы

Severity vs Priority
Серьезность (Severity) — это атрибут, характеризующий влияние дефекта на работоспособность приложения.
Приоритет (Priority) — это атрибут, указывающий на очередность выполнения задачи или устранения дефекта. Можно сказать, что это инструмент менеджера по планированию работ. Чем выше приоритет, тем быстрее нужно исправить дефект.
Severity выставляется тестировщиком
Priority — менеджером, тимлидом или заказчиком

Градация Серьезности дефекта (Severity)

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

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

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

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

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

Градация Приоритета дефекта (Priority)
P1 Высокий (High)
Ошибка должна быть исправлена как можно быстрее, т.к. ее наличие является критической для проекта.
P2 Средний (Medium)
Ошибка должна быть исправлена, ее наличие не является критичной, но требует обязательного решения.
P3 Низкий (Low)
Ошибка должна быть исправлена, ее наличие не является критичной, и не требует срочного решения.

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

1. Модульное тестирование (Unit Testing)
Компонентное (модульное) тестирование проверяет функциональность и ищет дефекты в частях приложения, которые доступны и могут быть протестированы по-отдельности (модули программ, объекты, классы, функции и т.д.).

2. Интеграционное тестирование (Integration Testing)
Проверяется взаимодействие между компонентами системы после проведения компонентного тестирования.

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

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

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

Виды / типы тестирования

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

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

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

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

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

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

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

Тестирование пользовательского интерфейса (GUI Testing) — функциональная проверка интерфейса на соответствие требованиям — размер, шрифт, цвет, consistent behavior.

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

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

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

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

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

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

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

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

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

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

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

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

Повторное тестирование — тестирование, во время которого исполняются тестовые сценарии, выявившие ошибки во время последнего запуска, для подтверждения успешности исправления этих ошибок.
В чем разница между regression testing и re-testing?
Re-testing — проверяется исправление багов
Regression testing — проверяется то, что исправление багов, а также любые изменения в коде приложения, не повлияли на другие модули ПО и не вызвало новых багов.

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

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


Подходы к интеграционному тестированию:
• Снизу вверх (Bottom Up Integration)
Все низкоуровневые модули, процедуры или функции собираются воедино и затем тестируются. После чего собирается следующий уровень модулей для проведения интеграционного тестирования. Данный подход считается полезным, если все или практически все модули, разрабатываемого уровня, готовы. Также данный подход помогает определить по результатам тестирования уровень готовности приложения.
• Сверху вниз (Top Down Integration)
Вначале тестируются все высокоуровневые модули, и постепенно один за другим добавляются низкоуровневые. Все модули более низкого уровня симулируются заглушками с аналогичной функциональностью, затем по мере готовности они заменяются реальными активными компонентами. Таким образом мы проводим тестирование сверху вниз.
• Большой взрыв («Big Bang» Integration)
Все или практически все разработанные модули собираются вместе в виде законченной системы или ее основной части, и затем проводится интеграционное тестирование. Такой подход очень хорош для сохранения времени. Однако если тест кейсы и их результаты записаны не верно, то сам процесс интеграции сильно осложнится, что станет преградой для команды тестирования при достижении основной цели интеграционного тестирования.

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

Принцип 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)
Обнаружение и исправление дефектов не помогут, если созданная система не подходит пользователю и не удовлетворяет его ожиданиям и потребностям.

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

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

Разница между ad hoc и exploratory testing в том, что теоретически, ad hoc может провести кто угодно, а для проведения exploratory необходимо мастерство и владение определенными техниками. Обратите внимание, что определенные техники это не только техники тестирования.

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

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

Жизненный цикл бага


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

Программный продукт проходит следующие стадии:
• анализ требований к проекту;
• проектирование;
• реализация;
• тестирование продукта;
• внедрение и поддержка.

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

Жизненный цикл разработки ПО:
• Пре-альфа
• Альфа
• Бета
• Релиз-кандидат
• Релиз
• Пост-релиз

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

QA/QC/Test Engineer

Таким образом, мы можем построить модель иерархии процессов обеспечения качества: Тестирование — часть QC. QC — часть QA.

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


Источники: www.protesting.ru, bugscatcher.net, qalight.com.ua, thinkingintests.wordpress.com, книга ISTQB, www.quizful.net, bugsclock.blogspot.com, www.zeelabs.com, devopswiki.net, hvorostovoz.blogspot.com.

Ресурсы рекомендованные в комментах Sofiya Novachenko: istqbexamcertification.com www.testingexcellence.com

LinkedIn

Лучшие комментарии пропустить

ОК, после прочтения этой статьи курсы QA уже не нужны.

Ще варто загадати про requirement traceability matrix (матриця покриття вимог), в загальному про етапи розробки і місце тестування в цих етапах.
Підходи до Integration Testing — Bottom Up, Top Down, Big Bang.
З тестової документації ще є поняття Quality Assurance Plan, Test Strategy.
Валідація / Верифікація — пояснення і різниця між термінами.
Взагалі класні ресурси istqbexamcertification.com і www.testingexcellence.com де по теорії багато що розжовується і пояснюється.

Gennadii Mishchevskii большое тебе человеческое СПАСИБО!!!!

Кому интересна, обновил информацию. Добавил:
качество, верификация / валидация, traceability matrix, error/deffect/failure, подходы к интеграционному тестированию. Если есть что ещё — пишите )

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

Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

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

Спасибо автору. Как вовремя я нашел эту статью, а то уже понесло читать то, о чем пока что имею мало представления и вряд ли спросят на собеседовании.

Техника тест — дизайна «Исчерпывающие тестирование».
Принцип 2 — «Исчерпывающее тестирование недостижимо (Exhaustive testing is impossible)».
Полезно знать недостижимые техники тест-дизайна :-D
Лучше свои знания сверять с авторитетными источниками.
www.istqb.org/...​-level-syllabus-2011.html
www.dahlan.web.id/...​ware Test Design_Good.pdf вот по техникам неплохая книга.
Подскажите, почему исчерпывающие тестирование отнесли к технике тест — дизайна, какой источник об этом говорит?

Источник: www.protesting.ru/...​/testdesign_technics.html
Техника тест дизайна помогает выбрать входящие значения для теста. Если нужно протестировать, что паспорт выдают с 14 лет, то по технике граничных значений мы возьмём 13 и 14. По исчерпывающему — 0 — 150 (условно). Это тоже своеобразный выбор значений.

по поводу уровней тестирования их больше istqbexamcertification.com/...​-software-testing-levels . А именно:
1. Unit testing:
2. Component testing:
3. Integration testing:
• Big bang integration testing
• Top down
• Bottom up
• Functional incremental
4. Component integration testing:
5. System integration testing:
6. System testing:
7. Acceptance testing:
8. Alpha testing:
9. Beta testing:

не собесе только не говорите, что уровней тестирования 9,
пусть это останется вашей маленькой тайной :)

PS: линк на сайт АТБ не правильный )))

С вашим остроумием — Петросян нервно курит) Открываем стандарт ISTQB и читаем. Если такое сочитание букв -ISTQB вам знакомо)) узнаем много нового для себя — что есть все таки подтипи для выше упомянутых типов тестирования)) а, и еще постарайтесь о release testing найти в стандарте)))

ну куда ж нам, простым смертным, до Вашей крутизны )))))

Ребят, давайте не переходить на личности. Оля права, с ISTQB не посморишь, у Тараса тоже хороший поинт. Если и расписывать всё, то как расширение привычной пятёрки. Далеко не все читали и помнят стандарт. Главное — понимание процесса, а не формальное определение.

Главная проблема, что чаще всего котируются формальные знания, потому «шо так написано в стандарте», а понимает ли человек почему так, и какие есть еще варианты трактовки — совершенно неважно.

Ольга кинула ссылку на коммерческий ресурс и люди котрые это читают, могут подумать, что это официальный источник и там все по ISTQB.
Это не так.
Данный ресурс написан тестировщиком прошедшим сертификацию и решившим поделиться своими знаниями.
Эти данные не являются официальными, и не совсем соответствуют терминоглогии ISTQB
как в разрезе FL так и в разрезе ATM, а являются больше обобщающими, так сказать «для общего развития» )
пруф:

This website is not the official website of ISTQB and we are not affiliated with ISTQB or ITB.

Information provided on this website is unofficial and may be subject to change. Please refer to the official website for official details, dates etc. This site is in no way, shape, or form affiliated with, approved by, authorized by, or otherwise related to the ISTQB, ITB or any of its related boards.

Очень большая просьба Ольге не вводить в заблуждение, не разобравшись в проблематике вопроса )
официальный ресурс организации www.istqb.org

Во, а я думал сайт переделали )

вот это тут дебаты развернулись)) я как человек сдававший ISTQB и как человек которому попадался как раз такой вопрос — нужно было выбрать из списка какие есть уровни тестирования — могу сказать что я права. да, основных 4. но каждый из них имеет свои подвиды. если сайт который я скинула вам доверия не внушает, хотя по нему всегда все готовятся к экзамену, то ок. можете все перечисленные мною виды тестирования попробовать найти тут — glossary.istqb.org . официальный источник)

стандарт ISTQB

ISTQB не стандарт, а комерційна організація яка пропонує своє бачення на тестування

А что тогда стандарт по вашему?

Ну вы ж типа сдали istqb )
Должны знать стандарты по идее)
Там было это, даже вопрос попадается на экзамене)

Ваши комментарии направлены на то чтобы унизить человека. Ну никак вы не способны к конструктивному разговору... Я не типа, а сдавала и сдала экзамен) да, стандарты в istqb syllabus прописаны — в разделе на чем основано экзамен)) Ну и ? Что вы этим хотели сказать? Что документация экзамена не важна? Я вижу ваш слоган по жизни ’ лишь бы не молча’. Даже на четко поставленный вопрос отвечаете каким то глупым комментарием, а не четким ответом) я думаю те кому интересно тестирование мой комментарий поймут) до них дойдет) с вами и вашим острым умом общаться больше не буду)) p.s.. здесь люди типа делятся опытом. Типа дают ответы на вопросы. Обсуждают типа темы по тестированию , а не типа личные качества. Пишу вам типа на понятном вам языке) а то так вряд-ли дойдет)))

Может вы психологом пойдете работать?) Обеспечение качества и коммуникативные навыки, судя по коментариям — вот вообще не ваш конек ))))

Мне это уже говорили))) но я 💗 IT)

ISO/IEC/IEEE 29119 — але його дуже сильно критикують, відомі автори з тестування
є ще такі стандарти :
IEEE 829 Test Documentation
IEEE 1008 Unit Testing
BS 7925-1 Vocabulary of Terms in Software Testing
BS 7925-2 Software Component Testing Standard

стандарти, це те що випускають організації по стандартуванню. В тестуванні, як і в багатьох інженерних науках, все доволі відносно. Тому не завжди коректно покладатись на стандарти.
Наприклад, багато хто вважає є 3 рівні тестування — unit, integration, system. І в цьому є логіка. Тестування залежить від контексту і це потрібно завжди враховувати

ISTQB это коммерческая, но сертифицирующая организация, признаваемая в качестве стандарта в большинстве стран(где есть интернет, скажем так). Кроме ASTQB. Но они мало чем отличаются. Olga, а Вы знаете 0оть одну организацию, чье «видение» так же признано столькими специалистами и организациями?

Это нужно не меня спрашивать а Oleg Zarevych. Я не знаю, поэтому в пример его и ставлю.

то уровней тестирования 9

Декілька років тому, менеджер на внутрішньому екзамені хотів почути саме цей перелік :(

Сочувствую )))
а не просили расскзать про

— Hardware-software integration testing
— Feature interaction testing
— Customer product integration testing

? ))))

нє, він хотів почути у відповідь саме цю статтю

1. Unit testing:
2. Component testing:

а от яка різниця ? де починається\закінчується компонент ? дуже розмите поняття. Приклад з сайту — приклад інтеграційного тесту


Big bang integration testing
• Top down
• Bottom up
• Functional incremental

це не рівні тестування, а підходи до імплементації інтеграційного тестування

8. Alpha testing:
9. Beta testing:

взагалі ніякого відношення не мають до цього. ці види тестування вирішують різні задачі
Альфа тестування це швидше system\acceptance рівень.
Бета — acceptance, та і взагалі не дуже має спільного з тестуванням

Так вообще то это и есть подвиды 4х основных типов. Вы все правильно написали. И про тонкую грань тоже. В комментариях я писала что это подвиды. Просто скопировала с сайта с нумерацией, не знала что цель сидящих тут людей придраться к какой то нумерации))) и так понятно что это подвиды для людей которые в тестировании. Ну тут считается так круто сказать что istqb это фигня. В там то нужно две точки поставить или про АТБ пошутить))) p.s. Только насчёт Бета тестирования не соглашусь. Все таки альфа и бета относится к acceptance testing. Подвиды.

Ну про АТБ вы ж шутку не догнали)

АТБ==International Testing Board (сокращенно от International Software Testing Qualifications Board)

альфа и бета относится к acceptance testing. Подвиды

ні. Воно взагалі сюди ніякого відношення не має. це зовсім інше бачення тестування.
Альфа тестування — тестування продукту командою розробників — це і юніт тести, і системні. Все що робить команда. Може бути окремий альфа реліз в межах компанії — для внутрішніх користувачів. Це є acceptance рівень. І задача тут отримати фідбек від реальних користувачів або від великої к-сть користувачів.
Бета тестування — це реліз майже завершеного продукту для обмеженої або повної цільової аудиторії. Ціль — отримати фідбек від цільової аудиторії, знайти що і як покращити, показати себе на ринку. Це також можна розглядати як один з підвидів acceptance рівня

Доброго дня. а де можна про Acceptance Testing інформацію почитати?

Здравствуйте! В тестировании взаимодействия (interoperability testing) есть момент про тестирование совместимости (compatibility testing) — можете, пожалуйста, раскрыть тему последнего(совместимости)?

Доброго дня. Если коротко, то это тестирование совместимости системы с другими браузерами, железом, сетями, осями и т.д.

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

ISO 8402:1994

Этот стандарт уже отменен и вместо него используется ISO 9000:2015

очепятка — tets case

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

 — старый баг, все забывал зарепортить :)

Добрый день. При изучении видов тестирования, есть вопросы:
1. Функциональные — в видах и типах тестирования вы указали, что это — функциональное тестирование, тестирование пользовательское интерфейса, безопасности и взаимодействия. Но,в схеме виды тестирования — функциональное (по целям) больше в себе ничего не имеет, все остальное — не функциональное. Это ошибка?
2. Есть ли разница? В перечне нефункциональных видов тестирование — название "Тестирование стабильности или надежности",но в схеме по — другому — "Надежности и восстановление после сбоев«,а в производительности — «Стабильности».
3. А куда входит кросс — браузерное тестирование? Его сдесь нет!

А куда входит кросс — браузерное тестирование?

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

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

к пролукту

прошу прощенья , а это кто?

Это очепятка *продукту

понял) думаю что за термин, никогда раньше не слышал)

Поддержка браузеров — это требование к пролукту, соответственно — функционал.

1. В різних браузерах можна робити як функціональні, так і не функціональні перевірки
2. Вимога до продукту бувають функціональні та не функціональні

Трудно не согласиться )

особисто моя думка, не варто виносити крос браузерність як окремий вид тестування. Це швидше тестування взаємодії

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

istqbexamcertification.com/...​lity-testing-in-software
Тестування взаємодії\сумісності значить перевіряти продукт у роботі з різними середовищами. Для веб аплікації, різні середовища це і є браузери

Понял) понапридумывают термиологии , чтобы простые вещи сложно объяснять)))

просто є різні автори які одинакові речі по різному називають. Або через мінімальну відмінність новий вид тестування. Оцих тестувань сумісності є десь 3 назви. Навіть можна знайти розбіжності між ними. Але як на мене, таке стається коли різні автори говорять про одне і теж, а третій автор зводить все у купу не дуже розбираючись у питанні

Да, полностью согласен

не існує єдиної класифікації тестування. В різних джерелах може бути написано по різному.

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

згідно з ISO 9126 на якому базується ISTQB — це вірно. Хоча ніде не написано про UI тестування.
зараз ISO 9126 замінено іншим стандартом, де безпека та взаємодія винесені як не функціональні аспекти.

Тестирование стабильности или надежности

це підвид performance testing

кросс — браузерное тестирование

Швидше за все це тестування взаємодії.
НО види тестування є різними по відношенню до цілей тестування. Тобто, коли ми говоримо про тестування функціональне\нефункціональне — це класифікація на основі моделей якості.
Крос браузерне тестування не відноситься до цього. Ви ж можете у різних браузерах робити як і функціональні так і не функціональні тести

Извините, а «тестирование пользовательское интерфейса» по новым стандартам — не функциональное? Можете назвать номер стандарта нового, пожалуйста?

я не зрозумів питання

ну вы написали, что

зараз ISO 9126 замінено іншим стандартом,

, есть ссылочка?

Здравствуйте, есть вопрос к ТС и всем кто в теме.
Модель качества программного обеспечения ISO/IEC 9126 определяет 6 целей (характеристики внутреннего и внешнего качества ПО) и 21 атрибут (подхарактеристик). Собственно для проверки этих характеристик и существуют различные виды тестирования. Условно их можно разделить на функциональные виды и не функциональные.

Согласно упомянутой выше модели качества, продукт имеет такую характеристику как Functionality и следующие подхарактеристики:

  • Suitability,
  • Accuracy,
  • Interoperability,
  • Functional Compliance,
  • Security.
В шпаргалке к функциональным видам тестирования ТС записал тестирование безопасности (Security Testing) и тестирование взаимодействия (Interoperability Testing) что верно в соответствии с моделью.

Вопрос:
Начиная с 2011 года модель ISO/IEC 9126 была замещена на ISO/IEC 25010 в которой Interoperability и Security не являются функциональным атрибутами. Корректно ли теперь причислять Security Testing и Interoperability Testing к функциональным видам тестирования?

Буду признателен на разъяснение по данному вопросу.

Если спросят на собеседовании, то вот именно это будет лучшим ответом ) А на самом деле куда более важно не знать к какому типу что относится, а понимать, что это такое и как это тестировать. Лично мне ближе старый вариант, но я уверен, что у людей, разрабатывавших новый стандарт, были причины переосмыслить.
Яркий представитель нефункционального типа — UX. Всё сделано по требованиям, но на сколько это удобно. Что же касается безопасности, то это функционал. У тебя либо base64 в куках либо двухфакторная аутентификация с физическим чипом.

Понял, благодарю Вас за пояснение.

модель ISO/IEC 9126 была замещена на ISO/IEC 25010

але ISTQB базується на 9126. і це дивно бо вийшло воно коли вже був 25010.
ІМХО, краще дати розгорнуту відповідь.
Хоча, багато людей пропустили цей пункт в ІСТКБ і не знають про це

Спасибо большое, очень классная статья. Мой конспект перед каждым собеседованием. Еще предложение внести Попарное тестирование в Техники тест дизайна.

Могли бы вы добавить метод пар в техники тест дизайна?

Спасибо большое! Перечитываю каждый день вашу статью, очень мне нравится она.

+1, статья он топ! спасибо. не хватает только black/white/grey-box’ов.

Кстати, Диаграмма связей, взрыв мозга .. ничего не понял ))

Зачем после «Санитарного тестирования» снова описывается техника тест-дизайна «Предугадывание ошибки» ??

Чувствуется мне, что это был баг ) Спасибо, убрал повторение.

Sanity и Smoke, в разных источниках вижу разные трактовки, а в ISTQB пишут, что это синонимы, разъесните кто-то поподробней, пожалуйста.

Эти понятия часто путают. Я бы сказал, что Smoke — преверка основных фич билда, дабы быстро сказать, что билд хороший. Sanity — проверка основного функционала фичи без глубокого тестирвоания, дабы быстро сказать, что фича хорошая. Но правильно так, как написано в ISTQB.

Я так поняла, сертификат ISTQB ценится, но не все термины так уж однозначно воспринимаются?

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

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

Можно оперировать источниками и своим опытом. Лучший ответ на спорный вопрос — я понимаю это так и так это работает, а в ISTQB написано вот так. Главное, чтоб одно другому не противоречило.

Вопрос, насколько часто и что вы реально используете в проектах, из всего вышеперечисленного? Вопрос ко всей аудитории...

Re-testing — проверяется исправление багов
Regression testing — проверяется то, что исправление багов не повлияло на другие модули ПО и не вызвало новых багов.
Проводя параллель статьи и www.protesting.ru/…​ing/types/regression.html
Re-testing = Bug regression
Regression testing = Side effect regression

Вопрос перепутаны ли понятия? И где Регрессия старых багов (Old bugs regression)?

Я бы сказал, что Regression testing — это то, что написано у меня + «Side effect regression». Дописал в статье.

Old bugs regression
Честно говоря, никогда таким не занимался ) И даже не слышал, чтобы кто-то так делал. На старом проекте на такую активность могут уйти годы ) Тем более, что функционал меняется и степы в баге уже могут не соответствовать текущей реализации.
Был бы очень признателен, если бы вы с этим вопросом сходили на ISTQB и выяснили там, ибо то стандарт, а protesting — это ребятки, которые написали своим языком так же, как и я здесь. У нас с ними могут быть неточности, а стандарт — это закон.
В любом случае, спасибо!

«Тест аналитик, будет думать: „Что, если я не введу код?“, „Что, если я введу неправильный код? “, и так далее. Это и есть предугадывание ошибки» — это тест дизайнер.
По твоим же собственным словам:
Тест аналитик — определяет «ЧТО тестировать?»
Тест дизайнер — определяет «КАК тестировать?»

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

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

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

Это наверно так в институтах культуры учат общаться, вместо «спасибо» — "

%уйню
«, Вы же уже более 3-х лет в тестировании и сертификация вроде как есть в отличии от меня, а я не могу пока на джуна попасть. Но почему то понимаю что хотел сказать автор в слове «ЧТО» — это имеется ввиду оценивает какие функции («ЧТО»- форма регистрации,"ЧТО" — поле логина, «ЧТО» — платный функционал) вот ЧТО в первую очередь нужно, к примеру, нужно протестировать на сайте, а не
«Что, если я не введу код?»,
, как Вы сказали. А вот «КАК» это и есть предугадывание, анализ граничных значений и остальные техники тест дизайна. Если Вы не понимаете сути или не умеете анализировать то, что дал автор — не читайте, лучше пройдите еще раз сертификацию.

Ну вот, я не проЭПСИЛОН-ил. А сколько ты столь развернутых статей написал, чтобы обвинять автора?

спасибо большое, отличная работа!

Очень понравились две статьи про UI и UX с наглядными примерами.
«Разница между UI и UX: определение терминов»
www.idg.net.ua/blog/otlichiya-ui-i-ux
«Грань между UI и UX»
m.habrahabr.ru/post/190840
Кратко:
В переводе с английского UI (user interface) — это интерфейс пользователя. С помощью такого интерфейса юзер может взаимодействовать, т. е. вести диалог с устройствами, машинами, программами. Хорошим примером пользовательского интерфейса является мобильный телефон с дисплеем и клавишами для различных функций, приборная панель автомобиля с кнопками управления и т. д. UI — это то, как видит и с чем взаимодействует пользователь на экране.

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

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

Спасибо за ссылки. Только лучше, наверное убрать «m.» из ссылки на хабр. Не все с мобильных сидят.

Хочу обратить внимание на пункт «Тестирование удобства пользования», т.к. Usability testing (Тестирование удобства пользования) и GUI testing (Тестирование пользовательского интерфейса) — это совсем разные виды тестирования!!! Написано много статей про разницу между ними.

Usability testing (относистся к Нефункциональным видам тестирования):
Testing to determine the extent to which the software product is understood, easy to learn, easy to operate and attractive to the users under specified conditions. (ISTQB Glossary)
Тестирование удобства пользования или Usability Testing — это метод тестирования, направленный на установление степени удобства использования, обучаемости, понятности и привлекательности для пользователей разрабатываемого продукта в контексте заданных условий. [ISO 9126]
Тестирование удобства пользования дает оценку уровня удобства использования приложения по следующим пунктам:
— производительность, эффективность (efficiency) — сколько времени и шагов понадобится пользователю для завершения основных задач приложения, например, размещение новости, регистрации, покупка и т.д.? (меньше — лучше);
— правильность (accuracy) — сколько ошибок сделал пользователь во время работы с приложением? (меньше — лучше);
— активизация в памяти (recall) — как много пользователь помнит о работе приложения после приостановки работы с ним на длительный период времени? (повторное выполнение операций после перерыва должно проходить быстрее чем у нового пользователя);
— эмоциональная реакция (emotional response) — как пользователь себя чувствует после завершения задачи — растерян, испытал стресс? Порекомендует ли пользователь систему своим друзьям? (положительная реакция — лучше);

GUI testing (относистся к Функциональным видам тестирования):
Testing performed by interacting with the software under test via the graphical user interface. (ISTQB Glossary)
Задачей тестирования графического интерфейся пользователя является обнаружение ошибок следующего характера:
— Ошибки в функциональности посредством интерфейса;
— Необработанные исключения при взаимодействии с интерфейсом;
— Потеря или искажение данных, передаваемых через элементы интерфейса;
— Ошибки в интерфейсе (несоответствие проектной документации, отсутствие элементов интерфейса);

Спасибо, согласен, исправил )

скажите какая существует классификация ошибок, я чего-то не могу разобраться(

Дякую, систематизували теорію)

Спасибо за статью, Геннадий! Она очень помогает структурировать имеющиеся у меня теоретические знания по тестированию))

Дефект (он же баг) —
Bug (defect) —
Зачем дважды давать определения?

Первое — классическое определение бага, второе — наглядная разница между deffect, error, failure.

Большое спасибо за статью! За обе ее части :-) А на собеседовании не спрашивают про SoapUI, Git, Web-сервисы, модель OSI, базы данных и Linux? Хочется знать, к чему готовиться :-)

Хех, я спрашиваю web, rest, linux, сети, теорию и пара задачек ) Эта статья больше для новичков, которые только теорию могут знать и у них остальное не будут спрашивать и более опытных людей, которые знают, что конкретно готовить на собеседование и это только, чтобы освежить теорию. А оси и линукс — это проджект специфик.

Ясно :-) А можете привести примеры задачек?

Есть задачка на траблшутинг, но её привести не могу, только на собеседовании ;). А есть простая на сети: могу написать в личку.

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

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

Доброго времени суток! Меня также интересует вопрос, чему больше всего стоит уделить внимание перед поиском работы qa. Какими вопросами приблизительно будут штурмовать студента (скоро выпускника) на собеседовании, если опыта работы, к сожалению в этой сфере нет,а есть только теоретическая база и база html, css, java и желание развиваться.
Если не затруднит, ответьте сюда или в личку. Спасибо!

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

Спасибо, очень кратко изложено и максимально приблеженное к ISTQB

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

Ужс сколько воды в этих тестированиях.

Замечательная статья! всё что нужно и в одном месте! Спасибо!

Хорошо порой освежить память, спс. Только кроссбраузерного тестирования походу нет....

Да, нет. А что можно добавить по этому вопросу? Предлагайте, мож и сделаем лучше )

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

Какая же крутая статья! Прямо все по полочкам! Огромное спасибо !

Автору спасибо! Классный конспект.

Очень круто! Спасибо!

Спасибо. Не ожидал, что рекрутерам такой материал тоже пригодиться. Вам, кстати, могу также предложить комментарии отсюда: megamozg.ru/post/10268 ;)

Отличная статья, спасибо!! Тоже пытаюсь собрать и систематизировать информацию по тестированию ПО, так как постепенно теория забывается.. Кому интересно, заходите, смотрите.. Может что подскажете, посоветуете!! Давайте развиваться вместе!! www.youtube.com/...BwJFbPK43C-BTFLKSw/videos

хм, подборочка впечатляет. пойду ка я засяду на пару ночей)

Очень доступно подана информация о техниках тест дизайна www.youtube.com/watch?v=fn6kx7cuxGQ

Уровни Тестирования
1. Модульное тестирование (Unit Testing)
Компонентное (модульное) тестирование проверяет функциональность и ищет дефекты в частях приложения, которые доступны и могут быть протестированы по-отдельности (модули программ, объекты, классы, функции и т.д.).
2. Интеграционное тестирование (Integration Testing)
Проверяется взаимодействие между компонентами системы после проведения компонентного тестирования.
Первый уровень " Unit Testing" добавить модульное тестирования или компонентное, так как Вы используете в «Integration testin» компонентное тестирование, а до этого про него даже не вспоминали.

Сори, но я чёт не до конца понял суть претензий. Как по мне всё гут написано.

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

Входит в usability testing, как вы думаете?

Я думаю ТАК! просто іноді питають про UI testing, а оскільки ця стаття прекрасна для новачків, то мабуть буде добре, якщо буде винесено окремо таке визначення, щоб не було путанини. Але звісно це на Ваш розгляд, якщо Ви вважаєте що це зайве, то я сперечатись дуже не буду)
+ у визначенні

Failure — сбой (причём не обязательно аппаратный) в работе компонента, всей программы или системы. То есть, существуют такие дефекты, которые приводят к сбоям (A defect caused the failure) и существуют такие, которые не приводят. UI-дефекты например. Но аппаратный сбой, никак не связанный с software, тоже является failure.
Ви згадуєте про UI — дефекты

Согласен. Может, тогда имеет смысл дописать под описание юзабилити про UI и UX. Займусь на днях. Ещё раз спасибо )

Связанные с изменениями виды тестирования
....
•Повторное тестирование (re-testing)
Повторное тестирование (re-testing): Тестирование, во время которого исполняются тестовые сценарии, выявившие ошибки во время последнего запуска, для подтверждения успешности исправления этих ошибок.
В чем разница между regression testing и re-testing?
Re-testing — проверяется исправление багов
Regression testing — проверяется то, что исправление багов не повлияло на другие модули ПО и не вызвало новых багов. -- - спрашивали в GlobalLogik

напоминает качественный копипаст с сайта протестинг

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

И это мило что вы со всеми поделились собранной инфой.

Очень полезная напоминалка.Огромное человеческое спасибо автору

Непогано, а головне стисло.

Gennadii Mishchevskii большое тебе человеческое СПАСИБО!!!!

Все очень лаконично и здорово скомпоновано, но я бы еще дополнил инфы о качестве и его метриках, нередко на интервью задают вопрос: «как измерить качество?», — думаю будет полезным:

— Метрики качества программного обеспечения
— Стандартная оценка значений показателей качества
www.intuit.ru/...0/237/lecture/6136?page=3

Это достаточно большая и разосторонняя тема. Прошёлся бегло и не нашёл короткого описания, чтоб было по делу.

Спасибо, клево написал.. :-)

Отличная статья, все самое нужное! Можно еще добавить к видам тестирования — По уровню знания системы: Black box testing, White box testing и Grey box testing.

Обновил шпору. Добавил пункты тест плана, таблицу принятия решений, сравнение qa, qc и тест инженера и диаграммы связей.

Error Guessing дважды описан, в техниках тест дизайна и в типах тестирования) Из пожеланий, добавьте еще, пожалуйста, вкратце о моделях разработки ПО

Вкратце о моделях не получится ) Хочу отдельно написать, но пока времени нет.

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

Супер! Мои поздравления! )

Первую треть текста я буква-в-букву встречал в материалах на небезызвестном курсе QA :)

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

А где же метод всех пар, ортогональные массивы, таблицы принятия решений и тестирование переходных состояний?
Еще, честно говоря, не уловил что такое корректность требования? И, возможно, туда бы добавить реализуемость и тестируемость — а то требовать всякого можно :)

State transitional testing там есть, ортогональные массивы не стал вставлять, т.к. не так уж и часто их спрашивают у новичков. А на таблицу принятия решений стоит у меня напоминалка, как будет время — добавлю.

State transitional testing там есть
Не вижу, если честно — даже при помощи поиска по странице.
Возможно, у Вас где-то в исправленной версии это есть.

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

Спасибо, добавлю. Только не на пятое место, а на четвёртое, ибо после приёмочного тестирования идёт внедрение и эксплуатация. Согласны?

ні, Приймальне тестування (англ. Acceptancetesting)
Вхідні вимоги -Вимоги(Requirements)
Об’єкт тестування -Розроблена система
Визначення: На даному рівні завершений додаток(система)тестується Замовником, кінцевими користувачами або відповідними уповноваженими з метою визначення відповідності системи «Вимогам Замовника» і ГОТОВНОСТІ СИСТЕМИ ДО ВПРОВАДЖЕННЯ. Проектні випробування оформляють ПРОЦЕС ПЕРЕДАЧІ ПРОДУКТУ від Розробника Замовнику. Залежно від особливостей продукту і від вимог Замовника вони можуть проводитися в різній формі. Наприклад, у вигляді альфа- або бета-тестування.

а після цього

Операційне тестування (ReleaseTesting)
Вхідні вимоги -Бізнесмодель(BusinessCaseабоBusinessModel)
Об’єкт тестування -Розробленасистема

Визначення: Навіть якщо система задовольняє всім вимогам, важливо переконатися в тому, що вона задовольняє потребам користувача і виконує свою роль В СЕРЕДОВИЩІ СВОЄЇ ЕКСПЛУАТАЦІЇ, як це було визначено в бізнес-моделі системи. Слід врахувати, що і Бізнес модель може містити помилки.Тому так важливо провести операційне тестування як фінальний крок Валідації.

Крім цього, тестування в середовищі експлуатації дозволяє виявити і не функціональні проблеми, такі як:конфлікт з іншими системами, суміжними в області бізнесу або в програмних та електронних оточеннях; недостатня продуктивність системи в середовищі експлуатації та ін.

Очевидно, що знаходження подібних речей на стадії впровадження-критична й дорога проблема. Томутакважливо проведення не тільки верифікації, а й валідації, з самих ранніх етапів розробки ПЗ.

А загалом спасибі за статтю, я от для себе відкрила принципи тестування, ніколи їх не вчила і не знала, що такі є)

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

можливо...але мені це все давали вчити на джуна qa)

спс очень позновательно

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

Также, необходимо правильно понимать понятия verification и validation.
Когда мы говорим о разработке продукта, то в конечном итоге у него всегда должны быть пользователи. Согласно требованиям пользователей (требованиям рынка) и их ожиданиям будут разработаны явные требования, которые и будут использоваться в процессе разработки самого продукта.
Процесс оценки соответствия продукта явным требованиям (спецификациям) и есть верификация (verification), в то же время оценка соответствия продукта ожиданиям и требованиям пользователей — есть валидация (validation). Также часто можно встретить следующее определение этих понятий:
Validation — ’is this the right specification?’.
Verification — ’is the system correct to specification?’.

Согласен. Я даже на собеседовании так ответил. Но после в интернете нашёл несколько другую интерпритацию. Ту, что выше. Так что же тогда считать более правильным вариантом?

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

Я оставил оба варианта.

Згідно ISO 9000:2015:
verification
confirmation, through the provision of objective evidence, that specified requirements have been fulfilled
validation
confirmation, through the provision of objective evidence, that the requirements for a specific intended use or application have been fulfilled

Ще додам таку діаграму
Думаю, що ’specific intended use’ із визначення ISO 9000:2015 відповідає ’needs and expectaion of customer’ з діаграми.

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

Своїм коментарем я хотів підтримати варіант пояснень від Дениса.
На мою думку, краще в статті залишити один варіант відповідей — для новачків не буде плутанини. Денис дуже чітко «розжував» ці поняття.

Полезная подборка терминов и понятий. В качестве замечания могу добавить следующее:
Определения Error, Defect требуют небольшой корректировки, чтобы отделить мух от котлет. Не стоит смешивать понятия defect и error.
Error/mistake — это как ошибка в использовании продукта со стороны пользователя, так и ошибка, которая была допущена в процессе дизайна и разработки продукта. Наличие подобной ошибки означает наличие дефекта (defect/bug/fault) и может как приводить к сбою (falilure), так и не приводить к сбою в работе продукта.

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

По идее, два последних пункта — это тоже нефункциональное тестирование :).

Вольный пересказ Рекса Блэка, для повторения есть силабус. Ничего особенного.

Хороший материал. Можно еще Issue и Mindmap`ы добавить

Спасибо за источники

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

Дельное замечание. Добавил также из книги ISTQB английской версии.

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

Классно!
Жаль, что все еще нельзя сами посты лайкать.

Кому интересна, обновил информацию. Добавил:
качество, верификация / валидация, traceability matrix, error/deffect/failure, подходы к интеграционному тестированию. Если есть что ещё — пишите )

+100 тебе к карме. Сам собирался такую штуку себе написать для собеседований, но ты опередил меня.

ПС Еще круто будет добавить что-то вроде схемы видов тестирования. Часто на собеседованиях спрашивают по видам.

Всегда пожалуйста ) Виды там есть, а что ты имеешь ввиду под схемой?

goo.gl/8WGnkk что-то на подобии этого)

ПС Хах) можно так надобавлять, что через полгода будет целая книга по основам тестирования) Потом автоматизацию еще добавить)

Да, я видел эту схему. Добавил.

Отличная статья! Очень содержательно, как по мне. Молодец и спасибо за информацию)

Ще варто загадати про requirement traceability matrix (матриця покриття вимог), в загальному про етапи розробки і місце тестування в цих етапах.
Підходи до Integration Testing — Bottom Up, Top Down, Big Bang.
З тестової документації ще є поняття Quality Assurance Plan, Test Strategy.
Валідація / Верифікація — пояснення і різниця між термінами.
Взагалі класні ресурси istqbexamcertification.com і www.testingexcellence.com де по теорії багато що розжовується і пояснюється.

а что тогда надо знать на мидл кьюея ?

Отличная шпаргалка! Без лишней воды. Можно сказать — идёшь на собеседование — должно как от зубов отскакивать.

Спасибо тебе, Добрый Человек! Для повторения самое оно. Все четко и красиво, без воды.

Хорошая шпаргалка )

Можно ещё добавить:
1) Техники тестирования
2) Чем отличаются error, failure и defect
3) Если уж упомянули про баг репорт, то было бы хорошо описывать и другую тестовую документацию

И ещё многое другое (особенно если написать и про обеспечение качества, используемые метрики и т. д.)

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

Единственный вопрос — почему не в виде статьи, а сразу на форум?

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

Материал крутой, спасибо. Разве что редко когда можно предугадать о чем будет разговор на собеседовании. Готовишься по теории, а спрашивают по специфическим аспектам проекта и наоборот :)

Це все зібрано з ISTQB FL. Та інших відомих і доступних джерел. Лише декілька методів тест дизайну добавили. Як для мідла — це замало.
Треба ще розуміння ризиків, естімейтів. Розуміння гнучких підходів.
Також мене питались про різні white box техніки (це є в книзі Дороті Гретхем)

От меня тут буквально пару слов, всё остальное, правда, из разных источников, которые указаны в самом конце. И я в начале сразу оговорился, что это для Junior and Trainee. Естественно, что для мидла это не то, что надо.

Навіть для мідла норм. Хіба більш обширно потрібно, з можливістю навести приклади

Может, позже сделаю )

крутой материал, спасибо

забули ще про поняття error-guessing testing, який майже як exploratory, але вимагає знання продукту
error guessing: A test design technique where the experience of the tester is used to
anticipate what defects might be present in the component or system under test as a result
of errors made, and to design tests specifically to expose them.

і головне забула написати — стаття хороша. ))

Це мені одному здається, що половина тут написаного є фантазією адного/декількох авторів, а індустріальних стандартів толком немає.

Вот в JIRA


Major — Major loss of function.
Minor — Minor loss of function, or other problem where easy workaround is present.
Trivial — Cosmetic problem like misspelt words or misaligned text.
що не зовсім те, що описано тут.

Для ознайомлення цей текст підійде нормально. Але вимагати від кандидатів такі речі — це занадто.
Спитайте «що робив? з чим працював? що знаєш?» і потім по пару питань до кожної відповіді кандидата — і все стане зрозуміло.

А взагалі, тут є очевидці роботи QA по хоча б наближеній до ортодоксальної методології (є нормальна документація, автоматизовані тести пишуть не програмісти, регресійні тести та тести на навантаження є не святом, а буденністю, і т.д.)?

А то щось мені здається, що велика частина написаного в цій та схожих статтях — це сферичний тестувальник в вакуумі.

Не думаю, що в тестуванні методологія поставлена краще, ніж scrum в розробці.
(тобто всі як би знайомі з методологією, но в кожній команді працюють по своєму)

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

Ми таки існуємо

Большое спасибо за представленный материал!

ОК, после прочтения этой статьи курсы QA уже не нужны.

Подписаться на комментарии