Управление процессом тестирования ПО

Содержание

Слайд 2

АВТОРСКИЙ КОЛЛЕКТИВ

Вячеслав Панкратов
http://pankratov.org.ua/
Дмитрий Лысенко
http://dmitrylysenko.info/

Тест-дизайн

АВТОРСКИЙ КОЛЛЕКТИВ Вячеслав Панкратов http://pankratov.org.ua/ Дмитрий Лысенко http://dmitrylysenko.info/ Тест-дизайн

Слайд 3

Расписание тренинга

День 1:
Основы тестирования и обеспечения качества, обзор ролей и артефактов тестирования
Тест-дизайн
Автоматизация

Расписание тренинга День 1: Основы тестирования и обеспечения качества, обзор ролей и
тестирования ПО
Тестирование производительности ПО
День 2:
Организация основных процессов тестирования
Тест-менеджер: задачи, ответственность
Коллеги, подчинённые, руководство
Риски: как начать
Управление временем, организация работ

Тест-менеджмент

Слайд 4

Содержание

Знакомимся и проясняем ожидания
Определение тестирования ПО и качества информационных систем: чем мы

Содержание Знакомимся и проясняем ожидания Определение тестирования ПО и качества информационных систем:
всё-таки занимаемся?
Цели и задачи тестирования ПО
Уровни и этапы тестирования
Организация работы с дефектами
Обзор задач, ролей и артефактов в тестировании
Тест-дизайн
Автоматизация тестирования ПО
Тестирование производительности

Тест-менеджмент

Слайд 5

Содержание

Работа с рисками: как начать это дело?
Успешное управление: эффективность
Работа с подчиненными
Работа

Содержание Работа с рисками: как начать это дело? Успешное управление: эффективность Работа
с руководством, коллегами и заказчиками
Управление задачами с использованием модели FACT и др.
Правильное управление своим временем

Тест-менеджмент

Слайд 6

Качество Продукта
Процесс производства ПО
Связь: Качество-Процесс-Продукт
Тестирование ПО: как продать тестирование, миссия, фокус усилий

Базовые

Качество Продукта Процесс производства ПО Связь: Качество-Процесс-Продукт Тестирование ПО: как продать тестирование,
понятия

Тест-менеджмент

Слайд 7

Качество Продукта

Что такое Качество Продукта
Функциональность, Надежность, Производительность
Функциональность — делает ли приложение то,

Качество Продукта Что такое Качество Продукта Функциональность, Надежность, Производительность Функциональность — делает
что от него требуется
Надежность — работает ли приложение без сбоев, «зависаний» или вызова исключений
Производительность — работает ли приложение с приемлемой скоростью при доступе к нему многих пользователей

Тест-менеджмент

Слайд 8

Корни и ветки дерева качества

Откуда берется Качество?
Качество Продукта определяется только Качеством Процесса

Корни и ветки дерева качества Откуда берется Качество? Качество Продукта определяется только
его разработки
Качество Процесса определяется только Уровнем Культуры разработки в Компании

Тест-менеджмент

Слайд 9

Как продать Качество?

Типичные проблемы с «продажей» качества:
Неочевидность возврата инвестиций
Большой первоначальный объем работ:

Как продать Качество? Типичные проблемы с «продажей» качества: Неочевидность возврата инвестиций Большой
обзоры, инструменты, обучение
Хорошую работу не видно!

Тест-менеджмент

Слайд 10

Тестирование ПО: истоки

Первый баг
09.09.1945г. Грейс Мюррей Хоппер (Grace Murray Hopper)

Тест-менеджмент

Тестирование ПО: истоки Первый баг 09.09.1945г. Грейс Мюррей Хоппер (Grace Murray Hopper) Тест-менеджмент

Слайд 11

Эволюция представлений о тестировании

Проверка соответствия между реальным поведением программы и ее ожидаемым

Эволюция представлений о тестировании Проверка соответствия между реальным поведением программы и ее
поведением на конечном наборе тестов, выбранном определенным образом. [IEEE Guide to Software Engineering Body of Knowledge, SWEBOK, 2004]
Техническое исследование программы для получения информации о ее качестве с точки зрения определенного круга заинтересованных лиц. [С. Kaner, 1999]
Это не действие. Это интеллектуальная дисциплина, имеющая целью получение надежного программного обеспечения без излишних усилий на его проверку. [B. Beizer. Software Testing Techniques, Second Edition. NY:van Nostrand Reinhold, 1990]
Процесс наблюдения за выполнением программы в специальных условиях и вынесения на этой основе оценки каких-либо ее аспектов. [ANSI/IEEE standard 610.12-1990: Glossary of SE Terminology. NY:IEEE, 1987]
Процесс выполнения программы с намерением найти ошибки. [Г.Майерс. Надежность программного обеспечения. М:Мир, 1980]

1980

1987

1990

1999

2004

Тест-менеджмент

Слайд 12

Определение тестирования (классика)

Глен Маерс:
Тестирование это процесс выполнения программ с намерением найти ошибки
Пол

Определение тестирования (классика) Глен Маерс: Тестирование это процесс выполнения программ с намерением
Йоргенсен:
Тестирование сфокусировано на ошибках и сбоях. Тест – выполнение действий над ПО с целью найти ошибки или продемонстрировать работоспособность

Тест-менеджмент

Слайд 13

Расширенное определение Тестирования

Обобщенное определение тестирования
Тестирование – процесс проверки соответствия заявленных к продукту

Расширенное определение Тестирования Обобщенное определение тестирования Тестирование – процесс проверки соответствия заявленных
требований и реально разработанной функциональности
Преимущества
Фокус процесса тестирования смещен в сторону проверки требований

Тест-менеджмент

Слайд 14

Уточнённое определение Тестирования

Уточним определение
Тестирование – процесс проверки соответствия заявленных к продукту требований

Уточнённое определение Тестирования Уточним определение Тестирование – процесс проверки соответствия заявленных к
и реально реализованной функциональности, осуществляемый путем наблюдения за его работой в искусственно созданных ситуациях и на ограниченном наборе тестов, выбранных определенным образом

Тест-менеджмент

Слайд 15

Задачи тестирования

Задачи тестирования намного шире чем поиск дефектов!
Типичные вопросы, с которыми сталкиваются

Задачи тестирования Задачи тестирования намного шире чем поиск дефектов! Типичные вопросы, с
группы тестирования:
Сколько ошибок мы нашли? N – это много или мало?..
Почему наши пользователи находят ошибки, если мы потратили на тестирование столько времени?!
Мы нашли N ошибок – мы можем остановить тестирование?
А как будет себя вести наше приложение в эксплуатации?..

Тест-менеджмент

Слайд 16

Как продать Тестирование

Тестирование ПО занимает от 30% до 50% от всей стоимости

