Oi, Habr!
Temos um novo tópico importante - o desenvolvimento de produtos de TI de alta qualidade. No HighLoad++ frequentemente falamos sobre como agilizar serviços ocupados, e no Frontend Conf falamos sobre uma interface de usuário legal que não fica lenta. Regularmente temos tópicos sobre testes e DevOpsConf sobre como combinar diferentes processos, incluindo testes. Mas não há nada sobre o que pode ser chamado de qualidade em geral e como trabalhar nisso de forma abrangente.
Vamos consertar isso — desenvolveremos uma cultura de pensamento na qualidade do produto final para o usuário em todas as fases do desenvolvimento. O hábito de não focar na sua área de responsabilidade, e associar qualidade não só aos testadores.
Abaixo do corte conversaremos com o chefe do comitê do programa, chefe de testes da Tinkoff.Business, criador da comunidade de controle de qualidade de língua russa Anastasia Aseeva-Nguyen sobre o estado da indústria de controle de qualidade e a missão da nova conferência.
- Nastya, olá. Por favor, conte-nos sobre você.
Anastasia: Gerencio testes em um banco, sou responsável por uma equipe muito grande – somos mais de 90 pessoas. Temos uma importante linha de negócios, somos responsáveis pelo ecossistema das pessoas jurídicas.
Estudei mecânica e matemática e inicialmente queria me tornar programador. Mas quando recebi uma oferta interessante, decidi tentar ser testador. Curiosamente, essa acabou sendo minha vocação. Agora vejo todo o meu trabalho nesta indústria.
Sou um fervoroso adepto da disciplina de Garantia de Qualidade. Não sou indiferente aos produtos que são criados, à forma como a qualidade é tratada na empresa, na equipa e, em princípio, no processo de desenvolvimento.
É óbvio para mim que a comunidade nesta direção não está madura o suficiente, pelo menos na Rússia. Nem sempre entendemos que a garantia de qualidade não é apenas o fato de testar uma aplicação quanto à conformidade com os requisitos. Eu gostaria de mudar esta situação.
— Você usa as palavras Garantia de Qualidade e testes. Aos olhos da pessoa média, estes dois termos muitas vezes se sobrepõem. Como eles diferem se você cavar fundo?
Anastasia: Pelo contrário, eles não são diferentes. O teste faz parte da disciplina de Garantia de Qualidade; é uma atividade direta – o próprio fato de estar testando algo. Na verdade, existem muitos tipos de testes e várias pessoas são responsáveis por diferentes tipos de testes. Mas aqui na Rússia, quando surgiu uma onda de terceirizadores que fornecem testadores para empresas, os testes foram reduzidos a um único tipo.
Na maioria dos casos, eles se limitam apenas a testes funcionais: verificam se o que os desenvolvedores codificaram está em conformidade com as especificações e pronto.
— Por favor, diga-nos quais outras disciplinas de garantia de qualidade existem? O que mais, além dos testes, está incluído aqui?
Anastasia: A Garantia de Qualidade trata, antes de tudo, de criar um produto de qualidade. Ou seja, nos perguntamos quais atributos de qualidade nosso produto deve ter. Assim, se entendermos isso, poderemos comparar quem influencia esses atributos de qualidade. Não importa, desenvolvedor, gerente de projeto ou especialista em produto é uma pessoa que influencia o desenvolvimento de um produto, seu backlog e sua estratégia.
O testador fica mais consciente de seu papel. Ele entende que sua tarefa não é apenas testar o cumprimento dos requisitos, mas também testar os requisitos, questionar as formulações que vêm do especialista do produto e revelar todos os requisitos e expectativas implícitas do cliente. Quando entregamos novas funcionalidades ao nosso cliente, devemos realmente atender às suas expectativas e solucionar suas dores. Se pensarmos em todos os atributos de qualidade, o cliente ficará satisfeito e entenderá que a empresa cujo produto ele utiliza realmente se preocupa com seus interesses, e não trabalha segundo o princípio de “só para lançar uma feature”.
— Parece que o que você acabou de descrever é tarefa de um especialista em produto. Em princípio, não se trata de testes e nem de qualidade - geralmente se trata de gerenciamento de produtos, não?
Anastasia: Incluindo. A Garantia de Qualidade não é uma disciplina pela qual uma pessoa específica é responsável. Agora existe uma direção popular em testes, uma abordagem chamada Teste Ágil. Sua definição afirma claramente que esta é uma abordagem de equipe para testes, que inclui um determinado conjunto de práticas. Toda a equipe é responsável pela implementação dessa abordagem, nem é necessário que haja um testador na equipe. Toda a equipe está focada em entregar valor ao cliente e garantir que o valor atenda às expectativas do cliente.
— Acontece que a qualidade se cruza com quase todas as disciplinas vizinhas, impondo uma estrutura a tudo ao seu redor?
Anastasia: Certo. Quando pensamos em como queremos criar um produto de qualidade, começamos a pensar nos diversos atributos da qualidade. Por exemplo, como verificar se realmente fizemos o recurso que nosso cliente precisa.
É aqui que entra esse tipo de teste: UAT (Testes de aceitação do usuário). Infelizmente, isso raramente é praticado na Rússia, mas às vezes está presente nas equipes SCRUM como uma demonstração para o cliente final. Este é um tipo de teste bastante comum em empresas estrangeiras. Antes de abrir a funcionalidade para todos os clientes, primeiro fazemos o UAT, ou seja, convidamos o usuário final que testa e imediatamente dá feedback – se o produto realmente atende às expectativas e resolve as dores. Somente depois disso ocorre o dimensionamento para todos os outros clientes.
Ou seja, focamos no negócio, no cliente final, mas ao mesmo tempo não se esqueça da tecnologia. A qualidade do produto também depende muito da tecnologia. Se tivermos uma arquitetura ruim, não conseguiremos liberar recursos rapidamente e atender às expectativas dos clientes. Pode haver muitos bugs ao tentar escalar, ou ao tentar refatorar podemos quebrar alguma coisa. Tudo isso afetará a satisfação do cliente.
Deste ponto de vista, a arquitetura deve ser tal que possamos escrever um código limpo que nos permita fazer alterações rapidamente e não ter medo de quebrar tudo. Para que as iterações de revisão não se estendam por vários meses simplesmente porque temos muito legado e precisamos fazer longos estágios de testes.
— No total, desenvolvedores, arquitetos, cientistas de produto, gerentes de produto e os próprios testadores já estão envolvidos. Quem mais está envolvido no processo de garantia de qualidade?
Anastasia: Agora vamos imaginar que já entregamos o recurso ao cliente. Obviamente, a qualidade do produto precisa ser monitorada mesmo quando já está em produção. Nesta fase podem surgir situações com cenários não óbvios, os chamados bugs.
A primeira pergunta é como lidaremos com esses bugs depois de já termos lançado o produto? Como reagimos, por exemplo, ao estresse? O cliente não ficará muito satisfeito se a página demorar mais de 30 segundos para carregar.
É aqui que entra em jogo a exploração ou, como lhe chamam agora, DevOps. Na verdade, essas são as pessoas responsáveis pela operação do produto quando ele já está em produção. Isso inclui vários tipos de monitoramento. Existe até um subtipo de teste - teste em produção, quando nos permitimos não testar algo antes do lançamento e testá-lo imediatamente na produção. Trata-se de um conjunto de medidas do ponto de vista da organização da infraestrutura que permitem responder rapidamente a um incidente, influenciá-lo e corrigi-lo.
A infraestrutura também é importante. Muitas vezes há situações em que, durante um teste, é impossível ter a certeza de que realmente temos tudo o que gostaríamos de dar ao cliente. Nós o colocamos em produção e começamos a detectar situações não óbvias. E tudo porque a infraestrutura em teste não corresponde à infraestrutura em produção. Isto leva a um novo tipo de teste - testes de infraestrutura. Estas são várias configurações, configurações, migração de banco de dados, etc.
Isso levanta a questão: talvez a equipe precise usar infraestrutura como código.
Acredito que a infraestrutura afeta diretamente a qualidade do produto.
Espero que haja um relatório na conferência com um caso real. Escreva-nos se estiver pronto para nos contar, por experiência própria, como a infraestrutura como código afeta a qualidade. A infraestrutura como código torna mais fácil verificar todas as configurações e testar coisas que de outra forma simplesmente não seriam possíveis. Portanto, a operação também está envolvida no processo de desenvolvimento de um produto de qualidade.
— E quanto a análises e documentação?
Anastasia: isso se aplica mais a sistemas corporativos. Quando falamos sobre empresa, pessoas como analistas e analistas de sistemas vêm imediatamente à mente. Às vezes são chamados de redatores técnicos. Eles recebem a tarefa de escrever uma especificação e concluí-la, por exemplo, por um mês.
Foi repetidamente comprovado que escrever tal documentação leva a longas iterações de desenvolvimento e longas iterações de refinamento, porque durante o processo de teste os bugs são identificados e os retornos começam. Como resultado, existem muitos ciclos que aumentam os custos de desenvolvimento. Além disso, isso pode introduzir vulnerabilidades. Parece que escrevemos um código de referência, mas depois fizemos alterações que quebram a arquitetura perfeitamente pensada.
O resultado final não é um produto totalmente de alta qualidade, pois já apareceram patches na arquitetura, o código em alguns locais não é suficientemente coberto pelos testes, pois os prazos estão se esgotando, todos os bugs precisam ser resolvidos rapidamente. E tudo porque a especificação original não levou em consideração todos os pontos que precisam ser implementados.
Os desenvolvedores não são pragas e não escrevem códigos com erros propositalmente.
Se tivéssemos inicialmente pensado em uma especificação que cobrisse todos os pontos necessários, então tudo teria sido implementado exatamente como necessário. Mas isso é uma utopia.
Provavelmente é impossível escrever uma especificação perfeita de 100 páginas. É por isso precisa pensar em formas alternativas de escrever documentação, especificações, definindo tarefas que nos aproximariam de garantir que o desenvolvedor faça exatamente o que é necessário.
Aqui vêm à mente abordagens do Agile - histórias de usuários com critérios de aceitação. Isso é mais aplicável para equipes que desenvolvem em pequenas iterações.
— E quanto aos testes de usabilidade, usabilidade do produto, design?
Anastasia: Esse é um ponto muito importante, pois há designers na equipe. Na maioria das vezes, os designers são usados como um serviço - seja por um departamento de design ou por um designer terceirizado. Muitas vezes há situações em que parece que o designer ouviu o especialista do produto e fez o que entendeu. Mas quando iniciamos a iteração, verifica-se que o que realmente foi feito não foi o esperado: o designer esqueceu algo, não pensou bem no comportamento, porque ele não está na equipe e nem no contexto, ou na frente -O desenvolvedor final não entendeu completamente o layout. Podem ser necessárias várias iterações apenas porque há um problema com o desenvolvedor front-end na compreensão do design.
Além disso, há mais um problema. Os sistemas de design estão ganhando popularidade agora. Eles estão na moda, mas os benefícios deles não são totalmente óbvios.
Me deparo com a opinião de que os sistemas de design, por um lado, simplificam o desenvolvimento, mas, por outro lado, impõem muitas restrições à interface.
Com isso, não fazemos a funcionalidade que o cliente deseja, mas sim aquela que nos é conveniente, pois já temos alguns cubos com os quais podemos fazer.
Acho que vale a pena dar uma olhada neste tópico e nos perguntar se, ao tentar tornar o design mais fácil, estamos realmente resolvendo um problema do cliente.
— Há um número surpreendente de tópicos relacionados à Garantia de Qualidade. Existe uma conferência na Rússia onde todos eles possam ser discutidos?
Anastasia: Existe a conferência de testes mais antiga, que será realizada pela 25ª vez este ano e é chamada de Conferência de Garantia de Qualidade do SQA Days. Discute principalmente ferramentas e abordagens de teste específicas para testadores funcionais. Via de regra, os relatórios do SQA Days examinam profundamente áreas específicas da área de responsabilidade dos próprios testadores, mas não atividades complexas.
Isso ajuda muito no entendimento de diferentes ferramentas e abordagens, como testar bancos de dados, APIs, etc. Mas, ao mesmo tempo, por um lado, não motiva envolver mais do que apenas testes na criação de um produto melhor. Por outro lado, os testadores não se envolvem mais no processo para pensar no objetivo global do produto e no seu componente de negócio.
Dirijo um grande departamento e conduzo muitas entrevistas que realmente fornecem informações sobre o estado da indústria como um todo. Via de regra, nossos colaboradores trabalham em empresas e têm uma área de responsabilidade clara. Colegas que trabalham em projetos estrangeiros utilizam diferentes tipos de testes: eles próprios podem fazer testes de carga, testes de desempenho e às vezes até testes de segurança, porque realmente ajudam a equipe a garantir a qualidade do produto.
Gostaria que o pessoal da Rússia também começasse a pensar que a indústria não termina com testes funcionais.
— Para isso, estamos organizando uma nova conferência, QualityConf, que é dedicada à qualidade como disciplina integral. Conte-nos mais sobre a ideia, qual é o objetivo principal da conferência?
Anastasia: Queremos criar uma comunidade de pessoas interessadas em fabricar produtos de qualidade. Ofereça uma plataforma onde eles possam vir, ouvir os relatórios e sair após a conferência com uma compreensão específica do que precisa ser mudado para melhorar a qualidade.
Hoje em dia ouço frequentemente uma solicitação de consultoria sobre o que fazer quando há problemas de testes e qualidade. Ao começar a se comunicar com as equipes, você percebe que o problema não está nos testadores em si, mas na forma como o processo está estruturado. Por exemplo, quando os desenvolvedores acreditam que são responsáveis apenas por escrever o código, sua responsabilidade termina exatamente no momento em que entregam a tarefa para teste.
Nem todo mundo pensa no fato de que código mal escrito e de baixa qualidade com arquitetura ruim ameaça grandes problemas para o projeto. Eles não pensam no custo dos erros, que bugs que vão parar na produção podem resultar em grandes custos para a empresa e para a equipe. Não há cultura para pensar sobre isso. Quero que comecemos a distribuí-lo na conferência.
Entendo que isto não é uma inovação. Edward Deming, o autor dos 14 princípios da qualidade, escreveu sobre o custo de um erro no século passado. A Garantia de Qualidade como disciplina baseia-se neste livro, mas, infelizmente, o desenvolvimento moderno esquece-se dele.
— Você planeja abordar diretamente tópicos sobre testes e ferramentas?
Anastasia: Admito que haverá relatos sobre ferramentas. Existem ferramentas bastante universais com as quais empresas e equipes podem influenciar o produto.
Todos os relatórios serão globalmente unidos por uma missão comum: transmitir ao público que com a ajuda desta abordagem, ferramenta, método, processo, tipo de teste, influenciamos a qualidade do produto e melhoramos a vida do cliente.
Definitivamente não teremos relatórios sobre uma ferramenta só por ser uma ferramenta. Todos os relatórios incluídos no programa estarão unidos por um objetivo comum.
— Quem se interessará pelo que você está falando, quem você vê como convidados da conferência?
Anastasia: Teremos relatórios para desenvolvedores que se preocupam com o destino de seu projeto, produto, sistema. Da mesma forma, será do interesse dos testadores e, parece-me, especialmente dos gestores. Por gerentes, quero dizer pessoas que tomam decisões e também podem influenciar o destino e o desenvolvimento de um produto, sistema e equipe.
São pessoas que se perguntam como melhorar a qualidade de um produto ou sistema. Na nossa conferência, eles aprenderão sobre vários conjuntos de medidas e serão capazes de compreender o que está errado com eles agora e o que precisa ser mudado.
Acho que o principal critério é entender que algo está errado com a qualidade e querer influenciar isso. Provavelmente não seremos capazes de alcançar pessoas que pensam que isso só acontecerá na primeira vez.
— Você acha que a indústria como um todo está madura para falar não apenas sobre testes, mas sobre uma cultura de qualidade?
Anastasia: Acho que amadureci. Agora, muitas empresas estão se afastando da abordagem tradicional em cascata em direção ao Agile. Há um foco no cliente, as pessoas nas equipes estão realmente começando a pensar em como criar um produto de qualidade. Até mesmo as empresas estão se concentrando novamente na melhoria da qualidade.
A julgar pela quantidade de solicitações que estão surgindo na comunidade, acredito que é a hora. Não tenho certeza, é claro, de que esta será uma revolução em grande escala, mas gostaria que esta revolução na consciência acontecesse.
- Acordado! Vamos incutir cultura e mudar a consciência.
Conferência sobre desenvolvimento de alta qualidade de produtos de TI mantido em Moscou em 7 de junho. Você sabe quais etapas constituem um produto de alta qualidade, temos casos de combate bem-sucedido a bugs em produção, testamos métodos populares em nossa prática - precisamos da sua experiência. seu inscrições antes de 1º de maio, e o Comitê do Programa ajudará a focar o tema para a integridade geral da conferência.
Conectar a , em que discutimos questões de qualidade e a conferência, subscrevemos para ficar por dentro das novidades do programa.
Fonte: habr.com