Тестировщики и требования: непараллельные прямые

Автор: Наталья Руколь

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


Роль требований в процессе разработки
Требования похожи на единорогов. Такие же прекрасные мифические создания, несущие людям счастье  В ~99% проектов, с которыми я сталкивалась, требования:

• Были неполным
• Были некорректным
• Отсутствовали

Выбирайте любые пункты из трёх, а иногда и все вместе.

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

Как всегда, у нас есть выбор. Вариант #1 – подождать: а вдруг появятся? Чтобы ожидание не было скучным, можно разбавлять его регулярными жалобами на нехватку требований и байками из серии «а вот в нормальных компаниях…».

И есть вариант #2 – построить процесс таким образом, что у вас появятся требования. Именно об этом варианте мы и поговорим в статье.



Читать дальше

уф... да... без требований плохо!

Вопрос появился.
А по какому принципу требования делились на функциональные и не функциональные?

Например, ограничения на размер картинок почему вдруг попали в нефункциональные требования?

Честно говоря, всеми возможностями форума не пользуюсь.
Что опрос - это принадлежность темы - мне понятно.
А вот что картинка - принадлежность темы, честно говоря не думала. Это интересно! Надо порыться и попробовать темы создавать с картинкой по теме! К этой теме например пририсовать картинку с параллельными/непараллельными прямыми!
Полагала, что картинка это принадлежность ответа(поста).

Вопрос появился.
А по какому принципу требования делились на функциональные и не функциональные?

Например, ограничения на размер картинок почему вдруг попали в нефункциональные требования?

Возник тот же самый вопрос. Дочитал до этого места и решил отложить до прояснения вопроса. Хотел спросить, но был опережен.

уф... еще вопросы появились.

"В ~99% проектов, с которыми я сталкивалась, требования:
Были неполным
•Были некорректным
•Отсутствовали
"

1. Где-то дальше в статье предлагается зафиксировать требования и начать обсуждать с аналитиком.
Т.е. что? Аналитик работал плохо (раз требований нету или они плохие), а тут рррраз -- и осознал, что вот требования надо обсуждать и анализировать?
2. По поводу инструментов. Ежели предполагается некий коллектив запирать в комнате, чтоб требования обсудить и согласовать; то вот бутылку мартини ставлю -- не будут они ни в вики лазить, ни еще куда. Максимум -- крестики поставят на листе бумаги или почеркают этот лист. Или -- вообще просто будут о чем -то рассуждать.
Так что инструмент для сбора требований должен позволять легко печатать эти листы бумаги. Причем -- шрифтом удобном и в простецком виде. Word великолепно подходит!
И БЛОКНОТ!!! Банальный бумажный блокнот для записи потока рассуждений участников!

Вопрос появился.
А по какому принципу требования делились на функциональные и не функциональные?

Например, ограничения на размер картинок почему вдруг попали в нефункциональные требования?

Фунциональные требования отвечают на вопрос "что делать?":
- загружать картинку на сервер
- отображать в форме
- вставлять её в текст сообщения
и т.д.

Нефункциональные требования - все ограничения к этим самым "что делать", отвечающие на вопросы "как", "какие", "какого размера", "сколько", "как часто", "как быстро" и т.д.

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

Почему так? Проверено - удобно!

Можно ли по-другому? Наверное, можно, но в моей практике получилась каша, когда мы делали вложенные требования к "загрузке картинок": "jpg", "png" и т.д. В итоге мы переделывали по схеме, описанной в статье.

уф... еще вопросы появились.

"В ~99% проектов, с которыми я сталкивалась, требования:
Были неполным
•Были некорректным
•Отсутствовали
"

1. Где-то дальше в статье предлагается зафиксировать требования и начать обсуждать с аналитиком.
Т.е. что? Аналитик работал плохо (раз требований нету или они плохие), а тут рррраз -- и осознал, что вот требования надо обсуждать и анализировать?

