Сейчас я работаю над экспериментом в парном тестировании, цель которого – донести знания о тестировании до членов Agile-команд в моей организации. Ниже - краткое содержание изученного мной материала про парное тестирование, который будет полезен желающим внедрить эту практику у себя в компании.
Подход к парному тестированию
Парное тестирование – это способ подойти к тест-дизайну путем одновременного тестирования одной и той же функциональности двумя людьми, находящимися рядом друг с другом и постоянно обменивающимися идеями.
Объединяясь в пару, эти люди используют одно и то же устройство для тестирования. Один из них манипулирует клавиатурой (хотя клавиатура может переходить из рук в руки во время сессии), а другой генерирует идеи для тестов, следит за процессом и ведет записи, слушает, задает вопросы, ищет вспомогательные материалы…
Пара должна работать над одной и той же задачей, имеющей общую, четкую, ясную обоим цель. Хоть они и работают вместе, кто-то один берет на себя полноту ответственности. Этот человек может предварительно подготовиться, но лучше, если пара не будет загонять себя в жесткие рамки. Для начала вполне сгодится простой высокоуровневый чек-лист или набор идей для тестов.
Во время парной сессии тестировщики должны много разговаривать – не меньше, чем тестировать – с целью добиться общего понимания, что они, собственно, делают, и что еще важнее – зачем это вообще делается.
После очередной уборки на сервере выяснили, что у нас осталось несколько неопубликованных докладов со старых онланй-конференций. Те доклады, информация в которых еще не устарела постараемся выложить в ближайшее время.
Выступление Алексея Лянгузова на онлайн-конференции для специалистов по тестированию ConfeT&QA.
То о чём я хочу поведать, приемлемо в случае, если тестовая команда параллельно тестирует несколько проектов, с более-менее жёстким распределением по этим проектам. Представьте такой диалог между руководителем тестирования двух проектов А и Б (ЛидА и ГлеБ): ЛидА: Глеб, выручай у нас релиз на носу, нужны бойцы, не успеваем, зашиваемся. ГлеБ: Сколько людей надо? На какое время? Когда? ЛидА: Вчера надо. А сколько дашь? Мне вообще на денек-другой, может на недельку. ГлеБ: На недельку %) Ладно, так, дам тебе Тугодумова, Раздолбаеву и … ЛидА: з-э, только не Раздолбаеву… … Далее либо договорятся, либо придет Босс и скажет кому и куда идти. Знакомо? Я расскажу о своем подходе, как можно минимизировать данный хаос и затраты на переключение между проектами и максимально продуктивно и позитивно использовать тестировщиков, работающих на других проектах. И нет, это не постоянная ротация. Подход называется “Интенсивный Тестовый Цикл” и предлагает спланировать аврал заранее. Как? Об этом я и расскажу. Данный подход опробован не на одном проекте и зарекомендовал себя как работающий и полезный.
Какие инструменты облачного тестинга используют в Яндексе? Как устроено тестирование в Badoo? Что представляет собой система автоматизированного frontend-тестирования в Wrike?
Пару недель назад Wrike Tech club собрал около 150 специалистов по тестированию, чтобы обсудить в питерском офисе компании насущные, вечные и, на первый взгляд, почти неразрешимые проблемы QA в больших (и не очень) проектах.
Ниже видео и презентациями со встречи:
Илья Кудинов (Badoo), «Развитие процессов тестирования в Badoo за три года или как мы думали, что всё хорошо, а оказалось, что можно лучше»
Wrike QA Automated Team «Как устроено автоматическое frontend-тестирование на wrike.com»
Публикуем подборку докладов с SQA Days-18, посвященных построению процессов в тестировании.
Как ужиться с программистами в одном спринте. Или тестирование в SCRUM-команде – доклад Алексея Никитина об управлении тестированием в SCRUM.
Что ждет тестировщиков при организации процесса тестирования Enterprise-продуктов с нуля – доклад Германа Варгина о запуске процесса тестирования в сжатые сроки.
Процесс тестирования. Измерение и оценка – доклад Александра Мешкова об измерении эффективности тестирования.
Практическое пособие по разрушению отдела тестирования – доклад Андрея Мясникова о типичных ошибках при создании отдела тестирования.
Подготовка стратегии тестирования под высокорискованный, высокодоходный проект – доклад Сергея Мартыненко о построении стратегии тестирования для инновационных проектов.
Оценки тестирования - полезные и условные метрики – доклад Таисии Толстуновой о критериях оценки качества работы и полезных метриках.
Новый процесс тестирования на "старом" проекте – доклад Александра Полещука о том, с чего начать при построении процессов на уже существующем проекте.
Основа отдела тестирования. Ценности – доклад Екатерины Гайнутдиновой о создании культуры отдела тестирования.
Наши читатели при регистрации на конференцию могут получить скидку.
Давайте все вместе попытаемся составить далеко не исчерпывающую и даже не полную, но приемлемую, для всех нас приемлемую, классификацию\топологию типов тестирования, начиная «широкими мазками» «статическое» и «динамическое» и заканчивая сложно терминологическими названиями конкретных типов. Скажу честно, по-настоящему хорошей классификации из коробки я так и не нашел … даже в рамках всемирно признанных сертификаций, таких как ISTQB … Таким образом, проделанная нами предварительная работа ценна сама по себе … важная как для начинающих специалистов, так и для Pre-Sales Technical QA консультантов … Основа профессиональной сетки координат любого специалиста по тестированию … Но мы пойдем дальше: через призму совместно сформулированной QA топологии мы посмотрим на методологии разработки ПО, предметно, а не абстрактно, изучим общности и отличия Agile и Waterfall методологий в контексте QA. Уверен, доклад будет полезен не только QA специалистам и PM-ам, но и .... интрига-интрига :-)
Выступление Татьяны Андреевой на онлайн-конференции для специалистов по тестированию Fun ConfeT&QA.
Привычки упрощают нашу жизнь, оставляя больше времени на что-то более полезное, чем обдумывание каждого рутинного дела. Однако у такой удобной штуки есть и обратная сторона: замыленный глаз, усталось от монотонной работы, неполно описанные баги, недопонимание при общении с коллегами. И это не говоря уже о том, что от привычек невероятно сложно избавиться.
Обычно мы думаем о том, как пользователь будет использовать наш продукт, совершенно забывая, кто он такой. Понимание же предпочтений помогло бы лучше расставить приоритеты тестов и багов. Мы привыкли составлять тест-план согласно определённой системе, которая в конкретном случае может что-то пропустить.
Я хочу поделиться идеями того, как можно взглянуть на рутину с другой точки зрения. Я расскажу на примерах из жизни как небольшими изменениями в привычном ходе вещей можно если и не облегчить себе работу, то уж точно сделать её интереснее и увлекательнее.
Доклад Ирины Винокуровой с онлайн-конференции Fun ConfeT&QA.
…Ты приходишь на работу, получаешь новый билд на тестирование, радостно начинаешь тестировать, предвкушая кучу интересных багов… Но что такое? Первая же стандартная проверка, и приложение падает. Затем вторая, третья… Ситуация не меняется.
…В баг-трекере большое количество багов в статусе resolved. С удовольствием начинаешь перепроверять… Так, стоп. Шаги те же, но система падает. Правда, с другой ошибкой. И на немой укор программистом можно услышать: «Ну есть же ты. Ты и перепроверишь»…
…Весь отдел разработки гудит, что в программу вводится новая функциональность. Все программисты кодят так, что дымятся клавиатуры. Но на просьбу дать ТЗ, тебе отвечают, что пока не время…
Когда такие вещи случаются один или два раза, то это можно воспринимать, как досадную случайность. А что, если они постоянны? И стандартные ошибки, и не перепроверка своих же исправлений, и постоянные разговоры об автоматизации…
Но выход есть – объяснить программистам, чем же мы занимаемся на самом деле. С толком, чувством, расстановкой. Чтобы ребята наконец поняли: мы команда. И некоторые вещи надо делать совместно.
О том, что я рассказывала своим программистам про тестирование, как я это делала, и к чему это привело, я постараюсь рассказать в своём докладе.
Выступление Натальи Руколь на онлайн-конференции для тест-менеджеров Chief ConfeT&QA.
Как бы вы ни старались «проверить всё», расширяя отдел или увеличивая сроки, времени на тестирование никогда не хватит.
Именно поэтому настоящие джедаи идут другим путём: они делают всё возможное для отбора в тестирование самых важных, самых необходимых тестов, и при этом – в правильной последовательности. И делают они это быстро, точно, применительно к каждой итерации и в разрезе различных областей функционала и типов тестирования.
Как они это делают? Какие световые мечи используют для победы над пропущенными ошибками и затянутыми сроками?
В этом докладе я расскажу вам о ключевых способах приоритизации тестов:
Анализ по приоритетам
Анализ на основе рисков качества
Карта влияний
Матрица изменений
Благодаря этому докладу вы получите в свой арсенал инструменты быстрого и эффективного планирования тестирования. Да пребудет с вами сила!
Канал Youtube Wrike