Как продать Тестирование Тестирование ПО занимает от 30% до 50% от всей
разработки, в случаях сложных инфраструктурных проектов до 80%
(!) Продукты Microsoft: на 1 разработчика 2 тестировщика
Тестирование не только процесс контроля, но и мощный инструмент разработки, который позволяет достичь определенного уровня качества
>>

Тест-менеджмент

Слайд 17

Как ещё продавать Тестирование?

Основная цель тестирования – достижение заданного уровня качества продукта
Тестирование

Как ещё продавать Тестирование? Основная цель тестирования – достижение заданного уровня качества
может не только выявлять и определять дефекты, но и предотвращать их
Тестирование становится процессом, эффективность которого кардинально влияет на стоимость Продукта и Сроки его выхода на рынок

Тест-менеджмент

Слайд 18

Стоимость исправления ошибок

Миссия тестирования – снизить стоимость разработки путем раннего обнаружения дефектов;
Миссия

Стоимость исправления ошибок Миссия тестирования – снизить стоимость разработки путем раннего обнаружения
тестирования – отправная точка при продаже качества

Тест-менеджмент

Слайд 19

По степени детализации
По подходу к тестированию

Классификация тестирования

Тест-менеджмент

По степени детализации По подходу к тестированию Классификация тестирования Тест-менеджмент

Слайд 20

Практические соображения

Одна из задач менеджера – развитие компетенции персонала
Даже если вы уверены,

Практические соображения Одна из задач менеджера – развитие компетенции персонала Даже если
что все знают как правильно называется тот тип тестов, который они выполняют, занесите это в базу знаний ☺
Думая над задачей «следующей ступеньки» для подчинённых – думайте про «горизонтальное развитие»

Тест-менеджмент

Слайд 21

Уровень готовности: модули, Unit

Модульный уровень
Тестирование целостности кода на уровне логических модулей
Выполняется разработчиками
Контролируется

Уровень готовности: модули, Unit Модульный уровень Тестирование целостности кода на уровне логических
группой тестирования с помощью инструментов анализа покрытия кода unit-тестами (unit test coverage tools)

Тест-менеджмент

Слайд 22

Уровень готовности: отдельные части

Интеграционный уровень
Тестирование промежуточных результатов интеграции системы
Выполняется разработчиками и тестировщиками
Возможны

Уровень готовности: отдельные части Интеграционный уровень Тестирование промежуточных результатов интеграции системы Выполняется
подходы «сверху вниз» и «снизу вверх»

Тест-менеджмент

Слайд 23

Уровень готовности: собранная система

Системный уровень
Проверка полностью построенной системы на соответствие сформулированным требованиям
Подуровни:
Альфа-тестирование
Бета-тестирование
Приемочное

Уровень готовности: собранная система Системный уровень Проверка полностью построенной системы на соответствие
тестирование

Тест-менеджмент

Слайд 24

Уровень готовности: система

System level уровни
Альфа-тестирование
Выполняется группой тестирования внутри команды/организации разработки
Бета-тестирование
Выполняется группой тестирования

Уровень готовности: система System level уровни Альфа-тестирование Выполняется группой тестирования внутри команды/организации
в среде дружественно настроенных клиентов
Приемочное тестирование
Выполняется заказчиком с целью определить, будет ли система принята в эксплуатацию
(!) Выполняется группой тестирования с целью определить, будет ли система принята в тестирование (smoke testing)

Тест-менеджмент

Слайд 25

Как тестируем: снаружи

Классификация по применяемому подходу
Black box (Functional) Testing
Тестирование с точки зрения

Как тестируем: снаружи Классификация по применяемому подходу Black box (Functional) Testing Тестирование
конечного пользователя
Часто комбинируется с методиками «белого ящика»
Наиболее распространенные методики тестирования для user-oriented систем и приложений

Тест-менеджмент

Слайд 26

Как тестируем: изнутри

White box (Structural) Testing
Анализ приложения на уровне кода
Подвиды:
Ручное (экспертное тестирование

Как тестируем: изнутри White box (Structural) Testing Анализ приложения на уровне кода
кода)
Автоматизированное тестирование инструментами статического анализа
Один из наиболее «дорогостоящих» методов тестирования, требующий квалификации высокого уровня

Тест-менеджмент

Слайд 27

Как тестируем: «умные руки»

Grey box testing («серый» ящик)
Смешанная методика, применяемая опытными тестировщиками

Как тестируем: «умные руки» Grey box testing («серый» ящик) Смешанная методика, применяемая
или разработчиками при отладке кода
Тестирование с применением знаний о коде приложения и подробностей реализации функциональности

Тест-менеджмент

Слайд 28

Работа с требованиями – почему не все это умеют и могут делать
Расчёт

Работа с требованиями – почему не все это умеют и могут делать
трудоёмкости – сила методов тест-дизайна
Миф про «универсального тестировщика»

Тест-анализ и тест-дизайн

Тест-менеджмент

Слайд 29

Что было написано в требовании

Тест-менеджмент

SRS-01 (до изменения)
Форма регистрации нового пользователя в системе

Что было написано в требовании Тест-менеджмент SRS-01 (до изменения) Форма регистрации нового
“InfoSecurityManagement” позволяет вводить в реестр пользователей данные о пользователе и его роли:
Имя,
Доменное имя,
Должность,
Полномочия в системе

Слайд 30

Что изменилось в требовании

Тест-менеджмент

SRS-01.1 (после изменения)
Форма регистрации нового пользователя в системе “InfoSecurityManagement”

Что изменилось в требовании Тест-менеджмент SRS-01.1 (после изменения) Форма регистрации нового пользователя
позволяет вводить в реестр пользователей данные о пользователе и его роли:
Имя,
Доменное имя,
Должность,
Полномочия в системе
Если такой пользователь уже существует в реестре системы “InfoSecurityManagement”, на форме ввода появляется его E-mail адрес.

Слайд 31

Практический кейс

Что должно произойти в тест-кейсах?
Кто это должен сделать?
Когда это может происходить?
Вы

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

Тест-менеджмент

Слайд 32

Как часто бывает и что с этим делать

Пример нетестируемого требования производительности ПО
Время

Как часто бывает и что с этим делать Пример нетестируемого требования производительности
отклика системы должно находиться в приемлемых рамках
Время отклика (Отклика на какой операции?) системы (что такое система в этом требовании: UI, DB, client + server + network?) должно находиться (Условия? Нагрузка?) в приемлемых рамках (Цифры?)

Тест-менеджмент

Слайд 33

Первое уточнение

Пример тестопригодного требования
Время отклика системы с точки зрения конечного пользователя (end-to-end)

Первое уточнение Пример тестопригодного требования Время отклика системы с точки зрения конечного
во время продуктивной нагрузки (50 пользовательских сессий в режиме «менеджер» / 15 пользовательских сессий в режиме «аналитик») при загруженности пропускного канала от клиентской системы до сервера приложений в пределах 50% для сети 100 Mb/sec и утилизации ресурсов сервера приложений (CPU, RAM) в рамках 70-80%, а клиентской машины в рамках 40-60%, не должно превышать 1 секунды для операций создания записи (сущности) и 3 секунд для операций поиска.
Время выполнения аналитических отчётов определяется отдельно для каждого отчёта

