Что пишут в блогах

Подписаться

Что пишут в блогах (EN)

Разделы портала

Онлайн-тренинги

.
Управление людьми и проектами
Управление людьми и проектами, планирование, управление рисками


Парное тестирование: эксперимент по распространению знаний среди Agile-команд
21.07.2016 10:40

Автор: Катрина Клоки

Оригинал статьи: http://katrinatester.blogspot.ru/2015/06/a-pairing-experiment-for-sharing.html

Перевод: Ольга Алифанова

Уже месяц как я провожу эксперимент по парному тестированию в моей компании. Основная его цель – распространить знания между тестировщиками разных команд, занимающихся совершенно разными приложениями и платформами.

Структура эксперимента

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

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

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

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

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

Подробнее...
 
Александр Орлов: Как жить медленно и частями
20.07.2016 12:18

Выступление Александра Орлова на онлайн-конференции для специалистов по ручному тестированию Fun ConfeT&QA.

Из своих почти 9 лет тестирования 9 лет я проработал в распределенных проектах. Поначалу был тестировщиком, потом руководил командами и отделами тестирования. Проекты были разного размера – от 7 до 150 человек, с разными технологиями и количеством тестировщиков в них.

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

Оглянувшись назад и проанализировав свой опыт, удалось сделать несколько выводов о том, как команде тестирования работать в распределенных командах в условиях сверх-медленных коммуникаций. Этими выводами я и хотел бы поделиться.

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

 
Тестерская конфликтология или как вытаскивать «вбитые в голову гвозди»
13.07.2016 10:39

Выступление Сергея Атрощенкова на онлайн-конференции для тест-менеджеров Chief ConfeT&QA.

Давным-давно в нашей галактике шла война между Тестировщиками и Разработчиками.

Императорские офицеры то просили придержать коммит, то задавали провокационные вопросы вроде «А почему критический баг только сейчас завели?!»

Силы повстанцев были слишком малы, чтобы

  • конструктивно объяснить любимым разработчикам их неправоту,
  • выработать совместное отличное решение
  • и радостно разбежаться по своим Татуинам, делать самый лучший софт во всей Вселенной.

Эмоции и неконструктивность мешали проводить дружеские беседы. Вместо того, чтобы решать проблему, стороны начинали решать человеков. Дипломаты затыкались, начинало говорить оружие: пиу, тыдыдыщь, ба-ах, вжжынннн!

Но однажды на далекой (и близкой) планете с одной луной родился человек, который знал, как можно уже вытащить посаженные «занозы» в общении между противоборствующими сторонами, и как постараться не засадить новые. Силу большую чуял он!

Давайте нарушим правило «сам козёл» в многолетней войне за производство качественного ПО.

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

 
Как превратить тест-менеджера в тест-лида
10.07.2016 16:08

Авторы: Пол Симан, Ли Хоукинс, Раджеш Матур (Paul Seaman, Lee Hawkins, Rajesh Mathur).

Оригинал статьи: https://beaglesays.wordpress.com/2016/07/03/transforming-a-test-manager-into-a-test-leader/

Перевод: Ольга Алифанова

Ирония индустрии тестирования заключается в том, что люди, не включенные в тестирование (а также куча народу внутри нее) верят, что тестировать – это очень просто. Нет, некоторые продукты действительно просто тестировать. Они должны соответствовать следующим критериям, например:

  • Простая архитектура
  • Редко используются
  • Не критически важны и от них не зависит чья-то жизнь
  • Не взаимодействуют с другими приложениями или средами, или их взаимодействие и интеграция минимальны
  • Удобство использования и доступность практически не имеют значения и могут иметь баги, которые "не создают проблем тем, чье мнение важно.

Такие приложения обычно бесплатны, или основаны на открытом коде, или идут "в нагрузку" к другим продуктам. Например, возьмем Блокнот – его функциональность минимальна, и он бесплатно поставляется с другими продуктами Microsoft.

Подробнее...
 
SQA Days-19: подборка докладов по развитию команды
05.07.2016 13:47

В конце мая этого года в Санкт-Петербурге прошла конференция SQA Days 19. Записи некоторых выступлений с конференции уже появляются в открытом доступе.

По мере их публикования мы сделаем подборки докладов по основным темам в тестировании.

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

Регулярные оценки в команде тестировщиков, Наталья Руколь, Quality Lab, Москва, Россия


Аудит команды тестирования в сложном проекте, Nikita Syskov, EPAM, Минск, Беларусь



