Проблеми со автоматизација на тестот и модерен квалитет

Кои се вообичаените проблеми со автоматската тест во агилната и DevOps?

Современиот развој на софтвер и ОК се фокусираат премногу на автоматизација на тестот, а недоволно на истражувачко тестирање.

Дали ослободуваме софтвер со подобар квалитет со повеќе автоматизирани тестови? Мислам дека не!


Неодамна наидов на објава на мрежата на социјалните медиуми во која се вели

Она што го гледам во повеќето настани за тестирање и ОК денес се претежно DevOps, континуирана интеграција и автоматска тест.


Иако сето тоа е многу убаво, јас гледам дека се автоматизираат многу лажни тест случаи.

Гледам неколку грешки пријавени за време на тестовите за интеграција и функционалните тестови, иако сите тие се автоматизирани.

Во UAT, корисниците наоѓаат сè повеќе грешки затоа што тест-тимовите не успеваат да ги идентификуваат во претходните фази.

Ако не ги научиме луѓето како да пишуваат добри тест случаи, ќе завршиме со целосно автоматизирани


И, моето толкување на… е „глупости“. :-)

Како и да е, да видиме што навистина е што се случува во светот на модерната квалификација и автоматската тест.



Проблеми со современиот квалитет

Поголемиот дел од „Тест-автоматизацијата“ во рамките на агилниот развој е во тешка состојба. Индустријата за софтвер фрла огромни суми пари за да ангажира „Експерти за тест автоматизација“, најмногу за да стекне чувство на доверба дека софтверот што го градат е со висок квалитет. Сепак, забележливи грешки и / или други проблеми се наоѓаат за време на UAT или се лизгаат низ производствените средини. Па, што се случува?

Забелешка:Со тест автоматизација, јас најмногу се осврнувам Кромид Тест автоматизација.

Автоматското тестирање сега е во срцето на секој современ процес на развој на софтвер. Неговата цел е да помош испорача висококвалитетен софтвер на повторлива основа, но дали е навистина?


Дали тестерите сепак тестираат?

Вистината на работата е дека во повеќето агилни тимови, тестерите повеќе не тестираат.

Рачното тестирање ја изгуби својата доблест, благодарение на развојните практики и култури како што се агилното и DevOps , кои создадоа поделба во просторот за ОК - оние кои можат да кодираат и оние кои не можат.

Честопати би чуле работи како: „Јас сум 100% инженер за автоматизација“ или „80% автоматизација 20% рачно“ или уште полошо, „Мразам рачно тестирање“. Шокантно!

Во DevOps, наведени сме да веруваме дека сè треба да се автоматизира. Нема место за рачна интервенција, на пр. рачно тестирање.


Денес, повеќето тестери во агилен тим се борат да останат во чекор со побарувачката за „Тест автоматизација“. Постои притисок да се автоматизира секоја приказна во спринтот и нема доволно време за темелно истражувачко тестирање.

Проблемот, особено во агилниот развој, е што ОК земаат приказна за корисникот и ги автоматизираат нејзините критериуми за прифаќање. Додека го прават тоа, нивниот главен и единствен фокус е да се борат со своите ограничени вештини за кодирање само за да го положат тестот.

Нормално, ова создава тесен фокус кога сте заинтересирани само да го автоматизирате тестот и да го видите како поминува во цевководот за изградба. Ова само докажува што функционира во критериумите за прифаќање - правилно или погрешно - и имате тенденција да заборавите на големата слика.

Падот на рачното тестирање

Се повеќе и повеќе „традиционални тестери“ преминуваат на „агилно тестирање“ со полагање неколку часови за кодирање и стануваат се повеќе технички.


Не ме сфаќај погрешно; сето тоа е добро. Верувам како тестери, секогаш треба да се стремиме да научиме нови и нови технологии за да останеме снаодливи. Треба да го разбереме технолошкиот оџак ако сакаме да тестираме систем до висок степен на квалитет.

Сепак, вистинската причина зошто повеќето рачни тестери ги преземаат овие иницијативи е дека постои општо верување дека „автоматското тестирање“ е супериорно во однос на рачното тестирање и еј, кодирањето е забавно, нели?

Забелешка:Со рачно тестирање, јас сум НЕ се однесува на старошколскиот начин на следење на скрипта и извршување на чекорите. Јас се осврнувам на таканаречените „истражувачки тестери“ - оние кои го прават вистинското тестирање и се curубопитни да го испитаат однесувањето на системот вежбајќи интересни и внимателни сценарија.

За жал, се чини дека има голем пад на пазарот за истражувачки тестери. Ова е сосема евидентно. Само извршете неколку прашања за пребарување за „рачен тестер“ и „тестер за автоматизација“ на која било страница за ИТ-работни места и сами погледнете го резултатот.



Проблеми со автоматизација на тестот

Сега, да видиме зошто поголемиот дел од напорот за автоматизација на тестот не дава никаква вредност.

Чести грешки што гледам дека се случуваат постојано:

  • Имајќи погрешно очекување на автоматски тестови
  • Автоматизирање на тестови во погрешен слој, во погрешно време и користење погрешни алатки
  • Автоматизирање на бескорисни тестови
  • Занемарување на важни области
  • Недостасуваат клучни сценарија

