5 Características Importantes - Inspeção de Artefatos de Software

A inspeção de artefatos de software é um tipo de revisão que pode ser aplicado em todas as fases do ciclo de vida de um software, portanto quando aplicada da forma correta torna-se uma atividade cíclica e fundamental no processo de teste. Há algum tempo trabalho com inspeção de artefatos e é possível verificar que alguns problemas se repetem com certa frequência. Sendo assim, elencarei abaixo 5 características que o analista deve possuir para realização de uma boa inspeção de artefatos.:

• Comprometimento - O analista deve entender que a inspeção é um processo sério e formal, que implica em ações impeditivas para construção do software e/ou geração de indicadores que irão demonstrar a qualidade do produto que está sendo desenvolvido.

• Análise Crítica - O analista deve sempre entender que não existe defeito "bobo", simplesmente existe defeito! Portanto é essencial que o analista tenha uma visão pontual do artefato que está inspecionando e a visão global do processo. Também vale a pena ressaltar que "cada artefato é único", isto significa que o artefato deve ser inspecionado de forma isolada desconsiderando o que já foi inspecionado anteriormente (O analista deve se libertar da idéia: "Já inspecionei isto antes!"). O requisito do cliente é determinante, e uma vez que este seja previsto em checklists de verificação deve ser considerado como referência exclusiva.

• Conhecimento - Este é requisito básico e primordial para a inspeção. Um bom analista que realiza inspeção deve possuir atributos técnicos, conhecimento de negócio, entendimento de processo e documentação, bem como uma série de outros atributos. Aqui temos um ponto de atenção, pois este tipo de profissional quando alcança um certo grau de maturidade na função pode entender que alguns defeitos não são relevantes para o processo ou realizar a inspeção de forma automática, somente focando em pontos principais que defeitos ocorrem com maior frequência.

• Precisão e Autonomia - Deve-se ter a certeza absoluta de que o defeito identificado no artefato realmente é pertinente e passível de apontamento. Lembrando que qualquer apontamento realizado de forma incorreta, poderá acarretar em conflitos desnecessários e gerar enfraquecimento da imagem equipe de qualidade.

• Escrita - Ao identificar os defeitos, os mesmos serão documentados em alguma ferramenta ou documento específico. Dessa forma, o analista deve descrever o defeito com clareza, de forma sintética e buscando não ofender os responsáveis pela construção do artefato.

Testar é garantir a informação!

Simplificando... Garantia da Qualidade x Controle da Qualidade

Atualmente vemos uma grande confusão no mercado referente aos termos Garantia da Qualidade e Controle da Qualidade. Sem dúvidas que isto se deve ao fato de que em muitos casos os profissionais da área de tecnologia da informação não estão muito interessados na parte conceitual e teórica de seu trabalho. No entanto, este é um problema pois como posso trabalhar com algo que não sei nem explicá-lo? Ou pior, como posso querer trabalhar com algo que não quero nem explicá-lo? Pois é, e você sabe que este cenário é uma constante em nossa área.
 
Portanto, baseado em experiências de mercado, artigos de internet e livros específicos da área, neste post irei mostrar de forma simples e direta as diferenças entre Garantia e Controle da Qualidade de Software. Para distinguirmos estes termos, precisamos entender ao que se refere a Qualidade. "Qualidade é o grau no qual um conjunto de características inerentes satisfaz aos requisitos" (NBR ISO 9000:2005). No caso específico da Qualidade de Software, podemos entendê-la justamente da mesma forma, porém aplicada às necessidades e anseios do cliente referentes ao produto final de software, ou seja, o software deve estar em conformidade com todos os seus requisitos pré-determinados.

A Garantia da Qualidade de Software é um processo macro composto por algumas atividades como por exemplo o Teste de Software, Gerenciamento de Configuração e Controle da Qualidade. Na garantia de Qualidade o foco é na definição dos processos que darão subsídios e fornecerão confiança para que os produtos seja construídos corretamente de acordo com seus requisitos.

Diante desta definição, já podemos perceber que a Garantia da Qualidade é um processo macro que contempla em sua própria estrutura o Controle da Qualidade. Este por sua vez é focado em revisões e inspeções baseadas em checklists como foco na detecção e remoção de defeitos antes que os produtos sejam finalizados.

