С чего начать, если нет документации?

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

PS.Извините, за сумбурное изложение мыслей.

У нас тоже самое и это очень мрачно. Из-за таких ошибок в процессе ничего реального делать не получсется и внедрять тоже :( Бьёмся головой об стенку :(

Я вообщем-то начинающий тестировщик, и в запасе только теоретические сведения по организации процесса.
В принципе, все нормально,так как команда небольшая 6 программистов , программисты решают свои задачи и продукт выходит работоспособный, хотя и ошибок хватает.
Но ПМ требует четкой оценки качества и сроков тестирования при нечетком процессе разработки.Вот и хотелось бы узнать кому нибудь из более опытных людей удалось найти решение которое бы устроило всех.

Добры дзень у хату.

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

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

вот.

Всем доброго времени суток.

Да. Тест кейсы по-моему будут самым нормальным решением.

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

Я думаю, что это самый минимум. И он должен быть обязательно.

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

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

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

вот...

Требования опять таки формируются из представлений разных людей которые, предлагают те или другие "навароты" которые прикручиваются по ходу разработки

Пусть они эти навороты и представляют в виде документов... а во по ним пишите тест кейсы...

И не так все страшно как было :)

попробуйте малыми шагами.

нет документации - поставьте Wiki и выписывайте кратко, что знаете (usecases / how it works, why it works that way).
Девелоперы увидят, что что-то не так описано - или поправят сами, или скажут.
Делайте это по ходу получения информации и/или обдумывания тест кейзов.

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

вместо test cases пишите краткие check lists - все равно в такой обстановке, как правило, функциональность/требования меняются часто.

почитайте про context-driven testing, не пытайтесь вводить heavy-weight processes.

"тестировщик ищет ошибки исходя из своих представлений о программе" - это OK, просто "представление о программе" должно быть правильным =) и синхронизированным со всей командой.

оценивайте риски, и базируйте regression testing на этих оценках + checklists.

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

вместо test cases пишите краткие check lists - все равно в такой обстановке, как правило, функциональность/требования меняются часто.

Согласна Мы пишем чеклист, в котором 5 колонок:
1) Номер и название тест-кейса
2) Авто - является ли тест автоматизированным?
3) Описание - в этой колонке мы кратко описываем ожидаемый результат или какие-либо особенности
4) Результат - прошел тест или провалился
5) Номер(а) отчета(ов) об ошибке(ах) - в случае если тест провалился.
Тесты сгруппированы по юз-кейсам. Как таковых юз-кейсов у нас нет, но мы выделяем их из функциональности.
Чеклист мы храним в Excel, причем для каждой новой версии создаем отдельный лист. В колонке с номерами отчетов об ошибках мы храним не только ошибки, найденные в текущей версии, но и в предыдущих версиях. Мы раскрашиваем их в разные цвета в соответствии со статусом ошибки (new, assigned, resolved, closed)
Что касается требований, в нашей компании они выясняются в чате с заказчиком, постоянно уточняются и изменяются, время для ведения документации не выделяется, поэтому наиболее эффективным способом отразить постоянные изменения для нас является колонка Описание в чеклисте.

Ребята,

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

Что является базовым элементом в тестировании?
Ответ очевиден - проверка правильности базового элемента программы.

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

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

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

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

Для начала рекомендую писать тест кейсы и согласовывайте их с разработчиками. Это муторное занятие (согласование) будет занимать много времени особенно вначале, но поможет выработать единый подход к одинаковому пониманию функциональности. Тест кейсы позволят начать применять регрессионное тестирование и возможность оценить проделанную работу (что должно особенно монравиться ПМ :-)).

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

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

А вы попробуйте составить тест матрицу по покрытию функциональности без документации!!! Вы функции приложения из головы брать будете или из меню преложения :)

Пердложения:
1. Давить на ПМ чтоб была документация, возможно следует нанять технического писателя.
2. Взять законченное приложение и полностью протестировать, по ходу действия записывая что было протестировано и найденные ошибки. Тем самым можно будет собрать чеклист.
3. Если документация не предвидиться, а все добавления включаются по ходу, то ЗАСТАВТЕ хотя бы программеров вести примитивный Changelog, пусть указываю, что было изменено/добавленно/пофикшено в данном билде.

гг. Приятно, что не один я работаю на Титанике...

Лично я в этой ситуации решил свою группу потихоньку изолировать и формализовать отношения со всеми, чем и занимаюсь сейчас. Ради этого остановить процесс тестирования новых версий не могу, но тоже потихоньку перевожу его на какую-то формализацию и координированность. ПМ хочет ответа что "ошибок нет и проблем у заказчика не будет ВООБЩЕ". Гарантий хочет. То есть ВООБЩЕ не понимает, что такое тестирование. В такой ситуации толковых доков не добьешься.

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

Направление "Проломить ПМа и заставить его ..." - сомнительно. По крайней мере у нас.

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

гг. Приятно, что не один я работаю на Титанике...
ПМ хочет ответа что "ошибок нет и проблем у заказчика не будет ВООБЩЕ". Гарантий хочет. То есть ВООБЩЕ не понимает, что такое тестирование. В такой ситуации толковых доков не добьешься.

Направление "Проломить ПМа и заставить его ..." - сомнительно. По крайней мере у нас.

Что же это за ПМ такой? Чей-то хороший знакомый?

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

А вы попробуйте составить тест матрицу по покрытию функциональности без документации!!! Вы функции приложения из головы брать будете или из меню преложения :)

Пердложения:
1. Давить на ПМ чтоб была документация, возможно следует нанять технического писателя.
2. Взять законченное приложение и полностью протестировать, по ходу действия записывая что было протестировано и найденные ошибки. Тем самым можно будет собрать чеклист.
3. Если документация не предвидиться, а все добавления включаются по ходу, то ЗАСТАВТЕ хотя бы программеров вести примитивный Changelog, пусть указываю, что было изменено/добавленно/пофикшено в данном билде.

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

1. А вы точно уверены, что документация не "задушит" проект? Я не против документации, я против ее избыточности. Что будет писать технический писатель? Прецеденты? Классы? Диаграммы размещения? Так эти артефакты должны делать другие люди.
2. А пока оно не закончено, что делать?
3. Что пофикшено вы узнаете из базы ошибок. То над чем действительно надо работать: "Программисты должны вовремя отмечать, какие ошибки исправлены". Вот на это времени может уйти много. Если конечно у вас нет парабеллума. Что сделано нового нужно узнавать из тасктрекера.
А Changelog не работает. Т.е в теории все здорово, но на практике все сложнее.

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

Лучше наоборот устанавливать тесные взаимосвязи.

ПМ хочет ответа что "ошибок нет и проблем у заказчика не будет ВООБЩЕ". Гарантий хочет. То есть ВООБЩЕ не понимает, что такое тестирование.

Вот это очень тяжело. Более того, это может оказаться смертельным. Для проекта или команды.

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

Что я не понимаю. А до этого кому ошибки попадали? ПМ? А ему то они зачем?
В данном случае "скрипач не нужен".

Порадовало вот это:

ПМ хочет чтобы тестировщики отчитывались о том насколько качественно ... протестирована будет программа.

А он что, знает критерии оценки качества тестирования? У меня в этом есть сомнения... Если нет, то имеет смысл предложить критерии, по которым оно всегда будет выполнено качественно :)

А отсутствие доки... ну что же, бюрократия не всегда выгодна... учитесь работать без них. Как? Тут уже подробно описано. :)

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

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

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

Если ПМ не обеспечил вас документацией. то требовать от вас отчета бессмысленно. Формально правильным, но хамским по форме будет такой диалог:
- Когда будет протестирована программа?
- Через три дня после того как я получу специфицию, я вам отвечу, когда будет протестирована программа.

- Когда будет протестирована программа?
- Через три дня после того как я получу специфицию, я вам отвечу, когда будет протестирована программа.

Злой вы :)

- Когда будет протестирована программа?
- Через три дня после того как я получу специфицию, я вам отвечу, когда будет протестирована программа.

Злой вы :)

Зато это жизненно и правдиво.

Зато это жизненно и правдиво.

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