Një Përdorues Klikoi një Buton Bëri një Screenshoot të Bug-ut dhe e Dërgoi pa Instaluar Asgjë

Ka një moment në jetën e çdo aplikacioni web kur një përdorues has me diçka të prishur. Një buton që nuk bën asgjë kur shtypet. Një skemë që shembet në një madhësi të veçantë ekrani. Një formë që gëlltit mesazhin e vet të gabimit. Përdoruesi shikon në ekran, i hutuar, dhe pastaj bën një nga dy gjërat. Shumica thjesht largohen dhe kurrë nuk kthehen. Pak të rrallë marrin kohë për të hartuar një mesazh përgjatë vijave të "diçka nuk shkon mirë me faqen tuaj." Ky mesazh arrin pa kontekst, pa një përshkrim të asaj çfarë ndodhi, pa asnjë tregim të çfarë shfletuesi ose zyrës ishte i përfshirë, dhe sigurisht pa një ekran fotografuar që tregon problemin aktual. Zhvilluesi lexon atë mesazh, përpiqet të riprodhojë problemin, dështon, dhe bug-u mbetet i nuk është rregulluar derisa ta kërcënon përdoruesin tjetër. Ky cikl përsëritet pa fund në internet, dhe shkaku rrënjësor nuk është dembëlësia e përdoruesit. Shkaku rrënjësor është fërkimi.

Bërja e një ekranu fotografuar në një kompjuter kërkon njohjen e kombinimit të duhur të tasteve, i cili ndryshon në varësi të sistemit operativ. Në Windows mund të jetë Print Screen, ose Alt plus Print Screen për dritaren aktive, ose tastin Windows plus Shift plus S për mjetin e kapjes. Në një Mac është Command plus Shift plus 3, ose 4, ose 5, secili duke prodhuar rezultate pak të ndryshme. Në një telefon jesti përfshin shtypjen e njëkohshme të dy butonave fizikë, i cili gjysma e kohës aksidentalisht e bllokon ekranin në vend të saj. Pasi të bëhet ekranu fotografuar, duhet të gjendet në sistemin e skedarëve, bashkangjitur në një email ose ngjitje në një formë mbështetjeje, dhe të dërgohej. Secili nga këto hapa është një pikë tjetër ku përdoruesi heq dorë dhe vendos se bug-u nuk të vlen një raportet. Rezultati është se zhvilluesit marrin afërisht një raport për çdo njëqind bug-e që përdoruesit në fakt has.

Zgjidha që u ngrit nga kjo zhgënjim është turpërisht e thjeshtë. Një buton i vogël shfaqet në faqe. Kur përdoruesi e klikoi, serveri bën një ekran fotografuar të faqes të saktë që përdoruesi shikon dhe e bashkangjit në një raport. Nuk kërkohet asnjë zgjërim i shfletuesit. Nuk ka kombinim tastete të kujtoj. Nuk ka skedar për të gjetur dhe ngarkuar. Një kliko, një ekran fotografuar, një raport. Përdoruesi shton një vjet ose dy që përshkruaj se çfarë shkoi keq, dhe zhvilluesi merr një imazh të përsosur qartë të faqes të prishur bashkë me përshkrimin. Ky është i gjithë rrjedha e punës, dhe ka ndryshuar mënyrën se si mbërrijnë raportet e bug-eve.

Pse Zgjëtimet e Shfletuesit Nuk e Zgjidhën Kurrë Këtë Problem

Reagimi i dukshëm fillestar është se zgjëtimet e shfletuesit tashmë ekzistojnë për këtë qëllim. Ka doza të mjeteve të kapjes ekrani të disponueshme si zgjëtime Chrome, shtesa Firefox, dhe shtesa Safari. Disa prej tyre janë mjaft të mira, me tipare adnotimi, ngarkim automatik, dhe integrimi me platforma të menaxhimit të projekteve. Por të gjithë ndajnë të njëjtën defekt themelor. Ata kërkojnë nga përdoruesi të instaloj diçka përpara se të ndodhë bug-u. Askush nuk instalon një zgjërim të raportimit të bug-eve paraprake në rast se një faqe interneti që do të vizitojnë nesër do të ketë një skemë të prishur. Zgjëtimet zgjidhin problemin për ekipet e QA dhe provuesit e brendshëm që mund t'u thuhet të instalojnë mjete specifike. Nuk bëjnë absolutisht asgjë për publikun e gjerë që has një bug për herë të parë në një faqe që mund të mos vizitojnë kurrë përsëri.

Ka edhe çështjen e besimit. Kërkesa për një përdorues për të instaluar një zgjërim të shfletuesit me qëllim raportimin e një bug-u prezanton një zhvendosje të mprehtë në ndërveprim. Përdoruesi erdhi në faqe për të arritur diçka, zbuloi që ishte e prishur, dhe tani i kërkohej të instaloj softuerin e palëve të treta. Ky kërkesë në mënyrë të drejtë do të ngrejë dyshim për shumë përdorues, dhe madje edhe ata të gatshëm të përputhjen me kostona të navigimit të dyqaneve të zgjëtimeve, dhënies së leje, dhe të zbulimit se si punon mjeti. Nga koha kur instalohet zgjëtimi, bug-u origjinal mund të mos jetë më i riprodhushëm, ose përdoruesi thjesht ka kaluar në një konkurrent. Dritarja për kapjen e një raport bug-u është e ngushtë, dhe çdo gjë që e zgjerojnë hendekun midis "diçka shkon keq" dhe "raporti u dërgua" do të thotë se raporti nuk dërgohet kurrë.

Bibliotekavat e kapjes ekrani në anën e klientit, siç janë html2canvas, kanë përpjekur të zgjidhin këtë nga një kënd i ndryshëm. Këto biblioteka JavaScript paraqesin DOM-in në një element kanvas, duke efektivisht gjetur një ekran fotografuar pa asnjë përfshirje të serverit. Ato funksionojnë në mënyrë të arsyeshme mirë për skema të thjeshta, por dështojnë shpejt me CSS kompleks, iframe të ngulitur, imazhe cross-origin, elemente kanvas, dhe fonde të zakonshme. Imazhi rezultues shpesh nuk duket fare siç shikon përdoruesi në fakt, i cili dështon në mënyrë të plotë qëllimin. Një raport bug-u që përmban një ekran fotografuar që nuk përputhet me faqen aktuale është më keq se asnjë ekran fotografuar, sepse dërgon zhvilluesi duke ndjekur një problem vizual që nuk ekziston ndërsa problemi aktual mbetet i fshehur.

Ekranet e Fotografuar në Anën e Serverit dhe Si Ata Kapin Ato Që Përdoruesi Shikon

Qasja pas screenshots.yeb.to merr një shteg plotësisht të ndryshëm. Në vend të përpjekjes për të rikonstruuar faqen në anën e klientit, serveri merr URL-in dhe e paraqet duke përdorur një motor shfletuesi të vërtetë që funksionon në një mjedis të kontrolluar. Ekranu fotografuar merret nga një instancë e vërtetë Chromium që ngarkon faqen, ekzekuton JavaScript, aplikon CSS, paraqet fondet, dhe kapja rezultatin si një imazh i përsosur. Kjo do të thotë se ekranu fotografuar duket saktësisht siç shfaq një shfletues i vërtetë, sepse ajo është ajo që shfaq një shfletues i vërtetë.

Kur një përdorues klikon butonin e raportimit të bug-ut, URL-i aktual i faqes dërgohet në serverin bashkë me metapodatat rreth madhësisë viewport të përdoruesit, raportit të pikselëve të zyrës, dhe çdo parametrash të kërkuara të shtetit. Serveri lëshon një sesion shfletuesit pa kokë të konfiguruar për të përputhur sa më mirë me këto parametra. Ngarkon faqen, pret që të gjitha aktivet të përfundojnë paraqitjen, dhe merr ekranin fotografuar. Rezultati ruhet dhe lidhet me raportin bug-u, i cili i jep zhvilluesit një regjistrim vizual të saktë të faqes në momentin kur përdoruesi klikon butonin. Procesi i tërë zgjat disa sekonda, i cili është mjaft i shpejtë që përdoruesi të shtojë përshkrimin e tij ndërsa ekranu fotografuar gjenerohet në sfondin.

Ka nuanca që e vlejnë të njohura. Një ekran fotografuar në anën e serverit kap faqen siç shfaqet në server, jo domosdoshmërisht pikselat e saktë në ekranin e përdoruesit. Nëse bug-u shkaktohet nga çudira të dhëniese të shfletuesit specifike, përmbajtje cache, ose gjendje e ruajtur në nivel lokal, kapja e serverit mund të mos riprodhojë artefaktin vizual të saktë. Por në praktikë, shumica dërmuese e bug-eve që raportin përdoruesit janë probleme të skemës, imazhe të prishur, përmbajtje që mungon, ose dështimet funksionale që janë konsistente pavarësisht se kush ngarkoi faqen. Për këto raste, një ekran fotografuar në anën e serverit nuk ndryshon nga ai në anën e klientit, dhe zvogëlimi masiv i fërkimit e bënë kompromis për të vlerë.

Duke Integruar Butonin Pa Ndryshuar Aplikacionin

