Olá, Habr!
Temos um novo tema importante - o desenvolvimento de produtos de TI de qualidade. Frequentemente falamos em HighLoad++ sobre como tornar serviços sobrecarregados rápidos, e na Frontend Conf sobre interfaces de usuário excelentes que não travam. Temos regularmente discussões sobre testes e no DevOpsConf sobre a integração de diversos processos, incluindo testes. Mas sobre o que pode ser chamado de qualidade como um todo, e como trabalhar de forma abrangente nisso - não há.
Vamos corrigir isso para - vamos cultivar a cultura de pensar na qualidade do produto final para o usuário em cada estágio do desenvolvimento. O hábito de não se restringir à sua zona de responsabilidade e associar qualidade não apenas com os testadores.
No post abaixo, conversaremos com a presidente do comitê de programação, chefe de testes do Tinkoff.Banco, criadora da comunidade QA de língua russa Anastasia Aseeva-Nguen sobre o estado da indústria de QA e a missão da nova conferência.
- Olá, Nastya. Fale um pouco sobre você, por favor.
Anastasia: Eu gerencio os testes no banco, sou responsável por uma equipe muito grande - temos mais de 90 pessoas. Temos uma linha de negócios importante, somos responsáveis pelo ecossistema para pessoas jurídicas.
Eu estudei em mecânica e matemática e inicialmente queria ser programadora. Mas quando surgiu uma proposta interessante, decidi experimentar como testadora. Por mais estranho que pareça, isso se tornou minha vocação. Agora vejo todo o meu trabalho exatamente nessa área.
Sou uma fervorosa defensora da disciplina de Garantia de Qualidade. Não me é indiferente quais produtos estão sendo criados, como a qualidade é tratada na empresa, na equipe e, em princípio, no processo de desenvolvimento.
Para mim, é evidente que a comunidade nessa área é insuficientemente madura, pelo menos na Rússia. Nem sempre entendemos que garantir qualidade não é apenas o fato de testar um aplicativo quanto à conformidade com os requisitos. Gostaria de mudar essa situação.
- Você usa as palavras Garantia de Qualidade e testes. Na visão do público em geral, esses dois termos muitas vezes se sobrepõem. Qual é a diferença entre eles, se aprofundarmos?
Anastasia: Na verdade, eles não se diferenciam. O teste é parte da disciplina de Garantia de Qualidade, é uma atividade direta — o simples fato de que estou testando algo. Existem muitos tipos de testes, e diferentes tipos de testes são responsabilidade de diferentes pessoas. Mas na Rússia, quando surgiu a onda de terceirização que fornece testadores para empresas, o teste se reduziu a um único tipo.
Na maioria dos casos, limita-se apenas à teste funcional: verifica-se se o que os desenvolvedores codificaram está de acordo com a especificação e pronto.
— Fale, por favor, sobre quais outras disciplinas de garantia de qualidade existem? O que mais, além de testes, está incluído aqui?
Anastasia: Garantia de Qualidade é, antes de tudo, sobre a criação de um produto de qualidade. Ou seja, nos perguntamos quais atributos de qualidade nosso produto deve ter. Assim, se entendemos isso, podemos correlacionar quem influencia esses atributos de qualidade. Não importa, se é um desenvolvedor, gerente de projeto ou gerente de produto — é a pessoa que influencia o desenvolvimento do produto, seu backlog e sua estratégia.
O testador começa a perceber melhor seu papel. Ele entende que sua tarefa não é apenas testar a conformidade com os requisitos, mas também testar os requisitos, questionar as formulações que vêm do gerente de produto, revelar todos os requisitos implícitos e expectativas do cliente. Quando fornecemos uma nova funcionalidade ao nosso cliente, devemos realmente satisfazer suas expectativas e resolver seu problema. Se pensarmos em todos os atributos de qualidade, o cliente ficará satisfeito e entenderá que a empresa cujo produto ele usa realmente se preocupa com seus interesses, e não age apenas com o princípio de "apenas lançar uma funcionalidade".
— Parece que o que você acabou de descrever é uma tarefa do gerente de produto. Isso, em princípio, não é sobre testes e nem sobre qualidade — é sobre gestão de produtos, não é?
Anastasia: Inclusive. Garantia de Qualidade não é uma disciplina da qual apenas uma pessoa específica é responsável. Atualmente, há uma abordagem popular em testes chamada Agile Testing. Sua definição menciona diretamente que é uma abordagem colaborativa para testes, que envolve um conjunto específico de práticas. A responsabilidade pela implementação dessa abordagem é de toda a equipe, mesmo que não seja necessário ter um testador na equipe. Toda a equipe está focada em entregar valor ao cliente e garantir que esse valor corresponda às suas expectativas.
— Então, a qualidade se entrelaça com quase todas as disciplinas ao nosso redor, impondo limites ao que está ao redor?
Anastasia: Correto. Quando pensamos em criar um produto de qualidade, começamos a refletir sobre diversos atributos de qualidade. Por exemplo, como verificar se realmente criamos uma funcionalidade que atenda às necessidades do nosso cliente.
Aqui surge um tipo de teste conhecido como UAT (teste de aceitação do usuário). Infelizmente, na Rússia, ele é raramente praticado, mas às vezes aparece em equipes SCRUM, como uma demonstração para o cliente final. Em empresas estrangeiras, é um tipo de teste bastante comum. Antes de disponibilizar a funcionalidade para todos os clientes, fazemos primeiro o UAT, ou seja, convidamos o consumidor final, que realiza os testes e fornece feedback imediato — se o produto realmente atende às expectativas e resolve o problema. Somente depois disso ocorre a escalabilidade para todos os outros clientes.
Ou seja, nos orientamos pelos negócios, pelo 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 lançar funcionalidades rapidamente e corresponder às expectativas do cliente. Podem surgir muitos bugs ao tentar escalar, ou durante o refatoramento podemos quebrar algo. Tudo isso impacta a satisfação do cliente.
Sob essa perspectiva, a arquitetura deve ser tal que possamos escrever código limpo, que permita realizar alterações rapidamente e sem medo de quebrar tudo. Para que as iterações de melhorias não se estendam por meses, simplesmente porque temos um legado muito grande e precisamos realizar longos testes.
— Portanto, já estão envolvidos desenvolvedores, arquitetos, gerentes de produtos, gerentes de produtos, e os próprios testadores. Quem mais está envolvido no processo de garantia de qualidade?
Anastasia: Agora, vamos imaginar que já entregamos uma funcionalidade ao cliente. É evidente que precisamos monitorar a qualidade do produto, mesmo depois que ele já está em produção. Nessa fase, podem surgir situações com cenários não óbvios, os chamados bugs.
A primeira pergunta é: como lidamos com esses bugs depois que já lançamos o produto? Como reagimos, por exemplo, à carga? O cliente não ficará muito feliz se a página demora mais de 30 segundos para carregar.
Aí entra em cena a operação ou, como agora é chamado, DevOps. Na prática, são pessoas responsáveis pela operação do produto quando ele já está em produção. Isso inclui diversos tipos de monitoramento. Há até um tipo específico de teste — teste em produção, onde nos permitimos não testar algo até o lançamento e testamos isso imediatamente em produção. Trata-se de um conjunto de ações do ponto de vista da organização da infraestrutura, que permite uma rápida resposta a um incidente, influenciar nele e corrigi-lo.
A infraestrutura também é importante. Muitas vezes, há situações em que, durante os testes, não conseguimos garantir que temos tudo o que gostaríamos de oferecer ao cliente. Lançamos em produção — e começamos a encontrar situações não óbvias. E isso acontece porque a infraestrutura nos testes não corresponde à infraestrutura em produção. Daí surge um novo tipo de teste — teste de infraestrutura. Isso inclui várias configurações, ajustes, migrações de banco de dados, etc.
Daí surge a questão — talvez a equipe precise usar infraestrutura como código.
Acredito que a infraestrutura impacta diretamente na qualidade do produto.
Espero que na conferência haja uma apresentação com um caso real. Escreva para nós se estiver disposto a compartilhar, baseado na sua experiência, como a infraestrutura como código impacta na qualidade. A infraestrutura como código facilita a verificação de todas as configurações e permite testar o que, de outra forma, seria simplesmente impossível. Portanto, a operação também está envolvida no processo de desenvolvimento de um produto de qualidade.
— E quanto à análise e documentação?
Anastasia: Isso se refere mais a sistemas empresariais. Quando falamos de enterprise, imediatamente pensamos em pessoas como analistas e analistas de sistemas. Às vezes, são chamados de escritores técnicos. Eles recebem a tarefa de escrever uma especificação e a realizam, por exemplo, em um mês.
Foi comprovado repetidamente que a redação de documentação dessa natureza resulta em longas iterações de desenvolvimento e prolongadas iterações de ajustes, pois no processo de teste surgem bugs, levando a retornos. Como resultado, surgem muitos loops que aumentam os custos de desenvolvimento. Além disso, isso pode introduzir vulnerabilidades. Embora tenhamos aparentemente escrito um código de referência, as mudanças acabaram quebrando uma arquitetura cuidadosamente planejada.
O resultado é um produto de qualidade inferior, pois a arquitetura já possui remendos, e o código em alguns pontos não está suficientemente coberto por testes, já que os prazos estão apertados e precisamos corrigir os bugs rapidamente. E isso tudo porque não foram considerados todos os aspectos necessários na especificação inicial.
Os desenvolvedores não são malfeitores e não escrevem código com erros intencionalmente.
Se tivéssemos planejado a especificação desde o início, cobrindo todos os aspectos necessários, tudo teria sido implementado exatamente como deveria. Mas isso é uma utopia.
Provavelmente, é impossível escrever uma especificação ideal de 100 páginas. Portanto, é necessário considerar maneiras alternativas de redigir documentação, especificações e definições de tarefas que nos aproximem de um ponto em que o desenvolvedor faça exatamente o que é necessário.
Aqui, surgem abordagens do Agile — histórias de usuários com critérios de aceitação. Isso é mais aplicável a equipes que evoluem em pequenas iterações.
— E quanto aos testes de usabilidade, à facilidade de uso do produto, ao design?
Anastasia: Este é um ponto muito importante, pois existem designers na equipe. Muitas vezes, os designers são utilizados como um serviço — seja um departamento de design ou um designer terceirizado. Frequentemente, ocorrem situações em que o designer parece ter ouvido o gestor de produto e fez o que entendeu. Mas, quando começamos a iteração, descobre-se que, na verdade, não foi feito o que se esperava: o designer esqueceu de algo, não pensou completamente no comportamento, porque ele não está na equipe e não está no contexto, ou o desenvolvedor front-end não entendeu completamente seu layout. Podem ser necessárias várias iterações apenas devido ao problema de compreensão do design pelo desenvolvedor front-end.
Além disso, existe um outro problema. Atualmente, os sistemas de design estão se tornando populares. Eles estão na moda, mas os benefícios não são tão óbvios.
Encontro 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.
No final, não estamos criando a funcionalidade que o cliente quer, mas sim a que nos é conveniente, porque já temos certos blocos a partir dos quais podemos construí-la.
Acho que vale a pena refletir sobre isso e pensar se, ao tentar facilitar o trabalho no design, estamos realmente resolvendo a dor do cliente.
— Surpreendentemente, existem muitos tópicos relacionados ao Quality Assurance. Há alguma conferência na Rússia onde todos possam discutir isso?
Anastasia: Existe a conferência mais antiga sobre testes, que este ano ocorrerá pela 25ª vez e se chama Conferência sobre Garantia de Qualidade SQA Days. Principalmente, discute-se lá ferramentas e abordagens específicas para testes funcionais. Geralmente, nas apresentações do SQA Days, áreas específicas da responsabilidade dos testadores são abordadas em profundidade, mas não eventos abrangentes.
Isso ajuda bastante a entender as diversas ferramentas e abordagens para testar bancos de dados, APIs etc. No entanto, por um lado, isso não motiva a envolver mais pessoas na criação de um produto de maior qualidade, não apenas os testadores. Por outro lado, os testadores não se tornam mais envolvidos no processo para pensar no objetivo global do produto e em seu aspecto comercial.
Eu lidero um grande departamento, conduzo muitas entrevistas que realmente permitem captar o estado da indústria como um todo. Geralmente, nossos colaboradores trabalham em empresas de grande porte e têm uma área de responsabilidade clara. Colegas que trabalham em projetos internacionais utilizam diferentes tipos de testes: podem realizar 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 aqui na Rússia as pessoas também começassem a pensar que a indústria não se limita apenas ao teste funcional.
— Para isso, estamos organizando a nova conferência QualityConf, que é dedicada à qualidade como uma disciplina integral. Pode nos contar mais sobre a ideia, qual é o principal objetivo da conferência?
Anastasia: Queremos criar uma comunidade de pessoas interessadas em desenvolver produtos de qualidade. Oferecer um espaço onde possam vir, ouvir palestras e sair da conferência com uma compreensão concreta do que precisa mudar para melhorar a qualidade.
Atualmente, ouço frequentemente de consultorias a pergunta sobre o que fazer quando há problemas com testes e qualidade. Ao começar a conversar com as equipes, percebo que o problema não está nos testadores, mas na forma como o processo é estruturado. Por exemplo, quando os desenvolvedores acreditam que são responsáveis apenas pela escrita do código, sua responsabilidade se encerra no momento em que entregam a tarefa para testes.
Nem todos pensam que um código mal escrito e de baixa qualidade com uma arquitetura deficiente pode representar grandes problemas para o projeto. Não se reflete sobre o custo dos erros, sobre o fato de que bugs que entram em produção podem causar grandes custos para a empresa e a equipe. Não há uma cultura que pense sobre isso. Quero que na conferência comecemos a disseminá-la.
Entendo que isso não é uma inovação. Edward Deming, autor dos 14 postulados da qualidade, escreveu sobre o custo do erro ainda no século passado. Este livro é a base da Garantia da Qualidade como disciplina, mas, infelizmente, o desenvolvimento moderno esquece disso.
— E vocês planejam abordar tópicos diretamente relacionados a testes e ferramentas?
Anastasia: Admito que haverá palestras sobre ferramentas. Existem ferramentas bastante universais que as empresas e equipes podem usar para influenciar o produto.
Todas as palestras estarão globalmente unidas por uma missão comum: transmitir ao público que, por meio dessa abordagem, ferramenta, método, processo ou tipo de teste, influenciamos a qualidade do produto e melhoramos a vida do cliente.
Com certeza não teremos palestras sobre ferramentas apenas por conta delas. Todas as palestras que entrarão na programação serão unidas por um objetivo comum.
— Quem se interessaria pelo que você está dizendo, quem você vê como convidados da conferência?
Anastasia: Teremos palestras para desenvolvedores que se preocupam com o futuro de seus projetos, produtos e sistemas. Também será interessante para testadores e, na minha opinião, especialmente para gerentes. Com gerentes, refiro-me a pessoas que tomam decisões e podem influenciar o destino e o desenvolvimento de produtos, sistemas e equipes.
Essas são pessoas que se perguntam como melhorar a qualidade do produto e do sistema. Na nossa conferência, elas aprenderão sobre diversas iniciativas e poderão entender o que está faltando e o que precisa ser alterado.
Acho que o principal critério é entender que algo não está certo com a qualidade e querer influenciar isso. Provavelmente, não conseguiremos alcançar as pessoas que acham que tudo está bem na primeira tentativa.
— O que você acha, a indústria em geral amadureceu para falar não apenas sobre testes, mas sobre a cultura da qualidade?
Anastasia: Eu acredito que sim. Muitas empresas estão se afastando da abordagem Waterfall tradicional em direção ao Agile. Há uma orientação crescente para o cliente, e as pessoas nas equipes realmente começam a pensar em como criar um produto de qualidade. Mesmo em empresas de grande porte, a reorientação para a melhoria da qualidade está ocorrendo.
Pelo número de solicitações que surgem na comunidade, acredito que já é hora. Não tenho certeza de que será uma revolução em grande escala, mas gostaria que essa mudança de pensamento acontecesse.
— Combinado! Vamos cultivar a cultura e transformar a mentalidade.
Conferência sobre desenvolvimento de produtos de TI de qualidade terá em Moscovo, 7 de junho. Você sabe quais etapas compõem um produto de qualidade, temos casos de sucesso na luta contra bugs em produção, testamos em nossa prática metodologias populares – precisamos de sua experiência. suas candidaturas até 1 de maio, e o Comitê de Programação ajudará a focar a temática para a coesão geral da conferência.
Junte-se ao , onde discutimos questões de qualidade e a conferência, inscreva-se em , para ficar por dentro das novidades do programa.
Fonte: habr.com
