James Bach’s Blog - Justifying Real Acceptance Testing
Перевод статьи Баха
http://www.satisfice.com/blog/archives/973
Justifying Real Acceptance Testing
В защиту настоящего приемочного тестирования
Этот пост не том виде тестирования, о котором люди говорят, когда близится релиз и принимается решение о выпуске. Для этого у меня есть другое слово. Я называю это "тестирование" или что-то вроде финального тестирования или тестирования релиза. Во многих проектах такое тестирования проводится настолько поверхностным образом, что лучше описать его как проверку, в соответствии с отличиями проверок от тестирования, о которых я уже писал в этом блоге. как отмечает Майкл болтон, такие проверки можно лучше описать, как проверки на отказ, так как "fail" дает основания заявить, что продукт не будет готов, пока некоторое количество "passes" не покажет, что он готов.
Приемочное тестирование может быть определено несколькими способами. Этот пост о том, что я считаю настоящим приемочным тестированием, которое я определяю как тестирование потенциальным акцептором (заказчиком), выполняемое с целью получения информации для принятия (приобретения, возможности полагаться) продукта.
Нужно ли нам приемочное тестирование?
До тех пор, пока бизнес принимает решение полагаться на какой-либо компонент или сервис, существует опасность, что продукт сломается и бизнес пострадает. Один из подходов к решению этой проблемы - стадное принятие решения: следуй за большей частью роя, выбирай популярный продукт, который рекламируется, о котором известно, что он делает то, что вам нужно и у тебя все, скорее всего, будет в порядке. Я поступил так со смартфоном, защищенным ноутбуков, файлообменным сервисом и так далее - и получил хорошие результаты, хотя иногда и был разочарован.
У меня небольшой бизнес. Я шустрый по сравнению с почти любой другой компанией в мире. Мое приемочное тестирование обычно принимает форму подписки на обслуживание продукта, который я приобретаю или загрузки "базовой" версии продукта. Я работаю с ними и наблюдаю за тем, как я себя чувствую. Таким образом, я научился любить Dropbox, несмотря на тревожную ситуацию в области безопасности (я не могу заблокировать мои Dropbox файлы) или на значительную вероятность того, что большие файлы будут повреждены (я не доверяю ему ничего больше половины гига).
Но что, если бы я консультировал большую компанию по услуге или продукту, который будет использоваться и на который будут полагаться сотни и тысячи сотрудников? Что делать, если продукт создан по специальному заказу только для них? В таком случае приемочное тестирование становится важным.
Гарантирует ли соглашение об уровне обслуживания (SLA) работоспособность продукта?
Есть несколько проблем связанных с возможностью полагаться на обещания вендоров. Во-первых, вендоры обычно не обещают полного удовлетворения. Уровень услуги в контракте очень узко и конкретно описан. Это значит, что все, о чем вы не подумали и не включили в контракт - не будет прикрыто. Тестирование - процесс, который помогает выявить часть сервиса, которая важна для нас.
Во-вторых, есть проблема со временем. К тому времени, когда вы обнаружите проблемы в продукте вендора, вы уже можете зависеть от него. Возможно, вы уже широко развернули продукт. Может быть, уже слишком поздно отступить и изменить решение. Может быть, ваша компания обговорила юридически такой вариант, но практически это неисполнимо. Если ваш вендор очень маленький, он не может позволить себе быстро исправить свой продукт. Если ваш поставщик очень большой, он может позволить себе еле переставлять ноги по пути к исправлению проблемы.
Приемочное тестирование заставляет вендора серьезней относиться к качеству
приемочное тестирование никогда не должно проводиться силами вендора. Однажды я был нанят вендором для пентеста их продукта, чтоб успокоить клиента. Но у вендора нет ни стимула помочь мне добиться успеха в моей, ни желания добросовестно сообщать о уязвимостях, которые я обнаружил. Было бы гораздо лучше, если бы клиент нанял меня.
Только у принимающей стороны есть стимул хорошо провести тестирование. В приемочном тестировании не должно быть жестко ограниченного запланированного набора специфических проверок, иначе поставщик будет уверен, что пройдет их. Тестирование должно быть непредсказуемым, чтоб у поставщика был стимул сделать продукт удовлетворяющим требования в общем. Оно должно быть адаптивным (исследовательским), таким, чтоб любое слабое место, что вы нашли, можно было исследовать и использовать.
Вендору нужны ваши деньги. Если ваша компания достаточно большая, а вендор голоден, он сдвинет горы, чтоб заставить продукт хорошо работать если знают, что вы обратите на это внимание. Приемочное тестирование, проведенное творчес кой и квалифицированной командой тестировщиков, держит поставщика на кончиках пальцев.
Если вы проведете тестирование до принятия решения о том, что вы принимаете продукт, у вас появится шанс избежать катастрофы - слишком поздно обнаружить, что продукт - лимон disaster of discovering too late that the product is a lemon, идиома такая, видимо).
Мой менеджмент не задумывается о вопросе приемо-сдаточных испытаний. Что мне делать?
1. Привести аргументы, изложенные выше.
2. Формально сообщить менеджменту об этом (в письменной форме)
Принимают решения в области рисков бизнеса - руководство. Они могут считать, что о риске не стоит беспокоиться. В этом случае вы должны ждать и наблюдать. Людей легче убедить яркими впечатлениями, а не абстрактными принципами.
1. Соберите конкретные примеры проблем, о которых говорите. Какие баги вы нашли в продуктах поставщиков?
2. Соберите новости и багрепорты о продуктах ваших (или других) вендоров, которые были наиболее разрушительными.
3. В случае, если вы собираетесь провести небольшое приемочное тестирование, запишите все, что вы найдете и будьте готовы напомнить руководству о этой истории.
http://www.satisfice.com/blog/archives/973
Justifying Real Acceptance Testing
В защиту настоящего приемочного тестирования
Этот пост не том виде тестирования, о котором люди говорят, когда близится релиз и принимается решение о выпуске. Для этого у меня есть другое слово. Я называю это "тестирование" или что-то вроде финального тестирования или тестирования релиза. Во многих проектах такое тестирования проводится настолько поверхностным образом, что лучше описать его как проверку, в соответствии с отличиями проверок от тестирования, о которых я уже писал в этом блоге. как отмечает Майкл болтон, такие проверки можно лучше описать, как проверки на отказ, так как "fail" дает основания заявить, что продукт не будет готов, пока некоторое количество "passes" не покажет, что он готов.
Приемочное тестирование может быть определено несколькими способами. Этот пост о том, что я считаю настоящим приемочным тестированием, которое я определяю как тестирование потенциальным акцептором (заказчиком), выполняемое с целью получения информации для принятия (приобретения, возможности полагаться) продукта.
Нужно ли нам приемочное тестирование?
До тех пор, пока бизнес принимает решение полагаться на какой-либо компонент или сервис, существует опасность, что продукт сломается и бизнес пострадает. Один из подходов к решению этой проблемы - стадное принятие решения: следуй за большей частью роя, выбирай популярный продукт, который рекламируется, о котором известно, что он делает то, что вам нужно и у тебя все, скорее всего, будет в порядке. Я поступил так со смартфоном, защищенным ноутбуков, файлообменным сервисом и так далее - и получил хорошие результаты, хотя иногда и был разочарован.
У меня небольшой бизнес. Я шустрый по сравнению с почти любой другой компанией в мире. Мое приемочное тестирование обычно принимает форму подписки на обслуживание продукта, который я приобретаю или загрузки "базовой" версии продукта. Я работаю с ними и наблюдаю за тем, как я себя чувствую. Таким образом, я научился любить Dropbox, несмотря на тревожную ситуацию в области безопасности (я не могу заблокировать мои Dropbox файлы) или на значительную вероятность того, что большие файлы будут повреждены (я не доверяю ему ничего больше половины гига).
Но что, если бы я консультировал большую компанию по услуге или продукту, который будет использоваться и на который будут полагаться сотни и тысячи сотрудников? Что делать, если продукт создан по специальному заказу только для них? В таком случае приемочное тестирование становится важным.
Гарантирует ли соглашение об уровне обслуживания (SLA) работоспособность продукта?
Есть несколько проблем связанных с возможностью полагаться на обещания вендоров. Во-первых, вендоры обычно не обещают полного удовлетворения. Уровень услуги в контракте очень узко и конкретно описан. Это значит, что все, о чем вы не подумали и не включили в контракт - не будет прикрыто. Тестирование - процесс, который помогает выявить часть сервиса, которая важна для нас.
Во-вторых, есть проблема со временем. К тому времени, когда вы обнаружите проблемы в продукте вендора, вы уже можете зависеть от него. Возможно, вы уже широко развернули продукт. Может быть, уже слишком поздно отступить и изменить решение. Может быть, ваша компания обговорила юридически такой вариант, но практически это неисполнимо. Если ваш вендор очень маленький, он не может позволить себе быстро исправить свой продукт. Если ваш поставщик очень большой, он может позволить себе еле переставлять ноги по пути к исправлению проблемы.
Приемочное тестирование заставляет вендора серьезней относиться к качеству
приемочное тестирование никогда не должно проводиться силами вендора. Однажды я был нанят вендором для пентеста их продукта, чтоб успокоить клиента. Но у вендора нет ни стимула помочь мне добиться успеха в моей, ни желания добросовестно сообщать о уязвимостях, которые я обнаружил. Было бы гораздо лучше, если бы клиент нанял меня.
Только у принимающей стороны есть стимул хорошо провести тестирование. В приемочном тестировании не должно быть жестко ограниченного запланированного набора специфических проверок, иначе поставщик будет уверен, что пройдет их. Тестирование должно быть непредсказуемым, чтоб у поставщика был стимул сделать продукт удовлетворяющим требования в общем. Оно должно быть адаптивным (исследовательским), таким, чтоб любое слабое место, что вы нашли, можно было исследовать и использовать.
Вендору нужны ваши деньги. Если ваша компания достаточно большая, а вендор голоден, он сдвинет горы, чтоб заставить продукт хорошо работать если знают, что вы обратите на это внимание. Приемочное тестирование, проведенное творчес кой и квалифицированной командой тестировщиков, держит поставщика на кончиках пальцев.
Если вы проведете тестирование до принятия решения о том, что вы принимаете продукт, у вас появится шанс избежать катастрофы - слишком поздно обнаружить, что продукт - лимон disaster of discovering too late that the product is a lemon, идиома такая, видимо).
Мой менеджмент не задумывается о вопросе приемо-сдаточных испытаний. Что мне делать?
1. Привести аргументы, изложенные выше.
2. Формально сообщить менеджменту об этом (в письменной форме)
Принимают решения в области рисков бизнеса - руководство. Они могут считать, что о риске не стоит беспокоиться. В этом случае вы должны ждать и наблюдать. Людей легче убедить яркими впечатлениями, а не абстрактными принципами.
1. Соберите конкретные примеры проблем, о которых говорите. Какие баги вы нашли в продуктах поставщиков?
2. Соберите новости и багрепорты о продуктах ваших (или других) вендоров, которые были наиболее разрушительными.
3. В случае, если вы собираетесь провести небольшое приемочное тестирование, запишите все, что вы найдете и будьте готовы напомнить руководству о этой истории.