Прийшов час осідлати справжнього Буцефала🏇🏻Приборкай норовливого коня разом з Newxel🏇🏻Умови на сайті
×Закрыть

Soft development.Требования, спецификации для web-приложения. На чем лучше писать?

Здравствуйте, Друзья!
Какими вы пользуетесь инструментами для написания requirements и specifications (FA, SRS), в том числе: блок схем, описаний и примеров в процессе разработки ПО?

Спасибо!

LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Нелюбителям визуальных сред для рисования диаграм может понравиться plantuml.sourceforge.net

Enterprise Architect для любого вида диаграмм и схем. Лучшего средства моделирования на сегодня не знаю.

Окрім перечисленого вище, доволі непогана штука для блок-схем www.draw.io

Очень интересная вещь! Спасибо, Анастасия!

Подивітся в сторону BDD і Gherkin language

в ворде пишем
мокапы в бальзамике рисуем,
а потом ватерфолом их, вотерфолом

На сложных проектах блок-схемы делаем в omnigraffle, wireframes в adobe indesign.

Trello, Skype, бумага. В особо сложных случаях — Google Docs.

www.visual-paradigm.com тільки в реальному проекті не використовував. Але відяшки на сайті дуже цікаві.

в залежності від того скільки девів буде брати участь в розробці...

QA-и уже пишут требования и спецификации? оО
Как бы там не было, список вполне очевиден: Word, Excel, PowerPoint, Visio, майнд-мэпы (любой тул, например XMind), мокапы\скриншоты...

Иногда пишут оказиваетья... например, на курсах SS — есть такие задания).

Та и QA — могут пофиксить баг вместо девов(например, я ради интереса могу что-то пофиксить если оно GUI) xD

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

Формализованные требования это конечно хорошо, но тест план можно составить и без них. В современном мире «быстрых» (краткосрочных) продуктов, функционал которых часто меняется ибо зависит от бизнеса (что часто тоже динамично меняется) классические спецификации давно отошли даже не на второй план а далеко в ящик (не считая waterfall-проектов типа CRM и некоторых других), давно используется формат user stories/mock-ups/screenmaps.
Этот документ тоже называется спецификацией и пишет её обычно BA (Бизнес Аналитик) с (опционально) TR-ом (Техникал Райтером) при тесном общении с продукт овнером и стейкхолдерами.
Как-то так...

А процессы какие? Waterfall или Scrum / Agile?
В случае аджайла юзайте любой agile таск трекер — ту же Jira, к примеру и отмечайте там user stories. Это и будет базой для тест плана. Также рекомендую вести acceptance criteria в описании stories: помогает в написании тест кейсов.
Для блок-схем прекрасно подходит Visio.
В случае ватерфолла

формализованных требований нет
 — бида-бида... Тут зависит от 2 состояний проекта: величины жопы (то есть, субъективного состояния тестирования в проекте: интегральная оценка по следующим параметрам: покрытие, кол-ва найденных high+ severity defects клиентом, усилия, затрачиваемые на актуализацию тест кейсов и т.д. ) и стадии проекта.
1). Жопа: небольшая. Стадия: близка к сдаче. Рекомендации: не трогать, пока не воняет :) Дотянуть проект как есть, если он не планирует развиваться дальше. Сдать и забыть. Любая попытка актуализации требований в этом случае приведёт к нерациональному использованию времени и усилий. Лучше их потратить в актуализацию тест кейсов / тестирование.
2). Жопа: небольшая. Стадия: середина разработки. Рекомендации: провести риск-анализ. В случае наличия серьёзных рисков из-за непонятных требований — действовать. В случае оценки рисков как незначительных (например, задача не уникальна, предметная область хорошо известна и т.д. — оставить и актуализировать исключительно новые требования / изменения к старым, в этом случае прописывая старые).
3). Жопа: небольшая. Стадия: начало разработки. Рекомендации: однозначно накинуть на себя роль бизнес-аналитика. Потом будет хуже :)
4). Жопа: серьёзная. Стадия: близка к сдаче. Рекомендации: провести риск-анализ. Актуализировать области максимальных рисков по убыванию, и актуализировать требования именно в них, насколько хватает времени без сильной потери качества тестирования. Акцентировать внимание на покрытии и приоретизации тест кейсов. Выделить critical path(s).
5). Жопа: серьёзная, полная. Стадия: середина разработки. Однозначно актуализировать всё, на что хватает времени. Объяснить заказчику на основе метрик, зачем нужно актуализировать требования и чем может закончиться пофигистичное к ним отношение. Если метрик нет — ввести. Давить до упора, насколько это возможно.
6). Жопа: серьёзная. Стадия: начало разработки. Рекомендации: Возможен конфликт между командой тестирования и командой разработки и / или заказчиком. Провести риск-анализ, провести анализ процессов, благо, время пока позволяет. Прояснить process gaps. Найти меры по их уменьшению / ликвидации. Ввести метрики. На основе собранных метрик за 2..4 недели и анализа процессов провести общую встречу (сначала внутри команд(ы), затем с заказчиком), показать риски и метрики и выработать стратегию совместной работы, в том числе и в плане требований. Давить не надо, лучше — объяснить выгоду, которую заказчик получит от корректной работы с требованиями.
7). Жопа: полная. Стадия: близка к сдаче. Рекомендации: Аналогично 4, но быстрее. Намного быстрее. Сосредоточиться исключительно на critical path. Поговорить с заказчиком с целью выбить больше времени на тестирование. Если получилось — переходим на режим 5, но опять-таки работаем быстрее. Никаких формальностей, никаких новых метрик — время дорого. В этом случае расширяем critical path вниз по приоритетам и актуализируем всё, что успеваем.
8). Жопа: полная. Стадия: начало разработки. Рекомендации: Я таких не видел :) Обычно на этой стадии глубину жопы оптимистично занижают. Но если вдруг такое есть — вести разъяснительную работу по аналогии с 6. Возможно припугнуть заказчика глубиной жопы в контексте риск-анализа.

Дмитрий, спасибо за исчерпывающий ответ!

А какую версию Jira лучше ставить, For projects или For development?

Подписаться на комментарии