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

Фотография

Как организовать процесс в таких условиях?


  • Авторизуйтесь для ответа в теме
Сообщений в теме: 10

#1 quiser

quiser

    Новый участник

  • Members
  • Pip
  • 8 сообщений

Отправлено 01 ноября 2006 - 09:19

Добрый день

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

Господа, поделитесь опытом, наверняка кто-то с этим сталкивался,

Как организовать процесс тестирования в таких условиях?
  • 0

#2 hudson

hudson

    Активный участник

  • Members
  • PipPip
  • 90 сообщений
  • ФИО:Быкадоров Дмитрий

Отправлено 01 ноября 2006 - 09:24

Для начала юзер-мануалоd более чем достаточно имхо - для функционального тестирования (во всяком случае для ознакомления с системой и чернового планирования). Какого рода тестирование предполагается организовать?

Кстати, документирование это один из подвидов деятельности QA - есть даже специальность технический писатель, которая (хоть и не непосредственно) относится к тестированию и QA.

Да, и еще, какими сроками/ресурсами располагаете?
  • 0

#3 quiser

quiser

    Новый участник

  • Members
  • Pip
  • 8 сообщений

Отправлено 01 ноября 2006 - 09:49

2 hudson:
Дело в том что ресурсов практически нет, пока я один, который должен организовать процесс на новом проекте, с которым все более мнее понятно, и вот на этом недобитом :), сроки пока неизвестны (но говорят что нужно было вчера)

Тестирования предпологается функционала, перфоменс и может быть юзабилити
  • 0

#4 lisiki

lisiki

    Новый участник

  • Members
  • Pip
  • 25 сообщений

Отправлено 02 ноября 2006 - 09:02

2 hudson:
Дело в том что ресурсов практически нет, пока я один, который должен организовать процесс на новом проекте, с которым все более мнее понятно, и вот на этом недобитом :), сроки пока неизвестны (но говорят что нужно было вчера)

Тестирования предпологается функционала, перфоменс и может быть юзабилити

Просмотр сообщения


Т.е. кроме вас никто этим заниматься не будет? так?
Тогда стоит задача организовать тестирование с одним тестером в качестве ресурса. Причем это тестер, возможности которого вы отлично знаете. И все становится проще. Вы же можете оценить, сколько времени вам нужно на ту или иную задачу. А задачи расписать в отдельный столбик.
Задача: оценить время на разработку тестов. Задача: изучить приложение. Задача: начерно разделить приложение на части. Задача: черновик основных тестов по каждой части приложения. Задача: протестировать приложение по черновику. Задача: описать все предыдущие шаги в плане (лучше бы с нее начать:) ) с оценкой по времени.
Это похоже на то, о чем вы спрашиваете?:)
  • 0

#5 Bishop_

Bishop_

    Новый участник

  • Members
  • Pip
  • 64 сообщений
  • ФИО:Дмитрий


Отправлено 02 ноября 2006 - 11:03

Я так понимаю, человек, спрашивает, какую лучше применить модель (методологию) в данной ситуации.
В случае с change request'ами, советую их формлять в багтрекинговую систему как один из возможных вариантов.
В случае с выбором модели я бы посоветовал, V-модель.
Приступайте к анализу ваших юзер мануалов, планированию: риски, планы тестирования, проектирование итд
  • 0
<span style='font-size:8pt;line-height:100%'>Luxoft UA</span>

#6 Clauster

Clauster

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 913 сообщений
  • ФИО:Худобородов Валерий
  • Город:Espoo

Отправлено 02 ноября 2006 - 11:35

Выявите артефакты, которые у вас есть. Два вы уже назвали - change request и user manual. Могу подсказать, напрашиваются как минимум test cases, test plan, test report, requirements. Определите их взаимосвязи. Попробуйте внедрить полученную модель. Используя практику и теорию совершенствуйте и адаптируйте процесс.
Удачи.
  • 0

#7 astik

astik

    Активный участник

  • Members
  • PipPip
  • 79 сообщений
  • Город:Deutschland

Отправлено 02 ноября 2006 - 12:20

Я так понимаю, человек, спрашивает, какую лучше применить модель (методологию) в данной ситуации.
В случае с change request'ами, советую их формлять в багтрекинговую систему как один из возможных вариантов.
В случае с выбором модели я бы посоветовал, V-модель.
Приступайте к анализу ваших юзер мануалов, планированию: риски, планы тестирования, проектирование итд

Просмотр сообщения


Poprobuju ne soglasitsja s vami. vdannom sluchae primenenie V modeli budet davol'no tak problemotichno: otsutstvie dokumnetacii, koncepta, ssystemnoi modeli,funkcional'nogo i technicheskogo opisanija, komponentnoi specifikacii. Ne pozvoljaet nam ispol'zovat' vse preimushestva metodiki "V- model". Sdes bol'she podoidet "Inkrementelle Modell RUP"

Takzhe vazhno reshit' kakoi strateggi v dannom sluchae luchshe priderzhivat'saj "Top-Down", " Bottom-up" , "Ad-hoc", "funktional"
Nu i konecho ochen' vazhno opredelit kakie vidy testov vam nado provesti. Napisat' hotja by malo mal'skii test koncept.
  • 0

