Рейтинг
+7.19
голосов:
6
avatar

Размышления о тестировании  

О предположениях и основанных на них решениях, часть 2

Продолжу рассуждения о том, какие решения мы формулируем в отчётах о тестировании, какие предположения лежат в их основе, и как убедить читателя отчёта в том, что мы приняли правильные решения (если, конечно, мы сами в этом уверены :)).

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

Вот что написано в отчёте:

  • «Мы протестировали продукт на операционной системе Windows XP SP2»

А вот то, что там не написано:
( Читать дальше )

О предположениях и основанных на них решениях

Недавно послушал подкаст Джеймса Баха и Джона Баха "Testers say the darndest things", в котором они рассуждали о том, как научить тестировщиков точно, технично и правдиво объяснять, что они делают и чего они сделать не могут.

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

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

Тестирование по-русски

Вчера принимал участие в новом проекте uTest.com, в общих чертах — тестирование локализованных версий некоего мобильного приложения. Участие принимали три человека из России, два из Израиля, два из Германии, три из Чехии. По условиям заказчика нужно было пройтись по уже составленным тестовым сценариям, за это обещалась сумма, сравнимая с оплатой пяти рабочих часов тестировщика в СПб. Результаты тестирования, как обычно, доступны всем.

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

Кто должен закрывать баг в баг-трекере?

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

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

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

Зачем изучать чужие ошибки?

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

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

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

Билды ручной сборки

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

Разоблачение парадокса о том, что хорошее тестирование ухудшает качество (продолжение)

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

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

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

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

Посчитай-ка мне мячики, сынку...

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

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

Активные и пассивные действия

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

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

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

Разоблачение парадокса о том, что хорошее тестирование ухудшает качество

Орехи и скорлупки.
Отгадка

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

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

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