Home

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

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

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

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

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

Итак, читаем: Less Is More, или Меньше слов -- больше смысла!

В преддверии конференции DevPoint (Новосибирск, 2 октября), на которой главный редактор портала Software-Testing.RU Алексей Баранцев выступит с докладом «Selenium 2.0: будущее тестирования веб-приложений», а также 3-4 октября проведет два тренинга "Тест-дизайн от А до Я" и "Управление требованиями, тестами, дефектами", он дал интервью организаторам конференции.

В этом интервью Алексей ответил на следующие вопросы:

• Почему вы решили приехать в Новосибирск на конференцию?
• Что вы ждете от DevPoint 2?
• Продолжите фразу: « Я бы удивился (обрадовался), если бы на DevPoint 2...»
• Кому будет интересен ваш мастер-класс?
• Что такого люди могут узнать на вашем мастер-классе, о чем не прочитают в интернете или в какой-нибудь умной книжке?
• Чем планируете заняться в Новосибирске в свободное от конференции время?

Читать интервью

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

И, кстати, раскрою небольшой секрет, не дожидаясь официальной публикации -- во второй день конференции SQA Days 7, которая пройдёт в Харькове 14-15 мая, Саша будет проводить мастер-класс "Конструктивное решение проблем и конфликтов", акцентируя внимание именно на конфликтах между тестировщиками и другими участниками проектов разработки, так что этот кейс можно считать небольшой подготовкой к мастер-классу.

Кейс “Опять двадцать пять”

Максим (руководитель проекта) и Алексей (руководитель группы тестирования) работают в небольшой продуктовой компании.
Однажды вечером между ними состоялся такой диалог.

М: Привет! Слушай, похоже тебе и твоим ребятам придется поработать в субботу. Извини, что сообщаю об этом всего лишь за два дня.
А: Опять? Надо же…
М: Да. Разработчики буквально пару минут назад сообщили мне, что завтра к обеду будет готов билд, в котором будут исправлены все пять оставшихся критичных багов, восемь второго приоритета и еще куча мелких. Всего 27 штук! И это они за 4 дня успели сделать, такого у нас уже давно не было. Они действительно классно поработали. Давай и вы тоже продолжите в том же духе.
А: Мда… они молодцы, конечно. Они сами что-нибудь потестили? Билд хотя бы собирается нормально?
М: Конечно собирается, даром что ли неделю на настройку билдера убили. И юнит-тесты прошли все, хоть их и немного.
А: … да еще и старых.
М: Ну да, старых, но это же все время, ты же в курсе. Каждый из них, конечно же, проверил все пофикшенные баги у себя локально, куда ж без этого. И все было нормально. Но чтоб узнать, как оно все вместе работает, вы нам и нужны. Так ведь? У них на это просто никогда не будет времени, да и не их это задача. Вы же должны обеспечить качество продукта.
А: Хорошо, я могу протестировать продукт, но как обеспечить его качество и качество их чудо-кода… я не знаю.
М: Конечно знаешь. По крайней мере, лучше тебя этого никто тут не знает. Ты же эксперт в таких вещах.

Продолжение кейса и обсуждение в блоге Happy-PM

Автор: Баранцев Алексей

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

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

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

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

И мне было очень приятно увидеть, что одно из ведущих мест среди участников этого проекта занял наш соотечественник, россиянин Вячеслав Ерофеев -- он получил статус Most Valuable Tester (MVT) в проекте:

The Test Manager from ICQ said that it is a pleasure to read his bug reports – his descriptions are very accurate, clear and always contain all the necessary information. In addition, his findings are exceptionally valuable.

Therefore, although in terms of amount of approved bugs he was at the 3^rd place, his reports are considered to be the most contributing to the ICQ2GO product quality.

Кроме того, Вячеславу достался один из трёх призов за лучший баг.

Мы от всей души поздравляем Вячеслава с этим достижением!

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

P.S. К сожалению, uTest не выдаёт данные своих тестировщиков, поэтому мы не сумели пока связаться с Вячеславом, но если он читает эти строки, или если кто-нибудь поможет нам выйти с ним на связь, мы были бы очень рады этому и постарались узнать "из первых рук", каково оно -- работать в "краудсорсинговом" проекте.

Обсудить в форуме

При подготовке к семинару "Функциональное тестирование на основе моделей" из серии онлайн-семинаров по четвергам, я активно использовал лекции Виктора Кулямина, которые он читает уже несколько лет студентам ВМК МГУ.

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

С Виктором мы знакомы с первого курса университета и вместе работаем до сих пор. Но несмотря на то, что он тоже активно занимается тестированием, его имя практически не заметно в наших тестировочных тусовках. Почему? Я уже говорил про этот интересный феномен в интервью, которое давал порталу it4business. Есть большой мир "академического" тестирования, в котором происходит много интересных событий, проводятся конференции, публикуются книги, но этот мир почти не пересекается с миром промышленного тестирования. Почти как волшебники и маглы в книжках про Гарри Поттера :)

Я обещал, что мы постараемся немного раскрыть завесу над миром академического тестирования, поэтому сейчас мы готовим интервью с Виктором. А пока оно ещё не опубликовано, можно читать статьи и набираться ума-разума. Сам я это делаю регулярно :)

Колонка главного редактора

В результате самоотверженного труда Алексея Лупана появилась расшифровка моего выступления на конференции AgileDays-2008 на тему "Каким должно быть приёмочное тестирование в agile-проектах?"

После этой конференции прошёл почти целый год, и уже слегка подзабылись те мысли, которые ворошились у меня в голове, когда я готовился выступать на ней. Поэтому когда я редактировал сейчас этот текст, я испытывал смешанные чувства. Местами я думал – да это же практически гениально, как же я сам до этого не догадался! И только потом вспоминал, что это же мои собственные слова.

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

Надо также помнить, что это живая речь, поэтому местами изложение не очень структурированное (если не сказать сильнее), а кое-где весьма эмоциональное. Надеюсь, что текст сможет передать мои эмоции. А если нет – посмотрите видеозапись.

Читать расшифровку в блоге Алексея Лупана...

Обсудить в форуме