вторник, 28 февраля 2012 г.

Рутина

Р . Юферев в своем выступлении очень внятно и дельно рассказывает о необходимости думать.

В частности, он говорит: "когда вы узнаете об ошибке? Когда на нее наткнется ЛОЯЛЬНЫЙ пользователь, который не махнет рукой на ваш сервис, но отправит тикет в саппорт".

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


А мне должно быть стыдно, чо уж. Знаю как работает тестирование и техподдержка. Но багрепорт не отправил.

Вывод: пишите в саппорт. И будет всем щясте.

Собственно, выступление Р. Юферева:

Lesson 77

Рекламы предыдущего поста пост: http://w-bf.livejournal.com/237635.html

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

Невоспроизводимые ошибки воспроизводятся.

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

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

- Ошибка может быть инерционной, такой как утечка памяти, дикий указатель или повреждение стека. Если вы подозреваете проблемы, связанные со временем, рассмотрите вопрос о сотрудничестве с программистами, используя Bounds Checker (http://www.numega.com), Purify (http://www.rational.com/products/purify_unix/index.jsp) или другие подобные утилиты, либо используйте методы мониторинга ПО во времени (видеозапись вывода, мониторинг использования памяти и т. п.).
- Ошибка может появляться только первый раз после установки ПО или использовать только определенную часть продукта. Используйте Drive Image (http://www.powerquest.com/driveimage/), Ghost (http://www.symantec.com/sabu/ghost) или другие подобные утилиты, чтоб создать точную копию чистой системы(на которую никогда не устанавливалось ваше приложение). Восстановите систему, установите приложение и попытайтесь снова воспроизвести ошибку.
- Ошибка может зависеть от специфических значений переменных или от повреждений БД
- Ошибка может воспроизводиться в определенную дату или время. Конец дня, недели, квартала или года.
- Ошибка может зависеть от серии задач в определенном порядке. Что вы делали перед тем как появилась бага?
- Ошибка может быть остаточной после предыдущего сбоя. К примеру, вы перезапускали машину после последнего GPF?
- Ошибка может быть вызвана взаимодействием тестируемого приложения с другим ПО, работающим в фоне или ПО, конкурирующем в доступе к устройству. Возможно, сбой отражает проблемы во взаимодействии с устройствами.

Есть и другие идеи, их слишком много, чтобы останавливаться на них в этой книге. Мы рассматриваем эту область подробней в части первой новой редакции Testing Computer Software (Kaner и соавторы), но в то же время вы могли бы найти полезные идеи у Nguyen (2000), Kaner (1993), and Telles и Hsieh (2001).

Lesson 76

Рекламы предыдущего поста пост:
http://w-bf.livejournal.com/237635.html

И да, слово Канеру:

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


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

У программистов есть инструменты, которых нет у тебя. Если ты сообщишь только симптомы, программист сможет отследить по коду, уточнив, как именно ты мог получить определенные сообщения или увидеть определенный диалог. Предположение, что программисты могут исправить 20% «невоспроизводимых» багов, о которых им сообщили, не является неразумным (Очевидно, что процент будет меняться в зависимости от продукта, набора инструментов. По достоверным сведениям, есть программисты и проекты в которых этот показатель поддерживали на уровне 80%).

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

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

Когда репортите такую ошибку, дайте понять, что она не воспроизводится. Некоторые трекеры имеют специальное поле для этого (Воспроизводится: да/нет/временно/неизвестно). Некоторые компании используют для этого маркировку, например NR(not reproducible) в заголовке или первой строке описания.

Использование скриншотов, программ для записи действий или видеозаписи экрана поможет вам доказать существование UFO (Unidentified Funny Objects) программистам.

Йасуперстаррр

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

Там вначале все объявляются и знакомятся, на 11 минуте начинается мое вещание.
На 60й — начинает жечь Михаил.

Я рассказываю как не нужно писать тесты, Миша — как нужно.



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

Реквестирую в тред мнения о моем докладе, о докладе Миши и о моей дикции, гг.

UPD: Хороший вопрос мне задали на 36:15, LOL

суббота, 25 февраля 2012 г.

Радости пост

Обновился таки мой tf101 до ICS 4.0.3

Ничего нового. Ничего особенного.
Поменялись 2 иконки.
Приложения - как были - так и остались. Работают точно так же.
Выглядят точно так же. Настройки те же.

И да, все-все стало работать плавно и чуть быстрее.

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

среда, 22 февраля 2012 г.

Рутина

Скрам на марше, Бгг.

Альбом: office


Так реально интересней. И да, могу - не копать.

Lesson 75

С подачи doktorbel .

Философское.

1. Если функционал покрыть тестами, то в нем, скорее всего, не будет баг.
2. Чем дольше в тестируемом функционале нет баг, тем больше вероятность того, что они там появятся.
Вывод:
Баги появляются в функционале, в котором нет тестов.
Второй вывод:
Баги появляются, пока на функционал нет тестов.
Главный вывод:
При дальнейшем повышении автоматизации тестирования единственной задачей станет: БЫТЬ ГОТОВЫМ к неисправности автоматики.
Следствие:
Чем надежнее автоматика, облегчающая работу тестировщика, тем тяжелее быть постоянно готовым к её неисправности. Следовательно, чем более облегчается труд тестировщика, тем тяжелее у них работа.

If You're testing through bug nest keep testing.
(типа того)

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

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

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

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

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

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

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

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

вторник, 21 февраля 2012 г.

Пан Анджей

Закончил читать Божьих воинов.
Приступим к следующей книге пана: Свет вечный:
Ой, ой-ой-ой, приближается, уважаемые господа и дорогие слушатели, приближается день гнева, день скорби, день слез. Приближается День Суда и наказания. Как говорится в Послании Иоанна: Antichristus venit, unde scimus quoniam novissima hora est. Идет, идет Антихрист, приходит последнее время. Близится конец света и завершение существования всего…

Другими словами: хреново, блин.


Настоятельно рекомендую, да...

Lesson 74

Почитайте на досуге, интересный текст: http://lomelind.livejournal.com/479554.html#cutid1

Это печально, но я отчетливо - сталкер по той классификации.
Дык, надо что-то менять, штоп стать шаманом. Бубен купить?

Альбом: randompics4lj


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

Сбой — это лишь симптом, а не сама ошибка.

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

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

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

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

Lesson 73

Вот говорят разные высокозаряженные сильноумные дяди - Держи друзей близко, а врагов - еще ближе.

Что-то я не пойму их... Враг - еще ближе?
Это ж, нахер, просто неприятно!
Хотя откуда у меня - и враги? Так, выделываюсь.

Альбом: randompics4lj


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

Различайте понятия критичности и приоритета дефекта.

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

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

воскресенье, 19 февраля 2012 г.

Так

Мой падаван хитрый чувак.

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

Я не знаю, что делать...

суббота, 18 февраля 2012 г.

Вечерний пост

Завтра уберу запись, ибо нефиг. Наверное.

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

Lesson 72

Чините минорные баги! Чините минорные баги, суки!
Как бывший боец техподдержки говорю. Ну и Канер с Пелсом подтверждают.

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

Мелкие баги стоят нам отчетности и исправления.

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

Несколько лет назад, один из нас — Kaner, в сотрудничестве с David Pels исследовали влияние незначительных ошибок на затраты на техническую поддержку. Kaner был менеджером разработки ПО, Pels управлял техподдержкой. Работая с массовым, активно подаваемым продуктом, Kaner и Pels просматривали каждое письмо и email, полученные от клиентов, журнальные обзоры, звонки заказчиков и записи в баг-трекере. Они классифицировали проблему как «дешевую», если она стоит меньше, чем 4 часа(не считая тестирования) на исправление. Исправлением могло быть изменение кода, замена файла драйвера, изменение инструкции пользователя или текста на коробке продукта. До тех пор, пока работа требует меньше, чем 4 часа и препятствует дальнейшим жалобам по этому вопросу, проблема считается «дешевой». В соответствии с этим критерием они пришли к выводу, что «дешевые» исправления незначительных ошибок могли бы предотвратить больше половины звонков в техподдержку. В течении следующего года группа Канера исправила множество подобных проблем и технические затраты на поддержку новых клиентов сократились вдвое. Это не идеальная причинно-следственная связь, так как группа Канера исправила также несколько серьезных ошибок и добавило ряд фич (и дефектов), но было ясно, что в основном на удовлетворенность клиентов повлияла общая чистка. На рынке товар также значительно вырос в том году.

Любой продукт имеет несколько небольших дефектов, но как только их число растет — падает доверие заказчиков. Более тревожным является терпимость, привыкание к таким ошибкам. В тот момент, когда вы прекратите репортить некритичные дефекты (некоторые компании давят на сотрудников, сообщая, «сколько стоят» дефекты), вы и ваша компания окажетесь терпимы и к более серьезным ошибкам. На этом пути находится провал продукта (если вы не являетесь монополистом). Подобная прогрессирующая терпимость к дефектам была важным фактором в катастрофе Challenger, что Richard Feynman наглядно показывает в своей книге What Do You Care What Other People Think (Feynman 89).

Lesson 71

Вы небось подумали что я сдался и слился? Не тут то было, переводим дальше.
Хм, хотя вам могло быть просто пофиг.

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

Скруглите угловатые тесты

Эффективные тесты часто включают в себя граничные значения. Первые ошибки, что вы найдете, скорее всего, будут связаны с ними. Идея их тестирования состоит в том, что если программа смогла пережить экстремальные значения переменной, то она, вероятно, сможет работать и на менее экстремальных значениях. Таким образом, вы могли бы многое узнать, благодаря нескольким экстремальным испытаниям. Например, тестируя поле ввода, принимающее значения от 0 до 999, вы, вероятно, проверите 1, 0, 999, 1000.

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

Предположим, на диапазоне 0-999 программа отказывает на значении 999. Если вы остановитесь на этом результате, многие программисты проигнорируют это(«Кто будет вводить 999? Это наибольшее возможное значение, Оно никому не нужно!»).

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

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

пятница, 17 февраля 2012 г.

Давным-давно

Давным-давно на белом свете жили глупые короли, прекрасные принцессы, страшные лесные разбойники и веселые трубадуры

Пересмотрите, хороший мультик.

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


четверг, 16 февраля 2012 г.

Конференции о тестировании пост

Намедни прошла confetqa

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

Теперь по докладам.

Sikuli – инструмент автоматизации GUI приложений, Игорь Хрол
Игорь таки молодец, в выходные я буду писать фарм бота для онлайн-игрушки. Что касается работы - медленно, стохастично, неэнтЫрпрайзно.

Гибкая система логирования результатов выполнения авто-тестов, Дмитрий Иржов
Гг, Каждый программист должен написать свой xml-парсер, а каждый тестировщик - свой логгер.
Велосипеды не нужны.

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

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

Visual Studio, Coded UI и MS Test Manager: три в одном, Денис Колесников
У вас есть лишние десять штук баксов на инфраструктуру от MS? Вот у нас наоборот, десяти штук баксов как-раз не хватает, да...

Python приправы при готовке Selenium фреймворка на медленном огне, Михаил Поляруш
%&#&ть! При чем тут вообще тестирование? И да, я бы посмотрел, как Михаил поддерживал фреймворк на питоне... не им написаный.

Доклад Д.Жария для меня лично отбил все потраченное время. И это хорошо.

среда, 15 февраля 2012 г.

Ы!

Ололо, Максимко через пару часов вещает.

Пыщ-Пыщ!

http://www.it-people.ru/obrazovatelnye-programmy/otkrytye-seminary-po-sredam/seminar-dlya-testirovshikov-maksim-zakharov-naumen-15-fevralya/

понедельник, 13 февраля 2012 г.

Вечерний пост

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


пятница, 10 февраля 2012 г.

Хаус

Хаус в апреле все.

1
Альбом: randompics4lj

2
Альбом: randompics4lj

3
Альбом: randompics4lj

4
Альбом: randompics4lj

5
Альбом: randompics4lj

6
Альбом: randompics4lj

7
Альбом: randompics4lj

8
Альбом: randompics4lj


Реквестирую новые фильмы с Лори, новую музыку Лори.

четверг, 9 февраля 2012 г.

Радости пост

Ггы, свершилось.

Тестировщики и примкнувшие, собираемсо же!

15 февраля в 19:00, с собой иметь 100 рублей.

Там буду я и Михаил из Абак Пресс, он расскажет как тестировать надо, я - как не надо.
Еще придут ребята из контура и будут внимательно за всем наблюдать.

Фцелом пыщ-пыщ, потусим.

http://www.it-people.ru/obrazovatelnye-programmy/otkrytye-seminary-po-sredam/seminar-dlya-testirovshikov-maksim-zakharov-naumen-15-fevralya/

http://software-testing.ru/forum/topic/21876/