Ola Habr!
Temos un novo tema importante: o desenvolvemento de produtos informáticos de alta calidade. En HighLoad++ adoitamos falar de como facer que os servizos ocupados sexan rápidos, e en Frontend Conf falamos dunha interface de usuario xenial que non se ralentiza. Temos regularmente temas sobre probas e DevOpsConf sobre a combinación de diferentes procesos, incluídas as probas. Pero sobre o que se pode chamar calidade en xeral e como traballalo de forma integral - non.
Imos arranxar isto por — Desenvolveremos unha cultura de reflexión sobre a calidade do produto final para o usuario en cada fase do desenvolvemento. O hábito de non centrarse na súa área de responsabilidade e asociar calidade non só aos probadores.
Debaixo do corte falaremos co xefe do comité do programa, xefe de probas de Tinkoff.Business, creador da comunidade de QA de fala rusa. Anastasia Aseeva-Nguyen sobre o estado da industria de control de calidade e a misión da nova conferencia.
- Nastia ola. Fálanos de ti.
Анастасия: Xestiono probas nun banco, son responsable dun equipo moi grande: somos máis de 90 persoas. Temos unha importante liña de negocio, somos responsables do ecosistema das persoas xurídicas.
Estudei mecánica e matemáticas e inicialmente quería ser programador. Pero cando recibín unha oferta interesante, decidín probarme como probador. Curiosamente, esta resultou ser a miña vocación. Agora vexo todo o meu traballo nesta industria.
Son un fervente seguidor da disciplina de Garantía de Calidade. Non me deixa indiferente que produtos se crean, como se trata a calidade na empresa, no equipo e, en principio, no proceso de desenvolvemento.
Iso é obvio para min a comunidade nesta dirección non é o suficientemente madura, polo menos en Rusia. Non sempre entendemos que a garantía de calidade non é só o feito de probar unha aplicación para o cumprimento dos requisitos. Gustaríame cambiar esta situación.
— Utiliza as palabras Garantía de calidade e probas. Ao ollos da persoa media, estes dous termos adoitan solaparse. En que se diferencian se cavas profundamente?
Anastasia: Pola contra, non son diferentes. As probas forman parte da disciplina de Garantía de Calidade; é unha actividade directa, o mesmo feito de que estou probando algo. En realidade, hai moitos tipos de probas, e unha variedade de persoas son responsables de diferentes tipos de probas. Pero aquí en Rusia, cando apareceu unha onda de subcontratistas que fornecen probadores ás empresas, as probas reducíronse a un único tipo.
Na maioría dos casos, limítanse só a probas funcionais: comproban que o que codificaron os desenvolvedores cumpre coa especificación e iso é todo.
— Díganos que outras disciplinas de garantía de calidade existen? Que máis se inclúe aquí, ademais das probas?
Анастасия: A garantía de calidade consiste, en primeiro lugar, en crear un produto de calidade. É dicir, preguntámonos que atributos de calidade debe ter o noso produto. En consecuencia, se entendemos isto, podemos comparar quen inflúe nestes atributos de calidade. Non importa, desenvolvedor, xestor de proxectos ou especialista en produtos é unha persoa que inflúe no desenvolvemento dun produto, no seu atraso e na súa estratexia.
O probador faise máis consciente do seu papel. Entende que a súa tarefa non é só probar o cumprimento dos requisitos, senón tamén probar os requisitos, cuestionar as formulacións que proveñen do especialista en produtos e revelar todos os requisitos e expectativas implícitas do cliente. Cando entregamos novas funcionalidades ao noso cliente, debemos cumprir as súas expectativas e resolver a súa dor. Se pensamos en todos os atributos da calidade, o cliente estará satisfeito e entenderá que a empresa cuxo produto usa realmente se preocupa polos seus intereses e non funciona co principio de "só para lanzar unha función".
— Parece que o que acabas de describir é tarefa dun especialista en produtos. Isto, en principio, non se trata de probas nin de calidade; xeralmente trátase de xestión de produtos, non?
Анастасия: Incluíndo. A Garantía de Calidade non é unha disciplina da que sexa responsable unha persoa específica. Agora hai unha dirección popular nas probas, un enfoque chamado Probas áxiles. A súa definición indica claramente que se trata dun enfoque de equipo para as probas, que inclúe un determinado conxunto de prácticas. Todo o equipo é responsable de implementar este enfoque; nin sequera é necesario que haxa un probador no equipo. Todo o equipo está enfocado en ofrecer valor ao cliente e garantir que o valor satisfaga as expectativas do cliente.
— Acontece que a calidade se cruza con case todas as disciplinas circundantes, impondo un marco a todo?
Анастасия: certo. Cando pensamos en como queremos crear un produto de calidade, comezamos a pensar nos distintos atributos da calidade. Por exemplo, como comprobar que realmente fixemos a función que necesita o noso cliente.
Aquí é onde entra este tipo de probas: UAT (proba de aceptación do usuario). Desafortunadamente, raramente se practica en Rusia, pero ás veces está presente nos equipos SCRUM como demostración para o cliente final. Este é un tipo de proba bastante común en empresas estranxeiras. Antes de abrir a funcionalidade a todos os clientes, primeiro facemos UAT, é dicir, invitamos ao usuario final que proba e inmediatamente dá comentarios: se o produto realmente cumpre as expectativas e soluciona a dor. Só despois disto ocorre a escala a todos os demais clientes.
É dicir, centrámonos no negocio, no cliente final, pero ao mesmo tempo non te esquezas da tecnoloxía. A calidade do produto tamén depende moito da tecnoloxía. Se temos unha mala arquitectura, non poderemos lanzar funcións rapidamente e cumprir as expectativas dos clientes. Pode haber moitos erros ao tentar escalar, ou ao tentar refactorizar podemos romper algo. Todo isto afectará á satisfacción do cliente.
Dende este punto de vista, a arquitectura debería ser tal que poidamos escribir código limpo que nos permita facer cambios rapidamente e non ter medo de que o romperemos todo. Para que as iteracións de revisión non se estendan durante varios meses simplemente porque temos moito legado e necesitamos facer longas etapas de proba.
— En total, desenvolvedores, arquitectos, científicos de produtos, xestores de produtos e os propios probadores xa están implicados. Quen máis participa no proceso de garantía de calidade?
Анастасия: Agora imaxinemos que xa entregamos a función ao cliente. Obviamente, hai que controlar a calidade do produto aínda que xa estea en produción. Nesta fase, poden aparecer situacións con escenarios non obvios, os chamados erros.
A primeira pregunta é como tratamos estes erros despois de que xa teñamos lanzado o produto? Como reaccionamos, por exemplo, ao estrés? O cliente non estará moi contento se a páxina tarda máis de 30 segundos en cargarse.
Aquí é onde entra en xogo a explotación ou, como a chaman agora, DevOps. De feito, estas son as persoas que se encargan de operar o produto cando xa está en produción. Isto inclúe varios tipos de seguimento. Incluso hai un subtipo de proba: probas en produción, cando nos permitimos non probar algo antes do lanzamento e probalo inmediatamente na produción. Trátase dunha serie de medidas dende o punto de vista da organización da infraestrutura que permiten responder rapidamente a unha incidencia, influír nela e corrixila.
As infraestruturas tamén son importantes. Moitas veces hai situacións nas que, durante unha proba, é imposible asegurarse de que realmente temos todo o que nos gustaría darlle ao cliente. Lanzámolo á produción e comezamos a detectar situacións non obvias. E todo porque a infraestrutura na proba non se corresponde coa infraestrutura en produción. Isto leva a un novo tipo de proba - probas de infraestruturas. Estas son varias configuracións, axustes, migración de bases de datos, etc.
Isto suscita a pregunta: quizais o equipo necesite usar a infraestrutura como código.
Creo que a infraestrutura afecta directamente á calidade do produto.
Espero que haxa un informe na conferencia cun caso real. Escríbenos se estás preparado para contarnos desde a túa propia experiencia como a infraestrutura como código afecta á calidade. A infraestrutura como código facilita a comprobación de todas as opcións e probar cousas que doutro xeito simplemente non serían posibles. Polo tanto, a operación tamén está implicada no proceso de desenvolvemento dun produto de calidade.
—¿Que pasa coa análise e a documentación?
Анастасия: Isto aplícase máis aos sistemas empresariais. Cando falamos de empresa, inmediatamente veñen á mente persoas como analistas e analistas de sistemas. Ás veces chámanse escritores técnicos. Reciben unha tarefa para escribir unha especificación e completala, por exemplo, durante un mes.
Probouse repetidamente que escribir esa documentación leva a iteracións de desenvolvemento moi longas e longas iteracións de refinamento, porque durante o proceso de proba identifícanse erros e comezan as devolucións. Como resultado, hai moitos bucles que aumentan os custos de desenvolvemento. Ademais, isto pode introducir vulnerabilidades. Parece que temos código de referencia escrito, pero despois fixemos cambios que rompen a arquitectura perfectamente pensada.
O resultado final é un produto non totalmente de alta calidade, porque xa apareceron parches na arquitectura, o código nalgúns lugares non está suficientemente cuberto por probas, porque os prazos están esgotando, todos os erros deben pecharse rapidamente. E todo porque a especificación orixinal non tivo en conta todos os puntos que hai que implementar.
Os desenvolvedores non son pragas e non escriben código con erros a propósito.
Se inicialmente tivesemos pensado nunha especificación que cubrira todos os puntos necesarios, entón todo sería implementado exactamente como era necesario. Pero isto é unha utopía.
Probablemente sexa imposible escribir unha especificación perfecta de 100 páxinas. Por iso necesidade de pensar en formas alternativas de escribir a documentación, especificacións, establecer tarefas que nos achegarían a garantir que o desenvolvedor fai exactamente o que fai falta.
Aquí me veñen á mente enfoques de Agile: historias de usuarios con criterios de aceptación. Isto é máis aplicable para equipos que se desenvolven en pequenas iteracións.
— Que pasa coas probas de usabilidade, a usabilidade do produto e o deseño?
Анастасия: Este é un punto moi importante, porque hai deseñadores no equipo. Na maioría das veces, os deseñadores úsanse como servizo, xa sexa por un departamento de deseño ou por un deseñador subcontratado. Moitas veces hai situacións nas que parece que o deseñador escoitou ao especialista en produtos e fixo o que entendía. Pero cando comezamos a iteración, resulta que o que realmente se fixo non foi o que se esperaba: o deseñador esqueceu algo, non pensou completamente no comportamento, porque non está no equipo nin no contexto, nin na fronte. -end desenvolvedor non entendeu completamente o deseño. Poden levar varias iteracións só porque hai un problema co que o desenvolvedor front-end entende o deseño.
Ademais hai un problema máis. Os sistemas de deseño están gañando popularidade. Están en exageración, pero os beneficios deles non son totalmente obvios.
Atopo a opinión de que os sistemas de deseño, por unha banda, simplifican o desenvolvemento, pero, por outra banda, impoñen moitas restricións á interface.
Como resultado, non facemos a función que quere o cliente, senón a que nos convén, porque xa temos certos cubos dos que podemos facelo.
Creo que este é un tema ao que vale a pena botarlle unha ollada e preguntarnos se ao tratar de facilitar o deseño estamos a resolver un problema do cliente.
— Hai un número sorprendente de temas relacionados coa Garantía de Calidade. Hai unha conferencia en Rusia onde se poidan discutir todas elas?
Анастасия: Existe a conferencia de probas máis antiga, que se celebrará por 25ª vez este ano e chámase SQA Days Quality Assurance Conference. Analiza principalmente ferramentas e enfoques de proba específicos para probadores funcionais. Como regra xeral, os informes dos SQA Days examinan en profundidade áreas específicas na área de responsabilidade dos propios probadores, pero non actividades complexas.
Isto axuda moito a comprender diferentes ferramentas e enfoques, como probar bases de datos, API, etc. Pero ao mesmo tempo, por unha banda, non motiva a implicar máis que probar na creación dun mellor produto. Por outra banda, os probadores non se involucran máis no proceso para pensar no obxectivo global do produto e no seu compoñente de negocio.
Dirixo un gran departamento e realizo moitas entrevistas que realmente proporcionan información sobre o estado da industria no seu conxunto. Como regra xeral, os nosos mozos traballan en empresas e teñen unha clara área de responsabilidade. Os compañeiros que traballan en proxectos estranxeiros usan diferentes tipos de probas: eles mesmos poden facer probas de carga, probas de rendemento e mesmo ás veces probas de seguridade, porque realmente axudan ao equipo a garantir a calidade do produto.
Gustaríame que os mozos de Rusia tamén empecen a pensar que a industria non remata coas probas funcionais.
— Para iso, organizamos unha nova xornada, QualityConf, dedicada á calidade como disciplina integral. Fálanos máis da idea, cal é o principal obxectivo das xornadas?
Анастасия: Queremos crear unha comunidade de persoas interesadas en facer produtos de calidade. Ofrecer unha plataforma onde poidan vir, escoitar informes e saír despois da conferencia cunha comprensión específica do que hai que cambiar para mellorar a calidade.
Hoxe en día escoito moitas veces unha solicitude de consultoría sobre que facer cando hai problemas coas probas e a calidade. Cando comezas a comunicarte cos equipos, ves que o problema non está nos propios probadores, senón en como se estrutura o proceso. Por exemplo, cando os desenvolvedores cren que só son responsables de escribir código, a súa responsabilidade remata exactamente no momento en que entregan a tarefa á proba.
Non todos pensan no feito de que un código mal escrito e de baixa calidade cunha arquitectura deficiente ameaza con grandes problemas para o proxecto. Non pensan no custo dos erros, que os erros que acaban na produción poden supoñer grandes custos para a empresa e o equipo. Non hai cultura para pensar nisto. Quero que empecemos a distribuílo na conferencia.
Entendo que isto non é unha innovación.Edward Deming, o autor dos 14 principios da calidade, escribiu sobre o custo dun erro no século pasado. A garantía de calidade como disciplina baséase neste libro, pero, por desgraza, o desenvolvemento moderno esquécese del.
— Pensas tocar directamente temas sobre probas e ferramentas?
Анастасия: Recoñezo que haberá informes sobre ferramentas. Existen ferramentas bastante universais coas que as empresas e os equipos poden influír no produto.
Todos os informes estarán unidos globalmente por unha misión común: transmitir á audiencia que coa axuda deste enfoque, ferramenta, método, proceso, tipo de proba, influímos na calidade do produto e melloramos a vida do cliente.
Definitivamente non teremos informes sobre unha ferramenta por unha ferramenta. Todos os informes incluídos no programa estarán unidos por un obxectivo común.
— ¿A quen lle interesará o que fala, a quen ves como convidado ao congreso?
Анастасия: Teremos informes para desenvolvedores que se preocupan polo destino do seu proxecto, produto, sistema. Así mesmo, será de interese para os probadores e, a min paréceme, sobre todo para os directivos. Por xestores, refírome ás persoas que toman decisións e que tamén poden influír no destino e desenvolvemento dun produto, sistema ou equipo.
Son persoas que se preguntan como mellorar a calidade dun produto ou sistema. Na nosa conferencia, aprenderán sobre varios conxuntos de medidas e poderán comprender o que lles pasa agora e o que hai que cambiar.
Creo que o criterio principal é entender que algo está mal coa calidade e querer influír nela. Probablemente non poderemos chegar a persoas que pensen que isto vai facer só a primeira vez.
— Cres que a industria no seu conxunto está madura para falar non só de probas, senón de cultura da calidade?
Анастасия: Creo que madurei. Agora moitas empresas están a afastarse do enfoque tradicional de Waterfall cara a Agile. Hai un enfoque no cliente, as persoas dos equipos realmente están empezando a pensar en como crear un produto de calidade. Incluso as empresas empresariais están a centrarse de novo na mellora da calidade.
A xulgar pola cantidade de solicitudes que están xurdindo na comunidade, creo que é o momento. Non estou seguro, por suposto, de que esta vaia ser unha revolución a gran escala, pero gustaríame que esta revolución na conciencia ocorrese.
- De acordo! Inculcaremos cultura e cambiaremos a conciencia.
Xornada sobre o desenvolvemento de produtos informáticos de alta calidade terá lugar en Moscova o 7 de xuño. Xa sabes cales son as fases que conforman un produto de alta calidade, temos casos de loita contra erros na produción, probamos métodos populares na nosa práctica - necesitamos a túa experiencia. seu solicitudes antes do 1 de maio, e o Comité do Programa axudará a centrar o tema para a integridade xeral da conferencia.
Conectar a , na que discutimos cuestións de calidade e a conferencia, subscríbete para estar ao día das novidades do programa.
Fonte: www.habr.com