Угу. Очень силён человеческий фактор.
1) аналитик уверен, что написать все требования - это долго и нудно, а тут ему показывают, насколько просто начать.
2) вместо нытиков "нам нужно вот это" он сталкивается с людьми, которые готовы что-то сами делать, и просят только помощь и поддержку, а не "сделайте всё за меня".
3) в тайм-менеджменте есть приём "съесть слона". "Написать требования к продукту" - это слон, которого скушать нереально. А тут мы режем его на кусочки, и просим объяснить вот эти 4, самые непонятные из 300, требования. Это - запросто, потому что можно сделать быстро!
4) слоник порезан, части сделаны. В моей практике сразу всплывает куча косяков, заводятся баги, что-то меняется к лучшему. Аналитик видит: "ого! потратил час - и столько пользы", и к следующей просьбе "растолкуй вот эти 6 требований" относится с позитивом!
5) если перейти на следующий уровень развития, и помимо требований начать вести измеримые риски качества, можно ввести простую статистику. "Вот здесь, после адекватного выяснения 10 требований, мы нашли 16 багов. Следовательно, невыясненные 290 требований - 464 ненайденные баги. Вы к этому готовы?"

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

2. По поводу инструментов. Ежели предполагается некий коллектив запирать в комнате, чтоб требования обсудить и согласовать; то вот бутылку мартини ставлю -- не будут они ни в вики лазить, ни еще куда. Максимум -- крестики поставят на листе бумаги или почеркают этот лист. Или -- вообще просто будут о чем -то рассуждать.
Так что инструмент для сбора требований должен позволять легко печатать эти листы бумаги. Причем -- шрифтом удобном и в простецком виде. Word великолепно подходит!
И БЛОКНОТ!!! Банальный бумажный блокнот для записи потока рассуждений участников!

В блоконте нет иерархии, структуры, статусов. В общем, давай розовый мартини - когда мы запирались на 2 недели, мы сидели с ноутбуками в шарпоинте.


А вообще, вижу в ответе недоверие "так не получится, аналитика за один день не изменить, требования в системе прорабатывать не получится и т.д."
Без паники! Всё проверено, всё работает :) Не веришь - проверь, только не с целью доказать, что не получится (как говорил Генри Форд: "неважно, что вы доказываете, что можете что-то или что не можете, у вас в любом случае это получится").

Вопрос появился.
А по какому принципу требования делились на функциональные и не функциональные?

Например, ограничения на размер картинок почему вдруг попали в нефункциональные требования?

Фунциональные требования отвечают на вопрос "что делать?":
- загружать картинку на сервер
- отображать в форме
- вставлять её в текст сообщения
и т.д.

Нефункциональные требования - все ограничения к этим самым "что делать", отвечающие на вопросы "как", "какие", "какого размера", "сколько", "как часто", "как быстро" и т.д.
Можно ли по-другому? Наверное, можно, но в моей практике получилась каша, когда мы делали вложенные требования к "загрузке картинок": "jpg", "png" и т.д. В итоге мы переделывали по схеме, описанной в статье.

(пожимая плечами).
Автор в любой своей статье вправе вводить любые свои собственные определения.
Только тогда:
1. Это определение надо формулировать в статье. Желательно в начале статьи.
2. Желательно доказать непротиворечивость системы определений автора и продемонстрировать, что так лучше.

А я вот не поняла, как связано название с содержанием. Могу, конечно, придумать объяснение, которое меня даже устроит, но сам факт непонимания есть.

А вообще, вижу в ответе недоверие "так не получится, аналитика за один день не изменить, требования в системе прорабатывать не получится и т.д."
Без паники! Всё проверено, всё работает :) Не веришь - проверь, только не с целью доказать, что не получится (как говорил Генри Форд: "неважно, что вы доказываете, что можете что-то или что не можете, у вас в любом случае это получится").

Недоверие?
К поеданию слона по кусочкам? Нисколько - работает (ну... это ж такая распространная фишка!).

Обсуждать статью, я думаю, интересней.

Наташа!
Вот прямо здесь, на форуме, попробуй создать тему с картинкой.

Требование:
Создание тем.
Вставка картинок.

есть же в твоей статье? Так?

Т.е. чтоб была тема, а где-нибудь рядом с опросом к теме -- и картинка.

