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

[vuchenka]

Ребят, подскажите, ответ на вопрос. Интересно у кого как.
Как у вас построен процесс тестирования проектов? По пунктам если можно.
Мы открыли отдел тестирования, и вот занимаемся налаживанием.

[clipsa]

"Найди свой путь!
Он ведь один и с него не свернуть..." (с)

Напрашиваются уточняющие вопросы:
Отдел тестирования же не возник из вакуума? Как проводилось тестирование ранее - без отдела тестирования?
Кого это не устраивало? Почему?
Какие проблемы вы хотите решить с помощью отдела тестирования?
Какую роль исполняете на проекте Вы?
Какая существует проектная документация?
Как построен процесс разработки в целом? И есть ли повод/желание его менять?
Сколько человек в отделе тестирования?

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

[Snap]

Ребят, подскажите, ответ на вопрос. Интересно у кого как.
Как у вас построен процесс тестирования проектов? По пунктам если можно.
Мы открыли отдел тестирования, и вот занимаемся налаживанием.

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

[vuchenka]

"Найди свой путь!
Он ведь один и с него не свернуть..." (с)

Напрашиваются уточняющие вопросы:
Отдел тестирования же не возник из вакуума? Как проводилось тестирование ранее - без отдела тестирования?
Кого это не устраивало? Почему?
Какие проблемы вы хотите решить с помощью отдела тестирования?
Какую роль исполняете на проекте Вы?
Какая существует проектная документация?
Как построен процесс разработки в целом? И есть ли повод/желание его менять?
Сколько человек в отделе тестирования?

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

Отдел тестирования же не возник из вакуума? Как проводилось тестирование ранее - без отдела тестирования?
Раньше тестировали сами программисты, директор (он технарь по образованию).

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

Какие проблемы вы хотите решить с помощью отдела тестирования?
Улучшить качество приложений.

Какую роль исполняете на проекте Вы?
Я тестировщик.)

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

Как построен процесс разработки в целом? И есть ли повод/желание его менять?
Как я понимаю, в процесссе разработки все налажено.

Сколько человек в отделе тестирования?
пока 1

[vuchenka]

Ребят, подскажите, ответ на вопрос. Интересно у кого как.
Как у вас построен процесс тестирования проектов? По пунктам если можно.
Мы открыли отдел тестирования, и вот занимаемся налаживанием.

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

Проекты пишем для себя, а не на продажу...
Думаю в этом нет необходимости, справимся своими силами. По крайней мере, попытаемся...

[Vasiliy]

Проекты пишем для себя, а не на продажу...
Думаю в этом нет необходимости, справимся своими силами. По крайней мере, попытаемся...

Зря вы так. Получается как будто вы себя цените ниже, чем своих заказчиков.

[Vasiliy]

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

Это развитие. А чем было плохо без тестировщика то?

Какие проблемы вы хотите решить с помощью отдела тестирования?
Улучшить качество приложений.

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

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

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

[clipsa]

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

[vuchenka]

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

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

[Rebz]

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

[pachkun]

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

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

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

[vuchenka]

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

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

[Rebz]

Успехов, нелегкое это дело - налаживать процесс, особенно не зная как он должен работать (тяжело без опыта). Хотя если приложить голову, то все можно устроить :)

[vuchenka]

а никто не может написать как у вас процесс тестирования проекта осуществляется?
2.

[ShortLegged]

Какие проблемы вы хотите решить с помощью отдела тестирования?
Улучшить качество приложений.

Качество приложений кого-то не устраивает? Почему его нужно улучшать?

Как построен процесс разработки в целом? И есть ли повод/желание его менять?
Как я понимаю, в процесссе разработки все налажено.

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

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

[Vasiliy]

а никто не может написать как у вас процесс тестирования проекта осуществляется?
2.

Описать можно, но вряд ли вам это много чего даст.

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

[clipsa]

Алеся/Ирина...вы бы хотя бы с именем бы определились... :-)

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

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

В общем - удачи и успехов! :-)