Hola Habr!
Tenim un nou tema important: el desenvolupament de productes informàtics d'alta qualitat. A HighLoad++ sovint parlem de com fer que els serveis ocupats siguin ràpids, i a Frontend Conf parlem d'una interfície d'usuari fantàstica que no s'alenteix. Periòdicament tenim temes sobre proves i DevOpsConf sobre la combinació de diferents processos, incloses les proves. Però sobre el que es pot anomenar qualitat en general i com treballar-hi de manera integral, no.
Arreglem això per — Desenvoluparem una cultura de pensament sobre la qualitat del producte final per a l'usuari en cada fase de desenvolupament. L'hàbit de no centrar-se en la seva àrea de responsabilitat, i associar la qualitat no només amb els provadors.
Per sota del tall parlarem amb el cap del comitè del programa, cap de proves de Tinkoff.Business, creador de la comunitat de control de qualitat de parla russa. Anastasia Aseeva-Nguyen sobre l'estat de la indústria del control de qualitat i la missió de la nova conferència.
- Hola Nastia. Si us plau, parleu-nos de vosaltres mateixos.
Анастасия: Gestiono proves en un banc, sóc responsable d'un equip molt gran: som més de 90 persones. Tenim una línia de negoci important, som responsables de l'ecosistema de les persones jurídiques.
Vaig estudiar mecànica i matemàtiques i inicialment volia ser programador. Però quan vaig rebre una oferta interessant, vaig decidir provar-me com a provador. Curiosament, aquesta va resultar ser la meva vocació. Ara veig tota la meva feina en aquesta indústria.
Sóc un fervent partidari de la disciplina d'assegurament de la qualitat. No em deixa indiferent quins productes es creen, com es tracta la qualitat a l'empresa, a l'equip i, en principi, al procés de desenvolupament.
Això és evident per a mi la comunitat en aquesta direcció no és prou madura, almenys a Rússia. No sempre entenem que l'assegurament de la qualitat no és només el fet de provar una aplicació per complir els requisits. M'agradaria canviar aquesta situació.
— Utilitzeu les paraules assegurament de la qualitat i proves. Als ulls de la persona mitjana, aquests dos termes sovint es superposen. En què es diferencien si caves profundament?
Anastasia: Més aviat, no són diferents. Les proves forma part de la disciplina d'assegurament de la qualitat; és una activitat directa, el mateix fet que estic provant alguna cosa. En realitat, hi ha molts tipus de proves, i una varietat de persones són responsables de diferents tipus de proves. Però aquí a Rússia, quan va aparèixer una onada de subcontractistes que subministren provadors a les empreses, les proves es van reduir a un sol tipus.
En la majoria dels casos, es limiten només a proves funcionals: comproven que el que han codificat els desenvolupadors compleix l'especificació i això és tot.
— Si us plau, digueu-nos quines altres disciplines de garantia de qualitat hi ha? Què més, a més de les proves, s'inclou aquí?
Анастасия: L'assegurament de la qualitat consisteix, en primer lloc, a crear un producte de qualitat. És a dir, ens preguntem quins atributs de qualitat ha de tenir el nostre producte. En conseqüència, si entenem això, podem comparar qui influeix en aquests atributs de qualitat. No importa, desenvolupador, gestor de projectes o especialista en producte és una persona que influeix en el desenvolupament d'un producte, el seu backlog i la seva estratègia.
El provador és més conscient del seu paper. Entén que la seva tasca no és només provar el compliment dels requisits, sinó també provar requisits, qüestionar les formulacions que provenen de l'especialista de producte i revelar tots els requisits i expectatives implícites del client. Quan oferim noves funcionalitats al nostre client, hem de satisfer realment les seves expectatives i resoldre el seu dolor. Si pensem en tots els atributs de la qualitat, el client estarà satisfet i entendrà que l'empresa el producte de la qual utilitza realment es preocupa pels seus interessos i no treballa amb el principi de "només per llançar una característica".
— Sembla que el que acabes de descriure és tasca d'un especialista en productes. Això, en principi, no es tracta de proves ni de qualitat: generalment es tracta de la gestió del producte, no?
Анастасия: Incloent. L'assegurament de la qualitat no és una disciplina de la qual sigui responsable una persona específica. Ara hi ha una direcció popular en les proves, un enfocament anomenat Proves àgils. La seva definició indica clarament que es tracta d'un enfocament d'equip per a les proves, que inclou un determinat conjunt de pràctiques. Tot l'equip és responsable d'implementar aquest enfocament; ni tan sols és necessari que hi hagi un verificador a l'equip. Tot l'equip està enfocat a oferir valor al client i garantir que el valor compleix les expectatives del client.
— Resulta que la qualitat es creua amb gairebé totes les disciplines que l'envolten, imposant un marc a tot el que l'envolta?
Анастасия: Dret. Quan pensem en com volem crear un producte de qualitat, comencem a pensar en els diferents atributs de la qualitat. Per exemple, com comprovar que realment hem creat la funció que necessita el nostre client.
Aquí és on entra aquest tipus de proves: UAT (prova d'acceptació dels usuaris). Malauradament, rarament es practica a Rússia, però de vegades està present als equips SCRUM com a demostració per al client final. Aquest és un tipus de proves força comú a les empreses estrangeres. Abans d'obrir la funcionalitat a tots els clients, primer fem UAT, és a dir, convidem l'usuari final que prova i immediatament dóna comentaris: si el producte realment compleix les expectatives i soluciona el dolor. Només després d'això es produeix l'escala a tots els altres clients.
És a dir, ens centrem en el negoci, en el client final, però alhora no t'oblidis de la tecnologia. La qualitat del producte també depèn en gran mesura de la tecnologia. Si tenim una arquitectura dolenta, no podrem llançar funcions ràpidament i satisfer les expectatives dels clients. Pot haver-hi molts errors quan intentem escalar, o quan intentem refactoritzar podem trencar alguna cosa. Tot això afectarà la satisfacció del client.
Des d'aquest punt de vista, l'arquitectura ha de ser tal que puguem escriure codi net que ens permeti fer canvis ràpidament i no tenir por que ho trenquem tot. De manera que les iteracions de revisió no s'estenen durant diversos mesos simplement perquè tenim tant llegat i hem de fer etapes de prova llargues.
— En total, els desenvolupadors, arquitectes, científics de productes, gestors de productes i els mateixos provadors ja estan implicats. Qui més participa en el procés d'assegurament de la qualitat?
Анастасия: Ara imaginem que ja hem lliurat la funció al client. Òbviament, la qualitat del producte s'ha de controlar fins i tot quan ja està en producció. En aquesta etapa, poden aparèixer situacions amb escenaris no evidents, els anomenats errors.
La primera pregunta és com tractem aquests errors després d'haver llançat el producte? Com reaccionem, per exemple, davant l'estrès? El client no estarà molt content si la pàgina triga més de 30 segons a carregar-se.
Aquí és on entra en joc l'explotació o, com en diuen ara, DevOps. De fet, aquestes són les persones que s'encarreguen d'explotar el producte quan ja està en producció. Això inclou diversos tipus de seguiment. Fins i tot hi ha un subtipus de proves: proves en producció, quan ens permetem no provar alguna cosa abans del llançament i provar-ho immediatament en producció. Es tracta d'una sèrie de mesures des del punt de vista de l'organització de la infraestructura que permeten respondre ràpidament a una incidència, influir-hi i corregir-la.
Les infraestructures també són importants. Sovint hi ha situacions en què, durant una prova, és impossible assegurar-nos que tenim realment tot el que ens agradaria donar al client. El tirem a la producció i comencem a detectar situacions no òbvies. I tot perquè la infraestructura de la prova no es correspon amb la infraestructura de producció. Això condueix a un nou tipus de proves: proves d'infraestructura. Es tracta de diverses configuracions, paràmetres, migració de bases de dades, etc.
Això planteja la pregunta: potser l'equip necessita utilitzar la infraestructura com a codi.
Crec que la infraestructura afecta directament la qualitat del producte.
Espero que hi hagi un informe a la conferència amb un cas real. Escriu-nos si estàs preparat per explicar-nos des de la teva pròpia experiència com la infraestructura com a codi afecta la qualitat. La infraestructura com a codi fa que sigui més fàcil comprovar tots els paràmetres i provar coses que d'una altra manera simplement no seria possible. Per tant, l'operació també està implicada en el procés de desenvolupament d'un producte de qualitat.
— Què passa amb l'anàlisi i la documentació?
Анастасия: Això s'aplica més als sistemes empresarials. Quan parlem d'empresa, de seguida ens vénen al cap persones com ara analistes i analistes de sistemes. De vegades s'anomenen escriptors tècnics. Reben una tasca per escriure una especificació i completar-la, per exemple, durant un mes.
S'ha demostrat repetidament que escriure aquesta documentació comporta iteracions de desenvolupament molt llargues i llargues iteracions de perfeccionament, perquè durant el procés de prova s'identifiquen errors i comencen les devolucions. Com a resultat, hi ha molts bucles que augmenten els costos de desenvolupament. A més, això pot introduir vulnerabilitats. Sembla que hem escrit codi de referència, però després hem fet canvis que trenquen l'arquitectura perfectament pensada.
El resultat final és un producte no del tot d'alta qualitat, perquè ja han aparegut pegats a l'arquitectura, el codi en alguns llocs no està prou cobert per proves, perquè els terminis s'esgoten, tots els errors s'han de tancar ràpidament. I tot perquè l'especificació original no tenia en compte tots els punts que calia implementar.
Els desenvolupadors no són plagues i no escriuen codi amb errors a propòsit.
Si inicialment haguéssim pensat en una especificació que hagués cobert tots els punts necessaris, tot s'hauria implementat exactament com calia. Però això és una utopia.
Probablement sigui impossible escriure una especificació perfecta de 100 pàgines. Aixo es perqué cal pensar en maneres alternatives d'escriure la documentació, especificacions, establir tasques que ens acostaran a garantir que el desenvolupador fa exactament el que cal.
Aquí em vénen al cap enfocaments d'Agile: històries d'usuari amb criteris d'acceptació. Això és més aplicable als equips que es desenvolupen en petites iteracions.
— Què passa amb les proves d'usabilitat, la usabilitat del producte, el disseny?
Анастасия: Aquest és un punt molt important, perquè hi ha dissenyadors a l'equip. Molt sovint, els dissenyadors s'utilitzen com a servei, ja sigui per un departament de disseny o per un dissenyador subcontractat. Sovint hi ha situacions en què sembla que el dissenyador va escoltar l'especialista de producte i va fer el que va entendre. Però quan comencem la iteració, resulta que el que es va fer realment no va ser el que s'esperava: el dissenyador va oblidar alguna cosa, no va pensar completament en el comportament, perquè no està a l'equip ni al context, o al davant. -end el desenvolupador no entenia completament el disseny. Pot ser que es necessitin diverses iteracions només perquè hi ha un problema amb que el desenvolupador frontal entén el disseny.
A més, hi ha un problema més. Els sistemes de disseny estan guanyant popularitat. Estan a la moda, però els beneficis d'ells no són del tot evidents.
Em trobo amb l'opinió que els sistemes de disseny, d'una banda, simplifiquen el desenvolupament, però d'altra banda, imposen moltes restriccions a la interfície.
En conseqüència, no fem la característica que vol el client, sinó la que ens convé, perquè ja disposem de certs cubs a partir dels quals podem fer-ho.
Crec que aquest és un tema que val la pena fer-hi una ullada i preguntar-se si en intentar facilitar el disseny estem solucionant un problema del client.
— Hi ha un nombre sorprenent de temes relacionats amb l'assegurament de la qualitat. Hi ha una conferència a Rússia on es puguin parlar de tots?
Анастасия: Hi ha la conferència de proves més antiga, que se celebrarà per 25a vegada aquest any i s'anomena SQA Days Quality Assurance Conference. Es tracta principalment d'eines i enfocaments de prova específics per a provadors funcionals. Per regla general, els informes dels SQA Days examinen en profunditat àrees específiques en l'àrea de responsabilitat dels mateixos provadors, però no activitats complexes.
Això ajuda molt a entendre diferents eines i enfocaments, com provar bases de dades, API, etc. Però al mateix temps, d'una banda, no motiva implicar més que provar en la creació d'un producte millor. D'altra banda, els provadors no s'impliquen més en el procés per pensar en l'objectiu global del producte i el seu component de negoci.
Dirig un gran departament i faig moltes entrevistes que realment proporcionen una visió de l'estat de la indústria en el seu conjunt. Per regla general, els nostres nois treballen en empreses i tenen una àrea de responsabilitat clara. Els companys que treballen en projectes estrangers utilitzen diferents tipus de proves: ells mateixos poden fer proves de càrrega, proves de rendiment i, fins i tot, de vegades proves de seguretat, perquè realment ajuden l'equip a garantir la qualitat del producte.
M'agradaria que els nois de Rússia també comencin a pensar que la indústria no acaba amb proves funcionals.
— Amb aquesta finalitat, organitzem una nova jornada, QualityConf, dedicada a la qualitat com a disciplina integral. Explica'ns més sobre la idea, quin és l'objectiu principal de la jornada?
Анастасия: Volem crear una comunitat de persones interessades a fer productes de qualitat. Oferir una plataforma on puguin venir, escoltar informes i marxar després de la conferència amb una comprensió específica del que cal canviar per millorar la qualitat.
Avui en dia escolto sovint una sol·licitud de consultoria sobre què fer quan hi ha problemes amb les proves i la qualitat. Quan comences a comunicar-te amb els equips, veus que el problema no és dels mateixos provadors, sinó de com s'estructura el procés. Per exemple, quan els desenvolupadors creuen que només són responsables d'escriure codi, la seva responsabilitat acaba exactament en el moment en què entren la tasca a la prova.
No tothom pensa en el fet que el codi mal escrit i de baixa qualitat amb una arquitectura deficient amenaça amb grans problemes per al projecte. No pensen en el cost dels errors, que els errors que acaben en producció poden comportar grans costos per a l'empresa i l'equip. No hi ha cultura per pensar en això. Vull que comencem a distribuir-lo a la conferència.
Entenc que això no és una innovació. Edward Deming, l'autor dels 14 principis de la qualitat, va escriure sobre el cost d'un error al segle passat. L'assegurament de la qualitat com a disciplina es basa en aquest llibre, però, malauradament, el desenvolupament modern se n'oblida.
— Teniu previst tocar directament temes sobre proves i eines?
Анастасия: Admeto que hi haurà informes sobre eines. Hi ha eines força universals amb les quals les empreses i els equips poden influir en el producte.
Tots els informes estaran units globalment per una missió comuna: transmetre a l'audiència que amb l'ajuda d'aquest enfocament, eina, mètode, procés, tipus de prova, hem influït en la qualitat del producte i hem millorat la vida del client.
Definitivament no tindrem informes sobre una eina pel bé d'una eina. Tots els informes inclosos en el programa estaran units per un objectiu comú.
— A qui li interessarà el que esteu parlant, a qui veus com a convidats de la conferència?
Анастасия: Tindrem informes per a desenvolupadors que es preocupen pel destí del seu projecte, producte, sistema. Així mateix, serà d'interès per als provadors i, em sembla, sobretot per als directius. Per directius, em refereixo a persones que prenen decisions i poden influir en el destí i el desenvolupament d'un producte, sistema, equip també.
Són persones que es pregunten com millorar la qualitat d'un producte o sistema. A la nostra conferència, coneixeran diversos conjunts de mesures i podran entendre què hi passa ara i què cal canviar.
Crec que el criteri principal és entendre que alguna cosa no funciona amb la qualitat i voler influir-hi. Probablement no podrem arribar a persones que pensen que això serà la primera vegada.
— Creus que la indústria en conjunt està madura per parlar no només de proves, sinó d'una cultura de qualitat?
Анастасия: Crec que he madurat. Ara moltes empreses s'estan allunyant de l'enfocament tradicional Waterfall cap a Agile. Hi ha un enfocament al client, la gent dels equips realment comença a pensar com crear un producte de qualitat. Fins i tot les empreses empresarials s'estan reorientant a millorar la qualitat.
A jutjar pel nombre de peticions que es plantegen a la comunitat, crec que és el moment. No estic segur, per descomptat, que aquesta serà una revolució a gran escala, però m'agradaria que aquesta revolució de la consciència es produís.
- Convingut! Inculcarem cultura i canviarem la consciència.
Conferència sobre desenvolupament d'alta qualitat de productes informàtics tindrà lloc a Moscou el 7 de juny. Ja sabeu quines etapes formen un producte d'alta qualitat, tenim casos de combatre amb èxit els errors en la producció, hem provat mètodes populars a la nostra pràctica: necessitem la vostra experiència. seva sol·licituds abans de l'1 de maig, i el Comitè del Programa ajudarà a centrar el tema per a la integritat general de la conferència.
Conectat amb , en què parlem de qüestions de qualitat i la conferència, subscriu-te per estar al dia de les notícies del programa.
Font: www.habr.com