Как стать автором
Обновить
2
0
Нина @N_Repka

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

Отправить сообщение
Добрый день!
Есть у нас система middle уровня ( конструктор ) на ней модульный тест полностью покрывает процесс. Соответственно стремимся покрыть все процессы тестами ( тест равен одной вариации прохождения данного процесса ) и далее полностью исключить ручной регресс.
Во-первых — ручная проверка front части останется необходимой, в той же мере, что и раньше. К тому же у вас нет тестов на фронт.

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

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

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

Т.е. наблюдается децентрализация в процессе. При схлопывании разработок воедино благодаря четко зафиксированным и проверенным контрактам получается рабочий процесс для дальнейшей передачи.
Я изначально просто неверно выразилась. У нас РМ принимают полное участие в жизнедеятельности задачи. Начиная с момента ее рождения со стороны заказчика и заканчивая выводом на бой. Речь не шла о тест планах, конечно РМ этим не занимаются, но принимают активное участие в определении видов тестирования, которые необходимы. Это обуславливается еще и тем, что различные виды имеют различную длительность. Не всегда есть достаточно времени для проведения комплексного тестирования ( се ля ви )… В классической модели я с вами полностью согласна, но в посте пыталась показать как процесс поставлен у нас.
Но нужно понимать, что это не решение to be, ибо я так хочу, это совместное обсуждение задач.
Но делаем шаги в сторону изменения данного процесса
Добрый день.
А что Вас смущает?
Есть команды, в которых ПМ'ы просят обязательно по сложным задачам провести модульное тестирование.
Я в начале указывала, что не особенно важно как называется должность. Просто в команде есть такой человек. В других местах это может быть абсолютно по-другому
Добрый день!
Потому что в нашем случае это не написание юнит тестов, а именно модульное тестирование. Поэтому до разработки еще тестировать нечего. Хотим выйти на параллельное тестирование с разработкой в 2-х типах команд.

Информация

В рейтинге
Не участвует
Откуда
Москва и Московская обл., Россия
Зарегистрирован
Активность