Тест-менеджмент

Слайд 34

Ещё одно уточнение

Что мы упустили в требовании?
Время отклика … при загруженности пропускного

Ещё одно уточнение Что мы упустили в требовании? Время отклика … при
канала …, не должно превышать 1 секунды … время выполнения …
Что с ресурсами?.. Какими они должны быть?

Тест-менеджмент

Слайд 35

Что должно было получится

Пример тестопригодного требования
Время отклика системы с точки зрения конечного

Что должно было получится Пример тестопригодного требования Время отклика системы с точки
пользователя (end-to-end) во время продуктивной нагрузки (50 пользовательских сессий в режиме «менеджер» / 15 пользовательских сессий в режиме «аналитик») при загруженности пропускного канала от клиентской системы до сервера приложений в пределах 50% для сети 100 Mb/sec, не должно превышать 1 секунды для операций создания записи и 3 секунд для операций поиска записи.
Время выполнения аналитических отчётов определяется отдельно для каждого отчёта.
Объём используемой оперативной памяти должен оставаться стабильным.

Тест-менеджмент

Слайд 36

Практический пример

Тест-менеджмент

Практический пример Тест-менеджмент

Слайд 37

Анализ архитектуры

Архитектура
Сервер приложений
Сервер БД
«Толстые» клиенты, около 10 операторов

Первые выводы и вопросы
Большинство операций

Анализ архитектуры Архитектура Сервер приложений Сервер БД «Толстые» клиенты, около 10 операторов
происходит на стороне клиента
Тестируем клиентскую часть и сервер приложений
Сервер приложения может работать со своей БД и с БД центрального отделения
БД не содержит никакой логики – только хранилище?

Тест-менеджмент

Слайд 38

Анализ конфигурационных требований

Требования к конфигурациям
Клиентская часть поддерживается на 4-х ОС
Сервер приложения поддерживается

Анализ конфигурационных требований Требования к конфигурациям Клиентская часть поддерживается на 4-х ОС
на 2-х ОС
Локализация – система поддерживает два языка
На тестирование выносится 20 функциональных требований к клиентской части и 10 функциональных требований к серверной части

Тест-менеджмент

Слайд 39

Пытаемся планировать

Вопросы к обсуждению
Какие виды тестов будем проводить?
Нагрузочного тестирования не будет,

Пытаемся планировать Вопросы к обсуждению Какие виды тестов будем проводить? Нагрузочного тестирования
10 операторов – это не та нагрузка, которую стоит проверять (или будет?)
Что стоит автоматизировать, что нет?
Какие окружения выделяем для тестирования?

Тест-менеджмент

Слайд 40

Попробуем прикинуть трудоёмкость

Допущения
Допустим, на одно функциональное требование мы предполагаем написать 5 тестовых

Попробуем прикинуть трудоёмкость Допущения Допустим, на одно функциональное требование мы предполагаем написать
сценариев
Допустим, на прохождение 1-го тестового сценария мы предполагаем потратить 5 минут
Посчитайте сами и ответьте на следующие вопросы:
Сколько всего окружений получается?
Сколько всего тестовых сценариев будет в системе?
Время затраченное на проведение 1-го раунда тестирования?

Тест-менеджмент

Слайд 41

Считаем окружения

Окружений: 16
4 клиентские ОС * 2 языка = 8 клиентских конфигураций

Считаем окружения Окружений: 16 4 клиентские ОС * 2 языка = 8
* 2 серверные ОС = 16 окружений
Тестовых сценариев в системе: 150
(20 клиентских требований + 10 серверных требований) * 5 тестовых сценариев на одно требование = 150.
Сколько всего тестовых сценариев для проведения 1-го раунда тестирования?

Тест-менеджмент

Слайд 42

Считаем время

Расчеты
Всего тестовых сценариев: 16 окружений * 150 тестовых сценариев = 2400
Время

Считаем время Расчеты Всего тестовых сценариев: 16 окружений * 150 тестовых сценариев
на проведение 1-го раунда тестирования: (2400 тестовых сценарев * 5 минут) / 60 = 200 часов или 5 недель

Тест-менеджмент

Слайд 43

Давайте подумаем

Тест дизайн: разработка тестов

Что мы не учли?
Требования относятся к функциональности (логике

Давайте подумаем Тест дизайн: разработка тестов Что мы не учли? Требования относятся
приложения) или к окружению (системные функции, работа с ресурсами ОС и т.д.). Если к функциональности, то не надо проверять их в различных окружениях.

Слайд 44

Разбор тестируемых функций

Что зависит обычно от окружения на клиенте и сервере?
Вход, выход,

Разбор тестируемых функций Что зависит обычно от окружения на клиенте и сервере?
печать форм, получение языка ОС, получение цветовой гаммы ОС, работа с протоколами общения между серверами приложений
Что не зависит от окружения?
Получение информации из БД, запрос на сервер приложения, анализ полученных данных на клиенте и т.д.

Тест-менеджмент

Слайд 45

Подбиваем баланс по группам требований

Получаем:
5 требований зависят от окружений на клиенте
5 требований

Подбиваем баланс по группам требований Получаем: 5 требований зависят от окружений на
зависят от всех окружений
5 требований зависят только от окружений сервера приложений
15 требований относятся к функциональности и не зависят от окружений

Тест-менеджмент

Слайд 46

Пересчитываем

Итого:
25 тестовых сценариев * 8 = 200 тестовых сценариев зависящих от окружения

Пересчитываем Итого: 25 тестовых сценариев * 8 = 200 тестовых сценариев зависящих
на клиенте
25 тестовых сценариев * 16 = 400 тестовых сценариев зависящих от всех конфигураций
25 тестовых сценариев * 2 = 50 тестовых сценариев зависящих от окружения на сервере приложений
75 тестовых сценариев относятся к функциональным тестам
200 + 400 + 50 + 75 = 725 тестовых сценариев

Тест-менеджмент

Слайд 47

Сила тест-дизайна

Расчеты
Всего тестовых сценариев: 725
Время на проведение 1-го раунда тестирования: (725 тестовых

Сила тест-дизайна Расчеты Всего тестовых сценариев: 725 Время на проведение 1-го раунда
сценариев * 5 минут) / 60 = 60,5 часов или 1,5 недели
Было: 200 часов или 5 недель
Стало: 60,5 часов или 1,5 недели
Экономия достигается за счёт принимаемых допущений и связанных с ними рисков

Тест-менеджмент

Слайд 48

Практические соображения
Принимаем решение об автоматизации тестирования

Автоматизация тестирования ПО

Тест-менеджмент

Практические соображения Принимаем решение об автоматизации тестирования Автоматизация тестирования ПО Тест-менеджмент

Слайд 49

