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

Фотография

как поднять процессы в компании с точки зрения качества и тестирования


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

#21 Haul

Haul

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

  • Members
  • Pip
  • 10 сообщений
  • ФИО:Линка
  • Город:Питер

Отправлено 19 мая 2009 - 08:56

Не очень нравится "испытательный срок". Судя по описанию, руководство понимает, что в компании бардак с процессами, и брало специалиста именно для ликвидации этого бардака. Но зачем тогда испытательный срок? Что, они правда готовы по окончании испытательного срока взять другого человека и начать всё сначала? Важный вопрос: вам на испытательный срок назначили такую же зарплату, как на постоянную работу, или существенно ниже? Если ниже, то нельзя полностью исключать возможность отказа от ваших услуг, даже если вы проявите себя с лучшей стороны (разработали план? спасибо, проводить его в жизнь будет другой человек).

В качестве путеводителя по установке процессов, связанных с тестированием, попробуйте тест Гринкевича (ссылка на software-testing.ru, почему-то его сайт drquality.ru не отзывается).
Пройдите тест, составьте план по тем пунктам, по которым тест не пройден, и работайте над ними.

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

В порядке самопиара даю ссылки на собственные заметки - может, пригодятся:
http://www.greesha.r...p;id=1212844310
http://www.greesha.r...p;id=1213112217

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

зп на испытательном такая же, как будет после. и брали меня просто как руководителя группы тестирования изначально не возлагая надежд на то, что я приду и все поправлю. но ситуация складывается так, что работать дальше так же просто нельзя. компания теряет деньги. на грани потери заказчика и тд
спасибо за ссылки!
буду рада, если поделитесь!!! (баг-трекер Mantis, система контроля версий есть)
  • 0

#22 greesha

greesha

    Опытный участник

  • Members
  • PipPipPipPip
  • 363 сообщений
  • ФИО:Печёнкин Григорий Михайлович
  • Город:Мытищи

Отправлено 19 мая 2009 - 09:32

Делюсь, не жалко.

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

1) Единственным средством обмена исходниками и любой документацией,
имеющей отношение к разработке софта, между сотрудниками является
Visual Source Safe. В Visual Source Safe должны быть лэйблы для ВСЕХ
версий, передаваемых другому программисту или в SUPPORT для отправки
клиенту, чтобы при необходимости легко можно было восстановить точную
версию приложения.

2) существуют два вида тестов для каждого приложения: обязательные
(минимальные) тесты на работоспособность, выполняемые программистами,
и детальные тесты на надёжность, стабильность, дуракоустойчивость и т.
п., выполняемые QA. Прежде чем поместить программу в Visual Source
Safe для передачи кому бы то ни было, программист должен проверить её
работоспособность.

3) Программисты НЕ ОБЩАЮТСЯ с клиентами напрямую. При получении
запросов непосредственно от клиентов посылают их на SUPPORT или ко
мне.

...

Для реализации этих требований прошу выполнять следуюшие правила.

- при выпуске очередной версии приложения программист должен присвоить
очередной номер версии, поместить все файлы проекта в VSS, и назначить
метку вида <Имя-приложения> Release <версия>. После этого убедиться в
том, что все необходимые варианты приложения (включая все
поддерживаемые приложенем платформы, языки и модификации) без проблем
собираются в "чистом" каталоге с использованием прилагаемых .bat
файлов. (отв. все разработчики, по каждому приложению ответственный за
проект назначается отдельно).

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

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


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

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


  • 0
Григорий Печёнкин
greesha.ru
жежешечка

#23 Vita

Vita

    Опытный участник

  • Members
  • PipPipPipPip
  • 315 сообщений
  • ФИО:Виктория
  • Город:Ярославль

Отправлено 19 мая 2009 - 16:47

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

- -

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

С уважением, Vita
... you can learn from that too


#24 LeshaL

LeshaL

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 094 сообщений
  • ФИО:Алексей Лянгузов
  • Город:Saint-Petersburg


Отправлено 19 мая 2009 - 17:18

Здравствуйте!
Вы описываете ситуацию как две капли похожую на ту, что у меня была на предыдущей работе. Только у меня уже опыт в тестировании был к тому времени 3+ года - казалось все знаю, хе-хе.
Попробую насоветовать чего-нибудь.

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

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

Дальше, с этим списком к руководству. Я не знаю какая должностная организация в вашей фирме, но просто необходимо найти руководителя, который будет продавливать внедрение ваших рац-предложений. Если такого начальника нету и всем все или по-барабану или у того кто хочет чего-то изменить нету на то полномочий - можете смириться с двумя вещами:
1) фирме придет кирдык
2) вы можете особо не напрягаться и продолжать делать что угодно, что считаете нужным, потому что см. 1)

компания 20-30 человек, которая пишет-тестирует ПО.
группа тестирования, состоящая из меня и еще одного сотрудника, которая работает "на всех" и является как бы самостоятельным звеном.
проекты: сейчас на тестировании 4 проекта, которые уже на сопровождении скорее. то есть добавляется новый функционал, латаются старые ошибки, производитс рефакторинг по ходу. один из проектов достаточно простой и с ним проблем нет - все задокументировано, тестируется легко и за 2 цикла, по остальным творится страшное- спецификаций нет, тест планов нет, полного тестирования никогда не было и в основном версии уходят заказчику неоттестированными вообще (на мой взгляд). программист пишет, мы тестируем что-то. потом идет еще одна сборка, что-то тестируется. потом еще одна. в итоге в финальной сборке падает половина функционала, которая была оттестирована когда-то в начале недели. а финальный билд тестируется за час до отправки... в 11 вечера мною...
...
решить, нужен ли еще тестировщик.

Нужно решить, что нужен, а то и не один. И как тут уже писалось, лучше опытный товарищ. Во-первых вы руководитель и судя по этому посту от вас хотят не просто того, чтобы вы тестировали. При этом логично нанять людей подкованых в тестировании дабы дать вам время на выявление и устранение проблем напрямую не связанных с проведением тестирования.
Во-вторых, если в фирме 20-30 человек и только 1-2 из них занимаются тестированием, то это уже само по себе плохое соотношение. Либо переизбыток программистов, либо недостаток тестеров. Тяжело посоветовать что-то более разумное не зная специфику проектов - но неплохо бы на каждый проект иметь хотя бы по одному постоянно над ним работающему тестеру.

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

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

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

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

Процесс тестирования неотделим от процесса разработки. Тестирования без разработки быть не может, а наоборот - запросто.

Итак, подведем итог тому что я тут написал. Список шагов:
1. Выявите все проблемы, с доказательствами, что они на самом деле проблемы. Честно и без утайки, пусть кому-то чего-то не нравится, но не признав проблему ее не решить.
2. Ищете руководителя, который будет курировать, лоббировать, поощрять или запрещать ваши предложения по улучшению любых процессов.
3. Есть два варианта проведения такого рода изменений (может и больше): эволюционный и революционный. Вам и начальнику из п.2 решать каким путем идти. Но лично я предпочитаю первый. Люди не любят революций, в какой-бы стране они не жили и где бы не работали. Да и не сработает революционный подход в вашем случае.
4. Выработайте решения для найденых проблем, возможно будет несколько путей решения каждой. Просто признать проблему недостаточно и не ждите, что кто-то вам посоветует решение. А вот если вы предложите пути решения, то к вам и охотнее прислушаются и найдутся люди, которые помогут выбрать то решение, которое устроит большинство людей.
5. Не пытайтесь решить сразу все проблемы. Не получится. Сначала решаете легоустранимые+серьезные, потом легкоустранимые+менее серьезные. Глядишь к концу вашего испытательного срока и наберется более-менее значительное количество успехов. Иначе можно кинуться исправлять что-то важное и долгоисправимое, но так и ничего не добиться. Такие проблемы (серьезные+тяжелоустранимые) решайте в третью очередь. Маловажные+тяжелоустранимые не решайте вообще пока кроме них ничего не останется.

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

#25 Green

Green

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 233 сообщений
  • ФИО:Гринкевич Сергей
  • Город:Москва

Отправлено 20 мая 2009 - 07:37

Почитал я эту ветку... и даже написать нечего. Уже все написано выше. Значит, буду критиковать.
:aggressive:

Во-первых, Haul, видно, что знаний и опыта у вас в этой области нет. Зачем брались за эту работу? Но это вопрос риторический.

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

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

Кто виноват?
Виноваты конечно Вы. Если бы у Вас было больше опыта или был больший выбор, то Вы бы не оказались в этой ситуации.

Что делать?
1. Снять с себя миссию спасителя.
2. Четко ограничить рамки своей компетенции. Начать с точки приема программы в тестирование и закончить точкой выдачи результатов тестирования. Все что внутри - Ваше, что снаружи - на кого бог пошлет.
3. Определить, какой именно результат должна выдать группа тестирования по итогам тестирования (что будет написано в отчете).
4. Определить, что потребовать от разработчиков до начала тестирования программы (какую информацию они должны представить, в каком виде и что сделать), а так же чем грозит продукту не выполнение каждого из требований.
5. Определить, что должно быть сделано остальными по результатам тестирования и как это проверить/подтвердить.
6. "Выбить" из начальства санкции за не выполнение требований приемки/передачи продукта в тестирование.
7. Определить, что именно, в каком порядке и каким образом будет тестироваться (и в таком порядке результаты отмечать в отчете о тестировании).

Для начала этого хватит.

Помимо прочего, нет ничего зазорного в том, что Вы чего-то не знаете или не умеете. Это детство, думать, что если рядом с Вами работает кто-то, кто знает работу лучше Вас, то это вредит Вашему имиджу и подрывает авторитет. Если Ваши подчиненные умнее, профессиональнее и опытнее, то это большой плюс Вам, как руководителю этого коллектива. Так что не стоит бояться брать на работу сотрудников с бОльшим опытом и знаниями.

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

#26 Haul

Haul

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

  • Members
  • Pip
  • 10 сообщений
  • ФИО:Линка
  • Город:Питер

Отправлено 20 мая 2009 - 09:11

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

#27 Vasiliy

Vasiliy

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 2 959 сообщений
  • ФИО:Касимов Василий
  • Город:Москва

Отправлено 20 мая 2009 - 10:07

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

Интересно. Рассказывайте, конечно.
И спрашивайте тоже :)
  • 0

#28 Haul

Haul

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

  • Members
  • Pip
  • 10 сообщений
  • ФИО:Линка
  • Город:Питер

Отправлено 20 мая 2009 - 11:18

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

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

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

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

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

в общем, результатами я довольна, сейчас определяю план действий на ближайшее будущее
  • 0

#29 Haul

Haul

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

  • Members
  • Pip
  • 10 сообщений
  • ФИО:Линка
  • Город:Питер

Отправлено 20 мая 2009 - 11:21

и еще у меня огромный список литературы, буду читать)
  • 0

#30 barancev

barancev

    Администратор

  • Admin
  • PipPipPipPipPipPip
  • 6 872 сообщений
  • ФИО:Алексей Баранцев
  • Город:Россия, Москва


Отправлено 20 мая 2009 - 13:54

мне дали карт-бланш на реорганизацию процессов внутри группы тестирования

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

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

А что они должны были сказать? "Нет, не улучшайте взаимодействие ни в коем случае!" Вряд ли. Да и вообще, тут санкция начальства не нужна. Лучше как-нибудь подбейте и других менеджеров проектов на совместные ланчи :)

выяснилась необходимость проведения собрания, чтобы буквально напомнить и научить всех пользоваться принятыми в компании программами (баг-трекеры, эл почта и тд) и соответственно написать документы- регламенты

Гм-гм... На собрание они придут, посидят, а вот регламенты читать не будут, не трудитесь над ними слишком старательно. И соблюдать вряд ли будут, если им просто сказать "Соблюдайте!" Это придётся кропотливо учить и учить... Каждого отдельно и всех вместе.

идею о заведении внутренней документации восприняли оч хорошо, директор показал их попытки что-то сделать в этом направлении

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

уж не знаю, связано ли это со мной (вряд ли), но решили искать опытного менеджера

Существующие менеджеры могут на Вас за это и обидеться. Типа они все тупицы, и скоро им будет указано на дверь.

Сергей Вам правильно посоветовал -- не пытайтесь оптимизировать сразу всё, тут надо иметь жонглёрские навыки, иначе это всё на Вас и свалится. Найдите для начала один самый большой источник проблем и устраните его. Потом второй. И так далее. Всё сразу не может быть источником проблем.
  • 0
Алексей Баранцев
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium

#31 Фрося

Фрося

    Специалист

  • Members
  • PipPipPipPipPip
  • 514 сообщений
  • ФИО:Радилова Елена Игоревна

Отправлено 02 июля 2009 - 09:29

Упс... зашла. Прочла ветку. Тихо завидую.... Ситуация-то у автора темы - просто шикарная:
1. Руководство хочет что-то менять.
2. Есть тестировщик (и) и менеджер (ы)
3. Предлагают внести предложения -- как менять!!!!

Тихая зависть... и только....

Упс... сейчас руководство походя в коридоре предолжило раскидать работу как-нибудь.....
А работа такая - по очередному релизу НЕОБХОДИМО в сжатые сроки оформить ВСЮ документацию ЖЦ..... (предыдущий релиз -см. мою тему Пятничнйы кризис в работе..) от корректировки Требований к ПО, через верификацию до конечной точки - отчета о завершении выпуска...

Если кто-то может посоветовать - как можно донести до рукодства -- что процессы разработки ПО должны быть хоть как-то организованы...
Что - необходим более-менее формализованный процесс тестирования. Что невозможно оформлять задним числом по запискам запросы на изменения, невозможно задним числом расписать План Тестирования и результаты прохождения тестов...

Спасибо!
  • 0
Почему-то по пятницам особо остро хочется быть блондинкой....

#32 nhuber

nhuber

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

  • Members
  • PipPip
  • 97 сообщений
  • ФИО:Николай
  • Город:Новосибирск

Отправлено 02 июля 2009 - 11:00

Если кто-то может посоветовать - как можно донести до рукодства -- что процессы разработки ПО должны быть хоть как-то организованы...
Что - необходим более-менее формализованный процесс тестирования. Что невозможно оформлять задним числом по запискам запросы на изменения, невозможно задним числом расписать План Тестирования и результаты прохождения тестов...

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

Просто доносить до руководства мысль, что надо что-то делать - неперспективно, потому что это означает, что руководство должно получить ещё одну головную боль. Возьмите эту головную боль на себя, внесите конкретные легко реализуемые (для начальства) предложения - и перемены станут более реальными.
  • 0

#33 barancev

barancev

    Администратор

  • Admin
  • PipPipPipPipPipPip
  • 6 872 сообщений
  • ФИО:Алексей Баранцев
  • Город:Россия, Москва


Отправлено 02 июля 2009 - 11:07

Упс... сейчас руководство походя в коридоре предолжило раскидать работу как-нибудь.....
А работа такая - по очередному релизу НЕОБХОДИМО в сжатые сроки оформить ВСЮ документацию ЖЦ..... (предыдущий релиз -см. мою тему Пятничнйы кризис в работе..) от корректировки Требований к ПО, через верификацию до конечной точки - отчета о завершении выпуска...

А представьте себе, если бы всю эту документацию надо было сделать не после выпуска релиза, а в процессе его выпуска, то есть по сути ВМЕСТО того, чтобы работать, вы бы писали бумажки. Каково, а? Попробуйте понять своё руководство, у них тоже есть свой здравый смысл.
  • 0
Алексей Баранцев
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium

#34 Фрося

Фрося

    Специалист

  • Members
  • PipPipPipPipPip
  • 514 сообщений
  • ФИО:Радилова Елена Игоревна

Отправлено 02 июля 2009 - 12:27

А представьте себе, если бы всю эту документацию надо было сделать не после выпуска релиза, а в процессе его выпуска, то есть по сути ВМЕСТО того, чтобы работать, вы бы писали бумажки. Каково, а? Попробуйте понять своё руководство, у них тоже есть свой здравый смысл.


Представила.
Что-то с трудом верится - что тестирование по принципу "Мамой клянусь - все работает!" упрощает процесс выпуска релиза...
Или, например, изменение Требований на словах , тоже что-то упростит...
  • 0
Почему-то по пятницам особо остро хочется быть блондинкой....

#35 barancev

barancev

    Администратор

  • Admin
  • PipPipPipPipPipPip
  • 6 872 сообщений
  • ФИО:Алексей Баранцев
  • Город:Россия, Москва


Отправлено 02 июля 2009 - 14:30

А представьте себе, если бы всю эту документацию надо было сделать не после выпуска релиза, а в процессе его выпуска, то есть по сути ВМЕСТО того, чтобы работать, вы бы писали бумажки. Каково, а? Попробуйте понять своё руководство, у них тоже есть свой здравый смысл.


Представила.
Что-то с трудом верится - что тестирование по принципу "Мамой клянусь - все работает!" упрощает процесс выпуска релиза...
Или, например, изменение Требований на словах , тоже что-то упростит...

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

Кстати, а что Вы имеете против устных требований? В чём проблема работы с требованиями в таком формате?
  • 0
Алексей Баранцев
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium

#36 greesha

greesha

    Опытный участник

  • Members
  • PipPipPipPip
  • 363 сообщений
  • ФИО:Печёнкин Григорий Михайлович
  • Город:Мытищи

Отправлено 02 июля 2009 - 14:38

Кстати, а что Вы имеете против устных требований? В чём проблема работы с требованиями в таком формате?


Правильное название устных требований — «хотелки». :)
  • 0
Григорий Печёнкин
greesha.ru
жежешечка

#37 barancev

barancev

    Администратор

  • Admin
  • PipPipPipPipPipPip
  • 6 872 сообщений
  • ФИО:Алексей Баранцев
  • Город:Россия, Москва


Отправлено 02 июля 2009 - 14:40

Правильное название устных требований — «хотелки». :)

Правильное название устных требований -- "устные хотелки", правильное название письменных требований -- "письменные хотелки" :)
  • 0
Алексей Баранцев
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium

#38 Clauster

Clauster

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 913 сообщений
  • ФИО:Худобородов Валерий
  • Город:Espoo

Отправлено 02 июля 2009 - 20:22

А представьте себе, если бы всю эту документацию надо было сделать не после выпуска релиза, а в процессе его выпуска, то есть по сути ВМЕСТО того, чтобы работать, вы бы писали бумажки. Каково, а? Попробуйте понять своё руководство, у них тоже есть свой здравый смысл.


Представила.
Что-то с трудом верится - что тестирование по принципу "Мамой клянусь - все работает!" упрощает процесс выпуска релиза...

Ну я бы ещё добавил "show stopper-ов нет, исправленные баги закрыты, приемочное тестирование проведено" и можно выпускаться. Если качество выпускаемого продукта всех устраивает, зачем что-то формализовывать? Если интересно работать с формализованными процессами, то вам надо идти работать в контору с CMMI или типа того.
  • 0

#39 Фрося

Фрося

    Специалист

  • Members
  • PipPipPipPipPip
  • 514 сообщений
  • ФИО:Радилова Елена Игоревна

Отправлено 03 июля 2009 - 06:09

Ну я бы ещё добавил "show stopper-ов нет, исправленные баги закрыты, приемочное тестирование проведено" и можно выпускаться. Если качество выпускаемого продукта всех устраивает, зачем что-то формализовывать? Если интересно работать с формализованными процессами, то вам надо идти работать в контору с CMMI или типа того.

Отвечаю с "хвоста"

1. Интересно работать с формализованными процессами?
Да, было бы интересно поработаь с полгода с формализованными процессами. Чтобы понять - что хорошего привнесено.
2. "Зачем формализовать?"
Так - это требование "свыше". Есть программные продукты,процесс выпуска которых обязательно должен быть подтвержден документально. Ну вот я с такими продуктами и имею дело. Поэтому последний год - вот эту доказательную базу (куча бумаг) и делаю.

3. Поэтому например, для "хотелок" необходима бумага, где показано/доказано:
- что "хотелки" есть
- что выполнимы
- не противоречивы
- достаточны
- не из воздуха взялись, а необходимы.

С устной формой -- никак не получится......
4. Чем плохи устные "хотелки" вообще?
- могут быть в принципе неправильны (бумага имеет свойство выявлять ляпы),
- могут быть неправильно поняты
- часть хотелок может быть просто забыта напрочь, и всплывет в самом конце разработки.
- если хотелки создаются нескоьлькими людьми.... то вообще не понятно - чего надо-то?
  • 0
Почему-то по пятницам особо остро хочется быть блондинкой....

#40 barancev

barancev

    Администратор

  • Admin
  • PipPipPipPipPipPip
  • 6 872 сообщений
  • ФИО:Алексей Баранцев
  • Город:Россия, Москва


Отправлено 03 июля 2009 - 06:31

3. Поэтому например, для "хотелок" необходима бумага, где показано/доказано:
- что "хотелки" есть
- что выполнимы
- не противоречивы
- достаточны
- не из воздуха взялись, а необходимы.

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

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

3. Почему Вы считаете, что с устной формой не получится? Ну да, фиксировать как-то надо, тут я согласен. А про остальное -- см. предыдущий абзац.
  • 0
Алексей Баранцев
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium


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

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