Три инструмента тест-менеджера для работы с людьми, Сергей Атрощенков, EPAM, Санкт-Петербург, Россия



 
Как выжать максимум из команды тестирования с разнообразными навыками
27.04.2016 10:46

Автор: Джастин Рорман (Justin Rohrman)

Оригинал статьи: http://blog.smartbear.com/automated-testing/software-testing-skills/

Перевод: Ольга Алифанова

Типичная команда тестирования – это набор таких разных людей, как бизнес-эксперт, системный программист, пара-тройка технарей-тестировщиков и (иногда) менеджер.

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

Что делать разумному менеджеру в таких случаях? Об этом мы и поговорим.

Подробнее...
 
6 предрелизных вопросов
02.03.2016 14:56

Автор: Джейк Бартлетт (Jake Bartlett).

Оригинал статьи: http://www.ministryoftesting.com/2016/02/6-questions-to-ask-before-releasing-software/

Перевод: Ольга Алифанова

Ваша команда упорно трудилась над итерациями, и потратила кучу времени на разработку новой функциональности. И вот настал тот день, когда все готово к релизу. А действительно ли оно готово?

Как вы определяете, что вы можете выпускать ваше детище в релиз? Кто скажет "Поехали" и махнет рукой? Что именно нужно обязательно сделать перед релизом?

Вы постоянно заботитесь о качестве вашего продукта, и точно также вы должны беспокоиться об улучшении и оптимизации вашей релизной деятельности.

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

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

Чем лучше вы и ваши клиенты готовитесь к релизу, тем счастливее вы станете.

Вот на что стоит обратить внимание, когда релиз не за горами:

Подробнее...
 
Интроверты в Agile
08.02.2016 12:58

Автор: Катрина Клоки (Katrina Clokie)

Перевод: Ольга Алифанова

Оригинал статьи: http://katrinatester.blogspot.ru/2016/01/introverts-in-agile.html

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

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

"Интроверт расходует энергию на разговоры. Экстраверты от разговоров подзаряжаются".

Вот вам пример. Раньше я работала тестировщиком в Agile-команде с двухнедельными Scrum-спринтами. Каждый четверг мы устраивали трехчасовую встречу по планированию спринта (с 9 утра до 12 дня), на которой обсуждались пользовательские истории, ставились задачи, оценивались временные затраты, и утверждался бэклог на спринт.

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

Подробнее...
 
Т-тестировщики и их роль в команде
27.01.2016 11:12

Автор: Роб Ламберт

Ссылка на оригинал статьи: http://thesocialtester.co.uk/t-shaped-testers-and-their-role-in-a-team/

Перевод: Ольга Алифанова.

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

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

Я могу долго продолжать, я задавал массу таких вопросов.

Подробнее...
 
Принципы, а не правила
25.01.2016 11:45

Автор: Иэн МакКоуатт (Iain McCowatt)

Ссылка на оригинал: http://exploringuncertainty.com/blog/archives/1154

Перевод: Ольга Алифанова

Цель тестирования

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

"Обеспечить информированное принятие решений, обнаруживая и делясь своевременной и релевантной информацией о ценности решений и рисках, сопутствующих им".

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

Более того, миссия служит призмой, через которую мы смотрим на мир. Когда нам говорят "делайте так-то", мы вооружаемся своей миссией и спрашиваем, помогут ли эти действия достигнуть нашей цели, в правильном ли направлении мы будем двигаться?

Стив Джобс говорил: "Люди думают, что сконцентрироваться - это сказать "да" той вещи, на которой вы концентрируетесь. Это не так. Это означает, что вы должны сказать "нет" сотне других неплохих идей. Инновация - это умение сказать "нет" тысяче идей". В областях, схожих с тестированием, там, где процесс никогда не может быть полностью завершен, где каждое решение - это риск, подобная концентрация критична для успеха: мы должны быть в состоянии отказаться от вполне разумных предположений (а также от всяких глупостей). Миссия - прекрасный инструмент для исследования предположений и объяснения, почему нет.

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

Однако тут требуется предостережение. Когда вы определяете информационные задачи проекта, легко скатиться в "закрытые" вопросы вроде "Делает ли продукт это?", "Можем ли мы загружать данные?". Самые интересные вопросы, которые необходимо задать, всегда открытые: "Что и когда происходит?", "Сколько времени это займет?", "Сколько пользователей приложение выдержит перед тем, как упасть?". Не ограничивайте себя закрытыми вопросами. Небольшой совет: если вы переформулируете цели тестирования в форме вопросов, следите, что не все из них - закрытые. Задавать открытые вопросы очень важно.

Подробнее...
 



Страница 8 из 12