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

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

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

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

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

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

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

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

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

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

на аудит и хорошего менеджера денег похоже нет...

А зачем Вам аудит? Чтобы выяснить, что вокруг все плохо? Вы и сами это понимаете.

Процессы за испытательный срок Вы не настроите, имхо, ну если только он у Вас не пожизненный))

Попытайтесь взять один проект, не тот что самый лучший, но и не тот, что самый страшный. По нему надо установить примерные рамки, когда к Вам должна приходить версия, когда Вы ее отдаете (все это примерно). За сколько нужна сборка, что проверить ее и сказать, что это можно релизить. Я бы сначала нарисовал это на бумаге и показал руководству со словами: "Вот к этому мы будем стремиться". Потому что, если придти к разработчику и сказать, чтоб он выдавал сборку за два дня до релиза, а не за два часа, то он посмотрит на вас круглыми глазами и скажет, что он ничего не успеет сделать в таком случае.

на аудит и хорошего менеджера денег похоже нет...

А зачем Вам аудит? Чтобы выяснить, что вокруг все плохо? Вы и сами это понимаете.

Процессы за испытательный срок Вы не настроите, имхо, ну если только он у Вас не пожизненный))

Попытайтесь взять один проект, не тот что самый лучший, но и не тот, что самый страшный. По нему надо установить примерные рамки, когда к Вам должна приходить версия, когда Вы ее отдаете (все это примерно). За сколько нужна сборка, что проверить ее и сказать, что это можно релизить. Я бы сначала нарисовал это на бумаге и показал руководству со словами: "Вот к этому мы будем стремиться". Потому что, если придти к разработчику и сказать, чтоб он выдавал сборку за два дня до релиза, а не за два часа, то он посмотрит на вас круглыми глазами и скажет, что он ничего не успеет сделать в таком случае.

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

на аудит и хорошего менеджера денег похоже нет...

Может, есть немного денег на хорошего тестировщика?

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

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

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

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

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

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

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

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

спасибо, очень хорошая мысль!!!

а что есть хороший тестировщик?

Который сможет оценить ситуацию.

и зачем тогда я?

Хороший вопрос.

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

Так вы компании хотите пользу принести, или просто обеспечить себя какой-то работой? Второе, конечно, проще.

понятно, что придти в одно утро и сказать - "теперь все будет вот", - так не получится.
да и не надо это.

Не просто "не надо", а "нельзя и все".


Уточняем ситуацию:

группа тестирования, состоящая из меня и еще одного сотрудника,

= В компании нет тестирования.

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

= Компания не понимает, чего она хочет.

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

Начать надо с осознания проблем. идеально - с точки зрения бизнеса. Не в терминах "там что-то тестируется 2 часа", а в терминах - мы потеряли N времени и M денег, почему? Потому, что... Заказчик прислал расстрельную команду. Почему? И так далее.

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

Haul,

Судя по всему от вас ждут quality assurance plan. А потом и действий по нему.
Если бы мне предложили пари, я бы на Вас не поставил. Это не то, чему можно научиться за пару месяцев.
Но возможно Ваше руководство устроит любой результат, ибо они сами не знают, чего хотят.

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

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

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

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

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

Вообще, про промах пока говорить рано.

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

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

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

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

Как-то слишком пафосно для профессионала. Так защищаетесь? Можно поподробнее об ощущениях "специалиста такого профиля, что стоит таких денег".


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

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

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

Haul, у меня по прочтении Вашего письма возникло несколько вопросов:
1. Опыт консалтинга в области чего у Вас имеется?
2. Каким образом Вы попали на данное место: по результатам собеседования или протекционизма?
3. Когда Вы устраивались на работу, разве не велась речь о том, что Вам нужно будет делать и какова ситуация сейчас?

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

С другой стороны если на целых 4 проекта всего два тестировщика, то видимо разрабатываемое ПО даже не среднего размера и нацелено не на самые критичные для клиента задачи.

Насколько я понимаю, Ваш вопрос на самом деле звучит так: "Каким образом удволетворить желание руководства, оставив за собой рабочее место?"

С моей точки зрения, без чтения всё-равно обойтись не удастся.
К сожалению, краткая информация о Ваших навыках, не позволяет понять насколько Вы знакомы с процессом разработки ПО, чтобы рекомендовать ту или иную литературу.
Попробуйте ознакомиться с русским переводом SWEBOK. По-крайней мере там нет воды. И после этого Вы сможете сами выбирать направление дальнейшего изучения.
С учётом размера Вашей компании и текущих процессов, может быть имеет смысл посмотреть в сторону Agile. Однако без опытного специалиста или хотя бы достаточного знакомства с ним не стоит пытаться начинать внедрять его. В любом случае это нужно будет делать уже заметно после окончания испытательного срока и, желательно, с единомышленниками в компании.
Но, думаю, что некоторые практики из agile вполне могут помочь в описанной ситуации.

В принципе, данный ранее совет посмотреть на качество работы до этапа тестирования - совет хороший. Однако есть два "но":
1. Ваши полномочия распространяются на все процессы разработки ПО или только на тестирование?
2. Прежде чем лезть со своим уставом в чужой монастырь, стоит сперва построить свой. То есть необходимо всё же наладить работу именно отдела тестирования. Правильно поставленные процессы Вашего отдела будут сами влиять на работу остальных отделов. То есть если Вы опишите работу Вашего отдела и потом укажете, что для этого нужны некие определённые действия от других, то они будут вынуждены это Вам предоставить. Но толкьо в том случае, если Ваши регламенты утвердит руководство - если Вы его убедите в необходимости этого и потом сможете отстаивать эти правила первый месяц-другой, пока остальные будут пытаться работать как всегда.

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

Думаю, что для начала хватит

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

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

Как-то слишком пафосно для профессионала. Так защищаетесь? Можно поподробнее об ощущениях "специалиста такого профиля, что стоит таких денег".


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

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

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

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

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

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

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