У меня не получилось. (извините, модераторы... ну да... эксперимент, который вам лишние хлопоты принес...)
Вполне возможно - что плохо работаю с форумом!

Ну вот если создашь -- тогда есть смысл статью обсуждать.
Если не удастся -- смысла нету обсуждать статью-то.

Вообще сбор, анализ, и фиксирование требований -- сильно объемная тема. Взгляд тестировщика.
На мой вкус -- очень такая темка подходящая для бурного обсуждения на SQA 10!

Вот!

Наталья, вот такая ситуация.
Тестировщик видит некое стечение обстоятельств, которые сами по себе проблемой на текущий момент не является, но в будущем если и возникнет что-то, то сразу тяжёлое. Идёт к начальнику аналитиков с предложением формализовать данную ситуацию. А тот отправляет к разработчикам, которые в подобных случаях без задачи от аналитика ничего делать не хотят. Как добыть требования и заставить их придерживаться?

Автор в любой своей статье вправе вводить любые свои собственные определения.
Только тогда:
1. Это определение надо формулировать в статье. Желательно в начале статьи.
2. Желательно доказать непротиворечивость системы определений автора и продемонстрировать, что так лучше.

Я не ввожу определений! Анализ (любой, при проектировании продуктов или при проектировании тестов) - это искусство, а не ремесло. Если собрать в одной комнате 5 супер-пупер аналитиков, а в другой 5 супер-пупер тест-дизайнеров, и выдать в каждой комнате одинаковые задачи, каждый участник сделает результат по-своему. Нет "единственно правильного" решения, и я его не навязываю - это то же самое, что объяснять художнику как "правильно" рисовать. Хочется сделать по-другому? Welcome, это может получиться даже лучше.

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

картинка  1.png   4,35К   5 Количество загрузок:

Наталья, вот такая ситуация.
Тестировщик видит некое стечение обстоятельств, которые сами по себе проблемой на текущий момент не является, но в будущем если и возникнет что-то, то сразу тяжёлое. Идёт к начальнику аналитиков с предложением формализовать данную ситуацию. А тот отправляет к разработчикам, которые в подобных случаях без задачи от аналитика ничего делать не хотят. Как добыть требования и заставить их придерживаться?

Вернуться к аналитику и сказать, что разработчики делать не хотят :) Предложить вместе обсудить, выяснить как всё-таки правильно сделать, формализовать/описать договорённость. После этого уже идти к разработчикам. Повторить цикл N раз пока результат не будет достигнут :)

картинка  1.png   4,35К   5 Количество загрузок:

Ага.
Я так в пост (сообщение) тоже могу вставить.

А вот темку создать с картинкой не вышло!!
И картинка дивная к параллельным прямым!

Вернуться к аналитику и сказать, что разработчики делать не хотят :) Предложить вместе обсудить, выяснить как всё-таки правильно сделать, формализовать/описать договорённость. После этого уже идти к разработчикам. Повторить цикл N раз пока результат не будет достигнут :)

Ситуация осложняется тем, что аналитик хоть и самый главный, но работает не так давно и почему-то не над той областью, по которой поступило предложение (хотя она в его ведомости). В подчинении у него по данной области только внедренец, которому до лампочки подобные вопросы.
К тому же это уже будет походить на "выпрашивание требований". Проще говоря, не встанет ли поперёк горла такая назойливость?

Ситуация осложняется тем, что аналитик хоть и самый главный, но работает не так давно и почему-то не над той областью, по которой поступило предложение (хотя она в его ведомости). В подчинении у него по данной области только внедренец, которому до лампочки подобные вопросы.
К тому же это уже будет походить на "выпрашивание требований". Проще говоря, не встанет ли поперёк горла такая назойливость?

Давайте разбирать конкретнее:
- Чем чревато "неразбирательство" по вопросу, который Вы поднимаете? Если произойдёт бяка, которой Вы опасаетесь - во сколько $, или часов, или ещё чего-нибудь она встанет компании?
- Какова вероятность того, что эта бяка произойдёт? Сколько %, навскидку?
- Чтобы не допустить эту проблему, какое-то время придётся потратить Вам, аналитику, разработчику, протестировать результат. Оцените эти затраты в $ или времени, в той же единице что и первый пункт.

