Ron Patton дает следующее опеределение загадочному слову software bug:
Не зная, куда податься, они пытаются по крайней мере убедиться в том, что конечный продукт соответствует спецификации.
Что не плохо, но!
Очень важным является именно 4 пункт. Фактически этот пункт означает ошибку в ТЗ. А, как все мы знаем, ТЗ тоже надо тестировать. На полноту, корректность, осуществимость, необходимость, проверяемость и недвусмысленность.
Что будет, если мы этого не сделаем? А будет то, что пользователь, пройдя по своему сценарию использования, будет возмущаться поведением продукта. Потому что оно "само собой подразумевалось". Ну, это хороший вариант развития событий. Бывают еще и другие, когда, например, из-за тяжелой реализуемости съезжают сроки. Или из-за сложной же проверяемости...
Но пользователю то важна двусмысленность! А точнее, ее отсутствие. И еще желательно, чтобы его мысли прочитали и реализовали даже то, чего не было в ТЗ :) Но должно было быть!
Поэтому - не забываем о том, что мы здесь собрались не только для того, чтобы сверить то, что есть, с тем, как это описали. Не забываем про 4 и 5 (!) пункты.
В пятом пункте говорится о том, что после нас - все. Обратного пути нет. Дальше с приложением будут работать уже реальные пользователи. И мы - та последняя инстанция, которая должна взглянуть на продукт не только с точки зрения "оно работает, как написано", но и с точки зрения того, кто в итоге будет с ним работать.
Может быть, приложение работает слишком медленно? Или тяжело понять, что есть что? Например, где кнопка входа в личный кабинет, где отменить эту надоевшую спам-расслыку итд итп. Посмотрите на продукт глазами того, кто будет использовать его по назначению, не сверяясь с ТЗ, а просто выполняя какую-то свою задачу, которую данное приложение должно, по идее, облегчить.
Просто помните о том, что тестирование - не поиск ошибок! :)
- The software doesn`t do something that the product specification says it should do.
- The software does something that the product specification says it shouldn`t do.
- The software does something that the product specification doesn`t mention.
- The software doesn`t do something that the product specification doesn`t mention but should.
- The software is difficult to understand, hard to use, slow, or - in the software tester`s eyes - will be viewed by the end user as just plain not right.
- Продукт не делает что-то, что, согласно спецификации (далее - ТЗ), должен делать.
- Продукт делает что-то, что, согласно ТЗ, делать не должен.
- Продукт делает что-то, что в ТЗ не указано.
- Продукт не делает что-то, что в ТЗ не указано, хотя должно.
- Продукт очень сложный для понимания, трудный в использовании, медленный, или - глазами тестировщика, который смотрит на продукт как конечный пользователь, делает что-то... просто не правильно!
Не зная, куда податься, они пытаются по крайней мере убедиться в том, что конечный продукт соответствует спецификации.
Что не плохо, но!
Очень важным является именно 4 пункт. Фактически этот пункт означает ошибку в ТЗ. А, как все мы знаем, ТЗ тоже надо тестировать. На полноту, корректность, осуществимость, необходимость, проверяемость и недвусмысленность.
Что будет, если мы этого не сделаем? А будет то, что пользователь, пройдя по своему сценарию использования, будет возмущаться поведением продукта. Потому что оно "само собой подразумевалось". Ну, это хороший вариант развития событий. Бывают еще и другие, когда, например, из-за тяжелой реализуемости съезжают сроки. Или из-за сложной же проверяемости...
Но пользователю то важна двусмысленность! А точнее, ее отсутствие. И еще желательно, чтобы его мысли прочитали и реализовали даже то, чего не было в ТЗ :) Но должно было быть!
Поэтому - не забываем о том, что мы здесь собрались не только для того, чтобы сверить то, что есть, с тем, как это описали. Не забываем про 4 и 5 (!) пункты.
В пятом пункте говорится о том, что после нас - все. Обратного пути нет. Дальше с приложением будут работать уже реальные пользователи. И мы - та последняя инстанция, которая должна взглянуть на продукт не только с точки зрения "оно работает, как написано", но и с точки зрения того, кто в итоге будет с ним работать.
Может быть, приложение работает слишком медленно? Или тяжело понять, что есть что? Например, где кнопка входа в личный кабинет, где отменить эту надоевшую спам-расслыку итд итп. Посмотрите на продукт глазами того, кто будет использовать его по назначению, не сверяясь с ТЗ, а просто выполняя какую-то свою задачу, которую данное приложение должно, по идее, облегчить.
Просто помните о том, что тестирование - не поиск ошибок! :)
Предлагаю пройти по одной из веток, критикующих этот подход.
ОтветитьУдалитьТЗ нет. Совсем нет. Что, все баги из пунктов 1-4 исчезли?
У нас остается пункт номер 5 :)
УдалитьА вместо ТЗ - наша логика. А еще то, что лежит в головах менеджеров, разработчиков и пользователей. Но лучше все-таки завести документацию, иначе это может печально окончится.
Если, конечно, это не короткий проект "сдал и забыл"
А чем короткий проект хуже остальных? Чем он заслужил такое отношение?
УдалитьЗЫ: Люди живут без документации и не особо жалуются.
Какое-такое?
УдалитьНормальное отношение. Просто если проект короткий, проще быть без документации, потому что все - в головах сотрудников.
А если проект большой, народа много? Бегать собирать информацию? Один тестировщик пришел, второй пришел ровно то же самое узнать, третий... Чем хорошо?
Документация не просто так ведь придумана была. А для фиксирования требований, в конце концов, чтобы тебе потом не сказал Заказчик, что ему функций мало, сделайте больше.
Чтобы искать ошибки на ранней стадии. Аналитик пишет документацию, разработчик выверяет со своей стороны. тестировщик со своей. А если информация только в головах, можно что-то упустить...
И люди, кстати, могут жить вообще ни разу не эффективно и не жаловаться, это не показатель. Знаю людей, которые работают ради "пришел, отсидел 8 часов и ушел".
"Такое" это "сдал и забыл".
УдалитьАргументы вида "это же не просто так придумано было" попахивают confirmation bias и другими, куда более опасными болячками. А заказчик он все равно придет и скажет сделать больше фич - было ли там ТЗ или нет. Ему надо - он попросит. Если юридически оно никак не регулируется - еще и проблем вам создаст. Но ТЗ имеет весьма отдаленное отношение к юриспруденции. А ТЗ как средство прикрыться от заказчика это вообще работа в стиле "прикрой свою пятую точку".
Чтобы искать ошибки на ранней стадии совсем не обязательно ТЗ. Достаточно быстро получить прототип и какое-нибудь описание архитектуры. Там, как правило, куда более страшные ошибки чем "у вас тут запятая в ТЗ пропущена".
Про эффективность работы и "пришел, отсидел 8 часов и ушел" не понимаю. Особенно после того как тот же человек в качестве аргумента приводит CYA-programming.
Сергей, мы можем с вами долго спорить о возвышенном, но, положа руку на сердце - вы действительно считаете, что без ТЗ намного лучше?
УдалитьМы ведь с вами оба понимаем, что в большинстве компаний отсутствие ТЗ приведет к куче ошибок и нестыковок. Потому что - человеческий фактор.
Да, можно бить себя пяткой в грудь и говорить о том, что в таких командах просто идиоты собрались, и что нормальным людям "достаточно быстро получить прототип и какое-нибудь описание архитектуры". И тем не менее. Такие команды были, есть и будут есть.
На исследование прототипа не хватает опыта, знаний. А то и просто к коду не допускают. Бывают и такие команды, да-да. И что им делать?
И сломанный телефон опять же, никто не отменял. Требования заказчика без ТЗ дойдут до разработчиков-тестировщиков не в том же виде, в котором были высказаны изначально. Или вы считаете, что только команды, где все общаются с заказчиком (ну митинги например, общие), имеют право на существование?
И я не сопоставляла эффективность и "пришел, отсидел", кстати. Хотя, я считаю, они взаимосвязаны. Но я говорила о том, что люди могут работать и не жаловаться, что совсем не означает того, что процесс поставлен хорошо и в нем нечего улучшать
Я считаю что ТЗ в том виде в котором они существуют в адской бездне аутсорсинга и энтерпрайза это бессмысленная трата человеческих усилий и бумаги. А учитывая, что большая часть тестировщиков хочет "ТЗ про все вообще" - оно еще хуже.
УдалитьЕсли в кратце, то все как-то так: http://gettingreal.37signals.com/ch11_Dont_Do_Dead_Documents.php
И дело не в человеческом факторе или людях-идиотах. Я вообще склонен думать о людях хорошо (по крайней мере до тех пор пока мне несколько раз не докажут что все не так). Пресловутый "человеческий фактор" это зачастую проявление процессуальных и организационных проблем. Про то как это лечится написано очень много, но люди предпочитают собирать все те же грабли что и 20 лет назад и винить в этом всех подряд. Это нормально и монструозное ТЗ тут ничем не поможет. Ну ок, превратит один кусок проблем в другой кусок проблем, но ничего принципиально не решит.
ТЗ это не панацея, а просто вспомогательный инструмент. Не стоит им затыкать организационные проблемы и недостаток технических компетенций.
И да, ряд команд не имеет права на существование. Ровно как и тестирование, но тут хватит простой цитаты:
"Большую часть тестирования что я видел надо автоматизировать, а потом эту самую автоматизацию вместе с породившим его тестированием выкинуть" (с) Julian Harthy
Ну чтож, мне повезло больше, я видела вполне нормальные примеры ТЗ, не "мертвые документы"...
УдалитьЯ вообще себе слабо представляю, как команда, пусть даже небольшая, будет делать проект без документации. Обсудили, сделали.
Через месяц всплывает вопрос, люди пытаются вспомнить, почему сделали именно так, а не иначе, и не помнят... А ведь, возможно, логика была.
"ТЗ это не панацея, а просто вспомогательный инструмент." - тут согласна, но не понимаю, где вы в моем посте вообще углядели мысль о том, что ТЗ - это панацея?
И таки да, для начинающих тестировщиков именно первые 4 пункта определения Рона Патторна являются самыми главными, не вижу в этом ничего плохого. Или быть джуниором тоже постыдно? Надо сразу все уметь?
Насчет цитаты Julian Harthy - ну так тут чистое имхо "большую часть кода, которую я видела, надо тестировать".
Не все команды могут писать сразу и хорошо)
Я не писал что нормальных ТЗ не бывает. Бывают. Более того - ТЗ (особенно то, что регламентируется в различных стандартах) это не единственно верный способ фиксировать требования.
УдалитьТесты могут быть документацией. Документацию можно автоматически генерировать из кода. Часть гугловских проектов так и живет. Да, там есть документация, но она не первична, а скорее побочный продукт. Можно порыться у тех же 37signals - там вроде даже примеры публичные есть.
И мне не нравятся примеры "волшебной целительной силы ТЗ" вроде сломанного телефона и человеческого фактора. ТЗ их не лечит, а в ряде случаев еще и может усугубить. Тут, собственно, я и предположил что вы пытаетесь придать ТЗ лечебные свойства которыми оно на самом деле не обладает.
Ну и главный побочный эффект подхода Паттона в том, что такие люди, как правило, потом не умеют работать вне рамок документации или просто без документации. Это плохо. Еще плохо считать что у любой задачи есть единственно верное решение. А джуниором быть нормально, только я не вижу причем тут джуниоры к Паттону.
И да, Harthy не о том, что тестировать не надо, а о том, что делать это надо хорошо и правильно, а не "как все". Это сложно, особенно когда вокруг сотни втюхивателей "серебряных пуль", но вполне реализуемо.
"Тесты могут быть документацией. Документацию можно автоматически генерировать из кода. Часть гугловских проектов так и живет." - а если бы и тестов не было?
УдалитьТо что тогда? Как узнать, кто прав, кто виноват?
Документацию генерить из кода - это все равно что просить программиста проверить свой код самостоятельно.
Нет, я не спорю! Половина людей с этим справится. Но никто не отменял и замыленность взгляда "в моем коде багов нет!" Сам написал, проверил так, как сам написал... А не так, как задумывалось.
"Я и предположил что вы пытаетесь придать ТЗ лечебные свойства которыми оно на самом деле не обладает" - а почему вы так предположили? Основываясь на своем опыте и опыте знакомых? А я тогда могу по своему опыту сказать, что ТЗ действительно может обладать той самой лечебной силой.
Понятно, что это не панацея и ВЕЗДЕ работать не будет. Но работает. Во многих местах работает. И кстати, Заказчика такой подход тоже устраивает, как ни странно - видеть то, о чем договарились.
Просто не надо обобщать. Да, люди могут жить без документации и не жаловаться. Да, люди могут жить без документации и ОЧЕНЬ сильно жаловаться. Да все может быть, зависит от команды, от людей...
Джуниоры к Паттону при том, что его книга написана "с нуля", и ее очень неплохо было бы джуниору прочитать перед тем, как пытаться устроить monkey-testing. Почему бы и не начать с выверки ТЗ? А потом уже шаги влево-вправо делать?
А в больших командах, опять же, новичков довольно много и им нужна документация. Неважно, в виде ТЗ или тест-плана. Но что-то им надо. Если они новички на проекте (бывает и такое, что людей бросают между проектами, что невозможно, если все знания сидят лишь в умах...)
Комментариев хватило бы на несколько новых статей. Наверное так и стоит сделать.
ОтветитьУдалитьА Паттон не прав. Например ТЗ не включает в себя законодательство, но как то так молчаливо подразумевается, что программа закон нарушать не должна.
Атрибуты "Сопровождаемости" (пятая группа по 9126) как правило в ТЗ не описывают, а эта штука хоть и не имеет отношения к пятому пункту Паттона но бьет очень, очень больно. И одна единственная ошибка оттуда может вам стоить всего проекта. Хотя софт будет и удобен в использовании и ТЗ соответствовать.
Паттон не прав.
Рискну экстраполировать более раннее утверждение автора и предположить, что для коротких проектов "поматросил и бросил" атрибуты "Сопровождаемости" значения не имеют. Репутационные издержки? Нет, не слышал. Ведь даже джуниорам надо что-то делать, особенно если вся контора из них.
Удалить"Ведь даже джуниорам надо что-то делать, особенно если вся контора из них" - можете ехидничать сколько влезет.
УдалитьИ все-таки в большинстве контор ТЗ очень важно для процесса. Но, разумеется, это только для команд, полных джуниоров и в проектах "поматросил и бросил".
Разумеется, вы не встречались с фрилансерами, у которых по 5 проектов на 5-6 месяцев, которые они сделали и взяли новые 5, соответственно, времени шибко интересоваться судьбой старых у них нет. Но это, разумеется, просто какие-то отбросы общества, которые не любят свои проекты.
Сергей, который Мартыненко - напишите новых статей, я только за :)
В курсе BBST приведено другое определение: "Anything that causes an unnecessary or unreasonable reduction of the quality of a software product."
ОтветитьУдалитьИспользование спецификации, всего лишь одна из возможных стратегий тестрования.
Да, одна из.
УдалитьСогласна
Третий абзац снизу. "В пятом пункте говориться о том" - в слове говорится мягкий знак не нужен.
ОтветитьУдалитьСпасибо, поправила!
Удалить