Olá Habr!
Temos um novo tópico importante - desenvolvimento de alta qualidade de produtos de TI. Costumamos falar no HighLoad ++ sobre como agilizar os serviços carregados e no Frontend Conf - uma interface de usuário interessante que não fica lenta. Temos regularmente tópicos sobre testes e o DevOpsConf sobre a combinação de diferentes processos, incluindo testes. Mas sobre como a qualidade pode ser chamada como um todo e como trabalhar com isso de maneira abrangente, não.
Vamos corrigi- lo no
QualityConf - desenvolveremos uma cultura de pensamento sobre a qualidade do produto final para o usuário em cada estágio do desenvolvimento. O hábito de não ficar preso na sua área de responsabilidade e associar a qualidade não apenas aos testadores.
Debaixo do corte, conversaremos com o chefe do comitê do programa, o chefe de testes da Tinkoff
Business , o criador da comunidade de controle de qualidade que fala russo
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, fale sobre você.
Anastasia : Eu lidero os testes no banco, sou responsável por uma equipe muito grande - somos mais de 90. Temos uma importante linha de negócios, somos responsáveis pelo ecossistema de pessoas jurídicas.
Estudei no mehmat e inicialmente queria me tornar um programador. Mas quando tive uma oferta interessante, decidi me testar como testador. Curiosamente, esse acabou sendo meu chamado. Agora eu vejo todo o meu trabalho nesta indústria.
Sou um fervoroso adepto da disciplina de Garantia da Qualidade. Não ligo para quais produtos são criados, como eles se relacionam com a qualidade na empresa, na equipe e, em princípio, no processo de desenvolvimento.
É óbvio para mim que a
comunidade nessa direção não está madura o suficiente , pelo menos na Rússia. Nem sempre entendemos que garantia de qualidade não é apenas o fato de testar um aplicativo quanto à conformidade com os requisitos. Eu gostaria de mudar esta situação.
- Você usa as palavras Garantia de qualidade e teste. Aos olhos do homem comum, esses dois termos muitas vezes se cruzam. Como eles diferem se você se aprofundar?Anastasia: Pelo contrário, eles não são diferentes. O teste faz parte da disciplina Garantia da Qualidade; é uma atividade direta - o fato de eu estar testando alguma coisa. Na verdade, existem muitos tipos de teste e pessoas diferentes são responsáveis por diferentes tipos de teste. Mas na Rússia, quando houve uma onda de terceirizados que fornecem testadores para a empresa, os testes foram reduzidos a uma única visualização.
Na maioria dos casos, eles são limitados apenas a testes funcionais: eles verificam se o que os desenvolvedores compilaram atende às especificações e isso é tudo.
- Diga-me, por favor, que outras disciplinas de garantia de qualidade existem? O que mais, além dos testes, inclui?Anastasia : Garantia de Qualidade é, antes de tudo, criar um produto de qualidade. Ou seja, estamos imaginando quais atributos de qualidade nosso produto deve possuir. Assim, se entendermos isso, podemos comparar quem influencia esses atributos de qualidade. Não importa, o
desenvolvedor, gerente de projeto ou gerente de produto é uma pessoa que influencia o desenvolvimento de um produto, sua carteira de pedidos, sua estratégia.
O testador está mais consciente do seu papel. Ele entende que sua tarefa não é apenas testar a conformidade com os requisitos, mas também testar os requisitos, questionar a linguagem que vem do tecnólogo 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 resolver sua dor. Se pensarmos em todos os atributos da qualidade, o cliente ficará satisfeito e entenderá que a empresa cujo produto ele usa realmente se importa com seus interesses e não trabalha com o princípio de "apenas para liberar um recurso".
- Parece que o que você acabou de descrever é tarefa do tecnólogo do produto. Isso, em princípio, não se trata de testes e não de qualidade - geralmente é sobre gerenciamento de produtos, não?Anastasia : Incluindo. A garantia da qualidade não é a disciplina pela qual uma pessoa específica é responsável. Agora, há uma direção popular nos testes, uma abordagem chamada
Teste Ágil . Na sua definição, parece claro que essa é uma abordagem de equipe para testes, que inclui um certo conjunto de práticas. Toda a equipe é responsável por implementar essa abordagem, nem é necessário que um testador esteja na equipe. Toda a equipe está focada em agregar valor ao cliente, e para que esse valor atenda às suas expectativas.
- Acontece que a qualidade se cruza com quase todas as disciplinas circundantes, impondo uma estrutura a tudo ao redor?Anastasia : Certo. Quando pensamos no que queremos criar um produto de qualidade, começamos a pensar nos vários atributos da qualidade. Por exemplo, como verificar se realmente criamos um recurso que nosso cliente precisa.
Esse tipo de teste é exibido como
UAT (teste de aceitação do usuário). Infelizmente, na Rússia, raramente é praticado, mas às vezes está presente nas equipes do SCRUM, como uma demonstração para o cliente final. Em empresas estrangeiras, esse é um tipo bastante comum de teste. Antes de abrir a funcionalidade para todos os clientes, primeiro criamos o UAT, ou seja, convidamos o usuário final que realiza os testes e imediatamente fornece feedback - o produto realmente atende às expectativas e resolve a dor. Somente depois disso é a escala para todos os outros clientes.
Ou seja, nos concentramos nos negócios, no cliente final, mas ao mesmo tempo
não esquecemos 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 do cliente. Pode haver muitos erros ao tentar escalar ou ao refatorar, podemos quebrar alguma coisa. Tudo isso afetará a satisfação do cliente.
Desse 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 refinamento não sejam estendidas por vários meses, simplesmente porque temos muitos legados e precisamos fazer longas etapas de teste.
- No total, desenvolvedores, arquitetos, especialistas em produtos, gerentes de produtos e testadores já estão envolvidos. Quem mais está envolvido no processo de garantia de qualidade?Anastasia : Agora imagine que já entregamos um recurso a um cliente. Obviamente, você precisa monitorar a qualidade do produto e quando ele já está em produção. Nesse estágio, situações com cenários não óbvios, os chamados bugs, podem aparecer.
A primeira pergunta é como trabalhamos com esses bugs após o lançamento do produto? Como, por exemplo, reagimos à carga? O cliente não ficará muito satisfeito se a página carregar por mais de 30 segundos.
É aqui
que a exploração ou, como chamam agora, o
DevOps entra em jogo. De fato, essas pessoas são responsáveis pela operação do produto quando ele já está à venda. Isso inclui vários tipos de monitoramento. Existe até um subtipo de teste - teste no produto, quando nos permitimos não testar algo antes de lançá-lo e testá-lo imediatamente no produto. Essa é uma série de medidas, do ponto de vista da organização da infraestrutura, que permitem responder rapidamente a um incidente, influenciá-lo e corrigi-lo.
Infraestrutura também é importante. Muitas vezes, há situações em que durante o teste é impossível garantir que realmente tenhamos tudo o que gostaríamos de dar ao cliente. Nós lançamos o produto - e começamos a pegar situações não óbvias. E tudo porque a infraestrutura no teste não corresponde à infraestrutura no prod. Isso leva a um novo tipo de teste -
teste 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 a infraestrutura como código.
Acredito que a infraestrutura afeta diretamente a qualidade do produto.
Espero que a conferência tenha um relatório com um caso real. Escreva-nos se você estiver pronto para contar, por sua própria experiência, como a infraestrutura como código afeta a qualidade. A infra-estrutura como um código facilita a verificação de todas as configurações e o teste de algo que, de outra forma, é simplesmente impossível. Portanto, a exploração também está envolvida no processo de desenvolvimento de um produto de qualidade.
- E quanto à análise e documentação?Anastasia : Isso se aplica mais aos sistemas corporativos. Quando falamos de empresa, pessoas como analistas e analistas de sistemas imediatamente vêm à mente. Às vezes são chamados de escritores técnicos. Eles recebem uma tarefa para escrever uma especificação e concluí-la, por exemplo, um mês.
Foi provado repetidamente que escrever essa documentação leva a longas iterações de desenvolvimento e longas iterações de refinamento, porque durante o processo de teste são detectados erros, os retornos começam. Como resultado, existem muitos loops que aumentam o custo do desenvolvimento. Além disso, isso pode introduzir vulnerabilidades. Parece que escrevemos o código de referência, mas fizemos alterações que quebram a arquitetura perfeitamente pensada.
O resultado é um produto de qualidade não tão alta, porque os patches já apareceram na arquitetura, em alguns locais o código não é suficientemente coberto pelos testes, porque os prazos estão se esgotando, é preciso fechar todos os bugs mais rapidamente. E tudo porque na especificação original todos os pontos que precisam ser implementados não foram levados em consideração.
Os desenvolvedores não são pragas e não escrevem código especificamente com erros.
Se inicialmente pensássemos em uma especificação na qual todos os pontos necessários seriam abordados, tudo seria implementado exatamente como deveria. Mas isso é utopia.
Provavelmente é impossível escrever uma especificação perfeita de 100 páginas. Portanto,
precisamos pensar em maneiras alternativas de escrever documentação , especificar, definir tarefas que nos aproximem do fato de que o desenvolvedor faz exatamente o que precisamos.
A seguir, abordagens ágeis - histórias de usuários com critérios de aceitação. Isso é mais aplicável a equipes que se desenvolvem em pequenas iterações.
- E os testes de usabilidade, usabilidade do produto, design?Anastasia : Esse é um ponto muito importante, porque há designers na equipe. Na maioria das vezes, os designers o usam como um serviço - seja o departamento de design ou o designer terceirizado. Muitas vezes, há situações em que o designer parece ter ouvido o tecnólogo do produto e fez o que ele entendeu. Mas quando começamos a iteração, acontece que o que não era realmente esperado foi feito: o designer esqueceu algo, não pensou no comportamento porque ele não estava na equipe ou no contexto, ou o desenvolvedor front-end não entendeu completamente layout. Pode levar várias iterações apenas porque há um problema com o entendimento do design pelo desenvolvedor front-end.
Além disso, há outro problema. Os sistemas de design estão ganhando popularidade. Eles estão no hype, mas os benefícios deles não são totalmente óbvios.
Sou de opinião que os sistemas de design, por um lado, simplificam o desenvolvimento e, por outro, impõem muitas restrições à interface.
Como resultado, não criamos um recurso que o cliente deseja receber, mas um que seja conveniente para nós, porque já temos certos cubos dos quais podemos fazê-lo.
Parece-me que você deve prestar atenção a este tópico e pensar se realmente solucionamos a dor do cliente na tentativa de simplificar o trabalho no design.
- Surpreendentemente, muitos tópicos relacionados à garantia da qualidade. Existe uma conferência na Rússia na qual todos eles podem ser discutidos?Anastasia : Existe a mais antiga conferência de testes, que será realizada pela 25ª vez este ano e é chamada de SQA Days Quality Assurance Conference. Ele discute principalmente ferramentas e abordagens de teste específicas para testadores funcionais. Como regra, os relatórios do SQA Days examinam profundamente áreas específicas na área de responsabilidade dos testadores, mas não eventos complexos.
Ajuda muito a entender várias ferramentas e abordagens, como testar bancos de dados, APIs etc. Mas, ao mesmo tempo, por um lado, não motiva envolver não apenas testes na criação de um produto melhor. Por outro lado, os testadores não se envolvem mais no processo para pensar sobre a meta global do produto e seu componente de negócios.
Lidero um departamento grande, conduzo muitas entrevistas, que de fato nos permitem apresentar o estado da indústria como um todo. Como regra, nossos funcionários trabalham na empresa e têm uma área de responsabilidade clara. Os colegas que trabalham em projetos estrangeiros usam diferentes tipos de testes: eles mesmos podem realizar testes de carga, desempenho e, às vezes, testes de segurança, porque realmente ajudam a equipe a fornecer qualidade ao produto.
Eu gostaria que nossos funcionários na Rússia também começassem a pensar que o setor não termina com testes funcionais.
- Para isso, estamos organizando uma nova conferência QualityConf, que é dedicada à qualidade como uma disciplina holística. Conte-nos mais sobre a idéia, qual é o principal objetivo da conferência?Anastasia : Queremos criar uma comunidade de pessoas interessadas em criar produtos de qualidade. Ofereça uma plataforma na qual eles possam vir, ouvir relatórios e sair após a conferência com um entendimento concreto do que precisa ser alterado em seu lugar para melhorar a qualidade.
Muitas vezes, agora ouço um pedido de consultar o que fazer quando há problemas com testes, com qualidade. Quando você começa a conversar com as equipes, percebe que o problema não está nos próprios testadores, mas na maneira como o processo é construído. Por exemplo, quando os desenvolvedores acreditam que são responsáveis apenas pela escrita do código, sua responsabilidade termina exatamente no momento em que transferiram a tarefa para o teste.
Nem todo mundo pensa que um código de baixa qualidade, mal escrito e com arquitetura ruim apresenta grandes problemas para o projeto. Não pense no custo dos erros, pois os erros que entraram em produção podem resultar em grandes custos para a empresa e a equipe. Nenhuma cultura para pensar sobre isso. Quero que comecemos a distribuí-lo na conferência.
Entendo que isso não é uma inovação. Edward Deming, autor de 14 postulados de qualidade, escreveu sobre o custo do erro no século passado. Este livro é baseado na garantia da qualidade como disciplina, mas, infelizmente, o desenvolvimento moderno se esquece disso.
- Você planeja abordar tópicos diretamente sobre testes e ferramentas?Anastasia : Admito que haverá relatórios sobre as ferramentas. Existem ferramentas bastante universais pelas quais empresas e equipes podem influenciar um produto.
Todos os relatórios serão globalmente unidos por uma missão comum: transmitir ao público que, com essa 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 a ferramenta em benefício da ferramenta. Todos os relatórios que se enquadram no programa serão unidos por um objetivo comum.
- Quem estará interessado no que você está falando, a quem você vê como convidados da conferência?Anastasia : Teremos relatórios para desenvolvedores que não são indiferentes ao destino de seu projeto, produto, sistema. Será igualmente interessante para testadores e, parece-me, especialmente para gerentes. Por gerentes, quero dizer pessoas que tomam decisões e podem influenciar o destino e o desenvolvimento de um produto, sistema e equipe também.
São pessoas que estão se perguntando como melhorar a qualidade de um produto, sistema. Em nossa conferência, eles aprenderão sobre vários complexos de eventos e serão capazes de entender o que não está certo com o que precisa ser mudado.
Eu acho que o principal critério é entender que algo está errado com a qualidade e quero influenciá-lo. Provavelmente, a primeira vez que alcançar pessoas que acreditam que isso funcionará, não teremos sucesso.
- Você acha que a indústria como um todo amadureceu para falar não apenas sobre testes, mas sobre uma cultura de qualidade?Anastasia : Eu acho que amadureci. Agora, muitas empresas estão se afastando da abordagem tradicional do Waterfall para o Agile. Há um foco no cliente, as pessoas nas equipes estão realmente começando a pensar em como criar um produto de qualidade. Mesmo nas empresas, há uma reorientação para melhorar a qualidade.
A julgar pelo número de consultas que surgem na comunidade, acredito que está na hora. Não tenho certeza, é claro, de que será uma revolução em larga escala, mas gostaria que essa mudança de consciência acontecesse.
- Concordo! Instilaremos uma cultura e transformaremos a mente.Uma conferência sobre o desenvolvimento da qualidade dos produtos de TI da QualityConf será realizada em Moscou, em 7 de junho . Você sabe, desde que estágio um produto de alta qualidade é composto, existem casos em estoque para lidar com êxito com os bugs no produto, testamos técnicas populares em nossa prática - precisamos da sua experiência. Envie suas inscrições até 1º de maio , e o Comitê de Programa ajudará a concentrar o tópico na integridade geral da conferência.
Conecte-se a um bate - papo no qual discutimos questões de qualidade e a uma conferência, assine o canal Telegram para acompanhar as notícias do programa.