То свистит.

То не свистит.

Но когда свистит — то прям ващще…

Начал искать первопричину этого автогреха. Пару дней отсиживал в засаде (за рулём), то разгоняя машину, то адски тормозя, то петляя по улицам киевского стольного града.

И таки нашёл! 🙂

Понёс механику баг-репорт:

Уважаемые учёные по машинам,

мною, жителем киевских окраин, неоднократно замечено, что когда я еду на работу — с востока на запад — то под капотом не свистит.

А когда я еду домой — с запада на восток — то почти постоянно что-то где-то под капотом свистит.

Карта обоих маршрутов прилагается.

Прошу починить.

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

Вот, обнаружен баг.

Вот при каких условиях он воспроизводится, скриншот прилагается.

Следственные мероприятия и полевые испытания привели меня к однозначному выводу: свистит только тогда, когда еду домой с работы, направляясь с запада на восток.

Плиз, фикс.

Механик послушал аудиозапись свиста, станцевал перед машиной ламбаду, и подтвердил мои выводы: таки да, свистело только при езде с запада на восток, и вы не сумашедший.

Но дурак.

Бо свистело не потому, что «Oh, East is East, and West is West, and never the twain shall meet» (© Rudyard Kipling, который про Маугли сочинил), а потому, что ослабло натяжение ремня генератора электрического тока, и ремень проскальзывал по направляющим ложбинкам.

Непонятно?

Каждый раз, когда я включал фары, повышалась нагрузка на генератор, и он начинал крутиться быстрее. Ремень из, мгм, полимеров… и когда его натяжение ослабло, он перестаёт плотно прилегать к железяке генератора. А железяка крутится на высокой скорости, и если ремень хоть немного «провисает», то появляется тот самый свист.

«Засвистело, и упало на столе».

А фары я включал только по вечерам, когда возвращался домой.

А домой я еду с запада на восток.

А если не знаешь, как всё устроено ИЗНУТРИ, и ведешь наблюдение только СНАРУЖИ, то как догадаться?!

Никак.

Ремень-то подтянули, делов-то, и вообще, я мог его сам починить.

А самооценку мне кто подтянет?…

Чего я об этом вспомнил: да попался мне на глаза один баг-репорт, и прям один в один… Там было исчерпывающе точное описание того, что тестировщик ВИДЕЛ, и полное игнорирование контекста, в котором случился баг, бо тестировщик о ряде положений даже не догадывался (ненуачо, тестирование же не такое сложное, как программирование, да?!).

Конечно, программист проклял этого создателя бага, бо «не воспроизводится же», а юнак твердит, что воспроизводится, и даже демонстрирует это на видеозаписи и брызжет отравленными слезами.

Таки контекст важнее всего.

Понимание принципов «почему и как оно вообще работает» важнее знания ряда ситуаций, которые могут произойти.

Программистов жалько… Себя — нет.

Под капот надо смотреть

Смотрю тест-кейс:

ForgEt password анфас.

= = = = = = START = = = = = = =

Precondition: (очевидно копипаст требований, но то норм)

1. User is not logged.
2. Log in form is displayed on the page and have following elements:
   • static text above the «Email Address» field;
   • required «Email Address» field (empty);
   • required «Password» field (empty);
   • checkbox «Remember Me»;
   • Login button;
   • Forgot Password? link. (но не норм то, что это просто перечисление того, что тестировщик должен будет увидеть на экране. Оно вроде бы важно, но на деле — мусор, бо к делу не относится.)
3. Available user account ‘test@gmail.com / 11111111‘

Steps:

1. Open ‘Forgot Your Password?‘ form сlicking on the [Forgot Your Password?] link — the Forgot Your Password? dialog box should be displayed.
2. Fill the Email Address field following data:
   • Email: test@gmail.com
3. Assure that: the mail with Password — ‘11111111‘ has been delivered to mentioned Email Addres

= = = = = = END = = = = = = =

Думаем: если в одной строке рассказывается про какое-то действие, которое НЕПРЕМЕННО должно сопровождаться указанием «проверить наличие того и сего» (еще раз — ЕСЛИ такое вообще нужно), тогда указание/перечень того, что должно быть проверено, следует указывать сразу под упомянутой строкой.

Как надо/можно делать:

Пример №1. Простое (но не самое адекватное) упрощение текста

Steps To Reproduce

1. Open storefront.
2. Click on Login link on the header of the page.
   • My Account login page is opened and loaded.
   • The Returning Customers box is displayed on the page.
3. Click on Forgot Your Password? link.
4. ‘Forgot Your Password?’ dialog box will be displayed.

Камменты:

1

The Returning Customers box is displayed on the page. — это вообще что за «Коробка возвращающегося клиента» и необходимость проверять ее наличие? Подразумевается наличие формы логина — какой же это бокс-то?

2

Кейс вообще рассказывает о ситуации «Юзер провтыкал свой пароль к аккаунту в нашем магазине, и вместо того, чтобы залогиниться, как просто и добрый самаритянин, он злобно растеряно негодующе запрашивает у системы запуск алгоритма восстановления пароля«.

В большинстве жизненных случаев в короткой и бурной жизни тестировщика нет смысла исчерпывающе точно указывать, куда и когда надо кликать, чтобы тупо залогиниться… Поэтому принципиально не следует перечислять пошагово страницы и линки, которые надо пройти… да и надо ли их проходить? Не факт, что юзер будет переходить на страницу логина именно через open storefront + Click on Login link on the header of the page. Почему бы нам просто не открывать эту страницу по url?

Путь «open storefront + Click on Login link on the header of the page» можно проверить в отдельном тест-кейсе. И особенно хорошо такой кейс положить в набор для smoke testing. А во всех остальных миллионах тестов, в которых подразумевается «надо залогиниться», к экрану с формой логина можно обращаться СРАЗУ по url, например.

Принцип Keep It Simple, Stupid (KISS) в действии.

Пол Стэнли одобряэ! I was made for testing you, bayba…

Пример №2. Упрощенное (и более адекватное) представление всей ситуации, которую надо создать и проверить

Steps To Reproduce

1. Open the Returning Customers Login page
2. Click on Forgot Your Password? link.
3. Check, that ‘Forgot Your Password?’ dialog box will be displayed.

Камменты:

