Модульное тестирование в современных командах

[@saw_tooth]

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

Что простите?

[@N_Repka]

Добрый день.
А что Вас смущает?
Есть команды, в которых ПМ'ы просят обязательно по сложным задачам провести модульное тестирование.
Я в начале указывала, что не особенно важно как называется должность. Просто в команде есть такой человек. В других местах это может быть абсолютно по-другому

[@N_Repka]

Но делаем шаги в сторону изменения данного процесса

[@saw_tooth]

Не хочу никого обидеть, но:
— зачада РМ, бегать развлекать девелоперов, что бы они не скучали без работы
— задачи тестирования, более того планированием тестирования (да да, типы проводимых тестов, их виды и то, какую область они проверяют) описывается в тест плане, который готовит специальный человек в компании, именуемый Test Architector или более простом — Senior QA, или если все очень плохо, то Team Lead… но никак не РМ.
ЗЫ. Во втором сообщении Вы и сами подчеркнули «просят», но не «определяют»

[@N_Repka]

Я изначально просто неверно выразилась. У нас РМ принимают полное участие в жизнедеятельности задачи. Начиная с момента ее рождения со стороны заказчика и заканчивая выводом на бой. Речь не шла о тест планах, конечно РМ этим не занимаются, но принимают активное участие в определении видов тестирования, которые необходимы. Это обуславливается еще и тем, что различные виды имеют различную длительность. Не всегда есть достаточно времени для проведения комплексного тестирования ( се ля ви )… В классической модели я с вами полностью согласна, но в посте пыталась показать как процесс поставлен у нас.

[@AnROm]

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

[@N_Repka]

Но нужно понимать, что это не решение to be, ибо я так хочу, это совместное обсуждение задач.

[@VolCh]

Почему на водопаде модульное тестирование до разработки?

[@VolCh]

*не до
приложение не даёт ни исправить, ни на свой коммент ответить

[@N_Repka]

Добрый день!
Потому что в нашем случае это не написание юнит тестов, а именно модульное тестирование. Поэтому до разработки еще тестировать нечего. Хотим выйти на параллельное тестирование с разработкой в 2-х типах команд.

[@VolCh]

А в чём для вас разница? Ни разу не встречал разделения, просто как синонимы.

[@N_Repka]

У нас получается так:
модульное тестирование — это тестирование фичи в разрезе систем с учетом жесткости контрактов на выходе/входе. Тестирование на уровне кода и далее написание тестов на модули, которые были разработаны/изменены ( адаптеры, функции, процедуры )
есть так же сит тестирование — оно у нас проверяет доработку с другой стороны. Со стороны полного процесса и не начинается, пока фича целиком не разработана на всех системах.
Модульному же не требуется разработка на системе А, чтобы проверить систему В.

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

[@Afflatus]

Хорошая статья — написано просто и понятно :)

[@N_Repka]

Спасибо!

[@AnROm]

Плохое качество картинок, более читабельный шрифт бы выбрали на схемах.

[@eddHunter]

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

Это глубокое заблуждение.

• Во-первых — ручная проверка front части останется необходимой, в той же мере, что и раньше. К тому же у вас нет тестов на фронт.
• Во-вторых — это тема сугубо для разработчиков. Модульное тестирование, прежде всего, призвано задокументировать функционал, оптимизировать архитектурные решения, а не сколько поправить критические баги, на то скорее интеграционные тесты.

[@N_Repka]

Во-первых — ручная проверка front части останется необходимой, в той же мере, что и раньше. К тому же у вас нет тестов на фронт.

В статье указано, что занимаемся системами только middle/back уровня, фронт остается вне нашей сферы деятельности.

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

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

А автоматизированные модульные тесты выступают своего рода базой знаний

[@eddHunter]

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

[@N_Repka]

Добрый день!
Есть у нас система middle уровня ( конструктор ) на ней модульный тест полностью покрывает процесс. Соответственно стремимся покрыть все процессы тестами ( тест равен одной вариации прохождения данного процесса ) и далее полностью исключить ручной регресс.