Сообщений в теме: 22

[Green]

Коллеги!

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

Очень бы хотелось посмотреть. Буду благодарен за ссылку.

[Vasiliy]

А такой вообще есть?
Может проще кинуть клич тут и собрать список операций форумчан, который потом можно систематизировать?

[Green]

Это тоже вариант.
Но может это уже сделали за нас.

[rlabs]

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

Смету пишете?

[van]

Сергей,

Ни разу не встречал описание должностных обязанностей с таким уровнем детализации :)

Если на у ровень выше (планирование..., оценка..., выполнение..., мотивация... и т.п.), то пожалуйста:
- на форуме есть много тем, посвященных этому вопросу;
- вакансий, в которых тоже полезные вещи пишут;
- резюме специалистов с перечнем responsibilities.

[Green]

Сергей,

Ни разу не встречал описание должностных обязанностей с таким уровнем детализации :)

Если на у ровень выше (планирование..., оценка..., выполнение..., мотивация... и т.п.), то пожалуйста:
- на форуме есть много тем, посвященных этому вопросу;
- вакансий, в которых тоже полезные вещи пишут;
- резюме специалистов с перечнем responsibilities.

А вот и не угадал!
Но попытка хорошая.

[Green]

Идея заключается в следующем.

Сейчас мне приходится проводить аудит процессов тестирования в разных подразделениях. Как его делать? Методика очень проста. Есть перечени производственных операций, документов, обязанностей и т.п. Берем эти перечни и сравниваем с тем, что есть. Если есть - галочка, если нет - прочерк. Затем разбираемся с тем, чего нет. Почему нет и как это влияет на результат. Затем переходим к тому, что есть. На сколько хорошо делается то, что есть и какова степень влияния на результат. В итоге собираем все вместе и делаем вывод. В завершении аудита делаем вывод что и когда должно быть сделано.

Вот так.

Начальный список есть. Но он доморощенный, а хотелось бы получить объективный список действий, которые тестировщики выполняют на проекте. Ясно, что будут спорные моменты. Например, поддержание тестового окружения. Тестировщики могут за него отвечать, а могут и нет (особенно в тех компаниях, где существует тестовая лаборатория).

Тем не менее список действий, которые точно должен выполнять тестировщик, всегда конечен и его можно сформулировать.

[van]

Что именно не угадал? :)

Предлагаю сделать следующим образом: напиши пожалуйста свои "доморощенный" список, а общественность присоединится :)

Уверен, что так дело веселей пойдет!

[Clauster]

А чтение форума к каким операциям можно отнести?
Как-никак, а косвенным образом на проект влияет

PS Ох уж этот CMMI! :)

[idunin]

[offtop]

Сейчас мне приходится проводить аудит процессов тестирования в разных подразделениях. Как его делать? Методика очень проста. Есть перечени производственных операций, документов, обязанностей и т.п.

Я, конечно, понимаю что яйца курицу не учат , но не мог промолчать. Очень интересная статья лежит на сайте: Аудит у Прокруста (Автор: Юрий Горюнов)
Вот, мне кажется что Вы собрались делать именно то, что описано в данной статье.
Заранее прошу прощения, если не правильно понял, то, что Вы собираетесь делать.
[offtop]

И кстати, сразу вопрос. Зачем нужна такая подгонка под то, что кому и как делать? Только ли для стандартизации?
Ведь если у людей процесс налажен, по мере возможности они его совершенствуют, добиваются результатов, но вот допустим какой-то человек делает несколько операций, которые по стандарту делать не должен. То фирме стандартизация не светит?
Да, забыл добавить условие, что этот человек с обязанностями, которые он по стандарту не должен делать прекрасно справляется и также их совершенствует.

[Fisher]

Привет, Сергей.

Я как-то отсканировал декомпозицию работ по тестированию из одной известной книжки.
Файл - прилагается.

Прикрепленные файлы

•  Декомпозиция_работ_по_тестированию__черновик_.doc   83,5К   394 Количество загрузок:

[Green]

[offtop]

Сейчас мне приходится проводить аудит процессов тестирования в разных подразделениях. Как его делать? Методика очень проста. Есть перечени производственных операций, документов, обязанностей и т.п.

Я, конечно, понимаю что яйца курицу не учат , но не мог промолчать. Очень интересная статья лежит на сайте: Аудит у Прокруста (Автор: Юрий Горюнов)
Вот, мне кажется что Вы собрались делать именно то, что описано в данной статье.
Заранее прошу прощения, если не правильно понял, то, что Вы собираетесь делать.
[offtop]

И кстати, сразу вопрос. Зачем нужна такая подгонка под то, что кому и как делать? Только ли для стандартизации?
Ведь если у людей процесс налажен, по мере возможности они его совершенствуют, добиваются результатов, но вот допустим какой-то человек делает несколько операций, которые по стандарту делать не должен. То фирме стандартизация не светит?
Да, забыл добавить условие, что этот человек с обязанностями, которые он по стандарту не должен делать прекрасно справляется и также их совершенствует.

Все очень просто.

