Перейти на страницу опроса.

Попытка вставки формы опроса непосредственно на эту страницу завершилась факапом.

Я в курсе того, что вопрос кажется странным. но на одном ресурсе (потом укажу) обсуждение этого вопроса уже собрало 160 комментариев, и спор только разгорается…

Я хочу развить высказанную Алексом Сергеевым тему «осмысленности» заметок с описанием багов.

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

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

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

Привет, коллеги!
Давненько не писал ничего — был в отпуске. Сейчас предстоит еще небольшой перерыв в общении в данном сообществе — подготавливаюсь к докладу на грядущих SQA Days 6 (в рамках SECR 2009). Но тем не менее, начатую работу надо закончить, поэтому закончу опровергать свою же статью "Парадокс: Хорошее тестирование ухудшает качество."

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

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

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

А вот теперь поехали! ( Читать дальше )

Дано:

1. видеоролик,
2. минута и восемь секунд.

Вопрос: сколько раз в этом ролике парни в белой форме мячики пасуют?

( Читать дальше )

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

Но начать мне хотелось бы с одной правдивой истории из своей практики.

Однажды мне пришлось выступать в роли независимого арбитра при проведении приёмо-сдаточных испытаний. Заказчик принимал очередную версию системы у разработчика-аутсорсера, и ситуация уже до начала приемо-сдаточных испытаний была достаточно напряжённая. Со стороны заказчика должны были присутствовать специалисты из отдела маркетинга, для которых и была разработана система. «Маркетологи» торопили, требовали поскорее сдать систему, потому что им уже надо. И они даже были готовы мириться с наличием незначительных дефектов в системе. Разработчики тоже стремились сдать систему поскорее, что вполне понятно. Но согласно правилам система должна была успешно пройти приёмо-сдаточные испытания. ( Читать дальше )

Здравствуйте коллеги.

Кто-нибудь мог подумать что я в серьёз думаю, что хорошее тестирование способно ухудшить качество ПО. Смею вас заверить: я так не думаю.
Давайте разбираться почему же такой парадокс кажется возможным.

Для начала посмотрим на приведенный показатель качества. Отношение починеных дефектов к общему числу найденых. Если у нас найдено 100 дефектов, а починено из них 50 — это лучше, чем найдено 100 и починено 25 и хуже чем ситуация, когда найдено 100, а исправлено 75 из них. Все логично, такую метрику можно использовать как показатель качества.
А вот и нет! Не является это показателем качества. Почему?
( Читать дальше )

Знаете какими качествами должен обладать тестировщик? Я вот не знал… Но сегодня, разгребая логи своего сайта, неожиданно для себя уяснил, что тестировщик должен быть:

( Читать дальше )

Попался мне на глаза pdf от компании LogiGear.com "The continuing evolution of software testing.pdf", в котором в принципе рассказывается о том, как спецы LogiGear пришли и автоматизировали все и вся с 0% до > 90%, и теперь у их клиентов все идет отлично.

         Файл находится на моем сервере только потому, что на его "домашнем" для скачивания файла нужно заполнить форму «для знакомства».

Местами интересен соус, под которым все это подано — грядет эра “Software Testing 3.0”, которая, очевидно, заменит текущую эру “Software Testing 2.0”.

( Читать дальше )

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

Казалось бы — это «дутье» на воду? А вот пробовал ли человек, с таким подходом, подойти к программисту и спросить: а тут программа вообще может упасть, скажи мне честно? В большинстве случаев ответ удивит. Сильно удивит.
Программистов, уверенных на 100% что у них ни при каких условиях не может появиться ошибки, не рассматриваю, не видел я таких, или условия просто умею предлагать, которые может и не реальны с точки зрения программы, но часть кода с ними, конечно же упадет =).
К коллегам девелоперам всегда можно найти подход, для получения релевантной информации.

к чему это я? Пересматривал Дилберта… и наткнулся: