Infra - Segurança
TMap Next(Test Management Approach) - Técnicas de Avaliação(Evaluation) - Parte 7
O resultado de uma Avaliação(Evaluation) depende fortemente da atitude do(s) avaliador(es), afinal avaliamos documentos que são criados por outros.
por Fábio Martinho CamposIntrodução
O resultado de uma Avaliação(Evaluation) depende fortemente da atitude do(s) avaliador(es), afinal avaliamos documentos que são criados por outros.
Dependendo de como os defeitos(ou erros) forem registrados ou comunicados, o autor do documento pode se sentir atacado pelo resto do time, resultando em uma aspecto negativo da real intenção do processo de Avaliação(Evaluation).
É importante saber que a meta final do processo de Avaliação(Evaluation) é entregar o melhor produto de trabalho possível.
Técnicas de Avaliação(Evaluation) são muito recomendadas para melhorar e aumentar a qualidade do produto
Pesquisas têm mostrado que o processo de Avaliação(Evaluation) não são sempre implementados ou executados corretamente. Tal pesquisa ainda revela que:
q 56%dos autorestiveram dificuldadede se distanciar doseu trabalho
q 48% dos avaliadores não receberam o treinamento correto
q 47% dos autores ficam com medo que os dados sejam usados contra eles
O TMap Next cita e faz o uso de três principais técnicas para este fim:
q Inspeções(Inspections);
q Revisões(Reviews);
q Passo a passo(Walkthroughs).
O TMap Next usa como base a norma IEEE 1028(Standard for Software Reviews) para sua implementação.
Durante o processo de desenvolvimento de software, vários produtos intermediários são elaborados/criados.
Avaliação(Evaluation) é avaliar produtos intermediários no processo de desenvolvimento de sistemas
A avaliação intermediária de produtos não somente está limitada aos documentos do time de desenvolvimento. Avaliação(Evaluation) pode ocorrer em todos os níveis de documentação, como:
q Design funcional/técnico;
q Documento de requisitos;
q Plano de gerenciamento;
q Plano de desenvolvimento;
q Plano de teste;
q Documentação de manutenção do software;
q Manual do usuário e manual de instalação;
q Notas de release(Release notes);
q Design de teste;
q Script de teste;
q Protótipos;
q Screenshots de tela que são impressos;
q E muitos outros documentos usualmente encontrados nos projetos de desenvolvimento de software.
Praticamente, todo e qualquer documento do projeto é passível de uma Avaliação(Evaluation).
Outro aspecto importante no uso de Avaliações(Evaluations) é que defeitos podem e são encontrados antecipadamente no ciclo de desenvolvimento de software, antes mesmo do teste de software em si.
Isso porque Avaliações(Evaluations) verificam produtos intermediários e não como o teste de software que validam produtos finais. Como já sabemos quanto mais cedo um defeito for encontrado no ciclo de vida de desenvolvimento de software, mais barato ele será para ser corrigido(Regra 10 Myers).
Avaliações(Evaluations) têm demonstrado ser a maneira mais eficiente e eficaz para eliminar defeitos à partir de produtos intermediários do sistema.
Avaliação(Evaluation) é também um processo fácil de ser “configurado”, pois nenhum software ainda existe e conseqüentemente nenhum ambiente de teste precisa ser criado.
Técnicas de Avaliação(Evaluation) formais são caracterizadas pelo fato de várias pessoas avaliarem como um time, defeitos são documentados e existem vários procedimentos para executas as atividades de Avaliação(Evaluation).
Existem vários níveis de formalidade em Avaliações(Evaluations). Nem todos os produtos intermediários precisam ser avaliados igualmente e é por esta razao que é muito importante criarmos uma Estratégia de Avaliações(Evaluations).
Todas as técnicas de Avaliações(Evaluations) existentes seguem, praticamente, uma mesma estrutura(com exceção da introdução):
q Introdução;
q Responsabilidades;
q Critérios de entrada;
q Procedimentos;
q Critérios de saída.
Não vamos detalhar aqui cada um destes itens para cada uma das Avaliações(Evaluations) . No entanto, veremos quem são os responsáveis e procedimento de cada uma das técnicas Avaliações(Evaluations) a seguir:
Passo a passo(Walkthroughs)
Um Walkthrough é um método pelo qual o autor explica os conteúdos de um produto durante a reunião. Vários objetivos diferentes podem ser:
q Trazer a todos os participantes ao mesmo ponto de início, por exemplo: preparar-se para uma revisão ou inspeção;
q Transferir informação, por exemplo: desenvolvedores e testadores se ajudarem mutuamente nas suas atividades de programação e design de teste, respectivamente;
q Perguntar aos participantes por comentários e/ou informações adicionais;
q Permitir aos participantes escolher uma de várias alternativas propostas pelo autor.
Um Walkthrough pode ser realizado para qualquer um dos documentos já listados e quando os mesmos já estiverem 50-100% completos.
Responsabilidades
O número de participantes em uma reunião de Walkthrough é ilimitado se o autor desejar explicar o seu produto de trabalho para certos tipos de grupos. Os possíveis papéis para um Walkthrough podem ser:
q Moderador;
q Autor;
q Secretário;
q Participantes.
Procedimentos
O processo de um Walkthrough pode ser dividido nas seguintes fases:
- Planejamento
- Preparação
- Execução
Revisões(Reviews)
Existem vários tipos de Revisões, como: revisões técnicas, revisões gerenciais, revisões por pares(peer review) e revisões de experts .
A Revisão segue um método formal, aonde um produto de trabalho(60-80% completo) é enviado a um número de revisores com a questão de se avaliar à partir de uma certa perspectiva(dependendo do tipo de revisão). O auto coleta comentários e então realiza alguns ajustes no produto.
Uma Revisão foca primeiramente em achar alternativas para uma determinada solução, baseado no conhecimento e competência dos revisores, bem como achar e corrigir defeitos.
A Revisão de um produto acontece antecipadamente do ciclo de vida do produto.
Responsabilidades
O número mínimo de participantes em uma reunião de Revisão é três. Isso pode ser menos ainda em uma reunião de Revisão do tipo peer review. Os possíveis papéis em uma Revisão podem ser:
q Moderador;
q Autor;
q Revisor.
Procedimentos
O processo de uma Revisão pode ser dividido nas seguintes fases:
- Planejamento
- Preparação
- Execução
Inspeções(Inspections)
Existem várias formas do processo de inspeção, sendo que as maiores referencias mundiais para este são Tom Gilb e Michael Fagan .
Um trabalho formal é seguido quando executamos uma inspeção, com os produtos sendo lidos totalmente por um grupo de experts. Tais documentos podem ser qualquer um dos já listados.
Os inspetores procuram por desvios em critério pré-definidos, os quais devem estar 100% completos.
Além do fator de se escolher a solução mais adequada, uma inspeção foca primeiramente em atingir consenso na qualidade de um produto.
Aspectos para uma avaliação podem ser: conformidade do produto com certos padrões, especificações, regulamentos, diretrizes, planos e/ou procedimentos.
Responsabilidades
O número de participantes pode variar entre três a seis em uma reunião de Inspeção. Os possíveis papéis em uma Inspeção podem ser:
q Moderador;
q Autor;
q Secretário;
q Inspetor.
Procedimentos
O processo de uma Inspeção pode ser dividido nas seguintes fases:
- Planejamento
- Kick-off
- Preparação
- Execução
Matriz de Seleção para Técnicas de Avaliação(Evaluation)
Assim como o teste de software, cada organização e/ou projeto organiza os processos de Avaliação(Evaluation) de acordo com as suas realidades. Isso significa que não existe uma única forma universal descrita das técnicas de Avaliação(Evaluation) ou especificar uma técnica para uma situaçao específica.
Para tanto, o TMap Next oferece um auxílio na hora de selecionar uma das técnicas apresentadas anteriormente.
Veja a segui a Matriz de Seleção para Técnicas de Avaliação(Evaluation):
|
Aspect |
Inspection |
Review |
Walkthrough |
|
Area of application |
In addition to determining whether the solution is adequately processed, focuses primarily on achieving consensus on the quality of a product. |
Focuses primarily on finding courses for a solution and on finding and correcting defects. Review types include technical, management, peer and expert review. |
Focuses on choosing from alternative solutions, completing missing information, or knowledge transfer. |
|
Products to be evaluated |
For example: functional/technical design, requirements document, management plan, development plan, test plan, maintenance documentation, user/installation manual, software, release note, test design, test script, prototype, and screen print. |
||
|
Group size |
Three to six participants. |
At least three participants.
|
Two to seven participants in alternative version to unlimited for presentation version. |
|
Preparation |
Strict management of the aspects to be evaluated by the inspectors. Defects (based on checklists, standards, etc) described by inspectors to be delivered to the author before the meeting. |
Reviewers largely determine themselves which aspects they want to evaluate. Defects of reviewers to be delivered to the author before the meeting. |
From being informed of the product to delivering defects. |
|
Product status and size |
Product is 100% complete, not yet definitive and limited in size (10-20 pages). |
Product is 60%-80% complete and has a variable size. |
Product is 50%-100% complete and has a variable size. |
|
Benefits |
High quality, incidental and structural quality improvement. |
Limited labour intensity, early involvement of reviewers. |
High learning impact, low labour intensity. |
|
Disadvantages |
Labour-intensive (costly), relatively long lead time. |
Subjective, possible disturbance of collegial relationships. |
Risk of ad-hoc discussions because participants are often not prepared. |
Referências e Links:
- Livros utilizados para a base deste artigo e materiais de apoio
1. TMap Next, for result-driven testing
2. Software Testing: A guide to the TMap Approach
3. End-to-end testing with TMap Next
- Links
- Site TMap Next: http://eng.tmap.net/Home/
-TMap Next Downloads: http://eng.tmap.net/Home/TMap/Downloads/index.jsp
- Glossário TMap Next: http://eng.tmap.net/Home/TMap/Glossary.jsp
- Segurança em SistemasSegurança
- Direitos dos consumidores: Compras coletivas na mira da Justiça e do LegislativoSegurança
- Cuidados jurídicos ao tentar alavancar sua Startup digital ou de InternetSegurança
- Apagão da mão-de-obra em TI: A culpa é de quem? Segurança
- Anatel extrapola ao regulamentar guarda de logs pelos provedoresSegurança