Так проще, однозначнее, прозрачнее.

И Expected results присутствует в последней строчке, «и всё, и этого достаточно» ©.

Но так тоже туповато… Ведь ситуация «вызвать форму восстановления забытого пароля» — всего лишь шаг в сценарии восстановления пароля. Смысл тестировать отдельно вызов этой формы, а потом отдельно отмену вызова этой формы? Это избыточные, неадекватные проверки.

Надо не привязывать один кейс к одному требованию. Разумнее читать требования ВООБЩЕ, продумывать ситуации, которые описаны ВООБЩЕ, и тестировать их последовательно, но именно как цельные ситуации, а не отдельные сокращения отдельных мышц на отдельной взятой руке в отдельной взятом сферическом вакууме.

1. Open the Returning Customers Login page
2. Open ‘Forgot Your Password?’ form.
3. дальше что надо делать, исходя из требований? А дальше надо доводить ситуацию до логического финиша, вестимо!

Step ‘Open Login form’ was removed to the hell. Understood the reason?

— Ну это-то то понятно.

— Понятно-то понятно… Например, ты знаешь про самую крутую технику тест-дизайна — редбрик тестинг?

— Нет. Рассказывай.

— Был бы ты англоязычным человеком, ты уже спросил бы «Что за ерунда, бро, какое ещё красно-кирпичное тестирование?». А так… можно любой фуфломицин всучить под этим редбрик тестингом, и никто не будет сомневаться. Будут потом на конференциях доклады об этом делать.

— Ты сволочь.

— Да, но у нас это называется «тренер». Двигаемся дальше. Тест-дизайн — это не «наилучшие способы придумывания тест-кейсов». Это аналитическая работа с непредсказуемым результатом… А тест-кейсы появляются просто как следствие аналитики. Нет аналитики — нет тест-кейсов. Есть аналитика, но плохая — будут плохие тест-кейсы…

А загляните в череп опытного заказчика ПО — он требования прописывает сам. Всегда. Да, общепонятно, что через требования он хочет получить хотя бы именно, что было заказано, но засада не в том, что «без ТЗ результат ХЗ» (можно ваять ПО и без предварительного малевания ТЗ). Проблема в коммуникациях. Чем более опытным становится заказчик, тем сильнее он эту проблему осознает и начинает решать.

Дичайшее озарение (и проблема) когда-то постигает каждого заказчика ПО — проект делают не те люди, с которыми ты договаривался.

Вот ты менеджеру проекта всё детально объяснил, и про бизнес, и про важность, и про ограничения, и про челленджи, и вообще так душевно помитинговали, что проснулся на окраине города, в вышиванке и не один… А те, кто проект делают — тебя никогда не видели, проект вообще не понимают, и не знают, зачем нужно то и это, и действуют только в рамках ограниченных технологических и ментальных инструкций…

Я знал его, Горацио.

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

Как эту психологическую проблему решает каждый заказчик в отдельности — та еще шнобелевская диссертация…

Как-то в самой крутейшей в Кишиневе студии «Сделаем сайт-визитку для вашего бизнеса, ня!» появился действительно ОПЫТНЫЙ заказчик. Как зашла она в нашу контору, так попросила не чаю, а показать ей того человека, который будет делать ей будущий сайт. ОДНОГО человека, с которым «потом будем разговаривать».

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

Кто за всё отвечает? Директор фирмы? Да, но он ничего не программирует. Программист? Да, но без дизайна он ничего не обещает. Дизайнер? Да, но без внятного ТЗ он не понимает, чего от него хотят, и сам сайт он делать не будет, он только картинку нарисует. Руководитель разработки? Кагбэ, да, но он руками в проекте ничего делать и рисовать не будет, поэтому «делать будем все сразу»… Так с кем вы хотите поговорить?

А только директор фирмы говорил с клиентом, и только он вообще знал, насколько важно успеть (полностью закрыть проект) к назначенной дате. И только он знал, как много денег было заплачено за этот заказ. По сравнению с обычными проектами — очень много, бо сроки давят, и для клиента это действительно важно… И только он знал, какие счета его бухгалтерией еще не оплачены, и как важно их покрыть, чтобы фирму не закрыть, и только ему было очевидно, что от данного заказа отказываться нельзя.

А менеджер разработки, глянув на сроки и приблизительное ТЗ, сразу сказал, что «Вообще не надо за этот проект браться, идея сайта слишком невнятная, из сайта-визитки они потом начнут делать какую-то ”всеобщую базу данных о недвижимости по стране”, очень многое нужно обсудить и договориться, мы очевидно не успеем…» Но отказываться нельзя.

А дизайнер, глянув на сроки и приблизительное ТЗ, сразу сказал, что идея — ни к черту, и делать ничего не следует, бо идея сайта совершенно невнятная, и из сайта-визитки потом начнут делать неведому шнягу («Всеобщую базу данных о недвижимости по стране? На каком движке? Боже мой, какой бред…»), и мы явно не успеем… Но отказываться нельзя.

А программисты (оба), глянув на сроки и приблизительное ТЗ, сказали «Однозначно хз…». Бо дизайна нет, и какие ограничения по верстке? На каких мониторах, например? У нас в наличии только 1024х768. И в каких браузерах? И что за, прости господи, идея у сайта такая дебильная? Они что, потом начнут делать из него «всеобщую базу данных о недвижимости по стране»? Быгыгы… На каком движке? Быгыгы… Но отказываться нельзя.

Множество уровней принятия решений. Искажения информации — буквально на каждом уровне. Как это надо делать — у каждого своё мнение. Надо ли объяснять клиенту, что «Мы тут подумали, и считаем, что ваш проект…»?

Что в этой ситуации может делать клиент? Ничего. Ждать, когда ему «всё сделают».

Ну, глорие Замолксис! По-частям все продвигалось нормально. Дизайн — так себе, но аппрувед, демо — аппрувед, контент — предоставлен. По-итогу сайт получился весьма работоспособным «внутри», но каким-то невнятным «снаружи». А тестировать — как всегда, было некогда. И как всегда, в срок не успели. И понятное дело, что демо — это хорошо, но надо бы доделать.

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

И началось…

