Как стать автором
Обновить

От пирамиды тестов – к колесу автоматизации: какие проверки нужны на проекте

Время на прочтение 7 мин
Количество просмотров 14K
Всего голосов 7: ↑7 и ↓0 +7
Комментарии 10

Комментарии 10

Не изобретайте колесо :)
Просто используйте фасетную классификация.

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

Смешались в кучу кони, люди. Тесты делятся по:


  • объекту тестирования (модуль, компонент, система)
  • тестируемое свойство (функциональность, производительность, безопасность, внешность, доступность)

И составлять пары "объект+свойство" можно практически в любых комбинациях.

Тесты можно делить ещё по множеству параметров) Колесо автоматизации призвано быть удобным «чек-листом» типов тестирования для автоматизации тестирования.

По каким ещё? Объект, свойство, процесс и всё.

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

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

У каждого продукта свои особенности, поэтому объёмы тестирования каждого сектора для каждого приложения, конечно, могут отличаться. Для нас это в первую очередь чек-лист, как мы писали выше.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий