#Test_design
As part of the Quality Assurance Team, we must provide high-quality products/services and provide real value to our customers.
Most often, companies admit to using the wrong business model or lacking Quality.
These mistakes leave room for discussion while involving QA expertise usually improves competition and provides better Testing processes.
Читать
As part of the Quality Assurance Team, we must provide high-quality products/services and provide real value to our customers.
Most often, companies admit to using the wrong business model or lacking Quality.
These mistakes leave room for discussion while involving QA expertise usually improves competition and provides better Testing processes.
Читать
#Test_design #equivalence_class
В этой статье поговорим об одной из самых распространенных техник тест-дизайна — классах эквивалентности.
Рассмотрим технику на примере формы регистрации. Возьмем какое-нибудь поле, например — поле ввода имени пользователя. Диапазон значений, которые в него можно ввести, бесконечен: короткие и длинные имена, случайные буквы, цифры и множество других вариантов. Но бесконечно тестировать эту форму не вариант, поэтому нам надо выделить в группы похожие друг на друга значения, которые нашей программой будут обрабатываться одинаково.
Таких групп будет уже гораздо меньше. Все значения внутри группы будем считать одинаковыми с точки зрения тестирования. Это означает, что при их вводе мы ожидаем, что получим схожий результат. Например, имена Олег и Марина — разные, но для тестирования достаточно ввести одно из них. Второй, скорее всего, обработается формой абсолютно также.
Такие группы будут называться классами эквивалентности. Помимо одинакового ожидаемого поведения, они должны тестировать одинаковый функционал. Например, нельзя относить к эквивалентным значениям те значения, которые тестируют разные поля. Каждому полю — свои группы.
Естественно, первым делом возникает желание посмотреть, как отреагирует поле на различные цифры, спецсимволы и нули. Но надо помнить, что наша задача — не ломать приложение, а выяснить, как оно работает, и начинать стоит с позитивных тест-кейсов. А чтобы их выделить, надо понимать, какое именно поле мы тестируем.
В нашем примере мы рассматриваем поле для ввода имен, а значит позитивными кейсами тут будут настоящие имена наших пользователей.
Возьмем обычное имя, состоящую из одного слова: Света. Вторая группа — это короткие имена, например, Ян. Следующий кейс — длинное имя, Максимилиан. Добавим имена с пробелами — Рэй Чарльз. И имена со спецсимволами: Семьюель Л. Джексон и Кири-Кири.
Вот по такому принципу мы стараемся объединять возможные имена в группы и делать только одну проверку для каждой группы. Это существенно сокращает время на тестирование, не снижая его эффективность.
В этой статье поговорим об одной из самых распространенных техник тест-дизайна — классах эквивалентности.
Рассмотрим технику на примере формы регистрации. Возьмем какое-нибудь поле, например — поле ввода имени пользователя. Диапазон значений, которые в него можно ввести, бесконечен: короткие и длинные имена, случайные буквы, цифры и множество других вариантов. Но бесконечно тестировать эту форму не вариант, поэтому нам надо выделить в группы похожие друг на друга значения, которые нашей программой будут обрабатываться одинаково.
Таких групп будет уже гораздо меньше. Все значения внутри группы будем считать одинаковыми с точки зрения тестирования. Это означает, что при их вводе мы ожидаем, что получим схожий результат. Например, имена Олег и Марина — разные, но для тестирования достаточно ввести одно из них. Второй, скорее всего, обработается формой абсолютно также.
Такие группы будут называться классами эквивалентности. Помимо одинакового ожидаемого поведения, они должны тестировать одинаковый функционал. Например, нельзя относить к эквивалентным значениям те значения, которые тестируют разные поля. Каждому полю — свои группы.
Естественно, первым делом возникает желание посмотреть, как отреагирует поле на различные цифры, спецсимволы и нули. Но надо помнить, что наша задача — не ломать приложение, а выяснить, как оно работает, и начинать стоит с позитивных тест-кейсов. А чтобы их выделить, надо понимать, какое именно поле мы тестируем.
В нашем примере мы рассматриваем поле для ввода имен, а значит позитивными кейсами тут будут настоящие имена наших пользователей.
Возьмем обычное имя, состоящую из одного слова: Света. Вторая группа — это короткие имена, например, Ян. Следующий кейс — длинное имя, Максимилиан. Добавим имена с пробелами — Рэй Чарльз. И имена со спецсимволами: Семьюель Л. Джексон и Кири-Кири.
Вот по такому принципу мы стараемся объединять возможные имена в группы и делать только одну проверку для каждой группы. Это существенно сокращает время на тестирование, не снижая его эффективность.
#QA #Test_design
Boundary Value Testing (техника анализа граничных значений) наиболее известная и простая техника тест дизайна, призванная помогать рядовому тестировщику выбирать наиболее эффективные значения для тестирования. Эта техника применима на всех уровнях тестирования - unit, integration, system, and system-integration test levels.
Читать
Boundary Value Testing (техника анализа граничных значений) наиболее известная и простая техника тест дизайна, призванная помогать рядовому тестировщику выбирать наиболее эффективные значения для тестирования. Эта техника применима на всех уровнях тестирования - unit, integration, system, and system-integration test levels.
Читать
#test_design
State-Transition testing, как и decision tables testing, отличный инструмент для фиксирования требований и описания дизайна приложения. В отличии от Decision tables testing, которые описывают конкретное состояние приложения, State-Transition testing описывают как эти состояния приложения могут меняться. Диаграммы определяют все события, которые возникают во время работы приложения, и как приложение реагирует на эти события.
Читать
State-Transition testing, как и decision tables testing, отличный инструмент для фиксирования требований и описания дизайна приложения. В отличии от Decision tables testing, которые описывают конкретное состояние приложения, State-Transition testing описывают как эти состояния приложения могут меняться. Диаграммы определяют все события, которые возникают во время работы приложения, и как приложение реагирует на эти события.
Читать