MPT.BR - Melhoria de Processo de Teste Guia de Implementação Parte 1: Nível 2 (Versão 1.1) Sumário 1 Prefácio... 3 2 Introdução... 3 3 Objetivo... 3 4 Implementando o MPT nível 2... 3 5 Gerência de Requisitos de Teste (GRT)... 4 5.1 Fundamentações teóricas... 4 5.2 Práticas específicas... 6 5.2.1 GRT1 Obter o entendimento dos requisitos de software e definir os requisitos de teste... 6 6.3.2 GRT2 Aprovar e obter o comprometimento com os requisitos de teste utilizando critérios objetivos... 7 6.3.3 GRT3 Estabelecer e manter a rastreabilidade bidirecional entre os requisitos e artefatos de teste... 8 6.3.4 GRT4 Realizar revisões em planos e produtos de trabalho do projeto e corrigir inconsistências identificadas em relação aos requisitos... 8 6.3.5 GRT5 - Gerenciar as alterações dos requisitos no projeto de teste.... 9 6 Práticas genéricas... 9 6.1 OG 1 Executar o processo... 9 6.1.1 PG 1.1 - Atingir os resultados definidos... 9 6.2 OG 2 Gerenciar o processo... 10 6.2.1 PG 2.1 Estabelecer e manter uma política organizacional para o processo 10 Melhoria de Processo de Teste Brasileiro MPT.BR Nível 2 v 1.1 1
6.2.2 PG 2.2 Planejar a execução do processo... 10 6.2.3 PG 2.3 - Monitorar e controlar a execução do processo para atender aos planos... 10 6.2.4 PG 2.4 Identificar e disponibilizar os recursos necessários para a execução do processo... 11 6.2.5 PG 2.5 Garantir que as pessoas que executam o processo são competentes em termos de formação, treinamento e experiência... 11 6.2.6 PG 2.6 Garantir a comunicação entre as partes interessadas no processo de forma a manter o seu envolvimento no projeto... 12 6.2.7 PG 2.7 - Monitorar e controlar o processo... 12 Melhoria de Processo de Teste Brasileiro MPT.BR Nível 2 v 1.1 2
1 Prefácio Este documento define as regras para implantação do MPT nível 2. 2 Introdução Para a implantação do MPT nível 2 entende-se que a empresa já foi credenciada no nível 1 e já tem o processo desse nível institucionalizado na organização. Em alguns casos específicos é aceitável que a empresa instale os dois níveis ao mesmo tempo, ficando essa decisão a cargo do implementador. 3 Objetivo Para implementar o nível 2 do MPT a organização precisará institucionalizar o uso do processo de Gerência de Requisitos de Teste (GRT). Para garantir a institucionalização de cada área de processo devem ser implementadas as práticas específicas e as práticas genéricas, conforme descrito adiante neste documento. A avaliação de que a unidade de teste alcançou um determinado nível será feita através da comprovação objetiva dos resultados alcançados e do exame das evidências (diretas, indiretas e afirmações) de que a empresa implantou cada uma das práticas específicas e genéricas para aquela área de processo e grau de maturidade visado. Desta forma temos a seguinte organização: Área de processo o Objetivos específicos Práticas específicas o Objetivos genéricos Práticas genéricas A organização poderá iniciar a implantação do modelo MPT pelo nível 2 desde que implemente paralelamente também o processo do nível 1 e que demonstre maturidade para assim proceder. 4 Implementando o MPT nível 2 O nível 2 do MPT contempla a seguinte área de processo: Gerência de Requisitos de Teste (GRT) Se tratarmos o projeto de teste como um projeto inter-relacionado ao projeto de desenvolvimento, não é difícil entender que ambos poderão se sustentar num mesmo processo de gerência de projetos e de gerência de requisitos, que Melhoria de Processo de Teste Brasileiro MPT.BR Nível 2 v 1.1 3
poderiam ser únicos para os dois. De qualquer forma o enfoque principal neste documento serão os projetos de teste de software. Para facilitar a gestão, é aconselhável que apenas empresas com um nível de maturidade alto de MPS ou CMMI decidam pelo uso de processos únicos para os dois tipos de projetos. Os mesmos requisitos que servem para desenvolver o software também servem para criar os artefatos de teste, inclusive porque muitas empresas produzem requisitos de teste a partir dos requisitos do usuário. Desta forma os requisitos de software são relevantes para o teste do software, e, além desses, existem ainda os requisitos específicos para o projeto de teste de software. De forma resumida podemos afirmar que os requisitos de teste são os requisitos de software, caso o escopo seja testar todo o software, acrescidos dos requisitos específicos de teste. No entanto, sugerimos que os requisitos sejam tratados por processos específicos de teste e de desenvolvimento. 5 Gerência de Requisitos de Teste (GRT) 5.1 Fundamentações teóricas O objetivo da área de processo Gerência de Requisitos de Teste é buscar junto aos fornecedores de requisitos aqueles inerentes ao projeto de teste de software. Esta gerência deverá garantir que não existe nenhuma inconsistência ou não conformidades na lista de requisitos, de forma a permitir que os artefatos deles provenientes, como, por exemplo, o Plano de Teste, possam vir a ser criados corretamente. Na maior parte das vezes os requisitos de software poderão também ser usados como requisitos de teste. A princípio deverão ser mantidos os requisitos de teste e os requisitos de desenvolvimento, embora organizações maduras possam ter uma gerência única para administrar ambos os requisitos. É importante frisar que os projetos de teste tratam requisitos de forma diferente do que são tratados pelos projetos de desenvolvimento. Um modelo mais simples, caso já exista uma área de processo de gerência de requisitos de software, seria criar uma outra área específica de gerência de requisitos de teste. Neste caso o cuidado deverá ser atualizar ambas listas de requisitos quando houver uma alteração de requisitos feita pelo fornecedor. Os requisitos de teste devem definir que nível de qualidade deve ser assegurado, que recursos de teste devem ser empregados, que equipes de teste serão utilizadas, e como se inter-relacionarão as equipes. Também podem existir Melhoria de Processo de Teste Brasileiro MPT.BR Nível 2 v 1.1 4
critérios (ou requisitos) de aceitação, incluídos na lista de requisitos de teste. Isso serve para mostrar como será demonstrada a funcionalidade, como será verificada a adequação do sistema, como serão examinados os requisitos não funcionais. Note que os requisitos de teste e os critérios de aceitação influenciam como deverá ser desenvolvido o software. Ou seja, na realidade, como é mencionado em parágrafo mais adiante, o conjunto de requisitos do sistema e de teste do sistema deveriam formar um todo integrado. Os requisitos de teste devem também cobrir os testes de aceitação. É função da área ou equipe de teste assegurar que os critérios de aceitação sejam atingidos, independentemente de se o cliente realizará ou não seus próprios testes de aceitação. Os requisitos do software normalmente são elaborados por um fornecedor de requisitos, normalmente o usuário, e são revistos pela equipe de desenvolvimento. Neste caso, a equipe de teste deverá receber os mesmos requisitos após o seu tratamento pela equipe de desenvolvimento, ou, melhor ainda, trabalhar junto com a equipe de desenvolvimento para poder desta forma elaborar os requisitos de teste. Cabe esclarecer que os fornecedores de requisitos poderão ser diversos, tais como clientes, usuários finais, legislações, etc. A partir dos requisitos de desenvolvimento enviados pelos fornecedores de requisitos é gerada uma lista e deverá ser firmado um acordo de comprometimento envolvendo todas as partes, fornecedor de requisitos, equipe de desenvolvimento e equipe de teste. Outras partes poderão estar envolvidas caso seja necessário. Esta lista deverá também conter os requisitos não técnicos, como aqueles referentes a orçamento e prazo. As práticas específicas nesta área de processo deverão envolver o seguinte: Criação de uma especificação e/ou lista de requisitos; Revisão técnica de todos os requisitos; Geração de um documento (lista de requisitos) com o qual todos os interessados estarão comprometidos; Criação de um documento que permita a rastreabilidade dos casos de teste e a sua relação com os requisitos que os originaram; Controle das alterações dos requisitos; O monitoramento dos requisitos durante toda a evolução do projeto de teste; O controle dos requisitos durante toda a evolução do projeto de teste. Melhoria de Processo de Teste Brasileiro MPT.BR Nível 2 v 1.1 5
A elaboração do Plano de Teste deverá ter início após o recebimento dos requisitos aprovados pelos interessados e envolvidos. Isso deve ser feito em comum acordo com a equipe do projeto de desenvolvimento e outras partes interessadas sempre que for possível. 5.2 Práticas específicas 5.2.1 GRT1 Obter o entendimento dos requisitos de software e definir os requisitos de teste A aplicação desta prática permite que seja alcançado o entendimento dos requisitos através de contatos mantidos com os fornecedores de requisitos. Para tal, a organização deverá ter alguns critérios pré-estabelecidos para que os requisitos possam ser entendidos corretamente e aceitos. Por entendimento dos requisitos considera-se também a definição dos requisitos específicos do projeto de teste de software. O Plano de Teste deverá identificar os fornecedores de requisitos e também como será feita a comunicação com eles. Com a execução desta prática deve-se conseguir um entendimento completo dos requisitos e a forma como os requisitos deverão ser enviados para o projeto. Isso significa dizer que requisitos somente poderão ser aceitos através de uma fonte perfeitamente identificada como fornecedores de requisitos. Não deve ser descartado que num ciclo de desenvolvimento incremental os requisitos poderão ser acrescidos à medida que o projeto evolui. Neste caso o Plano de Teste deverá prever esta alternativa e poder ser atualizado com facilidade. Ou seja, a medida que novos requisitos forem sendo fornecidos a lista será gradualmente alterada. Outras formas de ciclo de vida de desenvolvimento e teste deverão também estar previstas no monitoramento dos requisitos. Os requisitos deverão ser aceitos com base em critérios objetivos. Por exemplo, deve atender a seguinte pergunta: Está previsto o teste deste requisito no orçamento do projeto? Ou, o prazo do projeto contempla o teste deste requisito? O ideal seria a organização manter uma relação de perguntas básicas para facilitar a aceitação dos requisitos. 1) Lista dos fornecedores de requisitos; 2) Critérios para avaliação e aceitação dos requisitos; 3) Uma especificação ou lista de requisitos aprovada pelos interessados no projeto; Melhoria de Processo de Teste Brasileiro MPT.BR Nível 2 v 1.1 6
4) Documento mostrando que a especificação ou lista de requisitos está em conformidade com os critérios de aceitação pré-estabelecidos. Os requisitos, para serem aceitos, precisam ser submetidos a alguns critérios. Alguns exemplos de critérios para aceitação de requisitos são os seguintes: 1) Os requisitos devem ter uma definição completa; 2) Os requisitos precisam ser consistentes e coerentes em relação aos outros requisitos; não podem se sobrepor ou conflitar; 3) Os requisitos precisam ser definidos sem ambigüidades e numa linguagem clara de fácil entendimento por todos os interessados; 4) Cada requisito deve ser único considerando um mesmo projeto; 5) Todos os requisitos devem ser testáveis (verificáveis e validáveis e aceitáveis); 6) O requisito deve ser rastreável através dos artefatos do projeto. Na análise dos requisitos deve sempre ser preservada a ótica do teste do software. Por exemplo, um requisito que exija um tempo de resposta adequado à natureza do negócio significa que a conformidade do artefato com esse requisito deverá ser examinada através de um teste de desempenho. 6.3.2 GRT2 Aprovar e obter o comprometimento com os requisitos de teste utilizando critérios objetivos Os requisitos devem ser aprovados pelas partes interessadas no projeto de teste de software. A aprovação da lista final dos requisitos pode ser feita através de uma ata de reunião ou outro documento formal onde as partes envolvidas aprovam o seu conteúdo através de assinaturas ou de e-mails enviados ou por outro meio eletrônico qualquer. O importante é que se tenha um registro formal da aprovação da lista final de requisitos. Neste caso entende-se que foram feitas inúmeras reuniões até que por consenso chegou-se a lista final de requisitos. A aprovação seria apenas um processo formal de aceite. 1) Documento contendo a lista dos requisitos aprovados 2) Documento onde as partes envolvidas aprovam os requisitos. As organizações devem possuir critérios a serem usados na avaliação e aprovação dos requisitos. Algumas empresas tem um documento com uma lista de verificação para cada um requisito. Os requisitos devem ser aceitos de acordo com esse critério. Por exemplo, uma pergunta poderia ser se os requisitos são passíveis de teste. Ou seja, se existem recursos para o seu teste. Melhoria de Processo de Teste Brasileiro MPT.BR Nível 2 v 1.1 7
6.3.3 GRT3 Estabelecer e manter a rastreabilidade bidirecional entre os requisitos e artefatos de teste No caso dos projetos de teste de software, é necessário que a rastreabilidade permita fazer uma associação entre os casos de teste e os requisitos que estes casos de teste estão testando. Evidentemente, esse encadeamento irá passar pelos artefatos de desenvolvimento até chegar aos casos de teste. A rastreabilidade pode ser criada através de ferramentas de automação específicas ou através de planilhas manuais. O entendimento é que, normalmente, a matriz de rastreabilidade do projeto de desenvolvimento, caso exista, será a mesma que atenderá ao projeto de teste, desde que contemple os requisitos e os casos de teste. 1) Matriz de rastreabilidade 2) Mecanismo que permita rastrear os requisitos até os casos de teste A rastreabilidade deve ser horizontal e vertical. Por exemplo, um caso de teste pode ser usado para testar mais de um requisito. Além disso deve ser possível fazer o rastreamento nas duas direções, ou seja, rastreamento bidirecional. 6.3.4 GRT4 Realizar revisões em planos e produtos de trabalho do projeto e corrigir inconsistências identificadas em relação aos requisitos Deve ser demonstrado que foi feita uma revisão envolvendo os requisitos e todos os produtos gerados pelo projeto, inclusive o Plano de Teste. As inconsistências devem ser identificadas e as ações corretivas devem ser registradas e monitoradas até a sua conclusão. Cabe esclarecer que a inspeção: - a inspeção produz um laudo; - após a inspeção as não conformidades são priorizadas; - as não conformidades são resolvidas correta e completamente em ordem de prioridade. Cabe esclarecer que nem sempre todas as não-conformidades precisam ser resolvidas naquele momento, mas podem ser definidas com uma prioridade baixa e ficar para uma outra etapa. 1) Registros de não conformidades. Melhoria de Processo de Teste Brasileiro MPT.BR Nível 2 v 1.1 8
2) Ações corretivas e o controle dessas ações até a sua conclusão com as respectivas aprovações. 6.3.5 GRT5 - Gerenciar as alterações dos requisitos no projeto de teste. Esta prática estabelece que as alterações dos requisitos devem ser gerenciadas durante a evolução do projeto de teste de software. Entende-se que as alterações de requisitos só podem ser recebidas através de um documento formal de um fornecedor de requisitos. Desta forma, a solicitação de uma alteração de requisito ou da inclusão de um novo requisito ou da exclusão de um requisito deve ser avaliada de acordo com os critérios definidos para a avaliação e aprovação de requisitos. Além disso, deve ser avaliado o impacto que tal mudança trará no projeto. Toda a documentação envolvendo a solicitação de mudança, a análise de impacto e o monitoramento dessas mudanças deverão estar disponíveis no repositório de artefatos do projeto. 1) Nova versão da especificação ou lista de requisitos aprovada; 2) Relatório do estudo do impacto da alteração no projeto; 3) Relatórios do estudo de viabilidade para a aprovação da mudança; 4) Atas de reunião monitorando as alterações; 5) Aprovação dos novos requisitos segundo critérios técnicos estabelecidos. Muitas vezes, uma alteração de um requisito ou o surgimento de um novo requisito envolve o surgimento de um novo risco, o que significa dizer que a lista de riscos poderá também sofrer um impacto com esta mudança. 6 Práticas genéricas Práticas genéricas (PG) e objetivos genéricos (OG) são assim chamados porque os mesmos devem ser seguidos por todas as áreas de processo. 6.1 OG 1 Executar o processo Este atributo é uma medida do quanto o processo atinge o seu propósito. Este atributo serve para mostrar que o processo está implantado, que atende aos seus objetivos e que são cumpridas as práticas específicas. 6.1.1 PG 1.1 - Atingir os resultados definidos Para garantir que o processo esteja institucionalizado é preciso ter o processo disseminado na organização e que o mesmo sirva de base para a geração dos produtos a que se refere. É importante lembrar que é preciso o comprometimento da alta administração. Melhoria de Processo de Teste Brasileiro MPT.BR Nível 2 v 1.1 9
Processo definido e institucionalizado (GRT) Plano de Projeto incluindo a lista de requisitos. 6.2 OG 2 Gerenciar o processo Este atributo é uma medida do quanto à execução do processo é gerenciada. 6.2.1 PG 2.1 Estabelecer e manter uma política organizacional para o processo Deve ser evidente a importância atribuída ao processo GRT e, como tal, ele deve ser seguido por todas as áreas envolvidas. Entende-se que a alta gerência deve estar compromissada com o processo. Desta forma a organização como um todo deve ter conhecimento pleno o processo. Manual de qualidade reconhecendo a importância do processo de gerência de requisitos de testes demonstrando é efetivamente mantido Documentos afixados em locais de alta circulação na organização Registro na intranet de uma publicação que divulgue a obrigatoriedade do cumprimento dos processos. 6.2.2 PG 2.2 Planejar a execução do processo O processo deve fornecer meios para que seja feito um planejamento para o projeto usando as regras estabelecidas. Entende-se que deve ser também monitorado se o processo está sendo considerado no andamento do projeto. O Plano de Teste normalmente é uma evidência de que essa PG vem sendo cumprida para o MPT. O que se quer é que seja demonstrado que está sendo cumprido o que é dito no processo para o planejamento do projeto. Plano de Teste com a lista de requisitos ou, em alguns casos, o Plano de Gerência de Requisitos Processo de Gerência de Requisitos de Teste (GRT). 6.2.3 PG 2.3 - Monitorar e controlar a execução do processo para atender aos planos O processo deverá fornecer informações que garantam o monitoramento do projeto e que as não-conformidades sejam registradas e controladas até o seu acerto. Eventualmente poderão ser identificadas inadequações no próprio Melhoria de Processo de Teste Brasileiro MPT.BR Nível 2 v 1.1 10
processo, que devem ser registradas em documento próprio, e o acerto deve ser monitorado até a sua conclusão. Usar o processo é uma das formas de gerenciálo e monitorá-lo. O que se quer é que seja demonstrado que está sendo cumprido o que é dito no processo para a monitoração do projeto. Produto típico: Atas de reunião de acompanhamento do projeto Processo de Gerência de Requisitos de Teste (GRT) Relatório de falhas registradas; 6.2.4 PG 2.4 Identificar e disponibilizar os recursos necessários para a execução do processo Para que o processo seja executado através do projeto é preciso que os recursos necessários estejam claramente definidos. Por recursos entende-se pessoal, software, hardware, recursos financeiros, ambiente, etc. Produto típico: Plano de recursos do projeto - ver Plano de Teste. Processo de Gerência de Requisitos de Teste (GRT) 6.2.5 PG 2.5 Garantir que as pessoas que executam o processo são competentes em termos de formação, treinamento e experiência A organização deverá assegurar que as pessoas que executam os processos estão habilitadas. Isso implica treinamentos nos próprios processos como também em técnicas de gerência de projetos e gerência de requisitos. No caso do uso de ferramentas específicas deverá haver comprovação de que as pessoas foram treinadas para o seu uso. Produto típico: Registros de treinamentos realizados (GRT e GPT), tais como folhas de presença assinadas ou certificados. Treinamentos em estimativas, riscos, planejamento, etc. Processo de capacitação e treinamento. Na verdade esta prática exige que as pessoas envolvidas no processo tenham sido de alguma forma treinadas. Outros produtos típicos, dependendo da circunstância, poderão vir a ser aceitos. Melhoria de Processo de Teste Brasileiro MPT.BR Nível 2 v 1.1 11
6.2.6 PG 2.6 Garantir a comunicação entre as partes interessadas no processo de forma a manter o seu envolvimento no projeto As partes interessadas no processo devem ter o seu envolvimento garantido no projeto. Para isso é importante que recebam as informações e artefatos de seu interesse, e que isso faça parte do plano do projeto de teste. O envolvimento também pode ocorrer através de reuniões previamente planejadas no próprio Plano de Projeto. Produto típico: Plano de comunicação do Plano de Teste Atas de reunião de acompanhamento do projeto. Processo de Gerência de Requisitos de Teste. 6.2.7 PG 2.7 - Monitorar e controlar o processo Deve haver um acompanhamento sistemático da evolução do processo gerência de requisitos de teste, de forma a evitar que mudanças inesperadas de rumo ocorram. Isso deverá ser feito nos diversos níveis de decisão da organização e não apenas nos níveis técnicos. Normalmente essas ações estarão explicitadas no cronograma do Plano de Teste, na sua parte referente ao Plano de Comunicação. É importante que os problemas ou não conformidades sejam registrados num documento formal e sejam monitoradas até a sua conclusão. Produto típico: Atas de reunião de acompanhamento do projeto em diversos níveis (acompanhamento técnico e gerencial); Documentos que comprovem o envolvimento das partes envolvidas no andamento do projeto; Plano de Teste; Processo de Gerência de Requisitos de Teste. Melhoria de Processo de Teste Brasileiro MPT.BR Nível 2 v 1.1 12