И снова здравствуйте! :)
И сразу, как говорится, вопрос в лоб:
Коллеги, а многие ли среди ваших знакомых тестировщиков имеют сертификаты?
А многие ли хотят иметь?
А многие ли столкнулись с необходимостью их иметь?
А как вы относитесь к сертифицированным специалистам?
Как ни странно, но тема сертифицирования тестировщиков очень актуальна в последнее время...
Писали об этом уже и Алесей Баранцев в статье "Какие сертификаты нужны тестировщикам",
и Александр Орлов в статье "Шашечки или ехать". Кстати, надо сказать, что в голосовании, которое устроил тот же Александр Орлов наблюдается весьма интересная картина по результатам...
А ваше мнение какое?
Кстати сказать, я тоже имею что сказать на этот счет, но скажу буквально очень скоро :)
Всегда ваша,
Наташа Густыр
Read more...
среда, 28 января 2009 г.
понедельник, 26 января 2009 г.
Урок 53: Оценочные (evaluation-based) техники фокусируются на том, как определить, что тест выполнен или провален
Lessons Learned in Software Testing
Авторы: Cem Kaner, James Bach и Bret Pettichord
Перевод: Сергей Талалаев
Оценочные техники описывают методы для определения того, что программа выполнила или провалила тест. Они не определяют, как тестирование должно выполняться, или как должны собираться данные. Они говорят вам, что если вы можете собрать определенные данные, то вы сможете их оценить.
Самотестируемые данные. Файлы данных, используемые вами для тестирования, несут в себе информацию, которая позволяет вам определять, что выходные данные повреждены.
Сравнение с сохраненными результатами. Регрессионное тестирование (обычно, но не всегда автоматизированное), в котором тот факт, пройден тест или провален, определяется путем сравнения результатов, полученных вами сегодня, с результатами предыдущей недели. Если результаты были корректными на прошлой неделе и отличаюся сегодня, то такое различие может говорить о новом дефекте.
Сравнение со спецификацией или другим авторитетным документом. Различие со спецификацией - это (возможно) ошибка.
Эвристическое соответствие. Соответствие - это важный критерий оценки
программы.Несоответствие может быть поводом для создания отчета об ошибке или отражать сознательное изменение дизайна. Мы используем в работе 7 основных соответствий:
1. Историческое соответствие. Текущие поведение функции соответствует её поведению в прошлом.
2. Соответствие в представлении. Поведение функции соответствует тому, что организация ожидала от проекта.
3. Соответствие со сравнимыми продуктами. Поведение функции соответствует поведению подобных функций в сравнимых продуктах.
4. Соответствие утверждениям. Поведение функции соответствует тому, как, по мнению людей, это должно быть.
5. Соответствие ожиданиям. Поведение функции соответствует тому, что, по вашему мнению, хочет пользователь.
6. Соответствие продукту. Поведение функции соответствует поведению сравнимых функций или функциональных шаблонов в продукте.
7. Соответствие цели. Поведение функции соответствует её истинной цели.
Оракул-based тестирование. Оракул - это оценочное приспособление, которое скажет вам о том, что программа прошла или провалила тест. В высокопроизводительном автоматизированном тестировании оракул - это обычно другая программа,которая выдает результаты или оценивает результаты проверяемой программы. Оракул обычно более авторитетен, чем проверяемая программа, поэтому беспокойство, отмеченное оракулом, стоит времени и усилий, потраченных на проверку.
Read more...
среда, 14 января 2009 г.
SQA days 2008: текст доклада "Причины пожара на проектах"
Мы уже писали о выступлении на конференции SQA days и обещали опубликовать свои доклады. Наташа и Сергей сдержали обещание. Теперь моя очередь :) Я постаралась максимально приблизить печатную версию к устной, чтобы сохранить дух "живого" выступления.
«Горящий» проект – не редкость в IT сфере. Отставание от плана может возникать на разных стадиях: от инициализации проекта до тестирования. Данный доклад - попытка ответить на вопрос: «Почему тестировщики не укладываются в сроки?».
Недавно мне «посчастливилось» принимать участие в проекте, на котором отставание от сроков – обычное дело. Сразу хочу пояснить, что я понимаю под отставанием от сроков. Это разница между реально потраченным и запланированным временем (см. рисунок 1).
В докладе рассматриваются причины невыполнения в срок задач тестовой команды, хотя многое из того, о чём будет говориться ниже, актуально для любых проектных активностей.
Несколько слов о проекте, который вдохновил меня на подготовку этого доклада. Проект был сложный… :) Причём, я сейчас говорю не о сложности задач, которые стояли перед нашей командой, а о сложной структуре проекта. На рисунке 2 представлена схема этого проекта, где З1...З8 – задачи, из которых состоит реализация проекта, К1…К8 – компании (подрядчики), которые принимают участие в проекте. Как видно, каждый подрядчик отвечает за свою задачу. И даже заказчик выполняет часть работ по созданию программного обеспечения.
Многое из того, о чём пойдёт речь дальше, навеяно именно этим сложным проектом, но также я использовала опыт участия в более простых проектах (Рисунок 3).
Думаю, понятно, что вероятность «пожаров» на проектах со сложной структурой больше. Естественно, здесь много зависимостей. Если один из подрядчиков на начальном этапе не уложился в сроки, то «поплывут» даты в планах у остальных компаний-подрядчиков. На сложном проекте часто возникает ситуация: «а это не я». Это когда на выявление ошибки уходит час, а на выявление ответственного за неё тратятся дни или даже недели. Каждая компания пытается сделать крайним кого-то другого. Такая проблема обычно возникает из-за плохой организации взаимодействия между участниками проекта и нечёткого разграничения обязанностей.
Теперь непосредственно о самих причинах. Одна из самых очевидных причин «пожаров» - нереальные сроки. Как эти «нереальные» сроки появляются? Например, заказчик говорит: «нужно, чтобы эта функциональность (F1...Fn) была готова к такому-то числу». И тут начинается попытка уместить всю требуемую функциональность в указанные сроки (хотя бы в плане проекта, который потом не соответствует действительности). В данном случае ошибка в том, что не исполнитель оценивает временные затраты, а заказчик устанавливает дату. Если времени для реализации требуемой функциональности явно недостаточно, то нужно выбирать: или урезанная функциональность в указанные сроки или смещение сроков для реализации полного объёма задач.
Также часто я наблюдала пожары, когда требования менялись в ходе проекта. Если не переписать план в связи с изменением требований, то вероятность своевременного окончания проекта невелика :)
Для тестировщиков, которые выполняют задачи по уже составленному менеджером плану, часто очень актуальной проблемой становится неполный учёт задач в плане. Например, часто забывают о том, что уходит время на новичков, на помощь разработчикам в воспроизведении дефектов, на подготовку тестовых данных, на подготовку внеплановых отчётов для руководства. Плохой анализ требований и спецификации может привести к тому, что в тест-кейсах будут присутствовать не все проверки, а, следовательно, будет неправильно оценено время на тестирование. Даже одна пропущенная строка в спецификации может послужить искрой, из которой вырастет пожар. Например, в требованиях сказано: «Система должна работать под ОС Win 98, 2000, XP, Vista». Если в тест-кейсах об этом нет ничего, то тестирование будет проводиться на любой доступной тестировщику ОС (XP, например). Дальше заказчик начинает принимать Систему (на 98-й, например) – и начинается… Неожиданные ошибки, перепроверка Приложения на всех требуемых ОС, исправление дефектов и т.д. Пожар на лицо :)
Допустим, оценка временных затрат проводилась компанией – разработчиком (а не заказчиком), в плане учтены все задачи ориентируясь на абстрактного среднестатистического тестировщика. Вроде, всё хорошо. Но и здесь могут возникнуть проблемы. Не все тестировщики одинаковые. У них может быть разная квалификация. Здесь можно рассмотреть несколько случаев:
– человек просто плохой работник: или он делает всё слишком медленно (гораздо медленнее, чем среднестатистический сотрудник отдела тестирования), или делает быстро, но так, что доверять результатам нельзя, или и то, и другое... Т.е. человек не на своём месте.
– новичок в профессии (в компании, на проекте) – понятно, что человеку нужно время на адаптацию, и его не сразу можно считать полноценным ресурсом.
– неправильных подбор персонала на проект или неправильное распределение задач внутри тестовой команды на проекте. Например, человек всё время занимался тестированием десктоповских приложений, и тут его назначают на тестирование приложений для мобильных технологий. Понятно, что нужно время на то, чтобы вникнуть в предметную область. Или другой пример: тестировщика, который всегда занимался мануальным тестированием, назначают на проект по автоматизации тестирования. Т.е. при назначении людей на проект и при распределении задач внутри команды тест-менеджер должен учитывать сильные и слабые стороны своих подчинённых. НО: нельзя всегда выдавать человеку однотипные задачи только потому, что он хорошо их выполняет. Рано или поздно тестировщику станет скучно :)
Как правило, задачи в планах плавно перетекают одна в другую, т.е. между ними нет перерывов. Но ведь часто возникают вынужденные простои. Например, увеличение сроков анализа, разработки и других предшествующих тестированию этапов ведёт к простою команды тестирования. Ещё одна причина простоя - блокирующая критическая ошибка, до исправления которой тестировать невозможно или нет смысла. Недоступность приложения также блокирует работу тестировщика. Причины недоступности приложения:
– недоступен сам сервер (сгорел, на нём проводят профилактические работы, например, увеличивают кол-во памяти);
– идёт установка новой версии приложения;
– на тестовой платформе разработчики проводят исследования и эксперименты;
– на тестовой платформе проводится нагрузочное тестирование;
– на тестовой платформе проводится приёмочное тестирование заказчиком.
Т.е. здесь возникает проблема взаимодействия команд тестирования, разработки, внедрения. Сюда же можно отнести проблему коммуникации между участниками проекта, которые находятся далеко друг от друга: в разных странах, а ещё хуже, в разных часовых поясах. Здесь увеличивается время на обсуждения и принятие решений. Также существует проблема «свободного» графика работы, который так популярен в IT сфере. Допустим, в команде есть носитель «тайных знаний», без которого «работа стоит». Если этот «тайный носитель» любит поспать, то плохо дело :) Нужно или передавать знания (а ещё лучше оформить их в виде документации), или договариваться о более строгом графике работы.
И в заключение причины «пожаров», которые предусмотреть сложно – это форс-мажорные обстоятельства. Например, авария на серверах, отсутствие электричества, отсутствие тестировщика на рабочем месте (заболел, уволился и т.п.).
Естественно, я не перечислила всех возможных причин отставаний от запланированных сроков. Главное, о чём я хотела рассказать: нельзя надеяться на то, что всё будет идти идеально. Хотя надеяться можно, но «соломку лучше подстелить», т.е. заложить в план риски. Нужно тщательно проанализировать тип проекта, его размеры и структуру, оценить команду и составить адекватный план, по которому будет комфортно работать. Не будет лишних переживаний ни у Вас, ни у заказчика :)
С Уважением,
Ольга Балашенко
Read more...
«Горящий» проект – не редкость в IT сфере. Отставание от плана может возникать на разных стадиях: от инициализации проекта до тестирования. Данный доклад - попытка ответить на вопрос: «Почему тестировщики не укладываются в сроки?».
Недавно мне «посчастливилось» принимать участие в проекте, на котором отставание от сроков – обычное дело. Сразу хочу пояснить, что я понимаю под отставанием от сроков. Это разница между реально потраченным и запланированным временем (см. рисунок 1).
В докладе рассматриваются причины невыполнения в срок задач тестовой команды, хотя многое из того, о чём будет говориться ниже, актуально для любых проектных активностей.
Несколько слов о проекте, который вдохновил меня на подготовку этого доклада. Проект был сложный… :) Причём, я сейчас говорю не о сложности задач, которые стояли перед нашей командой, а о сложной структуре проекта. На рисунке 2 представлена схема этого проекта, где З1...З8 – задачи, из которых состоит реализация проекта, К1…К8 – компании (подрядчики), которые принимают участие в проекте. Как видно, каждый подрядчик отвечает за свою задачу. И даже заказчик выполняет часть работ по созданию программного обеспечения.
Многое из того, о чём пойдёт речь дальше, навеяно именно этим сложным проектом, но также я использовала опыт участия в более простых проектах (Рисунок 3).
Думаю, понятно, что вероятность «пожаров» на проектах со сложной структурой больше. Естественно, здесь много зависимостей. Если один из подрядчиков на начальном этапе не уложился в сроки, то «поплывут» даты в планах у остальных компаний-подрядчиков. На сложном проекте часто возникает ситуация: «а это не я». Это когда на выявление ошибки уходит час, а на выявление ответственного за неё тратятся дни или даже недели. Каждая компания пытается сделать крайним кого-то другого. Такая проблема обычно возникает из-за плохой организации взаимодействия между участниками проекта и нечёткого разграничения обязанностей.
Теперь непосредственно о самих причинах. Одна из самых очевидных причин «пожаров» - нереальные сроки. Как эти «нереальные» сроки появляются? Например, заказчик говорит: «нужно, чтобы эта функциональность (F1...Fn) была готова к такому-то числу». И тут начинается попытка уместить всю требуемую функциональность в указанные сроки (хотя бы в плане проекта, который потом не соответствует действительности). В данном случае ошибка в том, что не исполнитель оценивает временные затраты, а заказчик устанавливает дату. Если времени для реализации требуемой функциональности явно недостаточно, то нужно выбирать: или урезанная функциональность в указанные сроки или смещение сроков для реализации полного объёма задач.
Также часто я наблюдала пожары, когда требования менялись в ходе проекта. Если не переписать план в связи с изменением требований, то вероятность своевременного окончания проекта невелика :)
Для тестировщиков, которые выполняют задачи по уже составленному менеджером плану, часто очень актуальной проблемой становится неполный учёт задач в плане. Например, часто забывают о том, что уходит время на новичков, на помощь разработчикам в воспроизведении дефектов, на подготовку тестовых данных, на подготовку внеплановых отчётов для руководства. Плохой анализ требований и спецификации может привести к тому, что в тест-кейсах будут присутствовать не все проверки, а, следовательно, будет неправильно оценено время на тестирование. Даже одна пропущенная строка в спецификации может послужить искрой, из которой вырастет пожар. Например, в требованиях сказано: «Система должна работать под ОС Win 98, 2000, XP, Vista». Если в тест-кейсах об этом нет ничего, то тестирование будет проводиться на любой доступной тестировщику ОС (XP, например). Дальше заказчик начинает принимать Систему (на 98-й, например) – и начинается… Неожиданные ошибки, перепроверка Приложения на всех требуемых ОС, исправление дефектов и т.д. Пожар на лицо :)
Допустим, оценка временных затрат проводилась компанией – разработчиком (а не заказчиком), в плане учтены все задачи ориентируясь на абстрактного среднестатистического тестировщика. Вроде, всё хорошо. Но и здесь могут возникнуть проблемы. Не все тестировщики одинаковые. У них может быть разная квалификация. Здесь можно рассмотреть несколько случаев:
– человек просто плохой работник: или он делает всё слишком медленно (гораздо медленнее, чем среднестатистический сотрудник отдела тестирования), или делает быстро, но так, что доверять результатам нельзя, или и то, и другое... Т.е. человек не на своём месте.
– новичок в профессии (в компании, на проекте) – понятно, что человеку нужно время на адаптацию, и его не сразу можно считать полноценным ресурсом.
– неправильных подбор персонала на проект или неправильное распределение задач внутри тестовой команды на проекте. Например, человек всё время занимался тестированием десктоповских приложений, и тут его назначают на тестирование приложений для мобильных технологий. Понятно, что нужно время на то, чтобы вникнуть в предметную область. Или другой пример: тестировщика, который всегда занимался мануальным тестированием, назначают на проект по автоматизации тестирования. Т.е. при назначении людей на проект и при распределении задач внутри команды тест-менеджер должен учитывать сильные и слабые стороны своих подчинённых. НО: нельзя всегда выдавать человеку однотипные задачи только потому, что он хорошо их выполняет. Рано или поздно тестировщику станет скучно :)
Как правило, задачи в планах плавно перетекают одна в другую, т.е. между ними нет перерывов. Но ведь часто возникают вынужденные простои. Например, увеличение сроков анализа, разработки и других предшествующих тестированию этапов ведёт к простою команды тестирования. Ещё одна причина простоя - блокирующая критическая ошибка, до исправления которой тестировать невозможно или нет смысла. Недоступность приложения также блокирует работу тестировщика. Причины недоступности приложения:
– недоступен сам сервер (сгорел, на нём проводят профилактические работы, например, увеличивают кол-во памяти);
– идёт установка новой версии приложения;
– на тестовой платформе разработчики проводят исследования и эксперименты;
– на тестовой платформе проводится нагрузочное тестирование;
– на тестовой платформе проводится приёмочное тестирование заказчиком.
Т.е. здесь возникает проблема взаимодействия команд тестирования, разработки, внедрения. Сюда же можно отнести проблему коммуникации между участниками проекта, которые находятся далеко друг от друга: в разных странах, а ещё хуже, в разных часовых поясах. Здесь увеличивается время на обсуждения и принятие решений. Также существует проблема «свободного» графика работы, который так популярен в IT сфере. Допустим, в команде есть носитель «тайных знаний», без которого «работа стоит». Если этот «тайный носитель» любит поспать, то плохо дело :) Нужно или передавать знания (а ещё лучше оформить их в виде документации), или договариваться о более строгом графике работы.
И в заключение причины «пожаров», которые предусмотреть сложно – это форс-мажорные обстоятельства. Например, авария на серверах, отсутствие электричества, отсутствие тестировщика на рабочем месте (заболел, уволился и т.п.).
Естественно, я не перечислила всех возможных причин отставаний от запланированных сроков. Главное, о чём я хотела рассказать: нельзя надеяться на то, что всё будет идти идеально. Хотя надеяться можно, но «соломку лучше подстелить», т.е. заложить в план риски. Нужно тщательно проанализировать тип проекта, его размеры и структуру, оценить команду и составить адекватный план, по которому будет комфортно работать. Не будет лишних переживаний ни у Вас, ни у заказчика :)
С Уважением,
Ольга Балашенко
Read more...
понедельник, 12 января 2009 г.
Вырасти себе тестировщика
По мотивам доклада на конференции SQA Days 2008 в Минске.
Мировой финансовый кризис оказывает значительное влияние на работу IT-компаний: сокращается количество потенциальных проектов и, соответственно, повышается конкуренция. В таких условиях компании вынуждены обратить особое внимание на обеспечение конкурентного преимущества, чтобы выжить и остаться на плаву. Приходится снижать ставки, и на первое место выходит продуктивность и эффективность работы каждого сотрудника. Решение проблемы заключается, с одной стороны, в оптимизации процессов работы компании и, с другой стороны, в развитии персонала.
Для того, чтобы процессы повышения продуктивности работы, обучения и развития были эффективными, они должны быть измеримыми. Для этого необходимо иметь точку отсчета.
За точку отсчета разумно принять оценку текущего состояния организации в целом и каждого сотрудника в частности.
В докладе рассматривается только одна сторона вопроса – тема оценки, аттестации, обучения и развития тестировщиков силами компании или силами внешних экспертов.
1. Оценка индивидуальной деятельности тестировщиков
Как и в любой другой деятельности, тестировщику важно понимать, что ему необходимо делать, чтобы его работа была эффективной.
С другой стороны, организации необходимо понимать, чего требовать от сотрудника, согласно каким критериям производить оценку его работы. Таким образом, перед руководителем отдела тестирования стоит задача в определении стандартов работы тестировщиков.
Достижение определенных стандартов также служит почвой для вознаграждения специалистов.
Независимо от того, какие критерии и стандарты индивидуальной работы используются, с самого начала их необходимо обсудить с тестировщиками, и получить их согласие и понимание. В этом случае, тестировщикам будет проще самостоятельно оценивать, соответствует ли их деятельность установленным критериям.
Таким образом, первый этап в развитии тестировщика – это постановка цели, которую нужно достичь, причем цель эта должна соответствовать небезызвестным критериям SMART (точная, измеримая, согласованная, реалистичная и ограниченная во времени).
Вторым шагом менеджер, совместно с тестировщиком, должен спланировать процесс достижения поставленной цели и определить необходимые для этого мероприятия.
И, конечно, нельзя оставлять спланированный процесс без наблюдения. Задачи, которые вы раздаете и не контролируете, могут не выполняться или выполняться с трудом.
Менеджер может использовать следующие методы мониторинга и оценки показателей персонала:
- Наблюдение и личное участие;
- Опрос и обсуждение;
- Регулярный сбор метрик;
- Другие отчеты;
- Аттестация – как оценка деятельности по истечении некоторого периода времени.
По результатам оценки могут быть предприняты различные действия:
- Продолжение работы без изменений
- Корректировка выполнения работы
- Пересмотр стандартов
Весь цикл выглядит следующим образом:
Регулярный обмен информацией создает у исполнителей ощущение собственной значимости, поддерживает в них ясное понимание того, что от них ожидается при выполнении порученной работы. Плюс ко всему, может использоваться для контроля показателей деятельности.
Когда работа выполняется хорошо, тестировщик должен получать позитивную обратную связь, если работа не соответствует ожиданиям, то обратная связь должна быть конструктивной (похвала сильных сторон и комментарии по слабым, с акцентом на то, как справиться с трудностями). Только в этом случае человек будет чувствовать себя ценимым, и, соответственно, будет мотивирован к достижению установленных показателей. Ибо незабота о персонале является сильным демотивирующим фактором, и ни о каком росте и развитии в этом случае не может быть и речи.
Обратная связь должна быть: уместная, справедливая и своевременная.
Регулярная и уместная обратная связь является основой для формальной аттестации.
2. Аттестация персонала
Аттестация – это формализованная обратная связь. В ходе этого мероприятия рассматриваются достижения и проблемы, подводятся итоги и строятся планы на будущее.
Выгодна она тем что:
- Подталкивает к осмыслению достижений и осознанию затруднений
- Определению направлений развития и карьерных устремлений
- Дает возможность мотивировать персонал
- Улучшать эффективность работы команды
- Улучшать обмен информацией
- И др.
Мы будем рассматривать только узкий аспект аттестации – оценка знаний и навыков тестировщиков с целью их дальнейшего развития. Все остальное – условия работы, соответствие трудовому договору, межличностные отношения и взаимодействие с другими людьми, управление временем и др. – в настоящей статье не затрагиваются.
И, кстати говоря, не рекомендуется использовать аттестацию для вознаграждения (хотя некоторые компании именно так и поступают). Первоначальная идея аттестации – создание дружественной атмосферы развития.
Стандартной процедуры проведения аттестации не существует, есть только некоторые общие принципы. Рассмотрим их.
Подготовка аттестации
Если организация тщательно готовилась к набору тестировщиков, то подготовка аттестации будет проводиться немного проще, нежели начинать ее с нуля.
Что необходимо сделать:
- Анализ работы. Должен ли тестировщик писать тестовую документацию, проводить статическое тестирование требований, писать скрипты, работать с определенными инструментами и т.д.?
- Анализ организации. Какие именно инструменты используются в организации, каковы процессы в организации (старт проекта по тестированию, передача программного обеспечения на тестирование, коммуникации внутри команды и др.), с какими заказчиками работает организация, какие проекты разрабатывает (веб, десктоп, специальные бизнес-области) и т.д.
- Должностная инструкция. На основании двух описанных видов анализа составляется должностная инструкция.
- Требования к исполнителю. На основании должностной инструкции определяются требования к тестировщику (или группе тестировщиков).
На основании результатов этих действий составляются анкеты, вопросники и готовятся аттестационные собеседования.
Тестировщики должны быть осведомлены о том, что будет проводиться аттестация, и ознакомлены с предъявляемыми требованиями.
Проведение аттестации: тесты и собеседования
Ранее уже упоминалось, что при проведении аттестации будем делать акцент на проверке знаний и навыков.
Для проверки знаний удобно использовать тесты. Желательно формулировать открытые вопросы, потому что ответ на закрытый вопрос можно легко угадать.
Проверку навыков с помощью тестов осуществить затруднительно. Поэтому в данном случае рекомендую проводить аттестационные собеседования (с выдачей, например, тестовых заданий или наблюдением за работой тестировщика на текущем проекте).
При отсутствии времени и/или навыков в составлении вопросников для проверки знаний также можно использовать аттестационные собеседования.
Обработка результатов, принятие решений
Результаты проведенных тестов и собеседований необходимо собрать и обработать. Для наглядности удобно составлять профиль по каждому человеку, выделяя области знаний и навыков.
При необходимости можно использовать и сводные таблицы для группы тестировщиков одной должности, или другие схемы визуализации.
Имея информацию в обработанном виде, необходимо ее проанализировать и принять решение о дальнейших действиях для развития конкретного специалиста по тестированию.
3. Разработка программ обучения
Что такое развитие? Это расширение способностей и навыков. Индивидуальное развитие должно увеличивать уверенность тестировщика в своих силах, его самосознание и знания. И в первую очередь, развитие – это ответственность самого человека.
Вы же, как менеджер, можете и должны содействовать развитию своих подчиненных. Для этого, как я уже говорила в самом начале, необходимо снова согласовать цели, установить, при необходимости, новые стандарты, а затем спланировать обучение. Вы должны выступать интегратором обучения своих тестировщиков на работе и вне ее.
Есть одна опасность – обучение ради обучения. Это означает, что вы готовите курсы, семинары, тренинги или отправляете подчиненных для обучения в незавичимых центрах, а тестировщики реально не используют полученные знания и навыки на практике. Поэтому компания тратит ресурсы, но не получает результата взамен, тестировщик – тоже.
Чтобы подобная ситуация не произошла, цели развития должны быть согласованными с самим тестировщиком. То есть после получения результатов аттестации задача менеджера выработать цели и программу развития совместно с тестировщиком, опираясь на способности, опыт, устремления специалиста, требования и возможности его текущей работы, а также на перспективы и будущие потребности самой организации.
Необходимо стремиться к тому, чтобы эти 3 диска максимально перекрывали друг друга. Только в этом случае мероприятия по развитию специалиста будут успешны и выгодны обеим сторонам.
4. Тренинги, семинары, наставничество
Необходимо понимать, что существуют различные виды обучения и предназначены они для разных целей.
Так, например:
- Курсы: очень похожи на академическое образование. Охватывают довольно большой объем материала, могут состоять из лекционных и семинарских частей, а также практических занятий.
- Семинары: направлены на прояснение узкого круга вопросов или же конкретного вопроса.
- Тренинги: направлены на развитие конкретных навыков.
- Наставничество: направлено на развитие конкретных навыков.
Что же выбрать для обучения своих тестировщиков?
Для ответа на этот вопрос разумно использовать обработанные результаты аттестации. Если из аттестационного профиля видно, что у тестировщика не хватает знаний, то необходимо по конкретным темам организовать семинары.
Если человеку нужны определенные навыки, то стоит сосредоточиться на их развитии посредством тренинга (если это несколько человек) или же назначить наставника (одному или нескольким тестировщикам).
Если же мы видим, что пробелов у тестировщика(ов) довольно много, то, возможно, имеет смысл подготовить даже обучающий курс.
P.S. Необходимо отметить, что описанная схема развития тестировщиков применима также и к другим специалистам. Важно в каждом конкретном случае использовать индивидуальный подход к вашему персоналу.
Всегда ваша,
Наташа Густыр
Read more...
Мировой финансовый кризис оказывает значительное влияние на работу IT-компаний: сокращается количество потенциальных проектов и, соответственно, повышается конкуренция. В таких условиях компании вынуждены обратить особое внимание на обеспечение конкурентного преимущества, чтобы выжить и остаться на плаву. Приходится снижать ставки, и на первое место выходит продуктивность и эффективность работы каждого сотрудника. Решение проблемы заключается, с одной стороны, в оптимизации процессов работы компании и, с другой стороны, в развитии персонала.
Для того, чтобы процессы повышения продуктивности работы, обучения и развития были эффективными, они должны быть измеримыми. Для этого необходимо иметь точку отсчета.
За точку отсчета разумно принять оценку текущего состояния организации в целом и каждого сотрудника в частности.
В докладе рассматривается только одна сторона вопроса – тема оценки, аттестации, обучения и развития тестировщиков силами компании или силами внешних экспертов.
1. Оценка индивидуальной деятельности тестировщиков
Как и в любой другой деятельности, тестировщику важно понимать, что ему необходимо делать, чтобы его работа была эффективной.
С другой стороны, организации необходимо понимать, чего требовать от сотрудника, согласно каким критериям производить оценку его работы. Таким образом, перед руководителем отдела тестирования стоит задача в определении стандартов работы тестировщиков.
Достижение определенных стандартов также служит почвой для вознаграждения специалистов.
Независимо от того, какие критерии и стандарты индивидуальной работы используются, с самого начала их необходимо обсудить с тестировщиками, и получить их согласие и понимание. В этом случае, тестировщикам будет проще самостоятельно оценивать, соответствует ли их деятельность установленным критериям.
Таким образом, первый этап в развитии тестировщика – это постановка цели, которую нужно достичь, причем цель эта должна соответствовать небезызвестным критериям SMART (точная, измеримая, согласованная, реалистичная и ограниченная во времени).
Вторым шагом менеджер, совместно с тестировщиком, должен спланировать процесс достижения поставленной цели и определить необходимые для этого мероприятия.
И, конечно, нельзя оставлять спланированный процесс без наблюдения. Задачи, которые вы раздаете и не контролируете, могут не выполняться или выполняться с трудом.
Менеджер может использовать следующие методы мониторинга и оценки показателей персонала:
- Наблюдение и личное участие;
- Опрос и обсуждение;
- Регулярный сбор метрик;
- Другие отчеты;
- Аттестация – как оценка деятельности по истечении некоторого периода времени.
По результатам оценки могут быть предприняты различные действия:
- Продолжение работы без изменений
- Корректировка выполнения работы
- Пересмотр стандартов
Весь цикл выглядит следующим образом:
Регулярный обмен информацией создает у исполнителей ощущение собственной значимости, поддерживает в них ясное понимание того, что от них ожидается при выполнении порученной работы. Плюс ко всему, может использоваться для контроля показателей деятельности.
Когда работа выполняется хорошо, тестировщик должен получать позитивную обратную связь, если работа не соответствует ожиданиям, то обратная связь должна быть конструктивной (похвала сильных сторон и комментарии по слабым, с акцентом на то, как справиться с трудностями). Только в этом случае человек будет чувствовать себя ценимым, и, соответственно, будет мотивирован к достижению установленных показателей. Ибо незабота о персонале является сильным демотивирующим фактором, и ни о каком росте и развитии в этом случае не может быть и речи.
Обратная связь должна быть: уместная, справедливая и своевременная.
Регулярная и уместная обратная связь является основой для формальной аттестации.
2. Аттестация персонала
Аттестация – это формализованная обратная связь. В ходе этого мероприятия рассматриваются достижения и проблемы, подводятся итоги и строятся планы на будущее.
Выгодна она тем что:
- Подталкивает к осмыслению достижений и осознанию затруднений
- Определению направлений развития и карьерных устремлений
- Дает возможность мотивировать персонал
- Улучшать эффективность работы команды
- Улучшать обмен информацией
- И др.
Мы будем рассматривать только узкий аспект аттестации – оценка знаний и навыков тестировщиков с целью их дальнейшего развития. Все остальное – условия работы, соответствие трудовому договору, межличностные отношения и взаимодействие с другими людьми, управление временем и др. – в настоящей статье не затрагиваются.
И, кстати говоря, не рекомендуется использовать аттестацию для вознаграждения (хотя некоторые компании именно так и поступают). Первоначальная идея аттестации – создание дружественной атмосферы развития.
Стандартной процедуры проведения аттестации не существует, есть только некоторые общие принципы. Рассмотрим их.
Подготовка аттестации
Если организация тщательно готовилась к набору тестировщиков, то подготовка аттестации будет проводиться немного проще, нежели начинать ее с нуля.
Что необходимо сделать:
- Анализ работы. Должен ли тестировщик писать тестовую документацию, проводить статическое тестирование требований, писать скрипты, работать с определенными инструментами и т.д.?
- Анализ организации. Какие именно инструменты используются в организации, каковы процессы в организации (старт проекта по тестированию, передача программного обеспечения на тестирование, коммуникации внутри команды и др.), с какими заказчиками работает организация, какие проекты разрабатывает (веб, десктоп, специальные бизнес-области) и т.д.
- Должностная инструкция. На основании двух описанных видов анализа составляется должностная инструкция.
- Требования к исполнителю. На основании должностной инструкции определяются требования к тестировщику (или группе тестировщиков).
На основании результатов этих действий составляются анкеты, вопросники и готовятся аттестационные собеседования.
Тестировщики должны быть осведомлены о том, что будет проводиться аттестация, и ознакомлены с предъявляемыми требованиями.
Проведение аттестации: тесты и собеседования
Ранее уже упоминалось, что при проведении аттестации будем делать акцент на проверке знаний и навыков.
Для проверки знаний удобно использовать тесты. Желательно формулировать открытые вопросы, потому что ответ на закрытый вопрос можно легко угадать.
Проверку навыков с помощью тестов осуществить затруднительно. Поэтому в данном случае рекомендую проводить аттестационные собеседования (с выдачей, например, тестовых заданий или наблюдением за работой тестировщика на текущем проекте).
При отсутствии времени и/или навыков в составлении вопросников для проверки знаний также можно использовать аттестационные собеседования.
Обработка результатов, принятие решений
Результаты проведенных тестов и собеседований необходимо собрать и обработать. Для наглядности удобно составлять профиль по каждому человеку, выделяя области знаний и навыков.
При необходимости можно использовать и сводные таблицы для группы тестировщиков одной должности, или другие схемы визуализации.
Имея информацию в обработанном виде, необходимо ее проанализировать и принять решение о дальнейших действиях для развития конкретного специалиста по тестированию.
3. Разработка программ обучения
Что такое развитие? Это расширение способностей и навыков. Индивидуальное развитие должно увеличивать уверенность тестировщика в своих силах, его самосознание и знания. И в первую очередь, развитие – это ответственность самого человека.
Вы же, как менеджер, можете и должны содействовать развитию своих подчиненных. Для этого, как я уже говорила в самом начале, необходимо снова согласовать цели, установить, при необходимости, новые стандарты, а затем спланировать обучение. Вы должны выступать интегратором обучения своих тестировщиков на работе и вне ее.
Есть одна опасность – обучение ради обучения. Это означает, что вы готовите курсы, семинары, тренинги или отправляете подчиненных для обучения в незавичимых центрах, а тестировщики реально не используют полученные знания и навыки на практике. Поэтому компания тратит ресурсы, но не получает результата взамен, тестировщик – тоже.
Чтобы подобная ситуация не произошла, цели развития должны быть согласованными с самим тестировщиком. То есть после получения результатов аттестации задача менеджера выработать цели и программу развития совместно с тестировщиком, опираясь на способности, опыт, устремления специалиста, требования и возможности его текущей работы, а также на перспективы и будущие потребности самой организации.
Необходимо стремиться к тому, чтобы эти 3 диска максимально перекрывали друг друга. Только в этом случае мероприятия по развитию специалиста будут успешны и выгодны обеим сторонам.
4. Тренинги, семинары, наставничество
Необходимо понимать, что существуют различные виды обучения и предназначены они для разных целей.
Так, например:
- Курсы: очень похожи на академическое образование. Охватывают довольно большой объем материала, могут состоять из лекционных и семинарских частей, а также практических занятий.
- Семинары: направлены на прояснение узкого круга вопросов или же конкретного вопроса.
- Тренинги: направлены на развитие конкретных навыков.
- Наставничество: направлено на развитие конкретных навыков.
Что же выбрать для обучения своих тестировщиков?
Для ответа на этот вопрос разумно использовать обработанные результаты аттестации. Если из аттестационного профиля видно, что у тестировщика не хватает знаний, то необходимо по конкретным темам организовать семинары.
Если человеку нужны определенные навыки, то стоит сосредоточиться на их развитии посредством тренинга (если это несколько человек) или же назначить наставника (одному или нескольким тестировщикам).
Если же мы видим, что пробелов у тестировщика(ов) довольно много, то, возможно, имеет смысл подготовить даже обучающий курс.
P.S. Необходимо отметить, что описанная схема развития тестировщиков применима также и к другим специалистам. Важно в каждом конкретном случае использовать индивидуальный подход к вашему персоналу.
Всегда ваша,
Наташа Густыр
Read more...
четверг, 8 января 2009 г.
Урок 49: People-based техники фокусируются на том, кто проводит тестирование.
Lessons Learned in Software Testing
Авторы: Cem Kaner, James Bach и Bret Pettichord
Перевод: Сергей Талалаев
Вот несколько примеров таких техник, отличающихся исполнителями.
Пользовательское тестирование / User testing. Тестирование людьми, которые обычно используют ваш продукт. Пользовательское тестирование может выполняться в любой момент разработки на вашей стороне или их, в строгом соответствии с подготовленными сценариями или на усмотрение пользователя. Некоторым видам пользовательского тестирования, таким как анализ задач, больше подходит совместное исследование (с привлечением как минимум одного пользователя и одного члена вашей тестовой команды), чем тестирование одним человеком.
Альфа тестирование / Alpha testing. Внутреннее тестирование, выполняемое тестовой командой (и возможно другими заинтересованными, внутренними ресурсами).
Бета тестирование / Beta testing. Это вид пользовательского тестирования, проводимый потенциальными пользователями вашего продукта, а не тестировщиками вашей компании. Разработка тестирумого продукта обычно близка к завершению. Многие компании рассматривают любую передачу предрелизного кода клиенту как бета-тестирование; они обозначают все бета-тесты как "бета". Это ошибка. В действительности существует множество различных типов бета-тестов. Дизайн-бета тестирование, требующее от пользователей (в первую очередь экспертов) оценки дизайна, должно быть проведено как можно раньше, чтобы оставить время для внесения изменений по результатам тестирования. Маркетинг-бета тестирование, проводимое с целью убедить крупных клиентов в необходимости приобретения данного продукта и установки его на своих крупных сетях, должно проводиться существенно позже, когда продукт уже достаточно стабилен. При проведении бета-теста совместимости ваш клиент запускает ваш продукт на аппаратных и програмных платформах, полноценное тестирование на которых было сложным для вас. Данный вид тестирования должен проводиться до того момента, когда уже слишком поздно выявлять и исправлять проблемы совмеcтимости. Для любых типов бета-тестирования, которые вы проводите, вы должны сначала определить цели тестирования и лишь затем принимать решения о том, как и когда вы будете его проводить.
Баг-штурм / Bug bashes. Внутреннее тестирование с привлечением секретарей, программистов, менеджеров по продажам и всех, кто доступен. Обычный баг-штурм занимает пол-дня и проводится, когда продукт близок к релизу. (Замечание: мы рассматриваем данную технику в качестве примера, не настаивая на ней. Некоторые компании находят её полезной по различным причинам, другие - нет.)
Тематическое экспертное тестирование / Subject-matter expert testing. Передача продукта эксперту для проверки некоторых проблем, возникших с продуктом и требующих детального анализа (дефектов, замечаний и дополнений). Эксперт может и не являться возможным пользователем вашего продукта, ценность эксперта - это его знания, а не его значимость как потенциального покупателя.
Парное тестирование / Paired testing. Два тестировщика работают вместе над поиском ошибок. Обычно они делят один компьютер во время тестирования.
"Ешьте сами свою заливную рыбу" / Eat your own dogfood. Ваша компания использует предрелизную версию своего продукта, обычно дожидаясь, когда продукт станет достаточно устойчив для реальной работы до начала его продаж.
Read more...
вторник, 6 января 2009 г.
Видео конференции SQA Days 2008 в Минске
Друзья!
Уже совсем скоро на ресурсе it-conf появится видео всех докладов.
В настоящий момент готовы видеоролики всех докладов 2-й секции, а также некоторых флип-чартов и частично вступлений 1-й секции.
Всем, кто не был на конференции, очень советую посмотреть видео - ощутите себя полноценным участником, за тем небольшим исключением, что всего лишь не будет возможности задать вопросы докладчикам.
Всем, кто присутствовал на конференции, советую посмотреть доклады еще раз. Таким образом можно освежить материалы в памяти и сделать акценты на тех вещах, которые остались за гранью вашего внимания при первом прослушивании.
Всегда ваша,
Наташа Густыр
Read more...
Уже совсем скоро на ресурсе it-conf появится видео всех докладов.
В настоящий момент готовы видеоролики всех докладов 2-й секции, а также некоторых флип-чартов и частично вступлений 1-й секции.
Всем, кто не был на конференции, очень советую посмотреть видео - ощутите себя полноценным участником, за тем небольшим исключением, что всего лишь не будет возможности задать вопросы докладчикам.
Всем, кто присутствовал на конференции, советую посмотреть доклады еще раз. Таким образом можно освежить материалы в памяти и сделать акценты на тех вещах, которые остались за гранью вашего внимания при первом прослушивании.
Всегда ваша,
Наташа Густыр
Read more...
понедельник, 5 января 2009 г.
Перевод глоссария ISTQB на русский язык
Проект реализован силами участников портала Software-Testing.RU, в числе которых нахожусь и я, Наташа Густыр, под руководством Сергея Гринкевича.
Также готовый перевод Глоссария можно найти здесь. Авторами этого перевода является рабочая группа RSTQB в составе трех человек:
Андрей Конушин (Россия)
Алексей Александров (Россия)
Александр Александров (Россия)
Read more...
Подписаться на:
Сообщения (Atom)