Integrimi është me qëllim minimal. Një fragment i vogël JavaScript ngarkon komponentën buton, e cila mund të stilozohet për të përputhur sistemin e dizajnit të aplikacionit hostues. Butoni fluturon në një qoshe të faqes, të dukshëm por diskret. Kur shtypet, hap një mbivendosje të lehtë ku përdoruesi mund të shkruaj një përshkrim të shkurtë dhe opsionalisht të nënvizojë zonën e faqes ku ndodhi problemi. Prapa skenës, fragmenti dërgon URL-in aktual në API-n e kapjes ekrani, i cili kap faqen dhe kthen URL-in e imazhit. Raporti, i cili përmban ekranin fotografuar, përshkrimin, URL-in, dhe metapodatat e shfletuesit të bazës, dërgohet pastaj në çfarëdo qëllimi që zhvilluesi ka konfiguruar: një adresë email, një webhook Slack, një mjet menaxhimi projekti, ose një pikë përfundimi të zakonshme.

Integrimi i tërë nuk kërkon asnjë ndryshim në backend-in e aplikacionit. Nuk ka SDK për të instaluar, nuk ka middleware për të konfiguruar, nuk ka skemë baze të dhënash për të modifikuar. Fragmenti funksionon në mënyrë të pavarur, i komunikimit vetëm me API-n e kapjes ekrani dhe qëllimin e raportimit të konfiguruar. Kjo do të thotë se mund të hidhet në një blog WordPress, një aplikacion React me një faqe të vetme, një faqe HTML statike, ose një aplikacion PHP të vjetër me lehtësi të barabartë. Koha nga vendimi i shtimit të raportimit të bug-eve deri sa ta ketë në jetë në faqe matet në minuta, jo në shprintime.

Për zhvilluesit që dëshirojnë integrimi më të thellë, API-ja mund të thirrët drejtpërdrejt nga kodi në anën e serverit. Kjo hap mundësi të tilla si kapja automatike e një ekranu fotografuar sa herë ndodh një përjashtim i patrajtuar, ose marrja e ekraneve të fotografuar periudike të faqeve kritike dhe krahasimi i tyre kundër një linje bazë për të zbuluar regresionet vizuale. Por për rastin e përdorimit bazë të lejimit të përdoruesve të raportojnë bug-et me një kliko të vetme, fragmenti JavaScript bën kujdes për gjithçka pa asnjë ndryshim në anën e serverit.

Çfarë Ndryshon Kur Raportet e Bug-eve në Fakt Mbërrijnë

Transformimi në cilësinë e raportimit të bug-ut është dramatik. Para zbatimit të butonit, raporti tipik i bug-ut ishte një vjet i paqartë në një email. "Faqja duket e çuditshme." "Checkout-i është i prishur." "Diçka ndodhi kur përpiqesha të ruaj." Këto raporte kërkuan ronde të shumta të pyetjeve të ndjekjes, gjatë së cilës përdoruesi shpesh humbi durim dhe ndaloi të përgjigjej. Pas zbatimit të butonit, raportet mbërrijnë me një ekran fotografuar të qartë që tregon saktësisht se çfarë shkoi keq, bashkë me metapodatat që identifikojnë faqen, madhësinë viewport, dhe kohën e ndodhjes. Një zhvillues mund të shikojë ekranin fotografuar dhe të kuptojë menjëherë problemin pa asnjë përpara dhe prapa.

Vëllimi i raporteve gjithashtu rritet ndjeshëm. Përdoruesit që nuk do të hartojnë kurrë një email ose të plotësojnë një formë mbështetjeje do të kliko një buton dhe do të shkruaj tre fjalë. "Menuja përmbyset përmbajtjen" nuk është raporti më i detajuar i bug-ut në botë, por i kombinuar me një ekran fotografuar që tregon një menu navigimi të mbivendosur në zonën e përmbajtjes kryesore në një viewport mobil, i thotë zhvilluesit gjithçka që ka nevojë për të riprodhuar dhe riparuar problemin. Kombinimi i fërkimit më të ulët dhe konteksti më i pasur do të thotë se bug-et raportohen më herët, riparohen më shpejt, dhe verifikohen më besueshëm. Ditët e zbulimit të një problemi të skemës kritike tre javë pasi u paraqit janë në shumë masa të kaluara për çdo aplikacion që implementon këtë lloj mekanizmi feedback.

Ka një përfitim dytësor që është më pak i dukshëm, por po aq i vlefshëm. Arkiva e ekraneve të fotografuar bëhet një histori vizuale e aplikacionit. Çdo raport kap një moment në kohë, duke treguar saktësisht se si dukte faqja kur përdoruesi has një problem. Gjatë javëve dhe muajve, kjo arkivë zbërthen modelet. Ndoshta një faqe e caktuar shembet çdo herë kur bëhet një zbatim i ri. Ndoshta përdoruesit e celularit raportin probleme me një çështje tre herë më të lartë sesa përdoruesit e desktop. Ndoshta një version i caktuar i shfletuesit në mënyrë konsistente prodhon anomali të skemës. Këto modele janë të padukshme në raportet e vetme tekstit të bug-ut, por bëhen menjëherë të dukshme kur shfletoni një galeri të ekraneve të fotografuar të markuar me kohë.