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

о_О

В частности:

Проходили собеседование пару тестировщиков. Спрашиваю — что учили, что знаете про тестирование.

Ответ: «Я изучал тестирование полностью по блогу А. Лупана«

Гы 🙂

— А у Руколь, Баранцева бываете ? Читали? Курсы?

— А кто это?

— Э… Как же вы тогда изучали тестирование по блогу Алексея?

— А чо я, там всякие ФИО смотреть должен? Я ж тестирование изучал )

А потом сообщил, что ты ему подарил свою футболку в которой был на тренинге Баранцева. Я вот очень сомневаюсь что ты ее подарил ему 15 июля, а потом забрал, и пришел 23-го на тренинг 😀

При этом он сказал что футболка была на него коротка. А рост у него 1,73… Ну, явно твоя майка была б ему по колено, примерно )

Тут меня окончательно пробило на «бугугугугагага!». Ведь если соврал про футболку, следовательно, соврал и про то, что учился.

В общем, должность парню не предложили.

Дима, пожалуйста, пришли мне по почте (наложенным платежом) свои глаза.

Хочется в них посмотреть 🙂

И иди — учись.

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

Один из самых распространенных ответов таков:

«Тестирование повышает качество продукта».

Ну…

Вообще — нет, хотя… Да, с точки зрения рабоче-крестьянской логики, все именно так и происходит.

Я сам когда-то думал точно так же.

Я когда-то вообще думал только о том, как взять полууменьшенный минорный септаккорд от Ми, бо у Розенбаума оно получается, а у меня нет 🙂

Например, мое понимание смысела тестирования с годами ощутимо поменялось, и нынешнее свое понимание я совершенно не готов выбивать в мраморе на своем обелиске…

Однако попробуем уточнить, почему кандидат думает именно так (типичный диалог):

— А каким образом тестирование повышает качество?

— А таким, что если мы узнаем о багах, и асфиксим их (асфиксия — удушие, подразумевается планомерное удушение багов, гыгы), то качество продукта повышается.

— И в сравнении с чем оно повышается?

— Ну… В сравнении с тем, что было до тестирования, разумеется.

— Но ведь ожидалось, что продукт будет качественным, без багов. А тестирование показало, что продукт получился некачественным. Так в сравнении с чем качество смогло повысится после багфиксинга? Мне вот кажется, что после исправления дефектов продукт из некачественного просто стал качественным, а качество не повысилось, оно просто появилось.

— Ыыыыы… Ну так вот же — продукт стал качественным после исправления дефектов! И помогло в этом тестирование! Вот в этом и есть смысел тестирования — помогать делать продукт качественным!!! ©

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

Много народу в должности ПМ или вообще «клиент» убеждены в том, что

• если тестирование будет крутым,
• и если тестировщики будут крутыми,
• и если тестировщики будут «болеть за качество»,

то продукт будет отличным.

На самом деле, это вопрос и компетенция Product Manager.

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

После этого мы переходим к другим вопросам о тестировании. Например, к вопросам о том, как делают вино.

Есть в отрасли виноделия такие люди — виноградари. Они отвечают за условия, в которых виноград зреет.

Буквально — где когда и как сажать, как подвязывать, как чистить, как ухаживать…

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

Характеристик этих множество, самыми понятными считаются соотношение влаги, сахара и кислотности в ягоде.

Характеристики виноматериала зависят не только от сорта винограда и и положения звезд в созвездии Свисток рака. Они даже поддаются какому-то тюнингу.

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

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

Обычно же поражение Ботритисом такая же беда, как и прочие болезни винограда.

В некоторых странах виноград держат на лозе до наступления заморозков, и затем делают из иссушенных, подмороженных ягод вино под названием «ice-wine» (ледяное вино); тоже прелесть в разделе десертных вин, сцуко, очень дорогое и немассовое.

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

Ближе к началу осени виноградарь начинает орать о том, что если виноград не снять вот прямо сейчас, то он снимает с себя всякую ответственность; а винодел орет о том, что если он сделает вино не такое-то, как того ожидают ритейлеры, им обоим будет нечего с себя снимать, поэтому снимать виноград ещё не надо…

На заднем плане в лаборатории среди реторт притаился лаборант — он будет проверять соответствие винограда, а затем и итогового вина техническим характеристикам. Лаборант вообще не волнуется. Разработка идёт как полагается — все орут.

