Как организовать процесс в таких условиях?
#1
Отправлено 01 ноября 2006 - 09:19
Появилась такая проблемма,
в проекте нет никакой документации кроме User мануалов, писать их некому, комнада которая проектом занималась - ушла. Нет стабильной версии, но проект в потдержке, часто бывают ченьж реквесты.
Господа, поделитесь опытом, наверняка кто-то с этим сталкивался,
Как организовать процесс тестирования в таких условиях?
#2
Отправлено 01 ноября 2006 - 09:24
Кстати, документирование это один из подвидов деятельности QA - есть даже специальность технический писатель, которая (хоть и не непосредственно) относится к тестированию и QA.
Да, и еще, какими сроками/ресурсами располагаете?
#3
Отправлено 01 ноября 2006 - 09:49
Дело в том что ресурсов практически нет, пока я один, который должен организовать процесс на новом проекте, с которым все более мнее понятно, и вот на этом недобитом :), сроки пока неизвестны (но говорят что нужно было вчера)
Тестирования предпологается функционала, перфоменс и может быть юзабилити
#4
Отправлено 02 ноября 2006 - 09:02
2 hudson:
Дело в том что ресурсов практически нет, пока я один, который должен организовать процесс на новом проекте, с которым все более мнее понятно, и вот на этом недобитом :), сроки пока неизвестны (но говорят что нужно было вчера)
Тестирования предпологается функционала, перфоменс и может быть юзабилити
Т.е. кроме вас никто этим заниматься не будет? так?
Тогда стоит задача организовать тестирование с одним тестером в качестве ресурса. Причем это тестер, возможности которого вы отлично знаете. И все становится проще. Вы же можете оценить, сколько времени вам нужно на ту или иную задачу. А задачи расписать в отдельный столбик.
Задача: оценить время на разработку тестов. Задача: изучить приложение. Задача: начерно разделить приложение на части. Задача: черновик основных тестов по каждой части приложения. Задача: протестировать приложение по черновику. Задача: описать все предыдущие шаги в плане (лучше бы с нее начать:) ) с оценкой по времени.
Это похоже на то, о чем вы спрашиваете?:)
#5
Отправлено 02 ноября 2006 - 11:03
В случае с change request'ами, советую их формлять в багтрекинговую систему как один из возможных вариантов.
В случае с выбором модели я бы посоветовал, V-модель.
Приступайте к анализу ваших юзер мануалов, планированию: риски, планы тестирования, проектирование итд
#6
Отправлено 02 ноября 2006 - 11:35
Удачи.
#7
Отправлено 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.
#9
Отправлено 03 ноября 2006 - 09:30
Необязательно использовать V-модель в читом виде, в данной ситуации, основываясь на своем опыте, ее можно приспособить под свои нужды.Я так понимаю, человек, спрашивает, какую лучше применить модель (методологию) в данной ситуации.
В случае с 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.
вы пишите про отсутствие документации, но она же есть! Разве User Manual - это не документация? А насчет видов тестирования, которые будут использоваться в проекте, они в Тест Плане или Тест Странежи и описываются, и все это соглано - V-Model
#11
Отправлено 03 ноября 2006 - 11:33
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?Необязательно использовать V-модель в читом виде, в данной ситуации, основываясь на своем опыте, ее можно приспособить под свои нужды.Я так понимаю, человек, спрашивает, какую лучше применить модель (методологию) в данной ситуации.
В случае с 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.
вы пишите про отсутствие документации, но она же есть! Разве User Manual - это не документация? А насчет видов тестирования, которые будут использоваться в проекте, они в Тест Плане или Тест Странежи и описываются, и все это соглано - V-Model
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 анонимных