Когда и как начинать?

Принятие решение об автоматизации
Решение об автоматизации тестирования на проекте

Когда и как начинать? Принятие решение об автоматизации Решение об автоматизации тестирования
по разработке должно приниматься с учетом роста затрат на тестирование
Внедрять Автоматизированное тестирование ПО стоит только при наличии полноценного рабочего процесса тестирования и нескольких успешных циклов (выпущенных версий) тестирования в проекте

Тест-менеджмент

Слайд 50

О чём нужно помнить?

Принятие решение об автоматизации
Нужно помнить, что первоначальные затраты на

О чём нужно помнить? Принятие решение об автоматизации Нужно помнить, что первоначальные
автоматизацию тестирования могут в 8-12 раз превосходить затраты на полноценное ручное тестирование
При расчете эффективности автоматизации тестирования, требуется учитывать затраты на поддержку автоматизированных тестов (рекомендуется закладывать от 25% до 40% рабочего времени инженера автоматизации на поддержку и актуализацию тестовых сценариев и наборов)

Тест-менеджмент

Слайд 51

Когда это полезно?

Критерии пригодности к автоматизации
Внедрение автоматизации экономически оправдано
Проект по разработке долгосрочный

Когда это полезно? Критерии пригодности к автоматизации Внедрение автоматизации экономически оправдано Проект
(1-2 года) или находится в области mission/business critical проектов – потери от сбоев влекут невосполнимые финансовые потери или угрозу жизни.
Формальные методы расчета возврата вложений показывают положительный возврат средств

Тест-менеджмент

Слайд 52

Когда это необходимо?

Критерии пригодности к автоматизации
Внедрение автоматизации критично для успешной реализации проекта
Объем

Когда это необходимо? Критерии пригодности к автоматизации Внедрение автоматизации критично для успешной
регрессионного тестирования в 4-5 раз превышает объемы тестирования новой функциональности (80/20 - критичное соотношение)
Ресурсов по тестированию, при правильном соблюдении баланса сил Dev/Test в проекте в обозримом будущем недостаточно, чтобы удерживать контроль над качеством системы

Тест-менеджмент

Слайд 53

С чего начать? Цели и задачи

Что стоит автоматизировать вначале
Автоматизация приёмочного тестирования билда

С чего начать? Цели и задачи Что стоит автоматизировать вначале Автоматизация приёмочного
или набора Smoke-тестов
Автоматизация базовых операций системы, основных алгоритмов и устоявшейся функциональности
Автоматизация инсталляции-развёртывания системы и создания базового набора тестовых данных

Тест-менеджмент

Слайд 54

Идём или не идём?

Принятие решение об автоматизации
Непосредственные выгоды от внедрения автоматизации достигаются

Идём или не идём? Принятие решение об автоматизации Непосредственные выгоды от внедрения
за счет экономии времени при многократном прогоне тестов
Решение внедрении инструментов автоматизации стоит принимать только на основе формальных оценок: метод ROI (возврат на вложения)

Тест-менеджмент

Слайд 55

Что понимают под нагрузочным тестированием
Алгоритм создания скрипта

Тестирование производительности ПО

Тест-менеджмент

Что понимают под нагрузочным тестированием Алгоритм создания скрипта Тестирование производительности ПО Тест-менеджмент

Слайд 56

На что обычно наступают

Непонимание терминологии заказчиком и проектной командой
Определите понятия «нагрузочное тестирование»
Неготовность

На что обычно наступают Непонимание терминологии заказчиком и проектной командой Определите понятия
заказчика назвать «рамки успешности»:
Идите от бизнес-задач вместе с Заказчиком
Попробуйте использовать алгоритм «эксперимент-анализ-эксперимент» и думать в разрезе «стало лучше или хуже?»

Тест-менеджмент

Слайд 57

На что обычно наступают-2

Технологическая невозможность проектирования и воспроизведения адекватной модели нагрузки
Собирайте данные

На что обычно наступают-2 Технологическая невозможность проектирования и воспроизведения адекватной модели нагрузки
из эксплуатации
Ставьте эксперименты с разными моделями нагрузки
Пробуйте делать свои «пушки»
Несогласованность ожиданий
Проговорите и зафиксируйте формат отчётов
Проговорите и зафиксируйте вероятность доверия к результатам

Тест-менеджмент

Слайд 58

Слова: производительность и нагрузка
Тестирование производительности (performance testing)
Нагрузочное тестирование, целью которого является

Слова: производительность и нагрузка Тестирование производительности (performance testing) Нагрузочное тестирование, целью которого
определение показателей производительности системы при типовой нагрузке.
Тестирование производительности при максимальной нагрузке (load testing)
Нагрузочное тестирование, целью которого является определение параметров производительности при максимально прогнозируемой нагрузке на систему, а также определение пределов производительности, т.е. максимального количества пользователей, которые одновременно смогут работать с системой без ошибок и сбоев.

Тест-менеджмент

Слайд 59

Слова: стрессы и перегруз

Стрессовое тестирование (stress testing)
Нагрузочное тестирование, целью которого является

Слова: стрессы и перегруз Стрессовое тестирование (stress testing) Нагрузочное тестирование, целью которого
определение параметров производительности системы в случае ограниченности или недоступности ресурсов:
Оперативная память
Место на диске
Пропускная способность канала связи
Процессор

Тест-менеджмент

Слайд 60

Слова: объёмы данных
Объемное тестирование (volume testing)
Нагрузочное тестирование, целью которого является определение параметров

Слова: объёмы данных Объемное тестирование (volume testing) Нагрузочное тестирование, целью которого является
производительности системы в случае значительного изменения объемов данных.
Например:
Для принтера – большое количество печатаемых страниц
Для грамматического анализатора текста – большой объем текста, загруженного сразу

Тест-менеджмент

Слайд 61

Слова: наработка на отказ

Тестирование надежности (reliability testing)
Нагрузочное тестирование, целью которого является определение

Слова: наработка на отказ Тестирование надежности (reliability testing) Нагрузочное тестирование, целью которого
параметров производительности в условиях длительной эксплуатации, в том числе с большими объемами данных и при большой нагрузке на систему.

Тест-менеджмент

Слайд 62

Тестирование масштабируемости (scalability testing)
Нагрузочное тестирование, целью которого является определение параметров производительности системы

Тестирование масштабируемости (scalability testing) Нагрузочное тестирование, целью которого является определение параметров производительности
на различных аппаратно-программных платформах.
Система называется масштабируемой, если она способна увеличивать производительность пропорционально дополнительным ресурсам

Слова: расширяемость и масштаб

Тест-менеджмент

Слайд 63

Шаги
Запускаем тул на запись и кликаем нашу последовательность.
Логин и логофф части

