обощенный алгоритм процесса тестирования
#2
Отправлено 14 Апрель 2009 - 09:17
2. Узнаём каким-нибудь образом требования.
3. Смотрим на программу и на требования одновременно. Думаем.
4. Предоставляем (полезную) информацию о программе тому, кому она нужна.
Software-Testing.Ru, главный редактор
Авторские тренинги по тестированию программного обеспечения
#3
Отправлено 14 Апрель 2009 - 09:30
barancev (14.4.2009, 10:17) писал:
2. Узнаём каким-нибудь образом требования.
3. Смотрим на программу и на требования одновременно. Думаем.
4. Предоставляем (полезную) информацию о программе тому, кому она нужна.
Алексей, алгоритм неполный.
Между первым и третьим шагом нехватает ещё одного: "Получаем постановку задачи".
Это позволит понять - в каком направлении думать и делать, чтобы выдать полезную информацию тому, кто поставил задачу, а не просто "тому, кому она нужна".
InfoTeCS
#4
Отправлено 14 Апрель 2009 - 09:39
JimR (14.4.2009, 10:30) писал:
barancev (14.4.2009, 10:17) писал:
2. Узнаём каким-нибудь образом требования.
3. Смотрим на программу и на требования одновременно. Думаем.
4. Предоставляем (полезную) информацию о программе тому, кому она нужна.
Алексей, алгоритм неполный.
Между первым и третьим шагом нехватает ещё одного: "Получаем постановку задачи".
Это позволит понять - в каком направлении думать и делать, чтобы выдать полезную информацию тому, кто поставил задачу, а не просто "тому, кому она нужна".
Я это подразумевал во втором пункте. А Вы что имеете в виду, говоря о "требованиях", а?
Software-Testing.Ru, главный редактор
Авторские тренинги по тестированию программного обеспечения
#5
Отправлено 14 Апрель 2009 - 11:13
barancev (14.4.2009, 10:39) писал:
JimR (14.4.2009, 10:30) писал:
Между первым и третьим шагом нехватает ещё одного: "Получаем постановку задачи".
Это позволит понять - в каком направлении думать и делать, чтобы выдать полезную информацию тому, кто поставил задачу, а не просто "тому, кому она нужна".
Я это подразумевал во втором пункте. А Вы что имеете в виду, говоря о "требованиях", а?
Алексей, я соглашусь с JimR.
Требования это одно, а поставленная задача это другое.
Например есть простейший калькулятор, к нему есть куча требований, но будет стоять задача проверить лишь одну функцию сложения двух простых чисел в пределах [1, 100]...
Вот
Про Тестинг
#6
Отправлено 14 Апрель 2009 - 11:52
Boltick (14.4.2009, 12:13) писал:
Например есть простейший калькулятор, к нему есть куча требований, но будет стоять задача проверить лишь одну функцию сложения двух простых чисел в пределах [1, 100]...
Мы говорим об "обобщённом алгоритме тестирования вообще" или о "постановке задачи тестировщику на следующую неделю"? Откуда берётся постановка задачи? Что за высшие силы её ставят?
Software-Testing.Ru, главный редактор
Авторские тренинги по тестированию программного обеспечения
#7
Отправлено 14 Апрель 2009 - 12:43
#8
Отправлено 14 Апрель 2009 - 12:46
#9
Отправлено 14 Апрель 2009 - 12:58
Clauster (14.4.2009, 13:43) писал:
Поэтому я и написал -- "Узнаём каким-нибудь образом требования". По наитию -- это частный случай :)
Я где-то видел замечательное высказывание, что требования делятся на три части -- 1) зафиксированные, 2) выявленные но не зафиксированные, 3) невыявленные.
Но все три класса -- это требования, они есть, их не может не быть.
Software-Testing.Ru, главный редактор
Авторские тренинги по тестированию программного обеспечения
#10
Отправлено 14 Апрель 2009 - 13:48
barancev (14.4.2009, 11:52) писал:
Если алгоритм обобщенный, то стоит учитывать и "постановку задачи на следующую неделю", и то, что в большой фирме могут быть несколько групп тестировщиков, сосредоточенных на разных видах тестирования... И что, например, для нового проекта, менеджер может сказать "нам надо довести продукт до ума как можно скорее".
Как-то так :)
#11
Отправлено 14 Апрель 2009 - 14:03
Mila (14.4.2009, 14:48) писал:
barancev (14.4.2009, 11:52) писал:
Если алгоритм обобщенный, то стоит учитывать и "постановку задачи на следующую неделю", и то, что в большой фирме могут быть несколько групп тестировщиков, сосредоточенных на разных видах тестирования... И что, например, для нового проекта, менеджер может сказать "нам надо довести продукт до ума как можно скорее".
Как-то так :)
"Как-то так" у Вас вообще никакого алгоритма не получится ;)
Нельзя объять необъятное (с) Козьма Прутков
Моделирование только потому и имеет право на существование, что модель проще моделируемой сущности. Иначе модель просто не нужна.
Software-Testing.Ru, главный редактор
Авторские тренинги по тестированию программного обеспечения
#12
Отправлено 14 Апрель 2009 - 14:13
barancev (14.4.2009, 14:03) писал:
Нельзя объять необъятное (с) Козьма Прутков
Моделирование только потому и имеет право на существование, что модель проще моделируемой сущности. Иначе модель просто не нужна.
Вы спросили откуда берется постановка задачи :)
Если модель слишком далека от жизни, то результаты в итоге получаются далекими от реальности. Т.о. пункт "Получаем постановку задачи" лучше оставить.
#13
Отправлено 14 Апрель 2009 - 14:30
#14
Отправлено 14 Апрель 2009 - 14:34
Mila (14.4.2009, 15:13) писал:
Если модель слишком далека от жизни, то результаты в итоге получаются далекими от реальности. Т.о. пункт "Получаем постановку задачи" лучше оставить.
Я считаю, что "например, для нового проекта, менеджер может сказать "нам надо довести продукт до ума как можно скорее"" -- это требование. Вы считаете, что это постановка задачи. На этом и сойдёмся :)
Software-Testing.Ru, главный редактор
Авторские тренинги по тестированию программного обеспечения
#15
Отправлено 14 Апрель 2009 - 14:36
Clauster (14.4.2009, 15:30) писал:
Смотря что называть словом use case. Конечно, овальчик на UML-диаграмме это не очень хороший способ сформулировать требования. А если под use case подразумевается нарративная форма, как описано у Коберна в книжке "Современные методы описания функциональных требований к системам" -- так это оно самое и есть.
Software-Testing.Ru, главный редактор
Авторские тренинги по тестированию программного обеспечения
#16
Отправлено 14 Апрель 2009 - 15:15
Clauster (14.4.2009, 14:30) писал:
Юзкейсы - не требования?!
Щаз я сюда на разборки всю братву приведу с uml2.ru :crazy:
:)
Хорошо написанный юзкейс может послужить основой и для требований, и для тесткейсов, и для пользовательской документации. Некоторые умудряются даже исходные коды из них генерировать.
Другое дело, конечно, что юзкейсы - это далеко не все требования. Но для тестирования, например, не сильно нагруженных веб-приложений других требований может и не понадобиться.
#17
Отправлено 14 Апрель 2009 - 15:30
если бы, да кабы, да например...
а я вот ещё аллегорию употреблю: бульдозер и болид формула-1 не средства передвижения?
#18
Отправлено 14 Апрель 2009 - 16:21
и так:
1. Взяли прогу, требования по функционалу, требования на качество ПО(тут может кто то распишет подробнее какие качества ПО можно выделить, например время отклика или еще что то)
2. Составить тест-требования - что же надо тестировать(то это должен делать? и полностью ли это соответствует требованиям по функционалу и качеству ПО)
3. Составление тест-плана - когда и что тестируем
4. разработка тестов
5. тестирования
6. отчет о тестировании
#19
Отправлено 14 Апрель 2009 - 17:53
barancev (14.4.2009, 10:17) писал:
2. Узнаём каким-нибудь образом требования.
3. Смотрим на программу и на требования одновременно. Думаем.
4. Предоставляем (полезную) информацию о программе тому, кому она нужна.
5. ???
6. Профит
в этом же нет смысла. С какой стати Чубаке, вуки высотой два с половиной метра,
жить среди эвоков, которые чуть выше полуметра. В этом нет абсолютно никакого смысла.
#20
Отправлено 14 Апрель 2009 - 19:09
1. Определяем что нужно протестировать
2. Определяем как будем тестировать, когда закончим тестировать
3. Проводим тестирование
4. Предоставляем результат заинтересованным лицам
А касаемо Use Cases, все зависит от их качества, в моей практике были просто замечательные, и использовались командой как требования :)
Поделиться темой:
Similar Topics
| Название темы | Форум | Автор | Статистика | Последнее сообщение | |
|---|---|---|---|---|---|
|
Документ "Методика работы отдела тестирования"
Нужны примеры |
Управление проектами |
Darkus
|
|
|
|
Бесплатные и недорогие инструменты нефункционального тестирования
онлайн-семинар, 17 декабря, 16-00 |
Обучение тестировщиков ПО |
barancev
|
|
|
|
Анализ результатов тестирования
Анализ результатов нагрузочное тестирование с помощью TestComplete |
AutomatedQA - Perfomance Testing |
RomAl
|
|
|
|
Автоматизация тестирования 3d приложений
посоветуйте инструмент... |
Автоматизированное тестирование ПО |
smiling_fly
|
|
|
|
курсы тестирования
курсы тестирования |
Тестирование ПО | Гость_Vicky_* |
|
|

Помощь

