«Ну, объявление добавить в базу можно, а почему шрифт такой некрасивый? Вы что, не умеете сделать нормальный шрифт? А почему, когда мы смотрим наш сайт на мониторе в 22 дюйма, снизу выползает оранжевая полоса…» Боже, да где вы такой монитор нашли? «А у нас друг в Израиле, он посмотрел, и сказал, что дизайн вообще ни к черту…» В ТЗ было указано, что максимально разрешение экрана… «Зачем вы мне говорите про эти разрешения? Я же вас о другом спрашиваю!»

«А почему, когда вот здесь сделать клямц, то вот там делает пимпц?» Это такая технология, это интернет, он так работает. «Нет, нам не нравится, как работает интернет. Можно же сделать по-другому?! Почему бы вам не сделать по-другому?» Ну, в принципе можно, но это новый проект затевать надо, это к директору. «Нет-нет, никакого нового проекта, сделайте тут! Почему вы нас постоянно посылаете? Ну и что, что только к директору… Почему он не хочет возвращать нам деньги? Аллё, где ваш дурацкий менеджер по рекламе? Почему он никак не может сказать конкретно, когда вы доделаете наш сайт?»

Наконец, в офис пришел не заказчик, а настоящий ”product owner”, серьезный и злой дядька, который встал за спинами программистов, посмотрел в их мониторы, и начал сильно тыкать им в плечи, приказывая «Давай быстро сделай сайт нормально, нах! Ну!?»

Нет, это были не девяностые. Какие могли быть сайты в девяностых?

Итого: проект с радостью передали другой студии «Сделаем сайт-визитку для вашего бизнеса, ня!», и чем оно там закончилось…

Всё, что заказчик может сделать «на входе» — самостоятельно расписать ТЗ, бо работу будут делать вообще неведомые ему люди, с которыми всё не обсудить. Да и если со всем перезнакомиться — менеджеры разработки (и особенно рекламные менеджеры, которые проекты инициируют) весьма нередко меняются прям на ходу проекта… Всякое бывает. Пусть мы будем считать их неучами. Пусть делают строго по ТЗ.

Всё, что заказчик может сделать «в процессе» — регулярно запрашивать демо того, что уже сделано по требованиям. Именно по требованиям, бо нюансы и отклонения всегда бытуют, индустрия такова, и технологии таковы. И многие вещи становятся понятными только в процессе демонстрации, а не заранее.

Всё, что заказчик может сделать «по-итогу» — тестировать, тестировать, тестировать. Самостоятельно.

Задача тестировщика в начале проекта — понимать, что случится с психикой заказчика, когда упадет занавес. И начинать готовить финальное тестирование.

Собственно, для этого тестировщиков как можно раньше надо в проект привлекать — чтобы было время и возможность подготовиться к проведению тестирования, а не для того, чтобы «находить баги как можно раньше»… прекратите уже эту муть тиражировать. Нет клиенту никакого счастья от того, что мы баги находим «как можно раньше».

Без доступа к телу заказчика, конечно, натестируешь всякого… Например, программисты намутили возможность оплаты через очередной пэй-пал, и много всяких сложностей в процессе сего порешали, а тестировщики об этом вообще хз, и тестируют оформление «страницы товара», находя там баг на баге в верстке, и совсем чуть-чуть в функционале «Send to a friend»… Ну как тут не пожелать бить морды на комплексе?

Поэтому вторая задача тестировщика — поселиться в футболке программиста (Ближе к телу ©), и постоянно понимать, что в проекте становится важным, а что — вообще ерунда. Бо всё течёт, всё изменяется, и приоритеты тоже.

Третья задача тестировщика — взрослеть и перестать тупить над тест-кейсами. Бо успешность ПО не в строгом соответствии ТЗ.

PS Не будем ковырять разницу между «требованиями» и «ТЗ». Не в терминах собака зарыта.

В Confluence можно грамотно разметить оглавления в тексте, заголовками уровня 1-6.

Можно вставить автоматически собираемое «Содержание» всех заголовков на странице (макрос ‘Table of Contents’).

Можно вставлять в тело страницы другую страницу, целиком (макрос ‘Include Page’).

Даже можно сделать на странице, содержимое которой надо встроить, специальное выделение текста (макрос ‘Excerpt’), и вставлять ТОЛЬКО то содержимое, которое было помеченное таким хитрым образом (макрос ‘Excerpt Include’).

Можно вставлять ссылки на другие страницы внутри Confluence аж двумя способами: по-простому (по-дурацки) и грамотно.

Вставляем по-дурацки

1. Просто скопируй нужную ссылку из адресной строки, да вставь ее в нужное место на странице открытым текстом.

Буквально copy/paste ‘httр://confluence.test/display/~a.lupan/Action+Verbs+to+be+used+in+Goal+setting+process‘ в тело открытой на редактирование страницы.

Сработает сразу.

Но вероятно не будет работать в будущем, если в названии страницы изменится хотя бы один символ — ссылка просто «умрёт».

Например, если в названии только дружественные англо-символы (вроде «Action Verbs to be used in Goal setting process«), URL страницы будет выглядеть как ‘httр://confluence.test/display/~a.lupan/Action+Verbs+to+be+used+in+Goal+setting+process‘

Если изменить заголовок страницы на «Англ Action Verbs to be used in Goal setting process» (добавить неанглоалфавитный символ, или двоеточия, или что-то еще неординарное), URL страницы поменяется на что-то вроде ‘httр://confluence.test/pages/viewpage.action?pageId=54598262‘

Всё потому, что URL страниц в Confluence создается динамически, изменяясь «на лету» в зависимости от названия страницы.

А ссылки на страницы в Confluence существуют в системе как самостоятельные сущности (переменные). Поэтому привязываться надо не к ссылкам, а к сущностям, которые хранят в себе ссылки. Поэтому

Вставляем грамотно

1)

1. Вызвать макрос ‘Insert Link’ (элементарно вызывается по Ctrl+K).
2. В окне настроек выбрать Search > искать по названию страницы.

Будет мелкий неудобняк:

• надо начинать набирать название искомой страницы без ошибок хотя бы в первых словах.
• ой, если надо искать только что созданную страницу — она сперва должна проиндексироваться в системе, и процесс этот нам не подчиняется. Пока поиск не проиндексируется, будет казаться, что только что созданная страница тупо отсутствует…

