Lesson 293

Это последний урок последней главы книги Lessons Learned in Software Testing Сэма Канера и его товарищей.
22 августа 2011 года, 2 года и три недели назад я перевел первый урок.

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

Собирать перевод в одну xml'ку или pdf'ку мне лень, я книгу уже прочел, больше мне не интересно.

Дальше - возьму следующую книгу. Виттакера, может быть Копланда. А вообще Сэм, если я правильно понял, написал еще одну книгу, The Domain Testing Workbook, дождусь издания.

Максим cartmendum, пишу, как и обещал. Я добил последнюю страницу.

Слово Канеру

Относитесь к циклам тестирования как к сердцебиению процесса тестирования

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

1. Возьмите продукт. Убедитесь, что у вас правильный билд.
2. Сконфигурируйте систему тестирования. Очистите ее. Восстановите диск, полностью удалите предыдущую версию продукта.
3. Проверьте тестируемость. Это хороший билд? Он стоит того, чтоб его проверять? Проведите smoke-тесты, демонстрирующие, что основная функциональность работает.
4. Определите, что появилось нового, а что было изменено. Какой код расширял или менял возможности продукта?
5. Выясните, какие ошибки были исправлены. Также, найдите проблемы, которые отклонили и отреагируйте соответствующим образом.
6. Проверьте исправления. Их стоит проверять вначале, так как программисты еще помнят о них. Если ошибка не была исправлена, то программистам нужно быстро об этом узнать.
7. Протестируйте новые или менявшиеся области продукта. Это еще одна тема, которая еще свежа в умах программистов.
8. Протестируйте остальные области (высокие риски в первую очередь). Тестируйте все остальное, пока не кончится время. Выполните автоматизированные регрессионные тесты.
9. Сообщите о результатах. Результаты нужно предоставлять периодически, не реже одного раза в день в ходе цикла тестирования.

Lesson 292

В минувшие выходные боец @Raspberries жгла. Результат примерно такой:

Альбом: Ingress

Подробности и фоточки.

И еще история про кота от Александра Селяева.

Слово Канеру

Создайте стратегию тестирования как ответ на особенности и риски проекта

Хорошая стратегия тестирования формируется не только рисками, но и особенностями проекта. Вот несколько принципов формирования стратегий. Основанных на деталях проекта:

- Не теряйте баги в щелях между тестами. Если вы не используете принцип разных полумер или перекрывающихся зон ответственности, то сталкиваетесь с опасностью того, что определенная функциональность не будет проверена, так как окажется на границе ответственности между двумя тестировщиками или командами.
- Тестируйте то, что вас просят тестировать. Вы тестируете от имени большого количества клиентов. Что они считают, что вы должны проверить? Узнайте, и убедитесь в том, что вы удовлетворяете потребности хотя бы некоторых из них.
- Иногда проверяйте то, что вас просили не проверять. Иногда вас просят не тестировать определенные части продукта. Это деликатный вопрос и мы точно не скажем вам, что делать. Однако иногда те вещи, которые вас просили не тестировать являются теми, которые больше всего нуждаются в тестировании.
- Тестируйте путаницу и противоречия. Like coder; like code. Везде, где есть путаница и противоречия, процветают дефекты. Если программист не уверен в том, что делает функция — протестируйте ее. If he's new to the technology, test it. Если два программиста создавали части, взаимодействующие друг с другом — протестируйте их и вы не будете разочарованы.
- Не бейте мертвую фичу. Когда становится ясно, что фича полна ошибок — прекратите тестирование, если только вы не делаете это с разработчиком. Это может быть сломанная сборка, некорректная конфигурация. Кроме того, если компонент настолько плох, что будет заменен, а не пересмотрен, то любые ошибки, что вы найдете, будут закрыты.
- Чем больше изменений, тем больше тестирования. Теоретически, мельчайшее изменение в продукте может повлечь большие нелокальные эффекты. Это значит, что любое изменение потенциально обесценивает все тесты, которые вы когда либо проводили с продуктом. В действительности, большинство изменений имеют довольно ограниченный диапазон влияния. Тем не менее, вы должны следить за изменениями в продукте. Чем больше изменений, тем больше вы должны тестировать. Это становится серьезной работой в конце проекта.

