V&V não para vendetta

Nos últimos seis anos, trabalhei no desenvolvimento e teste de aceitação dos pedidos de condução e suporte de ensaios clínicos. Aplicações de vários tamanhos e complexidade, big data, um grande número de visualizações e visualizações, data warehousing, ETL, etc. Os produtos são utilizados por médicos, gerenciamento de ensaios clínicos e pessoas envolvidas no controle e monitoramento de pesquisas.

Para os aplicativos que têm ou podem ter um impacto direto na vida e na saúde dos pacientes, é necessário um processo formal de teste de aceitação. Os resultados dos testes de aceitação, juntamente com o restante do pacote de documentação, são submetidos à auditoria do FDA (Food and Drug Administration, EUA). O FDA autoriza o uso do aplicativo como uma ferramenta para monitorar e conduzir ensaios clínicos. No total, minha equipe desenvolveu, testou e enviou à produção mais de trinta aplicativos. Neste artigo, falarei brevemente sobre o teste de aceitação e o aprimoramento das ferramentas usadas para isso.

Nota: Não pretendo ser a verdade suprema e compreendo completamente que a maior parte do que escrevo é sobre um monólogo do Capitão Óbvio. Mas espero que o descrito possa ser útil tanto para o nível inicial quanto para as equipes que o encontram no trabalho cotidiano, ou pelo menos para alegrar aqueles que têm processos mais simples.

FDA

Ensaios clínicos são experimentos ou observações feitas em pesquisas clínicas. Tais estudos prospectivos de pesquisa biomédica ou comportamental em participantes humanos são projetados para responder a perguntas específicas sobre intervenções biomédicas ou comportamentais, incluindo novos tratamentos (como novas vacinas, medicamentos, escolhas alimentares, suplementos alimentares e dispositivos médicos) e intervenções conhecidas que justificam estudos adicionais e comparação. Os ensaios clínicos geram dados sobre segurança e eficácia. Wikipedia

Em outras palavras, para que a pílula para dor de cabeça chegue a um balcão de farmácia em algum lugar de Brighton Beach, ela passa por três fases de testes em humanos, durante as quais é determinado quanta substância ativa deve estar contida no comprimido, quão segura é e se cura dor de cabeça.

O que é o FDA em termos do que fazemos e como isso afeta o processo de desenvolvimento e o ciclo de lançamento?

A Food and Drug Administration (FDA ou USFDA) é uma agência federal do Departamento de Saúde e Serviços Humanos dos Estados Unidos, um dos departamentos executivos federais dos Estados Unidos. O FDA é responsável por proteger e promover a saúde pública por meio do controle e supervisão de segurança alimentar, produtos de tabaco, suplementos alimentares, medicamentos e medicamentos farmacêuticos vendidos sem receita (medicamentos), vacinas, produtos biofarmacêuticos, transfusões de sangue, dispositivos médicos, radiação eletromagnética dispositivos emissores (ERED), cosméticos, alimentos para animais e rações e produtos veterinários. Wikipedia

De fato, o FDA praticamente não diz respeito ao processo de desenvolvimento em si, trabalhamos de acordo com o SCRUM usual (para ser honesto, não é bem SCRUM - eles dizem que agora está na moda chamar esse processo de "SCRUM modificado") com um ciclo de liberação do sprint. Não entregamos a produção no final de cada sprint (e até no final de três sprints e até dez se a linha do tempo envolver 15 sprints), ou seja, do ponto de vista da entrega para o usuário final , temos uma metodologia semelhante a cascata.

No nosso caso, o teste é dividido em duas partes independentes, com cronogramas diferentes, estimativas diferentes e processos diferentes. A primeira parte é o teste in-dev usual, onde o testador é parte integrante da equipe de desenvolvimento e termina os sprints junto com o desenvolvimento. A segunda parte é o teste de aceitação real e a manutenção das atividades relacionadas (quando necessário). O processo é construído de acordo com a metodologia V&V: requisitos funcionais e do usuário na entrada, scripts de teste e um pacote de documentação de suporte na saída.

O ciclo de lançamento depende do escopo do projeto, geralmente os lançamentos não são iterativos. Após o lançamento, o aplicativo pode permanecer inalterado por um longo tempo, uma pausa entre os lançamentos pode variar de alguns meses a um ano ou mais.

V&V

O que é V&V e como isso afeta o processo de aceitação.

