Увод
Добар дан, становници Хабровска. Управо сам решавао тест задатак за КА Леад конкурс за финтецх компанију. Први задатак, да направите план тестирања са комплетном контролном листом и примерима тест случајева за тестирање електричног чајника, може се решити тривијално:
Тешко је смислити бољи план тестирања са комплетном контролном листом.
Али испоставило се да је други део био питање: „Да ли постоје проблеми који су заједнички за све тестере који их спречавају да раде ефикасније?“
Прво што ми је пало на памет било је да наведем све мање-више уочљиве проблеме на које сам наишао током тестирања, избацим мале ствари и сумирам остало. Али брзо сам схватио да ће индуктивна метода одговорити на питање које се не односи на „све“, већ, у најбољем случају, само на „већину“ тестера. Стога сам одлучио да приступим са друге стране, дедуктивно, и ево шта се догодило.
Дефиниције
Прва ствар коју обично радим када решавам нови проблем је да покушам да разумем о чему се ради, а да бих то урадио морам да разумем значење речи које га постављају. Кључне речи које треба разумети су следеће:
- проблем
- тестер
- тестер посао
- ефикасност тестера
Хајде да се окренемо Википедији и здравом разуму:
(старогрчки προβλημα) у ширем смислу – сложено теоријско или практично питање које захтева проучавање и решавање; у науци – контрадикторна ситуација која се појављује у виду супротстављених позиција у објашњењу било којих појава, предмета, процеса и захтева адекватну теорију за њено решавање; у животу се проблем формулише у облику који је људима разумљив: „Знам шта, не знам како“, односно зна се шта треба да се добије, али се не зна како то учинити . Долази од касно. лат. проблем, од грч. προβλημα „бачен напред, постављен испред”; од προβαλλω „бацити напред, ставити испред себе; окривити“.
Нема много смисла, у ствари, „проблем“ = „било шта што треба да се реши“.
- специјалиста (нећемо се делити на типове, пошто смо заинтересовани за све тестере) који учествује у тестирању компоненте или система, чији је резултат:
— скуп активности у вези са тестирањем.
(лат. еффецтивус) - однос између постигнутог резултата и употребљених ресурса (: КСНУМКС).
- последица ланца (низа) радњи (резултата) или догађаја, изражених квалитативно или квантитативно. Могући исходи укључују предност, недостатак, добитак, губитак, вредност и победу.
Као и код „проблема“, ту је мало значења: нешто што се појавило као резултат рада.
- квантитативно мерљива могућност обављања било које делатности особе или људи; услови који омогућавају коришћење одређених трансформација за добијање жељеног резултата. Тестер је личност, а у складу са теоријом виталних ресурса, свака особа је власник четири економска добра:
готовина (приход) је обновљиви ресурс;
енергија (животна снага) је делимично обновљив ресурс;
време је фиксни и суштински необновљив ресурс;
знање (информације) је обновљив ресурс, део је људског капитала који може расти и бити уништен.
Желео бих да напоменем да дефиниција ефикасности у нашем случају није сасвим тачна, јер што више знања користимо, то је нижа ефикасност. Стога бих ефикасност редефинисао као „однос између постигнутих резултата и утрошених ресурса“. Онда је све тачно: знање се не губи током рада, али смањује трошкове јединог суштински необновљивог ресурса тестера - његовог времена.
одлука
Дакле, тражимо глобалне проблеме тестера који нарушавају ефикасност њиховог рада.
Најзначајнији ресурс који се троши на рад тестера је његово време (остатак се може свести на то на овај или онај начин), а да бисмо могли да говоримо о исправном прорачуну ефикасности, резултат се такође мора свести на време .
Да бисте то урадили, размотрите систем чију одрживост тестер обезбеђује својим радом. Такав систем је пројекат чији тим укључује тестер. Животни циклус пројекта може се грубо представити следећим алгоритмом:
- Рад са захтевима
- Формирање техничких спецификација
- Развој
- Тестирање
- Пуштање у производњу
- Подршка (идите на ставку 1)
У овом случају, цео пројекат се може рекурзивно поделити на подпројекте (обележја), са истим животним циклусом.
Са становишта пројекта, што је мање времена утрошено на њега, то је ефикаснија његова имплементација.
Тако долазимо до дефиниције максимално могуће ефикасности тестера са становишта пројекта – ово је стање пројекта када је време за тестирање нула. Уобичајени проблем за све тестере је немогућност да постигну ово време.
Како се носити с тим?
Закључци су прилично очигледни и многи су их користили дуго времена:
- Развој и тестирање треба да почну и заврше скоро истовремено (ово обично ради одељење ). Идеална опција је када је сва функционалност која се развија већ покривена аутотестовима до тренутка када је спремна, организована у регресијско (и, ако је могуће, пре-урезивање) тестирање користећи неку врсту .
- Што више функција има пројекат (што је сложенији), то ће више времена морати да се потроши на проверу да нова функционалност не наруши стару. Дакле, што је пројекат сложенији, потребно је више аутоматизације .
- Сваки пут када пропустимо грешку у продукцији и корисник је пронађе, морамо да потрошимо додатно време пролазећи кроз животни циклус пројекта почевши од тачке 1 (Рад са захтевима, у овом случају, корисницима). Пошто су разлози за изостанак грешке генерално непознати, остаје нам само један пут оптимизације – свака грешка коју пронађу корисници мора бити укључена у регресијско тестирање како бисмо били сигурни да се више неће појавити.
Извор: ввв.хабр.цом