ведение документации
#1
Отправлено 13 сентября 2004 - 08:52
Наша организация прошла следующие стадии роста и "переоценки ценностей":
--на начальной стадии тестеры пытались писать полноценные тест-кейсы, это красиво ,но не эффективно и не результативно при данных условиях
--была попытка написания требований для последующего тестирования непосредственно по требованиям
--сейчас мы остановились на написании требований в таблицах в соответствии с типом окна: Окно-грид; окно, содержащее поля; окно-фильтр; требования для контекстного меню (если кого-то интересует сам вид таблиц - пишите на е-майл). После написания требований результаты тестирования документируются в отдельной таблице в самом простом виде - номер требования: passed/failed -номер ощибки(если она обнаружена).
Поделитесь своими принципами документирования в вашей организации, если она относится к описанному типу.
хотелось бы добавить информации непосредственно про сам продукт нашей организации. Мы разрабатываем банковское ПО, понятно что данная тема форума должна касаться программ, схожих по строению - т.е. набор секвел- запросов с обработкой информации.
Анжелика, Ведущий специалист отдела тестирования
Минск, Беларусь
angeldrr@tut.by
#2
Отправлено 13 сентября 2004 - 12:12
могу сказать, что путь, пройденный вашей организацией, типичный. Как правило, все начинают с классического подхода в оформлении документации. И как же иначе?! Ведь все пишут, что это необходимо.
Но столкнувшись на практике с тем, что документы пишутся только вначале проекта и потом не поддерживаются в актуальном состоянии, постепенно количество документации сводится к минимуму.
И вот здесь, начинается отправная точка творческого подхода к работе.
B)
Что же должно входить в набор проектной документации отдела тестирования, как это оформлять и как этим пользоваться?
Мой ответ - ВСЕ!
Хотите верьте, хотите нет. Но все описанное в книжках правда.
:P
Нужены тест план, тест кейсы, матрица покрытия требований тестами, матрица входных и выходных данных, баг трекинг и регулярные отчеты о прогрессе тестирования проекта.
Другой вопрос - какую информацию должны содержать эти документы?
Давайте рассмотрим, какие функции несет в себе документация.
1. Описательная - кто, что, зачем?
2. Регламентирующая - кто, что, как и в какой последовательности?
3. Календарная - где были, где сейчас и где будем к определенному сроку?
4. Стабилизационная - насколько "устойчива" работа и насколько быстро она может прийти в норму после стрессов?
5. Прогнозная - какие проблемы могут ожидать в будущем и как их избежать?
6. Финансовая - кто, что и засколько?
7. Юридическая - где границы и объем ответственности?
(Это всего лишь то, что первое пришло в голову.)
Если вы думаете, что все эти моменты можно опустить, то вы ошибаетесь.
Следующий вопрос - в каком объеме должны быть описаны основные моменты проекта?
Это уже зависит от того, на кого работает ваша организация и насколько полно она желает управлять бюджетом проекта.
Если вы разрабатываете продукт для своих нужд, то некоторые вопросы можно подробно не расписывать. Например, за что именно несет ответственность фирма в вопросах тестирования продукта.
Но если вы пишете ПО для банка, то это становится одной из ключевых проблем. Кто будет отвечать, если банк понесет убытки вследствие программного деффекта, который не был обнаружен на стадии тестирования?
Кто будет отвечать, если такой дефект был обнаружен тестировщиками, но не устранен программистами из-за нехватки времени?
Как построить работу с банком, что бы он понимал и отслеживал весь процесс создания ПО, включая тестирование?
Или другой пример.
Проект подходит к концу. Все работают с максимальным напряжением (может быть даже сверхурочно). Неожиданно, один тестировщик заболел и выбыл из процесса. Возможны три варианта развития событий:
1. отдел тестирования работает еще больше;
2. переносятся сроки сдачи (в моей практике такого еще ни разу не было ;) ) или игнорируется объем работ, который должен был сделать заболевший тестировщик;
3. приглашается дополнительный тестировщик или разработчик на место выбывшего. Наиболее эффективный вариант, на мой взгляд.
Как максимально быстро ввести нового тестировщика в курс дела?
Дать ему уже подготовленные тест кейсы и поставить на регресионное тестирование.
В качестве итога хочу подчеркнуть главную мысль.
Документация - это всего лишь составная часть работы или процесса (как вам будет угодно). Она характеризует зрелость компании и, соответственно, готовность компании к стабильной работе. Естественно, ведение документации отбирает часть времени (и иногда очень ощутимую). Это нужно знать и эти расходы должны быть запланированы в тестировочном процессе.
B)
#3
Отправлено 13 сентября 2004 - 12:49
Но я не хотела бы закрывать эту тему, потому как данный ответ сулит нам вот какое будущее:
--тестеры пишут требования (30-40% рабочего времени, если поставленная задача новая)
--тестеры пишут тест-кейсы (30-40% раб. времени)
--тестеры тестируют программу по созданным ими тест-кейсам в соответствии с поставлеными ими требованиями :P (50 % .....уже не хватает...)
--тестеры разрабатывают матрицу покрытий
--тест план ....
Я хочу сказать, что если в команде 4-5 человек... и проект достаточно большой - это практически нереально)). Предложения по "приобретению" новых тестеров заранее отклоняю))
Может всё -таки есть способ минимизирования каких-либо документов?
#4
Отправлено 13 сентября 2004 - 12:56
:)
Печатать уже начали.
Может начать писать книги?
:D
#5
Отправлено 13 сентября 2004 - 13:11
А если начать жалеть тестировщиков -- так можно и про программистов рассказать, что их жалко, бедненьких станет:
-- программисты пишут требования (а что иначе они будут реализовывать, не зная требований?) -- 30-40%
-- программисты кодируют -- 50%
-- программисты отлаживают код -- 50%
-- программисты документируют код -- 50%
-- программисты исправляют ошибки, найденные тестерами
-- программисты ...
Секрет в том, чтобы организовать работу так, чтобы и всё сделано было, и ни у кого больше 100% (ну, в крайнем случае 150% :)) не было. Это пытается сделать менеджер проекта, и его тоже, бедненького, становится жалко :)
Всех жалко. Где же выход?
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium
#6
Отправлено 13 сентября 2004 - 13:15
Скоро тестеры кодировать начнут :D--тестеры пишут требования (30-40% рабочего времени, если поставленная задача новая)
Подумайте в сторону разработки тест-кейсов в формате flow диаграм.
По идее их поддерживать в актуальном состоянии легче. Но (а как же без но? ;) ) квалификация тестировщиков должна быть соответствующей.
Я немного покопался в этом направлении, еще какие проблемы могут возникнуть:
в диаграмме не очень-то порасписываешь, что как и куда
в диаграмме негде ставить галочки ;)
Будет интересно узнать, кто еще смотрел в эту сторону и к каким выводам пришел.
#7
Отправлено 13 сентября 2004 - 13:21
Во-первых, подготовить шаблоны документов (но думаю, что вы и сами об этом догадались :) ).
Во-вторых, четко определить место и роль каждого документа в процессе.
Например, тест план пишется один раз в начале проекта и потом только периодически обновляется, если меняются существенные условия проведения тестирования.
В-третьих, все тесты надо разделить как минимум на 3 категории: smoke tests, critical path tests, extended tests.
Тест кейсы обязательно нужно писать для первой категории тестов, частично для второй и если останется время - для третьей.
Частично тест кейсы можно заменить (а некоторые заменяют полностью) матрицей контрольных точек (check points), но это не равнозначная замена, а подмена понятий. Такая матрица не может заменить тест кейсы.
Смотрите, сколько времени уже удалось высвободить для тестирования.
:rolleyes:
Без матрицы отслеживания покрытия требований вам вообще не обойтись. Иначе, как вы будуте знать сколько протестировали и сколько осталось. Такая таблица пишется один раз и обновляется только если вносятся изменения в требования к системе. Писать отдельно тестировочные требования не нужно, так как они повторяют требования к системе (но не путать с требованиями к тестированию - это в тест план).
В общем, не все так страшно.
B)
#8
Отправлено 13 сентября 2004 - 13:35
Если есть такие - скажите, это из-за, а) скажем, профессионализма тестеров или б) благодаря организации и финансированию? Из-за чего в большей степени?
#9
Отправлено 13 сентября 2004 - 13:37
На самом деле шаблоны для документирования у нас на самом деле есть (разработанные мной ;) ). Меня смущает отсутствие непосредственно самих тест-кейсов. Т.е. шаблоны у нас используются для написания требований.
Я исходила из каких принципов: требования нам писать в любом случае надо... можно ли как-то подогнать тест-кейсы в требования??
Например:
Требование: при нажатии на кнопку Х запись с созданным договором должна отображаться в таком-то гриде такого-то окна.
Тест-кейс: 1. Активируйте такое-то окно
2. Нажмите на кнопку Х
3. Проверьте что запись отобразилась в гриде текущего окна
4. Проверьте корректность отображённых данных
Мне кажется, что если тестер не дурак (даже вновь пришедший вместо временно заболевшего ;) -т.е. который не введён особо в курс дела), то по данному требованию он проделает именно эти шаги тестового сценария.
Здесь конечно подразумевается что тестеры достаточно творческие люди и с воображением у них нет проблем.
мне кажется что есть какой-то достаточно простой способ... но он основан на другом подходе -нежели описанных в книгах... Вот этот-то подход я и пытаюсь найти:) Это должно быть нечто новое изначально:)
Не знаю - понял ли меня кто-нить))))
#10
Отправлено 13 сентября 2004 - 13:55
Вот что мне непонятно, так это как работают Ваши программисты? Они-то чем руководствуются при разработке, если требования пишут только тестировщики для собственных нужд?Я исходила из каких принципов: требования нам писать в любом случае надо...
Теперь к существу дела.
В какой-то мере подогнать тесты к требованиям удаётся, но не в точности. Причина в том, что тесты не обязательно находятся во взаимно-однозначном соответствии с требованиями -- один тест может проверять выполнение несколько требований в некоторой конкретной ситуации, или наоборот -- для проверки некоторого требования в разных ситуациях необходимо несколько тестов. Именно отсюда и возникает матрица соответствия.
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium
#11
Отправлено 13 сентября 2004 - 14:05
Есть постановка задачи, она описана вобщем... т.е. что и как должно работать в принципе. Программисты думают как они могут реализовать постановку. Руководитель данной задачи (тоже программист) ездит в банк -заказчик и некоторые возникшие вопросы решает непосредственно там. Мы же начинаем тестировать уже нейкую работающую версию... по ходу дела определяем требования, по возникшим вопросам обращаемся к программистам.
Постановка, конечно, у нас тоже имеется.
#12
Отправлено 13 сентября 2004 - 14:10
То есть требования вы пишете, отталикиваясь от реализации?Объясняю, как работают наши программисты :)
Есть постановка задачи, она описана вобщем... т.е. что и как должно работать в принципе. Программисты думают как они могут реализовать постановку. Руководитель данной задачи (тоже программист) ездит в банк -заказчик и некоторые возникшие вопросы решает непосредственно там. Мы же начинаем тестировать уже нейкую работающую версию... по ходу дела определяем требования, по возникшим вопросам обращаемся к программистам.
Постановка, конечно, у нас тоже имеется.
Хм, а как же вы тогда догадываетесь, правильно программисты её сделали или нет? Получается, что если "не падает", то всё по-определению правильно. Или тестировщики тоже ездят в банк-заказчик, независимо от разработчиков? B)
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium
#13
Отправлено 13 сентября 2004 - 14:11
Ненаписанные тест кейсы - непроведенные тесты?В-третьих, все тесты надо разделить как минимум на 3 категории: smoke tests, critical path tests, extended tests.
Тест кейсы обязательно нужно писать для первой категории тестов, частично для второй и если останется время - для третьей.
Почему для critical path tests можно частично не писать тест кейсы ?
Какого рода тесты входят в extended tests?
Анжелика, просто творчеством и совмещением ролей при недостатке ресурсов, проблему, на мой взгляд, не решить. Ищите деньги, убеждайте руководство в необходимости ресурсов и инструментов. А способ этот не прост :).
(Это как учителям говорили директора: денег пока нет, но вы должны работать творчески, искать новые методы.)
#14
Отправлено 13 сентября 2004 - 14:27
Хотелось бы всё-таки определить набор необходимых документов для тестирования по минимуму.
#15
Отправлено 13 сентября 2004 - 14:29
Потому что тест кейсы это не панацея, а инструмент.Почему для critical path tests можно частично не писать тест кейсы ?
Если у вас есть время на написание тест кейсов - пишите. Если нет - тестируйте.
B)
Это не означает, что писать не надо. Просто под прессингом временного фактора приоритет отдается основному виду деятельности, а не вспомогательному.
#16
Отправлено 13 сентября 2004 - 14:33
На форуме я уже расписывал такой подход в разделении тестов. По этому коснусь его вкратце.В-третьих, все тесты надо разделить как минимум на 3 категории: smoke tests, critical path tests, extended tests.
Какого рода тесты входят в extended tests?
Smoke tests - служат для определения тестопригодности очередного билда или релиза.
Critical path tests - тестируют наиболее вероятные пути использования приложения.
Extended tests - тестируют все остальное, что нужно протестировать, если осталось время.
#17
Отправлено 13 сентября 2004 - 14:33
#18
Отправлено 13 сентября 2004 - 14:36
Очень правильное сообщение, грин)) Вы мне всё больше нравитесь)) ;)
Не зря мы из одного города.
:)
Сожалею, но должен вас огорчить.
В вашей компании не существует процесса разработки программного обеспечения. Точнее, то что у вас есть, это не процесс.
:(
Но не расстраивайтесь.
Это означает, что есть куда рости.
:rolleyes:
#19
Отправлено 13 сентября 2004 - 14:43
Именно сейчас мы должны установить основные критерии тестирования и типы документации... Когда всё станет на налаженную колею - будет проще.
Поэтому не судите строго, мы ещё очень маленькие, но очень хотим вырасти))
Для чего и спрашиваем у более опытных людей))
#20
Отправлено 13 сентября 2004 - 14:48
Вся теория проштудирована и анализирована... но действительно ли необходимо вести всю документацию?
Количество пользователей, читающих эту тему: 0
0 пользователей, 0 гостей, 0 анонимных