Поэтому более точный и удобный способ: в окне настроек макроса ‘Insert Link’ открыть раздел ‘Recently viewed‘. Нужная страница там безусловно найдется, практически всегда окажется, что я её уже открывал. Клик по её ‘Title’, и всё готово.

Confluence Recently Viewed

Теперь название страницы, на которую поставлена ссылка, может изменяться как угодно, вплоть до появления ‘pageId=54598262‘ — ссылка всё равно сохраняется «живой и невредимой».

2)

Как быстро вставить ссылку, не подергивая свою мышь:

1. В открытой на редактирование странице нажать на клавиатуре клавишу ‘[‘ — появится окно ‘Link suggestions’, аналог ‘Recently viewed’.

Дальше понятно?

Ссылки на имена юзеров вызываются через ‘@‘.

Вставлять картинки: через ‘!‘.

Можно внутри страницы организовать огневые перекрестные внутренние ссылки, что дичайше котируется в больших документах вроде ‘QA Vocabulary’ (например, в нашем 226 терминов, ой-вэй).

Ссылки на разделы внутри страницы

делаются так:

1. Разметить текст как заголовок (в моем случае ‘Definitions of Selected Functional Verbs‘).
   

   Confluence Heading

2. Скопировать этот текст в буфер обмена as is. Со всеми его пробелами и запятыми, если есть.
3. Перейти в другое место страницы, где надо сделать ссылку на данный заголовок.
4. Вызвать макрос ‘Insert Link’ (элементарно вызывается по Ctrl+K).
5. В окне настроек выбрать Advanced.
6. В поле ‘Link’ своими руками вписать символ ‘#‘ и сразу текст (заголовок) из буфера обмена со всеми его пробелами, as is, буквально ‘#Definitions of Selected Functional Verbs‘
   

   Confluence Advanced Links

   // Внимание: The anchor name is case sensitive. You must use the same pattern of upper and lower case letters as you used when creating the Anchor.

   // После обработки текст превратится в #DefinitionsofSelectedFunctionalVerbs (ибо справка: The anchor name in the full URL is concatenated into a single word, with all spaces removed).

   // В поле ‘Link text’ автоматически будет вписан тот же текст. Его спокойно можно отредактировать, при этом содержимое поля ‘Link’ уже не изменится.

7. Insert.

Итоговая ссылка на заголовок ‘Definitions of Selected Functional Verbs‘ будет выглядеть так: httр://confluence.test/display/~a.lupan/Action+Verbs+to+be+used+in+Goal+setting+process#ActionVerbstobeusedinGoalsettingprocess-DefinitionsofSelectedFunctionalVerbs

Мелкий неудобняк: ничто не подсказывает, что надо вставить ‘#‘. GTFO, если не знаешь про этот хинт. Я про него знаю, и вроде не дурак, но иногда забываю вписать эту чертову решеточку…

Серьезный, раздражающий неудобняк: если заголовок раздела ‘Definitions of Selected Functional Verbs‘ когда-нибудь изменится хоть на одну букву, ссылка внешне останется активной, но превратится в ссылку, просто закрытую заглушкой ‘#’.

Ок, это был простейший сценарий, ссылки внутри страницы. Теперь дело посложнее:

Поставить ссылку на заголовок с другой страницы, которая находится в другом space

Учли, что прямой Copy/Paste возможен, но потенциально недолговечен, и надо действовать через макрос ‘Insert Link’ (элементарно вызывается по Ctrl+K).

И пусть там можно найти только общий Title нужной страницы, внутренние ссылки оттуда недоступны, однако действовать надо именно через макрос ‘Insert Link’ (элементарно вызывается по Ctrl+K). Если в будущем изменится название страницы, в которой находится заголовок, на который надо ссылаться, Confluence эту ссылку грамотно обновит. Confluence рулит!

Вот если внтури страницы изменится тот самый внутренний заголовок, на который сделана «ссылка внутри страницы», тогда уж увы.

И всё равно придется действовать через раздел Advanced, да еще и вручную вписывать название страницы.

А это уже раздражающий неудобняк.

Если страница с внутренней ссылкой, на которую надо сослаться, находится в том же space:

1. Вызвать макрос ‘Insert Link’ (элементарно вызывается по Ctrl+K) > Advanced
2. Вставить ссылку по шаблону ‘Page Name#MyHeading‘.
3. В моем случае это ‘Action Verbs to be used in Goal setting process#DefinitionsofSelectedFunctionalVerbs‘
4. Insert.

Если страница с внутренней ссылкой, на которую надо сослаться, находится в другом space:

1. Вызвать макрос ‘Insert Link’ (элементарно вызывается по Ctrl+K) > Advanced
2. Вставить ссылку по шаблону ‘spacekey:Page Name#MyHeading‘.
3. В моем случае это ‘~a.lupan:Action Verbs to be used in Goal setting process#DefinitionsofSelectedFunctionalVerbs‘
4. Insert.

Работает.

ВНЕЗАПНОСТИ

1)

Полностью URL на определенный заголовок внутри определенной страницы выглядит так: httр://confluence.test/display/~a.lupan/Action+Verbs+to+be+used+in+Goal+setting+process#ActionVerbstobeusedinGoalsettingprocess-DefinitionsofSelectedFunctionalVerbs

Что же это за #ActionVerbstobeusedinGoalsettingprocess-DefinitionsofSelectedFunctionalVerbs, если я вписывал только #DefinitionsofSelectedFunctionalVerbs? Что за Wtf?

Ответ такой: все в порядке.

The page name is repeated in the URL, after the # sign. The second occurrence of the page name is concatenated into a single word, with all spaces removed.

Но зачем?

Ок, учтем, что в виде ссылки надо использовать только то, что идет за решеткой, но только после дефиса.

Неочевиднейший подход. Пока это поймешь…

2)

Если продолжить редактировать страницу, отсылка продолжает оставаться рабочей.

Но если я решу отредактировать эту ссылку… в ней исчезает spacekey, и вместо

‘~a.lupan:Action Verbs to be used in Goal setting process#DefinitionsofSelectedFunctionalVerbs‘

там будет написано

‘Action Verbs to be used in Goal setting process#DefinitionsofSelectedFunctionalVerbs‘.

Всё, ссылка сдохла.

