V&V não significa vingança

Nos últimos seis anos, venho desenvolvendo e aceitando testar uma variedade de aplicações em termos de complexidade e tamanho para conduzir e manter ensaios clínicos. Big data, um grande número de visualizações e visualizações, data warehousing, ETL e similares. O produto é utilizado por médicos, gerentes e pessoas envolvidas no controle e monitoramento de pesquisas.

Para 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 desenvolvimento de ferramentas em um pequeno grupo.

Nota: Não pretendo ser a verdade suprema e compreendo que a maior parte do que escrevo é sobre as evidências do monólogo do capitão. Mas espero que o descrito seja útil tanto para o nível inicial quanto para as equipes que encontrarem isso em seu trabalho diário, ou pelo menos para aqueles que têm processos mais simples.

FDA

Os estudos clínicos em todo o mundo são uma etapa essencial no desenvolvimento de medicamentos, que precede seu registro e uso médico generalizado. Em ensaios clínicos, um novo medicamento é estudado para obter dados sobre sua eficácia e segurança. Wikipedia

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

O que é o FDA para nós e como isso afeta o processo de desenvolvimento e o ciclo de lançamento?

A Food and Drug Administration (FDA, USFDA, cartas. Food and Drug Administration) é uma agência do Departamento de Saúde e Serviços Humanos dos EUA, um dos departamentos executivos federais. O departamento está envolvido no controle de qualidade de produtos alimentícios, produtos farmacêuticos, cosméticos, produtos de tabaco e algumas outras categorias de produtos, além de monitorar a conformidade com a legislação e os padrões nessa área. Wikipedia

O FDA praticamente não diz respeito ao processo de desenvolvimento em si, trabalhamos no SCRUM usual (ou melhor, não no SCRUM - eles dizem que agora está na moda chamar esse "SCRUM modificado") com um ciclo de liberação não-sprint. Não vamos ao prod no final do sprint (e mesmo 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 ao usuário final, temos algo parecido com uma cascata.

Os testes no nosso caso são divididos 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 e manutenção reais (quando necessário). O processo é construído de acordo com a metodologia V&V: requisitos funcionais e do usuário na entrada, testes e um pacote de documentação de suporte na saída.

O ciclo de lançamento depende do volume de trabalho, geralmente os lançamentos não passam por iterações. Após o lançamento, o aplicativo pode permanecer inalterado por um longo período, ou seja, uma pausa entre os lançamentos - de alguns meses a um ano ou mais.

V&V

Que tipo de animal é esse, V&V, e como isso se reflete no 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

Tradução livre:

“No gerenciamento de projetos, testes e desenvolvimento de software, verificação e validação (V&V) é o processo de verificação de que o software desenvolvido atende às especificações e cumpre a função pretendida. Também pode ser atribuído ao controle de qualidade em geral. Normalmente, os engenheiros de teste são responsáveis ​​pela verificação e validação do ciclo de vida de desenvolvimento de software. Em palavras simples, a verificação de software pode ser descrita como: “Suponha que tenhamos que desenvolver o sistema X. Atingimos a meta sem erros e suposições?” Por outro lado, a validação de software é “O sistema desenvolvido X é realmente algo O que queríamos conseguir? O sistema X atende aos requisitos de alto nível? ”

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 (SIT), o segundo em manutenção (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 é criada automaticamente, os testes são vinculados aos requisitos que são armazenados junto com os testes (juntos = HP ALM, naturalmente, não são armazenados muitos deles). Caso o requisito não seja coberto e não seja coberto, explicamos o motivo.

Quando o requisito de cobertura não é necessário?

Por exemplo, a CFR Parte 11 (as regras estabelecidas pelo FDA para registros e assinaturas eletrônicas ) contém um grande número de requisitos que já são cobertos pela Microsoft e, se usarmos o Windows AD para autenticação, não precisamos cobri-los novamente.

Por fim, a essência do teste de aceitação se resume a testar o produto quanto à conformidade com os requisitos e requisitos de conformidade do 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 SIT, Dono Técnico de Produto, Dono de Produto Empresarial, 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.

Nosso papel específico é Global QC . Essa é a pessoa do lado do cliente, responsável pela conformidade com os 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

Como parte do release do produto, um pacote de documentação é criado com 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, e o que foi especificamente testado e o que foi deixado de fora:

Plano de validação e lista da equipe - PM é responsável por escrever e aprovar o documento. Um documento geralmente inclui uma descrição do sistema, uma lista de artefatos que serão criados durante o desenvolvimento e o teste, uma estratégia de validação e uma lista de funções com responsabilidades.

Estratégia de teste - um documento que não se aplica a um aplicativo específico, mas é criado para uma ramificação de produto separada ou para uma ramificação de teste separada. Por exemplo, como e por que determinamos o que automatizaremos e o que não; quais tecnologias; como organizaremos o teste manual (listas de verificação ou scripts de teste, ou ambos juntos, ou algo completamente diferente); como decidimos se conduziremos a carga ou não; e assim por diante.

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 outro recurso.

Matriz de rastreabilidade - matriz de rastreamento do requisito ao teste. Rastrear como evidência de cobertura é uma parte importante do processo. Ao identificar qualquer requisito, você pode encontrar uma etapa específica na qual esse requisito é confirmado 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 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. Se for impossível devido ao uso de diferentes ferramentas não integradoras, você sempre pode deixar comentários em tarefas / testes, criar uma matriz (Excel mencionado acima) ou arquivar um banco de dados primitivo de três tabelas.

PDS - Product Design Specification, um documento desenvolvido por um consultor técnico ou arquiteto de projeto, essencialmente uma combinação de arquitetura de aplicativos de alto e baixo nível (HLA e LLA).

FRS & URS ou BRS são requisitos funcionais e do usuário, geralmente na forma de dois documentos separados, mas às vezes combinados na Especificação de Requisitos de Negócios.

Registro de defeitos - um registro de defeitos detectados durante o teste (defeitos e requisitos do aplicativo).

Registro de problemas menores - um registro de erros menores nos testes (erros de digitação, requisitos ausentes / desnecessários etc.) - quaisquer erros que fundamentalmente não alterem o significado do teste).

Relatório de resumo do teste - relate os resultados dos testes. TSR é o documento de fechamento do plano de teste e contém:

• Informações sobre os conjuntos que foram testados (incluindo números de compilação e datas de implantação), o número de ciclos de teste e resultados de teste.
• Descrição das violações cometidas em relação ao plano e procedimentos de teste (POP) aprovados para execução pela empresa.
• Lista de defeitos em aberto que explicam os motivos da transferência para a próxima versão.
• Link para o log de defeitos ou o próprio log.
• Um link para o log de erros de teste ou o próprio log.
• Uma recomendação para uma decisão de instalação na produção.

Plano de Implantação - um documento pelo qual o suporte e a integração são responsáveis, é compilado durante as instalações no ambiente SIT e é subsequentemente usado para implantar a versão na produção.

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

Aprovação de documentos

Qualquer processo de aprovação de documentação é condicionalmente dividido em 3 etapas:

• Preparação do documento.
• Revisão
• Declaração.

Considere o exemplo do 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.

Os componentes do kit de teste:

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

Por sua vez, cada teste inclui:

• Nome e identificador exclusivo dentro do conjunto.
• Descrição do produto
• Condições prévias.
• Pós-condições.
• Rastreamento (números de requisitos cobertos no teste).
• Recursos de execução (por exemplo, instruções para mascarar dados confidenciais).
• Etapas (ações necessárias, resultados esperados e reais).
• O resultado do teste.
• Realizado.
• Revuever.

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

1. Ortografia
   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. Passagem de teste / passagens em virgens
   Nesta fase, é avaliado o quanto o aplicativo atende aos requisitos e a maior parte dos possíveis bugs, incluindo bugs de requisitos, são corrigidos.
3. Revisão do gerente de projeto (líder da equipe do SIT)
   Revisão estilística e lógica.
4. Passagem / passagens de teste no ambiente SIT
   Nesse estágio, os erros associados à instalação, ambiente e configuração do ambiente são detectados (por padrão, acredita-se que o ambiente SIT repita exatamente ou quase completamente o PROD). A conclusão bem-sucedida desse estágio significa que a versão envolvida é 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 SOP escritos estão em vigor com a empresa.
6. Aprovação (CQ Global, Pedido Técnico, Pedido Comercial).
7. Execução formal de teste no ambiente SIT (liberar versão candidata)
   Após a aprovação dos testes para a passagem (p. 6) e a conclusão bem-sucedida dos testes no ambiente do SIT (p. 4), o teste é formalmente realizado no ambiente do SIT com a fixação formal do resultado. Se os erros encontrados nas passagens de teste não forem formalizados 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 passagem formal, incluído no pacote de documentação de saída do produto.
8. Revisão dos resultados da passagem responsável pelo projeto (líder da equipe do SIT).
   Da mesma forma que o ponto 3, o estilo de preenchimento é verificado e os resultados são analisados.
9. Revisão do cliente (QC global)
   O CQ global verifica a correção e a integridade do preenchimento dos resultados, possíveis erros, presença de confirmações (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).

Trabalhar com dados pessoais

Dado que a pesquisa é realizada usando a metodologia double blind *, esse é o menor dos nossos problemas. Mas os dados de médicos, nomes de empresas, números de protocolos de pesquisa etc., 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 - método 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 que costumávamos pisar em nossos projetos:

Uma pretensão de diversão: um globo

Em um dos aplicativos para criar um efeito de uau e não apenas precisávamos criar um globo interativo que você possa girar com o mouse, alternar dia / noite e assim por diante. No globo, existem marcas nos endereços, que são coloridas dependendo dos valores e intervalos em que esses valores se enquadram (como 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.

Histórico: os dados foram carregados no repositório 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 vincular a segunda parte dos dados (ainda não anonimizada) à 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 ou pense com antecedência sobre a aplicabilidade do mecanismo de anonimização e ofuscação.

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

Quem trabalhou com o HP ALM não ri do circo.

O gerenciamento eletrônico de documentos simplifica, de certa forma, a comunicação e o processo de revisão e aprovação do ponto de vista do trabalho manual, mas praticamente não produz um esgotamento no tempo no contexto do tempo de 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.

Prós:

• É fácil manter a versão mais recente atualizada.
• Menos artesanal.
• Todos os membros da equipe a qualquer momento têm acesso ao estado atual de um teste específico.
• Alterar histórico.
• História de passagem.
• Você pode acompanhar o tempo necessário para concluir o teste.
• É mais fácil planejar o tempo para mais passes.
• Devemos tentar usar a versão errada do teste para a passagem.
• Assinatura eletrônica.

Contras (especificamente para o HP ALM):

• Muito tempo é gasto em testes de formatação.
• Problemas periódicos com a própria ferramenta.
• Falta de um corretor ortográfico normal.
• Interface inconveniente.
• O tempo gasto escrevendo e revisando os testes é praticamente o mesmo que os testes no Word.
• Custo.

Estudo de caso relacionado à papelada e assinaturas manuais: "The Nightmare Before Release"

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



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

História número dois: "A gravidade é boa, a gravidade é confiável"

O fluxo de trabalho de papel é papel (quem duvidaria). Para a recepção de uma versão longe da maior aplicação, ela pode aparecer na região de cinco quilos.



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 gerenciamento de documentos eletrônicos - 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 maneira estável; portanto, como parte da abordagem inicial, nos limitamos a testes de unidade (inclusive no lado base) 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, frequentemente, 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 um relatório separado, do qual há um pouco menos do que "a automação deve ter !!!" ", Mas ainda em quantidade.

O segundo é explicar ao cliente que ele ganhará tempo e que será suficientemente confiável e aceitável do ponto de vista formal. O setor é controlado por um motivo.

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, à luz do processo de aprovação da documentação descrito acima, usando o manual Test Suite como exemplo, fica claro que o processo de automação não deve ser menos controlado.

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 você pode formar um conjunto para automação.

A lista de perguntas em nosso caso:

1. É possível automatizar os testes nesse caso específico?
2. O teste do componente * deve ser automatizado para ser estável?
3. Com que frequência devemos executar testes escritos para um componente?
4. Essa funcionalidade é crítica para os negócios? **
5. Quão difícil é automatizar os testes?

* 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.
** É afixado, dependendo do valor do campo adicionado aos requisitos pelo analista de negócios.


Em termos gerais, o processo de tomada de decisão é o seguinte:

1. A entrada recebe os requisitos do FRS.
   Uma matriz de design é compilada, em que cada linha é um requisito do FRS. Como colunas:
   
   • Descrição do requisito
   • Perguntas 1-5
   • Decisão da equipe
   • Tempo estimado de gravação
   • Aprovação
   • Comentários
2. A equipe coloca 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 pelo Design Matrix, os autotestes são gravados. Os scripts para autotestes são descritos no Gherkin e passam por uma revisão semelhante à dos testes manuais (CQ global, Proprietário técnico, Proprietário da empresa). Definições de etapas, objetos de página e assim por diante, são revisadas no pool de solicitações, inclusive por um especialista técnico da parte do cliente. Os resultados do autoteste e os relatórios gerados são antecipados no lado do QC global.

Nos dois anos desde a introdução, mudamos 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 produtos desenvolvidos para o cliente, se possível.

Conclusão

Concluindo, quero observar que o teste formal de aceitação não é algo assustador ou inútil, como parece para muitos. Ele permite, aproveitando ao máximo a abordagem de teste baseada em cenários, 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 no desenvolvimento personalizado?