Организация процесса тестирования "с нуля"

Здравствуйте.

Дано следующее:

1. Сложный, просто бескрайний многофункциональный проект, который ведется уже несколько лет и конца и края ему не видно
2. XP, характеризующее практически полное отсутствие какой бы то ни было документации
3. Несколько спецификаций в зачаточном состоянии, где на пальцах объяснено, что и как примерно должно быть.
4. Довольно часто изменяющиеся требования к продукту
5. 80% процентов информации - в голове у живущего в командировках product managera
6. Отдел тестирования в лице двух тестеров, при этом каждый занимается только одним проектом. Бригадной слаженной работы нет, лида - тоже
7. BTS в лице JIRA

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

Хоть как-то, step by step, поставить процесс тестирования.

Что придумала я на текущий момент:

1. Нужны требования. Факт. Вот только определение требований (которые насколько я поняла, вырабатываются с заказчиком, а он уже давно одну из первых версий продукта юзает) или сразу спецификация требований- которая обычно зовестя просто спецификацией.
2. Потом написать все тесты. Вот только разрабатывать их сверху-вниз или снизу-вверх? Есть какая-то общая схема?
3. Все это отправить в TestLink
4. План тестирования - не нужен, так как этим занимаюсь я одна, но впоследствии понадобится, когда появятся еще тестеры
5. Насколько подробные нужны отчеты? И какие? Если я сама себе начальник

6. Дальше - автоматизация, нагрузочное. А что еще может понадобиться при наличии только 1 тестера на проект? Имеет ли смысл объединять двух тестеров в команду, оперативно бросающуюся на разные проекты?
7. Как оформляется регрессионное тестирование?

Подскажите пожалуйста, я в верном направлении двигаюсь? Или это одному человеку не сделать да и вообще не нужно?
Заранее спасибо)

Вам не нужно тестирование. Это напрасная трата времени. Ну, не совсем напрасная. Неэффективная трата денег.

Если у организации денег как у дурака махорки и она не знает как их потратить, то дайте мне. Я знаю.


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

> 4. Довольно часто изменяющиеся требования к продукту
Это нормально

> 5. 80% процентов информации - в голове у живущего в командировках product managera
А это - верный путь к краху.

> 7. BTS в лице JIRA
Абсолютно ничего не значит.



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

> 2. Потом написать все тесты. Вот только разрабатывать их сверху-вниз или снизу-вверх? Есть какая-то общая схема?
Зависит от проекта. Очень зависит.

> 3. Все это отправить в TestLink
Или в ворд или в эксель или в ... Разница то в чем?

> 4. План тестирования - не нужен, так как этим занимаюсь я одна, но впоследствии понадобится, когда появятся еще тестеры
Не может быть, чтобы был не нужен.

> 5. Насколько подробные нужны отчеты? И какие? Если я сама себе начальник
Не нужны совсем. До тех пор, пока на их основании не будут делаться выводы.

> 6. Дальше - автоматизация, нагрузочное. А что еще может понадобиться при наличии только 1 тестера на проект? Имеет ли смысл объединять двух тестеров в команду, оперативно бросающуюся на разные проекты?
А автоматизация зачем? Выгоду считали?

Вам не нужно тестирование. Это напрасная трата времени. Ну, не совсем напрасная. Неэффективная трата денег.

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

2. XP, характеризующее практически полное отсутствие какой бы то ни было документации

Что все 12 практик? Если нет, то это не XP, а скорее ХРень :).

Короче прорекамирую Гринкевича http://www.drquality.ru/?p=22 , если еще не видели.

>Вам не нужно тестирование. Это напрасная трата времени. Ну, не совсем напрасная. Неэффективная трата денег.
Однако проект как-то тестируется уже 2 года и даже находится в относительно рабочем состоянии. Что было раньше - судить не берусь, но надо же сделать хоть какое-то подобие системы.

>Вам к другому врачу. К аналитику.
Какой аналитик, вы о чем! На моем проекте это мифическое существо отсутствовало даже при зарождении...

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

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

