Exibir código-fonte para Introdução ao teste de software

 Versão 1.1 de 07/11/2016

==O que é testar?==

Encontramos na literatura algumas definições sobre o que é a atividade de testar:

 “Testar é analisar um programa com a intenção de descobrir erros e defeitos.” (Myers)
 “Testar é exercitar ou simular a operação de um programa ou sistema. ”
 “Testar é confiar que um sistema faz o que se espera que ele faça e não faz o que se espera que não faça. ”
 “Testar é medir a qualidade e funcionalidade de um sistema. ”
 “O teste de programas pode ser usado para mostrar a presença de defeitos, mas nunca para mostrar a sua ausência.” (Dijkstra)

===Objetivo dos testes===

O objetivo principal dos testes é reduzir a probabilidade da ocorrência de um defeito quando o software estiver em produção, minimizando os riscos para o negócio e garantindo que as necessidades do cliente estão sendo atendidas.

===Erro, Defeito e Falha===

*Erro (error): é uma ação humana que produz um resultado incorreto.

*Defeito (fault): A manifestação de um erro no software. 
**Também conhecido como Bug;
**Se executado, o defeito pode causar uma falha.

*Falha (failure): diferença indesejável entre o observado e o esperado. (Defeito encontrado)

 '''Falha é um evento. Defeito é um estado do software, causado por um erro.'''

===Por que defeitos ocorrem no software?===

*Softwares são escritos por humanos;
*As pessoas não conhecem e não dominam tudo;
*As pessoas têm habilidades, mas não são perfeitas;
*As pessoas cometem erros;
*Tempo de desenvolvimento curto;
*Sem tempo para checar as atividades realizadas;
*Sistemas podem estar incompletos.

===O custo da falta de qualidade e da correção de defeitos===

Estatísticas de mercado apontam que para cada R$ 1,00 investido no desenvolvimento e manutenção de software, entre R$ 2,00 e R$ 3,00 são gastos com retrabalho.

*Talvez o software ou parte dele precise ser refeito, o que aumenta ainda mais os custos;
*Não se sabe, através de métricas claras e precisas, quais são as principais áreas de produção que geram retrabalho.

Existem alguns tipos de sistemas onde:

*As falhas causam prejuízos diretos, ou
*As falhas causam a perda de confiança do público (clientes e usuários).

A Regra 10 de Myers indica que o custo da correção de um defeito tende a ser cada vez maior quanto mais tarde ele for descoberto. Defeitos encontrados nas fases iniciais da etapa de desenvolvimento do software são mais baratos de serem corrigidos do que aqueles encontrados na produção.

===Por que testar é necessário?===

*Porque é provável que o software possua defeitos;
*Para descobrir a confiabilidade do software;
*Porque falhas podem custar muito caro;
*Para demonstrar as conformidades com os requisitos;
*Para assegurar que as necessidades dos usuários estejam sendo atendidas;
*Para reduzir custos;
*Para avaliar a qualidade do software.

====Não devemos testar====

*Para provar que o software não tem defeitos;
*Apenas porque os testes estão incluídos no plano de projeto.


===Mitos sobre o teste de software===

'''O testador é inimigo do desenvolvedor.'''
*Todos fazem parte da mesma equipe e trabalham para o sucesso dos projetos. O papel do testador não é apontar erros do desenvolvedor e sim trabalhar em conjunto para agregar qualidade ao produto final.
*Os desenvolvedores jamais devem levar o cadastro de bugs de uma tarefa que desenvolveu como algo pessoal, assim como os testadores devem entender quando a equipe não priorizar um ou mais bugs que tenha encontrado.


'''A equipe de testes pode ser formada pelos desenvolvedores menos qualificados.'''
*Uma equipe de testes necessita de pessoas que conheçam os sistemas, técnicas de teste, conhecimento em diversos tipos de teste, além de competências como atenção, olhar crítico, organização, etc.


'''*Quando estiver tudo pronto, o sistema vai para teste.'''
*O ideal é que o teste seja envolvido mais cedo no processo de desenvolvimento.  Quando antes os testes forem realizados, mais cedo os problemas serão encontrados e resolvidos.


'''Teste de software não exige muito intelectualmente.'''
*Se há apenas repetições de ações predefinidas, teste realmente pode não exigir muito do testador nesse aspecto. Mas é importante pensar em testes como uma forma de explorar, coletar informações e encontrar respostas a coisas que ainda não foram questionadas. E para alcançar esse nível de detalhamento é preciso pensar, observar e analisar muito o sistema a ser testado.


'''Se o software foi testado, então não pode ter bugs.'''
*Este é um dos mitos mais comuns entre clientes e gestores de projetos. Ninguém pode afirmar com absoluta certeza que um software está 100% livre de bugs, mesmo que tenha sido testado por um testador com capacidades magníficas.


'''Os testadores são os únicos responsáveis pela qualidade do produto.'''
*É uma atitude muito comum pensar que apenas os testadores (ou a equipe de testes) são responsáveis pela qualidade do produto. As responsabilidades dos testadores incluem a detecção de bugs para os responsáveis pelo projeto, e são os responsáveis que decidem se efetuam correções ou se dão o software como concluído.
*A qualidade do produto é um dever de todos os integrantes da equipe de desenvolvimento, e não apenas do testador.

==Tipos de testes==

===Testes de segurança===

A principal meta do teste de segurança é garantir que os dados ou funções de um sistema possam ser acessados apenas por atores autorizados a acessá-los. Todas as formas de ataque de acesso indevido devem ser simuladas.

'''Objetivos:'''

*Garantir que os dados do sistema estão protegidos adequadamente;
*Assegurar que todos os riscos que envolvem os acessos indevidos foram identificados;
*Analisar as ameaças e vulnerabilidades, tanto físicas como lógicas;
*Assegurar que os mecanismos de controle contra acessos indevidos foram corretamente implementados.

'''Quando usar:'''

*Testes básicos de segurança devem ser aplicados a todos os softwares;
*Quando a informação que circula através do software for de importância fundamental para a organização.


===Testes de performance===

O teste de performance, ou de desempenho como também é conhecido, mede e avalia o tempo de resposta, o número de transações e outros requisitos sensíveis ao tempo de resposta do sistema.

'''Objetivos:'''

*Determinar o tempo de resposta das transações;
*Verificar se os critérios de desempenho estabelecidos estão sendo atendidos;
*Identificar pontos de gargalo no sistema;
*Verificar o nível de utilização do hardware e software.

'''Quando usar:'''

*Quando se deseja avaliar o tempo de resposta de uma funcionalidade do sistema ou de todo o sistema;
*Devem ser realizados quando ainda há tempo hábil de serem realizadas correções.


===Testes funcionais baseados em requisitos===

O teste funcional baseado em requisitos tem por meta verificar se o software executa corretamente suas funções, se a implementação das regras de negócio foi apropriada e se o sistema é capaz de sustentar sua correta execução por um período contínuo de uso.

'''Objetivos:'''

*Assegurar a funcionalidade do sistema, incluindo entrada de dados, processamento e resposta;
*Verificar se os requisitos dos usuários estão implementados;
*Verificar se o sistema funciona corretamente após um período contínuo de utilização.

'''Quando usar:'''

*Qualquer sistema deve ter suas funcionalidades testadas;
*Pode ser usado desde a fase de especificação de requisitos até a fase de operação do sistema.


===Teste de usabilidade===

O teste de usabilidade verifica a facilidade que o software possui de ser claramente entendido e facilmente operado pelos usuários.

'''Objetivos:'''

*Verificar a facilidade de operação do sistema pelo usuário;
*Verificar a facilidade de entendimento das funções do sistema pelo usuário, através da utilização de manuais, on-line help, agentes e assistentes eletrônicos, etc.

'''Quando usar:'''

*Quando se deseja avaliar a complexidade de entendimento das telas e o fluxo de informação;
*Pode ser executado em conjunto com outros testes (funcionalidade, acessibilidade).

==Visão geral sobre o processo de testes na MSTECH==


Na MSTECH, '''TODOS''' são responsáveis pela qualidade dos produtos desenvolvidos.

*Os Analistas de requisitos e POs devem prezar pela qualidade das informações trazidas dos clientes e apresentar documentações de sistema consistentes;

*Os Desenvolvedores devem prezar pela qualidade dos sistemas, verificando:
**Se tirou todas as dúvidas sobre o requisito que vai desenvolver;
**Se desenvolveu tudo o que foi solicitado no documento de requisitos;
**Se codificou de acordo com os padrões definidos pela MSTECH;
**Se realizou testes em todos os fluxos das páginas desenvolvidas, incluindo regras de campos numéricos, textos e regras de negócio do cliente.

