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

[Polet]

Здраствуйте!
Такая вот проблема:
Меня назначили QA Manager-ом на новый проект. Я пока впервые на такой должности, и из-за постоянного стресса (переживаю, что у меня не получиться) никак не могу сосредоточиться – лезут разные идеи в голову: начинаю делать – кажется, что это не подходит, - и опять хватаюсь за другую идею, и опять бросаю, и так по кругу. Все это из-за того, что считаю, что все, что я делала и видела раньше, тут совершенно не подходит.
Детальнее:
Пока я являюсь и единственным тестером на проекте - на стадии проектирования ставлю задачи, и сама же их выполняю. То есть моя задача организовать процесс тестирования - выбрать стратегию, разработать тест план и др. организационную документацию. На этапе написания тест кейзов (по шаблонам, к-рые я должна разработать) планируется добавить еще двоих тестеров (или больше, если по расчетам (к-рые опять таки я должна провести) их потребуется больше). Они будут заниматься уже непосредственно тестированием, и немного написанием тест кейзов.
Сейчас у меня полная свобода действий, и я растерялась. Я не знаю с чего начать. Но не в плане теории – тут все ясно: сначала проджект план, потом тест план, потом спецификации, тест дизайн, сценарии, тест кейзы и т.д. Я никак не могу ухватить тестируемую систему “за хвост” – как поделить ее на функциональные группы, по какому критерию. Объясню в чем сложность – есть готовая система (которую будут переписывать с сохранением бизнес логики,– отсюда общая суть тестирования – чтобы новая система функционировала также как старая) и по ней мне и надо строить тестирование (это плюс, что система готова, я ее вижу и могу потрогать ), но заказчики не предоставляют никакой проектной документации, есть только User Guide ( и это большой минус). Я с таким еще не сталкивалась, и поэтому не представляю, как разрабатывать тестирование при отсутствии проектной документации, ведь везде в теории (то, что я читала) пишут, что тест план строиться на основе технической спецификации и требований к продукту.
Может, кто с таким сталкивался, помогите, пожалуйста, советом, направьте хотя бы в правильное русло. Или может, кто сталкивался с литературой по такому случаю…

[Fisher]

1. Из User Guide выписываем названия параграфов, те, которые совпадают с названиями крупной функциональности системы. Полученный документ - основа документа с тест кейсами.
2. Открываем User Guide, запускаем старую систему.
3. Читаем в User Guide описание отдельной функциональности, проверяем, что эта функциональность именно так и реализована в старой системе (этот пункт можно пропустить, если есть уверенность, что User Guide полностью соответствует старой системе). Если есть несовпадения, см. п.7 ниже.
4. Переписываем, детализируем, дописываем описание функциональности из User Guide в виде тест кейсов: шаг 1 и ожидаемый результат, шаг 2 и ожидаемый результат.
5. И так по каждому параграфу из User Guide.
6. Если какая-то функциональность в User Guide недостаточно понятно описана, запускаем старую систему и смотрим, как такая функциональность реализована.
7. Если возникают вопросы, обращаемся к знатокам старой системы, если такие есть. Ответы отражаем в тест кейсах.

Так можно составить список тест кейсов.

8. Возможно User Guide содержит другую информацию, которая тоже может быть использована при составлении тест плана. Например описание инсталляции, конфигурации системы. Хотя эта информация наверняка изменится для новой системы, все равно что-то можно использовать.
9. В ходе разработки новой системы обновляем тест кейсы в соответствии с реальной логикой.

[Polet]

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

[Darkus]

Вопрос. А почему вы согласились на эту должность?

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

[Polet]

А я и не обижаюсь. Я всегда спокойно принимаю критику, особенно конструктивную.
Отвечаю на вопрос:
Потому что я к этому стремилась!!! И я этого добилась!!!
А не получается (пока что!!!), потому, что проект отличается от тех, с которыми я сталкивалась до этого.
Я всегда стремлюсь сделать все оптимально и качественно!!!
И если бы я была впервые проектировщиком нового города, то да сначала б наверно так и было, как вы предположили, но в результате я бы нашла оптимальный вариант и спроектировала бы действительно качественно. А что бы не переводить материалы и время не терять, я бы консультировалась с бывалыми проектировщиками, что и делаю.
А то, что мне посоветовали, переписать юзер гайд, который вмещает более 1000-чи страниц, считаю не оптимальным решением. Хотя конечно, в наше время все так и делается – что-то написали, перекрутили, а дальше будь как будет, никакой оптимизации!!!
Так и проектировщики-строители понаделают неизвестно что, а потом никто жить и не хочет в таком городе. Получается по вашему пусть хоть какой-то город, хоть и криво спроектированный.

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

[Fisher]

1. Пусть сначала кто-то из знатоков системы назовет вам основные фичи. Это и будет основа для дальнейшего написания тест кейсов.

2. Потом постепенно писать тест кейсы для каждой фичи, координируя информацию с User Guide+старая система+разработчики+знатоки системы+переписка в команде.

[grr~]

Здраствуйте.
Мы с вами не с одним заказчиком работаем?

[APC]

Привет!
Я работаю почти на 100% в такой же ситуации, начинал так же.

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

А потом придет опыт.
Надеюсь и ко мне тоже он придет ;)

[Polet]

1. Пусть сначала кто-то из знатоков системы назовет вам основные фичи. Это и будет основа для дальнейшего написания тест кейсов.

2. Потом постепенно писать тест кейсы для каждой фичи, координируя информацию с User Guide+старая система+разработчики+знатоки системы+переписка в команде.

