SIPTEST System Intelligent Process Testing. Estado da arte na prática de testes tendo como referência o CMMI

(1)

SIPTEST - System Intelligent Testing Link Consulting,SA | Pág. 0 de 10

SIPTEST – System Intelligent Process Testing.

Estado da arte na prática de testes tendo como referência o

CMMI

(2)

SIPTEST - System Intelligent Process Testing Link Consulting,SA | Pág. 1 de 10

Índice

1 Introdução... 2

2 Objectivo genérico 2 – Integrar um Processo de Gestão ... 3

2.1 Prática Genérica 2.1 - Estabelecer uma política organizacional ... 3

2.2 Prática Genérica 2.2 - Planear o processo ... 3

2.3 Prática Genérica 2.3 - Providenciar recursos ... 3

2.4 Prática Genérica 2.4 - Atribuir responsabilidades ... 3

2.5 Prática Genérica 2.5 - Treinar as pessoas ... 4

2.6 Prática Genérica 2.6 - Gerir configurações ... 4

2.7 Prática Genéricas 2.7 - Identificar e envolver os stakeholders ... 4

2.8 Prática Genérica 2.8 - Monitorizar e controlar o processo ... 4

2.9 Prática Genérica 2.9 - Avaliar objectivamente ... 4

2.10 Prática Genérica 2.10 - Rever o estado com uma gestão de nível superior ... 5

3 Objectivo Genérico 3 - Institucionalizar um Processo Definido ... 6

3.1 Prática Genérica 3.1 - Estabelecer um processo definido ... 6

3.2 Prática Genérica 3.2 - Recolher informações de melhoria ... 6

4 Verificação e Validação em CMMI ... 7

4.1 Verificação em CMMI ... 7

4.2 Validação em CMMI ... 7

(3)

1 Introdução

Antes de iniciar um projecto de melhoria é necessário conhecer qual o nível de maturidade dos processos de teste existentes na organização. Portanto, a actual situação da organização tem que ser inicialmente avaliada. A avaliação torna claro que informação e que procedimentos estão em curso, e especialmente o que precisa ser melhorado. Este documento descreve todos os objectivos genéricos bem como as práticas genéricas do modelo TMMi e que derivam do modelo CMMI, e no final identifica outras acções (Verificação & Validação) que podem melhorar a qualidade do software desenvolvido segundo CMMI. Ao longo do documento, tanto os objectivos genéricos como as práticas genéricas estão devidamente organizadas numericamente. O objectivo genérico 1 ‘Atingir Objectivos Específicos’ (derivado do CMMI) não foi tomado em conta já que diz apenas respeito à representação contínua do CMMI, e portanto não tem relevância para a representação hierárquica do TMMi. No entanto, o esquema numérico do CMMI foi totalmente adoptado para evitar confusões para as organizações que utilizam tanto CMMI como TMMi. O nível de maturidade que a organização tem como meta determinará quais os objectivos genéricos e quais as práticas que deverão ser aplicáveis. Quando a organização tenta alcançar o nível de maturidade 2, as áreas de processo do nível 2 assim como os objectivos genéricos de nível 2, terão que ser aplicados. Os objectivos genéricos de nível 3 são aplicados quando a organização tenta atingir a maturidade de nível 3 ou superior. Isto significa que quando a organização atinge o nível de maturidade 2, para atingir o nível de maturidade superior (nível 3) a organização terá que aplicar às áreas de processo do nível 2 e aplicar os objectivos genéricos de nível 3 e aplicar as práticas dessas áreas de processo.

(4)

2 Objectivo genérico 2 – Integrar um Processo de Gestão

Um processo de gestão é um processo que realiza o trabalho necessário para produzir produtos. É planeado e executado de acordo com a política, emprega pessoas qualificadas e tem recursos suficientes para produzir outputs controlados. Um processo de gestão envolve os stakeholders, a monitorização e controlo, e é submetido a revisões e avaliado segundo as descrições dos seus processos. O processo pode ser instanciado por um projecto, por um grupo ou por uma unidade organizacional.

2.1 Prática Genérica 2.1 - Estabelecer uma política organizacional

A finalidade desta prática genérica é definir as expectativas organizacionais para o processo e assegurar que essas expectativas são partilhadas dentro da organização. Em geral, um gestor sénior é responsável por estabelecer e comunicar os princípios orientadores, direcções e as expectativas para a organização.

2.2 Prática Genérica 2.2 - Planear o processo

O propósito desta prática genérica é determinar o que é necessário para executar determinado processo e para alcançar os objectivos estabelecidos; preparar um plano para executar o processo; preparar uma descrição do processo e chegar a acordo sobre o plano com os stakeholders através da realização de revisões.

2.3 Prática Genérica 2.3 - Providenciar recursos