Не обратишь на это пристальное внимание — увы, блеать…

Confluence Space Key Disappear

3)

Confluence Help организован не по-взрослому.

Есть дефолт-справка по работе со ссылкам: https://confluence.atlassian.com/display/CONFEAP/Links

Но также зачем-то существуют отдельные страницы справка для разных версий Confluence. Например, справка для Confluenct версии 5.6 находится тут: https://confluence.atlassian.com/conf56/confluence-user-s-guide/creating-content/using-the-editor/working-with-links

Я работаю с Confluence 5.5.2, поэтому смотрю на https://confluence.atlassian.com/conf55/confluence-user-s-guide/creating-content/using-the-editor/working-with-links

Между всеми тремя версиями справки разницы НЕТ, количество слов в двух документах идентично. Wtf?

Confluence Help Links Word Count

В целом Confluence рулит неимоверно!

Просто надо немного оторвать ноги/руки тем, кто реализовал механизм работы с ссылками, и мир во всем моем мире наступит.

Сразу.

Всей подошвой.

Кагбэ, да, но тогда почему это называется «Регрессионное тестирование», а не «Перетестировывание всего заново»?

«Заново всё тестируем» — это не объяснение сути обсуждаемого феномена! Это лишь описание внешних признаков сего феномена. Так ребенок может объяснить, что такое автомобиль, не понимая, как и почему вот это вот всё работает. Вроде «Автомобиль — это когда папа за рулём, он едет на работу, а я в детский сад, и мне удобно в нём сидеть». Всё правильно же?!

Кроме термина регресс еще есть термин регрессия — сам по себе термин неоднозначный. Это бывает и в психологии, и в финансовой аналитике, и это разные феномены ВААПЩЕ.

Значитца, так. В википедии правильно указана суть термина «Регрессионное тестирование» (англ. regression testing, от лат. regressio — движение назад), но дальнейшее объяснение недостаточно адекватно. Дитячее оно.

Давайте объясняться по-взрослому.

Есть понятие Прогресс.

Есть же…

А есть понятие Регресс — обратная сторона прогресса.

Любая/каждая система по мере накопления функциональных возможностей развивается (прогрессирует). Это круто.

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

Любая ERP-система развивается по тому же принципу — все больше информации собирается и учитывается по каждому чиху. Отчёты все красочнее, объемнее, в запросах все больше ЕСЛИ и НО НЕ и КРОМЕ.

Однако увеличение функциональности незаметно приносит и увеличение взаимосвязей между функциями.

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

Это и есть регресс.

Чтобы убедиться в том, что в существующей системе не начинается регресс, полезно иногда проводить ее полное тестирование.

И уж тем более логично перетестировать всё, что можно, если в систему были внесены какие-то существенные изменения.

Со стороны это выглядит как «Внесли новый функционал — обязательно перетестировываем всё!» Словно тестировщики в тысячный раз прогоняют уже существующие тесты, вот и всё.

Не всё. Этого недостаточно.

Проблема регресса для тестировщиков намного серьезнее — мы каждый раз не знаем, что принесёт с собой новая функциональность в системе. И каждый раз надо предположить/узнать/протестировать новые взаимодействия в системе, а не тестировать только новые функции в изоляции от остальных.

Смысл просто гонять старые тест-кейсы, если они были написаны без учета новых ситуаций?

Со временем старый функционал начинает плотно пересекаться с новым — и надо заново расчехлять аналитику, заново выявлять новые ситуации, которые могут возникнуть, заново писать тест-кейсы, которые затрагивают уже не столько функциональные, сколько интеграционные аспекты…

А «в интеграции» бытуют такие баги, о которых и не догадаешься, рассматривая функцию логина по-отдельности от остальных функций…

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

В любом проекте с какого-то момента начинается уже не улучшение продукта, а борьба за «чтобы оно всё еще продолжало работать, как раньше«… с постоянным выяснением, а не наступил ли регресс из-за усложнения системы.

В начале проекта ВООБЩЕ нет необходимости думать про регрессионное тестирование. В начале проекта даже тест-кейсами особо заморачиваться нет смысла.

Но чем дальше влез в лес…

Ещё в тему

Regression is my profession!

Решение: создать новый стиль оформления страниц, и назначить этот стиль тем страницам, на которых не должно быть колонтитула.

Format > Styles and Formatting > select Page Styles icon at top:

Then:

1. Create a new page style based on the Default Style page style (right-click > New…).
2. Organiser tab > give this new style a meaningful name (e.g., «No header / footer») > set Next Style to «Default Style».
3. Header tab > uncheck Header on.
4. Footer tab > uncheck Footer on.
5. Click OK.
6. Place the cursor at the end of the content on the page prior to the page to have no header / footer.
7. Insert > Manual Break… > Type of «Page Break» > Style of «No header / footer» > click OK.
8. Press DEL (if required to remove carriage return or page break in front of cursor).
9. Repeat steps 6-8 for each page to have header / footer area suppressed.

For documents using direct formatting (e.g., Format > Page…) the same process should work, although to what degree, will depend on how the direct formatting has been applied and to what extent.

Осень.

Я, безработный, «словно птица на сносях», иду собеседоваться в большую компанию.

А там на входе две анкеты «на адекватность».

Дадада, давайт сюдайт, адекватность — это же моё второе имя!

Первая анкета скучна, как радио «Шансон» в киевском варианте. Сто насущнейших вопросов из области программирования.

Что такое ООП, а вот предположим, что мы намазываем на бутерброд наследуемый полиморфизм, а в чем же насущная суть абстрактной сущности, а вот найди неправильный тэг в предлагаемом html-коде, а что б ты сделал, если б ты увидел молдавских коммунистов в церкви (ничего, это же неправильные коммунисты, они делают неправильный мёд), а кто такой тов. Стучка (один из организаторов коммунистической партии в Латвии с 1919 г.), а где теперь живет Карл Маркс (в сердцах пролетариата), и прочее…

Я отвечал этой занудной анкете честно, обстоятельно и неторопливо, мол, не брал я на душу покойников, и не испытывал судьбу, и не знаю я никаких ваших ООП, а вот этот тэг на html надо безусловно закрывать вот здесь, а тут тоже не знаю, и это пропущу, и тут я хз, а тут я вообще хз, и я начальник, спал спокойненько, и весь ваш МУР видал в гробу…

