Запись доклада Андрея Кузьмичева на онлайн-конференции Fun ConfeT&QA, весна 2012.
От некоторых своих коллег я слышал, что success stories это скучно и не интересно. Я расскажу про fail`ы в то время как я был джуниором именно глазами джуниора.
Иногда я себе, а иногда мне друзья/коллеги задавали, например следущие вопросы:
- Почему я должен работать когда остальные балду пинают? / А почему они вообще балду пинают?
- Почему я должен ехать на конференцию за свой счет?
- Что надо чтобы начать постить баги? / Что надо чтобы ваши джуниоры начали постить баг.
- В какую сторону развиваться? / В какую сторону развивать
- Сколько я стою? / Как не потерять талантливого джуниора
- Чего я ещё не знаю?
Возможно, что для кого-то ответы на них очевидны, я расскажу какие ответы на эти и другие вопросы нашел я. Может я и не открою для вас что-то новое, но я надеюсь, что у вас будет над чем задуматься.
Автор: Киселева Ольга, автор и ведущий тренинга Онлайн-интенсив для начинающих тестировщиков.
Тест-кейс — это проверка. "Выполни тест-кейс по вводу отрицательных значений" = проведи проверку такую-то и проверь, что результат будет такой-то.
Устоявшегося русско-язычного определения нет, помните об этом. Главное — понимать суть.
Тест-кейс — это такое описание проверки работы системы, которое может выполнить любой человек из команды, будь то тестировщик, разработчик, аналитик или даже бизнес-заказчик.
Набор тест-кейсов называется тестовым набором (test suite).
Иногда этот набор некорректно называют тест-планом. Тест-план — это именно план: когда, что, зачем, какими ресурсами. (тут будет ссылка на статью про тест-план)
Стандартные атрибуты тест-кейса
- Номер — уникальный идентификатор тест-кейса. Его удобно использовать для одинакового понимания, о какой проверке идет речь (например, дать ссылку в баге).
- Название — краткое описание сути проверки. Должно помещаться в твиттер и быть понятным! Кратко, но емко.
- Предварительные шаги — описание действий, которые необходимо выполнить, но прямого отношения к проверке они не имеют (например, зарегистрироваться в системе для проверки создания элемента). Если предварительных шагов нет, то секция не заполняется.
- Шаги — описание действий, необходимых для проверки (например, создание элемента).
- Ожидаемый результат (ОР) — сама проверка: что мы ожидаем получить после выполнения шагов ("Элемент создан").
Доклад Алексея Баранцева с конференции Fun ConfeT&QA.
Вы нашли баг — но не можете его воспроизвести.
Вы нашли баг, он успешно воспроизводился — но на следующий день больше не можете его воспроизвести.
Вы нашли баг, он успешно воспроизводится — но только на вашей машине, а на других всё работает нормально.
Вы нашли баг, он успешно воспроизводится — но только не на машине разработчика и он не может пофиксить его.
Вы нашли баг, он успешно воспроизводился, и вот сам собой исчез, хотя разработчики говорят, что ничего не исправляли.
Знакомо? Наверняка.
Что делать в таких ситуациях?
Писать в баг-трекер или не писать?
А был ли баг вообще? Поверят ли вам?
Сколько времени потратить на попытки воспроизвести хитрый баг?
Я расскажу вам свои правила и маленькие хитрости, как действовать в этих случаях.
Наш тренер Ольга Киселева подготовила статью в помощь студентам своего онлайн-интенсива для начинающих тестировщиков, описав методику систематического поиска багов по Джеймсу Виттакеру (James A. Whittaker)
Методика туров
Приложение — незнакомый город.
Тестировщик — турист.
Исследуйте ПО так, словно это — незнакомый город
У туриста мало времени, поэтому он выполняет конкретную задачу, ни на что другое не отвлекаясь. Он бегает по казино, или осматривает достопримечательности, или посещает деловой семинар. Что угодно, но что-то одно.
Автор: Ольга Киселева, тренер курса Онлайн-интенсив для начинающих тестировщиков
У тестировщика миллион способов завести баг так, чтобы разработчики на него забили. Учитесь ставить такие задачи, которые будут исправлять.
1. Выберите тип
Разработчики не боги, они не могут делать все и сразу. Им нужно понимать, с чего начинать. Они сортируют задачи по типу — сначала новые функции, потом ошибки, потом все остальное.
Какие бывают типы задач:
- Баг — ошибка в программе.
- Улучшение — все ок, но хотим с перламутровыми пуговицами.
- Новая разработка — такой возможности нет, а очень хочется.
Допустим, заказчик захотел новую возможность, а вы завели ее не как новую возможность, а как баг. Разработчики весь месяц делали другие новые функции, и до вашей не добрались. Заказчик в ярости: вы же обещали... А виноват постановщик задачи — умей выбирать тип!
Автор: Киселева Ольга
Когда начинающие тестировщики впервые сталкиваются с оформлением чек-листа, они впадают в ступор — какой должен быть результат?
Верный гугл говорит — “О, зацени, как все просто!”:
Давайте попробуем применить на практике! Напишем чек-лист для регистрации на сайте https://dadata.ru/.
Подробнее...
Автор: Ольга Алифанова
Наиболее распространенный подход к определению серьезности бага в той или иной формулировке встречается в большинстве источников. Например, у Романа Савина:
-
Критическая – системный сбой, потеря данных, проблемы с безопасностью.
-
Значительная – зависание, блокирование использования, кодирования, тестирования
-
Умеренная – функциональные проблемы
-
Низкая – косметические проблемы
Автор текста: Баранцев Алексей
Бориз Бейзер описал "парадокс пестицида" в своей книге "Software Testing Techniques", вышедшей ещё в далёком 1983 году. Он попытался провести аналогию между повторным выполнением тестов и повторной обработкой полей тем же пестицидом, который уже применялся недавно. После первой обработки часть вредителей погибла, но не все -- некоторые выжили, потому что их организм оказался устойчив к яду. Так вот эти "счастливчики" с большой вероятностью переживут и повторную обработку. Точно так же, утверждал доктор Бейзер, повторное применение одних тех же тестов, и даже повторное применение одних и тех же методов тестирования, приводит к тому, что в программе остаются дефекты, против которых эти методы неэффективны.
С тех пор прошло уже почти 20 лет, большинство тестировщиков прекрасно знает, что такое "парадокс пестицида". И тем не менее, консультируя самые разные компании, и большие, и маленькие, я регулярно сталкиваюсь с одной и той же ситуацией:
- У нас много регрессионных тестов, нам не хватает времени на то, чтобы их все выполнить, может быть их автоматизировать?
- Может быть. Но сначала скажите, эти тесты часто обнаруживают дефекты?
- Да практически никогда! Поэтому и хотим автоматизировать.
- А новые тесты в этот набор часто добавляются?
- Только по дефектам, которые пользователи нашли.
- То есть пользователи в этих модулях обнаруживают дефекты, а тесты их не обнаруживают?
- Ну-у-у, да...
- А почему?
- ??? (молчание) ... (понимание) Так это же парадокс пестицида!!!!
И всё, работа закипела, сразу стало понятно, что половину тестов надо просто выкинуть, половину оставшихся выполнять один раз на десять итераций, и только небольшую часть действительно стоит автоматизировать, потому что если пестицид перестать применять совсем, баги снова разведутся. И теперь, когда старых тестов осталось так мало и освободилась масса времени, можно вспомнить о том, что тестировщик -- это не биоробот, а творец и исследователь, и применить все свои знания о том, как проектировать тесты, чтобы найти новые баги раньше, чем это сделают наши пользователи.
Коллеги, оставьте ненужный хлам в старом году, а в новом году добавьте разнообразия в свою жизнь! Скачать плакат для печати в pdf формате.
Давно хотели поделиться с нашими читателями ссылкой на запись специального вводного семинара "Тестирование программного обеспечения: основные понятия".
Этот семинар мы бесплатно даем всем слушателям онлайн-семинаров Алексея Баранцева, чтобы они могли познакомиться с ним перед прослушивание онлайн-семинара, т.к. он представляет собой общую вводную часть ко всем остальным семинарам серии, в нём излагаются некоторые общие вещи, чтобы не повторять их каждый раз в начале каждого семинара.
В этом семинаре Алексей рассказывает свою точку зрения на то, что такое тестирование, а также рассматривает три основные классификации видов тестирования, чтобы объяснить свою трактовку различных терминов.
Посмотреть отзывы о прошедших онлайн-семинарах
Запись доклада Рины Ужевко, который по результатам зрительского голосования был признан одним из лучших и поделил второе-третье место на Fun ConfeT&QA.
Пост на эту тему в блоге Рины.
В своем докладе я расскажу о видах “ловушек”, которые мы строим себе сами . Причем делаем это, зачастую, неосознанно.
Казалось бы, какой вред может быть от увлеченного работой или учебой тестировщика? Или в обращении к коллегам за помощью? Причем, вред не только себе, а и компании?
А он есть! Ведь то, что сверх меры,— всегда от лукавого. А мне, как тестировщику игрового ПО, очень часто приходилось сталкиваться с “ловушкой” увлечения работой. Ведь так сложно ощутить грань между “тестированием играючись” и “играючи тестируем”. Этой и другими “ловушками” , в которые довелось попасться мне самой или моим коллегам, я и поделюсь с вами.
Я расскажу о том:
- Как распознать “ловушку” вовремя,
- Дам советы обхода,
- Подскажу как спастись самостоятельно, если уже “попались”.
Доклад будет полезен как начинающим, так и “гуру” тестировщикам. (для них у меня тоже припасена “ловушка”)
А Вы уверены, что еще не попались?
|