>А автоматизация зачем? Выгоду считали?
Для ряда нудных простых регрессионных тестов, которые при каждой итерации занимают дня 2-3.

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


>Скорее всего требования составляются непосредственно пишущим программером в формате "что вспомнил, то и записал" + философские умозаключения.
Все несколько сложнее, но по структуре близко)

>Короче прорекамирую Гринкевича http://www.drquality.ru/?p=22 , если еще не видели.
За Гринкевича спасибо, интересно.

>Вам к другому врачу. К аналитику.
Какой аналитик, вы о чем! На моем проекте это мифическое существо отсутствовало даже при зарождении...

Жестко вам будет без аналитика и без требований. Единственный путь чтобы кто-то (догадайтесь кто?) периодически исполнял его роль. Т.е. два дня в неделю аналитик, три дня человек. Причем лучше четко разделять, когда чья роль исполняется, и не смешивать в один день разные роли (переключение контекста до добра не доводит).

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

Расскажу историю из своего теперешнего опыта... (Работаю на проекте уже почти год)
Состав команды:
- продакт менеджер - это самый большой босс на проекте
- апликэйшн менеджер
- 2 разработчика
- 1 тестер (я)
Проекту уже больше 5-ти лет,
- Документации на проекте 130 страниц док написанный 5 лет назад и изменившийся почти на 50% с ходом времени... Вся не документирования инфа находится в голове у продакт менеджера и у апликэйшн менеджера. Добиться от них информации - невозможно...
- BTS есть, но ей пользуются только апликэйшн менеджер и я... потому что все остальные забивают, включая продакт менеджера...

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

Не правда ли похожая ситуация???

У меня возникает очень странное чувство, что если бы меня не было, то все было так же хорошо, как и до меня :)


Вся проблема этого бардака в том, что люди, которые принимают решения не слушают то что им говорят!!! Они думают, что по дуновению волшебной палочки все станет как надо...

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

Кто этим должен заниматься? - если от руководства нет указаний на это

Расскажу историю из своего теперешнего опыта... (Работаю на проекте уже почти год)
Состав команды:
- продакт менеджер - это самый большой босс на проекте
- апликэйшн менеджер
- 2 разработчика
- 1 тестер (я)
Проекту уже больше 5-ти лет,
- Документации на проекте 130 страниц док написанный 5 лет назад и изменившийся почти на 50% с ходом времени... Вся не документирования инфа находится в голове у продакт менеджера и у апликэйшн менеджера. Добиться от них информации - невозможно...
- BTS есть, но ей пользуются только апликэйшн менеджер и я... потому что все остальные забивают, включая продакт менеджера...

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

Не правда ли похожая ситуация???

У меня возникает очень странное чувство, что если бы меня не было, то все было так же хорошо, как и до меня :)


Вся проблема этого бардака в том, что люди, которые принимают решения не слушают то что им говорят!!! Они думают, что по дуновению волшебной палочки все станет как надо...

Ба! Я и не думала, что где-то еще так же весело, как и у меня. С точностью до мелочей :). И самое интересное, да, без меня как-то все чудно справлялялись и все было более-менее хорошо. И всем было удобно. И больше ничего не требовалось. И тут пришла я, видевшая несколько разных систем тестирования, ни одна из которых, к сожалению, не может быть здесь реализована, и срочно начала чего-то хотеть.

И всем было удобно.

Удобно - никаких сомнений. В этом проблема и есть. Самая корневая причина. Раз в проекте появился тестер, значит не всё было так хорошо, значит с чем то не справлялись. Удобно было переложить поиск косяков на чужие плечи. И никак не ожидалось, что тестер начнёт создавать проблемы! Подавай ему документацию, требования, руководство пользователя.. Без него бы проект давно отправили заказчику, ну какие то ошибки он бы обнаружил, какие то нет, на какие то забил... А тестер, мало того что без году неделя, так ещё имеет наглость требовать изменений во всём процессе разработки!
Верно сказал Alfa

Единственный путь чтобы кто-то (догадайтесь кто?) периодически исполнял его роль. Т.е. два дня в неделю аналитик, три дня человек.

Именно так я и потсупил. Бескомпромисно включил в план работ пункт "Восстановление требований". Шок у программеров проходит быстро. Сразу после формирования списка функциональности.

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

Ага.
Только для программеров - я главное зло в конторе.

У меня возникает очень странное чувство, что если бы меня не было, то все было так же хорошо, как и до меня :)

Вся проблема этого бардака в том, что люди, которые принимают решения не слушают то что им говорят!!! Они думают, что по дуновению волшебной палочки все станет как надо...

Кто этим должен заниматься? - если от руководства нет указаний на это

Коллеги!

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

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

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

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

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

>Вам к другому врачу. К аналитику.
Какой аналитик, вы о чем! На моем проекте это мифическое существо отсутствовало даже при зарождении...

Жестко вам будет без аналитика и без требований. Единственный путь чтобы кто-то (догадайтесь кто?) периодически исполнял его роль. Т.е. два дня в неделю аналитик, три дня человек. Причем лучше четко разделять, когда чья роль исполняется, и не смешивать в один день разные роли (переключение контекста до добра не доводит).

Отношусь к далеко не редким,насколько я поняла, тестерам которые пытаются справиться со всем этим беспределом в одиночку..Только что-то не очень выходит. Требования первое время каждый день выпрашивала..в итоге все по прежнему. Я уже подумываю о том чтобы и вправду самой начать их восстанавливать..Это вы имели ввиду под аналитиком? Каким образом в таком случае лучше начать действовать? Что начать анализировать? А то я уже близка к суициду находясь в таком бардаке

У меня по ситуации больше вопросов, чем ответов.
В частности, как себе представляют роль тестирования в процессе разработки ПО Ваши коллеги и начальство?
С программистами более-менее понятно: "для программеров - я главное зло в конторе".
Далее, "люди, которые принимают решения не слушают то что им говорят!!!"

Гм... Как вы вообще заставляете себя подниматься утром на работу?

Неужели ради светлой цели "но надо же сделать хоть какое-то подобие системы." - Зачем? Ради самой системы?

Я уже подумываю о том чтобы и вправду самой начать их восстанавливать..

Не надо суицидов. Варианта 2 - либо тянете всё на себе - восстанавливаете требования, делаете трассировочные матрицы, пишете тесты, находите баги... либо отказываетесь принимать в работу ПО без документации. Второй вариант ещё ни у кого никогда не прокатывал. Тут вытекает одно не очеь очевидное, но очень нужное действие - составление WBS. Следует показать руководству на что и сколько вы тратите времени, чем оборачивается для него восстановление требований после написания кода в денежно-времнном выражении, в том числе и стоимость рефакторинга. Я так и не написал ещё, кстати. Поглядеть бы на чей ни будь пример...

У меня по ситуации больше вопросов, чем ответов.
В частности, как себе представляют роль тестирования в процессе разработки ПО Ваши коллеги и начальство?
С программистами более-менее понятно: "для программеров - я главное зло в конторе".
Далее, "люди, которые принимают решения не слушают то что им говорят!!!"

Гм... Как вы вообще заставляете себя подниматься утром на работу?

Неужели ради светлой цели "но надо же сделать хоть какое-то подобие системы." - Зачем? Ради самой системы?

Вот вы знаете, хотелось ответить цитатой с Баша "Иногда так хочется засейвиться и сделать Жириновского президентом", перефразируя: так хочется засейвиться и показать разработчикам что после их кодинга и без тестирования система просто не встанет!!

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

Я уже подумываю о том чтобы и вправду самой начать их восстанавливать..

Не надо суицидов. Варианта 2 - либо тянете всё на себе - восстанавливаете требования, делаете трассировочные матрицы, пишете тесты, находите баги... либо отказываетесь принимать в работу ПО без документации. Второй вариант ещё ни у кого никогда не прокатывал. Тут вытекает одно не очеь очевидное, но очень нужное действие - составление WBS. Следует показать руководству на что и сколько вы тратите времени, чем оборачивается для него восстановление требований после написания кода в денежно-времнном выражении, в том числе и стоимость рефакторинга. Я так и не написал ещё, кстати. Поглядеть бы на чей ни будь пример...

Тянуть все на себе этузазизма не хватит надолго!

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

З.Ы. Сам такой анализ делал. Простой документ в Ворде аля: 1. описание проблем и времени, которе на них тратиться
2. Пути решения указанных проблем с указание времени, которое можно будет сэкономить
3. Итог. Сколько времени можно будет сэкономить в общей сложности и насколько уменьшится срок выпуска продукта без потерь (а может и с увеличеним) в качестве.

Главное чтобы документ был написан достаточно лаконично, иначе могут просто не вникнуть в суть проблем, ибо "многа букафф", а у менеджера и так дел по горло.

Хороший совет насчет подсчета времени..Пожалуй так и поступлю..

Апну тему. Топикстартер, ты где? Что получилось?

Мне кажется, что в маленьких (<30 чел) компаниях ситуации примерно такие же, как в первом посте. Это нормально для них. Начальство таких компаний не хочет тратить время и деньги на оформление каких-то тестов, документации... Чаще всего как? Заполучили заказ. Быстренько обмозговали архитектуру и прочие технические дела. Начали писать код. Написали, сами же разработчики потестили, отдали. Все быстро, дешево, мобильно и гибко - что и требуют от маленьких компаний.
Когда-нибудь решают нанять тестеров - "чтобы улучшить качество". Как - да кто ж их, тестеров, знает? Мы напишем в вакансии "с опытом 3 года", пусть приходит и разруливает. И вот приходит тестер и не знает с какой стороны к такому процессу разработки подойти...
Мое мнение такое. Не надо ставить компанию с ног на голову. Если 60% бюджета будет съедать оформление документации, тестирование, имлементация автотестов и прочего - ничем хорошим это не кончится. Насильно вводить канонический RUP не всегда приемлемо.
Хороший вариант, который первый пришел на ум - завести BTS, вносить и новые требования, и найденные баги туда. Пришел новый билд от разработчиков - начинаем тестить с "имплементированных новинок", заводим еще пару (...десятков) багов касаемо новых фич. Конечно, надо убедить разрабов пользоваться BTS. Как - нужно смотреть по ситуации. Может, действительно, позаписывать куда тратится время тестера, показать начальству и продавить введение BTS. Кстати, пусть и разрабы тоже пишут свои идеи как реализовать ту или иную фичу в BTS. Поможет передавать информацию от разраба разрабу.
Рано или поздно накопится достаточное количество записей, помеченных буквами CR (change request) или fic (ficture). Копируем их в Ворд, группируем, разбираемся с противоречивыми и оформляем. Дешево и сердито заполучили документацию, которая покрывает какую-то часть функционала. И теперь, по крайней мере, можно будет передавать свою работу кому-то еще, кто придет на твое место. Или самому вспоминать, когда наступит время тестить новую версию продукта, которая назрела через 5 лет после предыдущей.
Об оформлении тестов. Не думаю, что нужно обязательно садиться и писать полный тест-план с тысячами тест-кейсов. Есть требование (новая фича), оформленное в BTS. Если оно большое, затрагивает большую часть работающего или сложно для понимания - сделать пометки что и как надо потестить. Не писать подробно "нажать ЛКМ на иконке, убедиться что иконка выделена синим", а просто основные идеи, типа "проверить инсталляцию на х64 архитектуре, синхронизацию, кнопки на экране № 1". Если один тестировщик на проекте - документация нафиг не нужна. Ведь начальство и ПМы вряди ли найдут время читать и анализировать тест-планы. Если заказчик не требует документов по проету, если они никому не интересны - фтопку их.