Lesson 291

Пару дней назад в Екатеринбург приезжал Максим cartmendum Дорофеев.
Как обычно, жог.

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

Это неловкое чувство, когда ты выключаешь сервер по питанию, а он продолжает пинговаться

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

Бритва Оккама-????(Дорофеева?): Из всех объяснений ситуации наиболее вероятно то, в котором количество мудаков минимально. Первое следствие (Захарова?): Если ситуация объясняется тем, что все вокруг — мудаки, то скорее всего мудак — объясняющий.

При всем при этом с основной мыслью Максима позволю себе не согласиться. Он говорил, что из вариантов Алгоритмы, бизнес-идеи, языки программирования, общение самое важное для IT-специалиста — умение общаться, 50%, остальные три пункта по 15%.

Я считаю - это верно для всех, кроме программистов. Программист должен любить писать код. По поводу и без. Общаться за него должны все остальные — аналитики, тестировщики, саппорты, админы, менеджеры и прочий обслуживающий строчки кода персонал. Потому как без строчек кода все эти люди - предприниматели, ОТК, заведующие складом и вахтеры. Но не IT-специалисты.

З.Ы. Максим, а ты напишешь про меня восторженный твит, когда я закончу перевод Канера? Мне осталось 2 страницы.

Слово Канеру

Два тестировщика, тестируя одно и то же не дублируют работу.

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

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

Lesson 290

Слово Канеру

Остерегайтесь поклонения предкам при повторном использовании материалов тестирования.

Переиспользуя материалы тестирования или любые другие, не рассматривайте их как черный ящик. Изучите из. Выясните, почему они созданы именно такими. Во многих случаях архивные материалы для тестирования настолько низкого качества, что лучше их не использовать вообще. Тенденция тестировщиков доверять старым материалам только потому, что они старые загадочна. Мы многократно видели древние тесты, которые выполнялись через много лет после того, как стали неактуальны. Мы видели умных и квалифицированных тестировщиков, беспрекословно следующих тестам, которые писали менее квалифицированные тестировщики. Это темная сторона повторного использования.


В одной тестовой лаборатории было правило «всегда прверяй с Compaq Presario, because they are notoriously incompatible». Это правило было написано в 1996 году. Оно все еще актуально? Кто-нибудь возвращался к этой проблеме? Кто-нибудь подвергал сомнению авторитет Древних, которые писали правила?

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

Lesson 289

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

Слово Канеру

Тестируйте серый ящик

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

Тестирование серого ящика особенно важно для тестирования веб- и интернет-приложений, так как интернет построен вокруг слабо интегрированных компонент, соединяющихся через хорошо определенные интерфейсы. Если вы не понимаете архитектуру сети, то тестирование будет поверхностным. Testing Applications on the Web (2000) Hung Nguyen — хороший пример стратегии тестирования серого ящика, применимой в веб.

Lesson 288

Совместно со стажером выполнили первый пункт полугодового плана группы - повесили сетку. К ней прилагаются восемь мячиков.

Альбом: office

Ништяк.

Слово Канеру

Используйте уровни тестирования для упрощения обсуждения сложности теста

Чтоб упростить взаимодействие по поводу стратегии тестирования, для многих проектов полезно различать уровни тестирования. На низком уровне более простые, менее обширные тесты. Тесты высокого уровня более сложны и всеохватывающи. Это позволит упростить обсуждение стратегии тестирования by providing a shorthand for talking about classes of testing. Вот пример иерархии уровней тестирования:

- Уровень 0: Smoke тестирование. Простые тесты, показывающие, что продукт готов к тестированию, a sanity check. Если не прошли тесты нулевого уровня, отправьте код назад к программистам.
- Уровень 1: Тестирование возможностей. Тесты, проверяющие работоспособность фич. Цель — убедиться в том, что каждая функция выполняет свою задачу. На этом уровне стоит избегать раздутых сценариев, сложных данных и взаимодействия фич.
- Уровень 2: функциональное тестирование. Тесты, проверяющие как работу, так и надежность каждой функции продукта. Интерес представляет покрытие тестами и сложные методы оценки результата. Используйте граничные значения, стресс-тесты, тесты на обработку ошибок, но избегайте запутанных сценариев и взаимодействия функций.
- Уровень 3: комплексное тестирование. Тесты на взаимодействие потоков управления группами функций, сложные сценарии. Фокус расширен и включает оценку производительности, совместимости, конфликты за ресурсы, утечки памяти, надежность и другие критерии качества, которые становятся проверяемыми по мере зрелости продукта.

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

Lesson 287

Слово Канеру

Тестируйте продукт на зрелость

Хотя общие стратегии для фаз жизни проекта, как правило, недостаточны, все же имеет смысл применять разные стратегии на разных фазах, в зависимости от того, насколько зрелым является продукт:
- На старте проекта тестируйте снисходительно. В начале проекта продукт плохо работает и вы мало о нем знаете. Серьезные тесты на данном этапе по большей части не нужны, так как даже простые тесты найдут ошибки. Таким образом, программисты, знающие, что продукт еще не готов, будут огорчены излишним усердием тестировщиков. Программисты хотят знать, работают ли функции, которые они реализовали.
- В середине проекта тестируйте агрессивно. Так как продукт поставляется вместе с реализованными фичами и техническим долгом, простые тесты теряют свою эффективность. Программисты чувствуют себя уверенно в продукте. Они переходят от реализации фич к фулл-тайм исправлению багов. Самое время, чтоб провести полное и более сложное тестирование. Mine flaky parts of the product for all they're worth. Найтиде и зарепортьте так много дефектов, как можете. Создайте беклог ошибок для разработчиков.
- Ближе к концу проекта тестируйте разными способами. В зрелом продукте сложнее найти ошибки, тестирование должно быть более творческим. Это время довести разнообразие тестирования до пределов вашей фантазии. И руководство окажет вам поддержку. Используйте помощников, автоматизацию, мероприятия тестировщиков (bug finding parties or bug bounties), эвристику, бетатестеров и все остальное. Если вы все сделаете правильно, ваша кривая скорости поиска ошибок будет идеальной кривой, как на диаграмме. Поднимите ее вверх на ранних этапах за счет агрессивного тестирования и удерживайте там во время завершения проекта за счет разнообразного тестирования, пока у вас не кончатся идеи для новых и лучших тестов.
- В последние дни проверяйте тщательно. Ошибка последних дней может стоить вашей компании очень дорого. Когда вы приближаетесь к дедлайну, тестирование должно стать оборонительным. Тщательно проверяйте каждое изменение. Проверьте каждый файл, который будет выпущен в релиз. Используйте парное тестирование, чтоб обеспечить вдвое больше глаз, наблюдающих за тестированием.

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

Картинки.
Раз:

Альбом: bug

Два:

Альбом: bug

Три:

Альбом: bug

Четыре:

Альбом: bug

Lesson 286

Вчера украинец прошел испытательный. И уже сегодня пришел не на час раньше, а на 45 минут всего. Расслабился.

К вопросу о именовании, нового стажера назову Наташа.

Слово Канеру

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

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

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

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

Lesson 285

Слово Канеру

Ваша первая стратегия тестирования проекта всегда неправильная