Вторая анкета поживее — сто вопросов про тестирование ПО. Там я тоже отвечал честно, обстоятельно и неторопливо, но тут уже, в отличе от первой, незаполненным не оставил ни одно поле.

Итого странная ситуация: коньдидатЪ продемонстрировал исчезающе мало знаний в программировании, но ВНЕЗАПНО оказался невероятно хорош в тестировании, набрал ~90% правильных ответов, каг же таг?

Разбираться со феноменом явилось двое тест-манагеров. Мое сопротивление было смелым, как атака кавалерии Келлермана под Ватерлоо, но таким же ненужным. Не суть, конечно, дело прошлое, но по итогу беседы мне был нанесён самый мощный coup de grâce в моей тестировщицкой жизни, о котором не забывается. Речь пошла про тестирование проекта, который вот-вот надо сдавать.

А именно: «А вот у вас проект, который вот-вот надо сдавать. Что вы предложите делать тестировщикам: проверять по тест-кейсам, или в свободном режиме потыкать проект, может и найдутся какие-нибудь баги?«

Я крепко подумал.

И ты подумай.

Саспенс же, ёпта.

Если проект уже надо сдавать, это означает, что времени — с гулькин, мгм, нос.

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

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

Ок, считаем, что другого шанса «сдать адекватный проект» не будет.

Можно заняться аналитикой: ещё раз пройтись по проекту и выяснить, все ли возможные сценарии работы приложения были продуманы и протестированы? Наверняка же не все… Но заниматься аналитикой перед финалом работы по проекту вобще?…

А если проект уже «надо сдавать» — это означает, что времени на багфиксы не будет?! Если в свободном поиске тестировщик найдёт что-то СТРАШНОЕ, то его свои же манагеры закопают у озера на Скулянке, лишь бы не сообщать в последний момент о том, что выходить в прод опасно…

Что-то хорошее в этой ситуации тоже нашлось — если проект «уже надо сдавать», это значит, что до сих пор тестировщики что-то в этом проекте ковыряли, и вероятно, уже не первый день, и вероятно, уже знают его очень хорошо. Знают сильные места, знают слабые места, знают то, о чем никому не надо говорить, знают то, что хочется развидеть, но без армии психоаналитиков мистер Крюгер все равно будет каждую ночь посещать и несчастного тестировщика, и несчастного девелопера, который всё это надевелоперил…

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

Подскажу бесплатно: или найдутся какие-то безумно идиотские экзотические сценарии перехода с одного экрана на другой, или какие-то безумно идиотские экзотические сценарии выполнения каких-то расчетов, которые закрэшат софтину, и тогда манагеры поедут на Скулянку выкапывать из благословенного молдавского чернозема тестировщика, который хотя бы что-то да знает о том, где у этой софтины слабое место, в которое НЕ НАДО тыкать…

Нехорошее соображение: программисты не рекомендуют тестировщикам находить экзотические баги под самый финал проекта.

Некстати подумалось, что если рискнуть, то можно дальше не читать, просто знайте, что убийца — не садовник…

Поэтому вариант «А давайте в режиме свободного падения покопаемся в программе, может быть, и найдём что-то…» мне не нравится КОТЭГОРИЧЕСКИ. Многовато экзотики. Потенциально можно доказать, что программа обладает страшными недостатками, но можно ли доказать, что она делает то, что…

А, кстати, программа уже делает то, что должна делать, без ошибок? Нет информации. Предположим, что я заказчик, который не врубается в градации экзотичности багов, и хочет, соппсно, получить софт, который будет делать то, что ему нужно… И как водится, предположим, что тестировщиков в проект пригласили просто потому, что кто-то убедил заказчика в том, что тестировщики — прекрасные эмуляторы «конечного пользователя». Следовательно, самая важная информация, которая должна приходить от тестировщиков — будет ли удовлетворён конечный пользователь, а он будет удовлетворён в принципе потому, что программа будет делать то, что она должна делать…

Вернёмся к исходникам:

1. проект «вот-вот» надо сдавать,
2. дальнейшая работа над проектом не объявлена,
3. у тестировщиков есть ТОЛЬКО две возможности:
   1. или проверять проект по тест-кейсам,
   2. или «тыкать проект» в поисках ранее пропущенных багов.

Ваше решение, фельдмаршал?

Решение такое: проверять проект по тест-кейсам.

Если есть время, то следует методично и последовательно убедиться ЕЩЁ раз в том, что программа делает то, что она ДОЛЖНА делать.

Палюбасу эта информация важнее всего.

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

Я отказался.

Мне отказали.

Научим всякой туфте, вроде Smoke Testing, Regression Testing, Decision Table Testing, Pairwise Testing, даже State-Transition Testing, или даже, святая святых, не каждому дано — Domain Analysis Testing… Это интересно? Это поможет найти работу?

Начинающему достаточно только рассказать про Equivalence Class Testing + Boundary Value Testing, показать форму заполнения тест-кейсов и отчетах о дефектах, и пнуть под зад, бо всё, «You’re in da Army now, stand up and fight», дальше — сам.

Но если только это и рассказать, то он же, зараза, вернётся с претензиями, мол, чему вы меня научили, бо работу никак не найду, а следовательно, я — няша, вы — злобные мудаки.

Почему недостаточно только рассказывать про Equivalence Class Testing + Boundary Value Testing?

Ну, поначалу всё ок, пока дело не дойдёт до какой-нибудь сложной формы наподобие google.com/advanced_search, и тогда «Баста, карапузики, кончилися танцы!»…

И ладно, если на наших глазах облажается джуниор (мы же тут любому джуниору ногу отгрызём, буде таковой рыпнется, ага?!). У джуниора есть время на то, чтобы осознать ошибки молодости и переучиться, и доучиться, или жениться и перестать отличать тестирование от программирования, равно как и утро от вечера.

А если это взрослый человек?

А если взрослый, то надо формулировать задачу правильно. И грамотно оценивать возможности реализации.

Как вы яхту назовете, так она и поплывёт

Ведь можно было бы сформулировать тот же запрос более откровенно: «Чему нужно научиться, чтобы найти работу в тестировании и зарабатывать там много денег?» Ну, что мешает?