Чувствуем совпадения с процессом разработки программного обеспечения, да? Насыпьте себе сухого кахетинского Форстериезуитенгартена (я легко могу это слово произнести без запинки), и продолжим.

Можно насыпать лед, бо жара в Киеве — нуеёнафиг…

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

В виноделии существуют законодательно предопределенные технические параметры качества производимого вина.

Вот бы софтописателям заполучить такие законодательные стандарты 🙂

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

Также винодел придерживается непременно повторяемой технологии производства вина, хотя имеет всю власть для проведения экспериментов.

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

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

1. заранее подготовить (или купить) виноматериал определенного качества,
2. строго и правильно выдерживать правильную технологию производства.

Для протокола: виноделы Европы уверенны в том, что создание вина — искусство, которое невозможно формализовать, алгоритмизировать, сделать техничным, все держится на чутье, таланте, и созвездии Свисток рака.

Короче, для них виноделие — состояние души.

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

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

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

Примеры физико-химических показателей для оценки качества вина:

• объемная доля этилового спирта, %;
• массовая концентрация сахара в пересчете на инвертный, г/100 см3;
• массовая концентрация титруемых кислот в пересчете на винную, г/дм3;
• массовая концентрация приведенного экстракта, г/дм3;
• давление в бутылках для вин, насыщенных СОг, кПа;
• органолептические показатели, баллы: прозрачность, цвет, букет, вкус, типичность (или для вин, насыщенных С02,- игристые и пенистые свойства);
• ассовая концентрация летучих кислот в пересчете на уксусную, г/дм3;
• массовая концентрация диоксида серы (общей и свободной), мг/дм3;
• массовая концентрация тяжелых металлов (железа, меди, свинца, олова), мг/дм3;
• содержание цианистых соединений;
• физико-химическая и микробиологическая стабильность, полнота налива и герметичность укупорки бутылок, гарантийный срок хранения готовой продукции;

Список скопирован с vinogradnik.org.ua, но вообще он предопределен в законодательствах и директивах отдельных стран.

Еще страшные цифры есть в реферате «Товароведная характеристика и оценка качества виноградного вина». Там рассказывается про то, как в производстве шампанского юзается рыбный клей и лимонная кислота 😉

Дык вот, примеры с циферками.

Если предоставленное нам для пробы вино не болеет (помутнение, окисление и прочие мерзости), и содержит спирта от 12 до 16%, а массовая концентрация Сахаров находится в диапазоне от 210 до 300 г/дм3 (и титруемых кислот там в пределах от 3 до 8 г/дм3), то согласно ГОСТ 7208-93, мы зрим ликерное вино, которое полностью соответствует российскому стандарту качества.

А если спирта около 12%, а содержание сахара стремится к нулю (полного нуля тут не бывает), то перед нами сухое столовое вино.

Если спирта будет менее 9%, то это, скорее всего, уже будет фляка, а не сухое вино.

Если спирта ноль, то перед нами компот обыкновенный, виноградный.

Итак,

• если все диапазоны соблюдены,
• если лабораторные пробы показывают правильность ожидаемых цифр,

Вопрос — это качественное вино?

Безусловно, да. Все то, что укладывается в заранее установленные параметры, является качественным.

Но вот…

Вкусное ли это вино?

«Вкусность» нельзя рассматривать с точки зрения циферок ТТХ.

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

Однако именно по «вкусности» качество вина и определяется конечным потребителем 🙂

Вино, которое всего лишь полностью соответствует параметрам ГОСТ, ничего необычного из себя не представляет. Его можно выпускать на рынок, тестирование оно проходит успешно, но страдать от счастья с этим вином не приходится.

Это простое, стандартное вино.

Проблематичность оценки заключается в факторе субъективности. Все мы «разбираемся в винах» (не забываем оттопыривать мизинец). И все мы когда-то попадаем в странную ситуацию: обычное, безусловно стандартное вино не воспринимается как качественное.

Под качественным вином нами почти всегда подразумевается ВЫСОКОкачественное вино.

Очевидна ли подмена понятий и ожиданий?

Это понятно, или это странно?

Трабла в том, что высококачественное вино в ГОСТ не описывается. Оно просто иногда «получается».

