Зачем нужны Варианты Тестирования?
#1
Отправлено 06 декабря 2006 - 09:50
А как вы думает зачем нуджны варианты тестирвоания??
почему возник такой вопрос??
у нас в компании не все менеджеры проектов считают что при тестировании нужно писать ВТ (тест кейсы). Мы в Цетре тестирования решили написать небольшой список основных причин почему - зачем всетаки они нужны (мы ТЕСТЕРЫ конечно понимаем зачем он нам нужен), но наши мененджеры не хотят, или не могут этого понимать , и естественно не выделяют на это ресурсы.
вот он наш СПИСОК
--------------
Для повышения качества продукта(чем больше и верно написано ТС тем больше функциональности протестовано, тем меньше ошибок в коненом продукте).
Для уменьшения затрат времени на регресионное тестиорование (не потребности снова писать ВТ, достатоно провести уже созданніе ранее ВТ ).
Для облегчения передачи заний новому сотруднику .
Для экономии времени, при фиксации ошибок (можна шаги для воспроизведения брать уже с готового ТС).
Для сдачи продукта клиету (на основе розработаных ВТ можно создать приемочные тесты).
Для контроля и управления тестированием (по ВТ можно проверить покрытие).
Для прогнозирования времени ресурсов на тестиование(оценка трудозатрат при планировании следующих робот).
Для выявления ошибок на раних стадиях разработки(путем статического тестирования требований к продукту).
Для розработки контрольного примера и автоматизации тестов (проще и быстрее автоматизировать тесты уже по описаным шагам ).
Для подтвержедния проведения тестов .
-----------------------------------------------------------------------------
интерстно Ваше мнение по этому поводу
#3
Отправлено 07 декабря 2006 - 02:02
А не смогли бы Вы составить аналогичный список для основных причин, почему тес т кейсы не нужны?Мы в Цетре тестирования решили написать небольшой список основных причин почему - зачем всетаки они нужны (мы ТЕСТЕРЫ конечно понимаем зачем он нам нужен), но наши мененджеры не хотят, или не могут этого понимать, и естественно не выделяют на это ресурсы.
Менеджеры конечно понимают, почему они не нужны, но ваши тестеры не хотят, или не могут этого понимать.
#4
Отправлено 08 декабря 2006 - 08:34
Хотя может и можно тестировать непостредственно по юс кейсам/нормально написанной спецификации?
А менеджеры не просили объяснить, зачем вообще тестирование нужно?
Это ж расходы лишние, ничего не создают, только работать мешают.
#5
Отправлено 08 декабря 2006 - 09:51
но хочеться доказать менеджерам что наша работа(тестеров), совсем не пустая трата времени и денег(в первую очередь денег).
вот собсвенно по этому и решили составить токой список.
если есть какие то дополнения или критика в адрес данного списка хотелось бы почитать.
#6
Отправлено 08 декабря 2006 - 09:57
ну если бы я был менеджером то наверно сотавил бы такой список. но увы я не менеджер (или к счастью не менеджер ).А не смогли бы Вы составить аналогичный список для основных причин, почему тес т кейсы не нужны?Мы в Цетре тестирования решили написать небольшой список основных причин почему - зачем всетаки они нужны (мы ТЕСТЕРЫ конечно понимаем зачем он нам нужен), но наши мененджеры не хотят, или не могут этого понимать, и естественно не выделяют на это ресурсы.
Менеджеры конечно понимают, почему они не нужны, но ваши тестеры не хотят, или не могут этого понимать.
хотя можно попробовать
1. нужно дополнительные ресурсы.
2. этитестеры все рубают на корнюм (находят ошибку в самы не подходящий момент)
3. когда говориш о том что это так и должно быть, то столько вопросов сразу - а почему так , а не этак, а почему почему........
4. сунут свой нос не туда куда следует (хотя скорей всего не туда куда хочет менеджер)
5. ничего сами не могут настроить (а если ... не получается настроить, а собственно кто должен помогать в настройке как не програмер или мп)
* думаю пока достаточно
#7
Отправлено 08 декабря 2006 - 16:35
конечно велосипед не изобретаем.
но хочеться доказать менеджерам что наша работа(тестеров), совсем не пустая трата времени и денег(в первую очередь денег).
вот собсвенно по этому и решили составить токой список.
если есть какие то дополнения или критика в адрес данного списка хотелось бы почитать.
Не надо никому ничего доказывать. ПМ - это не человек с улицы. Либо на то есть причины, либо это клинника...
1. Попробуйте узнать почему в том или ином случае нет места тестированию (может есть вполне понятная причина)
2. Не стоит писать "список доказательства необходимости обязательного проведения тестовых работ перед отправкой очередной версии заказчику", просто не протестируйте очередную версию и пошлите заказчику... Может ваши разработчики так пишут, что общее кол-во ошибок изначально находится в пределах согласованных с заказчиком. А может заказчик и не платит за тестирование на вашей стороне...
Консультант по процессам тестирования
#8
Отправлено 08 декабря 2006 - 16:38
ну если бы я был менеджером то наверно сотавил бы такой список. но увы я не менеджер (или к счастью не менеджер ).
хотя можно попробовать
1. нужно дополнительные ресурсы.
2. этитестеры все рубают на корнюм (находят ошибку в самы не подходящий момент)
3. когда говориш о том что это так и должно быть, то столько вопросов сразу - а почему так , а не этак, а почему почему........
4. сунут свой нос не туда куда следует (хотя скорей всего не туда куда хочет менеджер)
5. ничего сами не могут настроить (а если ... не получается настроить, а собственно кто должен помогать в настройке как не програмер или мп)
* думаю пока достаточно
Либо у вас тестировщики неправильные, либо менеджеры либо компания...
Но что-то (одно или несколько) определенно надо менять...
Консультант по процессам тестирования
#9
Отправлено 09 декабря 2006 - 03:22
Поскольку HOHOL_TC не захотел даже задуматься над моим вопросом, то я отвечу на него сам.А не смогли бы Вы составить аналогичный список для основных причин, почему тес т кейсы не нужны?Мы в Цетре тестирования решили написать небольшой список основных причин почему - зачем всетаки они нужны (мы ТЕСТЕРЫ конечно понимаем зачем он нам нужен), но наши мененджеры не хотят, или не могут этого понимать, и естественно не выделяют на это ресурсы.
Менеджеры конечно понимают, почему они не нужны, но ваши тестеры не хотят, или не могут этого понимать. :smile:
Главное, уменьшение ненужной документации повышет качества продукта, так как при затрате того же времени вы сможете выполнить больше тест кейсов и найти больше ошибок. То есть в этом случае вы больше времени тратите собственно на тестирование и меньше времени тратите на приготовление бумажек, которые, очевидно, вашим менеджерам не требуются.
Также это приводит к повышению качества регрессионного тестирования, потому что из-за большей вариативности ваших регрессионных тестов вероятности нахождения новых дефектов повышается.
У Вас будет также больше времени для передачи знаний новому сотруднику.
и т.п.
#10
Отправлено 13 декабря 2006 - 05:01
Не верю! Сколько ТС ни пиши, качество от этого не растёт. Даже очень сомнительно, что в результате будет "больше функциональности протестовано".Зачем нужны Варианты Тестирования???
--------------
Для повышения качества продукта(чем больше и верно написано ТС тем больше функциональности протестовано, тем меньше ошибок в коненом продукте).
Верю условно. Хотя не очень убедительно звучат слова "нет потребности снова писать ТС", выглядит так, будто это неизбежность -- не сейчас, так потом, лучше уж сейчас отмучаюсь. А вообще, если уж регрессионного тестирования действительно много, имеет смысл потратить часть времени на автоматизацию вместо написания ТС.Для уменьшения затрат времени на регресионное тестиорование (не потребности снова писать ВТ, достатоно провести уже созданніе ранее ВТ ).
Не верю! И мой личный опыт, и разговоры с коллегами показывают, что гораздо эффективнее для этой цели использовать описание требований. Тесты (особенно написанные в виде множества ТС) -- это лоскутное одеяло, глядя на них составить общее представление о системе совершенно невозможно. Если нет описания требований -- лучше потратить время, чтобы сделать его, а не ТС писать.Для облегчения передачи заний новому сотруднику .
Не верю. Один и тот же ТС очень редко находит ошибку повторно, подавляющая часть ТС вообще никогда не превратится в описание ошибки, а тех, которые по несколько раз обнаруживают ошибку и того меньше. Экономия явно не стоит затрат на написание ТС.Для экономии времени, при фиксации ошибок (можна шаги для воспроизведения брать уже с готового ТС).
Верю условно. Как правило бывает наоборот -- приёмочные тесты выкатываются заказчиком заранее. Но если заказчик хочет -- действительно, можно часть разработанных ТС включить в приемо-сдаточный набор. Хотя, вообще-то, по такому случаю опять же лучше автоматизировать эту выбранную часть, на заказчиков это производит благоприятное впечатлениеДля сдачи продукта клиету (на основе розработаных ВТ можно создать приемочные тесты).
Верю условно. Покрытие по ТС померить можно, но это очень недостоверная метрика. Лучше всё-таки, если есть возможность, мерить покрытие требований. Если все требования (в том числе нефункциональные) покрыты тестами -- тогда можно, действительно, считать по тестам.Для контроля и управления тестированием (по ВТ можно проверить покрытие).
Не очень верю. Как правило, следующие работы связаны в большей степени с тестированием новой функциональности. Регрессионное тестирование не должно занимать много времени.Для прогнозирования времени ресурсов на тестиование(оценка трудозатрат при планировании следующих робот).
Верю наполовину. Верю в то, что анализ требований позволяет выявлять ошибки на ранних стадиях, и это хорошо. Не верю в то, что написание ТС является обязательным условием для проведения анализа требований.Для выявления ошибок на раних стадиях разработки(путем статического тестирования требований к продукту).
Верю условно. Дело в том, что автоматизация это программирование. Представьте себе, что программисты каждый вариант использования реализовывали бы независимо от других. Почему они так не делают? Почему они вместо этого строят единую архитектуру системы, в которой все эти варианты использования реализуют? Потому что так эффективнее. И с тестами то же самое -- программировать каждый отдельный TC независимо от других означает сделать кучу лишней работы. Нужно стремиться к построению более сложной архитектуры тестового набора, повышающей степень переиспользования.Для розработки контрольного примера и автоматизации тестов (проще и быстрее автоматизировать тесты уже по описаным шагам ).
Не верю совсем! Если тесты написаны, даже очень много, это ещё не означает, что хотя бы один из них реально выполнен Нужны другие доказательства.Для подтвержедния проведения тестов.
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium
#11
Отправлено 13 декабря 2006 - 07:32
Редактор портала www.it4business.ru
#12
Отправлено 13 декабря 2006 - 12:02
времени??!
С некоторыми пунктами согласен на все 100 такие как
[/quote]
Не верю! Сколько ТС ни пиши, качество от этого не растёт. Даже очень сомнительно, что в результате будет "больше функциональности протестовано".
[quote name='HOHOL_TC' date='Dec 6 2006, 12:50 PM']Для уменьшения затрат времени на регресионное тестиорование (не потребности снова писать ВТ, достатоно провести уже созданніе ранее ВТ ).[/quote] - но сдесь формулировка не очень коректная.
[quote name='HOHOL_TC' date='Dec 6 2006, 12:50 PM']Для подтвержедния проведения тестов.[/quote]
Не верю совсем! Если тесты написаны, даже очень много, это ещё не означает, что хотя бы один из них реально выполнен Нужны другие доказательства. - с этим тоже согласен. - но сдесь имелось ввиду что тесты проведены хотябы один раз
ну а с остальными вроде и так все ясно
#13
Отправлено 13 декабря 2006 - 12:32
Откуда я знаю, зачем? Я вообще не говорил, что они нужны.Алексей, тогда зачем? :)
Но может быть кто-нибудь сможет привести действительно убедительный аргумент "за"?
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium
#14
Отправлено 13 декабря 2006 - 12:41
Чтобы тесты были проведены хотя бы один раз, их нужно ПРОВЕСТИ, а не НАПИСАТЬ. Причём, если они проведены, то писать их вообще говоря уже необязательно (это не я придумал, почитайте труды апологетов exploratory testing -- Канера, Баха, Хоффмана).имелось ввиду что тесты проведены хотябы один раз
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium
#15
Отправлено 13 декабря 2006 - 15:22
Таки втянули меня в обсуждение :)Откуда я знаю, зачем? Я вообще не говорил, что они нужны.Алексей, тогда зачем? :)
Но может быть кто-нибудь сможет привести действительно убедительный аргумент "за"?
Алексей, а я вас поспрашиваю, можно? Как вы проектируете тесты? На вопрос "а зачем проектировать тесты" отвечу "чтобы как минимум знать их количество" и вдогонку задам другой вопрос "а как вы планируете тестирование не имея количества тестов / объёма работ?"
PS
Какой-то преферанс получается, "а тогда ты вот так и так... согласен" :)
Редактор портала www.it4business.ru
#16
Отправлено 18 декабря 2006 - 10:19
Чтобы тесты были проведены хотя бы один раз, их нужно ПРОВЕСТИ, а не НАПИСАТЬ. Причём, если они проведены, то писать их вообще говоря уже необязательно (это не я придумал, почитайте труды апологетов exploratory testing -- Канера, Баха, Хоффмана).имелось ввиду что тесты проведены хотябы один раз
Нда. думаю что Канера вы явно плохо читали. Потому как именно Канер пишет о том что тесты нужно писать, а не в голове держать.
А вот Вам такой вопрос - предположим у Вас н - количество тестов, которые вы хотите провести, скажите вы их все в голове держите?
а если они с большим количеством данных, с таким же количеством комбинаций этих данных, что вы их в голове тоже держите?
а результаты Вы где пишете?
а если тест не пройден, тоесть найдена ошибка, при регресионном тестировании, Вы будете вспомитнать весь сценарий как он проводился, на каких тестовых данных и т.д. ?
А где записать конфигурацию системы, на которой проводилось тестирование?
думаю пока достаточно, примеров убедительных, почему именно сначала нужно написать ВТ, а потом их проводить.
#17
Отправлено 18 декабря 2006 - 19:44
Нда. думаю что Канера вы явно плохо читали. Потому как именно Канер пишет о том что тесты нужно писать, а не в голове держать.
"The techniques of testing are endless literally. The correct technique is the one that best gets you the information you need to take a better next step than you would otherwise. If you are stuck on a technique rather than the results, you have descended into ritual." © The Big Book of How to Do Perfect Testing by James Bullock
и не надо читать 10-летней давности "Testing Computer Software" Канера. И уж тем более не надо следовать ей дословно.
Если уж читать Канера - то "Lessons Learned in Software Testing".
а для обозначенных Вами проблем вместо написания кучи test cases существуют более [IMO] оптимальные варианты решения проблемы. Например, для комбинаторно-тяжелых тестов в качестве test cases использовать автоматические тесты.
#18
Отправлено 19 декабря 2006 - 05:48
Ага, дискуссия становится интереснееНда. думаю что Канера вы явно плохо читали. Потому как именно Канер пишет о том что тесты нужно писать, а не в голове держать.
Про "держать в голове" -- это Вы сказали, я не говорил, что тесты нужно держать в голове, не передёргивайте
Вообще, в голове вряд ли нужно вообще что-то держать, кроме полезных мыслей, и уж точно тесты не относятся к этой категории
Что же нужно иметь на бумаге? На бумаге нужно иметь стратегию тестирования, или дизайн тестового набора, который позволит когда угодно снова и снова построить требуемый набор тестов.
Чтобы было понятнее, что я имею в виду под дизайном тестового набора, давайте в качестве аналогии рассмотрим программирование. Как пишется программа? Сначала строится архитектурный дизайн, а потом пишется код. Как вы думаете, как проще понять устройство программы -- по дизайну или по коду? Разбираться в чужом коде, да если он ещё не очень хорошо написан, да если в основе лежит не очень удачный дизайн -- одно из самых неблагодарных занятий в программировании. А если учесть, что тесты проектируются обычно гораздо хуже, чем программы, и антипаттерн "спагетти" является одним из главных бичей тестирования (в том числе и в ручных тестах), то я бы никому не пожелал разбираться в чужом наборе тестов без дизайна (впрочем, и в старых своих тестах тоже).
Что касается Канера -- давайте, чтобы не быть голословными, возьмём его свеженькую статью (август 2006) "Inefficiency and Ineffectiveness of Software Testing" -- http://www.kaner.com...op5SEissues.pdf и посмотрим главу, которая называется "Reworking Test Documentation Practices". Также давайте посмотрим тезисы совместного доклада Канера и Баха "Developing the right test documentation" -- http://www.kaner.com..._docs_pnsqc.pdf (2001 год) и чуть более раннюю статью, во многом повторяющую тезисы этого доклада "Requirements for Test Documentation" -- http://www.kaner.com...equirements.pdf (2000 год). А после этого продолжим обсуждать точку зрения товарища Канера на рассматриваемый вопрос.
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium
#19
Отправлено 19 декабря 2006 - 09:35
По моему мнению, основая идея создания ТС - это упорядочивание процесса тестирования.
Т.е. создается офицальный документ, который согласовывается с членами проектной группы. Данный документ отражает требования к тестовым работам, а также определяет объем работ и требования к персоналу и архитектуре тестового окружения.
Также этот документ является метрикой для оценки качества тестируемого функционала.
Плюс появляются дополнительные бенфиты: можно посадитть на тестирование любого чела проекта, ускорение обучение новых тестировщиков, появляется детальное описание тербования для автоматизации и т.д.
Количество пользователей, читающих эту тему: 0
0 пользователей, 0 гостей, 0 анонимных