A finalidade desta prática genérica é assegurar que os recursos necessários para executar o processo estão definidos e disponíveis quando estes são necessários. Os recursos incluem um financiamento suficiente, adequadas

instalações físicas, pessoas qualificadas e ferramentas apropriadas.

2.4 Prática Genérica 2.4 - Atribuir responsabilidades

O propósito desta prática genérica é assegurar que existe alguém com a responsabilidade para executar o processo e alcançar resultados específicos durante essa execução. As pessoas designadas devem ter uma autoridade adequada para desempenhar as responsabilidades atribuídas. As responsabilidades podem ser atribuídas usando descrições detalhadas das tarefas como, por exemplo, o plano para executar o processo.

(5)

2.5 Prática Genérica 2.5 - Treinar as pessoas

A finalidade desta prática genérica é garantir que as pessoas têm as competências e conhecimentos necessários para realizar ou apoiar o processo. A formação adequada é fornecida às pessoas que executam as tarefas. O treino é fornecido para orientar as pessoas que interagem com aqueles que executam as tarefas.

2.6 Prática Genérica 2.6 - Gerir configurações

O objectivo desta prática genérica é estabelecer e manter a integridade das tarefas do processo. As tarefas são especificamente identificadas no plano de execução do processo juntamente com uma especificação do nível de gestão de configuração, por exemplo controlo de versões, o histórico de mudanças e controlo, identificação e uso de ferramentas, etc.

2.7 Prática Genéricas 2.7 - Identificar e envolver os stakeholders

A finalidade desta prática genérica é estabelecer e manter o envolvimento dos stakeholders durante a execução do processo. Os stakeholders são envolvidos em actividades como planeamento, decisões, compromissos,

comunicações, revisões e resolução de problemas.

Para o processo de teste os stakeholders incluem gestores e utilizadores/clientes. O papel do gestor envolve compromissos e a capacidade para executar actividades e tarefas relacionadas com a melhoria da capacidade de teste. O papel dos utilizadores/clientes envolve uma cooperação, apoio e às vezes a realização de actividades de teste. O foco desta cooperação é a solicitação do apoio, consenso e a participação do utilizador em actividades tais como a análise de risco, testes de aceitação e, possivelmente, testes de usabilidade. Dependendo do nível de teste o programador pode também ser um dos stakeholders, por exemplo, o programador pode também executar tarefas relacionadas com testes unitários; no entanto, ao nível dos testes de aceitação o programador torna-se um dos stakeholders para discutir incidentes encontrados, concordar ou não com os critérios, etc.

2.8 Prática Genérica 2.8 - Monitorizar e controlar o processo

O objectivo desta prática genérica é realizar a monitorização e o controlo directo do processo de teste. Uma análise apropriada sobre o processo de teste é mantida de modo que a acção correctiva possa ser executada assim que seja necessária. Monitorizar e controlar o processo envolve a medição de atributos apropriados do processo de teste e do output produzido por esse processo de teste.

2.9 Prática Genérica 2.9 - Avaliar objectivamente

A finalidade desta prática genérica é fornecer garantias credíveis de que o processo é implementado como planeado, respeitando a sua descrição, padrão e procedimentos. Em muitos casos, a avaliação é realizada por pessoas da própria organização, mas externas ao processo de teste ou ao projecto

(6)

2.10 Prática Genérica 2.10 - Rever o estado com uma gestão de nível superior

O objectivo desta prática genérica é proporcionar uma gestão de alto nível com a visibilidade apropriada do processo. A gestão de alto nível inclui os níveis de gestão da organização imediatamente acima do nível de gestão responsável pelo processo.

(7)

3 Objectivo Genérico 3 - Institucionalizar um Processo

Definido

Um processo definido é normalizado, tanto quanto o possível em toda a organização e adaptado somente quando necessário para um projecto em específico ou uma organização, com base nas suas directrizes. Os processos

definidos mantêm a descrição dos processos, medições e outras informações para melhoria dos processos activos na organização.

3.1 Prática Genérica 3.1 - Estabelecer um processo definido

A finalidade desta prática genérica é estabelecer e manter uma descrição do processo, que é a adaptação do conjunto de padrões de processos da organização, para responder às necessidades da organização. A organização deve ter processos de normalização que cubram áreas de processo, bem como orientações para adequar esses processos às necessidades de um projecto. Com um processo definido, a variabilidade na forma como os processos são realizados em toda a organização é reduzida. Dessa forma os dados e a aprendizagem podem, inclusive, ser partilhados com outras áreas da organização ou outras organizações.

3.2 Prática Genérica 3.2 - Recolher informações de melhoria

O objectivo desta prática genérica é recolher informação e artefactos derivados do planeamento para uso futuro e melhoria dos processos da organização. As informações e os artefactos são armazenados, possibilitando a partilha para aqueles que querem planear e executar processos semelhantes.

(8)

4 Verificação e Validação em CMMI

