N_Repka Dec 16 2016 at 18:22

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

6 min

10K

IT systems testing*

From sandbox

Comments 19

saw_tooth Dec 16 2016 at 18:33

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

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

N_Repka Dec 17 2016 at 05:01

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

N_Repka Dec 17 2016 at 05:44

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

saw_tooth Dec 17 2016 at 14:04

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

N_Repka Dec 17 2016 at 15:42

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

AnROm Dec 19 2016 at 09:42

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

N_Repka Dec 17 2016 at 06:00

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

VolCh Dec 17 2016 at 00:37

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

VolCh Dec 17 2016 at 00:40

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

N_Repka Dec 17 2016 at 04:58

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

VolCh Dec 17 2016 at 15:03

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

N_Repka Dec 17 2016 at 17:29

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

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

Afflatus Dec 17 2016 at 12:45

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

N_Repka Dec 17 2016 at 12:46

Спасибо!

AnROm Dec 19 2016 at 09:44

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

eddHunter Dec 22 2016 at 05:16

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

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

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

N_Repka Dec 22 2016 at 12:59

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

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

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

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

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

eddHunter Dec 22 2016 at 14:06

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

N_Repka Dec 29 2016 at 17:01

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

Show the best of all time