Мешает то, что отсюда ВНЕЗАПНО растут ножки у проблемки, которая для взрослых людей вообще может оказаться непереборимой. Чтобы начать в тестировании, надо учиться с нуля.

Надо стать джуниором.

Джуниор в любой отрасли == «На старте будет мало денег в принципе, но, вероятно, ПОТОМ денег будет много».

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

Снимать жилье на зарплату джуниора в Киеве априори невозможно.

Для того, чтобы «начать», действительно достаточно общих рекомендаций вроде «Савин + Канер». Как будет происходить развитие дальше — предсказать невозможно. Понятно, что кто-то останется на этом уровне, а кто-то начнет грызть сорцы и разбираться всё глубже и объемнее уже не только в тестировании, но и во всём остальном.

Капля никотина ковбоя не убивает. Не лошадь же…

Это как умение быть ковбоем и умение курить «Мальборо». Нет четкой взаимосвязи между этими явлениями, нет обязательного перехода от «я ковбой» к «я курю». Но со стороны может показаться, что если стал ковбоем, то и курить будешь непременно, хлебая кофе из жестяной кружки у первобытного костра.

Или наоборот, я уже курю «Мальборо», следовательно, я уже — почти ковбой. Где моя лошадка, где мои коровки, где моё лассо, где моя Горбатая гора?! Сплошные иллюзии.

Каждый человек (не я первый), который приходит в новую профессию в зрелом возрасте, тоже вынужден проходить этот этап «на старте мало денег». Перескочить этап «джуна» невозможно в принципе в любой профессии — от управления самолетами до продажи жареных семечек на автобусных остановках.

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

Особенно если семья не поддерживает.

Более-менее успешно (или быстро) пройти этап «джуна в тестировании» получается только у тех, для кого ковыряние в компьютерах было хобби на протяжении многих лет.

Бо важнее понимать окружение (environment), нежели запоминать вид и расположение иконок в приложениях, и только догадываться о том, как и почему оно работает.

Остальные «резко желающие стать тестировщиками/программистами/анархистами» напоминают стареющих портовых грузчиков, которые вдруг возжелали изменить профессию, «…шоб зарабатывать не хуже, чем Давид Ойстрах; ведь этот маланец, что жил на соседней с нами улице, с одного концерта зашибает больше, чем мы с одного месяца; так а мы чем хуже жидов-то, разумнее же всем стать на старости лет скрипачами, доходы опять же растут, мешки тягать не надоть…»

Неужели вы думаете, что пилить на скрипочке — это сложно? Семь нот. Четыре струны. Один смычок. Какие проблемы? Чо ты меня паришь своими тест-кейсами?! Почему так долго? Просто возьми и протестируй этот гребанный софт!!!

Консерватория никому не отказывает, но там все сперва ржут, а потом предлагают для начала поучиться пять-десять лет, без четкого обещания «станете мастером». Результаты понятны?

У меня этот переход был очень болезненным, но я к нему был готов. У кого-то это вообще не получается. И это нормально.

Например, приходит понимание того, что программировать/тестировать — это таки занятие для задротов, и не каждый из «обычных людей» с этим справляется. И даже нужда в деньгах для многих не является достаточным мотиватором, чтобы «это выдержать».

Вот и вся ситуация, если говорить грубо и без вежливых экивоков.

И вот что… Сегодня тестирование/программирование рулит, бо в кризисе айтишные конторы оказались на коне, всё такое.

Вспоминаем, как резко понадобились разномастные бухгалтера в девяностых, и где они сейчас.

Вы в курсе, что в семидесятых годах ХХ века в том же СССР было полно программистов? Кто тогда хотел ходить в очках, с бородой, в белом халате, в НИИ чего-то там?

Завтра тестирование перестанет рулить, завтра и кризис закончится. Все к этому готовы?

Сегодня тестировщики, скажем очень грубо, нужны потому, что программисты очень плохо программируют всё то, что будет работать «для обычных людей». Вот там, где «робот с роботом общается» — там да, ракеты летают, космос наш, всё ок. Когда всё шаблонизируется, когда программисты научатся работать с системами, которые не нужно «трогать руками внутри», тогда и тестировщики начнут отмирать.

Некоторые — от голода и упрямства.

И когда тестировщиков наконец-то станет МНОГО, и даже больше необходимого, их стоимость начнет падать просто потому, что их будет много, и уже будет не до жиру.

По-хорошему, каждому человеку, который не обладает психотипом «бизнесмен», надо работать над тем, чем он занимался бы и без зарплаты. Хобби — великое дело. Предрасположенность — это ценность.

Но вы не обращайте на всё это внимания. Вы велкам к нам. Мы научим, не сомневайтесь.

Ну, кое-что знаю…

Когда-то один сэр Тестировщик был очень юн и уверен в себе. За большие (для тогдашнего его) деньги он схантился в одну динамично загибающуюся кишиневскую компанию, которая хотела «изменить мир, а не просто продавать сладкую воду». О, да…

Всё же было не просто так. Умный и опытный сэр Тестировщик спросил на собеседовании:

— А svn у вас есть?

— Конечно! — ответили ему. — И ещё у нас есть корпоративы на природе!

— Тааак. А программисты у вас опытные?

— Конечно! И еще у нас есть премии за хорошую работу!

— А документацию вы где держите? Внутренняя вики есть?

— Конечно! И еще у нас полное оформление на работу!

В общем, был сэр сам себе дурак. Если выяснил, что svn в компании есть, то надо было также спросить «А им кто-то пользуется?» А он не спросил.

Опытные программисты там были, но он же не спросил, сколько именно. Позже оказалось, что опытных там было трое из двадцати двух. С тех пор термин «программист-студент» кому ок, а у кого от этого термина начинается сыпь, режутся клыки и шерсть на загривке топорщится.

И документацию на вики действительно держали. Точнее, документацию по этой самой вики. По проектам документация хранилась в svn, в виде doc файлов с постоянно обновляемыми планами проектов…

