Você sabe o que é um teste de software e quais são os principais tipos de teste de software? Neste artigo você vai tirar todas as suas dúvidas.

Por mais que se planeje a construção de um software, erros são passíveis de ocorrer. Pode ser um bug num game, uma falha que feche um programa ou um erro que impossibilite você salvar um arquivo.

Quem já passou por esse tipo de situação sabe como é chato quando ficamos na mão por culpa de um programa com falhas. O teste de software serve justamente para tentar encontrar possíveis erros que um programa recém-desenvolvido possa apresentar, de modo a conseguir corrigi-lo antes que seja lançado no mercado, ficando disponível para uso do público.

O teste de software geralmente é a última etapa na construção de um programa, visando checar o seu nível de qualidade. Os defeitos que um teste busca identificar incluem erro de compatibilidade, de algum algoritmo, de requisitos que não podem ser complementados, limitação de hardware etc. A lista é grande e aumenta com o tamanho do programa.

Quais os tipos de testes de software?

Existem diferentes tipos de testes que podem ser aplicados num software para identificar suas falhas, sendo as principais:

– Teste da caixa branca – utiliza o aspecto interno do programa/sistema, o código fonte, para avaliar seus componentes. Ele também é conhecido como teste orientado à lógica ou estrutural. Podem ser analisados itens como: fluxo dos dados, condição, ciclos etc. Na hora de implementá-lo é preciso verificar a criticidade, a complexidade, a estrutura e o nível de qualidade que se pretende obter do programa, envolvendo confiança e segurança;

– Teste da caixa preta – diferente do teste anterior, que prioriza os aspectos internos, o teste da caixa preta verifica aspectos externos. Os requisitos funcionais do sistema são avaliados. Não se observa o modo de funcionamento, sua operação, tendo como foco as funções que deverão ser desempenhadas pelo programa. Desse modo, avalia-se se um grupo de entrada de dados resultou nas saídas pretendidas, levando-se em consideração a especificação do programa. Ou seja, o que se esperava que o software deveria fazer. É conhecido também como técnica funcional;

– Teste da caixa cinza – esse tipo de teste une os dois anteriores, por isso o termo “cinza”. Avalia tanto os aspectos internos quanto os externos, de entrada e saída. Pode utilizar-se de engenharia reversa;

– Teste de regressão – esse consiste em realizar testes a cada versão de um software, onde se modificam-se funcionalidades. Desse modo, evita-se que erros que foram corrigidos antes no software antes voltem a aparecer na hora de se incrementar algo novo a ele.

– Teste de unidade – testa-se unidades menores de um software, de modo isolado, para ver se todas funcionam adequadamente;

– Teste de integração – depois das unidades testadas, realiza-se uma verificação se elas funcionam juntas, integradas. Pode ocorrer delas apresentarem incompatibilidades ao funcionarem em conjunto, mesmo após terem sido aprovadas no teste de unidade;

– Teste de carga – esse teste é feito para avaliar os limites de uso do software, o quanto ele suporta em volume de informações, tráfego etc. sem que apresente erros;

– Teste de usabilidade – esse teste é feito por um pequeno grupo de usuários para ver se o software satisfaz as suas necessidades. Nesse teste analisa-se como o usuário usa o sistema, verificando onde ele tem mais dificuldade. Ouve-se também suas impressões, porém é preciso confrontá-las com as observações do avaliador;

– Teste de stress – aqui leva-se o software ao seu limite de potência e funcionamento, para mais ou para menos, de modo a avaliar em qual ponto ele deixa de funcionar adequadamente. Isso é feito para verificar se suas especificações máximas ou mínimas de uso estão corretas.

O que é um plano de teste de software?

Um plano de teste é feito para colaborar com o desenvolvimento de um software. É por meio desse plano que os componentes técnicos, funcionais, estruturais etc. serão verificados e validados, de modo a garantir o bom funcionamento do programa junto ao usuário final. Sendo assim, um plano de teste de software tem como foco garantir a confiabilidade e segurança de um software, identificando possíveis erros e falhas durante a sua confecção, ou mesmo depois.

Ele deve ser planejado em conjunto com a proposta do software, sendo aplicado em cada etapa do projeto e não somente no final.

