суббота, 13 августа 2011 г.

О революциях и перегибах

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


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

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

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

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

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

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

Так что для меня высказанная мысль не является революционной, она - скорее просто перегиб. Как странно думать, что исключительно поиск ошибок ПОСЛЕ реализации может решить проблему качества, так же странна и мысль о том, что исключительно проверка требований ДО реализации спасёт мир. О качестве надо заботиться на каждом этапе, можно менять пропорции заботы на разных этапах, но выбрасывать какой-то этап полностью - вряд ли.

А в заключение мне очень хочется высказать одну простую мысль (хотя она может показаться кому-то не связанной с тем, что написано выше, но для меня - всё-таки по теме):

если вы смогли посмотреть на проблему с другой стороны - это отлично; если вы при этом решили, что этот взгляд единственно верный - подумайте ещё раз :)

35 комментариев:

  1. Я не слышал выступления Сергея, но зная его как профессионального "еретика", могу догадаться, что так все и было. Мысль идеальных требований в общем не нова, правда может имелось в виду идеальная спецификация? Все-таки требования и спецификация несколько разные вещи. Далее я так полагаю, что если при написании требований вы так же указываете и способ проверки достижения требования, а программист, делая свою работу, выкладывает код только удовлетворяющий этим критериям, то гипотетически идея Сергея имеет место быть. Вопрос а как убедится что требования составлены верно? Что значит проверка требований? Если нельзя 100% проверить код, почему можно идеально проверить требования?
    Но в целом странная, конечно, мысль. Что если у нас есть спецификация проект, а мы делаем по спецификации, то ошибок не будет и тестирование не нужно. В таком случае зачем на пром. предприятиях существуют отделы проверки качества продукции? и Почему возникает брак? А ведь там по сути на входе идеальная спецификация, точно рассчитанный технологический процесс, подобранное оборудование, точное определение действия человека??

    ОтветитьУдалить
  2. Не очень понимаю, за счёт чего "идеальные требования" приводят к ненужности тестирования, ведь с ними мы избавляемся только от ошибок в требованиях, но не от ошибок архитектуры, разработки, интеграции.

    ОтветитьУдалить
  3. Эдуард, спасибо за комментарий.

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

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

    И да - хороший пример с промышленными предприятиями :)

    ОтветитьУдалить
  4. Наталья, спасибо - уже после написания заметки подумала, что забыла подчеркнуть, что ошибки в спецификации - это только один тип ошибок.

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

    ОтветитьУдалить
  5. Да, Вы правильно всё описали. Но хотел бы ещё немного добавить, так как недавно читал вот эту замечательную статью http://it-boost.com/mentalitet о разнице в менталитетах. И Сергей Мартыненко как я вижу живое доказательство этой статьи. Мы будем долго при долго собирать и писать длинные докуменыт. А за это время наши конкуренты попробуют несколько разных вариантов и выпустят нужный пользователям продукт, может быть даже с багами (помню к примеру 2 года назад твитер через день падал, а теперь валом народ пишет его клоны, а он не поколебим), но это будет нужный продукт, люди буду пользоваться, а у Сергея будет спецификация :)

    ОтветитьУдалить
  6. Павел, спасибо за комментарий, и спасибо за ссылочку - интересная заметка.

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

    Это уже скорее я не представляю, КАК можно БЫСТРО сделать такую спецификацию, которая и динамическое тестирование сделает ненужным. Насколько я понимаю, Сергей верит в то, что быстро выверить спецификацию - вполне легко. Мой опыт говорит о том, что быстро это сделать не получится; быстро - можно выявить только часть проблем, причём, наверное, лежащих на поверхности. А выявление настолько большой части проблем на уровне спецификаций, чтобы тестирование после выпуска продута стало ненужным - вряд ли будет намного быстрее, чем умеренные проверки на уровне спецификаций + умеренное динамическое тестирование.

    Но в целом - Сергей скорее сторонник быстрого выпуска продукции, пусть и с багами.

    ОтветитьУдалить
  7. @Lena
    Вот и я не представляю как сделать быстро идеально полную без агрехов спецификацию, поэтому и написал, что это будет длительный бесполезный процесс.

    ОтветитьУдалить
  8. В этом, Павел, мы с Вами в общем-то сходимся :)

    Но стоит допустить, что может я просто как-то совершенно неправильно поняла или недопоняла мысль Сергея...

    ОтветитьУдалить
  9. Имхо есть несколько моментов, благодаря которым при самых идеально составленных требованиях от тестирования конечного продукта всё равно нельзя будет отказаться -
    1. Практически все требования описывают позитивные сценарии. Теоритически можно пробовать "стелить солому", и в описании требований учесть все возможные негативные сценарии. Но такое решение обычно неэффективно. Значит, после создания основной функциональности кому-то придётся думать как это сломать.
    2. Если у проекта идеальные требования и такие же идеальные девелоперы, это может избавить уверенного манагера от модульного тестирования. Очень смелый манагер может даже обойтись без интеграционного тестирования. Но где найти доверчивого заказчика, который обойдётся без приёмочного тестирования? ))

    Ну а в целом, в идее "при идеальных требованиях нет необходимости в тестировании" наблюдается логический баг )))
    Ибо если уж что и сделает тестирование избыточным - так это идеальный разработчик, а не идеальная документация. Вернее, их сумма - некачественный код или неудачно применённую технологию не спасёт никакая документация.

    ОтветитьУдалить
  10. Kori, спасибо за комментарий! Про "некачественный код или неудачно применённую технологию" - очень хорошо сказано :)

    А ещё знаете, пока писала эту заметку и отвечала на комментарии - постоянно примеряла всё на свой текущий проект, что, наверное, естественно. Так вот, мне очень понравилась Ваша мысль про негативные сценарии, но при этом подумала, что в спецификации моего проекта всё-таки описание поведения для большинства негативных сценариев предусмотрено, хотя это скорее исключение, чем правило :)

    ОтветитьУдалить
  11. Пожалуйста! Было интересно искать баги в озвученной идее. Хотя я процентов на 90% уверен, что Сергей выбрал данную формулировку на выступлении в качестве "а давайте бросим гранату".

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

    ОтветитьУдалить
  12. Честно говоря, Kori, я люблю провокации - они действительно порождают дискуссии и споры, которые как раз наиболее интересны. Но в том выступлении, на котором я была, провокационным было, пожалуй, только название - о "вреде" тестирования; а содержание выступления - лично для меня не стало ни гранатой, ни провокацией, о чём я собственно в заметке и написала :)

    ОтветитьУдалить
  13. Хочу вернуться к примеру с ОТК на предприятиях - вы в курсе, что при массовом производстве контролируется хорошо если 1% продукции в партии? А чаще и того меньше. Сколько-сколько тесткейсов у вас получилось? Сто тысяч? Несколько миллионов? Время - наш с заказчиком враг. Нет тестирования - есть время. Поэтому давайте думать, как его таки выбросить. Что просится на ум, если(по словам Сергея) источник до 70% багов(в СНГшном IT) - противоречивые(неясные) требования, неидеальные спецификации, промахи в архитектуре? Притом эти баги так дешево фиксятся, дух захватывает.
    А если проект уже запущен, вовсю кодируется, то да, с мерами по дешевой борьбе с багами как-то опоздали. Суть-то в чем - раз все равно штат выращиваем - так может вырастим его десятком-другим аналитиков, чем полусотней тестеров?

    ОтветитьУдалить
  14. Господин Анонимный, давайте обратим внимание:

    1) Массовое промышленное производство и IT - это всё-таки немного разные вещи. Что хорошо при штамповке ста тысяч одинаковых деталек, то не обязательно должно прокатить при выпуске одного (!) сложного (!) программного продукта, являющегося результатом интеллектуальной (!) деятельности, правда?

    2) Кто-то разве спорит с тем, что аналитики нужны? Или с тем, что надо эти самые требования тестировать? Да, там кроется много проблем. Да, с этим надо бороться. Но зачем перегибать-то? Почему если тестировать требования, то надо полностью отказаться от тестирования уже разработанного продукта? Давайте может искать золотую середину, а не впадать в крайности?

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

    ОтветитьУдалить
  15. Вы знаете, интеллектуалы построили себе коллайдер в Швейцарии, и вряд ли у нас с ними много общих тем. Чем отличается наша работа от работы операциониста в банке? Мы если и не штампуем 100000 деталек(модулей, проектов), то по крайней мере от нас этого ждут - рынок требует. И изменения, вносимые в процесс, будут превращать разработку в штамповку деталек, со всеми вытекающими, то сделано предложение - перенести затраты труда, уходящие на тестирование написанного кода в тестирование до написания. Это не касается уже начатых проектов - таких как ваш.
    Любой созидательный труд - процесс непростой и небыстрый. И в целом, баги будут находиться - но пусть они будут находиться редко - и пользователями. Последние привыкли ко всему, и определенный уровень багов переживут. А бизнес - быстро и своевременно получит прибыль. Это жизнь, в ней нет места идеальному коду, панацеям, серебряным пулям, и прочим сферическим коням.
    Это то, что я вынес для себя позитивного. Но есть и беспокойное белое пятно - кадровый вопрос. Тестировщик - дешев. Те, кто сейчас заполняет такие вакансии в массе своей - некомпетентные новички. Насколько полезным будет тестирование такими людьми требований?

    ОтветитьУдалить
  16. @Анонимный
    Ага, только в IT есть одна, всего лишь одна проблема: сегодня нужны круглые детальки, завтра квадратные, а после завтра форме мишек гамми.

    ОтветитьУдалить
  17. Ох, господин Анонимный, вы бы хоть подписались - очень же неудобно обращаться к вам "господин Анонимный".

    Как у вас всё быстро и просто решается.

    К моему проекту это не имеем отношения? На основании чего вы делаете такие выводы? У нас итеративная разработка, каждая итерация - новые требования и новая функциоальность, мы постоянно проходим этот процесс. Ну да ладно, забракуем такие проекты. Бог с ним, плюнем на все старые проекты.

    Но вот все новые - построим ПО-НОВОМУ, ПРАВИЛЬНО, о как.

    Да бог с ними - с багами, подумаешь - ну что-то найдут пользователи после разработки. Их же ж тестерам искать ДОЛГО. Простите - а сроки чего и чего мы сравниваем? То, что профессиональный тестировщик, хорошо зная проект, и за день может найти толпу багов, не допустив их попадания к пользователю - ну это ж просто недопустимые потери времени! Давайте ПОЛНОСТЬЮ, обязательно ПОЛНОСТЬЮ откажемся от тестирования тестировщиками. А пользователи потерпят, переживут.

    Кстати, а почему бы не пойти дальше? Если главное - время, то зачем нам вообще и проверки требований? Ну выпустим продукт с багами, вы ж говорите, что это не страшно совсем... Ах да, я забыла - ведь аналитики работают БЫСТРО, супер БЫСТРО. Они ж моментально находят все проблемы в требованиях. Тут вообще смешно говорить о времени, правда?

    А тестировщики ж все дешёвые и неэффективные. Давайте откажемся от толпы неэффективных тестировщиков. У нас есть новый выход - аналитики!.. Давайте срочно наштампуем толпу аналитиков!..

    Вы простите меня за такое изложение, но послушайте себя, пожалуйста - какие-то сплошные перегибы.

    Тестирование = потеря времени
    Тестировщики = дешёвые и некомпетентные
    Аналитики = спасение положения
    Анализ требований = нахождение ну прям подавляющего количества проблем
    ...

    Вам самому не странно?

    ОтветитьУдалить
  18. Павел, спасибо за комментарий.

    Честно говоря, я не знаю - может у нас с господином Анонимным просто слишком разный опыт?

    Может, если, например, речь идёт о клепании из года в год веб-магазинчиков, то это и можно сравнить с выпуском однотипных деталек? Я не знаю, я не занималась магазинам. Но на всякий случай - прошу прощения у тех, кто их тестирует; полагаю, что там тоже всё не так просто...

    А лично я сталкивалась в основном только со сложными индивидуальными проектами...

    ОтветитьУдалить
  19. @Lena
    Может быть, некоторые верстание на html называют программированием :)
    По моему г-н Анонимный, это либо Сергей Мартыненко, либо очень толстый тролль :)

    ОтветитьУдалить
  20. Не думаю, Павел, что Сергей Мартыненко стал бы прятаться за анонимностью, споря с маленькой девочкой Леной :)

    ОтветитьУдалить
  21. Ну, чтож. Закройте блог от анонимных комментариев. Честно, не хотел вас спровоцировать, больше не буду.

    ОтветитьУдалить
  22. Если бы хотела от анонимов закрыть блог - давно закрыла бы. Просто не у всех есть google account, поэтому анонимы разрешаются. Но люди, как правило, подписываются в теле коммента - ну чтоб обращаться к ним можно было по имени.

    Если вас устраивает "господин Анонимный" - то не вопрос, могу и дальше так вас называть.

    Провоцировать меня - нет, вы не провоцировали. На что собственно? %)

    ОтветитьУдалить
  23. 22 комментария!!!

    Сергей молодец, провокация удалась :)

    ОтветитьУдалить
  24. НО!!!

    Думала-думала, вернулась, решила высказаться :)

    С общей предпосылкой я, пожалуй, согласна. У меня сейчас есть проект, такой маааасенький-мааасенький, и мне казалось, что требования ему особо и не нужны. Надо спрототипировать, посмотреть, а там уже думать, что менять. Некий testing-driven development получается, причём вполне осознанный: я не могу понять, что мне нужно, пока не "пощупаю" прототип.

    Но сколько проблем последнее время повсплывало!!! Сколько раз одно и то же переделывали то в одну, то в другую сторону... И вот теперь меня сильно гложут сомнения по поводу выбранного подхода, и кажется, что продумав изначально требования, можно было бы сэкономить половину ресурсозатрат на разработку, а заведённых дефектов было бы раз в 5 меньше.

    НЕТ! Я не готова сказать "тестирование было бы не нужно", этот посыл Сергея я расцениваю скорее как грамотную провокацию. Но НАСКОЛЬКО МЕНЬШЕ его было бы нужно, и насколько более выгодным это было бы для проекта!

    p.s. Если ничего не путаю, Сергей руководит тест-командой, что противоречит его суждениям и подтверждает идею с закидыванием гранаты. Приглашу-ка я его сюда, интересно услышать его комментарии.

    ОтветитьУдалить
  25. Наталья, простите, не совсем поняла: "С общей предпосылкой я, пожалуй, согласна" - это с какой? С той, что если писать/тестировать требования, то это решит много проблем на ранних этапах? Но ведь это же очевидно, или нет? Неужели я зря так ошарашено пишу, что Сергей долго объяснял очевидные вещи? Может это действительно откровение? Но ведь когда я на следующий день на работе за обедом про это сказала, то моя подруга-тестировщица тоже удивлённо заметила (примерно, за цитату не ручаюсь): "Да это любой тестировщик максимум ко второму году работы понимает!" Или может и я, и моя подруга - такие нетипичные и оторванные от народа? %)

    А что касается провокации, то что же это получается - сказать что-то очевидное + сказать что-то заведомо э... неразумное и легко отрицаемое - это и есть формула провокации? Если так, то буду знать, спасибо...

    ОтветитьУдалить
  26. А еще, если подумать, то проверка 1% на промышленном производстве сравнима с классами эквивалентности. В целом, мне кажется, что идеи менеджмента качества применимы и к ПО тоже.

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

    Имхо, обе крайности - неразумны.

    ОтветитьУдалить
  27. red_foks, точно! Как раз вчера думала о том, что аналогия с промышленным производством если и может быть проведена, то немного не так, как это делал господин Анонимный:

    проверять каждую произведённую детальку в промышленном производстве - это как проверять каждое возможносе входное значение для программы. Это не делают они, на промышленном производстве, этого не делаем и мы, тестируя ПО. Будете смеяться, но я тоже как раз о классах эквивалентности тогда и подумала :) Так что спасибо, что вы эту мысль зафиксировали :)

    (Либо если уж говорить о штамповке одинакового, то давайте уж тогда сравним со штамповкой готового софта на диски (для коробочного продукта); но это совсем не по теме получается...)

    А по поводу крайностей - я тут как раз и возмущаюсь :) перегыбы это...

    ОтветитьУдалить
  28. Лена, написала мысли по поводу такой аналогии - http://redfoks.blogspot.com/2011/08/blog-post_16.html

    ОтветитьУдалить
  29. О, очень интересно почитать будет! Сейчас работы навалилось много, поэтому вечером почитаю - чтобы вдумчиво, а не на бегу - и уже в Ваш новенький блог отпишусь :)

    ОтветитьУдалить
  30. 1. Это не провокация.
    2. Это не граната.
    3. Это не троллинг.
    Если вы помните, мы собирались не на семинар, мастер-класс или тренинг. Мы собрались "побухтеть". Что неплохо получилось.

    Я веду некоторые изыскания, и материал "о вреде наиболее распространенного способа разделения проектных ролей" - одно из этих изысканий. Иногда я обкатываю некоторые из логических построений с коллегами. Бывает находим дыры, бывает находим неувязки.

    Если кто-то соберет вопросы и противоречия в единый список - будет здорово. Я попробую ответить. Только с силами собраться нужно.

    ОтветитьУдалить
  31. А вот и Сергей :) Спасибо за комментарий

    Конечно, я помню, что это было "побухтеть" - ну вот собственно про свои впечатления я и отписалась. Так что тут у нас тоже маленькое "бухтелово" получилось - может какие любопытные мысли тут проскочили.

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

    А если у вас будет желание прокомментировать что-либо из высказанного здесь - в заметке или в комментах - буду рада :)

    А сама я вот планирую ещё по одному эпизоду с той встречи отписаться... О-)

    ОтветитьУдалить
  32. Корректно поставленную задачу (имеющую единственное правильное решение и высокой степени сложности), например на олимпиаде по математике... любой дурак решит на отлично, можно не проверять!

    ОтветитьУдалить
  33. тем не менее прийти к "правильному" решению можно разными путями - грамотная спецификация должна указывать почему выбран именно этот путь.. (к сожалению требования не всегда понятно излагают поставленные цели и связи между ними). Отказ от тестирования - отказ от проверки достижения цели.. но.. частично эта работа тестировщика выполняется и аналитиком и программистом. Определить степень соответствия цели (верификация и валидация) - это типа решения ОБРАТНОЙ задачи математики - то, для чего нужны тестировщики.

    ОтветитьУдалить
    Ответы
    1. "Отказ от тестирования - отказ от проверки достижения цели" - спасибо, понравилась формулировка! Очень просто и доходчиво (хотя в целом тестирование - это гораздо шире) :)

      Удалить