Иногда можно попытаться предсказать, что «вот это вино получится высококачественным, очень юзабельным, с приятным и долгим послевкусием«, патамушта оно было сделано из винограда с такими-то высокими показателями ТТХ. Но бывает, что ожидания не оправдываются.

Иногда марочное вино, заранее предназначенное для многолетнего выдерживания в бочках, может обещаться когда-нибудь быть ВЫСОКОкачественным, и зачастую оно таким становится.

А иногда — нет.

Не всякое вино можно выдерживать по 50 лет в бутылках.

Невозможно гарантировать эту высококачественность подходом типа «винодел болеет за мой продукт, он переживает за качество всего проекта, он встанет и скажет, что проект не готов к выходу, даже если давление (в том числе и с моей стороны) будет высоко«.

Да и вообще, что такое «высококачественное вино»? Баланс между содержанием танинов, кислотностью и ароматикой? Долго послевкусие? Новое послевкусие?

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

Но есть вина, которые поражают неожиданным финтом:

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

Это ОЧЕНЬ круто.

За такие ощущения стоит заплатить дорого.

Ординарные вина подобными эффектами не обладают в принципе.

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

У опытного винодела вино, вероятнее всего, получится качественным.

У опытного и талантливого винодела вино, вероятнее всего, получится качественным, а вероятно, и высококачественным.

Все это зависит от винодела, а не от его лаборанта.

Тестировщик — не винодел. Он не разрабатывает.

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

Тестировщик — не инстанция, которая делает что-то такое, что позволяет качество продукта повышать или понижать, сильно или слабо болея за разрабатываемый продукт.

Продукт — вот он, готов (пусть даже частично), пробуйте и оценивайте.

Тестировщик определяет готовность и качество продукта, и сообщает эту информацию тем, кому она важна, dixi.

То, что тестировщики «не болеют» за продукт, не является проблемой аутсорсинга тестирования.

Более того, это вообще свойственно не только тестировщикам, но и всем остальным участникам разработки.

Взваливать ответственность за качество продукта на тестировщиков правильно только с точки зрения принципов Quality School (знаете ведь про школы тестирования, да?). В остальном это неправильно и даже пагубно.

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

Фиксить баги винодел не может, продукт уже готов. Он может их только предвидеть и может принимать какие-то меры в процессе производства, не более.

Все то, что винодел мог сделать, он должен был сделать ДО того, как вино объявляется готовым.

В виноделии, в случае если «не получилось», вы просто идете домой и сосете себе палец до просветления. Невозможно что-нибудь исправить в вине, которое «не получилось» в принципе.

Выправлять в готовом продукте можно только какие-то частности, но это редкость, и требует шаманства.

Да шаманство и не поможет, если речь идет всего лишь об исправлении дефектов.

В софтостроении хорошо то, что если продукту присущи какие-то дефекты, то их почти всегда можно исправить.

Но исправление дефектов не повышает качество продукта.

Исправление дефектов только «лечит» продукт, там, где что-то прогибается в минус, и после починки просто поднимается до уровня «ноль», то есть — как и ожидалось.

Картинка для наглядности

…

На оси Х слева направо последовательно перечислены какие-то функции, для которых мы будем выяснять уровень качества воплощения. Уровень «0» это очень хорошо, это значит, что в частностях все получилось as expected.

На оси Y отображается в «минусе» важность дефектов, которые были найдены, а в «плюсе» — уровень сатисфакции той или иной фичей.

Для наглядности — функция №1 получилась отменной, и получила целый балл к карме.

Любо-дорого открывать сайт в принципе 🙂

Остальные функции отзываются как положено, ок.

Функция №17 выдала нам такой лажовый бэмц, что приоритет бага был объявлен критическим. Позже баг пофиксят, и функция придет в норму. В норму, в «ноль», а не в дальние высоты программерского искусства.

Идея понятна?

Теперь вот что получается.

Качественный продукт — это ноль по всем показателям. Простое соответствие ожиданиям.

Высококачественный продукт — это выше нуля по всем показателям.

Такое бывает?

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

[polldaddy poll=5240022]

А речь идет о стонах.

Да, они — тонут и стонут. Они — это человеческие ресурсы, которых всем вам так не хватает.

Часть первая

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

Что дальше? Менеджер идет к начальству и говорит: “Начальство, мне нужно еще два тестера и один синьор разработчик.”

Начальство говорит: “Иди отсюда.”

