Перейти к содержимому

Фотография

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


  • Авторизуйтесь для ответа в теме
Сообщений в теме: 60

#21 Олешка

Олешка

    Консультант

  • Members
  • PipPipPipPip
  • 497 сообщений
  • ФИО:Ольга
  • Город:Рига, Латвия

Отправлено 25 сентября 2003 - 10:42

С разработчиков? Пардон, а как разработчик влияет на окружение?

С разработчиков - означает с команды проекта, которая должна иметь в своем составе документатора. Если его нет - см. мое сообщение еще раз. Требования же должны быть собраны до того, как вы вообще начнете что-то делать. Потом их можно уточнять.
  • 0

#22 Case

Case

    Основатель

  • Members
  • PipPipPipPipPipPip
  • 7 071 сообщений
  • ФИО:Панкратов Вячеслав
  • Город:Украина, Киев.

Отправлено 25 сентября 2003 - 10:43

To case: Вероятно, у Вас процесс не поставлен. Вот и не работает. У нас - работает.

Какой процесс именно?
У вас тестировщик что делает? Получает всё на входе. что вы перечислили от разработчиков?
  • 0
Слава Панкратов
Редактор портала www.it4business.ru

#23 Олешка

Олешка

    Консультант

  • Members
  • PipPipPipPip
  • 497 сообщений
  • ФИО:Ольга
  • Город:Рига, Латвия

Отправлено 25 сентября 2003 - 10:46

Какой процесс именно?
У вас тестировщик что делает? Получает всё на входе. что вы перечислили от разработчиков?


Продукт просто не принимается на тестирование, если к нему не дают перечисленную мной документацию. Это решается на уровне менеджера проекта и менеджера команды тестировщиков.

Задача тестировщика - составить план тестирования, придумать тесты, выполнить их и отчитаться. Все.
  • 0

#24 Case

Case

    Основатель

  • Members
  • PipPipPipPipPipPip
  • 7 071 сообщений
  • ФИО:Панкратов Вячеслав
  • Город:Украина, Киев.

Отправлено 25 сентября 2003 - 10:50

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

Канечно Ваш случай, когда есть всё указанное в документации приводит процесс в нормальное состояние, только вот проблема чуть глубже - вы говорите о качественно ином уровне процесса. зачастую, а тем паче на самых первых шагах построения системы каества этого всего просто нет, так же как и процесса версионности, билдов и так далее.
  • 0
Слава Панкратов
Редактор портала www.it4business.ru

#25 Case

Case

    Основатель

  • Members
  • PipPipPipPipPipPip
  • 7 071 сообщений
  • ФИО:Панкратов Вячеслав
  • Город:Украина, Киев.

Отправлено 25 сентября 2003 - 10:52

Хм, у вас может даже и очень удобный подход для отдела тестирования.
Только мне упорно не понятна формулировка "не принимается на тестирование".
У вас настолько оторванные отделы/направления?
Разработчики что-то делают (читай _сами тестят_) потом пишут документацию, пишут инсталл, потом только отдают на тестирование?! Ух. А не боитесь? Это ж какие затраты на исправление ошибок нужны!

Я как-то вижу процесс тестирования неотрывным от процесса разработки, тогда такого понятия как принять на тестирование продукт просто нет.
  • 0
Слава Панкратов
Редактор портала www.it4business.ru

#26 Олешка

Олешка

    Консультант

  • Members
  • PipPipPipPip
  • 497 сообщений
  • ФИО:Ольга
  • Город:Рига, Латвия

Отправлено 25 сентября 2003 - 10:52

Что она делает давайте сразу говорить, а то мы полдня только на терминологию теряем.

Группа контроля качества на выходе принимает продукт на тестирование от команды проекта. При продукте идет вся необходимая документация. Эта группа начинает работать от первого работоспособного релиза, создает свои тесты и выполняет их, оценивая качество продукта с точки зрения его стабильности и работающей функциональности.
  • 0

#27 Олешка

Олешка

    Консультант

  • Members
  • PipPipPipPip
  • 497 сообщений
  • ФИО:Ольга
  • Город:Рига, Латвия

Отправлено 25 сентября 2003 - 10:55

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

Есть входные критерии для продукта - должна быть документация, должны быть известны все исправленные баги, и все добавленные новые фичи. Само собой, проекту должна быть присвоена следующая версия. Должны быть известны все изменения в окружении приложения, в его конфигурации и т.д.
  • 0

#28 Олешка

Олешка

    Консультант

  • Members
  • PipPipPipPip
  • 497 сообщений
  • ФИО:Ольга
  • Город:Рига, Латвия

Отправлено 25 сентября 2003 - 10:58

To case: Команда проекта - только разработчики? Тогда, конечно, сложно будет.
  • 0

