пятница, 27 апреля 2012 г.

Lesson 111

История о маскирующемся баге.

Намедни появился в проекте баг. И еще был тест, который умел этот баг находить. Все просто?

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

А тест был предпоследним в последнем по алфавиту классе,

2 дня назад смотрим — ну очень долго идет сборка. Грохнули, включили логирование GC. Опять долго, OutOfMemory, в дампе норм, грохнули, добавили памяти. Один хрен — долго. Добавили вообще много памяти и перм гена накинули. Прошла сборка, и предпоследний тест в ней обнаружил пресловутый баг, с продвинутым скиллом маскировки.


Слово Канеру:

Рассмотрите ошибки, которые вы не находите во время автоматизации тестирования.

При подсчете стоимости автоматизации, мы советуем тебе сосредоточиться на упущенной выгоде. Что бы ты успел сделать за время, потраченное на автоматизацию? Какие тесты ты не провел? Какие баги не нашел (Marick 1998)?

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

Lesson 110

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

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

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

Подсчитали, что тестирующая система тратит треть времени сборки на удаление объектов, созданных во время тестов. Какая, стцуко, культурная. Думаем отключить для дневных сборок.

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

Кот рядом. Скоро отпуск.
Альбом: randompics4lj


Слово Канеру:

Автоматизированные регрессионные тесты находят меньшую часть ошибок.

Неформальные исследования показали, что процент багов, найденных автоматизированными тестами удивительно низок. Проекты с серьезной, хорошо спроектированной автоматизацией говорят, что регрессионные тесты находят около 15% багов от общего количества (Marick, online).


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

Новое тестирование старых фич с большей вероятностью найдет проблемы, чем старые регрессионные тесты. У них есть дополнительное преимущество — они могут найти ошибки, которые там были с самого начала[1].

[1] Есть два исключения.
1. Если в вашем проекте плохо с управлением конфигурациями, то старый код может быть переиспользован, внося в проект старые ошибки. Тем не менее, надлежащее управление конфигурациями, как правило, более дешево и эффективно, чем регрессионное тестирование.
2. Плохое проектирование кода может привести к ситуации, когда испрвление одной проблемы приводит к появлению второй. И когда вторая проблема будет исправлена, первая проблема появляется вновь.

среда, 25 апреля 2012 г.

Lesson 109

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

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

А еще у нас совсем тепло и вообще лето, +25.


Слово Канеру:

Не оценивайте тесты в терминах частоты их запуска.

Ценность теста в информации, которую он предоставляет. Это трудно оценить. Часто квалифицированное тестирование заключается в качественном решении подобных вопросов.
Некоторым тестировщикам советуют попытаться сделать оценку так: насколько автоматизация обеспечит возврат инвестиций путем сравнения затрат на автоматизацию и на проведение тех же тестов вручную (смотри, например Linz and Daigl 1998a and 1998b; Dustin et al. 1999, 52 and Fewster and Graham 1999, 519).

Мы считаем, что этот подход измеряет неправильные вещи неправильным способом (Hoffman 1999a).

Вот уравнение, которое мы считаем в корне неверным:
Альбом: bug

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

У нас есть два основных возражения против использования этой формулы для оправдания затрат на автоматизацию:
1. Тесты несравнимы. Не сравнивайте ручное и автоматизированное тестирование(Lesson 108). Они просто не могут обеспечить равный объем информации.
2. Нельзя сравнивать расходы на поддержание 50 прогонов автоматизированных тестов и организации 50-кратного тестирования вручную. Кто будет 50 раз тестировать вручную одно и то же? Это не будет стоить затраченных усилий. И то, что ценность теста — предоставляемая информация — не оправдание.

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

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

вторник, 24 апреля 2012 г.

Lesson 108

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

Слово Канеру:

Не сравнивайте ручное и автоматизированное тестирование.

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

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

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

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

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

пятница, 20 апреля 2012 г.

Lesson 107

Намедни был на НауДевелКампе.
Было всяко интересно.