Менеджер идет и думает: “Вот козлы. Вот козлы.”

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

А правильная стратегия какая? Если не знаем, то идем к Александру Орлову за вчитыванием в статью “У меня не хватает ресурсов”.

А если знаем, то отвлекаемся обратно на сторонние рассуждения о тестировании.

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

Отсюда можно сделать непрямой, но красивый вывод о том, что упомянутым в орловской цитате тестировщикам можно было бы придать титул «КАБАЛЬЕРО».

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

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

Начать можно с форума тестировщиков — «Размышления о престиже профессии тестировщика«. Там Алексей Баранцев сложил сагу о том, как и что можно было бы сделать на тему престижности этой профессии, потому как неможливо уже объяснять ценность тестирования «непосвященным людям».

Я, конечно, не удержался, и вякнул о том, что «Программисты и тестировщики — суть разработчики«, и отсюда надо плясать.

Но плясать оттуда никто не будет.

У меня особый случай, ибо как тестировщик я был воспитан грамотными разработчиками, потому и.

А другие когда-тошние ламеры начинали свою карьеру в тестировщицких карьерах, где надо тупо и истошно проходить тест-кейсы…

Ежедневно…

Не видя, собственно, смысла и конечной цели работы…

И верно:

Престиж ИТР в прошлом веке породил невероятную массу людей с высшим образованием, но без минимального понятия об инженерной деятельности.

То же самое примерно было с программистами и экономическими специальностями.

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

Предложение по этому поводу такое:

Публично отрицать хорошие стороны работы тестировщика!

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

Например, распространять информацию по принципу:

Есть такой закрытый клуб тестировщиков, они собираются по пятницам в гараже у Роджерса.

Там первое правило тестировщика — никому не рассказывай про тестировщиков. И второе правило тестировщика — вообще никому не рассказывай про тестировщиков!

Хочешь, я тебя туда отведу?

И чтобы закрепить эти позиции, предлагается сделать кино

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

Сценарий вкратце:

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

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

Потом он случайно обнаруживает ошибку в секретном модуле с помощью которого хакеры могут взорвать все американские АЭС. И докапываясь до истинны он узнает, что ошибка не случайная и русский хакер (он же бывший агент КГБ) известный по именем Руслана Беладонова уже готов запустить смертельный механизм.

Дальше все как обычно, погони перестрелки, заблокированные кредитки…

Развязка: будучи ранее программистом и не сумев добиться того чтобы его Р1 дефект был починен (единственный хороший программист — убит), он чинит это дело сам.

Но оказывается, что тестерам нет доступа на запись в репозиторий и он не может заинтегрировать свой спасительный код и америке наступает кирдык…

Бах! Это был всего лишь вещий сон, и он путем шантажа вынуждает сисадмина дать ему права на запись и все-таки успевает исправить программу за несколько секунд до взрывов.

Дальше опять как обычно — появляется ФСБ, ЦРУ и КГБ. КГБ арестовывает Руслана Б. Опального олигарха Бориса Березуцкого, заварившего всю кашу и прятавшегося в Европе выдает Интерпол.

ЦРУ и ФБР хватают всех работников фирмы, где работал главный герой (за исключением сисадмина).

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

Хэпиенд.

После такого фильма престиж профессии резко повысится, и даже дети будут говорить: «Мама, я хочу после школы заниматься тестированием! Запиши меня в секцию!»

Профессия тестировщика станет настолько востребованной, что в троллейбусах никто не будет покупать билеты — все будут тестировать билето-раздаточный вестибюлярный аппарат билетера.

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

Конец первой части.

Часть вторая, недописанная

Краткое содержание первой части:

Тсирвка тт-реало п рам сие тст-мдмента на ное мрц тест-ков сотвтдну из сах зчых олс тест-ежента.

————————————————————

Так.

Пауза.

Эту запись я вытащил из своих штанин черновиков.

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

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

Что теперь делать с этой записью непонятно.

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

Ну, пусть висит.

Just for fun.

Странное соотношение — в записи автор изрядно скромнит, а раскрывается как следует только в комментировании.

Музыка: Тролль-ля-ля, тролль-ля-ля, оседлали мы коня…

Похоже, следует изложить тему подробнее.

Я сделаю определенные выводы, и хочу, чтобы они были поняты в правильном контексте.