*Os Analistas de testes devem analisar o sistema desenvolvido, planejar testes de acordo com as regras de negócio e executá-los, a fim de encontrar defeitos nos sistemas. 
**Os analistas de testes devem ter seu foco principal em encontrar problemas de regras de negócio que vão impactar diretamente o cliente.
**Entende-se que, quando o desenvolvedor terminou sua tarefa, ele realizou os testes básicos (se campos de data aceitam datas inválidas, se campos numéricos aceitam letras, etc.);
**O analista de testes deve prezar pela qualidade dos sistemas, tendo um entendimento amplo de seu funcionamento e suas regras de negócio;
**Deve registrar todos os problemas encontrados.

===A qualidade nas etapas de desenvolvimento===

====Planning====

A MSTECH utiliza a metodologia rápida de desenvolvimento SCRUM.
Antes do início de uma nova Sprint, os membros da equipe recebem do PO o documento de requisitos para a próxima versão do sistema. Esse documento deve conter os requisitos do cliente, suas regras de negócio e observações. Os membros da equipe devem ler o documento e anotar dúvidas, sugestões e problemas para serem discutidos no planning.

====Desenvolvimento====

Após o Planning, os desenvolvedores iniciarão a construção do sistema, enquanto os Analistas de testes planejam e criam casos de teste.
É importante que o desenvolvedor tenha sanado todas as suas dúvidas antes de iniciar suas atividades.
Quando um desenvolvedor termina sua tarefa, é muito importante que ele revise tudo o que foi desenvolvido:

*Todas as regras de negócio foram implementadas?
*O desenvolvimento foi feito dentro dos padrões?
*Todos os campos se comportam como o esperado?
*A tela executa todos os fluxos (Cadastrar, Alterar, Excluir, etc.)?

====Testes funcionais das tarefas desenvolvidas====

Quando um desenvolvedor termina o desenvolvimento, realiza testes e dá a tarefa como encerrada, os Analistas de testes vão repassar todas as regras de negócio e verificar se tudo foi desenvolvido conforme o requisito exige.

====Bugs====

Durante os testes, os Analistas de testes podem encontrar problemas, que podem ser de regras de negócio, problemas de funcionalidades, usabilidade, acessibidade, etc.
Os bugs serão cadastrados no sistema destinado para isso (Youtrack ou TFS), contendo:

*Título (descrição resumida);
*Ambiente de testes em que o bug foi encontrado, incluindo o BD utilizado;
*Passos para a reprodução do problema;
*Resultado obtido;
*Resultado esperado;
*Imagens e vídeos para ajudar no entendimento do problema.

Além disso, os bugs contém campos de classificação. Todos os bugs devem ser classificados de acordo com seu tipo: Funcionalidade, Usabilidade, Configuração, Layout ou Acessibilidade. Através dessa classificação, os gestores podem fazer análises estatísticas dos bugs abertos e elaborar planos de melhoria do desenvolvimento. 
Existe um Guia para auxiliar na classificação de bugs e, em caso de dúvidas, os analistas de testes estão preparados para auxiliar.
Os desenvolvedores podem e devem conversar com os analistas de testes, tirando dúvidas sobre o sistema e sobre os bugs.
Vale lembrar que qualquer pessoa da equipe pode cadastrar um bug. Não é uma exclusividade dos Analistas de testes.

====Correção e reteste====

Os desenvolvedores deverão analisar os bugs abertos. Constatando o problema, deverá proceder com a correção. Pode ocorrer do bug cadastrado não ser válido (regra de negócio mudou, PO mudou a definição e não atualizou o documento, etc.). Nesses casos, o desenvolvedor deve registrar o ocorrido no bug e devolvê-lo para reteste.
Os Analistas de testes ficarão responsáveis por realizar novos testes e verificar as correções.

===A equipe de testes===

Atualmente a MSTECH conta com 6 analistas de testes, que estão capacitados para executar testes funcionais e não funcionais.

*Ana Guedes
*André Iguera
*Halana Camuci
*Jaqueline Sgarbi
*Marriely Garcia

===Quando os testes são executados?===

Os testes funcionais baseados em requisitos e os testes de usabilidade são executados em paralelo com o desenvolvimento das entregas.
Os testes de performance e acessibilidade são executados com agendamento prévio pelos responsáveis pelos projetos.