1. Юра нам рассказывал о Perfomance Review.
Я бы попробовал, но непонятно, что изменится.
2. Дмитрий Калаев рассказывал, почему IBM'ы не рождают FaceBook'и.
Было понятно, почему не рождают. Было непонятно, и чо дальше.
3. Зайцев Андрей рассказывал как Нау захватит мир.
Учим мунспики, учим...

А на технический трек я не пошел, пошел к аналитикам, да.

4. Юля рассказала, как мы работаем с требованиями.
Узнал много нового. Было даже понятно.
6. Илья рассказал, как он делал гуй.
Весело, увлекательно, чоделатьнепонятно.
5. Антон рассказал, как скрам помогает повысить показатели.
Много спорили, зал говорил, что показатели потому что Антон и компания стали опытней и умнее, а Антон говорил, что это все скрам.
7. Самый Главный(TM) рассказал, о особенностях продажи продуктов.
Интересно. Про то, как продаются продукты, помогающие экономить, а как - помогающие зарабатывать. И как один продукт бывайт и тем и другим, в зависимости от контекста.

Выступил и я с коллегой из группы мануального тестирования. Рассказали о парном тестировании.

Один из слайдов:
Альбом: office


Практически фото процесса:
Альбом: office


Слово Канеру:

Не автоматизируйте бардак.

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

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

четверг, 19 апреля 2012 г.

Lesson 106

Читаю истории успеха:

2.5 месяца назад организовал отдел тестирования За полмесяца наладил взаимодействие и схему работы с 2я отделами разработчиков.

Ка-а-а-г он это сделал?
Я-не-верю-ни-слову.

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

А человек взял и наладил за пару недель, епт.


ЧЯДНТ?

Слово Канеру:

Инструмент тестирования это не стратегия.

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

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

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

Lesson 105

Сегодня была прекрасная возможность сказать А я предупрежда-а-ал!

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

Слово Канеру:

Не требуйте 100% автоматизации.

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

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

Будь скептически настроен, когда консультант или продавец инструмента автоматизации рассказывает тебе о ведущих компаниях, достигших 100% автоматизации. Требуй доказательств. Многие ведущие компании успешно используют сочетания методов тестирования, в том числе однократное минимально документируемое исследовательское тестирование. И оно должно быть. Автоматизация обычно означает запуск небольшого количества тестов как можно чаще. Многие тесты стоят того, чтоб их провести только один раз.

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

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

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

среда, 18 апреля 2012 г.

Lesson 104

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

Особенность - если виновный не виден по коммитам, то чинит первый попавшийсая программист.
Цитируем сэра Терри: Нет справедливости. Есть я.

Слово Канеру:

Выбери свою стратегию автоматизации, опираясь на контекст.

Стратегии автоматизации зависят от требований к тестам, архитектуре продукта и квалификации персонала.
Требования тестирования Программное обеспечение может иметь много фич, но чаще всего лишь несколько из них являются ключевыми. Они должны надежно работать. Они могут требовать обширного тестирования, оправдывающего автоматизацию. Кроме того, вы могли бы сосредоточиться на том, как автоматизированное тестирование сможет помочь управлять основными рисками продукта. Ручное же тестирование может быть хорошим в других аспектах тестирования.
Архитектура продукта Анализируй архитектуру продукта для определения возможностей по автоматизации. Какие компоненты ПО важны? Как они взаимодействуют? Какие технологии в них используются? Какие у них точки соприкосновения? Архитектура описывает компоненты и их взаимодействие в различных частях системы. Языки, окружения, компоненты ограничивают набор возможных инструментов тестирования. Интерфейсы По определяют возможности по автоматизации (Hoffman 1999b).
Квалификация тестировщиков Некоторые подходы к автоматизации могут быть успешно использованы непрограммирующими тестировщиками. Другие полностью используют навык тестировщика-программиста. Одного из нас (Pettichord) однажды попросили порекомендовать единый подход к автоматизации тестирования в компании с различными продуктами, разработанными в разных местах. Он не смог этого сделать. В некоторых местах были тестировщики, умеющие программировать, в других их не было. Не было единого подхода, работающего для всех. Даже если бы продукты были похожи, у персонала были слишком разные подходы и возможности.

