Лекция часть вторая

Внимание! Автор текста - не я. Это пересказ своими словами\пародия на то, что я слышал и читал. Надеюсь, никого не обидел.

По мотивам лекции, прочитанной ведущим программистом отделу SD в четверг, 4 июня 2009 года. А также по мотивам обзорной лекции, прочитанной Бригом в неизвестном здании Новосибирска(Хроники тестировщика). Я практически ничего не добавил от себя, а лишь смержил две отличнейших лекции.
Слушайте и не говорите, что вы не слышали.

Часть первая

Часть вторая.
А теперь давайте выпьем и пойдем дальше.
Этапы разработки, применимые к простым смертным, а значит и к нам:

1. Создание постановки (ТЗ, ЧТЗ, требования)
2. Создание задач на выполнение требований
3. Реализация требований
4. Тестирование разработчиком
5. Выпуск версии
6. Тестирование внутреннего стенда
7. Тестирование тестового стенда клиента
8. Обработка запросов техподдержкой

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

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

Увеличение на этапе четыре обусловлено несколькими факторами и на них стоит остановиться подробней. Программист – творец, и после акта творения ему хочется закурить… О чем это я? Ах, да. У нег есть желание создавать дальше не оглядываясь назад. Однако, зная, что они творцы, многие программисты забывают, что они в то же самое время обычные, блядь, шестеренки большого механизма и вообще пролетариат. И вся махина трудового законодательства говорит им – возьми и проверь. Большинство не проверяют. Я проверяю, но таких мало и они выше оплачиваются. Отсюда увеличение цены на этапе четыре.

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

Цена исправления ошибки, обнаруженной на этапе тестирования – выше чем стоимость исправления на всех предыдущих этапах, может даже вместе взятых , но тестирование – наше все. О нем подробней я еще расскажу, сейчас только назову причину жизненной необходимости этого этапа. Недешевый этап 6 и 7 необходим потому, что мы с вами существуем в огромном мире. И хотим кушать. Хлеб. Желательно с маслом и колбасой. И чтоб рядом стояла вазочка с икрой. Но, так как мир огромен, а вазочек не так много – есть еще куча пидорасов, жадно смотрящих на уже практически нашу икру. И они не жалеют денег на тестирование.

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

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

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


Нарисовав еще один график, и посмотрев на них в перспективе, что мы видим? Что пахать, как всегда, придется программистам, а тестировщики во всем опять окажутся виноватыми.

Чтоб сделать выводы и продолжить дальше, надо кое-что понять и почувствовать.
Вот аналитики смотрят, какая система SD лучше? Наша или конкурентов? Положа вот этот бутерброд на сердце скажу – моя. То есть мной написанная. В смысле - пальцами правленая и хуйней по этой причине не страдающая. И мне лично по барабану, какая версия мне попалась в руки. Одним словом - не система плоха. По большому счету, система отстойной в хлам не бывает никогда, ибо не идиоты ее писали. Тестировщики и SD меня поддержат: сколько раз приходилось ебать черную кошку в черной комнате, не смотря на то, что ее там не было? Когда это сделаешь раз 50, начинаешь чувствовать, что хотел сказать программер между пивом и сигаретой. Не понимать, а именно чувствовать. Цифра-то она цифра. Но жар, блядь, холодных числ, и дар, блядь, божественных видений никто не отменял. Во всем есть красота. И в этом гнусном ящике тоже. И вот когда ты почувствуешь внутреннюю логику, то она становится близкой и предсказуемой. Вот взять, например, женщину... Хорошая погода, не правда ли? Мимо. Били ли вас, мадемуазель, когда-нибудь по бикини веслом? Что-то тоже не катит. Читали ли вы, мадам, Шопенгауэра? Схлопотал по ебалу, даже не договорив фамилию. Девушка! Хотите кофе в постель? И дрогнуло что-то внутри нее. Нда... Потому что про погоду она слышала раз двести, а про кофе никогда. О чем это я? Ах, да. Так вот, стань ближе к системе. И она станет ближе к тебе. В мануалах есть все - как она устроена, как она ломается, и как ее лечить. Там не сказано только об одном - как ее любить. Ну, не приходило никому в голову. Мне пришло. Дарю вам эту идею безвозмездно.

Конец второй части.
Здесь были рассмотрены вопросы цены исправления и обнаружения ошибок, а также предложен метод повышения эффективности работы с сисстемой.
В следующих частях я планирую пересказать идеи борьбы с мифами и вопросы покрытия тестированием.