Что там творили (от слова «творчество») программисты-студенты… Ну, представьте себе комнату, в которой сидят вроде бы адекватные молодые люди. Каждый по-отдельности вроде бы умеет писать код. Каждый знает, что существуют все эти svn и вики, но лично ему они ещё ни разу не понадобились. Ну да, программисту-одиночке подобные инструменты действительно не нужны, они крайне необходимы только для совместной работы. Но теперь представьте, что все люди в этой большой комнате работают над одним и тем же проектом, но — каждый по-отдельности. И каждый обоснованно уверен в том, что лично ему все эти фигни вроде svn ему нафиг не упёрлись.

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

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

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

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

Сэр Тестировщик вдруг понял, почему главный программист (тот, который рефакторит код до трех ночи) больше не хочет быть ёб*** главным программистом.

Сэр Тестировщик начал звереть.

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

Первый же попавшийся программист на них посмотрел, и сказал «Да, не работает, но я не этот функционал делал, я делал вон тот функционал…»

Ок, ответствует ему сэр Тестировщик, в твоем секторе, хм, тоже много красного. Впрочем, я туда ещё не добрался толком…

«Э, ты не то тестируешь! Ты найди мне все места, где вместо рендеринга страницы выпадает только белая страница, где скрипт не генерит контент!» — заявляет этот штырь.

Взял себя сэр Тестировщик в руки, но вскоре эти руки достаточно быстро опустились к плинтусу. Основной массив ёб*** багов состоял из настолько мелких проблем, что их и функциональными не назовешь, а посему «незачем было такой баг искать».

Например, один из программистов постоянно закрывал кнопку ‘Register’ заглушкой ‘#’, и забывал к вечеру перед сдачей проекта эту заглушку снять. А чего там проверять регистрацию, ей-богу. Её уже когда-то проверяли.

Другой постоянно оставлял на экране в неожиданных местах строки типа ‘hzhzhzhzh’ – ну просто для того, чтобы ориентироваться, в каком месте должна выводиться информация, которую подкачивал его скрипт.

Тест-кейсы в этой кутерьме совершенно не требовались.

В общем, руки у сэра были, но очередной кино-кадр эти руки к плинтусу прибил. Тестирует сэр Тестировщик очередной проект, разумеется, поднятый на машинке программиста на Tomcat-сервачке. И что-то там нашлось, мелкое, стилистическое. А программист-демон этот баг взял и моментально исправил. А сэр Тестировщик ж не знал! У него ж ВНЕЗАПНО все страницы проекта лишаются ёб*** стилистического оформления! Поскакал сэр Тестировщик к этому волшебному кадру, и начали они три дня и три ночи общаться друг с другом на грамотном румынском языке с применением русской блатной фени:

— Достопочтенный сэр Пеньтьюм, можете ли вы объяснить, в чём проблема?

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

— Но позвольте, уважаемый сэр, в текущем состоянии продолжать тестировать проект не представляется возможным. Не соизволите ли вы откатить изменения к предыдущему состоянию?

— Ой, а я ж не знаю, как это сделать, я же уже не помню, какие изменения я сделал.

— А svn на что нам был даден небесным подарком свыше?

— А кто этот джентльмен, Эсвээн? Я его не знаю.

— Что ж, достопочтенный сэр Пеньтьюм, имейте хороший день!

Совершенно рассвирепев, сэр Тестировщик переключился на другой проект, и за один час нашел там 22 крупных багов. Из них восемь вообще уж гугенотско-критикальных. Снова оседлал он своего Росинанте, и поскакал к менеджеру этого проекта, и сообщает, мол, девушка, на твоём проекте баги же, баги! Ёб*** б*** с*** баги!

— Ах, да… — ответствует заколдованная принцесса, — Программисты с этого проекта говорили мне, что знают о восьмидесяти багах на этом проекте, и что они должны исчезнуть, когда они перепишут код на язык Java.

— А до этого они на каком языке писали?

— Кажется, на C++, я точно не знаю. Они сейчас учат Java, и заново переписывают проект по-новому. В третий раз.

Йоговское состояние «ahooy» вам знакомо? Сэр Тестировщик познал его сполна…

Полностью несгибаемый тестировщицкий дух был сломлен на той же неделе, когда сэр Тестировщик открыл в браузере очередной проект портала по продаже картинок через мобильные телефоны, поднятый на всё том же Tomcat-сервачке. А картинки эти оказались порно-картинками. Ну, что ж… Но понад всеми этими порно-картинками красными буквами совершенно вне дизайна было крупно написано «Liudochka, eu te iubesc!» («Людочка, я тебя люблю!»).

Сделал сэр Тестировщик скриншот этого признания, и понёсся к менеджеру этого порно-картиночного проекта с тревожным донесением. Парень очень оживился:

— А, это нормально, это я написал привет моей новой девушке, я недавно влюбился, хочу жениться. Видишь, ее фотография первая в галерее… Сейчас я эту надпись сниму, не заводи это в Jira, это не баг…

Не стал сэр заводить это в Jira. Дело в том, что в тот же день семеро программистов с утра на работу не пришли, и вопросы о проекту, которым они заведовали, оставались нерешёнными. ВНЕЗАПНО они появились, все в костюмчиках с галстучками. Это было действительно эффектно, с ихними-то рожами…

— Вы где были?

— А, мы экзамен на бакалавра сдавали…

С какого-то времени в Молдове можно поступать в высшее учебное заведение только при наличии первой ученой степени — бакалавр. Экзамен на эту степень принудительно держат все великовозрастные лицеисты. Но в те доистерические времена в вузы ещё принимали абитуриентов без «бака», однако в течение первого года обучения такие студенты были обязаны отдельно подготовиться и все-таки сдать экзамен на бакалавра, чем наши программисты в тот день и занялись. Атестат зрелости, значит, получили. Мужики, значит, восемнадцатилетние. Они изменят мир.

Вскоре на дежурный вопрос «Как дела у нас в отделе тестирования?» сэр Тестировщик искренне ответил «Очень плохи дела», и был он полностью прав, бо там всё было плохо.

Сэра Тестировщика назвали мудаком, который берет много денег, а тестирует очень медленно и плохо, много требует от окружающих, и вообще хмурый и неприветливый, а ведь его «брали с надеждой» на то, что он наведет порядок в области тестирования, а он со всеми этими утверждениями быстро и полностью согласился, лишь бы поскорее завершился пред-увольненьческий дежурный разговор.

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

А что ты знаешь про лютые фэйлы, а, ${username}?