Na imagem abaixo, podemos verificar a relação entre os termos.:

A tabela abaixo demonstra as principais diferenças entre as duas atividades.:

Quality Assurance	Quality Control
1. Garantia da qualidade garante que o processo é definido e apropriado.	1. As atividades de controle da qualidade focam na descoberta de defeitos em i específicos.
2. Metodologia e padrões de desenvolvimento são exemplos de garantia da qualidade.	2. Um exemplo de controle da qualidade poderia ser: "Os requisitos definidos são os requisitos certos?".
3. Garantia da qualidade é orientada a processo.	3. Controle da qualidade é orientado a produto.
4. Garantia da qualidade é orientada a prevenção.	4. Controle da qualidade é orientado a detecção.
5. Foco em monitoração e melhoria de processo.	5. Inspeções e garantia de que o produto de trabalho atenda aos requisitos especificados.
6. As atividades são focadas no inicio das fases no ciclo de vida de desenvolvimento de software.	6. As atividades são focadas no final das fases no ciclo de vida de desenvolvimento de software.
7. Garantia da qualidade garante que você está fazendo certo as coisas e da maneira correta.	7. Controle da qualidade garante que os resultados do seu trabalho são os esperados conforme requisitos.

Fonte: Quality Assurance is not Quality Control.

Bom, como vimos os conceitos não possuem nenhuma dificuldade fora do comum mas sem o conhecimento dos mesmos torna-se inviável a estruturação de qualquer equipe de qualidade e/ou o entendimento de áreas que atuam baseadas nestes conceitos. Cada vez mais as grandes organizações entendem e investem em Qualidade de Software, portanto o envolvimento e comprometimento nesta área por parte dos profissionais já é tratado como um diferencial mercadológico.

Testar é garantir a informação!

Roteiros de Teste Unitário, Integrado e Funcional.: Tão simples assim?

Ao falarmos de forma isolada sobre roteiros de teste, todo analista crê que possui conceitos claramente definidos e completamente embasados em experiências anteriores de mercado, solicitações específicas de determinado cliente ou a aprendizagem de disciplinas em seu curso universitário. No entanto, basta que o analista sente em sua cadeira para modelar os casos unitários, integrados e funcionais de um mesmo projeto para todas as suas dúvidas, que outrora não existiam, começarem a surgir. 

Também não podemos esquecer que há um cenário pior ainda e muito comum.: Após a criação de todos os roteiros de teste, é perceptível que os mesmos possuem divergências, redundâncias e casos de teste desnecessários, mas o analista julga que está tudo correto e nem ao menos levanta dúvidas referente à modelagem dos casos de teste.

Tenho a certeza que você já passou por isso ou já viu ocorrer esta situação em seu local de trabalho. Portanto, iremos demonstrar as principais diferenças entre casos de teste para os roteiros de teste unitário, integrado e funcional, e para isto recorreremos aos principais autores, conceitos e técnicas disponíveis no mercado, bem como criaremos exemplos específicos que demonstrem na prática os diversos conceitos existentes. A intenção não é entrar especificamente na execução dos testes, mas sim demonstrar de forma simples as principais diferenças existentes e consolidar na sua mente todos os conceitos envolvidos. Existem diversas formas de construção para cada roteiro, e tentaremos abordar as melhores práticas para construção de cada um deles.

Utilizaremos um projeto (projetoCalculoSimples) contendo uma tela, 3 classes, 1 stored procedure e 1 acesso DB2 via programa cobol. Veja abaixo imagem detalhada do projeto contendo exemplos de teste unitário (em vermelho), teste integrado (em verde) e teste funcional (em azul).:

Após esta breve introdução, nos próximos 3 posts entraremos em detalhes específicos para a criação de cada roteiro.:

1°) Roteiros de Teste Unitário - "Pequenas partes que garantem a qualidade"
2°) Roteiros de Teste integrado - "Consolidando Relacionamentos"
3°) Roteiros de Teste Funcional - "Visualizando a funcionalidade na prática"

Testar é garantir a informação!