Durante e após o processo de desenvolvimento, o programa desenvolvido deve ser verificado para garantir que responde às especificações e fornece as funcionalidades esperadas. O modelo CMMI contempla dois processos de controlo e análise para avaliação do software desenvolvido: Verificação e Validação (V & V) [7]. A Verificação e Validação inicia-se com a revisão dos requisitos e continua através das revisões de design e inspecções de código. Verificação e Validação não são a mesma coisa, embora muitas vezes sejam confundidas. Boehm explicou a diferença entre os dois processos da seguinte forma:

 Verification: “Are we building the product right?”  Validation: “Are we building the right product?”

O objectivo principal do processo V & V é estabelecer confiança de que o sistema de software é ‘adequado à finalidade’. Isto significa, que o sistema deve ser suficiente para a utilização pretendida.

4.1 Verificação em CMMI

A Verificação inclui verificação do produto, bem como todos os intermediários relacionados com os requisitos, incluindo clientes, requisitos dos produtos, etc. A Verificação é inerente a um processo incremental, pois ocorre durante todo o desenvolvimento do produto, começando com a verificação dos requisitos, progredindo através da verificação do produto em evolução, e culminando com a verificação do produto terminado. Os objectivos e as práticas descritas no modelo CMMI para o processo de verificação são:

1) Objectivo Específico 1 - Preparar a Verificação

a. Prática Específica 1.1 - Seleccionar Produtos para Verificação b. Prática Específica 1.2 - Estabelecer um Ambiente de Verificação

c. Prática Específica 1.3 - Estabelecer Procedimentos e Critérios de Verificação 2) Objectivo Específico 2 - Realizar Revisões

a. Prática Específica 2.1 - Preparar Revisões b. Prática Específica 2.2 - Executar Revisões

c. Prática Específica 2.3 - Analisar os Dados das Revisões 3) Objectivo Específico 3 - Verificar Produtos Seleccionados

a. Prática Específica 3.1 - Realizar a Verificação

b. Prática Específica 3.2 - Analisar os Resultados da Verificação

4.2 Validação em CMMI

Actividade de Validação pode ser aplicada a qualquer aspecto do produto em qualquer ambiente de execução, tais como, operação, treino, produção, manutenção e suporte. A Validação demonstra que o produto irá cumprir o seu

(9)

propósito, por outras palavras, a validação assegura que se desenvolveu o correcto produto. As actividades de validação utilizam abordagens semelhantes à verificação (exemplo, teste, análise, inspecção, demonstração, simulação). Regularmente os utilizadores finais e outros stakeholders relevantes estão também envolvidos em actividades de validação. Os objectivos e as práticas descritas no modelo CMMI para o processo de validação são:

1) Objectivo Específico 1 - Preparar a Validação

a. Prática Específica 1.1 - Selecionar Produtos para Validação b. Prática Específica 1.2 - Estabelecer um Ambiente de Validação

c. Prática Específica 1.3 - Estabelecer Procedimentos e Critérios de Validação 2) Objectivo Específico 2 - Validar Produtos ou Componentes de Produtos

a. Prática Específica 2.1 - Realizar a Validação

b. Prática Específica 2.2 - Analisar os Resultados da Validação

O TMMi é um guia e uma referência para melhorar o processo de teste de qualquer organização. O modelo pode também ser considerado como o “modelo”, uma descrição generalizada de como uma actividade, neste caso de teste deve ser feita. O TMMi pode ser usado para complementar o CMMI (uma abordagem para melhoria de processos), ou de forma independente. Aplicando o TMMi para avaliar e melhorar um processo de teste de uma organização, a produtividade desta deverá aumentar e por consequentemente a qualidade do produto final.

(10)

5 Referências

[1] M.B. Chrissis, M. Konrad, e S. Shrum. CMMI: Guidelines for Process Integration and Product Improvement. The SEI Series in Software Engineering. Addison-Wesley, 2003.

[2] T. Suwannasart. Towards Development of a Testing Maturity Model. Illinois Institute of Technology, 1996. [3] I. Burnstein. Practical Software Testing: A Process-Oriented Approach. Springer Professional Computing. Springer, 2003.

[4] E.P.W.M. Veenendaal e H.J.J. Cannegieter. The Little TMMi: Objective-driven Test Process Improvement. UTN Publishers, 2011.

[5] Cap Gemini Sogeti (Firm). TPI R Next: Business Driven Test Process Improvement. UTN Publishers, 2009. [6] TMMi Foundation. TMMi Reference Model. http://www.tmmifoundation.org/html/resources.html, 2012. [7] I. Sommerville. Software engineering. International computer science series. Addison-Wesley, 2007.

[8] B. W. Boehm. Guidelines for Verifying and Validating Software Requirements and Design Specifications. Em P. A. Samet, editor, Euro IFIP 79, páginas 711–719. North Holland, 1979.