Форум тестировщиков: Software-Testing.Ru: обощенный алгоритм процесса тестирования - Форум тестировщиков: Software-Testing.Ru

Перейти к содержимому

  • (2 Страниц)
  • +
  • 1
  • 2
  • Вы не можете создать новую тему
  • Вы не можете ответить в тему

обощенный алгоритм процесса тестирования

#1 Пользователь офлайн   Grunge 

  • Новый участник
  • Pip
  • Группа: Members
  • Сообщений: 7
  • Регистрация: 29 Март 2009

Отправлено 13 Апрель 2009 - 23:50

Кто-нибудь может привести мне пример сабжа?

#2 Пользователь офлайн   barancev 

  • Администратор
  • PipPipPipPipPipPip
  • Группа: Admin
  • Сообщений: 2 718
  • Регистрация: 12 Май 2004
  • Пол:Мужчина
  • Город:Россия, Москва
  • Skype:barancev

Отправлено 14 Апрель 2009 - 09:17

1. Берём в руки программу.
2. Узнаём каким-нибудь образом требования.
3. Смотрим на программу и на требования одновременно. Думаем.
4. Предоставляем (полезную) информацию о программе тому, кому она нужна.

#3 Пользователь офлайн   JimR 

  • Опытный участник
  • PipPipPipPip
  • Группа: Members
  • Сообщений: 252
  • Регистрация: 26 Ноябрь 2003
  • Пол:Мужчина
  • Город:Москва
  • Интересы:RPG, фантастика, музыка(довольно разных стилей)
  • Skype:JimR__

Отправлено 14 Апрель 2009 - 09:30

Просмотр сообщенияbarancev (14.4.2009, 10:17) писал:

1. Берём в руки программу.
2. Узнаём каким-нибудь образом требования.
3. Смотрим на программу и на требования одновременно. Думаем.
4. Предоставляем (полезную) информацию о программе тому, кому она нужна.


Алексей, алгоритм неполный.
Между первым и третьим шагом нехватает ещё одного: "Получаем постановку задачи".
Это позволит понять - в каком направлении думать и делать, чтобы выдать полезную информацию тому, кто поставил задачу, а не просто "тому, кому она нужна".
Дмитрий Ручко
InfoTeCS

#4 Пользователь офлайн   barancev 

  • Администратор
  • PipPipPipPipPipPip
  • Группа: Admin
  • Сообщений: 2 718
  • Регистрация: 12 Май 2004
  • Пол:Мужчина
  • Город:Россия, Москва
  • Skype:barancev

Отправлено 14 Апрель 2009 - 09:39

Просмотр сообщенияJimR (14.4.2009, 10:30) писал:

Просмотр сообщенияbarancev (14.4.2009, 10:17) писал:

1. Берём в руки программу.
2. Узнаём каким-нибудь образом требования.
3. Смотрим на программу и на требования одновременно. Думаем.
4. Предоставляем (полезную) информацию о программе тому, кому она нужна.


Алексей, алгоритм неполный.
Между первым и третьим шагом нехватает ещё одного: "Получаем постановку задачи".
Это позволит понять - в каком направлении думать и делать, чтобы выдать полезную информацию тому, кто поставил задачу, а не просто "тому, кому она нужна".

Я это подразумевал во втором пункте. А Вы что имеете в виду, говоря о "требованиях", а?

#5 Пользователь офлайн   Boltick 

  • Специалист
  • PipPipPipPipPip
  • Группа: Members
  • Сообщений: 529
  • Регистрация: 19 Июль 2005
  • Пол:Мужчина
  • Город:Нидерланды
  • Интересы:командные виды спорта: футбол, баскетбол, counter-strike :)
  • Skype:aliaksei.bulat

Отправлено 14 Апрель 2009 - 11:13

Просмотр сообщенияbarancev (14.4.2009, 10:39) писал:

Просмотр сообщенияJimR (14.4.2009, 10:30) писал:

Алексей, алгоритм неполный.
Между первым и третьим шагом нехватает ещё одного: "Получаем постановку задачи".
Это позволит понять - в каком направлении думать и делать, чтобы выдать полезную информацию тому, кто поставил задачу, а не просто "тому, кому она нужна".

Я это подразумевал во втором пункте. А Вы что имеете в виду, говоря о "требованиях", а?

Алексей, я соглашусь с JimR.
Требования это одно, а поставленная задача это другое.
Например есть простейший калькулятор, к нему есть куча требований, но будет стоять задача проверить лишь одну функцию сложения двух простых чисел в пределах [1, 100]...

Вот
Алексей Булат
Про Тестинг

#6 Пользователь офлайн   barancev 

  • Администратор
  • PipPipPipPipPipPip
  • Группа: Admin
  • Сообщений: 2 718
  • Регистрация: 12 Май 2004
  • Пол:Мужчина
  • Город:Россия, Москва
  • Skype:barancev

Отправлено 14 Апрель 2009 - 11:52

Просмотр сообщенияBoltick (14.4.2009, 12:13) писал:

Требования это одно, а поставленная задача это другое.
Например есть простейший калькулятор, к нему есть куча требований, но будет стоять задача проверить лишь одну функцию сложения двух простых чисел в пределах [1, 100]...

Мы говорим об "обобщённом алгоритме тестирования вообще" или о "постановке задачи тестировщику на следующую неделю"? Откуда берётся постановка задачи? Что за высшие силы её ставят?

#7 Пользователь офлайн   Clauster 

  • Гуру
  • PipPipPipPipPipPip
  • Группа: Members
  • Сообщений: 1 669
  • Регистрация: 15 Март 2005
  • Пол:Мужчина
  • Город:С-Пб
  • Интересы:горный велосипед, сноуборд, кайтинг, байдарки, футбол, фотография, музыка, литература и т.д.

Отправлено 14 Апрель 2009 - 12:43

Чую сейчас начнется холивор. Можно запросто и без требований тестировать, разве нет? По use cases или user story. Или, вообще, по наитию (типа exploratory), так сказать (в самом простейшем случае). Что хочется сказать - обобщенного алгоритма нет. Есть много подходов к тестированию и каждый из них хорош в определенных условиях.

#8 Пользователь офлайн   greesha 

  • Опытный участник
  • PipPipPipPip
  • Группа: Members
  • Сообщений: 346
  • Регистрация: 24 Июнь 2007
  • Пол:Мужчина
  • Город:Мытищи
  • Skype:gpechyonkin

Отправлено 14 Апрель 2009 - 12:46

Просмотр сообщенияClauster (14.4.2009, 12:43) писал:

Чую сейчас начнется холивор. Можно запросто и без требований тестировать, разве нет? По use cases или user story.


Уже начался :crazy:

А use cases и user story - это что, не требования?
Григорий Печёнкин
greesha.ru
жежешечка

#9 Пользователь офлайн   barancev 

  • Администратор
  • PipPipPipPipPipPip
  • Группа: Admin
  • Сообщений: 2 718
  • Регистрация: 12 Май 2004
  • Пол:Мужчина
  • Город:Россия, Москва
  • Skype:barancev

Отправлено 14 Апрель 2009 - 12:58

Просмотр сообщенияClauster (14.4.2009, 13:43) писал:

Чую сейчас начнется холивор. Можно запросто и без требований тестировать, разве нет? По use cases или user story. Или, вообще, по наитию (типа exploratory), так сказать (в самом простейшем случае).

Поэтому я и написал -- "Узнаём каким-нибудь образом требования". По наитию -- это частный случай :)

Я где-то видел замечательное высказывание, что требования делятся на три части -- 1) зафиксированные, 2) выявленные но не зафиксированные, 3) невыявленные.
Но все три класса -- это требования, они есть, их не может не быть.

#10 Пользователь офлайн   Mila 

  • Постоянный участник
  • PipPipPip
  • Группа: Members
  • Сообщений: 192
  • Регистрация: 16 Декабрь 2003
  • Город:Санкт-Петербург

Отправлено 14 Апрель 2009 - 13:48

Просмотр сообщенияbarancev (14.4.2009, 11:52) писал:

Мы говорим об "обобщённом алгоритме тестирования вообще" или о "постановке задачи тестировщику на следующую неделю"? Откуда берётся постановка задачи? Что за высшие силы её ставят?


Если алгоритм обобщенный, то стоит учитывать и "постановку задачи на следующую неделю", и то, что в большой фирме могут быть несколько групп тестировщиков, сосредоточенных на разных видах тестирования... И что, например, для нового проекта, менеджер может сказать "нам надо довести продукт до ума как можно скорее".
Как-то так :)

#11 Пользователь офлайн   barancev 

  • Администратор
  • PipPipPipPipPipPip
  • Группа: Admin
  • Сообщений: 2 718
  • Регистрация: 12 Май 2004
  • Пол:Мужчина
  • Город:Россия, Москва
  • Skype:barancev

Отправлено 14 Апрель 2009 - 14:03

Просмотр сообщенияMila (14.4.2009, 14:48) писал:

Просмотр сообщенияbarancev (14.4.2009, 11:52) писал:

Мы говорим об "обобщённом алгоритме тестирования вообще" или о "постановке задачи тестировщику на следующую неделю"? Откуда берётся постановка задачи? Что за высшие силы её ставят?