Ferramentas de teste de software

Para garantir a qualidade de um programa, as desenvolvedoras realizam testes nele. Isso é necessário para que falhas sejam detectadas antes que o software seja colocado no mercado. Sabe aquele programa que vive travando, não roda direito ou que faz o PC ficar lento? Esse, provavelmente, deve ter passado pelo processo de desenvolvimento com essas imperfeições. Então, para evitar que isso aconteça, as empresas contratam profissionais (os testadores de software ou analistas de testes) para identificarem esses problemas e relatarem para que os desenvolvedores os corrijam. Mas, para fazer isso eles precisam realizar uma bateria de testes diferentes, que envolvem desde análise da estrutura interna do software até a avaliação da interface.

O que são ferramentas de teste de software?

Para que esses testes possam ser realizados de modo mais rápido e com maior abrangência, existem ferramentas que automatizam alguns deles ou auxiliam na execução de outros. Essas são as ferramentas de teste de software.

O que é e o que faz um testador de software?

Com a expansão do mercado de tecnologia da informação (TI), uma nova profissão surgiu e tem crescido nos últimos anos: o testador de software ou analista de testes. Esse profissional é contratado para encontrar erros, falhas, bugs e outros tipos de problemas que não foram detectados durante a confecção de um software.

O mercado para esse tipo de profissão é amplo. Abrange desde a prestação de serviços de testes de softwares para programas gerenciais até aplicativos de smartphones voltados para o público. E a expectativa é de que ele fique cada vez maior, à medida em que clientes de desenvolvedoras de softwares passam a solicitar a avaliação desse profissional nos programas encomendados.

Automação de testes de software

Num mundo cada vez mais interligado pela tecnologia, os planos de testes de softwares têm um peso importante, pois muitos negócios dependem de que esses estejam funcionando corretamente.

Qualquer falha num programa de gerenciamento financeiro pode acarretar prejuízos grandes em termos monetários. Um erro num software de um equipamento médico pode custar a vida uma pessoa ou dificultar o atendimento a alguém que precisa.

E não é só os casos mais extremos que precisam de testes de software de qualidade, pois uma simples falha de um programa de uso comum que ocorra com frequência pode fazer com que usuário dele abra queixa ou não o recomende para outros usuários, migrando para a concorrência. Quem perde é quem desenvolveu o software.

Processo de Teste de Software

O Processo de Testes de Software representa uma estruturação de etapas, atividades, artefatos, papéis e responsabilidades que buscam a padronização dos trabalhos e ampliar a organização e controle dos projetos de testes.

O Processo de Teste, como qualquer outro processo deve ser revisto continuamente, de forma a ampliar sua atuação e possibilitar aos profissionais uma maior visibilidade e organização dos seus trabalhos, o que resulta numa maior agilidade e controle operacional dos projetos de testes.

Etapa 1: Planejamento dos Testes

Esta etapa caracteriza-se pela definição de uma proposta de testes baseada nas expectativas do Cliente em relação à prazos, custos e qualidade esperada, possibilitando dimensionar a equipe e estabelecer um esforço de acordo com as necessidades apontadas pelo Cliente.

Dinâmica das Macro-Atividades

Este diagrama representa a seqüência das “macro-atividades” a serem executadas na etapa de “Planejamento dos Testes”.

Detalhamento das Macro-Atividades

Esta lista representa o conjunto de atividades que deverão ser executadas para que cada macro-atividade seja considerada finalizada, funcionando como um “check-list” de execução da etapa de “Planejamento dos Testes”.

Estudo do Projeto:

Estudar as modificações solicitadas pelo Cliente (novos requisitos);

Estudar as modificações de arquiteturas dos aplicativos;

Estudar as lições aprendidas dos Projetos Anteriores;

Avaliar expectativas de custos, prazos e qualidade exigidas pelo Cliente;

Avaliar os riscos envolvidos nos Projetos e seus impactos neste processo;

Avaliação de Impacto:

Avaliar se o projeto exige a criação de casos de testes “progressivos”;

Avaliar se o projeto exige modificações em casos de testes “regressivos”

Avaliar se o projeto exige adequações na automação dos testes;