Погрешни очекувања

Пред некое време, напишав блог пост на зошто сакате да автоматизирате тест ? Ако не сте го прочитале, вреди да се прочита.

Резимето на тој напис е дека автоматизирате тестови што сакате да ги извршувате редовно. По дефиниција, ова се вашите регресивни тестови кои потврдуваат дека системот сè уште функционира.

Меѓутоа, ако автоматските проверки најдат многу проблеми со регресија, би ги довел во прашање вештините на развивачите и процесот на развој. Автоматските тестови за интерфејс не треба да се [одржуваат на сметка на] или [компензирани] за лошо кодирање.

Погрешен слој, погрешен алат и погрешно време

Мнозинство од „Инженери за тест автоматизација“ во агилни тимови, разгледајте приказна за корисникот и автоматизирајте ги критериумите за прифаќање. Поголемиот дел од времето ова се прави со комбинација на селен и краставица.

Модерните веб-апликации сега се јасно поделени помеѓу backend и frontend. Заднината е претежно составена од голем број РЕСТ веб-услуги или API со лесно достапни крајни точки.

Логиката на апликацијата може да се тестира во слојот API. Сепак, повеќето инженери за тестирање за автоматизација прибегнуваат кон валидирање на функционалноста на UI слојот, што е во најдобар случај тежок.

Постојат алатки за тестирање таму, како што се Карате и Уверен, што го поедноставува тестирањето на API. Треба да ги користиме овие алатки за време на развојот. За жал, некои инженери за тест автоматизација дури и не знаат основи на HTTP , а камоли да можам да пишувам сценарија за тестирање на API.

Што се однесува до автоматизацијата на тестовите за интерфејс, Кипарис е одлична алатка. Тоа е повеќе како алатка TDD за програмерите од предната страна. Програмерите добиваат многу брз фидбек за однесувањето на новите компоненти за интерфејс.

И каратето и чемпресот служат како „алатки за тест за развој“, т.е. алатки што го водат и поддржуваат развојот. И двете се лесни, лесни за интеграција и можат да ги обезбедат доверба во развојот .

Потоа можеме да користиме Селен или Кипарис за да дизајнираме само неколку сценарија што го вежбаат системот од крај до крај. Овие сценарија го формираат нашиот пакет за регресија со мала тежина и обезбедуваат доверба во деловниот континуитет .

Мошне често слушам работи како: „чекаме додека функцијата не се развие целосно и стабилна, пред автоматските тестови“. Секој свесен тестер знае дека грешките во новата опција се побројни од грешките во регресијата. Постои поголема шанса да најдете проблеми со тековната карактеристика во развој, отколку стабилна.

Ако потрошите време за автоматизирање на тестовите, направете ги паралелно со развојот, кога тие можат да обезбедат поголема вредност.

Автоматизирање на бескорисни тестови

Не го автоматизирајте секој „тест“ само заради тоа. Ставете некој процес на размислување во игра. Проучете ги архитектонските дијаграми на високо и ниско ниво. Прашајте што може да тргне наопаку. Испитајте ги точките на интеграција и побарајте потенцијални точки на неуспех.

Преземете пристап базиран на ризик во автоматизацијата, како што (се надевам) би направиле со вашиот целокупен пристап за тестирање. Која е веројатноста нешто да не успее, и какво е влијанието на неуспехот? Ако одговорот е висок, тогаш тие сценарија треба да се автоматизираат и извршуваат на секое градење.

Во секој спринт, ние често завршуваме со пишување автоматски тестови околу кориснички приказни за тој спринт и забораваме на интеграцијата со другите одлики. Постојат или слаби или никакви тестови за интеграција.

Запомнете дека автоматизирањето на „тестовите“ трае време. Имајте на ум и дека со автоматизирање на тест, вие не тестирате, само проверувате дали предметната карактеристика исполнува некои критериуми за прифаќање.

Ти не може автоматизирајте тестирање, но можете да ја автоматизирате проверката на познати факти.

Затоа, секогаш кога поминувате во автоматизирање на „тест“, размислете за времето што го трошите не тестирајќи!

Занемарување на важни области

Гледам се повеќе и повеќе од оваа небрежност од раѓањето на културата DevOps.

Во DevOps, цевководот за испорака, заедно со скриптите за распоредување, се 'рбетот на развојот и испораката на софтверот, но тие тешко дека некогаш се тестираат.

Во изминатите неколку години, лесно можев да кажам дека сум видел многу повеќе „еколошки проблеми“ отколку функционални грешки. Проблеми со животната средина, како што се проблеми со CI-серверот, скрипти за распоредување, тест-околини итн.

Проблемите со животната средина имаат сериозно влијание врз развојот и напорот за тестирање. Тие трошат многу време на програмери и DevOps и масовно го забавуваат процесот на распоредување, но нема предвид за тестирање и со тоа спречување на овие проблеми.

Ние само ги прифаќаме како дел од современата испорака на софтвер.