Если алгоритм обобщенный, то стоит учитывать и "постановку задачи на следующую неделю", и то, что в большой фирме могут быть несколько групп тестировщиков, сосредоточенных на разных видах тестирования... И что, например, для нового проекта, менеджер может сказать "нам надо довести продукт до ума как можно скорее".
Как-то так :)

"Как-то так" у Вас вообще никакого алгоритма не получится ;)
Нельзя объять необъятное (с) Козьма Прутков

Моделирование только потому и имеет право на существование, что модель проще моделируемой сущности. Иначе модель просто не нужна.

#12 Пользователь офлайн   Mila 

  • Постоянный участник
  • PipPipPip
  • Группа: Members
  • Сообщений: 192
  • Регистрация: 16 Декабрь 2003
  • Город:Санкт-Петербург

Отправлено 14 Апрель 2009 - 14:13

Просмотр сообщенияbarancev (14.4.2009, 14:03) писал:

"Как-то так" у Вас вообще никакого алгоритма не получится ;)
Нельзя объять необъятное (с) Козьма Прутков

Моделирование только потому и имеет право на существование, что модель проще моделируемой сущности. Иначе модель просто не нужна.


Вы спросили откуда берется постановка задачи :)

Если модель слишком далека от жизни, то результаты в итоге получаются далекими от реальности. Т.о. пункт "Получаем постановку задачи" лучше оставить.

#13 Пользователь офлайн   Clauster 

  • Гуру
  • PipPipPipPipPipPip
  • Группа: Members
  • Сообщений: 1 669
  • Регистрация: 15 Март 2005
  • Пол:Мужчина
  • Город:С-Пб
  • Интересы:горный велосипед, сноуборд, кайтинг, байдарки, футбол, фотография, музыка, литература и т.д.

Отправлено 14 Апрель 2009 - 14:30

Просмотр сообщенияgreesha (14.4.2009, 12:46) писал:

Просмотр сообщенияClauster (14.4.2009, 12:43) писал:

Чую сейчас начнется холивор. Можно запросто и без требований тестировать, разве нет? По use cases или user story.


Уже начался :crazy:

А use cases и user story - это что, не требования?

А то вы сами не знаете? Если user story с натяжкой ещё можно назвать требованиями, то use case лично у меня язык не поворачивается.

#14 Пользователь офлайн   barancev 

  • Администратор
  • PipPipPipPipPipPip
  • Группа: Admin
  • Сообщений: 2 718
  • Регистрация: 12 Май 2004
  • Пол:Мужчина
  • Город:Россия, Москва
  • Skype:barancev

Отправлено 14 Апрель 2009 - 14:34

Просмотр сообщенияMila (14.4.2009, 15:13) писал:

Вы спросили откуда берется постановка задачи :)

Если модель слишком далека от жизни, то результаты в итоге получаются далекими от реальности. Т.о. пункт "Получаем постановку задачи" лучше оставить.

Я считаю, что "например, для нового проекта, менеджер может сказать "нам надо довести продукт до ума как можно скорее"" -- это требование. Вы считаете, что это постановка задачи. На этом и сойдёмся :)

#15 Пользователь офлайн   barancev 

  • Администратор
  • PipPipPipPipPipPip
  • Группа: Admin
  • Сообщений: 2 718
  • Регистрация: 12 Май 2004
  • Пол:Мужчина
  • Город:Россия, Москва
  • Skype:barancev

Отправлено 14 Апрель 2009 - 14:36

Просмотр сообщенияClauster (14.4.2009, 15:30) писал:

Если user story с натяжкой ещё можно назвать требованиями, то use case лично у меня язык не поворачивается.

Смотря что называть словом use case. Конечно, овальчик на UML-диаграмме это не очень хороший способ сформулировать требования. А если под use case подразумевается нарративная форма, как описано у Коберна в книжке "Современные методы описания функциональных требований к системам" -- так это оно самое и есть.

#16 Пользователь офлайн   greesha 

  • Опытный участник
  • PipPipPipPip
  • Группа: Members
  • Сообщений: 346
  • Регистрация: 24 Июнь 2007
  • Пол:Мужчина
  • Город:Мытищи
  • Skype:gpechyonkin

Отправлено 14 Апрель 2009 - 15:15

Просмотр сообщенияClauster (14.4.2009, 14:30) писал:

Просмотр сообщенияgreesha (14.4.2009, 12:46) писал:

А use cases и user story - это что, не требования?

А то вы сами не знаете? Если user story с натяжкой ещё можно назвать требованиями, то use case лично у меня язык не поворачивается.


Юзкейсы - не требования?!
Щаз я сюда на разборки всю братву приведу с uml2.ru :crazy:

:)

Хорошо написанный юзкейс может послужить основой и для требований, и для тесткейсов, и для пользовательской документации. Некоторые умудряются даже исходные коды из них генерировать.

