Comments 8
Частично или полностью эту задачу можно (и нужно!) поручить тестировщикам
Кхм... Ну, хоть не техподдержке - и на том спасибо...
Рассмотреть все частные случаи разрабатываемого процесса
По мере перебора крайностей документация всё пухнет-пухнет, а вероятность поймать дефект логики в конечном продукте всё не падает и не падает...
Подумать и сформулировать набор правил для каждой сущности.
Вы использовали слишком общие сущности в качестве примера. У читателя могут возникнуть стрёмные идеи по итогу. Идеи, коих Вы в виду не имели, надеюсь.
Я полагаю, что Вы задумывали написать что-то о разделении единого кома проекта на конечное количество самодостаточных И НЕ ДЕЛИМЫХ МЕЛЬЧЕ без потери контекста сущностей.
Т. е. набор сущностей для примера должен быть не "«Переписка», «Оплата», «Отзывы»" (что слишком крупно для адекватного ТЗ), а что-то вроде "письмо в переписке", "транзакция в системе оплаты" и "отзыв".
Причём, каждая из этих сущностей имеет при себе не только перечень правил обработки, но и ПРИМЕРНЫЙ перечень обязательных атрибутов (в примере - ID автора для всех трёх, привязка к задаче для всех трёх, текстовое содержание для всех трёх (с указанием, где зачем текст будет использоваться), цифровое значение рейтинга для отзыва (и его способ отображения на фронтэнде)), etc-etc.
При таком делении можно накрыть уйму блох одной шапкой (и даже облегчить программистам задачу по дальнейшей проработке архитектуры), заранее прикинув, где у нас похожие (или даже полностью идентичные) операции (и заранее их сгруппировав или даже объединив), какие данные лучше объединить в какие таблицы, какие сущности у нас вообще дублируются (и подумать - а может, не дублируются?), может быть даже заранее стребовать и включить в ТЗ какое-то кэширование...
Но вот беда...
А так уж устроен наш мозг, что ему нужна конкретика и образы, а не полотна с текстом!
Риск услышать ненавистное мне "Лень читать!" (о, если бы только это...) в этом случае и правда велик.
Причём, независимо от способа отображения и последующей интерпретации ТЗ.
Способа заставить программиста "попасть" в ТЗ (и при этом не наделать дефектов логики, именуемых Вами как "плавающие ошибки"), при этом не заставляя читать ТЗ, мне не известно.
Документация и должна пухнуть, если пухнет кодовая база и бэклог. Тут больше игра на оптимизацию. При удачном решении большого роста не будет ни там ни там.
Я полагаю, что Вы задумывали написать что-то о разделении единого кома проекта на конечное количество самодостаточных И НЕ ДЕЛИМЫХ МЕЛЬЧЕ без потери контекста сущностей.
Полагаю, автор так далеко не заглядывал. Первый вариант у него описывает обобщенные правила для реализуемых процессов. Без понимания, как это протестировать помимо положительных сценариев, что автор и подчеркнул.
А вот умение разделить сложную функциональность на атомарные сущности, каждую из которых можно полностью протестировать отдельно - навык хорошего аналитика.
Мне эта задача видится как требующая решения на уровне архитектуры приложения. Если это фактически самое самое важное место в программе, вокруг которого вращается все, то я бы выделил его в независимую единицу с четким интерфейсом, грубо говоря "движок приложения" (есть шаблоны архитектурные для таких типовых задач), и покрыл бы юнит тестами так, чтобы мышь не проскочила.
Если, конечно, писать "сверху вниз" безо всякой архитектуры, тогда логика расползется по всему коду, будет нечитаемая каша, страх изменений и постоянный регресс. (Страх кстати и есть одна из причин ругани в команде). Дальнейший рефекторинг станет сложным. Интервалы релизов будут увеличиватсья. Тестирование превратится в гонку на время. По причине этого введут автоматизацию тестирования, которая не решит это проблему. Это перекладывание отсутствующих тестов с уровня кода (юнит-тесты) на уровень пользовательского интерфейса. Где они сложнее, и менее надежны по своей природе.
Я бы копал в сторону т.н. Business Rules Engine
Конечные автоматы и юнит тесты как раз и есть варианты 1 и 2 из поста. Юнит тест обязан перебрать все варианты для 100% покрытия. Описания состояний и переходов между ними - state machine. Не понятно только, почему предлагают выбирать между ними...
требует от нас предварительно проделать достаточно большой объем аналитической работы
Опыт подсказывает, что без "достаточно большого объема аналитической работы" любая система средней сложности и выше не взлетит.
Кстати, как вы думаете, какой сюрприз (явно ненужный нам) можно получить по этому правилу? Напишите в комментариях, если заметите!
Первое, что заметил: никак не определен статус переписки, если общих проектов нет. Черный список, защита от спама в личку и другие замечательные вещи.
Второе: если когда проект завершен, исполнителю нельзя написать. А если новый проект? Пожалуй, это самое критичное.
Третий момент — это уточнение: если Проект переходит в статус "выполняется", ставится ли у него атрибут "снят с публикации"?
И встречный вопрос: а какой баг заложили вы?
«Плавающие» ошибки в проектах. Как поставить задачу так, чтобы их избежать и не прослыть придирой и формалистом