Qualidade de Software

1. GESTÃO DE DEFEITOS
PROF. ALEXANDRE LISBÔA DA SILVA

2. Gestão de Defeitos
ERRO DEFEITO FALHA

3. O que são: erro, defeito e
falha?
Erro: Ação humana que produz
um resultado incorreto (pode ser
cometido em qualquer fase do
desenvolvimento de software)

4. O que são: erro, defeito e
falha?
Defeito: Manifestação de um erro de no
software: Também conhecido como Bug
Se executado, o defeito pode causar uma
falha.
É o resultado do erro cometido.

5. O que são: erro, defeito e
falha?
Falha: Diferença indesejável entre o observado
e o esperado (defeito encontrado).
Tudo o que for observado pelo usuário como
diferente do resultado esperado pode ser
causada também pelas condições de ambiente.

6. O que são: erro, defeito e falha?
https://www.bbc.com/portuguese/noticias/2015/05/150513_vert_fut_bug_digital_ml
https://www.youtube.com/watch?v=t3v5r_SV4z0

7. Encontrando e Reportando um
defeito.
 Descobrir defeitos será a coisa que mais ocorrerá se
você se tornar um testador.
 Os defeitos são descobertos na maioria das vezes
por ações que os testadores utilizam.
 Na maioria das vezes o teste foi tão elaborado que
é quase impossível de alguém encontrar algum
outro, no entanto, as vezes os defeitos são
descobertos assim, sem querer mesmo.

8. E quando descobrimos um
defeito, o que fazer?
 Relatar um defeito é sempre crucial para que sua correção
seja feita da melhor forma e o quanto antes.
 Ao relatar um bug, devemos indicar o impacto. A norma
IEEE 1044-1993 define a seguinte classificação:
 Urgente;
 Alta;
 Média;
 Baixa;
 Nenhuma.

9. E quando descobrimos um
defeito, o que fazer?
 Claro que este padrão não fará milagres, servirá apenas uma classificação
que auxiliará no ponto de partida para escolha do que corrigir e quando
corrigir.
DICA: Achou um bug, então pare tudo e relate-o!
 Tenha em mente que o quanto antes você reportar um bug, mais tempo ele
terá para ser analisado e corrigido conforme as prioridades do projeto, do
cliente, etc...
 Nem tudo que você achar ser defeito pode realmente ser, e apesar de os
testadores ficarem frustrados com isso, sinta-se feliz, pois em algum momento
pode ser que alguns defeitos não tenham mais tempo hábil pra sua correção
e isso sim frustra qualquer um.

10. Descrição Efetiva de Defeitos
 Descrever um bug é um passo fundamental da gestão de defeitos. Abaixo
seguem algumas diretrizes para serem seguidas ao relatar um efeito:
1. Evidencie: guardar a evidência do bug encontrado por meios de arquivos
de saídas, print screens de telas, etc...
2. Reproduza: tente reproduzir o erro, já analisando e anotando todo o
passo a passo para o reporte. Tendo conseguido reproduzir o erro e
anotar tudo, descreva de forma clara:
a) O que aconteceu? Informar o que aconteceu no erro.
b) O que era pra ter acontecido? Pois para o desenvolvedor não é necessário que ele
leia todo os caso de teste, pra ele importa apenas o resultado final.
c) Como você fez para chegar neste ponto? Passos pra reprodução.

11. Nunca julgue ao reportar
defeitos
 Existem duas formas de se julgar no reporte de defeitos: você sugerir que
deve ser culpa de algo e você sugerir que deve ser culpa do código do
programador.
 Apesar de você querer facilitar o entendimento do defeito encontrado
detalhando o máximo possível, uma coisa é certa: se você não tem
certeza de algo nunca sugira que pode ser “isso” ou “aquilo” que pode ter
ocasionado tal problema. Isso pode fazer com que o desenvolvedor
também acredite nisso e fuja do foco do problema, levando muito mais
tempo até achar o real problema.
 E muito menos descreva algo como se desse a entender que por causa do
código de má qualidade de tal sistema que tal defeito foi encontrado.
Ninguém é melhor que ninguém, e se não houvesse erros o mercado de
teste simplesmente não existiria.

12. Reporte de Defeitos Ineficientes
Embora a regra seja sempre detalhar da melhor
maneira o defeito encontrado, nem sempre o
tempo estará ao nosso lado. Algumas vezes
podem acontecer coisas que podem prejudicar
no reporte destes defeitos.
Ainda assim, é melhor pensar alguma coisa pra
que tal reporte não dificulte ainda mais a situação.

13. Follow-up seu reporte de defeitos
 Depois do reporte que um defeito foi encontrado e relatado,
ele segue um ciclo de vida pré-definido pelo processo de
gestão de defeitos.
 Este ciclo de vida define os fluxos até que o defeito possa ser
definitivamente fechado.
 Uma vez que o testador acha, relata seu defeito, é sua tarefa
monitorá-los. Verificar se há informação suficiente, se o
desenvolvedor quer que você explique de outra forma, enfim
cuidar para que o processo não se atrase. Deve-se estar
sempre atento aos seus “filhos”.

14. Follow-up seu reporte de defeitos
 O status que um defeito pode assumir durante seu ciclo
de vida varia muito, e ele pode ser alterado diversas
vezes.
Abaixo alguns dos status dos defeitos:
Aberto;
Em análise;
Em espera;
Em desenvolvimento;
Em teste;
Fechado;
Resolvido;
Reaberto;
Duplicado.

15. Isolando e Reproduzindo Defeitos
 Como parte do perfil de um bom testador, saiba que cabe a você ter em
mente algumas práticas para facilitar no entendimento e controle dos seus
defeitos encontrados.
ABAIXO ALGUMAS DELAS:
 Passos pra reproduzir o defeito;
 Evidências;
 Logs dos softwares
 Dados que possam ser relevantes como data, ambiente, SO;
 Verifique as dependências e requisitos para o software funcionar com sucesso;
 Verifique se a infra está de acordo.

16. Agradecemos!
ALEXANDRE.LISBOA@FMPSC.EDU.BR