Шаги Запускаем тул на запись и кликаем нашу последовательность. Логин и логофф
записываем в «vuser_init» и «vuser_end» части (при прогоне с различными параметрами, операции описанные в инит и енд части не проигрываются).
Действия пользователя записываем в action часть, или создаём несколько actions, если по-логике выполняется более чем одно действие с осязаемым результатом.
Смотрим что получилось и проигрываем: получаем воспроизведение действий от лица одного пользователя (пока создания нагрузки нет).

Алгоритм работы

Тест-менеджмент

Слайд 64

Шаги
При необходимости расставляем точки рандеву
При необходимости определяем транзакции (что интересно померять)
При необходимости/возможности

Шаги При необходимости расставляем точки рандеву При необходимости определяем транзакции (что интересно
параметризируем скрипт
Выполняем калибровочный прогон на 3-5 пользователей
Создаём модель нагрузки
Выполняем прогон
Коллекционируем и анализируем данные

Алгоритм работы-2

Тест-менеджмент

Слайд 65

Этапы тестирования
Что происходит во время планирования
Практические соображения

Планирование и этапы тестирования

Тест-менеджмент

Этапы тестирования Что происходит во время планирования Практические соображения Планирование и этапы тестирования Тест-менеджмент

Слайд 66

Этапы тестирования

Планирование тестирования
Проектирование тестирования
Реализация тестирования
Выполнение тестирования
Оценка тестирования

Тест-менеджмент

Этапы тестирования Планирование тестирования Проектирование тестирования Реализация тестирования Выполнение тестирования Оценка тестирования Тест-менеджмент

Слайд 67

Цели планов

Планирование тестирования
Выясняется
объем работ,
сроки выполнения,
пути решения задач по выполнению

Цели планов Планирование тестирования Выясняется объем работ, сроки выполнения, пути решения задач
работ,
ресурсы,
календарный план
Основной артефакт – план тестирования >>

Тест-менеджмент

Слайд 68

Задачи и содержание планов

Назначение плана тестирования
План тестирования ПО является основным согласующим документом

Задачи и содержание планов Назначение плана тестирования План тестирования ПО является основным

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

Тест-менеджмент

Слайд 69

Что внутри плана

Что происходит при планировании
Анализ имеющейся информации о проекте
Выявление компонент ПО,

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

Тест-менеджмент

Слайд 70

Из чего состоит план

Основные разделы плана тестирования
Название, Проект
Журнал изменений
Введение
Назначение
Исходные данные
Область применения
Идентификация проекта
Тестовые

Из чего состоит план Основные разделы плана тестирования Название, Проект Журнал изменений
требования
Стратегия тестирования
Ресурсы и расписание
Материалы, подлежащие сдаче

Тест-менеджмент

Слайд 71

Стратегия тестирования

Стратегия тестирования
Типы тестирования
Тестирование данных и целостности базы данных
Функциональное тестирование
Тестирование бизнес-циклов
Тестирование пользовательского

Стратегия тестирования Стратегия тестирования Типы тестирования Тестирование данных и целостности базы данных
интерфейса
Нагрузочное тестирование
Тестирование безопасности и управления доступом
Конфигурационное тестирование
Инсталляционное тестирование
Критерии завершённости
Инструментальные средства

Тест-менеджмент

Слайд 72

Этапы тестирования

Практические соображения
Не старайтесь создать тест-план в точности по шаблону
Попробуйте применить концепцию

Этапы тестирования Практические соображения Не старайтесь создать тест-план в точности по шаблону
«живых документов»
Здравый смысл…
Здравый смысл!
Здравый смысл ☺

Тест-менеджмент

Слайд 73

Алгоритм работы с дефектами
Трекинг по статусам и ролям
Типичные проблемы

Работа с дефектами

Тест-менеджмент

Алгоритм работы с дефектами Трекинг по статусам и ролям Типичные проблемы Работа с дефектами Тест-менеджмент

Слайд 74

Универсальный алгоритм? Хм ☺

Алгоритм работы с дефектами
Алгоритм трекинга дефектов может отличаться от

Универсальный алгоритм? Хм ☺ Алгоритм работы с дефектами Алгоритм трекинга дефектов может
проекта к проекту
Я предлагаю общую большую схему
Если у вас это не так – посмотрите на что вы наступаете работая «как сейчас» и на что не будете если настроите как предлагается

Тест-менеджмент

Слайд 75

Куколка-бабочка?

Статусы ошибок, набор полей, их типы и свойства, возможные переходы между статусами

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

Трекинг по статусам

Тест-менеджмент

Слайд 76

Кто кому: пас на тренера!

Трекинг по ролям

Тест-менеджмент

Кто кому: пас на тренера! Трекинг по ролям Тест-менеджмент

Слайд 77

Что бывает не так?

Сокращение шагов по воспроизведению ошибки
Отсутствие описания ошибочного поведения
Отсутствие описания

Что бывает не так? Сокращение шагов по воспроизведению ошибки Отсутствие описания ошибочного
правильного поведения
Неправильное использование статуса Reopen (для новых ошибок с похожими признаками)
Неправильное использование статуса Duplicate
>>

Типичные проблемы

Тест-менеджмент

Слайд 78

А ещё бывает и так…


Тестирование устаревшего билда
Изобретение собственных требований
Использование нечетких формулировок
Попытка определить

А ещё бывает и так… … Тестирование устаревшего билда Изобретение собственных требований
причину ошибки (поставить диагноз)
Искусственное завышение приоритета ошибки
Самовольное сужение тестового покрытия

Типичные проблемы

Тест-менеджмент

Слайд 79

Учет рисков, меры по их минимизации
Процесс управления рисками
Типичные риски
Практические соображения

Работа с рисками

Тест-менеджмент

Учет рисков, меры по их минимизации Процесс управления рисками Типичные риски Практические

Слайд 80

Работа с рисками: как начать?

Учет рисков, меры по их минимизации
Риск – действующий

Работа с рисками: как начать? Учет рисков, меры по их минимизации Риск
или развивающийся фактор процесса, обладающий потенциалом негативного влияния на ход процесса
Риск – лишь потенциальный, а не обязательный результат
Опасен не сам риск, а его последствия

Тест-менеджмент

Слайд 81

Работа с рисками: одной картинкой

Тест-менеджмент

Работа с рисками: одной картинкой Тест-менеджмент

Слайд 82

Работа с рисками: зачем это всё?

Извлечение уроков
Извлечение уроков формализует усвоение накопленного опыта

Работа с рисками: зачем это всё? Извлечение уроков Извлечение уроков формализует усвоение
в форме, доступной для использования как внутри группы, так и на уровне всей компании
Даже если вы уверены, что все помнят усвоенные уроки, занесите информацию в базу знаний

Тест-менеджмент

Слайд 83

Работа с рисками: главное начать

Процесс управления рисками
Описанные фазы являются логическими шагами, и

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

Тест-менеджмент

Слайд 84

Работа с рисками: и ещё немного

Типичные риски
Технические:
Нахождение критичных ошибок после ввода системы

Работа с рисками: и ещё немного Типичные риски Технические: Нахождение критичных ошибок
в эксплуатацию
Нахождение «дыр» в системе безопасности
Возникновение проблем при поставке и развертывании системы
Использование новых технологий
Использование продуктов третьих производителей
>>

Тест-менеджмент

Слайд 85

Работа с рисками: и ещё чуть-чуть!

Типичные риски

Планирование
Неправильное определение границ работ
Неправильный выбор

Работа с рисками: и ещё чуть-чуть! Типичные риски … Планирование Неправильное определение
архитектуры
Неправильная оценка ресурсов
Организационные
Частое и противоречивое изменение требований заказчиком
Текучесть кадров

Тест-менеджмент

Слайд 86

Работа с рисками в тестировании

Типичные риски в тестировании
Нехватка ресурсов
Требования будут формализованы поздно

Работа с рисками в тестировании Типичные риски в тестировании Нехватка ресурсов Требования
для полноценного тест-дизайна (не хватит времени)
Критичные ошибки будут найдены поздно

Тест-менеджмент

Слайд 87

Практические соображения

Типичные риски в тестировании
Работа с рисками в тестировании не отличается от

Практические соображения Типичные риски в тестировании Работа с рисками в тестировании не
работы с рисками как таковой
Отличаются типичные риски
Тестирование более зависимый процесс
Большая зависимость от заказчика

Тест-менеджмент

Слайд 88

Практические соображения

Типичные риски в тестировании (пример)
Большие и НЕУЧТЁННЫЕ затраты на перетестирование: проблемы

Практические соображения Типичные риски в тестировании (пример) Большие и НЕУЧТЁННЫЕ затраты на
планирования тестирования
Использование группы тестирования как отладочного механизма: проблема с пониманием роли процесса тестирования в компании или проекте
Поставка сырых или устаревших модулей: непоставленный процесс версионного контроля и конфигурационного менеджмента

Тест-менеджмент

Слайд 89

ОСНОВНЫЕ РОЛИ
Тест-менеджер, менеджер проекта по тестированию
Тест-аналитик
Тест-дизайнер
Тестировщик, Инженер по тестированию
ВСПОМОГАТЕЛЬНЫЕ РОЛИ
Администратор тестовой системы,

ОСНОВНЫЕ РОЛИ Тест-менеджер, менеджер проекта по тестированию Тест-аналитик Тест-дизайнер Тестировщик, Инженер по
приложений поддерживающих жизненный цикл тестирования
Администратор баз данных, менеджер баз данных
Разработчик тестов

Обзор ролей и артефактов в тестировании

Тест-менеджмент

Слайд 90

Менеджер по тестированию не уборщица

Зачем нужно понимать какие роли куда относятся?
Менеджеру нельзя

Менеджер по тестированию не уборщица Зачем нужно понимать какие роли куда относятся?
заниматься вспомогательной деятельностью
Специализация даёт прирост в эффективности: выделяйте роли в команде
Специализаций и роли – основа перехода к процессному управлению
Роли – первые «горизонтальные» ступеньки для роста ваших людей

Тест-менеджмент

Слайд 91

Обзор артефактов тестирования (RUP)

Тестировщик ПО
Test script
Test log
Аналитик
Test Case
Test-Ideas List
Workload Analysis Model
Test Data
Test

Обзор артефактов тестирования (RUP) Тестировщик ПО Test script Test log Аналитик Test
results

Тест-менеджмент

Слайд 92

Обзор артефактов тестирования (RUP)

Дизайнер
Test Strategy
Test Automation Architecture
Test Environment Configuration
Test Suite
Тест-менеджер
Test Plan
Test Evaluation

Обзор артефактов тестирования (RUP) Дизайнер Test Strategy Test Automation Architecture Test Environment
Summary

Тест-менеджмент

Слайд 93

Мои артефакты: магия проста

Что я использую на практике:
Тест план: что есть

Мои артефакты: магия проста Что я использую на практике: Тест план: что
из артефактов, что будем тестировать и что НЕ будем тестировать, кто будет тестировать, какие типы тестов будем проводить, «тест лаб» или на чём будем тестировать, какими инструментами будем пользоваться, какие отчёты будем предоставлять, что будем сдавать заказчику
Тест кейс: «где я», что я делаю, что я ожидаю
Чек-лист: «когда много контрольных точек»
Тестовая процедура: «когда много шагов»

Тест-менеджмент

Слайд 94

Круг задач
Активности
Список ответственности
Совмещение ролей

Активности тест-менеджера

Тест-менеджмент

Круг задач Активности Список ответственности Совмещение ролей Активности тест-менеджера Тест-менеджмент

Слайд 95

Ваш круг задач

Контроль объема проекта
Планирование и контроль выполнения задач по тестированию
Управление персоналом
Контроль

Ваш круг задач Контроль объема проекта Планирование и контроль выполнения задач по
рисков, связанных с тестированием
Мотивация персонала

Тест-менеджмент

Слайд 96

Ваши активности

Согласование миссии тестирования
Получение обязательств по тестируемости продукта
Оценка и отстаивание уровня качества
План

Ваши активности Согласование миссии тестирования Получение обязательств по тестируемости продукта Оценка и
развития качества продукта
Оценка и улучшение производительности тестирования

Тест-менеджмент

Слайд 97

Совмещение ролей

Как правило, в небольших проектах совмещение ролей неизбежно. Это нормально
Рассмотрим возможные

Совмещение ролей Как правило, в небольших проектах совмещение ролей неизбежно. Это нормально
сочетания ролей в проекте (следующий слайд)
+ - сочетание допустимо
± - сочетание нежелательно
- - сочетание недопустимо
>>

Тест-менеджмент

Слайд 98

«Огурцы с молоком»

Рассмотрим наиболее «порочное» сочетание ролей: разработчик-тестировщик
Разработчик проводит тестирование по остаточному

«Огурцы с молоком» Рассмотрим наиболее «порочное» сочетание ролей: разработчик-тестировщик Разработчик проводит тестирование
принципу и не может найти неожиданные ошибки за счет «замыленности» взгляда.
Отсутствие или низкое качество регрессионного тестирования
Тестирование не является процессом с заданными входными и выходными данными и критериями завершения
Повышается вероятность пропуска или не нахождения критических дефектов

Тест-менеджмент

Слайд 99

Исключения и связи

Тест-менеджмент

Исключения и связи Тест-менеджмент

Слайд 100

Успешное управление

Тест-менеджмент

Работа с подчиненными
Работа с руководством, коллегами, заказчиками
Управление задачами
Управление временем, тайм-менеджмент

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

Слайд 101

С кем мы работаем?

Подбор исполнителей
Именно руководитель составляет план и определяет количество нужных

С кем мы работаем? Подбор исполнителей Именно руководитель составляет план и определяет
ресурсов
Не соглашайтесь с урезанием ресурсов «безвозмездно», потребуйте либо увеличить бюджет, либо отпущенное время, либо усилить команду
Согласие с «безвозмездным» урезанием ресурсов подрывает ваш авторитет
>>

Тест-менеджмент

Слайд 102

Плюс на минус даёт…

Подбор исполнителей
Персональный состав команды согласовывается с руководством
Руководитель может обоснованно

Плюс на минус даёт… Подбор исполнителей Персональный состав команды согласовывается с руководством
отказаться работать с кем-либо из подчиненных
Но если руководитель работает с подчиненными и не сообщает о проблемах, то это автоматически означает, что:
Это не отразится на качестве работы данного работника
Это не отразится на сроках выполнения работ
Это не отразится на качестве работы самого руководителя

Тест-менеджмент

Слайд 103

Кто даёт оценки по времени?

Оценка задач
Задачи должны оцениваться теми, кто их будет

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

Тест-менеджмент

Слайд 104

Трудоёмкость задач: keywords

Оценка трудоемкости задач: способы
Evidence based
Дельфи
COCOMO

Тест-менеджмент

Трудоёмкость задач: keywords Оценка трудоемкости задач: способы Evidence based Дельфи COCOMO Тест-менеджмент

Слайд 105

Мысли вслух

Практические соображения
Помните о правиле «треугольника» Время-Деньги-Ресурсы. Фиксировать можно не более 2

Мысли вслух Практические соображения Помните о правиле «треугольника» Время-Деньги-Ресурсы. Фиксировать можно не
параметров
Если какой-либо параметр меняется более, чем на 10%, то воздействие на другие два будет квадратичным
Менеджер вносит на порядок большие ошибки в оценки проекта, чем инженеры при оценке индивидуальных задач

Тест-менеджмент

Слайд 106

О чём часто забывают

Оценка задач. Практические соображения
При оценке не забывайте о «скрытых»

О чём часто забывают Оценка задач. Практические соображения При оценке не забывайте
задачах и «запасе прочности»
При составлении планов и оценке учитывайте риски
...слабо развиты наши методы оценок. В сущности, они отражают молчаливое и совершенно неверное предположение, что все будет идти хорошо. Фредерик Брукс
Как правило, план не выполняется из-за неучтенных задач или рисков

Тест-менеджмент

Слайд 107

Все люди – разные

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

Все люди – разные Индивидуальный подход Существует множество способов классификации психологических типов.
следующую классификацию (с точки зрения отношения к работе):
«Пунктуальный». Не пренебрегает деталями, но всегда занят и не способен расставить приоритеты
«Хочу понравиться всем». Работает старательно и добросовестно, но не умеет говорить «нет» и часто перегружен чужой работой
>>

Тест-менеджмент

Слайд 108

Все люди – очень разные ☺

Индивидуальный подход
...
«Всегда опаздываю». Способен справиться с большим

Все люди – очень разные ☺ Индивидуальный подход ... «Всегда опаздываю». Способен
объемом работ в краткие сроки, но всегда откладывает ее до последнего – иначе ему неинтересно
«Самодостаточный». Ответственен, но избегает обращаться за помощью и советами, из-за чего часто затягивает даже простые задачи
«Творец». Способен найти нетривиальный подход, эффективно решать сложные задачи, но часто игнорирует планы и бизнес-потребности, избегает рутинной работы
Учитывайте индивидуальность при постановке задач!

Тест-менеджмент

Слайд 109

Что мы забываем при планировании?
Практические соображения
Подстраивайте график работы группы под нужды проекта
Учитывайте

Что мы забываем при планировании? Практические соображения Подстраивайте график работы группы под
разницу во времени между офисами и заказчиком
Учитывайте культурные различия

Тест-менеджмент

Слайд 110

Коммуникации и встречи

Проводите ежедневные собрания группы
Выявляйте текущие проблемы, но не пытайтесь их

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

Тест-менеджмент

Слайд 111

Контроль и информация

Контроль
Будьте в курсе, чем занят каждый подчиненный и когда он

Контроль и информация Контроль Будьте в курсе, чем занят каждый подчиненный и
окончит свое задание
Планируйте загрузку с избытком («горизонт задач»)
Если вы узнаете о плохой работе подчиненных от руководства – это тревожный симптом!
Информация
Обеспечьте совместное использование (sharing) имеющегося опыта
Избегайте возникновения «Тайных Знаний» (Secret Knowledge)
Поддерживайте создание и развитие Базы Знаний

Тест-менеджмент

Слайд 112

Мотивация

Тест-менеджмент

Кто может мотивировать
Виды мотивации
Иерархия потребностей
Практические соображения

Мотивация Тест-менеджмент Кто может мотивировать Виды мотивации Иерархия потребностей Практические соображения

Слайд 113

Кто мотивирует?

Кто должен мотивировать
Как правило, в тестировании задачи по мотивации исполняет тест-менеджер
В

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

Тест-менеджмент

Слайд 114

Как мотивировать?

Типичная схема мотивации
Материальная
Ставка
Премия по результатам личной деятельности
Премия по результатам деятельности

Как мотивировать? Типичная схема мотивации Материальная Ставка Премия по результатам личной деятельности
отдела
...
Нематериальная
Личное общение
Внимание и защита
Сопричастность
Влияние

Тест-менеджмент

Слайд 115

Тест-менеджмент

Иерархия потребностей (по Маслоу)

Тест-менеджмент Иерархия потребностей (по Маслоу)

Слайд 116

Что это означает на практике?

Мотивирующие факторы для различных уровней (по Маслоу)
5. Клубы

Что это означает на практике? Мотивирующие факторы для различных уровней (по Маслоу)
(кружки) качества, SEPG, подарки при значимых событиях...
4. Название должности, представительские обязанности, имидж компании, аксессуары...
3. Участие в управлении, обратная связь с руководством, обучение, информация о долгосрочных перспективах...
2. Конкурентная з/п, комфортное рабочее место и т.п.
1. Выполнение 80% требуемого объема работы оплачивается на уровне средней з/п на рынке

Тест-менеджмент

Слайд 117

Чего от нас ждут, как от менеджеров?

Исходя из того, что мы люди

Чего от нас ждут, как от менеджеров? Исходя из того, что мы
здравые ☺
Что нужно руководству компании?
Что нужно вашему заказчику?
Что нужно вашему ПМ-у?
Что нужно вашему ведущему разработчику?

Тест-менеджмент

Слайд 118

Модель F.A.C.T.
Разгребая завалы: «GTD»

Управление задачами и временем

Тест-менеджмент

Модель F.A.C.T. Разгребая завалы: «GTD» Управление задачами и временем Тест-менеджмент

Слайд 119

Модель FACT

Выполняйте задачи в такой последовательности:
A – срочные и важные задачи
С

Модель FACT Выполняйте задачи в такой последовательности: A – срочные и важные
– несрочные, но важные задачи
F – неважные, но срочные задачи
T – неважные и несрочные задачи

Распределите все задачи по срочности и важности

Тест-менеджмент

Слайд 120

Когда её делать… или не делать?

Принципы планирования рабочего дня
При классификации задач задайте

Когда её делать… или не делать? Принципы планирования рабочего дня При классификации
себе вопросы:
Это связано с моими целями? (при ответе «да» - тип A,C)
Только ли я смогу это сделать? (при ответе «да» - тип A,C)
Это должно быть сделано сегодня? (при ответе «да» - тип F,C)
Прежде, чем отнести задачу к типу Т, подумайте, не стоит ли ее делегировать

Тест-менеджмент

Слайд 121

Какие задачи и когда делать?

Принципы планирования рабочего дня
Установите «коммуникационные окна»
Установите время, когда

Какие задачи и когда делать? Принципы планирования рабочего дня Установите «коммуникационные окна»
вы отвечаете лишь на экстренные вопросы
Попытайтесь не выделять специально времени для задач типа T, а использовать их как «песок»

Тест-менеджмент

Слайд 122

Тест-менеджмент

Тест-менеджмент

Слайд 123

Как заставить себя умываться по утрам

Основные принципы
Чтобы начать управлять временем требуются первоначальные

Как заставить себя умываться по утрам Основные принципы Чтобы начать управлять временем
затраты
Ведите хронометраж рабочего дня. Попробуйте продержаться хотя бы 1-2 недели ☺
Фиксируйте запланированные и незапланированные дела, помехи, эмоциональное и физическое состояние
Не старайтесь угодить всем. Берегитесь «хронофагов»
Пожиратели времени, люди которые постоянно спрашивают тебя, не затрудняясь поискать ответ самостоятельно
Имейте список целей. Без этого невозможно составлять планы, а без плана невозможно управлять временем
Научитесь говорить «нет» и делегировать задачи

Тест-менеджмент

Слайд 124

Помогать не значит делать за кого-то

Делегирование задач
Почему зачастую руководитель намного более занят,

Помогать не значит делать за кого-то Делегирование задач Почему зачастую руководитель намного
чем подчиненный?
Если вы помогаете решать проблему вашего подчиненного, она не становится вашей
Избегайте «размывания» ответственности
Избегайте коллективной ответственности
Учитывайте индивидуальность

Тест-менеджмент

Слайд 125

Рекомендуемая литература

Автоматизированное тестирование программного обеспечения
Элфрид Дастин, Джефф Рэшка, Джон Пол
Automated Software Testing

Рекомендуемая литература Автоматизированное тестирование программного обеспечения Элфрид Дастин, Джефф Рэшка, Джон Пол

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

Тест-менеджмент

Слайд 126

Рекомендуемая литература

Ключевые процессы тестирования. Планирование, подготовка, проведение, совершенствование
Рекс Блэк
Издательство: Лори, 2006 г.
В

Рекомендуемая литература Ключевые процессы тестирования. Планирование, подготовка, проведение, совершенствование Рекс Блэк Издательство:
этой книге Рекс Блэк выделяет двенадцать процессов тестирования, являющихся ключевыми для достижения успеха. За описанием каждого из этих процессов следует пример использования процесса. Вместо громоздких правил представлены списки контрольных вопросов - легкие, гибкие инструменты для внедрения тестирования, ориентированного на процесс, для сбора измерений и внесения последовательных изменений.

Тест-менеджмент

Слайд 127

Рекомендуемая литература

Тестирование производительности Web-приложений Microsoft. NET (+ CD-ROM)
Performance Testing Microsoft. NET Web

Рекомендуемая литература Тестирование производительности Web-приложений Microsoft. NET (+ CD-ROM) Performance Testing Microsoft.
Application
Издательство: Русская Редакция, 2003 г.
Эта книга написана группой специалистов Microsoft, протестировавших и настроивших сотни Web-сайтов и Web-приложений, - Microsoft Аррliсаtion Consulting and Engineering (АСЕ) Team (группа консалтинга и проектирования приложений Microsoft).

Тест-менеджмент

Слайд 128

Рекомендуемая литература

Путь камикадзе
Эдвард Йордон
Издательство: Лори, 2003 г.
Книга Эдварда Йордона `Путь камикадзе` представляет

Рекомендуемая литература Путь камикадзе Эдвард Йордон Издательство: Лори, 2003 г. Книга Эдварда
собой полное руководство по выживанию в безнадежных проектах, предназначенное для разработчиков программного обеспечения

Тест-менеджмент

Слайд 129

Рекомендуемая литература

Мифический человеко-месяц
Фредерик Брукс
Издательство: Символ-Плюс, 2006 г.
Эта книга – своего рода библия

Рекомендуемая литература Мифический человеко-месяц Фредерик Брукс Издательство: Символ-Плюс, 2006 г. Эта книга
для разработчиков программного обеспечения во всем мире, написанная Бруксом еще в 1975 году. Полагают, что без прочтения книги Брукса не может состояться ни один крупный руководитель программного проекта

Тест-менеджмент

Слайд 130

Рекомендуемая литература

Тестирование dot com
Роман Савин
Издательство: Дело, 2007 г.
Этот курс лекций создан для

Рекомендуемая литература Тестирование dot com Роман Савин Издательство: Дело, 2007 г. Этот
тех, кто хочет обучиться тестированию, понять, как вести себя в корпоративном окружении, и добиться профессионального и личностного роста. Он будет интересен и участникам процесса разработки программного обеспечения, рекрутерам, людям, связанным с интернетом или пишущим о нем, и просто всем желающим понять кухню интернет-стартапов

Тест-менеджмент

Слайд 131

Рекомендуемая литература

Тайм-драйв
Глеб Архангельский
Издательство: Манн, 2007 г.
Самая полезная и увлекательная книга об управлении

Рекомендуемая литература Тайм-драйв Глеб Архангельский Издательство: Манн, 2007 г. Самая полезная и
временем. Книга отличается популярным изложением. В максимально простой и пошаговой форме, на реальных российских примерах, она дает ответ на главный вопрос современного менеджера: как успевать больше?

Тест-менеджмент

Слайд 132

Рекомендуемая литература

Оценка персонала. Четкий алгоритм действий и качественные практические решения
Алла Вучкович-Стадник
Издательство: Эксмо,

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

Тест-менеджмент

Слайд 133

Рекомендуемая литература

Грейдинг. Технология построения системы управление персоналом
Валерий Чемеков
Издательство: Вершина, 2007 г.
В предлагаемой

Рекомендуемая литература Грейдинг. Технология построения системы управление персоналом Валерий Чемеков Издательство: Вершина,
вниманию читателей книге автор рассматривает системный подход к кадровым технологиям (грейдингу, оценке результативности, аттестации), который основан на измерении и описании должностей. Полученные данные позволяют формулировать требованиядля поиска кандидата, проведения аттестации, обучения, построения системы тарификации.

Тест-менеджмент

Имя файла: Управление-процессом-тестирования-ПО-.pptx
Количество просмотров: 312
Количество скачиваний: 1