“No gerenciamento de projetos de software, testes de software e engenharia, verificação e validação de software (V&V) é o processo de verificar se um sistema de software atende às especificações e se cumpre o objetivo pretendido. Também pode ser referido a um controle de qualidade de software. Normalmente, é de responsabilidade dos testadores de software como parte do ciclo de vida de desenvolvimento de software. Em termos simples, a verificação do software é: "Supondo que devemos construir o X, nosso software alcança seus objetivos sem erros ou falhas?" Por outro lado, a validação do software é: "X era o que deveríamos ter construído? O X atende aos requisitos de alto nível? » Wikipedia

Em outras palavras:
Verificação: estamos fazendo o produto certo?
Validação: Estamos produzindo o produto certo?

Isso significa que devemos testar as especificações funcionais e do usuário com a integridade necessária e suficiente. Para nós, o primeiro V se transforma em teste de aceitação técnica (SIT), o segundo em suporte ao UAT, onde:

• SIT - Teste de Integração de Sistemas
• UAT - Teste de aceitação do usuário

A visualização da cobertura dos requisitos é realizada na Matriz de Rastreabilidade (uma tabela regular no Excel ou Word, vou falar sobre isso mais adiante), que permite o rastreamento dos requisitos até o teste e vice-versa. No caso de usar o gerenciamento eletrônico de documentos, a matriz é construída automaticamente, os testes são vinculados aos requisitos que são armazenados junto com os testes (juntos = HP ALM, é claro que não são misturados). Caso o requisito não seja coberto e não o seja, justificamos por que não o cumprimos.

Quando a cobertura do requisito não é necessária?

Por exemplo, a CFR Parte 11 ( Regras da FDA para Registros Eletrônicos e Assinaturas Eletrônicas ) contém muitos requisitos que já foram abordados na Microsoft; portanto, se usarmos o Windows AD para autenticação, não precisaremos atender a esses requisitos novamente.

Por fim, a essência dos testes de aceitação se resume a testar o produto quanto à conformidade com os requisitos e os requisitos de conformidade com o produto.

Funções

Um número bastante grande de funções participa do processo, que de uma forma ou de outra é familiar a todos os envolvidos no desenvolvimento de software: Desenvolvedor (Júnior, Médio, Sênior, Líder), Testador de unidade, Testador de SIT, Testador de produtos, Proprietário técnico de produtos, Produto comercial Proprietário, Scrum Master, Gerente de Projetos, Analista de Negócios, Líder Técnico, Líder de Teste SIT, Líder de Teste UAT, QC Global, Suporte, Engenheiro de Implantação e outros.

O papel específico para nós - QC global . Essa é a pessoa do lado do cliente responsável por observar e atender aos requisitos do processo - Ciclo de Vida do Software e todos os tipos de Procedimentos Operacionais Padrão (POP) do lado do cliente - durante o desenvolvimento e a aceitação, além de fornecer um pacote de documentos para auditoria externa.

Documentação de aceitação

No escopo da liberação do produto, criamos um pacote de documentação que incorpora um grande número de níveis de aninhamento, incluindo documentação relacionada à forma como o produto foi testado, por que foi testado dessa maneira e não de outra forma, o que especificamente estava no escopo do teste e o que não era:

Plano de validação e lista da equipe - PM é responsável pela criação e aprovação do documento. O documento geralmente inclui a descrição do sistema, lista de artefatos de desenvolvimento e teste, estratégia de validação, lista de funções e responsabilidades.

Estratégia de teste - o documento que não pertence ao aplicativo específico, mas existe para o ramo de produtos ou um ramo de teste. Por exemplo, como determinamos qual parte do teste seria automatizada, o que planejamos usar para automação, como planejamos realizar testes manuais, planejamos usar listas de verificação, scripts de teste, ambos ou qualquer outra coisa mais; como planejamos decidir se realizamos testes de desempenho / carga / volume ou não; e coisas assim.

Plano de teste - comum para as equipes UAT e SIT, inclui uma breve descrição do objeto de teste, possíveis restrições, requisitos do ambiente, tempo, conjuntos de testes e assim por diante.

Conjunto de Testes - um conjunto de testes ou listas de verificação formados por área funcional, tipo de teste ou qualquer outra característica.

Matriz de rastreabilidade - uma matriz com rastreios de requisitos a testes. O rastreamento de requisitos como evidência de cobertura é uma parte importante do processo. Usando o identificador de qualquer requisito, é possível encontrar uma etapa específica na qual esse requisito é testado e fornecer evidências ao revisor (captura de tela, arquivo etc.) para uma versão específica do aplicativo (ou para cada versão em que esse requisito foi cumprido). formalmente coberto). Portanto, vincule, vincule e vincule novamente os testes aos requisitos (tarefas), com base nos quais você obtém o resultado esperado, mesmo que isso não seja necessário, porque isso simplificaria sua vida no futuro. Se for impossível devido ao uso de diferentes ferramentas não integradoras, você sempre poderá deixar comentários em tarefas / testes, criar uma matriz (Excel mencionado acima) ou criar um banco de dados primitivo de três tabelas.

O PDS - Especificação do Projeto do Produto, Líder Técnico ou Arquiteto do Sistema é responsável pela criação do documento. De fato, é um tipo de combinação de documentos de arquitetura de alto e baixo nível (HLA e LLA).

FRS & URS ou BRS - requisitos funcionais e do usuário. Geralmente, existem dois documentos separados, mas às vezes há Especificação de Requisitos de Negócios que incorpora as duas especificações.

Registro de Defeitos - um registro de erros identificados no aplicativo e / ou requisitos durante o SIT formal.

Registro de problemas menores - um registro de pequenas alterações nos scripts de teste (erros de digitação, requisitos esquerdos ou redundantes, quaisquer erros).

Relatório de resumo do teste - um relatório sobre os resultados da fase de teste, que inclui o seguinte:

• Informações sobre construções usadas para o teste (incluindo números de construção e datas de implantação com informações sobre os motivos da implantação), número de ciclos de teste e resultados de scripts de teste (aprovados / reprovados).
• Uma descrição das discrepâncias dos POPs.
• A lista de defeitos em aberto com justificativas.
• O link para o log de defeitos ou o próprio log de defeitos.
• O link para os problemas menores se registra ou se registra.
• Uma recomendação sobre implantação no ambiente de produção.

Plano de implantação - o documento usado para implantação na produção incorpora a descrição das reversões.

Relatório de resumo de validação - o documento de fechamento do plano de validação.

Aprovação de documentação

Qualquer processo de aprovação de documentação pode ser dividido em 3 etapas:

• Preparação de documentos.
• Revisão
• Aprovação

Vejamos o exemplo de um conjunto de testes.

Para escrever scripts de teste e combiná-los em suítes de teste, usamos um modelo padrão aprovado no lado do cliente.

Parágrafos do conjunto de testes:

• Nome do projeto e do aplicativo.
• Versão de lançamento.
• Nome e identificador exclusivo do conjunto.
• Descrição (o que testamos e que tipos de teste usamos).
• Scripts de teste.
• Lista de aprovadores.

Por sua vez, cada teste consiste em:

• Nome e identificador exclusivo do script de teste.
• Descrição.
• Condições prévias.
• Pós-condições.
• Referências de rastreabilidade.
• Instruções para execução (por exemplo, instruções de como mascarar dados confidenciais).
• Etapas (procedimento, resultados esperados e observados).
• Resultado do script de teste.
• Testador.
• Revisor

O ciclo de vida normal do teste se assemelha a uma cascata e fica assim:

1. Escrita
   Análise de requisitos. Definição e aplicação de técnicas de design de teste para a cobertura mais adequada da funcionalidade. Escrevendo etapas.
2. Execuções a seco no ambiente de desenvolvimento
   Nesta fase, tentamos descobrir como o aplicativo atende aos requisitos e encontrar a maioria dos erros possíveis, incluindo erros de requisitos.
3. Revisão da pessoa responsável (líder da equipe do SIT)
   Revisão estilística e lógica.
4. Funcionamentos a seco no ambiente de sentar
   Nesse estágio, os erros associados à instalação, ambiente e configuração do ambiente são detectados (por padrão, assumimos que o ambiente SIT repete exatamente ou quase completamente o PROD). A conclusão bem-sucedida desse estágio significa que a versão implantada é estável e a liberação pode ser considerada um candidato.
5. Revisão do cliente (QC global)
   O CQ global verifica se os requisitos foram atendidos e se os testes escritos correspondem aos POPs da empresa.
6. Aprovação (CQ Global, Pedido Técnico, Pedido Comercial).
7. Execução formal de script de teste no ambiente SIT (versão candidata a lançamento)
   Após a aprovação dos testes para a execução (p. 6) e a conclusão bem-sucedida das execuções a seco no ambiente do SIT (p. 4), o teste é formalmente executado no ambiente do SIT com a fixação formal do resultado. Se os erros encontrados nos passes de execução a seco não forem formais e simplesmente inseridos no Jira de maneira semelhante ao que acontece durante o processo de desenvolvimento, um formulário de defeito separado será criado para cada erro encontrado na execução formal, incluído na documentação de saída pacote para o produto.
8. Revisão de execução de script de teste (líder da equipe do SIT).
   O mesmo no ponto 3.
9. Revisão do cliente (QC global)
   O CQ global verifica a correção e a integridade do preenchimento dos resultados, possíveis erros, a presença de evidência (por exemplo, capturas de tela). Um ponto importante, porque o CQ Global é responsável por fornecer um pacote de documentos para uma auditoria externa (pelo FDA ou pelos clientes).

Trabalhando com dados pessoais

Dado que a pesquisa é realizada usando a metodologia duplo-cego *, esse é o menor dos nossos problemas. Mas os dados de médicos, nomes de empresas, números de protocolos de pesquisa etc. devem ser alterados. Do ponto de vista formal, se não podemos nos livrar de dados confidenciais, temos que mascará-los nas capturas de tela, mas essa é uma situação razoavelmente padrão e compreensível.

* duplo-cego - os pacientes são divididos aleatoriamente em dois grupos, um dos quais recebe o medicamento do estudo e o segundo um placebo ou medicamento com eficácia comprovada. Ao mesmo tempo, nem o médico nem o paciente sabem em qual grupo o paciente foi designado. Isso elimina o viés do médico e o efeito placebo. No contexto de trabalho com dados pessoais, isso significa que, na maioria dos casos, a identidade do paciente não pode ser identificada com base nos dados armazenados no banco de dados ou acessíveis ao usuário.

Mas o fato de esse ser o menor dos nossos problemas não significa que não possa trazer problemas. Aqui estão alguns ancinhos (para não pisar duas vezes) que recebemos em nossos projetos:

Pode ser divertido (não para nós naquele momento): "O Globo"

Em um dos aplicativos, para criar um efeito de uau e não apenas, nós realmente precisamos criar um globo interativo que você possa girar com o mouse, alternar dia / noite e assim por diante. No mundo, existem marcas nos endereços, que são coloridas dependendo dos valores e intervalos em que esses valores se enquadram (um tipo de código de cores). Após anonimizar o banco de dados no ambiente de demonstração, duas horas antes da demonstração, graças ao script de anonimato, ficamos sem códigos postais com todas as consequências.



Moral: não toque nos dados duas horas antes da demonstração.

História número dois: "Sobre o anonimato"

Antecedentes: Os dados são coletados no repositório de um grande número de fontes, os dados pertencem a domínios diferentes, mas são interconectados por identificadores.

A história: os dados foram carregados no banco de dados e anonimizados antes de serem utilizados para fins de teste. Aconteceu que os dados não foram baixados de todas as fontes necessárias. Então eles carregaram a peça que faltava. Não foi possível conectar a segunda parte dos dados (ainda não anonimizada) com a primeira parte já anonimizada. Como resultado, o início do trabalho no ambiente do SIT foi adiado por duas semanas, pelas quais as equipes de implantação e suporte corrigiram os dados.

Moral: antes de anonimizar, certifique-se de que o banco de dados contenha tudo o que deve estar nele e pense com antecedência sobre a aplicabilidade dos mecanismos de anonimização e ofuscação.

Fluxo de trabalho eletrônico versus papel na prática

O fluxo de trabalho eletrônico simplifica um pouco a comunicação e o processo de revisão e aprovação do ponto de vista do trabalho manual, mas praticamente não oferece ganhos em termos de tempo para a preparação para o teste e sua execução. Listados abaixo estão os prós e os contras do fluxo de trabalho eletrônico versus papel com base no exemplo do HP ALM.

Benefícios:

• Fácil de apoiar.
• Menos trabalho manual.
• Todos os membros da equipe a qualquer momento têm acesso ao estado atual de um teste específico
• Histórico de mudanças.
• Histórico de execuções.
• Você pode acompanhar o tempo necessário para concluir o teste.
• Fácil de planejar futuras execuções.
• É difícil usar a versão errada do script de teste.
• Assinatura eletrônica.

Contras (especificamente para o HP ALM):

• Grande quantidade de tempo para formatação de scripts.
• Problemas periódicos com a própria ferramenta.
• Não é o melhor verificador ortográfico.
• Interface inconveniente.
• O tempo gasto escrevendo e revisando os testes é praticamente o mesmo que os testes no Word.
• Custo.

Uma história verdadeira relacionada à papelada e assinaturas manuais: "Um pesadelo antes do lançamento"

Certa noite, escrevi 450 vezes: “a cor dos pontos no gráfico corresponde à indicada nos requisitos. Sobrenome, nome, data ”e coloque uma assinatura - simplesmente porque imprimimos em uma impressora em preto e branco, e a cor dos pontos nos gráficos importava.