#29 Олешка

Олешка

    Консультант

  • Members
  • PipPipPipPip
  • 497 сообщений
  • ФИО:Ольга
  • Город:Рига, Латвия

Отправлено 25 сентября 2003 - 11:01

Я как-то вижу процесс тестирования неотрывным от процесса разработки, тогда такого понятия как принять на тестирование продукт просто нет.

Мы можем принять продукт на тестирование в любом состоянии. Например, есть версия 0.0.0.1, в которой работает только 1 модуль из запланированного. Этот модуль и будет тестироваться и в соответствущей документации это будет отражено. Пока работают тестировщики, программеры подготовили версию 0.0.0.2, куда включили красивый интерфейс. Замечательно, мы берем на тестирование, оформляйте все изменения, и вперед. Если же нам не сообщат об этом замечательном интерфейсе, мы его, конечно, заметим, но вот вопрос - все ли его свойства будут проверены? Определенная дисциплина с документацией тут нужна. Если не будет обмена информацией, тестировщики работают вслепую.
  • 0

#30 Case

Case

    Основатель

  • Members
  • PipPipPipPipPipPip
  • 7 071 сообщений
  • ФИО:Панкратов Вячеслав
  • Город:Украина, Киев.

Отправлено 25 сентября 2003 - 11:11

Безусловно нужна, безусловно.
У вас очень формально построен процесс - и это очень даже хорошо. Я просто посмотрел на него с точки зреня управления и скажу чесно, я не хотел бы руководить им в сжатые сроки и отвечать за его качество.
Повторюсь, вопрос заданный meol насколко я понял относился к другой ситуации. Есть желание наладить процесс тестирования. Тут ваши рекомендации не сработают, ибо сам процесс разработки стоит не на том уровне.
Давайте уточним у meol-а, насколько кто из нас прав?
  • 0
Слава Панкратов
Редактор портала www.it4business.ru

#31 Олешка

Олешка

    Консультант

  • Members
  • PipPipPipPip
  • 497 сообщений
  • ФИО:Ольга
  • Город:Рига, Латвия

Отправлено 25 сентября 2003 - 11:18

To case:

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

Конечно, посмотрим, что meol скажет.
  • 0

#32 el-step

el-step

    Активный участник

  • Members
  • PipPip
  • 76 сообщений
  • Город:Москва

Отправлено 25 сентября 2003 - 12:25

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

#33 Case

Case

    Основатель

  • Members
  • PipPipPipPipPipPip
  • 7 071 сообщений
  • ФИО:Панкратов Вячеслав
  • Город:Украина, Киев.

Отправлено 25 сентября 2003 - 12:57

Надеюсь так же, что разьясню для себя определённые моменты.
А можно будет по пути следования повествования задавать вопросы? А то у меня их много.
  • 0
Слава Панкратов
Редактор портала www.it4business.ru

#34 Олешка

Олешка

    Консультант

  • Members
  • PipPipPipPip
  • 497 сообщений
  • ФИО:Ольга
  • Город:Рига, Латвия

Отправлено 25 сентября 2003 - 13:24

Хммм.. с самого начала - можно попытаться. По наличии времени. Вопросы - можно и сейчас выкладывать.
  • 0

#35 Case

Case

    Основатель

  • Members
  • PipPipPipPipPipPip
  • 7 071 сообщений
  • ФИО:Панкратов Вячеслав
  • Город:Украина, Киев.

Отправлено 25 сентября 2003 - 13:40

Тогда не получится изложения :)
У меня к примеру еть вопросы о целесообразости такого подхода и модели разработки/тестирования. В принципе ведь классический водопад получается. Проектирование-разработка/документирование-тестирование. Стоимость внесения изменений в такой модели растёт экспоненциально. Как вы боретесь с ростущими затратами (я не о материальных затратах, о ресурсах).
  • 0
Слава Панкратов
Редактор портала www.it4business.ru

#36 Олешка

Олешка

    Консультант

  • Members
  • PipPipPipPip
  • 497 сообщений
  • ФИО:Ольга
  • Город:Рига, Латвия

Отправлено 25 сентября 2003 - 15:26