Ние трошиме многу напор за автоматизирање на функционалното однесување и целосно ги игнорираме „нештата“ кои се најважни. Уште полошо е да се потпреме на тестовите на Селен за да се покаже дали распоредувањата работат или не!

Недостасуваат клучните сценарија

Сценаријата се крал! На крајот на краиштата, сценаријата се тие што откриваат грешки.

Мошне често, сериозно прашање протекува во производство, бидејќи никој не размислуваше за тоа конкретно сценарио. Бројот на извршени автоматски тестови не е важен. Ако некое сценарио не било смислено или тестирано, законот на sod ни кажува дека има грешка таму.

За жал, во повеќето агилни средини за развој, не се посветува доволно посветеност на целата оваа важна активност на „Сценарио работилница“.



Проблеми со процесот

Ајде да видиме како горенаведените проблеми се манифестираат во типично сценарио за развој:

  • Сопственикот на производот пишува кориснички приказни без или со минимални критериуми за прифаќање.
  • Нема доволно време посветено на сесиите за пречистување на приказната за да разговараме за различни сценарија за приказна за корисник.
  • Критериумите за прифаќање се толкуваат како тестови за прифаќање - Да, постои разлика помеѓу двете !
  • Тестерите само ги автоматизираат критериумите за прифаќање во приказните за корисниците, претежно користејќи селен и / или краставица.
  • Автоматското тестирање е скоро секогаш одговорност на „тестерите за автоматизација“.
  • Програмерите немаат идеја што е опфатено во тест пакетите или дури не знаат како да ги извршат автоматските тестови.
  • Автоматските тестови се додаваат на постојано проширувањето на „регресивниот пакет“, затоа трае и подолго и секој пат.
  • Автоматизираните функционални тестови на UI се интегрирани во градежниот гасовод, што е добро, но

Инвеститорот турка едноставна промена и треба да почека 30 минути за автоматските тестови да зеленат пред новата функција или поправка на грешки да бидат распоредени во производството. 30 минути чекање е само ако тестовите го поминат првиот пат. Ако не успеат поради некои тестови или проблеми со животната средина, тоа може да трае подолго.

Бидејќи автоматските тестови се извршуваат и ОК испитува случајни дефекти, развивачот и / или сопственикот на производот ја потврдија новата имплементација и се задоволни што ги објавуваат, но не можат затоа што градењето не е зелено.

По некое време, или изградбата станува зелена или управата се фрустрира со неуспешните тестови и во секој случај донесува одлука за ослободување. Потоа, BOOM, по неколку минути во производството, има скок на 500 грешки на серверот.

Инфраструктурни неуспеси

Неуспесите се чини дека покажуваат слична шема

  • Неуспех во точките за интеграција.
  • Неуспех во комуникација со апликации од трети страни.
  • Неуспешни се веб-услугите и барањата до крајните точки на API.
  • Погрешна конфигурација на еден од ВМ или јазлите, што резултира со повремени проблеми.

А сепак, не постои процес за проверка на овие проблеми како дел од процесот на развој или испорака.

Фокусот на инженерите за тест автоматизација е да ги автоматизираат функционалните тестови. Нема фокус на перформанси, безбедност или еластичност. И, секако нема тестирање на инфраструктурата!



Резиме

Дојде време да го смениме нашиот фокус од автоматизирање на функционални тестови кои имаат малку шанси да ги фатат функционалните проблеми на посериозните и најчести еколошки проблеми што го мачат развојот.

Тест автоматизација, ако е направено погрешно или без процес на размислување , е губење време и не дава никаква вредност на никого. Лажните автоматски тестови можат да направат огромни трошоци за одржување и да го попречат развојот. На крајот, единственото решение е да ги поставите тестовите.

Во современиот развој на софтвер, најголемиот дел од напорите на „Инженерите за тест-автоматизација“ се трошат во борба со кодот за автоматизација и да ги активираат „тестовите“ наместо да се фокусираат на правилно тестирање и истражување на системот.

Буквално нема доволно време да се напише код за автоматизација и изврши истражувачко тестирање. Ние автоматизираме приказна по приказна и забораваме на тестовите за интеграција, забораваме на големата слика.

Честопати завршуваме со тони автоматизирани тестови, сепак истражувачкото тестирање открива мнозинство грешки. Потоа, ретроспективно, пишуваме автоматски тест за грешките што беа пронајдени со истражувачко тестирање, за да се фатат грешки во регресија.

Треба да бидеме селективни за тоа што да автоматизираме и да судиме за нашата одлука заснована врз ризик. Што може да тргне наопаку, каква е веројатноста тоа да тргне наопаку и какво ќе биде влијанието врз корисникот или бизнисот доколку се одвива наопаку?

Ако работите со „Тест автоматизација“, тогаш не користете Селен за да ја тестирате функционалноста на API или компонентите на UI. Наместо тоа, користете Селен за да автоматизирате само неколку корисни и критички деловни сценарија за да обезбедите доверба во континуитетот на бизнисот пред секое издание.

И за крај, секој пат кога ќе потрошите автоматизирање на „тест“, размислете за времето што го трошите не тестирајќи!

Понатамошно читање: