Интересует какие документы реально используются вами при тестировании ПО.
Может быть кто-то считает, что спецификации на программу достаточно и не нужно тратить время на все остальное. Поделитесь опытом, пожалуйста.
Здравствуйте, Dummy, Вы писали:
D>Интересует какие документы реально используются вами при тестировании ПО. D>Может быть кто-то считает, что спецификации на программу достаточно и не нужно тратить время на все остальное. Поделитесь опытом, пожалуйста.
Делюсь
— План тестирования (что, как, когда, кем и какими средствами будет тестироваться).
— Спецификации тестов.
— Сами тесты.
— Протоколы прогона тестов (тестлоги).
— Багрепорты по результатам прогона тестов. Их лучше хранить в специальной системе отслеживания
дефектов и запросов на изменение системы.
Здравствуйте, bkat, Вы писали:
B>Здравствуйте, Dummy, Вы писали:
D>>Интересует какие документы реально используются вами при тестировании ПО. D>>Может быть кто-то считает, что спецификации на программу достаточно и не нужно тратить время на все остальное. Поделитесь опытом, пожалуйста.
B>Делюсь
B>- План тестирования (что, как, когда, кем и какими средствами будет тестироваться). B>- Спецификации тестов. B>- Сами тесты. B>- Протоколы прогона тестов (тестлоги). B>- Багрепорты по результатам прогона тестов. Их лучше хранить в специальной системе отслеживания B>дефектов и запросов на изменение системы.
B>Пожалуй этого будет достаточно.
Да, еще, сами тесты тоже надо тестировать, но это уж как получится.
Первые прогоны тестов могут рассматриваться как тестирование тестов.
Но спецификации тестов можно проверять и вручную, если конечно на это хватит сил...
Здравствуйте, bkat, Вы писали:
B>Здравствуйте, Dummy, Вы писали:
D>>Интересует какие документы реально используются вами при тестировании ПО. D>>Может быть кто-то считает, что спецификации на программу достаточно и не нужно тратить время на все остальное. Поделитесь опытом, пожалуйста.
B>Делюсь
B>- План тестирования (что, как, когда, кем и какими средствами будет тестироваться). B>- Спецификации тестов. B>- Сами тесты. B>- Протоколы прогона тестов (тестлоги). B>- Багрепорты по результатам прогона тестов. Их лучше хранить в специальной системе отслеживания B>дефектов и запросов на изменение системы.
B>Пожалуй этого будет достаточно.
Это все теоретически и если следовать стандартам.
Есть ли какая польза от, допустим, тест-плана в небольшой команде?
То что там описывается — нетрудно держать в памяти.
Вот с этими пунктами я согласен — способствуют систематизации тест-процесса.
Если проект не мелкий, то легко просто забыть что тестировалось, а что нет.
1. Спецификации тестов.
2. Сами тесты.
3. Багрепорты
В чем необходимость(практическая) ведения Протоколов прогона тестов (тестлоги)?
Здравствуйте, Dummy, Вы писали:
D>Здравствуйте, bkat, Вы писали:
B>>Здравствуйте, Dummy, Вы писали:
D>>>Интересует какие документы реально используются вами при тестировании ПО. D>>>Может быть кто-то считает, что спецификации на программу достаточно и не нужно тратить время на все остальное. Поделитесь опытом, пожалуйста.
B>>Делюсь
B>>- План тестирования (что, как, когда, кем и какими средствами будет тестироваться). B>>- Спецификации тестов. B>>- Сами тесты. B>>- Протоколы прогона тестов (тестлоги). B>>- Багрепорты по результатам прогона тестов. Их лучше хранить в специальной системе отслеживания B>>дефектов и запросов на изменение системы.
B>>Пожалуй этого будет достаточно.
D>Это все теоретически и если следовать стандартам. D>Есть ли какая польза от, допустим, тест-плана в небольшой команде? D>То что там описывается — нетрудно держать в памяти.
Да нет, это практика. Если на проекте есть выделенный тестер,
то все это уже можно делать. Почему бы заранее определить, как будет тестироваться
система. А может вам специальный тестовый комплекст создавать придется.
D>Вот с этими пунктами я согласен — способствуют систематизации тест-процесса. D>Если проект не мелкий, то легко просто забыть что тестировалось, а что нет.
D>1. Спецификации тестов. D>2. Сами тесты. D>3. Багрепорты
D>В чем необходимость(практическая) ведения Протоколов прогона тестов (тестлоги)?
Чтобы было видно, что ВСЕ тесты были прогнаны, а не те, которые захотел тестер.
Если тестирование автоматическое, то логи создаются вообще автоматом.
Кстати, я еще забыл про RTM
Полезно иметь для того, чтобы оценить покрытие требований тестами.
Хотя бы один тест на одно требование иметь надо.
1. Project Manager дает задачу девелоперу
2. Девелопер реализует ее и отдает на тестирование
3. Тестер проводит тестирование и сообщает результаты.
Т.е. тестеру заранее не известны требования и тестируется только то что приходит от разработчика.
Все это ведется через багтрекинговую систему.
1. Получил задачу
2. Реализовал
3. Отправил тестировать
4. IF тест не пройден GOTO 2.
5. Интегрировал в систему
СтОит ли в этом случае создавать тестплан, вести тестлоги, матрицу требований.
А вот спецификации тестов и сами тесты — вещь по-моему действительно необходимая, которую надо было бы не только задокументировать но еще и подвергнуть контролю версий. Для регрессионного тестирования без них не обойтись.
D>А если работа ведется таким образом:
D>1. Project Manager дает задачу девелоперу D>2. Девелопер реализует ее и отдает на тестирование D>3. Тестер проводит тестирование и сообщает результаты.
D>Т.е. тестеру заранее не известны требования и тестируется только то что приходит от разработчика. D>Все это ведется через багтрекинговую систему. D>1. Получил задачу D>2. Реализовал D>3. Отправил тестировать D>4. IF тест не пройден GOTO 2. D>5. Интегрировал в систему
Что в этом случае будет проверять тестер?
Как решит, что это ошибка, а это — нет?
За исключением очевидных случаев, когда система просто грохается,
тестер при таком подходе не будет знать, на основании чего он тестирует.
Здравствуйте, bkat, Вы писали:
B>Здравствуйте, Dummy, Вы писали:
D>>А если работа ведется таким образом:
D>>1. Project Manager дает задачу девелоперу D>>2. Девелопер реализует ее и отдает на тестирование D>>3. Тестер проводит тестирование и сообщает результаты.
D>>Т.е. тестеру заранее не известны требования и тестируется только то что приходит от разработчика. D>>Все это ведется через багтрекинговую систему. D>>1. Получил задачу D>>2. Реализовал D>>3. Отправил тестировать D>>4. IF тест не пройден GOTO 2. D>>5. Интегрировал в систему
B>Что в этом случае будет проверять тестер? B>Как решит, что это ошибка, а это — нет? B>За исключением очевидных случаев, когда система просто грохается, B>тестер при таком подходе не будет знать, на основании чего он тестирует.
Есть спецификация на разрабатываемую программу.
Там описывается как система должна реагировать на действия пользователя.
Здравствуйте, Dummy, Вы писали:
D>Здравствуйте, bkat, Вы писали:
B>>Здравствуйте, Dummy, Вы писали:
D>>>А если работа ведется таким образом:
D>>>1. Project Manager дает задачу девелоперу D>>>2. Девелопер реализует ее и отдает на тестирование D>>>3. Тестер проводит тестирование и сообщает результаты.
D>>>Т.е. тестеру заранее не известны требования и тестируется только то что приходит от разработчика. D>>>Все это ведется через багтрекинговую систему. D>>>1. Получил задачу D>>>2. Реализовал D>>>3. Отправил тестировать D>>>4. IF тест не пройден GOTO 2. D>>>5. Интегрировал в систему
B>>Что в этом случае будет проверять тестер? B>>Как решит, что это ошибка, а это — нет? B>>За исключением очевидных случаев, когда система просто грохается, B>>тестер при таком подходе не будет знать, на основании чего он тестирует.
D>Есть спецификация на разрабатываемую программу. D>Там описывается как система должна реагировать на действия пользователя.
Тогда я тебя не понял.
Ты говорил, что "тестеру заранее не известны требования и тестируется только то что приходит от разработчика."
Зачем от тестера скрывать требования?
Пусть он потихоньку готовит свои тесты, смотря на требования.
Как только кусок системы будет готов, у тестера будут готовы тесты.
В общем если цель тестирования — найти ошибки, а не убедиться,
что система иногда работает, то к тестированию надо готовиться серьезно.
Здравствуйте, bkat, Вы писали:
B>Здравствуйте, Dummy, Вы писали:
D>>Здравствуйте, bkat, Вы писали:
B>>>Здравствуйте, Dummy, Вы писали:
D>>>>А если работа ведется таким образом:
D>>>>1. Project Manager дает задачу девелоперу D>>>>2. Девелопер реализует ее и отдает на тестирование D>>>>3. Тестер проводит тестирование и сообщает результаты.
D>>>>Т.е. тестеру заранее не известны требования и тестируется только то что приходит от разработчика. D>>>>Все это ведется через багтрекинговую систему. D>>>>1. Получил задачу D>>>>2. Реализовал D>>>>3. Отправил тестировать D>>>>4. IF тест не пройден GOTO 2. D>>>>5. Интегрировал в систему
B>>>Что в этом случае будет проверять тестер? B>>>Как решит, что это ошибка, а это — нет? B>>>За исключением очевидных случаев, когда система просто грохается, B>>>тестер при таком подходе не будет знать, на основании чего он тестирует.
D>>Есть спецификация на разрабатываемую программу. D>>Там описывается как система должна реагировать на действия пользователя.
B>Тогда я тебя не понял. B>Ты говорил, что "тестеру заранее не известны требования и тестируется только то что приходит от разработчика." B>Зачем от тестера скрывать требования? B>Пусть он потихоньку готовит свои тесты, смотря на требования. B>Как только кусок системы будет готов, у тестера будут готовы тесты.
B>В общем если цель тестирования — найти ошибки, а не убедиться, B>что система иногда работает, то к тестированию надо готовиться серьезно.
Да, это конечно правильно.
Перефразирую вопрос: что я потеряю, если не подготовлю тестплан, тестлоги, матрицу.
Вопрос в том на сколько эффективнее может быть работа при соблюдении всех правил.
Больше времени может быть потрачено только на составление документации, чем на само тестирование.
Это как с автоматизацией — сначала нужно определить нужно тебе это или нет.
На сколько мне известно, в некоторых методологиях разработки ПО основной упор делается на документообороте (например ISO9001), в других документообороту не уделяется особого внимания — если не ошибаюсь XP.
D>Да, это конечно правильно. D>Перефразирую вопрос: что я потеряю, если не подготовлю тестплан, тестлоги, матрицу. D>Вопрос в том на сколько эффективнее может быть работа при соблюдении всех правил. D>Больше времени может быть потрачено только на составление документации, чем на само тестирование. D>Это как с автоматизацией — сначала нужно определить нужно тебе это или нет.
Если не будешь заранее готовиться к тестированию, то потеряешь в качестве.
Готова ли твоя компания платить за качество — это тебе виднее .
Я считаю, что если готовиться к тестированию параллельно с разработкой,
то это с лихвой окупится.
Если ты посадишь тестера за комп, дашь ему систему и требования и скажешь "давай, тестируй..."
то толку не будет. Так можно поступать, когда будут продуманы тесты заранее
и тестеру дается система и тесты, которые он прогоняет и в итоге создает лог.
D>На сколько мне известно, в некоторых методологиях разработки ПО основной упор делается на документообороте (например ISO9001), в других документообороту не уделяется особого внимания — если не ошибаюсь XP.
Я не очень большой спец в XP. Там, насколько я знаю, большое внимание уделяется модульному тестированию.
Тесты модуля могут рассматриваться как один из видов документов.
Но кроме модульного тестирования есть еще, к примеру, системное тестирование,
которое делается по требованиям и в этом случае желательны RTM, тесты и прочее...
Кстати, то что мы тут сейчас с тобой делаем — это попытка спланировать тестирование на твоем
проекте. Т.е. тебя интесует, какие виды тестирования тебе нужны и как это будет отражаться
в документах или других рабочих продуктах (unit tests)...
В итоге то, что ты решишь для себя, можно будет задокументировать и у тебя получится план тестирования,
который можно будет детально обсудить с другими членами команды
В общем, качество не дается просто так, и за него надо платить...
Здравствуйте, bkat, Вы писали: B>Да, еще, сами тесты тоже надо тестировать, но это уж как получится.
Ну, вообще ситуация, когда два бага друг друга компенсируют имеет вероятность второго порядка малости. Поэтому в большинстве практических случаев достаточно просто написать тесты. Как только обнаружено расхождение с ожидаемым результатом — смотреть, кто виноват, тест или тестируемое.
... << RSDN@Home 1.1.0 stable >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
D>Да, это конечно правильно. D>Перефразирую вопрос: что я потеряю, если не подготовлю тестплан, тестлоги, матрицу.
Самое главное — ты потеряешь уверенность в том, что софтина работает. Если у тебя нет письменного документа, в котором стоит галочка "проверено" напротив каждой фичи, то на основании чего ты выставляешь заказчику счет?
Одних спецификаций недостаточно, потому что девелопер постоянно правит баги, внося новые. И может сложиться впечатление, что все фичи были протестированы, хотя на самом деле фича A тестировалась в версии 1.1, а фича B — в версиях 1.1 и 1.2. При этом при починке этой фичи возник regression bug и фича А в 1.2 не работает.
... << RSDN@Home 1.1.0 stable >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, bkat, Вы писали: B>>Да, еще, сами тесты тоже надо тестировать, но это уж как получится. S>Ну, вообще ситуация, когда два бага друг друга компенсируют имеет вероятность второго порядка малости. Поэтому в большинстве практических случаев достаточно просто написать тесты. Как только обнаружено расхождение с ожидаемым результатом — смотреть, кто виноват, тест или тестируемое.
Согласен. Дело только в том, на что делается упор.
Мне известны ситуации, когда ошибок в тестах было больше,
чем ошибок в системе. В этой ситуации прогон тестов означал именно проверку тестов.
Здравствуйте, bkat, Вы писали: B>Согласен. Дело только в том, на что делается упор. B>Мне известны ситуации, когда ошибок в тестах было больше, B>чем ошибок в системе. В этой ситуации прогон тестов означал именно проверку тестов. Я, как пурист-теоретик считаю, что в любом случае упор делается на получение тестрепорта зелененького цвета. А что означали красненькие крестики — вопрос контекстно зависимый, кроме тех случаев, когда априори известно, где багов больше.
... << RSDN@Home 1.1.0 stable >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, bkat, Вы писали: B>>Согласен. Дело только в том, на что делается упор. B>>Мне известны ситуации, когда ошибок в тестах было больше, B>>чем ошибок в системе. В этой ситуации прогон тестов означал именно проверку тестов. S> Я, как пурист-теоретик считаю, что в любом случае упор делается на получение тестрепорта зелененького цвета. А что означали красненькие крестики — вопрос контекстно зависимый, кроме тех случаев, когда априори известно, где багов больше.
Опять же согласен.
Но пробный прогон тестов — это не единственный способ проверки тестов.
Их еще можно проверять вдумчивым чтением (review).
Тоже способ
Может еще кто другие, реально используемые способы подскажет,
как тестировать тесты...
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Dummy, Вы писали:
D>>Да, это конечно правильно. D>>Перефразирую вопрос: что я потеряю, если не подготовлю тестплан, тестлоги, матрицу. S>Самое главное — ты потеряешь уверенность в том, что софтина работает.
Уверенность в том, что программа работает у меня будет когда я буду знать, что тесты
1. составлены правильно
2. охватывают наибольший диапазон функционала
3. тестируют наиболее востребованные функции
4. пройдены
S>Если у тебя нет письменного документа, в котором стоит галочка "проверено" напротив каждой фичи, то на основании чего ты выставляешь заказчику счет?
В роли такого документа выступает багтрекинговая система, где каждая фича и баг имеют определенное состояние для каждой версии программного продукта
S>Одних спецификаций недостаточно, потому что девелопер постоянно правит баги, внося новые. И может сложиться впечатление, что все фичи были протестированы, хотя на самом деле фича A тестировалась в версии 1.1, а фича B — в версиях 1.1 и 1.2. При этом при починке этой фичи возник regression bug и фича А в 1.2 не работает.
Опять же багтрекинговой системы + спецификации думаю будет достаточно.
Здравствуйте, Dummy, Вы писали:
D>Здравствуйте, Sinclair, Вы писали:
S>>Здравствуйте, Dummy, Вы писали:
D>>>Да, это конечно правильно. D>>>Перефразирую вопрос: что я потеряю, если не подготовлю тестплан, тестлоги, матрицу. S>>Самое главное — ты потеряешь уверенность в том, что софтина работает.
D>Уверенность в том, что программа работает у меня будет когда я буду знать, что тесты D>1. составлены правильно D>2. охватывают наибольший диапазон функционала D>3. тестируют наиболее востребованные функции D>4. пройдены
S>>Если у тебя нет письменного документа, в котором стоит галочка "проверено" напротив каждой фичи, то на основании чего ты выставляешь заказчику счет?
D>В роли такого документа выступает багтрекинговая система, где каждая фича и баг имеют определенное состояние для каждой версии программного продукта
Ты что, серьезно в багтрекинговую систему будешь заносить результаты
прогона теста, даже если он прошел успешно?
Туда ты скорей всего занесешь описание бага. Такое описание может содержать
кучу другой вспомогательной информации, которую получится добыть после анализа
непройденного теста.
Тест логи — это не то, на чем есть смысл экономить.
Создавать их — плевое дело, но зато ты точно будешь знать, какие тесты были прогнаны,
а какие — нет. Представь, что у тебя 1000 тестов. Сегодня ты гоняешь одни тесты,
завтра — другие, а послезавтра ты уже забудешь, что гонял 2 дня назад.
А если тесты гоняешь не ты, то как ты узнаешь, сколько тестов, когда
и с каким результатам было прогнано? Спросишь у тестера и поверишь ему на слово?
Другой пример, который показывает полезность тест лога.
Допустим у тебя есть пара сотен тестов, которые надо прогнать
на всех версиях Win, начиная от Win95 и заканчивая WinXP плюс
с разными языками. Тест логи позволяют отслеживать что уже было прогнано
и на каких ОС. Логи помогут не забыть прогнать тесты аккуратно.
Если проверкой логов занимается вообще сторонний человек,
то вероятность что-то забыть будет сведена к нулю.
В общем повторюсь, тестлоги — вещь полезная, получаются практически даром
и в общем-то полезны.
Здравствуйте, bkat, Вы писали:
B>Здравствуйте, Dummy, Вы писали:
D>>Здравствуйте, Sinclair, Вы писали:
S>>>Здравствуйте, Dummy, Вы писали:
D>>>>Да, это конечно правильно. D>>>>Перефразирую вопрос: что я потеряю, если не подготовлю тестплан, тестлоги, матрицу. S>>>Самое главное — ты потеряешь уверенность в том, что софтина работает.
D>>Уверенность в том, что программа работает у меня будет когда я буду знать, что тесты D>>1. составлены правильно D>>2. охватывают наибольший диапазон функционала D>>3. тестируют наиболее востребованные функции D>>4. пройдены
S>>>Если у тебя нет письменного документа, в котором стоит галочка "проверено" напротив каждой фичи, то на основании чего ты выставляешь заказчику счет?
D>>В роли такого документа выступает багтрекинговая система, где каждая фича и баг имеют определенное состояние для каждой версии программного продукта
B>Ты что, серьезно в багтрекинговую систему будешь заносить результаты B>прогона теста, даже если он прошел успешно?
Я имел ввиду то, что судя по состоянию багов и фич можно определить, что будет содержать данная версия программы и что предстоит исправить в следующему релизу.
B>Туда ты скорей всего занесешь описание бага. Такое описание может содержать B>кучу другой вспомогательной информации, которую получится добыть после анализа B>непройденного теста.
B>Тест логи — это не то, на чем есть смысл экономить. B>Создавать их — плевое дело, но зато ты точно будешь знать, какие тесты были прогнаны, B>а какие — нет. Представь, что у тебя 1000 тестов. Сегодня ты гоняешь одни тесты, B>завтра — другие, а послезавтра ты уже забудешь, что гонял 2 дня назад. B>А если тесты гоняешь не ты, то как ты узнаешь, сколько тестов, когда B>и с каким результатам было прогнано? Спросишь у тестера и поверишь ему на слово?
Согласен.
B>Другой пример, который показывает полезность тест лога. B>Допустим у тебя есть пара сотен тестов, которые надо прогнать B>на всех версиях Win, начиная от Win95 и заканчивая WinXP плюс B>с разными языками. Тест логи позволяют отслеживать что уже было прогнано B>и на каких ОС. Логи помогут не забыть прогнать тесты аккуратно. B>Если проверкой логов занимается вообще сторонний человек, B>то вероятность что-то забыть будет сведена к нулю.
B>В общем повторюсь, тестлоги — вещь полезная, получаются практически даром B>и в общем-то полезны.
Вот, такого ответа я и ожидал!
Хотелось бы услышать несколько комментариев в пользу ведения тестплана (желательно с примерами, мне нужно увидеть конкретный результат повышения эффективности тестирования).
Здравствуйте, bkat, Вы писали: B>Опять же согласен. B>Но пробный прогон тестов — это не единственный способ проверки тестов. B>Их еще можно проверять вдумчивым чтением (review).
Я, как, практик, выгужден отметить, что вдумчивое чтение помогает также и при отладке собственно тестируемого кода B>Может еще кто другие, реально используемые способы подскажет, B>как тестировать тесты...
Смотря какие тесты ты имеешь в виду. Автоматизированные — это одно, а те, где просто написано "нажать туда-то, в открывшемся диалоге сделать то-то"... — другое.
... << RSDN@Home 1.1.0 stable >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
.