Все стартовые импульсы при заведении блогов — правильны

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

Это бред… Чем больше разных информационных ресурсов — тем лучше.

Но это и положительный импульс, который может превратиться в что-то существенное. Побольше бы таких импульсов!

И редко, редко, очень редко такие начинания сопровождаются ежедневной работой над созданным ресурсом. Весь пар уходит в дизайн, верстку, вклеивание голосований и прочего… Материала еще нет никакого, создатель старается сделать красивое оформление. А ведь оформление определяется контентом. Коня в оглобли запрягать надо, или оглобли в коня?

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

Примеры удачных проектов

Software-testing.ru, а вслед за ним еще и it4business.ru (они объединены одним форумом, и поэтому выступают и рассматриваются в одной связке) — пример того, что ПОЛУЧИЛОСЬ. Исходный импульс был «как у всех», но над двумя последними их авторы вели и ведут работу лично, самостоятельно, ежедневно. Ну, почти лично. Но без указаний о том, что «вот там кнопка для добавления статьи». Кнопку все видят, делов-то.

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

it4b «ушел» от узкой темы тестирования, но пришел к слишком общей теме, поэтому явно идентифицировать себя с этим ресурсом уже не каждому под силу.

S-T.ru держится «в русле», но ему еще очень надо поменять дизайн, и очень явно разделить контент, чтобы не превращаться в доску объявлений о тренингах для тестировщиков.

Примеры неудачных проектов

• ruwiki.qalaboratory.com — его автор верил в то, что ресурс будет жить, но сейчас там 404. Я тоже верил в веру автора, но 404 ничем не опровергнуть.
• mytestlab.ru — многообещающий был проект, уже давно не существует, остатки есть на mytestlab.livejournal.com, но и там последняя запись — двухлетней давности.
• ru_softtesting — самый многочисленный тематический коммьюнити в ЖЖ, но все равно тухлый. Вакансии, семинары, «с днем тестера»…
• ru_testers — ужасающ, но примечателен девиз сообщества… Контент: объявления.
• ru_testing — больше живых вопросов, но последняя «живая» запись — аж от 14 июля…
• ммммм (это кусок кремлевской стены)… Ну, и другие.

В чем «неудача»?

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

В сети нет вакуума в темах.

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

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

Лучшая цель для создания ресурса

Ресурс должен заводиться «для себя».

И на странице «about» должно быть написано что-то вроде «Привет, я сделал этот сайт для самого себя. Я занимаюсь тем-то«.

Очень плохо, если создатель ресурса на странице «about» начнет писать что-то вроде «да, ресурс далек от идеала, но просто мне лень сюда писать; но вот я вам создал сайт, он потихонечку растет, плиз, добавляйте на него статьи«… Создавать для того сайт с оплатой хостинга, а затем лениться над ним работать?! Шурик, это же не наш метод!

Нужен достойный пример описания ресурса?

На:

Приветствуем!

Если вы здесь впервые, то вы уже нашли место, где растут и развиваются IT-менеджеры.

Это портал для IT-менеджеров, для тех кто руководит, принимает решения и отвечает за результат. Темы портала: Карьера, Персонал, Технологии.

Можно подписаться RSS на портала и всегда быть в курсе, что нового мы тут делаем. Спасибо и заходите еще!

Хотя, это целый портал…

На более личное:

Меня зовут Борис, я собрал на этом сайте коллекцию рабочих шаблонов, приемов и утилит для того, чтобы и другие люди смогли использовать их в своей рутинной работе по обеспечению качества программных продуктов. Я занимаюсь этим делом уже 14 лет. Welcome!

Ни слова о том, что «наблюдается определенный вакуум«… Просто нет. Вакуум в головах, а не в…

Писать блог нужно для себя

Это, почему-то, ясно не всем и не сразу, поэтому об этом можно и нужно сказать.

Пиши блог для самого себя, ёпта. Пиши только о том, что интересно лично тебе. Если отчего-то смущает публичность — пиши под замком. В черновиках.

Да, твой блог В ПРИНЦИПЕ будет читать кто-то еще, но В ПРИНЦИПЕ писать нужно с оглядкой только на самого себя и на личную самоцензуру.

Идеал: когда-нибудь при поиске решения какой-то проблемы ты нагуглишь ее, прочитаешь, скажешь «Блинааааа, как все внятно и толково расписано! Надо подписаться на RSS. Э, момент, это же мой собственный блог!!!«