Avaliar se o projeto exige adequação nas atuais ferramentas empregadas;

Avaliar se o projeto exige a aquisição/construção de novas ferramentas;

Avaliar se o projeto exige modificações na estruturação do ambiente;

Análise Interna de Esforço

Levantar métricas históricas para auxiliar na elaboração das estimativas de esforço;

Estimar esforço interno para absorção dos impactos da Arquitetura dos Testes;

Demonstrar esforço externo para absorção dos impactos da Arquitetura dos Testes;

Análise Externa de Esforço:

Avaliar disponibilidade de espaço físico e infra-estrutura para os Terceiros;

Especificar as necessidades de adequações que serão repassadas a Terceiros;

Especificar métricas de qualidade e produtividades esperadas;

Especificar SLA’s de serviço e multas contratuais;

Estabelecer concorrência e obter a melhor proposta (opcional);

Receber Proposta de Trabalho (Cronograma, Prazos e Custos da Terceirização);

Definição de Cenários Possíveis (Duração, Esforço, Custo e Qualidade):

Levantar Lista de Projetos em Andamento e a serem Iniciados;

Avaliar a disponibilidade de recursos internos para alocação no Projeto;

Identificar Cenários Diversos (Terceirização, Redução de Escopo, Repriorização de Projetos);

Definir Cronograma-Macro para cada cenário identificado;

Definir Riscos para cada cenário identificado e Planos de Ação Esperados;

Estabelecer Propostas e Aguardar aprovação da Diretoria;

Aprovação do Planejamento:

Obter o Aceite das Propostas de Cenários Aprovados pela Diretoria;

Obter o Aceite de uma das Propostas pelo Cliente;

Divulgar do Cenário Aprovado do Projeto aos colaboradores e terceiros;

Obter a Assinatura do CONTRATO-MESTE e elaborar os ANEXOS; (no caso de terceirização)

Alocar Espaço Físico dos Terceiros; (no caso de terceirização)

Comunicar a Finalização da Etapa de Planejamento dos Testes; (externo)

Definição das Responsabilidades

Neste diagrama, está a representação dos papéis e responsabilidades para cada grupo de atividades envolvido na etapa de “Planejamento dos Testes”.

Definição de Cenários Possíveis (Duração, Esforço, Custo e Qualidade): Levantar Lista de Projetos em Andamento e a serem Iniciados;

Avaliar a disponibilidade de recursos internos para alocação no Projeto;

Identificar Cenários Diversos (Terceirização, Redução de Escopo, Repriorização de Projetos);

Definir Cronograma-Macro para cada cenário identificado;

Definir Riscos para cada cenário identificado e Planos de Ação Esperados;

Estabelecer Propostas e Aguardar aprovação da Diretoria; Aprovação do Planejamento: Obter o Aceite das Propostas de Cenários Aprovados pela Diretoria;

Obter o Aceite de uma das Propostas pelo Cliente;

Divulgar do Cenário Aprovado do Projeto aos colaboradores e terceiros;

Obter a Assinatura do CONTRATO-MESTE e elaborar os ANEXOS; (no caso de terceirização)

Alocar Espaço Físico dos Terceiros; (no caso de terceirização)

Comunicar a Finalização da Etapa de Planejamento dos Testes; (externo) Definição das Responsabilidades Neste diagrama, está a representação dos papéis e responsabilidades para cada grupo de atividades envolvido na etapa de “Planejamento dos Testes”.

Mapeamento dos Artefatos Nesta representação gráfica, estão destacados os “artefatos de entrada” exigidos como premissa para que cada macro-atividade possa ser realizada. Também são destacados os “artefatos de saída” produzidos como resultado da atividade. Etapa 2: Especificação dos Testes Esta etapa é caracterizada pela identificação dos casos de testes que deverão ser construídos e modificados em função das mudanças solicitadas pelo Cliente, bem como pelo próprio aperfeiçoamento do processo de testes (ampliação da cobertura). Dinâmica das Macro-Atividades Este diagrama representa a seqüência das “macro-atividades” a serem executadas na etapa de “Especificação dos Testes”.