К примеру, вы - автомеханик и вас попросили проверить машину - что-то в ней барахлит и это не нравится владельцу. В чем проблема, он не знает. "Чувствует, что дело бесовское, а объяснить не может".

И обращается он к вам. Помоги, мол, добрый молодец, а я тебе буду благодарен.

Отчего же не помочь, думаешь ты (а что бы ты правильно думал, деректор гаража помогает тебе определиться). И помогаешь.

Итак, помогаем. Но что делать? Самый простой способ окинуть все взглядом и сравнить с тем, как должно быть. Легко!

Но тут вмешивается человеческий фактор - субъективность мнения и сила авторитета и т.п. Того, кто приносит плохие новости - убивают. Что бы избежать этой участи, нужно "соломку подстелить" в виде мнения авторитетов, стандартов и других помошников консультанта. И уже это не ты плохие новости приносишь, а сами дураки, что авторитетов не читаете и стандарты не изучаете.

[idunin]

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

[barancev]

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

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

Почему так происходит?

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

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

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

[Green]

Чем является программирование, как впрочем и тестирование? Творчеством или набором стандартный операций?

На этот счет есть отличная статья у Джоела Спольски. Я с ним полностью согласен, что программирование - это дизайн. Тестирование - так же является дизайнерской операцией.

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

У нас все так же. Есть набор стандартных операций. К примеру, телефонные переговоры с представителем заказчика. И, не зависимо от желания проектной команды или руководителя, это операция должна выполняться. Кто ее будет выполнять? Какие вопросы могут быть и должны быть обсуждены на таких виртуальных встречах? Как распределяется уровень компетенций по решению сложных или граничных вопросов на таких митингах? И таких вопросов может быть большое количество. Так вот, креатив заключается в том, насколько хорошо и качественно будет выполняться операция "Телефонные переговоры", а заодно и другие. Но избежать ее не представляется возможным.

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

Вот именно о таких кирпичиках, которые ДОЛЖНЫ быть выполнены или МОГУТ выполняться в тестировочном проекте, я спрашиваю.


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

[Green]

Привожу список операций, которые получились у нас.

Обозначения:
ТМ - тест менеджер
ТЕ - тест инженер
Rollout plan - документ, описывающий установку программы


Activity - Roles
Review requirements - TM, TE
Create Test Strategy - TM
Estimate / schedule testing activities - TM
Create Test Cases - TM, TE
Create Test Data - TM, TE
Create automated tests - ТЕ
Create traceability matrixes - TM, TE
Define and Prepare test environments - TE
Assign test tasks - TM
Execute test cases - TM, TE
Perform exploration testing - TM, TE
Perform automated tests - ТЕ
Register Bugs - TM, TE
Prepare test logs - TM, TE
Prepare weekly test reports - TM
Prepare TERs (Test execution reports) - TM
Update documentation (test cases, data, plans, traceability matrixes) - TM, TE
Production issues registration, tracking, reproducing - TM
Perform process setting and improvement - TM
Supervising the team - TM
Newcomers trainings - TM
Test team meetings - TM
Holding meetings with development team and onsite analyst - TM
Holding meetings with Customer representatives - TM
Communication with Customer - TM
Rollout plan review - TM
Independent build instalation on test environment - TE

[Green]

Привет, Сергей.

Я как-то отсканировал декомпозицию работ по тестированию из одной известной книжки.
Файл - прилагается.

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

[van]

Привет, Сергей.

Я как-то отсканировал декомпозицию работ по тестированию из одной известной книжки.
Файл - прилагается.

Что - то не открывается у меня файлик...

[van]

Сергей, привет!

Спасибо за предоставленый список.
Я внесу свои 5 копеек и напишу список тестовых активностей, который я составлял при разработке должностных инструкций.

Времени не очень много, поэтому я не стал их фильтровать на предмет того, что у тебя уже написано (почти все у тебя есть, но пару - тройку моментов можно будет добавить):

TestManager:
 Выработка стратегии тестирования;
 Разработка планов тестирования;
 Написание и согласование документов, регламентирующих организацию работ по тестированию;
 Постановка задач, связанных с тестированием;
 Осуществление контроля за процессом тестирования;
 Координация деятельности группы тестирования с другими участниками проекта;
 Критический просмотр тестовых процедур;
 Анализ и обсуждение способов тестирования;
 Решение спорных вопросов с разработчиками;
 Сбор данных и составление отчётов о статусе тестирования и имеющихся проблемах;
 Поиск и подбор тестировщиков;
 Обучение новых сотрудников;
 Постоянное совершенствование процесса тестирования.

Test Engineer:
 Разработка тестовых процедур и совокупности тестовых данных на основе требований;
 Проектирование тестов;
 Исполнение тестовых процедур вручную;
 Проведение тестирования и составление отчетов о ходе тестирования;
 Строгое соблюдение стандартов тестирования;
 Составление отчетов о имеющихся проблемах;
 Анализ и обсуждение способов тестирования;
 Обсуждение дефектов;
 Анализ документации на продукт, предназначенный для тестирования.