Вхід і реєстрація
Різне · 7 липня 2014, 20:51 1244
Miroslav Romanenko

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

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

Спасибо!

Теми: requirements, test-plan, tools, вимоги
👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
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
Макс Матюхин программист в Badoo 09.07.2014 18:50

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

Відповісти
Підтримати
Andriy 09.07.2014 16:36

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

Відповісти
Підтримати
Anastasiya Zaytceva Associate Developer в GlobalLogic 09.07.2014 12:34

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

Відповісти
Підтримати
Miroslav Romanenko 09.07.2014 14:21

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

Відповісти
Підтримати
Anastasiya Zaytceva
Oleksii Khorchev Engineering Manager building an organization в EPAM 09.07.2014 07:49

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

Відповісти
Підтримати
Нестор Иванович 09.07.2014 05:25

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

Відповісти
Підтримати
Kostiantyn Kugot Engineering Manager в Oracle 09.07.2014 01:46

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

Відповісти
Підтримати
Max Ischenko Founder в DOU.ua 08.07.2014 13:05

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

Відповісти
Підтримати
Serhiy Muzychenko 08.07.2014 12:44

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

Відповісти
Підтримати
Volodymyr Spodaryk Team / Tech Lead в Dataforest 08.07.2014 12:43

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

Відповісти
Підтримати
Miroslav Romanenko
Alexander Kuznyak Delivery Manager Consultant в сам себе режиссёр 08.07.2014 09:27

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

Відповісти
Підтримати
qadrat qadrat 08.07.2014 10:04

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

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

Відповісти
Підтримати
Alexander Kuznyak
Miroslav Romanenko 08.07.2014 10:22

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

Відповісти
Підтримати
Alexander Kuznyak
Alexander Kuznyak Delivery Manager Consultant в сам себе режиссёр 08.07.2014 12:41

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

Відповісти
Підтримати
Miroslav Romanenko
Дмитрий Мирошник Lead QA Automation Engineer 10.07.2014 02:30

А процессы какие? 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. Возможно припугнуть заказчика глубиной жопы в контексте риск-анализа.
Відповісти
Підтримати
Miroslav Romanenko
Miroslav Romanenko 10.07.2014 10:51

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

Відповісти
Підтримати
Дмитрий Мирошник
Miroslav Romanenko 11.07.2014 11:48

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

Відповісти
Підтримати
Дмитрий Мирошник

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

Не підписуватись
Скористайтесь акаунтом
×
з умовами використання сайту і політикою конфіденційності.