Detalhamento das Macro-Atividades Esta lista representa o conjunto de atividades que deverão ser executadas para que cada macro-atividade seja considerada finalizada, funcionando como um “check-list” de execução da etapa de “Especificação dos Testes”. ESTUDO DOS REQUISITOS: Estudar os requisitos funcionais e não funcionais solicitadas pelo Cliente (novos requisitos);

Estudar as modificações de requisitos solicitados pelo Cliente (mudanças de requisitos);

Revisar os artefatos e identificar “inconsistências” dos requisitos;

Estabelecer o Aceite dos Documentos fornecidos e “feedback” da qualidade dos mesmos;

Estudar as lições aprendidas da Etapa “Especificação de Testes”; ESPECIFICAR AS ADAPTAÇÕES DA ARQUITETURA DOS TESTES: Especificar as adequações nas atuais ferramentas empregadas;

Especificar as novas ferramentas exigidas pelo projeto;

Especificar as modificações estruturais na organização do ambiente;

Especificar as adequações na automação da preparação do ambiente (script de teste);

Especificar as adequações na automação da execução dos testes (script de teste);

Especificar as adequações na automação da análise dos resultados (script de teste); IDENTIFICAÇÃO DOS CASOS DE TESTES Identificar cada solicitação de mudança requisitada pelo Cliente;

Identificar todos os Casos de Uso envolvidos em cada solicitação;

Identificar Casos de Uso não cobertos adequadamente por Casos de Testes; (legado)

Identificar todos o Fluxos do Caso de Uso (Básico, Alternativo e Exceção);

Identificar os casos de testes que garantam cada Fluxo do Caso de Uso; REFINAMENTO DOS CASOS DE TESTES: Estabelecer dinâmica com os Analistas de Testes que possuem conhecimento horizontal;

Apresentação de um quadro-geral do impacto das mudanças nos respectivos aplicativos;

Cada Analista de Testes apresenta seus casos de testes por aplicativo;

O grupo de Analistas de Testes criticam e sugerem melhorias nos casos de testes;

O grupo de Analista de Testes avaliam o nível de cobertura alcançado;

Novas reuniões serão realizadas até que seja alcançado o patamar ideal de casos de testes; Aceite dos Casos de Testes: Identificar Áreas-Chaves para apresentação dos casos de testes (Clientes Internos e Externos)

Apresentar os casos de testes “progressivos” que serão aplicados nos testes;

Apresentar os casos de testes “regressivos” que serão aplicados nos testes;

Realizar refinamento dos casos de testes apresentados (“regressivos e progressivos”);

Estabelecer o acordo Mútuo de Responsabilidade sobre o Nível de Qualidade do Software; REFINAMENTO DO PROJETO DE TESTES: Reavaliar as estimativas de esforço e duração do Processo de Teste; (se necessário)

Estabelecer um Cronograma-Detalhado, baseado no Cronograma-Macro já elaborado;

Reavaliar riscos do Projeto em função de uma maior detalhamento sobre os requisitos;

Negociar eventuais modificações em relação à duração, prazo e custo do projeto de testes;

Comunicar a Finalização da Etapa de “Especificação dos Testes”; (externo) Definição das Responsabilidades Neste diagrama, está a representação dos papéis e responsabilidades para cada grupo de atividades envolvido na etapa de “Especificação dos Testes”. Mapeamento dos Artefatos Nesta representação, estão destacados os “artefatos de entrada” exigidos como premissa para que cada macro-atividade possa ser realizada. Também são destacados os “artefatos de saída” produzidos como resultado da atividade.

Calculando o ROI (Retorno de Investimentos) em Testes de Softwares Convido você agora a se aprofundar e calcular junto comigo os custos dos defeitos para um software e o retorno do investimento na realização de teste de software. Primeiramente devemos identificar custos, incidências e percentuais de correção de defeitos nas fases do ciclo de desenvolvimento do software, assim conseguiremos realizar um cálculo de valores baseado na realidade. Em primeiro lugar, é preciso observar que o custo de correção de defeitos encontrados em qualquer pacote de software cresce exponencialmente a cada fase da criação ou existência deste software, o que pode ser representado, segundo o autor Ron Patton, da seguinte forma [8] como mostra a figura abaixo.

