Комментарии 10
Не изобретайте колесо :)
Просто используйте фасетную классификация.
Для глубин гост 22274 в помощь.
PS. Есть минус, не стильно, не модно и не молодежно, зато винтажно
Просто используйте фасетную классификация.
Для глубин гост 22274 в помощь.
PS. Есть минус, не стильно, не модно и не молодежно, зато винтажно
Колесо действительно изобрели до ГОСТ и до нас)) Мы считаем, что в автоматизации тестирования описанный метод полезен, в первую очередь, своей наглядностью.
А в чем преимущество «колеса» в наглядности перед, скажем, простым списком видов тестирования? Вы пишете, что это «полезный способ визуализации», а в чем конкретно заключается польза? Что именно иллюстрирует это колесо? Почему какие-то типы тестирования справа, а какие-то слева? Почему тип тестов А соседствует с типами B и C? Имеют ли значения цвета?
Этот перевод описывает более наглядную форму, чем простой список тестов (где, как правило, больше всего запоминаются первый и последний пункт). Возможно, это хорошая идея — расположить сектора в определенном порядке или связать каждый тест с цветом, хотя автор статьи предлагает считать все «спицы» равнозначными. Мы используем этот способ, прежде всего, как чек-лист типов автотестов.
Смешались в кучу кони, люди. Тесты делятся по:
- объекту тестирования (модуль, компонент, система)
- тестируемое свойство (функциональность, производительность, безопасность, внешность, доступность)
И составлять пары "объект+свойство" можно практически в любых комбинациях.
Тесты можно делить ещё по множеству параметров) Колесо автоматизации призвано быть удобным «чек-листом» типов тестирования для автоматизации тестирования.
По каким ещё? Объект, свойство, процесс и всё.
Вариантов деления достаточно много, например, по целям, значимости, доступу к коду системы. Здесь каждая команда выбирает то, что ей удобно
В колесе потерялась иерархия тестов пирамиды, соответсвенно не понятно, должны ли быть равные объёмы тестирования для каждого из секторов колеса.
Потерялась последовательность и направленность разработки тестов, часть тестов выделена искусственно.
А на вопрос, что разрабатывать первым тут вообще нет ответа.
Очень странная система классификации, ощущение, что автор оригинальной статьи сам себя перемудрил.
У каждого продукта свои особенности, поэтому объёмы тестирования каждого сектора для каждого приложения, конечно, могут отличаться. Для нас это в первую очередь чек-лист, как мы писали выше.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.
От пирамиды тестов – к колесу автоматизации: какие проверки нужны на проекте