Поначалу такое кажется бредом. Начинающие писать помнят наперечет все свои записи, и не представляют себе, как можно что-то забыть. Можно. Гитарасты, например, поначалу тоже так думают. Но у каждого гитараста когда-нибудь дело доходит до повторного разучивания старых мелодий…

Контент блога определяется проблемами его автора

А писать, как и, простите, писать, нужно тогда, когда уже не можешь терпеть! © М. Жванецкий.

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

Ведение ресурса не должно быть для автора тяжким трудом и работой. Это должно быть интересно.

Стало неинтересно? Заморозь проект.

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

Такой подход далек от кармадрочерства, вроде «Пропиарюсь… Напишу нужную сообществу статью«. Никакому сообществу твои статьи не нужны. Сам себе пиши.

Отношение к проблемам

Лохматый! Сиди прямо и не стесняйся, тут не военкомат. Тут всего лишь сеть со всеми ее ресурсами.

Все интересные народу ресурсы содержат следующее:

• аналитика,
• суждение (пусть даже не такое, как у большинства),
• разбор полетов и случаев,
• личная заинтересованность автора.

Вагон комплексов, ложная скромность, оглядка на «а что скажут бородатые дядьки-тестеры» и «Я скромный, я не хочу пиарить свою личность» — все это ломает интерес и никак не подталкивает к написанию чего-либо. Не хочешь пиариться? А нафига тогда тебе нужен блог или вики-коммьюнити?

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

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

Крепись, дура! Ты ведь тоже можешь кого-то посылать и банить!

Пиши сам для себя. Не жди гостей и не приглашай к себе никого.

Тебя и так найдут 🙂

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

Просто не пиши для всех о слишком личном.

И не тормози на полпути.

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

И написал об этом в своем блоге.

Но на полпути остановился.

Глупая установка «Выводы каждый сделает для себя сам, а я так, скромно стою, просто указал на проблему…» — это просто психоблок из разряда детских страхов. Детей в школе изрядно пинают и ориентируют или говорить на пять, или не говорить вообще. Но взрослый?! В интерпретации взрослого человека это выглядит странно и, в итоге, очень скучно. Это выглядит как «Вы считаете, что я тупой? Ну, да, я бываю тупым, но не настолько… Неужели вы не видите иронию в моих словах? Где я тут тэг иронии потерял, хе-хе… О, как несправедлив этот мир!«

Ааааа, бля, проснись, чувак! Впрочем, продолжай спать.

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

«Неееееее! Я — выводы? Выводы пусть сделает каждый самостоятельно, а я тут, в углу постою…»

Ну что мешало автору СДЕЛАТЬ то, что он и так должен был сделать для своего же ресурса — написать развернутый, внятный, умный, техничный комментарий к ситуации?! И ведь сам написал!

После того, как слегка пнули.

Но написал!

Но ведь после того, как пнули…

Но написал! Этот чувак рулит! Да он не беспросветно скован! Он просто еще не развернулся, как полагается.

Ну, чувак, разворачивайся же скорее! Сделал же офигеннский разбор темы про RFC! Сникерсни дальше!

Глава следующая, заключительная

Я не зарабатываю на своем блоге рекламой, он хостится на бесплатном сервисе, дизайн я просто выбрал из существующих. Мое дело — контент и раз в год продление и парковка домена. Это очень дешево.

Но это один из самых долгоживущих моих блогов. Он мне все еще интересен.

Меня очень «греет», когда кривая его посещений ползет вверх. Радует, реально.

Я постоянно ищу о нем отзывы и ссылки — любые.

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

А когда этот блог становится мне неинтересным (и это бывает, я как-то пару месяцев его не трогал), кривая посещений ползет вниз.

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

Может показаться странным, но статистика неумолима: по переходам из поисковиков одной из самых читаемых статей этого блога является запись про «Выпадающие списки в Excel и Calc«.

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

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

Но поскольку я работаю ежедневно, то график выстраивается сам собой весьма плотно.

Видно, что я следую лишь кое-чему из того, о чем написано в предыдущих главах?

Просто я следую только самому важному:

• пишу для себя.
• пишу только о том, что интересно лично мне.
• пишу только потому, что мне все еще интересно об этом писать.