O custo de encontrar defeitos e removê-los na fase de especificação é baixíssimo, na ordem de grandeza de dezenas de centavos (de uma moeda qualquer).Na fase de design estes custos já crescem para a ordem de grandeza de unidades de moeda, e assim por diante, até chegarem a custos na casa das centenas quando o software já está em produção.O custo baixo de se encontrar defeitos nas fases de especificação e design se justifica pelo baixo — ou, em alguns casos, desprezível — retrabalho resultante da descoberta e correção destes defeitos nestas fases iniciais. Seria o equivalente a amassar o guardanapo e começar a rabiscar novamente. Defeitos encontrados na fase de codificação já são mais caros porque muitas vezes exigem testes realizados pelos desenvolvedores (o que toma tempo), correção ou mesmo descarte de código desenvolvido e, nos piores casos, um retrocesso às fases de especificação e design. Já os defeitos encontrados na fase de produção, além de todos os custos anteriores, implicam em custos de atendimento ao cliente, replicação dos defeitos em laboratório, chegando até mesmo aos temidos recalls. Em suma, o raciocínio de Patton é claro: quanto mais cedo forem encontrados os defeitos, menos custarão, tanto para os desenvolvedores quanto para os clientes. Quanto à eficiência dos testes na descoberta de defeitos de software, dados obtidos a partir de projetos da própria Sofist mostram que quando o cliente atribui tarefas de testes para parte de seu time de desenvolvimento, este consegue descobrir no máximo 40% dos defeitos do software em questão. Calculando o retorno sobre o investimento (ROI) Tomando por base empresas que seguem o modelo CMMI, temos que aquelas que se enquadram no nível 1 tipicamente entregam software com 7,5 defeitos a cada 1.000 linhas de código, enquanto as empresas com certificação CMMI nível 5 produzem software com melhor qualidade, reduzindo os defeitos para uma média de 1 a cada 1.000 linhas de código [9]. Nesta situação, tomemos por hipótese um pacote de software com 1 milhão de linhas de código — nada incomum em projetos atuais — que tenha sido codificado com 1.000 (mil) defeitos inadmissíveis, isto é, que terão que ser corrigidos a qualquer custo, seja em que fase da vida do software forem encontrados. Assumindo, de acordo com o raciocínio de Patton, que defeitos encontrados durante a fase de desenvolvimento tenham custo de R$ 1,00, durante a fase de testes tenham um custo de R$ 10,00 e que os mesmos defeitos encontrados com o software em produção tenham um custo de R$ 100,00, podemos construir um cenário interessante. Análise de 3 situações: O software vai para o mercado sem ter sido formalmente testado; O software passa por um processo de testes realizados por pessoal interno, interinamente designado pela empresa para realizá-los; O software passa por um processo testes realizado por equipe especializada terceirizada; Premissas da análise 10% dos defeitos serão encontrados na fase de codificação, 0%, 40% ou 85% dos defeitos serão encontrados na fase de testes (respectivamente nos cenários 1, 2 e 3) e o restante será encontrado na fase de produção;

O salário considerado no caso dos testes internos é de R$3.000,00 mensais, com custo para a empresa (acrescido dos benefícios) de R$5.000,00 mensais; Ainda no caso de testes internos, considera-se a atuação parcial de um gerente de testes com salário de R$5.000,00 (R$10.000,00, com benefícios), com 50% de seu tempo designado para o processo de testes; Os testes terceirizados são conduzidos por uma equipe que custa R$10.000,00 por mês, durante três meses; Considera-se ROI como sendo a razão entre os valores economizados (em relação à abordagem sem testes) e o valor dos investimentos em cada uma das opções de testes avaliadas neste caso; Resultados – Tabela ROI De acordo com este raciocínio, podemos compor a tabela apresentada acima. A tabela mostra com clareza que osinvestimentos em testes de software, sejam estes realizados por pessoal interno ou por equipe especializada terceirizada, trazem vantagens financeiras, constituindo-se em investimentos que geram reduções relevantes dos custos de desenvolvimento do produto. Os resultados, como pode ser claramente visto na imagem acima, apresentam uma justificativa sólida para a realização dos testes.