вторник, 17 апреля 2012 г.

Вдогонку

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

Уточнить: Я живу в сказочной стране эльфов, я за починку тестов, я верю в зеленые сборки.

Добавить: Раз уж мы написали кучу тестов, то dura lex, durex или, как это перевели на баше, закон суров, гандон.

Lesson 103

Напевает
Микросхемы терпят все,
Можешь делать все, что хочешь.


Что-то я много чего не понимаю. Нужна аргументация, а ее нет или мало.
Сейчас говорю не только о селениумных, но и о unit тестах, о статических анализаторах.

Правильно ли фигачить новую функциональность, невзирая на сработавшие вышеперечисленные?

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

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

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

Затем. А давайте какие-то там тесты не будут управлять процессом разработки и приоритетами задач программистов. Давайте приоритетами задач программистов будет управлять менеджер проекта, который за все отвечает. Это правильно. Ему сейчас нужно фичи.
Он делает вывод - чиним потом, сейчас гоним фичи.

Вот дальше я шаги не делал
Но если попробовать:
- Сломанные тесты это не некритичные дефекты приложения, это критичные дефекты процесса. Надо чинить.
- Негоже из за пары тестов стопорить весь процесс разработки. Можно фигачить.

Ну и еще можно совсем пофантазировать.
- А вот в гугле есть ПМ, а есть начальник разработчика. И у них ПМ разработчику не начальник, а вполне себе заказчик. Можно и так относиться. Тогда - совсем другой коленкор, не так ли.

Короче.
Реквестирую ваши мнения. Даже опрос вставлю.



Помогите понять.



Слово Канеру:

Расширяй охват вместо повторения одних и тех же тестов.

Используй автоматизацию для расширения охвата и восприятия, чтоб видеть больше и больше.

Ты просто не сможешь запустить некоторые тесты без использования автоматизации. Другие тесты ты сможешь запустить в более серьезном масштабе. Вот несколько примеров:

Тестирование нагрузки Что случится, если 200 человек попробуйт использовать твой софт одновременно? А если 2000? Тебе необходима автоматизация для эмуляции такого кейса.

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

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

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

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

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

суббота, 14 апреля 2012 г.

Lesson 102

Слово Канеру:

Ускорить процесс разработки вместо экономии нескольких долларов на тестировании.


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

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

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


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

Если кодовая база в значительной степени стабильна и покрыта большим набором автоматизированных тестов, программисты могут пытаться вносить большие изменения с меньшим риском. Также, команда продукта может варьировать объем функциональности ии дату выпуска продуктов и в кратчайшие сроки реагировать на потребности рынка.
Вот несколько примеров для поддержания высоких темпов разработки.
Автоматизированные Smoke-тесты Термин smoke-тест пришел из тестирования аппаратного обеспечения. Ты подключал новую плату и включал питание. Если ты видел дым — ты выключал питание и делать какие-любо другие тесты не было необходимости. Smoke-тесты (или тесты вирификации билда) как можно шире покрывают фичи продукта за ограниченное время — обычно за обед или за ночь. Если ключевые фичи не работают или ключевые ошибки не исправлены, команда не будет тратить время на инсталляцию и тестирование билда. Исправление этих проблем становится приоритетной задачей программистов.
Автоматизированные юнит тесты. Эти тесты также упорядочивают процесс разработки, предотвращают дефекты и поддерживают движение. Это большой набор тестов сосредоточен на тестировании низкоуровневых функций и классов продукта.
Наибольшая ценность smoke и unit тестов в том, что любой тест может быть запущен в любой момент. Их автоматический запуск — часть процесса разработки. Их наличие позволяет отдельным программистам создавать минибилды включающие одно или несколько изменений. Если один из минибитлов сломан, то программисту известно, с чего начинать расследование. Если минибилды в порядке, то и большой билд, собирающий все изменения, пройдет успешно. Это преимущество руководитель проекта, несомненно, оценит.
Эти виды автоматизированных тестов теебуют времени, усилий, мастерства и денег. Unit-тесты, скорее всего, создадут программисты, хотя вы бы могли стимулировать эту работу, написав код вместе с ними, как часть парного программирования. Со всеми этими преимуществами вам будет проще обеспечить сотрудничество, чем если бы вы направили усилия на сохранение времени ручного тестирования (Beck 1999, Часть 20).

