Testes de Qualidade (SQC)

Abril 9, 2008 at 6:20 pm Deixe um comentário

Eu sempre tive uma opinião um pouco divergente da maioria em relação a testes de qualidade. Para mim, a equipe de testes deve saber tanto quanto ou até mais que a equipe de desenvolvimento. Saber procurar um bug, investigar e dar a solução não é tarefa para qualquer um. E ao investigar aplicações .NET, é possível utilizar alguns recursos extras, que podem auxiliar e facilitar a vida dos testers.

Antes de tudo, é importante esclarecer do que exatamente estou falando. Qual é o tipo de teste a que estou me referindo e quando ele acontece.

Software Quality Control (SQC) consiste em verificar e validar a qualidade dos softwares envolvidos. Tecnicamente, este controle é efetuado através de testes (unit, integration ou system). Normalmente, este tipo de testes de software é realizado ao final do processo de desenvolvimento (ou de suas iterações), antes do produto entrar em homologação. O objetivo é garantir que o software desenvolvido está de acordo com os requisitos de negócio, funcionais e de qualidade de serviço (Quality of Service Requirement).

E aqui começa a dificuldade: como validar e garantir todas essas questões, e quais recursos podem auxiliar neste árduo trabalho?

Voltando ao processo, o teste de qualidade começa quando o desenvolvimento acaba (claro, não vamos entrar em detalhes de testes de desenvolvedor, etc). Portanto, a única “coisa” que o responsável pelo teste tem em mãos é um build (ASP.NET, Windows Formas, Smart Client, …), simples e direto. Muito provavelmente não terá em mãos os códigos-fonte, estrutura do projeto e detalhes da implementação. Por esse motivo, este build deve fornecer o máximo de informações para investigação técnica, através de arquivos PDB (Program Database) e versões em Debug.

Através destas informações, é possível localizar algum erro mais a fundo, onde ocorreu, o stack do CLR, o que estava na memória, onde as threads estavam paradas, entre outras informações importantes.

SQC não é uma tarefa fácil. Ao achar um erro, é necessário saber o que estava acontecendo em todo o ambiente. Se o erro é de OutOfMemory, por exemplo, o que ocasionou este erro, como o GC estava se comportando, como estava a aplicação neste momento. Por isso, equipe de testes tem que tem um conhecimento muito grande sobre todo o funcionamento do CLR, desde declarações de variáveis a threads, GC e concorrência.

Efetuar testes sem saber o que acontece por baixo dos panos não tem valor algum.
Reportar erros qualquer pessoa pode fazer. Descrever o porquê é o segredo de bons profissionais.

Abraços e até a próxima!

Anúncios

Entry filed under: Debugging.

Blog Chat sobre Debugging Sai uma moda, entra outra

Deixe uma Resposta

Preencha os seus detalhes abaixo ou clique num ícone para iniciar sessão:

Logótipo da WordPress.com

Está a comentar usando a sua conta WordPress.com Terminar Sessão / Alterar )

Imagem do Twitter

Está a comentar usando a sua conta Twitter Terminar Sessão / Alterar )

Facebook photo

Está a comentar usando a sua conta Facebook Terminar Sessão / Alterar )

Google+ photo

Está a comentar usando a sua conta Google+ Terminar Sessão / Alterar )

Connecting to %s

Trackback this post  |  Subscribe to the comments via RSS Feed


Calendário

Abril 2008
S T Q Q S S D
« Mar   Jun »
 123456
78910111213
14151617181920
21222324252627
282930  

Most Recent Posts


%d bloggers like this: