Testar em grandes empresas, na empresa, geralmente é uma tarefa complicada e ingrata. A diferença entre as divisões de negócios e a TI é enorme: quando um desenvolvedor tem uma visão no nível do código e uma verificação no nível dos testes de unidade, e o cliente pensa em trabalhar ou não, mesmo que não com serviços, mas com processos inteiros que vão além de uma equipe de desenvolvimento ou mesmo de todo divisões \ empresas. E ele pede para organizar testes de negócios, ou testes de ponta a ponta, ou testes com base em cenários do começo ao fim (fim 2 final).
Vamos começar do começo - dos dois pilares de onde surgiu esse notável “teste de negócios de ponta a ponta”, a saber, da pirâmide de testes e do padrão ISO9000.
Testando a pirâmide
A pirâmide de teste provavelmente é familiar para qualquer testador que tenha se tornado proficiente em sua profissão e tenha acumulado inchaços ao se comunicar com unidades relacionadas. Especialmente, é necessário recorrer a ele ao substanciar a automação de teste. Quais testes são mais baratos e mais importantes para desenvolver? E correr?
A essência da pirâmide de teste não é complicada: o teste deve ser baseado nos testes mais simples e rápidos de escrita e execução - testes de unidade. Obviamente, verificar as interfaces de classes e funções dificilmente pode ser mostrado ao cliente, mas sem essa base forte, monolítica e sem problemas, dificilmente é possível criar algo mais alto. Como regra, várias dezenas de funções, métodos e classes implementam algum tipo de funcionalidade para o cliente e, de fato, uma dúzia de testes de unidade pode ser reduzida a alguns testes de nível superior. O cliente já precisa de um apartamento bonito com decoração, mas é improvável que ele fique satisfeito quando as janelas inclinadas de seu apartamento pararem de se abrir e o piso e o teto quebrarem com a primeira brisa. No entanto, o próprio cliente a entrar no apartamento e verificar sua qualidade pode não ser a melhor ideia. Concordo, é difícil para o usuário verificar a qualidade do concreto na fundação e reproduzir todas as condições climáticas. Portanto, nos testes, é claro, são necessários testes de nível superior, e somente quando realizamos testes de unidade, o mesmo ocorre com testes de nível superior.
É mais difícil desenvolver e demorar mais para executar testes de nível superior - testes de integração, que verificam a operação correta dos módulos de trabalho simultâneos em que toda a equipe trabalhou, liberando seu produto (sistema). Ou seja, a integração do código é verificada, o sistema é testado sem levar em consideração a interação com sistemas externos. Esses testes já implicam uma verificação de alto nível, provavelmente através de uma chamada para o sistema por meio da API do sistema ou mesmo de uma GUI (frente). Trabalhar com esse tipo de teste é mais difícil - para cobrir todas as ramificações e nuances do código, você provavelmente precisará usar um grande número de verificações fortemente sobrepostas em vários dados de teste e, durante a automação, desenvolva muitas condições e ramificações nos scripts. Ou seja, por um lado, já abordamos o usuário, dificultando a vida, mas, por outro lado, ainda é difícil encontrar um idioma comum, isso nos custa mais e a qualidade das verificações ainda não é suficiente. Ou seja, podemos lançar o cliente em um apartamento novo, ele pode verificar tudo, mas sem levar em consideração a interação com outros moradores, condições climáticas e serviços públicos. Concordo, o senso de um mundo ideal, um modelo, na vida real, como regra, não é muito.
Se adicionarmos essas condições, veremos como nosso sistema interage com sistemas externos - fornecedores e consumidores, com nosso ambiente, ou seja, realizamos testes de sistema, então podemos ver facilmente que a complexidade dos testes também aumentará. Precisamos alcançar a operabilidade simultânea de todos os sistemas em interação, embora sem o envolvimento de especialistas neles. Por enquanto, basta aceitar alguns dados de nossos fornecedores e transferir nossos dados para nossos consumidores. Na sequência e formato corretos. O destino adicional dos dados não nos incomoda. O principal é que nosso sistema funcione corretamente no ambiente certo. E tudo ficaria bem aqui - para o nosso cliente, já podemos realizar uma demonstração em grande escala, mas apenas na vida real não são todos os critérios de sucesso para o nosso desenvolvimento. É claro que é bom que o cliente tenha o apartamento dele em uma casa sólida, mas se você precisar sair dele, escalando o arame farpado e depois passeando de canoa pelo lago com crocodilos até cabanas repletas de cobras, talvez não estejamos certos fez lá?
Portanto, aqui a primeira idéia para testes de ponta a ponta é verificar não apenas nosso ambiente, mas também todos os sistemas interconectados pelos quais passam os dados recebidos ou enviados por nosso sistema. E isso, por sua vez, significa que teremos que combinar várias dessas "pirâmides de teste" umas com as outras. A construção de uma ponte frágil sobre a qual manteremos os dados valiosos para o usuário pelo identificador.
A única questão é como fazer isso? Quem deve fazer isso? Como montar?
ISO9000
Uma série de padrões que descrevem o sistema de gerenciamento da qualidade, incluindo o fato de que qualquer processo na organização deve ser descrito e documentado, mesmo que seja o processo de emitir uma comissão no outono para o zelador. E, nesse caso, não é possível descrever nenhum processo que ocorra dentro do software usado e desenvolvido na organização. A questão é como fazer isso? Obviamente, a melhor descrição, do ponto de vista do BDD, é a descrição do comportamento por testes, sob a qual a pirâmide de testes estará. Mas retornaremos imediatamente ao nosso dilema, combinando várias pirâmides com cordas finas de cima para cima, ao longo das quais nosso caminhante na corda bamba e seus usuários caminharão sem seguro.
A abordagem de processo é uma estratégia de gerenciamento que exige que as organizações gerenciem seus processos e as interações entre eles. Portanto, você precisa considerar cada processo principal da empresa e seus processos de suporte.
Portanto, é mais fácil usar abstrações - criar pelo menos um diagrama de processo e indicar suas entradas e saídas, tornar o processo controlado e mensurável, garantir a interconexão com os processos pai e filho, conforme exigido pela ISO9000
Todos os processos têm:
• insumos;
• saídas;
• controle operacional;
• medição e monitoramento apropriados.
Cada processo terá processos de suporte que sustentam e permitem que o processo se realize
Os diagramas de negócios são mais adequados para essa finalidade, e os padrões como UML, BPMN, ARIS etc. são usados com mais freqüência, e os próprios processos se tornam fluxogramas com "cubos" amarrados neles. Há interação entre os “cubos”, no padrão BPMN é um fluxo de ações e um fluxo de mensagens. E é exatamente disso que precisamos!
Qualquer empresa que queira ter um certificado e siga a norma ISO9000, provavelmente adquiriu esses esquemas, e eles são parte integrante dos requisitos de nível superior. Se a empresa tiver bons analistas, provavelmente os links para os requisitos de ações individuais dos esquemas diminuirão para os requisitos de baixo nível. Nós precisamos deles.
De fato, nos diagramas, podemos ver todo o processo e entender qual cenário precisamos construir e qual sistema / equipe executar com quais dados e em que momento.
Não estou subestimando o trabalho de desenvolvedores que escrevem códigos competentes que enviam mensagens entre diferentes partes de sistemas de software e hardware, mas é impossível manter tudo em mente. E quando o processo é usado em muitos outros processos, é melhor ter esse "cartão" com você para realizar testes competentes e, ainda mais, para construir um modelo de teste.
O que na prática
Portanto, temos dois introdutórios - cada equipe \ sistema deve ter uma pirâmide de testes preparada - desde os menores testes unitários até testes complexos do sistema, além do fato de que, dentro da organização, devemos descrever os requisitos na forma de negócios -processos. Esse fato nos permitirá responder rapidamente ao cliente que processo de negócios como ele funciona e em que ponto ele quebra, e nós mesmos, ao recebermos defeitos da operação industrial, executamos rapidamente a análise de causa raiz (análise das causas principais de defeitos). Em teoria.
Mas, na prática, tudo recai sobre o testador - como, de uma pilha de testes, especialmente estrangeiros, para selecionar os corretos, construí-los em uma cadeia e com a entrada de cada um dos sistemas para enviar os dados necessários e comparar com o resultado esperado corretamente determinado?
A opção mais fácil é desenvolver inicialmente testes baseados em modelos de negócios e dividir equipes em projetos que implementam um processo de negócios específico. Para isso, em algumas ferramentas de gerenciamento de teste, já é possível carregar esquemas BPMN (por exemplo, para HPE ALM - o carregamento no formato XPDL é suportado). O próprio HP ALM dividirá o esquema em um conjunto de requisitos (ações) e, se desejado, criará uma hierarquia de requisitos (módulo Requisitos-> Modelos de Negócios). Em seguida, é nosso negócio cobrir os requisitos com testes e depois construí-los e, portanto, os testes em cadeias que cobrem nosso processo de negócios. Essas cadeias no HPE ALM são chamadas de "caminhos" e permitem ver todas as combinações de sequências. Se desejado, as cadeias podem ser imediatamente convertidas em testes.
Mas mesmo se você não usar ferramentas de teste, ainda precisará criar cadeias a partir do processo de negócios. Especialmente considerando a imperfeição das ferramentas (nem tudo é tão róseo), bem como o fato de que, muito provavelmente, o modelo de teste precisará ser montado pós-fato e executado na forma de uma regressão por uma "equipe comum" que não está presa a novos projetos.
Quantas maneiras um esquilo pode atingir uma colisão?Nesse caso, precisaremos abrir os testes de cada equipe, encontrar aqueles vinculados aos requisitos que aparecem no modelo de negócios e construir cadeias a partir deles, salvando-os em um "espaço comum". Criar um espaço comum é algum tipo de substituto, mas, em qualquer caso, deve ser, mesmo na forma de um livro de celeiro, excel ou uma área de projeto em uma ferramenta de gerenciamento de testes. Se falarmos sobre o HPE ALM novamente, o módulo BPT (Business Process Testing) é responsável por essa funcionalidade, que ao mesmo tempo permite transferir os resultados de um teste para os parâmetros de outro. No entanto, se você deseja e trabalha duro no HPE ALM, é possível implementar isso reconstruindo os conjuntos de testes (conjunto de testes) no fluxo de execução (fluxo de execução). Em seguida, ao iniciar o conjunto completo, os testadores responsáveis por passar cada um dos componentes do script de ponta a ponta serão chamados por sua vez.
E, infelizmente, testar sozinho não é suficiente. Na minha prática, quase todas as ferramentas têm algumas falhas fatais e, portanto, se você chegar ao estágio de automação de testes em um processo de negócios, chegará à criação de um script que puxará os testes na seqüência correta.
Como resultado, duas conclusões podem ser feitas:
1) para cenários de ponta a ponta, é muito provável que testes desenvolvidos anteriormente sejam usados para cada um dos sistemas incluídos na cadeia de processos de negócios (cenário)
É possível apresentar todos os conjuntos de testes completos de uma empresa na forma de uma matriz esparsa, onde os testes para cada sistema são distribuídos em colunas (para simplificar - testes do sistema) e processos de negócios em linhas. Ou seja, para certos processos de negócios, é necessário selecionar \ criar testes que abranjam o processo de negócios, estabelecer relacionamentos. Se não houver cobertura, é uma ocasião para preencher as lacunas no modelo de teste ou para garantir que a qualidade seja garantida por outros níveis de teste (teste de integração, teste de unidade, revisão de código e execução através de analisadores).
2) É necessária uma ferramenta para monitorar, rastrear e atualizar o processo de negócios para sincronização com o modelo de teste.
E se as ferramentas de teste lidam de maneira mais ou menos tolerável com a criação de um modelo de teste, tudo fica muito ruim com a atualização, geralmente é mais fácil recriar o modelo novamente do que tentar ver mudanças no processo e no modelo de teste. E a experiência de equipes reais sugere que é melhor criar uma visualização ao vivo da arquitetura. A maneira mais fácil de fazer isso é na área comum, usando uma placa e adesivos simples. Em seguida, as equipes que participam do processo de negócios podem ver claramente como o processo está sendo modificado (conexões são removidas e adicionadas, ações são removidas e adicionadas). O principal é que todos tenham acesso ao quadro. Além disso, observe que, se o processo envolver mensagens entre sistemas, geralmente, pelo menos, haverá dois testes de cada sistema - para enviar e receber dados. No entanto, em vez de adesivos, você pode usar uma cidade inteira de Lego (de grandes blocos) ou algo ainda mais criativo. O principal aqui é um idioma e um espaço de informações, que são muito escassos na empresa.
Em conclusão
Organizar testes visuais e adequados dos processos de negócios é algo complexo e muito caro. Observe que o teste E2E não é apenas aceitação, teste do usuário que o cliente executará, está construindo uma ponte, levando em consideração todas as situações possíveis que o cliente seguirá e guiará os usuários.
Mais uma vez - E2E - este não é um passeio pela Lada Kalina através da ponte, e nem mesmo duas passagens de kamaz. Isso é um trabalho de engenharia complicado, pesando pontes com sensores e realizando todas as verificações e situações possíveis - pelo menos uma descrição desses cenários.
Se sua empresa precisa ou não de uma execução de acabamento ideal, é uma questão exclusivamente para seus objetivos e necessidades. Sempre, como em qualquer teste, você deve avaliar os riscos potenciais de defeitos ausentes nesse estágio, bem como o custo da preparação e realização dos testes de ponta a ponta. Avaliar o que lhe custará mais com isso e só então agir. Mas, no caso de testes de ponta a ponta em processos de negócios, deve-se lembrar que não faz sentido sem uma base sólida na forma de 100% de testes de unidade de taxa de transferência (~ 90-100% de cobertura), sem testes de integração (~ 60-80% de cobertura, 90- 100% de taxa de transferência), sem testes do sistema (cobertura de 20 a 40%, taxa de 80 a 100%). Estabelecer critérios para o sucesso (portões de qualidade) é mais do que um requisito para a qualidade do produto, a principal coisa a lembrar aqui é que o volume de testes E2E é apenas o topo da pirâmide (cobertura de 1-2%, ~ 99% de velocidade), que não deve ser maior que sua base, não ao mesmo tempo, faça um furo com os passos anteriores. Este é um complemento que a priori é considerado fechado nas etapas anteriores.
A organização desses testes é principalmente o trabalho de preparação e sincronização de casos e dados de teste (análise de teste), bem como um conjunto de medidas organizacionais, sincronizando equipes em um local ao mesmo tempo em um local de teste viável. Tendo isso em mente, não se deve tentar mostrar ao cliente "testes de ponta a ponta" com antecedência, para não perder tempo ao mesmo tempo um grande número de pessoas sem todos os componentes de trabalho reunidos.
As ferramentas descritas pela
PS , bem como as práticas - puramente, por exemplo, o autor não se propuseram a anunciar produtos e declarar essa abordagem dos testes de ponta a ponta da única maneira verdadeira.