Moral: a escolha dos meios deve ser consistente com os objetivos.

Outra história: “Pesado é bom, pesado é confiável.” ©

O fluxo de trabalho em papel é sobre papel (quem duvidaria). A fase de teste de aceitação para uma aplicação longe da maior pode ser de cerca de cinco quilos de papel.



A conclusão que se sugere a partir das histórias acima (e muitas não contadas): apesar das desvantagens listadas e não listadas do fluxo de trabalho eletrônico - se você pode escolher, escolha definitivamente o eletrônico, mesmo que o HP ALM (não seja mais a HP).

Automação

Um grande número de visualizações não permite automatizar aplicativos de forma estável; portanto, como parte da abordagem inicial, nos limitamos a testes de unidade (incluindo testes no lado do banco de dados) e testes de API, sem nenhuma tentativa de avançar para o E2E.

Como e por que chegamos à automação pelo menos parcial?

A primeira tarefa foi explicar para nós mesmos que, em alguns casos, realmente ganharíamos tempo. Sim, é compreensível: nem todo mundo acredita em automação e, freqüentemente, seu uso não se justifica - porque é usado de maneira errada, não existe e não para isso, mas esse é um tópico para uma discussão separada, sobre a qual existem são um pouco menos do que "a automação deve ter !!!", mas ainda muito.

A segunda coisa é explicar ao cliente que ele ganhará tempo e que será suficientemente confiável e aceitável do ponto de vista formal. O setor é controlado e há razões para isso.

Terceiro, e principal: determinar o algoritmo pelo qual podemos conscientemente tomar uma decisão sobre a automação de testar um aplicativo específico ou parte do aplicativo e obter o consentimento para a automação. Isso é importante porque fica claro que o processo de automação não deve ser menos controlado que o processo descrito para os scripts de teste manual.

Depois de explicar e justificar os dois primeiros pontos para nós e para o cliente, escrevemos uma estratégia de teste, pedimos aos analistas de negócios que adicionassem campos adicionais aos requisitos e formamos um conjunto de perguntas, dependendo das respostas para as quais podemos formar um conjunto para automação.

A lista de perguntas em nosso caso:

1. É possível automatizar o teste nesse caso específico?
2. É um componente estável *?
3. Com que frequência precisamos executar scripts de teste para este componente?
4. É uma função crítica para os negócios? **
5. Quão difícil é automatizar o teste?

* Estável = o componente não foi alterado por algum tempo e as alterações do componente não estão planejadas para as próximas versões.
** É preenchido, dependendo do valor do campo adicionado aos requisitos pelo analista de negócios.


Em geral, o processo de tomada de decisão é o seguinte:

1. Na entrada, temos requisitos do FRS.
   Criamos Design Matrix, onde cada linha é requisito do FRS e as colunas são:
   
   • Descrição do requisito
   • Perguntas 1-5
   • Decisão da equipe
   • Estimativa aproximada
   • Aprovação
   • Comentários
2. A equipe coloca as respostas às perguntas e, com base nos dados recebidos, determina se vale a pena automatizar o teste de um requisito / grupo de requisitos específico, no todo ou em parte.
3. O cliente analisa a solução proposta e aprova a versão final.
4. Após a aprovação da Matriz de Design, os autotestes são gravados. Os scripts para autotestes são escritos em notação Gherkin e passam por uma revisão semelhante à dos testes manuais (CQ global, Proprietário técnico, Proprietário da empresa). As definições de etapas, objetos de página e assim por diante, são revisadas nas solicitações de recebimento, inclusive por um especialista técnico da parte do cliente. Os resultados do autoteste e os relatórios gerados são revisados ​​e aprovados no lado Global QC.

Dentro de dois anos a partir do momento da implementação, passamos para a automação parcial do teste de aceitação de dois aplicativos relacionados ao download, configuração e exibição de dados no data warehouse e, em um futuro próximo, planejamos continuar usando a abordagem combinada em outros aplicativos. produtos desenvolvidos para o cliente, se possível.

Conclusão

Concluindo, gostaria de observar que o teste formal de aceitação não é algo assustador ou inútil, como parece para muitas pessoas na indústria. Permite, aproveitando ao máximo a abordagem de teste de cenário, facilitar o teste de versões futuras, confirmar o nível necessário e suficiente da qualidade do software e, finalmente, tranquilizar o cliente. E o que, se não a paz de espírito do cliente, é importante na terceirização do desenvolvimento?