Мне как раз и предстоит стать знатоком системы, и основные фичи я должна буду назвать.
Вопрос в том как это сделать? И как это делается? В моем случае я не просто тестер, я “3 в 1” – тестер, проектировщик и бизнес аналитик!!!
А все потому, что клиенты экономят на ресурсах!!!

[KInnaO]

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

[Yury]

Меня назначили QA Manager-ом на новый проект.
...............
Пока я являюсь и единственным тестером на проекте ...
................
Сейчас у меня полная свобода действий, и я растерялась. Я не знаю с чего начать. Но не в плане теории – тут все ясно: сначала проджект план, потом тест план, потом спецификации, тест дизайн, сценарии, тест кейзы и т.д

Мне кажется, что начинать надо всё-же с прояснения Вашей роли.
Являетесь ли Вы "QA Manager-ом" или "Тестером"? Это две совершенно разные роли.
За что Вы отвечаете: за QA (process police) или за тестирование (предоставление информации о реальном качестве продукта)?
Принимаете ли решение, когда выпустить продукт?
Разобрались ли Вы с приоритетами вашей компании? Что для неё важнее - быстрее завершить разработку, обеспечить высокое качество или уложиться в утвержденный бюджет?
Каковы основные риски этого проекта?

Только после того, как Вы знаете ответы на эти вопросы, Вы можете начинать разработку стратегии тестирования.
Кстати, а нужен ли Вам "проджект план"?
Используете ли вы "Waterfall SDLC"?
Если у вас используется итеративный SDLC, то "проджект план" Вым может быть и не нужен.

[Polet]

Меня назначили QA Manager-ом на новый проект.
...............
Пока я являюсь и единственным тестером на проекте ...
................

Мне кажется, что начинать надо всё-же с прояснения Вашей роли.
Являетесь ли Вы "QA Manager-ом" или "Тестером"? Это две совершенно разные роли.

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


Еще раз повторюсь:
Моя задача – организовать процесс тестирования продукта от начала и до конца, включая все необходимые этапы. Со стороны тестирования я пока одна. Поэтому пока совмещаю все роли в тестировании. Соответственно на данном этапе я отвечаю и за QA (process police) на данном конкретном проекте и за тестирование конкретного продукта. И также я объяснила из-за чего так все сложилось! И я же принимаю все решения по стороне тестирования – я решаю, сколько надо будет подключить тестеров, сколько времени займет реализация проекта… и соответственно я же буду принимать решение о готовности продукта к выпуску и т. д.

Отвечаю на следующий вопрос: “ Что для неё важнее - быстрее завершить разработку, обеспечить высокое качество или уложиться в утвержденный бюджет?”

Поскольку проект длительный и объемный, то сроки выполнения не являются приоритетными. У меня стоит задача – определить, сколько потребуется времени в человеко-часах на дизайн тестирования и сколько – на само тестирование, а уже заказчики будут решать, хотят ли они “три человека на два месяца или пять на один”.

“…Высокое качество…” – это размытое понятие, также я могу ответить, что требуется обычное качество.

И т.д.

Я ответила на ваши вопросы, вот только ни на шаг не приблизилась к цели…

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

[Darkus]

От критики к делу.
Вам, как растущему руководителю, очень советую прочитать тоненькую книжку.
"Огвоздин В.Ю. Управление качеством."
Буквально страниц 100 из основ и тогда вам можно будет задавать вопросы дальше :)
....
Что же касается

Я ответила на ваши вопросы, вот только ни на шаг не приблизилась к цели…

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

Здесь немного из его книги:
http://www.stq.ru/ri...&article_id=631

[Rost]

Мне как раз и предстоит стать знатоком системы, и основные фичи я должна буду назвать.
Вопрос в том как это сделать? И как это делается? В моем случае я не просто тестер, я "3 в 1" - тестер, проектировщик и бизнес аналитик!!!
А все потому, что клиенты экономят на ресурсах!!!

Позвольте мне порекоммендовать как Вам поступить.
1. Декомпозируйте систему. - Соберие всех тим лидов (или подойдите к каждому) и узнайте какие модули задействованы в системе, а так же их взаимодействие.
2. Формализуйте источники - Определите с руководством что вам считать главным источником информации и на чем базироваться при описании системы(так называемый "референс"). Например, на Вашем месте я бы предложил начальству следующий вариант: а) я смотрю на старую систему, если все нахожу, тогда пишу по ней; б) если в старой системе я не нахожу чего-то, тогда я смотрю в юзер гайд; в) если нет ни там ни там спрашиваю менеджера/заказчика/разработчика; г) если никто не может помочь я высылаю запрос на разъяснения ответственному лицу (заказчику или руководителю проекта).
3. Если возможно попробуйте пойти не по стандартной схеме (даешь каждому нестандартному проекту свой нестандартный подход ). Попробуйте начать с написания тест спецификаций (System\Software Test Plan). По ходу описания Вы ознакомитесь с продуктом, начнете таки что-то реальное выдавать на выходе, поймете сколько людей надо добавить в команду(и какого уровня профессионализма) и сформируете свое видение стратегии тестирования. Вот тогда в "фоновом" режиме потихоньку и Тест План появится. А там уже и до автоматизации рукой подать.

А главное - Вы есть Руководитель группы тестирования (не важно Вы одна или вдесятером :-)). Ничего не бойтесь. Не ошибается тот кто ничего не делает. Каждую ошибку Вы же сами и исправите. Так что можете об этом не беспокоиться. Желаю удачи.