#8 rlabs

rlabs

    Специалист

  • Members
  • PipPipPipPipPip
  • 660 сообщений
  • Город:Россия, Санкт-Петербург

Отправлено 02 ноября 2006 - 13:02

Кстати, документирование это один из подвидов деятельности QA - есть даже специальность технический писатель, которая (хоть и не непосредственно) относится к тестированию и QA.

Просмотр сообщения


С каких это пор пользовательская документация - вид деятельности QA?
  • 0

#9 Bishop_

Bishop_

    Новый участник

  • Members
  • Pip
  • 64 сообщений
  • ФИО:Дмитрий


Отправлено 03 ноября 2006 - 09:30

Я так понимаю, человек, спрашивает, какую лучше применить модель (методологию) в данной ситуации.
В случае с change request'ами, советую их формлять в багтрекинговую систему как один из возможных вариантов.
В случае с выбором модели я бы посоветовал, V-модель.
Приступайте к анализу ваших юзер мануалов, планированию: риски, планы тестирования, проектирование итд

Просмотр сообщения


Poprobuju ne soglasitsja s vami. vdannom sluchae primenenie V modeli budet davol'no tak problemotichno: otsutstvie dokumnetacii, koncepta, ssystemnoi modeli,funkcional'nogo i technicheskogo opisanija, komponentnoi specifikacii. Ne pozvoljaet nam ispol'zovat' vse preimushestva metodiki "V- model". Sdes bol'she podoidet "Inkrementelle Modell RUP"

Takzhe vazhno reshit' kakoi strateggi v dannom sluchae luchshe priderzhivat'saj "Top-Down", " Bottom-up" , "Ad-hoc", "funktional"
Nu i konecho ochen' vazhno opredelit kakie vidy testov vam nado provesti. Napisat' hotja by malo mal'skii test koncept.

Просмотр сообщения

Необязательно использовать V-модель в читом виде, в данной ситуации, основываясь на своем опыте, ее можно приспособить под свои нужды.
вы пишите про отсутствие документации, но она же есть! Разве User Manual - это не документация? А насчет видов тестирования, которые будут использоваться в проекте, они в Тест Плане или Тест Странежи и описываются, и все это соглано - V-Model
  • 0
<span style='font-size:8pt;line-height:100%'>Luxoft UA</span>

#10 Clauster

Clauster

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 913 сообщений
  • ФИО:Худобородов Валерий
  • Город:Espoo

Отправлено 03 ноября 2006 - 09:39

Разве User Manual - это не документация?

Просмотр сообщения

Неа.
  • 0

#11 astik

astik

    Активный участник

  • Members
  • PipPip
  • 79 сообщений
  • Город:Deutschland

Отправлено 03 ноября 2006 - 11:33

Я так понимаю, человек, спрашивает, какую лучше применить модель (методологию) в данной ситуации.
В случае с change request'ами, советую их формлять в багтрекинговую систему как один из возможных вариантов.
В случае с выбором модели я бы посоветовал, V-модель.
Приступайте к анализу ваших юзер мануалов, планированию: риски, планы тестирования, проектирование итд

Просмотр сообщения


Poprobuju ne soglasitsja s vami. vdannom sluchae primenenie V modeli budet davol'no tak problemotichno: otsutstvie dokumnetacii, koncepta, ssystemnoi modeli,funkcional'nogo i technicheskogo opisanija, komponentnoi specifikacii. Ne pozvoljaet nam ispol'zovat' vse preimushestva metodiki "V- model". Sdes bol'she podoidet "Inkrementelle Modell RUP"

Takzhe vazhno reshit' kakoi strateggi v dannom sluchae luchshe priderzhivat'saj "Top-Down", " Bottom-up" , "Ad-hoc", "funktional"
Nu i konecho ochen' vazhno opredelit kakie vidy testov vam nado provesti. Napisat' hotja by malo mal'skii test koncept.

Просмотр сообщения

Необязательно использовать V-модель в читом виде, в данной ситуации, основываясь на своем опыте, ее можно приспособить под свои нужды.
вы пишите про отсутствие документации, но она же есть! Разве User Manual - это не документация? А насчет видов тестирования, которые будут использоваться в проекте, они в Тест Плане или Тест Странежи и описываются, и все это соглано - V-Model

Просмотр сообщения

Esli vy hotite protestirovat' User Manual, to togda vam dostatochno informacii. No i to ja ne mogu sebe predstavit' kak vy smozhete vnedrit' metodologiju V-modeli. dazhe v ee usechenom varijante?
Dlja malomal'skogo testirovanija PO vy ne smozhete sostavit' dazhe testovogo scenarija ne govorju uzh o strategii, tak kak otsutstvujut elementarnyi spisok trebovanii k PO. I kak ego ne prisposablivai optimal'nym eto reshenie ne budet.
  • 0


Количество пользователей, читающих эту тему: 0

0 пользователей, 0 гостей, 0 анонимных