Попробую по порядку. Начиналось все с проекта, в котором были проблемы с качеством, не было документатора и не было тестировщика. На этом этапе был накоплен некий потенциал знаний о том, как должен идти процесс тестирования и решили - почему бы не попробовать это реализовать. Кстати, собирали эти знания сами, по статьям, Интернету, книгам, стандартам. Да, так вот - первое, что было сделано - была составлена функциональная спецификация на этот проект. Дальше эта спецификация была утверждена у менеджера проекта, предоставлена клиенту и корректировалась мною при каждом изменении функциональности. Следующим шагом была разработка тестового плана по той самой спецификации и налаживание регулярной поставки версии на тестирование перед тем как отдавать клиенту. Одновременно мы стали использовать bug tracking. Наладился некий ритм - клиент просит внести изменения - это фиксируется в спецификации. Пока программисты делают эти изменения, у меня есть время на планирование самих тестов. После первых нескольких прогонов появились оценки по времени - сколько надо, чтобы прогнать все регрессионные тесты. Следующий шаг - работа вместе с программистами, то есть проверять их исправления до того как продукт собран в поставляемую клиенту версию. Накопились и тесты. Дальше стали работать по схеме:
за два-три дня до поставки на тестирование менеджером проекта проводится оценка объема работ, исправлений и улучшений. Поставка - еженедельная. Запланированные изменения жестко фиксируются - к поставке сделать только то-то и то-то. Вносятся изменения в спецификацию и тестировщик сразу планирует тесты на эти изменения и все области, которые их затронули. Дальше идет реализация намеченного, сборка и поставка на тестирование. Потом - проверка изменений/исправлений - регистрация найденных ошибок - определение пакета критических багов - выполнение исправлений - проверка этих исправлений - если все ок - прогон регрессиннного пакета тестов (el-step, читай - приемочного) и сдача клиенту релиза с отчетом тестировщиков.
  • 0

#37 meol

meol

    Новый участник

  • Members
  • Pip
  • 23 сообщений

Отправлено 26 сентября 2003 - 03:45

to Case

Повторюсь, вопрос заданный meol насколко я понял относился к другой ситуации.

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

Теперь о сжатых сроках: при правильной расстановке рисков и приоритетов проблема решаема IMHO.

На счет QA согласна с Case - QA department занимается другими задачами, например - разработка, документирование и внедрение нормативов производственных процессов, контроль качества производственных процессов.

To Oleshka
Тестировщик внутри проекта и тестировщик команды QA - как бы находятся по разные стороны барикад...т.е. они работают отдельно друг от друга.
Или не так? QA тестировщик создает свои тесты или все-таки использует наработки проектного тестировщика? На ком из них лежит задача создание тест плана?
Вобщем мне осталось непонятным разделение задач между QA тестером и командным тестером, и их взаимодействие.

To Case
Безусловно тестировщик может выполнять обширный круг задач в проекте - выработка требований, написание use cases, руководства пользователей...Просто потому, что больше некому. Однако это всего лишь распределение ролей в команде. Цель у всех одна - более качественный продукт на выходе.
Без формализации* процесса и разделения задач и обязанностей м/у всеми участниками команды (постановщики, разработчики, тестеры, QA) должного качества не получится.

*но разумеется в разумных пределах, чтобы не было лишней работы и как следствие лишних затрат
  • 0

#38 Case

Case

    Основатель

  • Members
  • PipPipPipPipPipPip
  • 7 071 сообщений
  • ФИО:Панкратов Вячеслав
  • Город:Украина, Киев.

Отправлено 26 сентября 2003 - 06:21

Oleshka, тама это :) Тема есть отдельная, для тех "кто помнит как всё начиналось" :)
Или продолжим тут?
  • 0
Слава Панкратов
Редактор портала www.it4business.ru

#39 Олешка

Олешка

    Консультант

  • Members
  • PipPipPipPip
  • 497 сообщений
  • ФИО:Ольга
  • Город:Рига, Латвия

Отправлено 26 сентября 2003 - 06:58

Да можно и перенести. Куда?
  • 0

#40 Олешка

Олешка

    Консультант

  • Members
  • PipPipPipPip
  • 497 сообщений
  • ФИО:Ольга
  • Город:Рига, Латвия

Отправлено 26 сентября 2003 - 07:06

На счет QA согласна с Case - QA department занимается другими задачами, например - разработка, документирование и внедрение нормативов производственных процессов, контроль качества производственных процессов.

To Oleshka
Тестировщик внутри проекта и тестировщик команды QA - как бы находятся по разные стороны барикад...т.е. они работают отдельно друг от друга.
Или не так? QA тестировщик создает свои тесты или все-таки использует наработки проектного тестировщика? На ком из них лежит задача создание тест плана?
Вобщем мне осталось непонятным разделение задач между QA тестером и командным тестером, и их взаимодействие.

To meol:

У нас пока еще не дошли до такого высокого уровня, чтобы держать отдельную группу, которая будет бороться за нормативы - фондов нету. Есть менеджер системы качества, который и занимается всеми вопросами стандартизации. QA department занимается полным тестированием продукта как внешняя команда по отношению к проекту, играя за клиента. Наработки проектного тестировщика не используются, создаются свои тестовые планы.
  • 0


Количество пользователей, читающих эту тему: 6

0 пользователей, 6 гостей, 0 анонимных