А теперь - немножко магии :) Умножьте первые два значения и сравните с третьим. Если третье больше - не парьтесь и не мешайте людям работать. Если перемножение первых двух пунктов существенно больше - покажите свои выкладки РМу и объясните, что вы экономите для проекта кучу денег.

Ситуация осложняется тем, что аналитик хоть и самый главный, но работает не так давно и почему-то не над той областью, по которой поступило предложение (хотя она в его ведомости). В подчинении у него по данной области только внедренец, которому до лампочки подобные вопросы.
К тому же это уже будет походить на "выпрашивание требований". Проще говоря, не встанет ли поперёк горла такая назойливость?

Давайте разбирать конкретнее:
- Чем чревато "неразбирательство" по вопросу, который Вы поднимаете? Если произойдёт бяка, которой Вы опасаетесь - во сколько $, или часов, или ещё чего-нибудь она встанет компании?

Я вот совсем не уверен, что тестировщик практически любой крутости может грамотно оценить, в какое количество килобаксов встанет компании тот или иной инцидент. Просто из-за недостатка информации, которую он, в общем-то, и не должен знать.

Я вот совсем не уверен, что тестировщик практически любой крутости может грамотно оценить, в какое количество килобаксов встанет компании тот или иной инцидент. Просто из-за недостатка информации, которую он, в общем-то, и не должен знать.

Таки да, далеко не любой крутости и далеко не любого уровня знаний по проекту, но автор написал:

Наталья, вот такая ситуация.
Тестировщик видит некое стечение обстоятельств, которые сами по себе проблемой на текущий момент не является, но в будущем если и возникнет что-то, то сразу тяжёлое.

Надеюсь что я правильно понимаю "что-то сразу тяжёлое".

Я вот совсем не уверен, что тестировщик практически любой крутости может грамотно оценить, в какое количество килобаксов встанет компании тот или иной инцидент. Просто из-за недостатка информации, которую он, в общем-то, и не должен знать.

Таки да, далеко не любой крутости и далеко не любого уровня знаний по проекту, но автор написал:

Наталья, вот такая ситуация.
Тестировщик видит некое стечение обстоятельств, которые сами по себе проблемой на текущий момент не является, но в будущем если и возникнет что-то, то сразу тяжёлое.

Надеюсь что я правильно понимаю "что-то сразу тяжёлое".

Как я вовремя вернулась: один мой вопрос уже задали, и ответ уже есть (-: Потому перейду к "сразу тяжёлому".
Наверно, лучше сразу описать ситуацию, чем говорить общими словами. Приложение состоит из нескольких модулей. Есть служебный со всякими настройками, правами и пр. В нём также имеется раздел справочники. Справочник -- хранилище данных, из которого в нужном месте подтягиваются значения в поле типа "выпадающий список". Значения из справочников могут использоваться в других справочниках. Для сложных модулей уровень вложенности ещё здесь уже 2-3, плюс вставка в сам модуль. А сверху на это накладывается невидимая логика: зависимости между полями в самом модуле. Все справочники всех модулей хранятся в общей куче, невозможно узнать, как они связаны между собой и модулями.
Итак, имеем область, которая используется редко со стороны разработки и никогда со стороны пользователей. В последнее время у меня лично стало возникать много мелких проблем, связанных со справочниками: то при переходе на другую базу потерялось 70% содержимого, то внешне кажется, что не работает невидимая логика. В итоге за последние две недели 4 дня (а ведь время могло бы исчисляться в минутах) потратила на работу с этими справочниками, попутно выловив баги, пустые справочники и неудобства. Если баги я ещё могу занести в джиру и их поправят, то с предложениями по улучшению в последнее время всё намного хуже. От них просто отмахиваются. Соответственно, мне нужно превратить предложение в баг. А для этого нужно сформировать требования и заручиться поддержкой со стороны аналитики или хотя бы внедрения (последних волнуют справочники только тогда, когда с ними проблемы).

И в догонку к предыдущему вопросу. Как узнать, 4 дня моей работы это дорого для фирмы или нет?