Забавная история.
Найдено тут.
Бывает, что одной команде хочется проиграть, а другой всё равно. А вот так, чтоб проиграть хотелось обеим командам - это редкость. Но и такое случается. О самом увлекательном футбольном поединке из этой серии я сейчас расскажу.
История эта произошла в 1994 году. Страны Карибского региона проводили международный футбольный турнир, который называется Кубок Карибского Моря (Shell Caribbean Cup). В одной отборочной группе собрались сборные Барбадоса, Гренады и Пуэрто Рико. По регламенту только одна команда выходила из группы в следующий раунд финальной фазы. Команда Гренады в первом туре победила Пуэрто Рико со счетом 2:0, в то время как Барбадос свою встречу пуэрториканцам проиграл с минимальным счетом 0:1.
Гренада шла на первом месте, и ей нужно было не проиграть Барбадосу (или хотя бы не больше, чем в два мяча).
Для того, чтобы первое место досталось в итоге Барбадосу, а не Гренаде, ему нужно было побеждать в очной встрече сборную Гренады с разницей в 2 мяча. Один мяч уже ничем не помогал.
Все бы ничего, если бы не страннейшее правило турнира: золотой гол в добавленное время приравнивался двум голам.
Забив быстрые два гола, Барбадос повел в матче со счетом 2:0. Этот счет, устраивающий барбадосцев, держался вплоть до 83-й минуты. Однако, к великому сожалению барбадосцев, они сами же себе случайно забили автогол и свели свои усилия насмарку. Счет на табло стал 2:1.
Матч (точнее, его оставшиеся семь минут) стремительно близился к завершению. Гренада стала плотно обороняться, поскольку очень боялась счета 3:1. Забивать голы сопернику всегда тяжелее, чем себе. Видя это, игрок сборной Барбадоса (как мы помним, этой сборной нужно победить с разницей именно в два мяча) защитник Сиели, не будь дураком, взял да и умышленно забил гол в свои ворота. Ведь он изменил счет на 2:2 и мог вот-вот перевести игру в овертайм (целых 30 минут), в течение которого Барбадосу можно было забить один "золотой гол" и выиграть у гренадцев как раз 4:2 (а не 3-2) и стать лидером группы.
Игроки сборной Гренады и все зрители от этих событий, мягко говоря, обалдели. Всё сошло с ума: сборной Гренады нужно было собраться и забить один мяч (они не хотели рисковать в овертайме). Разницы, в какие ворота им бить, не было никакой. Проиграй Гренада 3:2 - вышла бы дальше. Выиграй Гренада 3:2 - тоже вышла бы дальше.
Естественно, Гренада всем скопом радостно кинулась атаковать свои же ворота. Барбадосцы бросились к воротам соперника и …начали защищать владения Гренады от её же автогола. Позади вратаря гренадцев встал защитник Барбадоса Сиели (тот самый) – он должен был отбивать мячи Гренады . Тогда Гренада побежала забивать гол Барбадосу , и барбадосцы кинулись защищать уже свои владения.
На поле и на трибунах царил такой дурдом! В последние две минуты основного времени и четыре минуты добавленного гренадцы старались забить гол – без разбору - в любые ворота, а барбадосцы обороняли от губительного для них гола ВСЕ ворота на поле. Барбадос выстоял. Гренаде не удалось забить ни гол, ни автогол - 2:2.
В добавленное время гениальный план Барбадоса сработал. Игрок Барбадоса Торн забил «золотой гол», который автоматически прекратил игру и сделал счет 4:2 в пользу Барбадоса .
Слово Канеру
Не используйте стандарт IEEE 829 Каждый из нас был в восторге от стандарта IEEE 829, когда в первый раз читал его. Однако, мы обнаружили ряд проблем на практике. Иногда во время обсуждения этих проблем, мы говорили, что они возникают из-за неправильного использования стандарта. В конце концов, он очень гибок. Тестировщики не должны использовать стандарт неправильно.
Это похоже на аргумент «Не оружие убивает людей, а люди». Иногда это верно, но иногда и нет.
Что касается IEEE 829 мы видели проблемы достаточное количество раз, у людей, которых мы уважаем, в компаниях, которые использовали шаблоны основанные на 829 в нескольких проектах, так что мы считаем, что эти проблемы отражают слабость стандарта и не могут быть отклонены со ссылкой на некомпетентность людей, этот стандарт использующих.
Аргумент «оружие не убивает людей» читается в этом случае иначе: если бы спусковой крючок пистолета был бы ворсинкой и это небезопасное оружие оставляли бы в общественных местах, заявляя «используйте это оружие во всех проектах».
Вот некоторые из вопросов, возникающих при использовании стандарта на практике:
- Предполагается, что лежащий в основе стандарта подход близок к водопаду, то есть в нем тесты разрабатываются заранее, тщательно документируются, а затем не меняются. Цена изменения (стоимость обслуживания документации) оказывает негативный эффект на саму возможность изменения. На наш взгляд, нужно создавать все более сложные и глубокие тесты по мере того, как программа становится все более стабильной. По мере роста расходов на документирование тестов мы предлагаем переиспользовать и изменять старые тесты вместо разработки новых, более сложных, и придерживаться улучшения текущей стратегии тестирования до того, как вы узнаете, что документация тестирования стала частью проблемы, а не частью процесса.
- Массивная документация создает определенный менталитет — делать то, что предписывает план. Это в корне отличается от менталитета настороженного, критического тестировщика, обращающего внимание на любые детали и следящего за перспективными возможностями.
- Стандарт не обеспечивает структуры для анализа требований к документации тестирования. Он не предоставляет никаких рекомендаций или руководств относительно того, когда нужен определенный тип документации.
- Не раскрывается и не обсуждается огромная стоимость предоставления всех типов этой информации. Время, затраченное на документирование может стать временем, потраченным на тестирование.
- Стандартом подчеркивается обширность документации. Чем больше, тем лучше. Кажется, что это хорошо — создать план тестирования, спецификацию архитектуры тестов, спецификацию процедуры тестирования, спецификацию тестовых сценариев и. т.п..
- Нет критериев для принятия решения о том является ли документация в конкретном случае хорошей или плохой. На практике объем, как правило, заменяет ясность и охват. Мы просмотрели огромный объем документации, которую авторы считали полной, только для того, чтоб обнаружить зияющие дыры — ключевые стратегии или риски полностью отсутствовали. Очень легко — не заметить несколько очевидных тестов, когда документация занимает тысячи страниц.
- Расходы на обслуживание документов огромны. Когда ПО меняется, вы не просто должны изменить часть документации, связанные с определенным аспектом программы. Вы должны найти все остальное, чтоб выяснить, что именно должно измениться. Это усилия по поиску и изменению неактуальных файлов. Если документация не соответствует коду 1 к 1, то это принесет массу затрат времени позже.
- Документирование каждого теста серьезно мешает автоматизации тестирования. Если документирование теста занимает 1 час (это заниженная оценка) и вы хотите 10 000 тестов в вашем проекте (это, безусловно, не завышенная оценка числа тестов) то придется потратить 10 000 тестер-часов на документирование. Также вы оплатите стоимость работы по приведению в соответствие тестов и документации. Когда тесты изменятся, например из за особенностей обслуживания тестируемого ПО, то придется менять и документацию, это приведет к затратам еще большего количества тестер-часов. Это огромный налог на автоматизацию. Компании, которые его платят могут отказаться от написания большого количества тестов вместо того, чтоб отказаться от затрат, связанных с их документированием. По нашему опыту, компании чаще всего просто отказываются от любой документации, в конечном итоге бесполезными становятся любые документы, созданные до этого (так как они становятся неактуальными).
- Парадигма автоматизированного тестирования, включающая миллионы тестов, сгенерированных или использующих случайные данные или последовательности, кажется совершенно чуждой данному стандарту. We can imagine shoe-horning the software documentation and the associated software models into the Standard's categories, but we don't see that done in practice. Instead, we see that these efforts (models, code, oracles, and so on) are documented elsewhere or not at all.
- Мы уже упоминали наш опыт судебных процессов. Закончив этот перечень, упомянув другой опыт. Некоторые компании начинают с соглашения о том, что процесс тестирования будет задокументирован в определенной степени, что стандарт 829 будет исполняться, что стратегия тестирования будет то-то и то-то. Затем они проходят часть пути проекта и отказываются от своего заявления в пользу того, как они видят положение сейчас, ради выполнения реальных задач по реальному графику. Они могли бы сразу принять правильное решение, но думали о том, как это будет выглядеть в суде. Они начали с тщательного планирования и следования стандартам индустрии, не выдержали их и выпустили дефектный продукт. Это выглядит очень плохо. Если вы не собираетесь следовать амбициозным планам и у вашей компании есть риск судебного преследования, не начинайте проект с заявления, что вы собираетесь следовать этому плану. Чрезмерно амбициозный план может принести больше вреда, чем пользы.
Перечислив все эти затраты, вернемся к вопросу бонусов. If we spend all this money, add all this inertia to our projects, and encourage our staff to run their brains at a lower setting when they do (as opposed to write about) testing, what do we get back in return?
Многие компании исползуют существенно меньше бумаги. Они отслеживают статус продукта с помощью набора коротких таблиц, отчетов о состоянии, а также регулярных встреч команды. Они отслеживают проблемы с помощью хорошо написанных багрепортов, хранящихся в хорошем багтрекере. Какие преимущества получат эти компании от стандарта 829? А какие выгоды будут решающими в ваших обстоятельствах?
Во многих случаях, преимущества не станут решающими. В таких случаях, с учетом дополнительных затрат и рисков, связанных с разработкой и хранением больших объемов документации, мы считаем, что создание документов по стандарту 8219 было бы безответственным шагом.
