Home

Наш тренер Ольга Киселева подготовила статью в помощь студентам своего онлайн-интенсива для начинающих тестировщиков, описав методику систематического поиска багов по Джеймсу Виттакеру (James A. Whittaker)

Методика туров

Приложение — незнакомый город.

Тестировщик — турист.

Исследуйте ПО так, словно это — незнакомый город

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

Доклад Алексея Баранцева с конференции Fun ConfeT&QA.

Вы нашли баг — но не можете его воспроизвести.
Вы нашли баг, он успешно воспроизводился — но на следующий день больше не можете его воспроизвести.
Вы нашли баг, он успешно воспроизводится — но только на вашей машине, а на других всё работает нормально.
Вы нашли баг, он успешно воспроизводится — но только не на машине разработчика и он не может пофиксить его.
Вы нашли баг, он успешно воспроизводился, и вот сам собой исчез, хотя разработчики говорят, что ничего не исправляли.
Знакомо? Наверняка.
Что делать в таких ситуациях?
Писать в баг-трекер или не писать?
А был ли баг вообще? Поверят ли вам?
Сколько времени потратить на попытки воспроизвести хитрый баг?
Я расскажу вам свои правила и маленькие хитрости, как действовать в этих случаях.

Автор: Киселева Ольга, автор и ведущий тренинга Онлайн-интенсив для начинающих тестировщиков.

Тест-кейс — это проверка. "Выполни тест-кейс по вводу отрицательных значений" = проведи проверку такую-то и проверь, что результат будет такой-то.
Устоявшегося русско-язычного определения нет, помните об этом. Главное — понимать суть.

Тест-кейс — это такое описание проверки работы системы, которое может выполнить любой человек из команды, будь то тестировщик, разработчик, аналитик или даже бизнес-заказчик.

Набор тест-кейсов называется тестовым набором (test suite).
Иногда этот набор некорректно называют тест-планом. Тест-план —  это именно план: когда, что, зачем, какими ресурсами. (тут будет ссылка на статью про тест-план)

Стандартные атрибуты тест-кейса

1. Номер —  уникальный идентификатор тест-кейса. Его удобно использовать для одинакового понимания, о какой проверке идет речь (например, дать ссылку в баге).
2. Название — краткое описание сути проверки. Должно помещаться в твиттер и быть понятным! Кратко, но емко.
3. Предварительные шаги —  описание действий, которые необходимо выполнить, но прямого отношения к проверке они не имеют (например, зарегистрироваться в системе для проверки создания элемента). Если предварительных шагов нет, то секция не заполняется.
4. Шаги — описание действий, необходимых для проверки (например, создание элемента).
5. Ожидаемый результат (ОР) — сама проверка: что мы ожидаем получить после выполнения шагов ("Элемент создан").

Запись доклада Андрея Кузьмичева на онлайн-конференции Fun ConfeT&QA, весна 2012.

От некоторых своих коллег я слышал, что success stories это скучно и не интересно. Я расскажу про fail`ы в то время как я был джуниором именно глазами джуниора.

Иногда я себе, а иногда мне друзья/коллеги задавали, например следущие вопросы:

• Почему я должен работать когда остальные балду пинают? / А почему они вообще балду пинают?
• Почему я должен ехать на конференцию за свой счет?
• Что надо чтобы начать постить баги? / Что надо чтобы ваши джуниоры начали постить баг.
• В какую сторону развиваться? / В какую сторону развивать
• Сколько я стою? / Как не потерять талантливого джуниора
• Чего я ещё не знаю?

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

Запись доклада Рины Ужевко, который по результатам зрительского голосования был признан одним из лучших и поделил второе-третье место на Fun ConfeT&QA.

Пост на эту тему в блоге Рины.

В своем докладе я расскажу о видах “ловушек”, которые мы строим себе сами . Причем делаем это, зачастую, неосознанно.
Казалось бы, какой вред может быть от увлеченного работой или учебой тестировщика? Или в обращении к коллегам за помощью? Причем, вред не только себе, а и компании?
А он есть! Ведь то, что сверх меры,— всегда от лукавого. А мне, как тестировщику игрового ПО, очень часто приходилось сталкиваться с “ловушкой” увлечения работой. Ведь так сложно ощутить грань между “тестированием играючись” и “играючи тестируем”. Этой и другими “ловушками” , в которые довелось попасться мне самой или моим коллегам, я и поделюсь с вами.

Я расскажу о том:

• Как распознать “ловушку” вовремя,
• Дам советы обхода,
• Подскажу как спастись самостоятельно, если уже “попались”.

Доклад будет полезен как начинающим, так и “гуру” тестировщикам. (для них у меня тоже припасена “ловушка”)

А Вы уверены, что еще не попались?

Автор: Наталья Руколь

Многие считают, что тестирование ПО — это поиск ошибок. Иногда я говорю тестировщикам: «не старайся найти как можно больше ошибок, старайся пропустить как можно меньше!», и меня не понимают: а в чём разница?

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

Традиционно мы публикуем выступления уже достаточно опытных и «умудренных годами» тестировщиков. Но сегодня решили немного отойти от стандартов и опубликовать выступление начинающего тестировщика – Софии Костюченко «Исследовательское тестирование. Как это было».

Чем может быть интересно это выступление?

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

Во-вторых, подготовлено оно совсем начинающим тестировщиком – поверите ли вы после просмотра, что на момент этого выступления опыта в тестировании у Софьи было … всего 2 месяца, а опыта выступлений не было вовсе? Правда, это были 2 месяца обучения на Курсе практического тестирования и Софья стала там одним из лучших выпускников. Сейчас Соня работает джуниор тестировщиком, продолжает учиться на 4 курсе физического факультета и (уверены) обязательно выступит где-нибудь еще.

Считаете ли вы себя квалифицированным тестировщиком?

Знаете ли вы, куда вам развиваться дальше и как это делать?

Если ответ «да», то мы за вас очень рады!

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

Есть что добавить? Поделитесь, и мы улучшим эту презентацию!

Автор: Андрей Мясников

Вместо предисловия.

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

“Whysoseriously?”
Joker.

Джокер.

Когда-то давно из колоды я вытянул джокер.

Нет, я не увлекаюсь азартными играми и вообще отвратительно играю в карты.

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

«А что?» - думал я, - «Работенка непыльная, знаний много не надо. Того, что у меня есть, вполне хватит». Хахаха. Три раза. Три месяца испытательного срока я въезжал в то, что я «знаю», учился привязывать это к реальности и применять на практике.

Потом работал и получал удовольствие. Был доволен собой и думал, что вот теперь-то меня похвалят за хорошую работу. Но почему-то не хвалили.

Я думал, что я просто ещё мало работаю, чтобы меня заметили. Впахивал, нередко задерживаясь допоздна, и похохатывал надо коллегами, которые ездили на какие-то тренинги и изучали новые инструменты и методики. Нафига? Ведь я и так справляюсь и могу выполнять свою работу пусть не на 5+, но на твердую четверку точно.

Компания платит деньги, я работаю – все довольны.

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