Стратегия должна развиваться по мере того, как вы работаете с продуктом и узнаете о его модели ошибок. Мы рекомендуем базировать вашу стратегию на рисках. Это ставит перед вами проблему: вы на знаете риски продукта. В начале проекта у вас есть только слухи о том, где могут находиться хорошие баги. Educated guesses, if you're lucky. В начале проекта ваша стратегия страдает, по меньшей мере, от одной из двух проблем: она не сфокусирована на рисках или сфокусирована на областях, которые не относятся к рискам.


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

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

Lesson 284

Пересмотрел Место встречи изменить нельзя.
Дальше на очереди - Семнадцать мгновений весны.

Просто вид из окна с рабочего места.

Альбом: office

Слово Канеру

Собирайте ресурсы для усиления стратегии тестирования

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

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

Lesson 283

Тестер 1: зацените постановку на скрипт
Тестер 3: Добавь комментарий "Ну н-н-н-ахер"
Тестер 3: Или такой вариант Выбор типа запроса из  2.2.1.1.2. не дополняет, но полностью противоречит типу из  2.2.1.2.1., при этом услуга  2.1.2.1. может быть не найдена
Тестер 2: Второй вариант значительно круче
Тестер 1: А по смыслу почти то же самое

Слово Канеру

Применяйте разные полумеры

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

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

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

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

Lesson 282

Для меня регулярные выражения - апофеоз программистской души и символ ее метаний и стремлений.

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

Регулярки сложно поддерживать. Мне.
Надо будет их выучить.

Слово Канеру

Стратегия объясняет ваши тесты

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

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

Lesson 281

Почему то считал, чтоб собрать хороших людей достаточно фразы:
Всем своим. %день_недели%, %название_кабака%

Оказалось, каждый ждет персонального приглашения и сомневается, ему ли адресовано послание. Напомнило этот баш:
ааа: дебил
xxx: ты мне?
yyy: ты мне?
zzz: кто, я?
aaa: вы просмотрели миниатюру "детская самооценка"

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

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


Слово Канеру

Стратегия тестирования больше, чем просто тесты

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

Lesson 280

Программист и менеджер.

П: Я буду эти тесты писать четыре дня, долго.
М: Все равно пиши.
П: Что важнее, тесты или функциональность?
М: Тесты. Так как функциональность без тестов — не работает, а значит вредна.

Несмотря на то, что тесты без функциональности это, конечно, ноль, функциональность без тестов (в контексте = не работающая) величина явно отрицательная.
Дискас?

Слово Канеру

Как могут лгать тест-кейсы

Если вы соберете все портфели в компании и сложите в кучу, вы ничего не узнаете о том, что внутри них. У вас есть 37 портфелей, они вместе весят 384 фунта, что это говорит о будущем компании? Ничего. Тем не менее, их содержание может иметь большое значение для вас. Вопрос решить можно только открыв портфели и разложив содержимое по полкам.

Тест-кейсы как портфели. Их подсчет без учета содержания ничего не говорит. Подсчет соотношения проходящих и падающих тестов тоже ничего не говорит: 90% тестов проходят, это хорошо или ужасно? Никто не ответит, не зная содержания тестов. Вычисление соотношения запланированных и написаных кейсов также ничего не говорит, может быть самое важное отложено на потом и последние 10% займут половину времени для создания. Или может случиться, что общее количество запланированных тестов недостаточно для покрытия рисков.

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

Johanna Rothman считает нашу позицию по этому поводу слишком экстремальной. Она пишет: «У нас есть еще одна альтернатива. Например, если количество прошедших тестов уменьшилось с 98% до 30% в начале проекта, тор вы должны беспокоиться? Скорее всего нет. Но, если вы за неделю до беты или запуска продукта, то да, вам стоит беспокоиться. Почему? В начале проекта вы вообще не будете проводить многие тесты. Но в конце проекта вам придется провести большую часть испытаний, если не все. Можно использовать эти цифры, чтоб обсудить проблемы, например, нехватки ресурсов. Вы могли бы использовать эти данные, чтоб объяснить вашу озабоченность.»