четверг, 12 апреля 2012 г.

Еще рутина

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

Баги, запланированные на следующую итерацию
1. Приложение не работает, если подниматься с пустой БД
2. Отсутствуют иконки смены состояния/свойств бизнес-объекта при быстрой работе.

Альбом: randompics4lj


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

Рутина

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

До сегодняшнего утра последовательно грешили на версию java, tomcat, плохую карму, jetty, кривые руки во время установки явы, версию операционной системы.

Утром обновили несколько важных инсталляций. Сбой не повторился. Выдохнули.

Вердикт - автотестеры ручками закосячили установку и им надо переустановить яву, операционную систему и ДНК.

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

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

Попросил программиста подняться на пустой. Сбой есть.

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

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

Выводы
1. Людям верить нельзя.
2. Семь рабочих часов от обнаружения до локализации это многовато.

среда, 11 апреля 2012 г.

Сhapter 5: Owerview

Слово Канеру:

Часть 5: Автоматизированное тестирование
Обзор


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

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

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

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

Рецензенты ранних черновиков этой главы отдельно призвали обратить внимание на следующие моменты:

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

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

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

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

Lesson 101

Разработчик: «Приложение поднимается, а то, что оно работает я не проверил»
Норм, чо.


Слово Канеру:

Если ты решил бороться, ты решил выиграть!

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

Чтоб подготовиться к апелляции, ты можешь:

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


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

пятница, 6 апреля 2012 г.

Lesson 100

Сотая лекция Канера. Надо разбить об меня 40% бутылки шампанского.
Слово Канеру:

Обжалуйте отсроченные баги немедленно.


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

Lesson 99

Слово Канеру:

Инерция тестирования никогда не должна быть причиной откладывания исправления дефекта.

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

Lesson 98

Слово Канеру:

Не позволяй отложенным багам исчезать.

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

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

Продукты, которые проходят через большое количество релизов, накапливают большой набор раздражающих багрепортов, которыен никогда не приведут к изменению кода или документации. Некоторые группы вместе с руководителями проектов делают ревью таких багов и постоянно закрывают их с причиной INWTSTA ("I never want to see this again").

Лучше всего делать такое ревью в начале проекта, когда давление времени минимально, а руководитель проекта спокоен и наиболее разумен.

Lesson 97

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

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

Слово Канеру:

Не настаивай, чтоб каждый баг был исправлен. Выбери свою битву.



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

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

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

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

вторник, 3 апреля 2012 г.

Хы

Как могло бы выглядеть мое резюме или робкая попытка инфогрфики.

Альбом: office


Гг, да, работу я не ищу.

Lesson 96

А вы знали, что падежей в русском языке прям 13?

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

Слово Канеру:

Проверяйте исправления быстро.

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

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

Ни одна ошибка не может быть закрыта никем, кроме тестировщика.

Lesson 95

У меня масса вопросов.
1. Нужна ли в jira русификация?
2. Что вы думаете о плагине Зефир? ну у нас реально нет кейсов вне АТ, значит и зефир не нужен, правильно?

Нашел примерно такой отзыв о Зефире:
[...] И при этом окружать профессионала будут очень приятные и адекватные люди (медленно сжимая кольцо), с которыми он будет говорить на одном языке – на языке жестов и междометий в адрес проклятых создателей гребанного Zephyr… [...]

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

Слово Канеру:

Если фикс фейлится (ну подскажите, как еще перевести fixes fail), поговорите с пограммистом

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

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