Другое дело, конечно, что юзкейсы - это далеко не все требования. Но для тестирования, например, не сильно нагруженных веб-приложений других требований может и не понадобиться.
Григорий Печёнкин
greesha.ru
жежешечка

#17 Пользователь офлайн   Clauster 

  • Гуру
  • PipPipPipPipPipPip
  • Группа: Members
  • Сообщений: 1 669
  • Регистрация: 15 Март 2005
  • Пол:Мужчина
  • Город:С-Пб
  • Интересы:горный велосипед, сноуборд, кайтинг, байдарки, футбол, фотография, музыка, литература и т.д.

Отправлено 14 Апрель 2009 - 15:30

:crazy:
если бы, да кабы, да например...
а я вот ещё аллегорию употреблю: бульдозер и болид формула-1 не средства передвижения?

#18 Пользователь офлайн   Grunge 

  • Новый участник
  • Pip
  • Группа: Members
  • Сообщений: 7
  • Регистрация: 29 Март 2009

Отправлено 14 Апрель 2009 - 16:21

Приведу то что я представляю под этим обобщенным алгоритмом, кто как его подкрутить поправит может - думаю тут вообще очень много чего править надо)
и так:
1. Взяли прогу, требования по функционалу, требования на качество ПО(тут может кто то распишет подробнее какие качества ПО можно выделить, например время отклика или еще что то)
2. Составить тест-требования - что же надо тестировать(то это должен делать? и полностью ли это соответствует требованиям по функционалу и качеству ПО)
3. Составление тест-плана - когда и что тестируем
4. разработка тестов
5. тестирования
6. отчет о тестировании

#19 Пользователь офлайн   Alfa 

  • Специалист
  • PipPipPipPipPip
  • Группа: Members
  • Сообщений: 552
  • Регистрация: 30 Январь 2007
  • Пол:Мужчина
  • Город:Moscow

Отправлено 14 Апрель 2009 - 17:53

Просмотр сообщенияbarancev (14.4.2009, 10:17) писал:

1. Берём в руки программу.
2. Узнаём каким-нибудь образом требования.
3. Смотрим на программу и на требования одновременно. Думаем.
4. Предоставляем (полезную) информацию о программе тому, кому она нужна.

5. ???
6. Профит
Чубака — это вуки с планеты Киши, но живет Чубака на планете Эндо, а теперь вдумайтесь:
в этом же нет смысла. С какой стати Чубаке, вуки высотой два с половиной метра,
жить среди эвоков, которые чуть выше полуметра. В этом нет абсолютно никакого смысла.



#20 Пользователь офлайн   Galina 

  • Постоянный участник
  • PipPipPip
  • Группа: Members
  • Сообщений: 151
  • Регистрация: 04 Май 2007
  • Пол:Женщина
  • Город:Москва
  • Skype:galina.galkina

Отправлено 14 Апрель 2009 - 19:09

Приведу свой вариант общего алгоритма:

1. Определяем что нужно протестировать
2. Определяем как будем тестировать, когда закончим тестировать
3. Проводим тестирование
4. Предоставляем результат заинтересованным лицам


А касаемо Use Cases, все зависит от их качества, в моей практике были просто замечательные, и использовались командой как требования :)

Поделиться темой:


  • (2 Страниц)
  • +
  • 1
  • 2
  • Вы не можете создать новую тему
  • Вы не можете ответить в тему


Similar Topics Collapse

  Название темы Форум Автор Статистика Последнее сообщение
Горячая тема (есть новые ответы) Документ "Методика работы отдела тестирования"
Нужны примеры
Управление проектами Darkus 
  • 20 Ответов
  • 4 011 Просмотров
Открытая тема (есть новые ответы) Бесплатные и недорогие инструменты нефункционального тестирования
онлайн-семинар, 17 декабря, 16-00
Обучение тестировщиков ПО barancev 
  • 1 Ответ
  • 503 Просмотров
Открытая тема (есть новые ответы) Анализ результатов тестирования
Анализ результатов нагрузочное тестирование с помощью TestComplete
AutomatedQA - Perfomance Testing RomAl 
  • 2 Ответов
  • 1 203 Просмотров
Открытая тема (есть новые ответы) Автоматизация тестирования 3d приложений
посоветуйте инструмент...
Автоматизированное тестирование ПО smiling_fly 
  • 1 Ответ
  • 1 355 Просмотров
*Открытая тема (есть новые ответы) курсы тестирования
курсы тестирования
Тестирование ПО Гость_Vicky_* 
  • 5 Ответов
  • 2 092 Просмотров

2 человек читают эту тему
0 пользователей, 2 гостей, 0 скрытых пользователей