Jeff Bleiberg пишет: «Как правило, есть необходимость обеспечить прозрачность процесса тестирования. Этому помогут метрики. Но, независимо от того, насколько они «надежны» и «говорят сами за себя» люди будут понимать их неправильно. Одно из моих правил состоит в том, что я не распостраняю свои отчеты и веду записи встреч, в которых отражаю значение метрик.»

Lesson 279

Речь Барри Шварца. Речь которой аудитория апплодировала стоя.
Перевод от alexthunder

О мудрости, личной инициативе, морали, соблюдении и несблюдении инструкций. Настоятельно рекомендую.
Видео:


Цитата:
"Инстуркции нужны нам для того чтобы спасать нас от катастроф. И они спасают. Одновременно инструкция гарантирует что болван останется болваном."

Слово Канеру

Не позволяйте логистике и артефактам заслонить собой стратегию

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

Lesson 278

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

Слово Канеру

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

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

- Стратегия. Как вы будете покрывать продукт, чтоб найти быстро важные проблемы? Что именно вы будете тестировать? Какими способами вы будете создавать тесты? Как вы будете определять ошибки? Стратегия тестирования определяет связь между проектом тестирования и миссией тестирования.
- Логистика. Какие ресурсы вы используете для реализации стратегии? Кто будет тестировать? Когда они будут это делать? Что нужно для получения результата?
- Артефакты работы. Как вы представите работу заказчикам? Как вы будете отслеживать ошибки? Какую тестовую документацию создадите? Какие отчеты создадите?

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

Lesson 277

Пока я стонал, что мне мешал дождик, enlightened боец Raspberries забацала нехилый trip автостопом(!) по уралу и создала, между прочим, вот такенное поле:

Альбом: Ingress

Слово Канеру

Проектируйте ваш план тестирования так, чтоб он соответствовал контексту.

Один из способов видуализации плана тестирования показан на рисунке. Это Satisfice Context Model. Пять пузырей на лучах звезды представляют то, что у нас имеется: ресурсы и ограничения. Центр звезды — наше решение. Объект планирования — решения по процессу тестирования, которые позволяют в рамках ограничений среды проекта и используя ресурсы достичь целей миссии.

Альбом: bug

Пять сущностей на картинке:

- Разработка. Система, которую вы тестируете. Как вы получаете продукт? Как его можно тестировать?
- Требования. Критерии качества продукта. Риски продукта. Чье мнение о качестве важно.
- Команда тестирования. Люди, которые тестируют продукт. Вы нанимаете команду? Are they up to speed on the technology?
- Лаборатория тестирования. Системы, инструменты, материалы, которые позволяют вам делать вашу работу. Есть ли у вас необходимое оборудование? В каком состоянии ваш баг-трекер?
- Миссии. Проблемы, решение которых будет рассматриваться как успех вашими клиентами. Находите ли вы быстро критичные баги? Производите ли точную оценку качества?

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

Lesson 276

Ingress и прочие велопоездки накрылись погодой.

Слово Канеру

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

План тестирования — основная идея всего, что вы делаете. Иметь эту идею очень важно. Документировать ли эту идею или нет — тема отдельного разговора.

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

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

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

Lesson 275

Слово Канеру

Существует много возможных стратегий тестирования

Стратегия тестирования это набор вариантов. Вы можете использовать несколько:
- Мы выпустим продукт для лояльных пользователей, после короткой внутренней проверки, которая позволит найти самые серьезные проблемы. Лояльные пользователи расскажут о изменениях в продукте, которые они хотели предложить после недолгой эксплуатации.

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

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

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

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

Lesson 274

Намедни купили и повесили на стену большие карты Екатеринбурга и области. А еще попросил на работе много много синих и зеленых... гм.. булавок? Втыкалок в карту, короче.

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

Слово Канеру

Три основных вопроса о стратегии тестирования «Зачем?», «Кому это нужно?» и «Сколько?»

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

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