А свой вагон комплексов я уже давно успел незаметно снять с путей и выгодно продать перекупщикам.

Официальщина:

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

Почему не смог?

1. Из-за разницы в конфигурации компьютеровВ веб-отрасли это бывает реже, чем в десктопных приложениях. Но бывает. Но редко.
2. В описании бага отсутствуют какие-то шаги или нюансыА вот это очень серьезно, и идет прямым минусом в карму тестировщику. После ревью баг будет переоткрыт, что неприятно ни им, ни нам, ни этим, которые за всеми нами приглядывают.
3. Дефект уже починен в более новом билде, а девелопер как раз и проверяет это дело на этот самом «обновленном»Это самое противное и требующее рассмотрения.

Третья причина является проблемой из-за того, что входит в противоречие с официальным толкованием статуса «Не могу воспроизвести»:

Дефект проверяется на билде, указанном в описании дефекта.

Дефект, зарегистрированный в версии 1.9, отложен и принят к

рассмотрению в версии 1.12. Высока вероятность того, что в 1.12 он уже будет как-то починен? Если рассматривать ситуацию абстрактно, то вероятность весьма, весьма, гм, вероятна.

А если так, то является ли преступлением против системы треканья багов проверить исторический баг на новом билде, и заявить, что «не могу воспроизвести»?

Не является.

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

Единственно верное решение:

Поставить билд 1.9, воспроизвести, понять, отчего это произошло, и убедиться в том, что в билде 1.12 эта проблема несомненно решена. Убеждаться — в коде.

И если дефект при проверке уже считается недействительным, нужно ставить ему статус «Fixed» с указанием билда, в котором баг считается починенным.

Что в действительности — возня со старым билдом может потребовать неоправданно много времени. «Единственно верное решение» может быть использовано только в том случае, если баг приоретизирован как «серьезный».

Вышеизложенное написано в поисках уточнения: баг, который не воспроизводится на обновленном билде — он все-таки «Fixed», или «Can’t reproduce»?

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

Для тех, кто только что присоединился

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

Резюме статьи краткое:

хороший тест план должен как минимум отвечать на следующие вопросы:

1. что надо тестировать (объект тестирования: система, приложение, оборудование)
2. что будете тестировать (список функций и компонент тестируемой системы)
3. как будете тестировать (стратегия тестирования — виды тестирования и их применение по отношению к тестируемому объекту)
4. когда будете тестировать (последовательность проведения работ: подготовка, тестирование, анализ результатов, в разрезе запланированных фаз разработки проекта)
5. критерии начала и окончания тестирования

Это касается формализации тестирования, когда надо Cover Your Ass от возможных претензий, или кого-то по щекам стопкой бумаги похлестать. Или идёт обсуждение с участием многих людей, и все, о чем говорится, должно быть где-то как-то задокументировано.

Но бывают дни, когда тестировщик остается один на один с приложением. И возня с документами для него критична по времени. Например, никому не нужна…

На этот случай есть вариант создания тест-плана без возни с документами. Иногда можно и без тест-кейсов обойтись…

Ну так, рецепт:

1. Логически разделить приложение на отдельные, независимые друг от друга модули (да, принципиально это возможно).
2. В каждом модуле перечислить доступные функции.
3. Для каждой функции написать списки (в виде заголовков тест-кейсов, не более) вероятных проверок для каждой функции. Без спецификаций или подробных документов.
4. Проверять каждый пункт последовательно.

В этом стиле лучше всего работать с приложением типа MindMap или FreeMind, если Linux. Но в принципе все это можно сделать и в простом Notepad или Excel приложении (второе на порядок удобнее, например, можно модули по страницам разбросать, а потом автоматизировать отчет о количестве уже проверенных пунктов и о результатах проверок). Но так или иначе, главное — чтобы был список.

Со списком можно уверенно и быстро работать, неимоверно рулят принципы GTD. Видно, что можно вычеркнуть, а что важно. Видно, сколько еще софта осталось непроверенным. Многое видно, короче.

Простой тест-план, он же чек-лист, готов.

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

Конечно, я немного лукавлю, называя чек-лист тест-планом. Но все зависит от контекста и ситуации на поле боя.

Важное дополнение: хороший тест-план отвечает на косвенно задаваемый вопрос «Почему?».

Пример: https://ru.scribd.com/document/39391857/TestPlanTemplateV1-0