Связь SRS с количеством багов.

Вот например, нужно протестировать, насколько корректно заносятся записи в БД. У тестировщика из требований по ней есть общая схема с описанием таблиц и типов полей, и ТЗ (как это принято называть в той конторе, где работает тестировщик — тех задание) на модуль, в котором в идеале есть инфа о том, какие таблицы должны обновляться при добавлений записи.

Получается так что при добавлении одной записи апдейтятся пять таблиц. Это написано в первом абзаце ТЗ. А во втором абзаце Главнокомандующий отдела разработки в ТЗ расписал только для одной таблицы какие должны вносится данные. А про остальные 4 таблицы в ТЗ он решил сэкономить время и не писать.

Естественно что для той таблицы про которую он расписал, как должны заносится данные, программисты сделали всё как положено. А для остальных — посчитали что раз нет в ТЗ можно не делать, или сделать так как они сами поняли.

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

Например, если написано что программа должна апдейтить таблицу StateLog, но не написано какие конкретно поля и как — тестировщик смотрит таблицу и видит, что там поле date заполняется null. Странно. Тестировщик идёт к проектировщику БД и спрашивает, почему date апдейтится нулём? Проектировщик БД говорит, что не нулём а датой, это баг. Тестировщик пишет баг, отправлет программистам. Программисты читают и говорят, что не волнует, этого не было в ТЗ. Бага редиректится разработчику ТЗ который писал ТЗ в самом начале и не внёс данной информации. Разработчик ТЗ в данном случае пишет в комментарий к багу что всё-таки нужно апдейтить дату лога, только после этого баг исправляется.

В исходное ТЗ при этом исправления не вносятся, и через несколько дней первоначальное ТЗ полностью устаревает, так как в процессе выясняются всё новые подробности работы. Остаются неизменными только высокоуровневые бизнес требования, вроде «программа должна предоставить возможность пользователю управлять счётом», нефункциональные требования / описание реализации меняется / уточняется постоянно.

Такая картина повторяется многократно в течении нескольких месяцев.

Неточности и недопонимания в исходном ТЗ порождают баги и бесконечные допиливания программы. Бесконечные допиливания программы приводят к тому, что даже то, что было написано изначально в описании реализации — устаревает. Автор ТЗ наблюдая такую картину оправдывается, что он специально не вносит многую информацию в исходное ТЗ потому что всё равно как будет работать программа мы не знаем пока не напишем, всё равно её потом сто раз допиливать, а бесконечно вносить правки в ТЗ с каждой правкой программы слишком утомительно. Но с другой стороны бесконечные правки порождает изначальная неточность.

Получается какой-то заколдованный круг.

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

Что делать? Это нормально?

Может быть кто-то с подобным встречался?

Кривое ТЗ? Неполное ТЗ? Отсутствие внятных требований? Да сплошь и рядом! Не многим тестировщикам везёт работать с нормальным техзаданием. Об этом говорят многие, но редко кто меняет ситуацию и вводит тестирование на уровне разработки ТЗ. Думаю, это дело времени, маленькими шажками мы и туда доберёмся. У нас с этим то же всё печально, пока пытаюсь таким образом справляться:
1. Всегда лезу в обсуждение разработчиками и другими участниками реализацию того или иного функционала.
2. Требую от разработчиков писать, при закрытии задачи то, что они сделали на самом деле, подробно (это, кстати и багов касается - полезно для регрессионного тестирования)
3. Перед началом тестирования подробно выясняю все детали, которые могут двояко трактоваться.

2frei_by
Описанное - обычные "детские" болезни разработки. Лечится повышением квалификации.

2frei_by
Описанное - обычные "детские" болезни разработки. Лечится повышением квалификации.

Ну да, у нас некоторые ведущие разработчики на время сессии могут отпуск брать. Но не все. Говорят что везде так. Неужели это правда?

2frei_by
Описанное - обычные "детские" болезни разработки. Лечится повышением квалификации.

Ну да, у нас некоторые ведущие разработчики на время сессии могут отпуск брать. Но не все. Говорят что везде так. Неужели это правда?

ведущие разработчики - студенты?

если это второе высшее, то нормально :)

Эт нормально... еще бывает распределенная команда
скажем, вы находитесь в одном городе, половина разработчиков - в другом, заказчик - в третьем... И если ТЗ нет, трекинговую систему заменяет скайп, svn - не правило, все льют на продакш, которым уже пользуются клиенты... вот она жесть