обощенный алгоритм процесса тестирования
#1
Отправлено 13 апреля 2009 - 20:50
#2
Отправлено 14 апреля 2009 - 06:17
2. Узнаём каким-нибудь образом требования.
3. Смотрим на программу и на требования одновременно. Думаем.
4. Предоставляем (полезную) информацию о программе тому, кому она нужна.
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium
#3
Отправлено 14 апреля 2009 - 06:30
1. Берём в руки программу.
2. Узнаём каким-нибудь образом требования.
3. Смотрим на программу и на требования одновременно. Думаем.
4. Предоставляем (полезную) информацию о программе тому, кому она нужна.
Алексей, алгоритм неполный.
Между первым и третьим шагом нехватает ещё одного: "Получаем постановку задачи".
Это позволит понять - в каком направлении думать и делать, чтобы выдать полезную информацию тому, кто поставил задачу, а не просто "тому, кому она нужна".
InfoTeCS
#4
Отправлено 14 апреля 2009 - 06:39
Я это подразумевал во втором пункте. А Вы что имеете в виду, говоря о "требованиях", а?1. Берём в руки программу.
2. Узнаём каким-нибудь образом требования.
3. Смотрим на программу и на требования одновременно. Думаем.
4. Предоставляем (полезную) информацию о программе тому, кому она нужна.
Алексей, алгоритм неполный.
Между первым и третьим шагом нехватает ещё одного: "Получаем постановку задачи".
Это позволит понять - в каком направлении думать и делать, чтобы выдать полезную информацию тому, кто поставил задачу, а не просто "тому, кому она нужна".
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium
#5
Отправлено 14 апреля 2009 - 08:13
Алексей, я соглашусь с JimR.Я это подразумевал во втором пункте. А Вы что имеете в виду, говоря о "требованиях", а?
Алексей, алгоритм неполный.
Между первым и третьим шагом нехватает ещё одного: "Получаем постановку задачи".
Это позволит понять - в каком направлении думать и делать, чтобы выдать полезную информацию тому, кто поставил задачу, а не просто "тому, кому она нужна".
Требования это одно, а поставленная задача это другое.
Например есть простейший калькулятор, к нему есть куча требований, но будет стоять задача проверить лишь одну функцию сложения двух простых чисел в пределах [1, 100]...
Вот
Про Тестинг
#6
Отправлено 14 апреля 2009 - 08:52
Мы говорим об "обобщённом алгоритме тестирования вообще" или о "постановке задачи тестировщику на следующую неделю"? Откуда берётся постановка задачи? Что за высшие силы её ставят?Требования это одно, а поставленная задача это другое.
Например есть простейший калькулятор, к нему есть куча требований, но будет стоять задача проверить лишь одну функцию сложения двух простых чисел в пределах [1, 100]...
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium
#7
Отправлено 14 апреля 2009 - 09:43
#8
Отправлено 14 апреля 2009 - 09:46
Чую сейчас начнется холивор. Можно запросто и без требований тестировать, разве нет? По use cases или user story.
Уже начался
А use cases и user story - это что, не требования?
#9
Отправлено 14 апреля 2009 - 09:58
Поэтому я и написал -- "Узнаём каким-нибудь образом требования". По наитию -- это частный случай :)Чую сейчас начнется холивор. Можно запросто и без требований тестировать, разве нет? По use cases или user story. Или, вообще, по наитию (типа exploratory), так сказать (в самом простейшем случае).
Я где-то видел замечательное высказывание, что требования делятся на три части -- 1) зафиксированные, 2) выявленные но не зафиксированные, 3) невыявленные.
Но все три класса -- это требования, они есть, их не может не быть.
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium
#10
Отправлено 14 апреля 2009 - 10:48
Мы говорим об "обобщённом алгоритме тестирования вообще" или о "постановке задачи тестировщику на следующую неделю"? Откуда берётся постановка задачи? Что за высшие силы её ставят?
Если алгоритм обобщенный, то стоит учитывать и "постановку задачи на следующую неделю", и то, что в большой фирме могут быть несколько групп тестировщиков, сосредоточенных на разных видах тестирования... И что, например, для нового проекта, менеджер может сказать "нам надо довести продукт до ума как можно скорее".
Как-то так :)
#11
Отправлено 14 апреля 2009 - 11:03
"Как-то так" у Вас вообще никакого алгоритма не получится ;)Мы говорим об "обобщённом алгоритме тестирования вообще" или о "постановке задачи тестировщику на следующую неделю"? Откуда берётся постановка задачи? Что за высшие силы её ставят?
Если алгоритм обобщенный, то стоит учитывать и "постановку задачи на следующую неделю", и то, что в большой фирме могут быть несколько групп тестировщиков, сосредоточенных на разных видах тестирования... И что, например, для нового проекта, менеджер может сказать "нам надо довести продукт до ума как можно скорее".
Как-то так :)
Нельзя объять необъятное (с) Козьма Прутков
Моделирование только потому и имеет право на существование, что модель проще моделируемой сущности. Иначе модель просто не нужна.
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium
#12
Отправлено 14 апреля 2009 - 11:13
"Как-то так" у Вас вообще никакого алгоритма не получится ;)
Нельзя объять необъятное (с) Козьма Прутков
Моделирование только потому и имеет право на существование, что модель проще моделируемой сущности. Иначе модель просто не нужна.
Вы спросили откуда берется постановка задачи :)
Если модель слишком далека от жизни, то результаты в итоге получаются далекими от реальности. Т.о. пункт "Получаем постановку задачи" лучше оставить.
#13
Отправлено 14 апреля 2009 - 11:30
А то вы сами не знаете? Если user story с натяжкой ещё можно назвать требованиями, то use case лично у меня язык не поворачивается.Чую сейчас начнется холивор. Можно запросто и без требований тестировать, разве нет? По use cases или user story.
Уже начался
А use cases и user story - это что, не требования?
#14
Отправлено 14 апреля 2009 - 11:34
Я считаю, что "например, для нового проекта, менеджер может сказать "нам надо довести продукт до ума как можно скорее"" -- это требование. Вы считаете, что это постановка задачи. На этом и сойдёмся :)Вы спросили откуда берется постановка задачи :)
Если модель слишком далека от жизни, то результаты в итоге получаются далекими от реальности. Т.о. пункт "Получаем постановку задачи" лучше оставить.
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium
#15
Отправлено 14 апреля 2009 - 11:36
Смотря что называть словом use case. Конечно, овальчик на UML-диаграмме это не очень хороший способ сформулировать требования. А если под use case подразумевается нарративная форма, как описано у Коберна в книжке "Современные методы описания функциональных требований к системам" -- так это оно самое и есть.Если user story с натяжкой ещё можно назвать требованиями, то use case лично у меня язык не поворачивается.
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium
#16
Отправлено 14 апреля 2009 - 12:15
А то вы сами не знаете? Если user story с натяжкой ещё можно назвать требованиями, то use case лично у меня язык не поворачивается.
А use cases и user story - это что, не требования?
Юзкейсы - не требования?!
Щаз я сюда на разборки всю братву приведу с uml2.ru
:)
Хорошо написанный юзкейс может послужить основой и для требований, и для тесткейсов, и для пользовательской документации. Некоторые умудряются даже исходные коды из них генерировать.
Другое дело, конечно, что юзкейсы - это далеко не все требования. Но для тестирования, например, не сильно нагруженных веб-приложений других требований может и не понадобиться.
#18
Отправлено 14 апреля 2009 - 13:21
и так:
1. Взяли прогу, требования по функционалу, требования на качество ПО(тут может кто то распишет подробнее какие качества ПО можно выделить, например время отклика или еще что то)
2. Составить тест-требования - что же надо тестировать(то это должен делать? и полностью ли это соответствует требованиям по функционалу и качеству ПО)
3. Составление тест-плана - когда и что тестируем
4. разработка тестов
5. тестирования
6. отчет о тестировании
#19
Отправлено 14 апреля 2009 - 14:53
5. ???1. Берём в руки программу.
2. Узнаём каким-нибудь образом требования.
3. Смотрим на программу и на требования одновременно. Думаем.
4. Предоставляем (полезную) информацию о программе тому, кому она нужна.
6. Профит
Чубака — это вуки с планеты Киши, но живет Чубака на планете Эндо, а теперь вдумайтесь:
в этом же нет смысла. С какой стати Чубаке, вуки высотой два с половиной метра,
жить среди эвоков, которые чуть выше полуметра. В этом нет абсолютно никакого смысла.
#20
Отправлено 14 апреля 2009 - 16:09
1. Определяем что нужно протестировать
2. Определяем как будем тестировать, когда закончим тестировать
3. Проводим тестирование
4. Предоставляем результат заинтересованным лицам
А касаемо Use Cases, все зависит от их качества, в моей практике были просто замечательные, и использовались командой как требования :)
Количество пользователей, читающих эту тему: 0
0 пользователей, 0 гостей, 0 анонимных