toets ontwikkelaar teen QA span toets - Wat is die regte afdeling van die werk? [Gesluit]

Question

Terwyl jy probeer om meer ontwikkelaar toets advokaat, vind ek die argument "Is dit nie werk QA se?" gebruik 'n baie. In my gedagtes, beteken dit nie sin maak om die QA span gee al die toets van verantwoordelikhede, maar terselfdertyd Spolsky en ander sê jy moet nie gebruik word om die $ 100 / hr ontwikkelaars om iets te doen 'n $ 30 / hr tester kan doen . Wat is die ervarings van ander in 'n maatskappy met 'n toegewyde QA span? Waar moet die verdeling van werk gemaak word?

Verduideliking: Ek bedoel QA as 'n bevestiging en verifikasie span. Devs moet nie doen die validering (kliënt-gefokus toets), maar waar is die verifikasie (funksionele toetsing) afdeling punt?

Answer 1

Dit is die verskil tussen "black box" toets (waar jy weet wat die kode is veronderstel om te doen, maar nie hoe dit werk), en "wit boks" toets (waar om te weet hoe dit werk dryf hoe jy dit toets). "Black box" toets is wat die meeste mense dink wanneer jy noem Gehalteversekering.

Ek werk vir 'n maatskappy waar die QA span is ook sagteware-ontwikkelaars. (Dit vernou die veld 'n baie as jy omgee om die maatskappy te raai.) Ek weet Joel se mening, en my ervaring lei my na gedeeltelik saamstem: om dieselfde rede dat 'n "wit hoed" hacker is meer effektiewe bevinding sekuriteit gate, is sekere vorme van foute meer doeltreffend gevind deur wit boks testers wat weet hoe om die kode te skryf (en dus wat die algemene foute is - byvoorbeeld, hulpbronbestuur kwessies soos geheue lekkasies).

Ook, omdat-QA georiënteerde ontwikkelaars is deel van die proses van die aanvanklike ontwerpfase, hulle kan teoreties help om 'n hoër gehalte-kode ry deur die hele proses. Die ideaal is vir elke ontwikkelaar werk op die projek met 'n geestelike fokus op funksie, jy het 'n opponerende ontwikkelaar met 'n geestelike fokus op die verbreking van die kode (en dus maak dit beter).

Gesien in die lig, dit is minder 'n kwessie van die gebruik van ontwikkelaars vir toetsers as dit is 'n soort van ontkoppel paar-programmering waar 'n mens ontwikkelaar het 'n klem op die beheer van gehalte.

Aan die ander kant, 'n baie van die toets (soos basiese UI funksie) eerlik nie daardie soort van vaardigheid nodig. Dit is waar Joel het 'n punt.

Vir baie besighede, ek kon 'n stelsel waar die programmering spanne handel af-kode hersiening en toetsing pligte vir kode mekaar se sien. Lede van die Business logika span, byvoorbeeld, kan 'n geleentheid toer toets en hersiening kode vir die UI span, en andersom spandeer. Op dié manier is jy nie "mors" ontwikkelaar talent op voltydse toets, maar jy is besig om die voordele van die kode bloot te stel aan (hopelik) deskundige ondersoek en straf. Dan kan 'n meer tradisionele QA span neem die "black box" toets.

Answer 2

Wanneer toepaslik, moet Quality Control spanne in staat wees om uit te voer Sekuriteit, Regressie, bruikbaarheid, prestasie, Stres, Installasie / Upgrade toets en nie Ontwikkelaars

Ontwikkelaars moet toets eenheid met kode-dekking te doen vir die kode as 'n minimale doel geskryf word.

tussenin, daar is nog heelwat toets gedoen moet word

• volle kode pad toets
• komponent toets
• Integrasie toets (van komponente)
• System (integrasie) toets
• ens

Die verantwoordelikheid vir hierdie gemeng tussen QA en Ontwikkeling, gebaseer op sommige van onderlinge ooreenkoms oor wat maak die meeste sin. Sommige komponent toets kan slegs deur 'n eenheid toets, ander "voldoende" getoets tydens integrasie toets ens.

Praat met mekaar, uit te vind wat almal is baie gemaklik doen. Dit sal 'n rukkie neem, maar dit is die moeite werd.

Answer 3

Daar altyd 'n paar ontwikkelaar toets moet wees. As 'n ontwikkelaar is die vervaardiging van te veel foute is, moet hy / sy tyd mors later oor die belangrikheid van dié foute. Dit is belangrik dat die ontwikkelaars nie die houding wat sê ontwikkel, oh well as ek 'n fout te verlaat, dit sal gevang word en ek sal 'n kans om dit op te los te kry.

Ons probeer om 'n drumpel vir foute wat hou. As hierdie drumpel is oorgesteek tydens die toets dan die ontwikkelaar verantwoordelik is vir dit. Dit is aan jou om te besluit wat die drumpel is (vir ons dit kan wissel van projek tot projek).

Ook al eenheid toets word gedoen deur die ontwikkelaars.

Answer 4

Ek het net in die bedryf vir 'n jaar, maar in my ervaring dev se is verantwoordelik vir eenheid toets hul funksies, terwyl QA is verantwoordelik vir die toets scenario's. QA sal ook verwag word om enige Boundryweg voorwaardes te toets.

Answer 5

Ek plak my antwoord op 'n vraag oor ons interne forum. As jy 'n uur of so .. neem 'n luister na Meeding op die basis van Speed video. Aanbevole

Nota (Deur Testers - ek verwys na die QA span)

Ontwikkelaars / Eenheid toetse ________ = _______ Usability toets & Verkennende toets

'============================================== ====================

Die aanvaarding / kliënt toetse ___ = _____ toets Property

Stel jou voor dat 'n vierkant met vier kwadrante wees. :)

Die links helfte moet outomatiese.

• Ontwikkelaars toetse bevestig dat die kode werk as die kodeerder wou dit.   Gereedskap: NUnit / xUnit / wat ook al tuisgemaakte instrument
• Customer toetse bevestig dat die kode werk as die kliënt wou dit. Die toetse moet baie maklik om te skryf nie, moet nie die kliënt nodig het om te leer NET / Java. Anders sal die kliënt gewoond te skryf dié toetse (hoewel hy 'n paar hulp van 'n ontwikkelaar vereis). Fiks byvoorbeeld gebruik HTML tafels wat geskryf kan word in die Woord. Gereedskap: FIT Regressie gereedskap lê ook hier. Rekord-herhaling.

Die reg helfte beter benut die tyd & poging van goeie testers. bv Geen outomatiese toets kan jou vertel of dialoog X is bruikbaar. Die mens is beter by hierdie as masjiene.

• Bruikbaarheid. Probeer om die stelsel af te breek (vang verwerkte mislukking scenario's, betree nul waardes). Basies vang dinge wat die ontwikkelaar gemis.
• toets Property vereis weer mens. Hier kyk jy kliënt mandaat eiendomme wat vereis word deur jou stelsel. bv Prestasie - maak jou dialoog search voldoen aan die 2 sek reaksie tyd? Sekuriteits- kan iemand hak in hierdie stelsel? ens Beskikbaarheid - is jou stelsel aanlyn 99,99% van die tyd

Testers moet nie tyd spandeer uitvoering toets-planne op die linker helfte. Dit is die ontwikkelaars verantwoordelikheid om te verseker dat die kode werk as die kliënt en die ontwikkelaar bedoel om dit te. Die testers kan help om die kliënt te formuleer die aanvaarding toetse INFACT ..

Answer 6

Toets moet as outomatiese as moontlik, wat dit blyk terug in dev werk as die testers skryf kode wat kry by die outomatiese toets suite.

Ook, ek het gevind dat ons kry 'n baie QA gedoen in kode review, as mense ekstra rand en hoek gevalle hulle wil sien by die eenheid toetse wat tans hersien (saam met die kode wat hulle toets sal stel natuurlik).

Answer 7

My algemene houding is dat testers nooit moet vind eenheidsvlak foute (insluitend grens gevalle). Die foute testers vind moet wees by die komponent, integrasie, of stelsel vlak. Natuurlik, op die eerste testers kan "gelukkig pad" foute en ander eenvoudige foute, vind maar hierdie afwykings moet gebruik word om te help ontwikkelaars te verbeter.

Deel van jou probleem kan word met behulp van $ 100 dollar per uur ontwikkelaars en $ 30 per uur testers:}. Maar ongeag die koste, dink ek weet dat foute vroeër gevind in die ontwikkeling siklus is onvermydelik goedkoper, jy waarskynlik nog geld te spaar deur met die ontwikkelaars eie meer toets. As jy 'n hoogs betaalde dev span en hack testers, sal jy waarskynlik 'n groot deel van die groot ooglopende kwessies, maar jy sal 'n baie van die meer obskure foute wat terug gaan na jou toe kom later spook mis.

So, ek dink die antwoord op jou vraag is dat testers soveel moet toets as jy wil hê hulle moet. Jy kan al jou toetsers vuur en het die ontwikkelaars al doen van die toets, of jy kan 'n leër van toetsers te huur en laat die ontwikkelaars so wat hulle wil.

Answer 8

Daar is 2 tipes van QA groepe, diegene wat wil om status quo te handhaaf. Ons het altyd so. Hulle natuurlik haat en ontslae te raak van diegene wat probeer dinge meer doeltreffend te maak en dus verder gaan as hul gemaksone. Wat met my gebeur het meer as een keer. Ongelukkig qa bestuurders is as onbevoeg as hulle QA spanne. So 'n QA bestuurder wat is die bestuur van vir laaste 6 jaar sal enige outomatisering doodmaak, sal voer baie prosesse net om hul existence.This regverdig is 'n boonste bestuur verantwoordelikheid om te erken dat.     Daar is 'n bietjie tegniese qa mense wat gereedskap weet. Ongelukkig is 'n programmeertaal is nie 'n instrument nie, maar 'n visie. Werk met die mense regtig afhang van hoeveel hulle bereid is om te leer en hoeveel die bestuur bereid is om 'n risiko van verandering dinge neem. Die toetse moet geskryf word op dieselfde manier as 'n hoof-kode is geskryf objekgeoriënteerde struktuur maklik om in stand te hou. Ek dink, dat ontwikkelaars moet hersien qa toetse. Die meeste van die tyd wat ek het gevind dat die outomatisering niks toets. Ongelukkig qa werk word beskou as die laer klas, so ontwikkelaars nie moeite doen. Ek myself kry 'n geluk, toe ek 'n ondersteuning van 'n invloedryke ontwikkelaar in 'n groep, wat bereid is om my pogings om 'n bestuurder te verduidelik nie. Dit werk net die helfte van die tyd, ongelukkig. Testers IMHO moet aan dev bestuurder rapporteer. En al span moet 'n verantwoordelikheid vir wat qa toetse eintlik toets te neem.

Answer 9

Hier is 'n paar maniere waarop ontwikkelaar toets is die mees doeltreffende / hoogste beloning:

• Ontwikkelaars verander 'n gedeelde biblioteek terwyl jy werk op 'n funksie - dev het insig in moontlike newe-effekte wat QA / validering nie
• Ontwikkelaars is onseker oor prestasie van biblioteek oproep en skryf 'n eenheid toets
• Ontwikkelaars ontdek pad van gebruik geval nie in spec wat kode moet ondersteun beskou, skryf kode, updates spec, skryf toets

Dit is onseker hoeveel toets plig moet uitgevoer word deur die dev in die derde voorbeeld gedra, maar ek argumenteer dat dit mees doeltreffende vir die dev omdat al die verwante kleinigheden van baie lae van dokumentasie en kode is reeds in haar kort termyn geheue. Dit perfekte storm kan nie haalbaar deur 'n tester na die feit wees.

Is ons praat oor QA of bekragtiging? Ek dink van QA langs die lyne van inspeksie kontrolelyste,-kode standaarde afdwing, riglyne UI, ens As ons praat validering, dit maak nie sin nie vir devs te veel tyd authoring spandeer en uitvoering van formele toets gevalle, maar devs moet al die rasionaal en ontwerp dokumentasie wat nodig is om 'n goeie toets skrywer verskaf.