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

[Doveangel]

Хотелось бы обменятся опытом по поводу шаблонов для написания документации, приемлемой для небольших организаций с отделом тестирования, например, в 4-5 человек (причём возможно без аналитика). Таких организаций, как известно, немало - поэтому эта тема мне кажется достаточно актуальной. Стандартный подход к написанию документации в данном случае неприемлем - так как для этого требуется гораздо больше временных и человеческих ресурсов.
Наша организация прошла следующие стадии роста и "переоценки ценностей":
--на начальной стадии тестеры пытались писать полноценные тест-кейсы, это красиво ,но не эффективно и не результативно при данных условиях
--была попытка написания требований для последующего тестирования непосредственно по требованиям
--сейчас мы остановились на написании требований в таблицах в соответствии с типом окна: Окно-грид; окно, содержащее поля; окно-фильтр; требования для контекстного меню (если кого-то интересует сам вид таблиц - пишите на е-майл). После написания требований результаты тестирования документируются в отдельной таблице в самом простом виде - номер требования: passed/failed -номер ощибки(если она обнаружена).

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

Анжелика, Ведущий специалист отдела тестирования
Минск, Беларусь
angeldrr@tut.by

[Green]

Анжелика,

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

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

Что же должно входить в набор проектной документации отдела тестирования, как это оформлять и как этим пользоваться?

Мой ответ - ВСЕ!
Хотите верьте, хотите нет. Но все описанное в книжках правда.
:P

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

Другой вопрос - какую информацию должны содержать эти документы?
Давайте рассмотрим, какие функции несет в себе документация.

1. Описательная - кто, что, зачем?
2. Регламентирующая - кто, что, как и в какой последовательности?
3. Календарная - где были, где сейчас и где будем к определенному сроку?
4. Стабилизационная - насколько "устойчива" работа и насколько быстро она может прийти в норму после стрессов?
5. Прогнозная - какие проблемы могут ожидать в будущем и как их избежать?
6. Финансовая - кто, что и засколько?
7. Юридическая - где границы и объем ответственности?
(Это всего лишь то, что первое пришло в голову.)

Если вы думаете, что все эти моменты можно опустить, то вы ошибаетесь.

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

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

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

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

Как максимально быстро ввести нового тестировщика в курс дела?
Дать ему уже подготовленные тест кейсы и поставить на регресионное тестирование.

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

B)

[Doveangel]

Грин, я очень ценю ваше время, потраченное на написание этого мини-use case по "ведению документации" :) . Это достаточно точное и правильное решение проблемы документирования процесса тестирования - сказать по правде- я уже распечатала это и показала сотрудникам :). Ваш труд не потрачен даром. Спасибо.

Но я не хотела бы закрывать эту тему, потому как данный ответ сулит нам вот какое будущее:
--тестеры пишут требования (30-40% рабочего времени, если поставленная задача новая)
--тестеры пишут тест-кейсы (30-40% раб. времени)
--тестеры тестируют программу по созданным ими тест-кейсам в соответствии с поставлеными ими требованиями :P (50 % .....уже не хватает...)
--тестеры разрабатывают матрицу покрытий
--тест план ....

Я хочу сказать, что если в команде 4-5 человек... и проект достаточно большой - это практически нереально)). Предложения по "приобретению" новых тестеров заранее отклоняю))

Может всё -таки есть способ минимизирования каких-либо документов?

[Green]

Спасибо за столь высокую оценку.
:)

Печатать уже начали.
Может начать писать книги?
:D

[barancev]

Собственно, почему только тестировщики -- все пишут. Загляните, например, в RUP, там количество артефактов тестирования вполне пропорционально сопоставимо с остальными подпроцессами. Всем поровну достаётся.

А если начать жалеть тестировщиков -- так можно и про программистов рассказать, что их жалко, бедненьких станет:

-- программисты пишут требования (а что иначе они будут реализовывать, не зная требований?) -- 30-40%
-- программисты кодируют -- 50%
-- программисты отлаживают код -- 50%
-- программисты документируют код -- 50%
-- программисты исправляют ошибки, найденные тестерами
-- программисты ...

Секрет в том, чтобы организовать работу так, чтобы и всё сделано было, и ни у кого больше 100% (ну, в крайнем случае 150% :)) не было. Это пытается сделать менеджер проекта, и его тоже, бедненького, становится жалко :)

Всех жалко. Где же выход?

[Guriy]

--тестеры пишут требования (30-40% рабочего времени, если поставленная задача новая)

Скоро тестеры кодировать начнут :D

Подумайте в сторону разработки тест-кейсов в формате flow диаграм.
По идее их поддерживать в актуальном состоянии легче. Но (а как же без но? ;) ) квалификация тестировщиков должна быть соответствующей.

Я немного покопался в этом направлении, еще какие проблемы могут возникнуть:
в диаграмме не очень-то порасписываешь, что как и куда
в диаграмме негде ставить галочки ;)

Будет интересно узнать, кто еще смотрел в эту сторону и к каким выводам пришел.

[Green]

Вот несколько способов, как сберечь время.

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

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

В-третьих, все тесты надо разделить как минимум на 3 категории: smoke tests, critical path tests, extended tests.

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

Частично тест кейсы можно заменить (а некоторые заменяют полностью) матрицей контрольных точек (check points), но это не равнозначная замена, а подмена понятий. Такая матрица не может заменить тест кейсы.

Смотрите, сколько времени уже удалось высвободить для тестирования.
:rolleyes:

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

В общем, не все так страшно.
B)

[Stasde]

А интересно, есть тут те, у кого нет таких проблем? Т.е. кто может сказать - вот у нас в компании или в команде тестовая документация полная? Что все актуально и детализировано и отслеживается и достаточно.
Если есть такие - скажите, это из-за, а) скажем, профессионализма тестеров или б) благодаря организации и финансированию? Из-за чего в большей степени?

[Doveangel]

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

На самом деле шаблоны для документирования у нас на самом деле есть (разработанные мной ;) ). Меня смущает отсутствие непосредственно самих тест-кейсов. Т.е. шаблоны у нас используются для написания требований.

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

Например:
Требование: при нажатии на кнопку Х запись с созданным договором должна отображаться в таком-то гриде такого-то окна.

Тест-кейс: 1. Активируйте такое-то окно
2. Нажмите на кнопку Х
3. Проверьте что запись отобразилась в гриде текущего окна
4. Проверьте корректность отображённых данных

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

мне кажется что есть какой-то достаточно простой способ... но он основан на другом подходе -нежели описанных в книгах... Вот этот-то подход я и пытаюсь найти:) Это должно быть нечто новое изначально:)

Не знаю - понял ли меня кто-нить))))

[barancev]

Я исходила из каких принципов: требования нам писать в любом случае надо...

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

Теперь к существу дела.

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

[Doveangel]

Объясняю, как работают наши программисты :)

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

[barancev]

Объясняю, как работают наши программисты :)

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

То есть требования вы пишете, отталикиваясь от реализации?

Хм, а как же вы тогда догадываетесь, правильно программисты её сделали или нет? Получается, что если "не падает", то всё по-определению правильно. Или тестировщики тоже ездят в банк-заказчик, независимо от разработчиков? B)

[Stasde]

В-третьих, все тесты надо разделить как минимум на 3 категории: smoke tests, critical path tests, extended tests.

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

Ненаписанные тест кейсы - непроведенные тесты?
Почему для critical path tests можно частично не писать тест кейсы ?
Какого рода тесты входят в extended tests?

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

(Это как учителям говорили директора: денег пока нет, но вы должны работать творчески, искать новые методы.)

[Doveangel]

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

Хотелось бы всё-таки определить набор необходимых документов для тестирования по минимуму.

[Green]

Почему для critical path tests можно частично не писать тест кейсы ?

Потому что тест кейсы это не панацея, а инструмент.

Если у вас есть время на написание тест кейсов - пишите. Если нет - тестируйте.
B)

Это не означает, что писать не надо. Просто под прессингом временного фактора приоритет отдается основному виду деятельности, а не вспомогательному.

[Green]

В-третьих, все тесты надо разделить как минимум на 3 категории: smoke tests, critical path tests, extended tests.

Какого рода тесты входят в extended tests?

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

Smoke tests - служат для определения тестопригодности очередного билда или релиза.

Critical path tests - тестируют наиболее вероятные пути использования приложения.

Extended tests - тестируют все остальное, что нужно протестировать, если осталось время.

[Doveangel]

Очень правильное сообщение, грин)) Вы мне всё больше нравитесь)) ;)

[Green]

Очень правильное сообщение, грин)) Вы мне всё больше нравитесь)) ;)

Не зря мы из одного города.
:)

Сожалею, но должен вас огорчить.

В вашей компании не существует процесса разработки программного обеспечения. Точнее, то что у вас есть, это не процесс.
:(

Но не расстраивайтесь.
Это означает, что есть куда рости.
:rolleyes:

[Doveangel]

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

Именно сейчас мы должны установить основные критерии тестирования и типы документации... Когда всё станет на налаженную колею - будет проще.

Поэтому не судите строго, мы ещё очень маленькие, но очень хотим вырасти))
Для чего и спрашиваем у более опытных людей))

[Doveangel]

Но не стоит думать, что в нашем отделе непрофессионалы. Есть и опыт работы и соответствующие тренинги/курсы. Здесь загвоздка именно в том, что нас мало, а проект достаточно большой. Вопрос о расширении не рассмтривается))

Вся теория проштудирована и анализирована... но действительно ли необходимо вести всю документацию?