DÉBONY SCHMIDT
A IMPORTÂNCIA DA QUALIDADE E TESTES DE SOFTWARE
Guarulhos
2011
DÉBONY SCHMIDT
A IMPORTÂNCIA DA QUALIDADE E TESTES DE SOFTWARE
Trabalho de conclusão de curso
apresentado à Faculdade Enia...
Schmidt, Débony
A importância da Qualidade e Testes de Software. –
São Paulo, 2011.83f.
Trabalho de Conclusão de Curso – F...
Aluno: Débony Schmidt
Título: A importância da Qualidade e Testes de Software
A banca examinadora dos Trabalhos de Conclus...
Dedicatória
Dedico este trabalho a Deus em primeiro
lugar e aos meus pais e irmã que sempre
estiveram ao meu lado e propor...
Agradecimentos
Agradeço aos meus familiares e amigos pelo
apoio. E agradeço também aos professores
Lúcio Luzetti, Neiva Co...
“Se tivesse seis horas para
derrubar uma árvore, eu
passaria as primeiras quatro
horas afiando o machado”
(Abraham Lincoln)
Resumo
Este trabalho exibe conteúdo relevante sobre os problemas encontrados
atualmente nas empresas de desenvolvimento de...
Abstract
This work displays relevant content on the problems encountered in today's
software development companies.
Most o...
Figuras
Figura 1 - Elementos chave do TQM Total Quality Management (Gestão da
Qualidade Total)...............................
Tabelas
Tabela 1 - Categorias dos Custos Operacionais da Função Qualidade ........................6
Sumário
1. Cenário Atual.....................................................................................................
3.7.1 Documentação dos Testes............................................................................ 39
3.7.2 Plano d...
1
Introdução
O presente trabalho apresentará o resultado de estudos sobre A importância
dos Testes de Software.
O tema foi...
2
outros projetos e arcar com os custos, pois, após a data acordada com o Cliente ser
ultrapassada o mesmo passa a não ter...
3
1. Cenário Atual
Os clientes atualmente estão se tornando mais exigentes com os softwares,
buscando projetos que atendam...
4
 Mais de 30% dos projetos são cancelados antes de serem
finalizados.
 Mais de 70% dos projetos falham nas entregas das...
5
Para que as empresas aumentem a produtividade e obtenha redução de
custos como muitas almejam, é necessário que os produ...
6
Tabela 1 - Categorias dos Custos Operacionais da Função Qualidade
Fonte: [4]
Todo gasto realizado com a qualidade deve s...
7
2. Qualidade de Software
2.1 Definição da Qualidade
Há várias definições que podem ser atribuídas a Qualidade:
“Qualidad...
8
Figura 1 - Elementos chave do TQM Total Quality Management (Gestão da Qualidade
Total)
Fonte: [9]
Foco do Cliente (Custo...
9
2.2 Histórico da Qualidade
Nos tempos anteriores ao século XX, a qualidade era vista somente como
responsabilidade do ar...
10
As empresas de desenvolvimento de software no inicio de suas atividades
utilizavam como metodologia de qualidade os pró...
11
Figura 2 - Pilares da Qualidade de Software
Fonte: (BARTIÉ, 2002)
2.3.1. Planejando a Qualidade
Esta fase será utilizad...
12
Para Gomes (2010) [4], a Garantia da Qualidade tem como objetivo prover
confiança sobre a conformidade de produtos e se...
13
Figura 3 - Ciclo de desenvolvimento no qual qualidade resume-se a testes de software
Fonte: (BARTIÉ, 2002)
O grupo de Q...
14
disso foi a elaboração do CMM (Capability Maturity Model), um modelo que propõe o
processo de software com melhoria con...
15
Figura 4 - Possíveis níveis de maturidade previstos no modelo CMM
Fonte: (BARTIÉ, 2002)
No nível 1 a organização está s...
16
No nível 3 todos os processos e procedimentos já estão especificados e
documentados. Sendo estes, a base para este níve...
17
Sendo estas medições consistentes e com grande definição. Disponibilizando bases
para que sejam avaliados os processos ...
18
Figura 5 - Esforço dedicado à correção de defeitos no desenvolvimento de software
Fonte: (BARTIÉ, 2002)
Para empresas q...
19
inconsistências. Também podemos empregar palavras existentes na língua inglesa
como bugs, crash e abends”. (BARTIÉ, 200...
20
Figura 6 - Erros, defeitos e falhas
Fonte: [17]
2.6.2 Bug
É um erro no funcionamento comum de um software, também
chama...
21
Figura 7 - Erro de código: "If" sem "End If"
Fonte: [18]
Há uma imagem de que os bugs são encontrados somente no código...
22
Figura 8 - Exemplo de erro na especificação.
Fonte: [18]
Os erros estão em todas as etapas do processo, porém, estudos ...
23
Figura 9 - Incidência de defeitos nas etapas de desenvolvimento
Fonte: (BARTIÉ, 2002)
2.7 O custo da qualidade
“O custo...
24
Figura 10 - Custo da Qualidade
Fonte: [19]
Custo de Falhas – Envolve todos os custos associados a produtos
defeituosos,...
25
para que este processo seja aplicado corretamente deve ser aplicado um montante
de dinheiro, profissionais e tempo. Par...
26
respeitou adequadamente os papéis para cada atividade dentro do desenvolvimento.
(PRESSMAN, 2002)
O objetivo da GQS é f...
27
3. Testes de Software
3.1 Fundamentos de Teste
A atividade de teste é um ponto importante no processo de garantia da
qu...
28
É importante saber que a atividade de teste não garante que os bugs não
existirão, ela apenas demonstra se há defeitos ...
29
 “sabemos que nosso software está cheio de bugs, então vamos cobrar
uma manutenção mensal do nosso cliente para conser...
30
criar outra promoção para se redimir do erro e os clientes ficaram insatisfeitos com o
ocorrido. [24]
Outros exemplos:
...
31
Figura 12 - Modelo de relacionamento entre desenvolvimento e testes
Fonte: (BASTOS, A. et. al., 2007)
3.4 Princípios de...
32
 Excesso de testes, quando são executados mais testes do que o previsto,
ultrapassando o tempo estimado e com um gasto...
33
em duas formas de avaliação, a Revisão voltada para a documentação e a Auditoria
que garante a qualidade das atividades...
34
Figura 14 - Execução Testes Caixa Branca
Fonte: (BARTIÉ, 2002)
Para a realização dos testes de caixa branca foram defin...
35
3.5.1.4 Teste de Operação
São testes utilizados no ambiente de operação em que atuará, com usuários
que irão executar a...
36
pela homologação realize um planejamento detalhado e apurado para que seja
possível identificar todos os cenários possí...
37
3.5.2.4 Teste de Suporte Manual
Analisa se os manuais e guias para os usuários estão sendo feitos de forma
correta, se ...
38
3.6 Estágios dos Testes
Figura 16 - Fases dos Testes
Fonte: (BARTIÉ, 2002)
3.6.1 Teste de Unidade
É realizado em unidad...
39
erros de transição de dados. Não faz parte deste teste avaliar a conexão com outros
sistemas (teste de interconexão). [...
40
Durante a fase de Elaboração dos Testes serão utilizados três documentos:
Especificação do projeto de Teste: Documento ...
41
Figura 17 - Modelo IEEE STD 829-1998
Fonte: (BASTOS, A. et. al., 2007)
3.7.2 Plano de Casos de Teste
É o documento que ...
42
3.7.2.1 Casos de Teste
A melhor definição para casos de teste é o maior detalhamento possível de
um teste, com especifi...
43
Figura 18 - RUP – Caso de Uso
Fonte: (BASTOS, A. et. al., 2007)
O fluxo básico ou principal, representado pela linha pr...
44
Caso o usuário acione a opção Limpar:
 O software deverá excluir as informações de Login e Senha.
Caso o usuário acion...
45
SISTEMA EMPRESARIAL
Login:
Senha:
Protótipo da Tela
3.7.2.3.2 Definição Casos de Teste
CT01 – Campos Obrigatórios
Pré-C...
46
CT02 – Login incorreto
Pré-Condições Acessar a tela de login.
Pós-Condições Software exibe mensagem de erro.
Detalhamen...
47
válidos”.
Massa de Entrada
e Saída
Login correto e Senha incorreta.
Critérios
Especiais
Não aplica
Ambiente SO Windows ...
48
CT05 – Login efetuado corretamente
Pré-Condições Acessar a tela de login.
Pós-Condições Acessar o software.
Detalhament...
49
Testes de Sistema – Analistas de Teste
Testes de Aceitação – Usuários com a ajuda dos analistas de teste.
Quem irá exec...
50
3.8.2 Execução dos Testes de Integração
Para Bastos, A.et. al. (2007) após serem executados todos os testes unitários,
...
51
Figura 20 - Documentos necessários para o processo de Teste
Fonte: (BASTOS, A. et. al., 2007)
3.9.1 Relatório Log de Te...
52
 Descrição: identificar o que foi testado e o ambiente em que o
teste foi executado incluindo hardware, quantidade de ...
53
 Impacto: indicar qual o impacto que o incidente terá no plano de
teste de execução podendo falhar, bloquear o(s) test...
54
Figura 21 - Ferramenta Selenium
Fonte: [33]
 Watir: Foi desenvolvido para criar testes automatizados para ambiente
web...
55
Figura 22 - Ferramenta BadBoy
Fonte: [35]
 Canoo WebTest: É uma ferramenta que possui o código aberto para a
criação d...
56
Figura 23 - Ferramenta Canoo WebTest
Fonte: [37]
3.9.5 Testes de Desempenho
 JMeter: É uma ferramenta da Apache que pe...
57
Figura 24 - Ferramenta JMeter
Fonte: [38]
3.9.6 Gerenciar Casos de Teste
 TestLink: É uma ferramenta que gerencia os c...
58
Figura 25 - Ferramenta TestLink
Fonte: [39]
3.9.7 Gerenciar Defeitos
 Bugzilla: É uma ferramenta que se baseia em Web ...
59
Figura 26 - Ferramenta Bugzilla
Fonte: [40]
 Mantis: É uma ferramenta que gerencia defeitos encontrados pela equipe
de...
60
Figura 27 - Ferramenta Mantis
Fonte: [42]
61
Considerações Gerais
Os problemas enfrentados pelas equipes de software são principalmente
causados pela falta de conhe...
62
Referências
Meios Impressos
 BARTIE, Alexandre. Garantia da Qualidade de Software. Rio de Janeiro:
Elsevier, 2002.
 B...
63
[4].(GOMES N. S., 2010)
Disponível em:
http://www.fazenda.gov.br/ucp/pnafe/cst/arquivos/Qualidade_de_Soft.pdf
Acessado ...
64
[10]. (WADA, 2007)
Disponível em:
http://www.cmqv.org/website/artigo.asp?cod=1461&idi=1&moe=212&id=4467
Acessado em 12 ...
65
[16]. (MARTINS, 2009)
Disponível em:
http://atitudereflexiva.wordpress.com/2009/07/22/falha-erro-e-defeito/
Acessado em...
66
[22]. (NOGUEIRA, Casos de Teste, 2007)
Disponível em:
http://www.testexpert.com.br/?q=node/90
Acessado em 30 de Outubro...
67
[28]. (LOURENÇO, Fases de Testes, 2010)
Disponível em:
http://www.artigonal.com/programacao-artigos/processo-de-teste-d...
68
http://www.testexpert.com.br/?q=node/383
Acessado em 06 de Novembro de 2011 às 15h38min
[35]. (HEINEBERG, 2008)
Disponí...
69
Disponível em:
http://www.testexpert.com.br/?q=node/677
Acessado em 06 de Novembro de 2011 às 16h29min
[42]. (CAETANO)
...
70
TERMO DE COMPROMISSO E RESPONSABILIDADE
Guarulhos, 16 de Novembro de 2011
Pelo presente, eu abaixo assinado declara, so...
Próximos SlideShares
Carregando em…5
×

TCC - QUALIDADE E TESTES DE SOFTWAR

229 visualizações

Publicada em

0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
229
No SlideShare
0
A partir de incorporações
0
Número de incorporações
1
Ações
Compartilhamentos
0
Downloads
2
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

TCC - QUALIDADE E TESTES DE SOFTWAR

  1. 1. DÉBONY SCHMIDT A IMPORTÂNCIA DA QUALIDADE E TESTES DE SOFTWARE Guarulhos 2011
  2. 2. DÉBONY SCHMIDT A IMPORTÂNCIA DA QUALIDADE E TESTES DE SOFTWARE Trabalho de conclusão de curso apresentado à Faculdade Eniac, referente ao curso de Sistemas de Informação. Prof. Neiva Coelho Marostica Guarulhos 2011
  3. 3. Schmidt, Débony A importância da Qualidade e Testes de Software. – São Paulo, 2011.83f. Trabalho de Conclusão de Curso – Faculdade Eniac – Sistemas de Informação. Orientador: Neiva Coelho Marostica
  4. 4. Aluno: Débony Schmidt Título: A importância da Qualidade e Testes de Software A banca examinadora dos Trabalhos de Conclusão em sessão pública realizada em ____/____/______, considerou o(a) candidato(a): ( ) aprovado ( ) reprovado 1) Examinador(a)______________________________________________________ 2) Examinador(a)______________________________________________________ 3) Examinador(a)______________________________________________________
  5. 5. Dedicatória Dedico este trabalho a Deus em primeiro lugar e aos meus pais e irmã que sempre estiveram ao meu lado e proporcionaram toda a estrutura para alcançar meus objetivos. Apoiando e incentivando meu crescimento.
  6. 6. Agradecimentos Agradeço aos meus familiares e amigos pelo apoio. E agradeço também aos professores Lúcio Luzetti, Neiva Coelho Marostica e Rita de Cássia que me auxiliaram no desenvolvimento deste trabalho.
  7. 7. “Se tivesse seis horas para derrubar uma árvore, eu passaria as primeiras quatro horas afiando o machado” (Abraham Lincoln)
  8. 8. Resumo Este trabalho exibe conteúdo relevante sobre os problemas encontrados atualmente nas empresas de desenvolvimento de software. A maioria dos softwares implantados não estão atendendo as especificações dos clientes, estão ultrapassando os prazos e custos previstos na definição do projeto. A principal causa destes problemas é a falta de qualidade nos processos e no produto desenvolvido. Ter um software criado com qualidade desde sua definição garante a satisfação dos clientes, menor quantidade de erros e manutenções realizadas. Para garantir esta qualidade é necessário possuir uma equipe de testes, que será responsável por validar todos os processos e varrer o software verificando se todos os requisitos foram atendidos sem apresentar nenhum erro. O resultado deste investimento são produtos melhores com maior confiabilidade e a equipe interagindo na busca de um produto satisfatório a todo momento cumprindo com os objetivos definidos. Palavras-Chave: Cenário Atual do Software, Qualidade de Software e Testes de Software.
  9. 9. Abstract This work displays relevant content on the problems encountered in today's software development companies. Most of the software deployed are not meeting customer specifications, are beyond the time and cost provided in the project definition. The main cause of these problems is the lack of quality in processes and product development. Having created a software quality since its definition ensures customer satisfaction, fewer errors and maintenance carried out. To ensure this quality is necessary to have a test team, who will be responsible for validating all the software processes and sweep checking that all requirements have been met without showing any error. The results of this investment are better products with greater reliability and staff interacting in pursuit of a satisfactory product at all times complying with the defined objectives. Keywords: Current Scenario Software, Software Quality and Software Testing.
  10. 10. Figuras Figura 1 - Elementos chave do TQM Total Quality Management (Gestão da Qualidade Total).......................................................................................................................8 Figura 2 - Pilares da Qualidade de Software.................................................................... 11 Figura 3 - Ciclo de desenvolvimento no qual qualidade resume-se a testes de software .................................................................................................................................. 13 Figura 4 - Possíveis níveis de maturidade previstos no modelo CMM ........................ 15 Figura 5 - Esforço dedicado à correção de defeitos no desenvolvimento de software ................................................................................................................................................. 18 Figura 6 - Erros, defeitos e falhas ...................................................................................... 20 Figura 7 - Erro de código: "If" sem "End If"....................................................................... 21 Figura 8 - Exemplo de erro na especificação................................................................... 22 Figura 9 - Incidência de defeitos nas etapas de desenvolvimento ............................... 23 Figura 10 - Custo da Qualidade.......................................................................................... 24 Figura 11 - Regra 10 de Myers........................................................................................... 25 Figura 12 - Modelo de relacionamento entre desenvolvimento e testes ..................... 31 Figura 13 - Ponto de equilíbrio dos testes ........................................................................ 32 Figura 14 - Execução Testes Caixa Branca ..................................................................... 34 Figura 15 - Execução Teste Caixa Preta .......................................................................... 36 Figura 16 - Fases dos Testes ............................................................................................. 38 Figura 17 - Modelo IEEE STD 829-1998 .......................................................................... 41 Figura 18 - RUP – Caso de Uso......................................................................................... 43 Figura 19 - Fluxo dos Testes .............................................................................................. 49 Figura 20 - Documentos necessários para o processo de Teste ................................. 51 Figura 21 - Ferramenta Selenium ...................................................................................... 54 Figura 22 - Ferramenta BadBoy......................................................................................... 55 Figura 23 - Ferramenta Canoo WebTest .......................................................................... 56 Figura 24 - Ferramenta JMeter........................................................................................... 57 Figura 25 - Ferramenta TestLink........................................................................................ 58 Figura 26 - Ferramenta Bugzilla ......................................................................................... 59 Figura 27 - Ferramenta Mantis ........................................................................................... 60
  11. 11. Tabelas Tabela 1 - Categorias dos Custos Operacionais da Função Qualidade ........................6
  12. 12. Sumário 1. Cenário Atual.....................................................................................................................3 2. Qualidade de Software ....................................................................................................7 2.1 Definição da Qualidade ............................................................................................7 2.2 Histórico da Qualidade .............................................................................................9 2.3 Gerenciando a Qualidade ..................................................................................... 10 2.3.1. Planejando a Qualidade................................................................................. 11 2.3.2. Garantia da Qualidade ................................................................................... 11 2.3.3. Controle da Qualidade ................................................................................... 12 2.4 Aplicando a Qualidade .......................................................................................... 12 2.5 CMM (Capability Maturity Model) ........................................................................ 14 2.5.1 Apresentação do CMM .................................................................................. 14 2.5.2 Impacto da Maturidade .................................................................................. 17 2.6 Qualidade e Defeitos ............................................................................................. 18 2.6.1 Erro, Defeito e Falha ...................................................................................... 19 2.6.2 Bug .................................................................................................................... 20 2.7 O custo da qualidade............................................................................................. 23 2.8 A Garantia da Qualidade de Software (GQS) ................................................... 25 3. Testes de Software........................................................................................................ 27 3.1 Fundamentos de Teste ......................................................................................... 27 3.2 Pré-conceitos dos testes....................................................................................... 28 3.3 A importância dos Testes ..................................................................................... 29 3.4 Princípios de Teste ................................................................................................ 31 3.5 Técnicas de Teste.................................................................................................. 32 3.5.1 Testes de Caixa Branca................................................................................. 33 3.5.2 Testes de Caixa Preta .................................................................................... 35 3.5.3 Testes de Caixa Cinza ................................................................................... 37 3.6 Estágios dos Testes............................................................................................... 38 3.6.1 Teste de Unidade............................................................................................ 38 3.6.2 Teste de Integração........................................................................................ 38 3.6.3 Teste de Sistema ............................................................................................ 39 3.6.4 Teste de Aceitação......................................................................................... 39 3.7 Elaboração dos Testes.......................................................................................... 39
  13. 13. 3.7.1 Documentação dos Testes............................................................................ 39 3.7.2 Plano de Casos de Teste .............................................................................. 41 3.8 Execução dos Testes ............................................................................................ 48 3.9 Relatórios de Teste................................................................................................ 50 3.10 Ferramentas de Teste........................................................................................ 53 Considerações Gerais.......................................................................................................... 61 Referências............................................................................................................................ 62 Meios Impressos ............................................................................................................... 62 Meios Digitais..................................................................................................................... 62 TERMO DE COMPROMISSO E RESPONSABILIDADE............................................... 70
  14. 14. 1 Introdução O presente trabalho apresentará o resultado de estudos sobre A importância dos Testes de Software. O tema foi escolhido por atuar na área de testes e verificar a falta de conhecimento de equipes de Tecnologia da Informação sobre o assunto e também pelo interesse de divulgar e expandir o trabalho das equipes de Qualidade. Será apresentado neste trabalho o impacto positivo nos softwares produzidos com qualidade que como resultado obtém a satisfação dos Clientes a redução de custos com correções e trabalhos e maior confiança no produto produzido. O objetivo principal é entender que um software pronto não é apenas um software entregue e sim um software com garantia de qualidade. Atualmente as empresas de desenvolvimento de software estão com o foco voltado ao Planejamento do que será desenvolvido e se cumprirão com os prazos e custos previstos. E os resultados obtidos nem sempre estão sendo satisfatórios, o número de projetos que não atendem ao planejamento aumentou significadamente e os motivos mais impactantes são requisitos e especificações do Cliente que não são atendidos, falhas geradas durante o desenvolvimento e após a implantação e custos maiores que o orçamento. Após a implantação de um software, se o mesmo apresentar problemas e divergências nas informações o custo realizado será maior do que o previsto, e os prejuízos serão acumulados tanto para o Cliente quanto para a Empresa. O prejuízo gerado para o Cliente é de ter investido em um projeto pronto a ser entregue na data acordada, porém, este prazo é prorrogado quando erros são encontrados. E para a Empresa o prejuízo é de ter gastos maiores com retrabalho, alocar equipes para a correção sendo que poderiam estar dando andamento a
  15. 15. 2 outros projetos e arcar com os custos, pois, após a data acordada com o Cliente ser ultrapassada o mesmo passa a não ter mais responsabilidade sobre os gastos gerados. Estudos demonstram que softwares sem qualidade além de não compensarem o esforço aplicado, tornam-se softwares sem confiabilidade na informação e com grande possibilidade de ao passar do tempo não serem mais úteis para o objetivo determinado. Para garantir a qualidade de um software empresas de Tecnologia passaram a investir em equipes de testes, demonstrando que o capital investido em pessoas qualificadas para este trabalho reduz o custo investido em softwares “problemáticos” e aumenta a satisfação do Cliente com os produtos entregues. A equipe de testes é responsável por minimizar erros de desenvolvimento da aplicação e garantir que o software a ser implantado atenda todas as especificações exigidas pelo Cliente. Para complementar estas afirmações a apresentação do tema será abordada em quatro capítulos, que descrevemos a seguir: O primeiro capítulo apresentará as considerações gerais sobre o cenário atual das empresas de software e o motivo de apresentarem grande quantidade de falhas após a implantação. O segundo capítulo abordará a Qualidade de Software, todas as definições e a importância de um produto final que atenda as necessidades do Cliente. No terceiro capítulo o processo de teste será apresentado com todas as especificações e formas de trabalho. E para encerrar apresento minhas considerações finais.
  16. 16. 3 1. Cenário Atual Os clientes atualmente estão se tornando mais exigentes com os softwares, buscando projetos que atendam o planejamento de custos, prazos e qualidade. [1] Muitas empresas (geralmente de médio e grande porte) contratam pessoas em curto espaço de tempo para desenvolverem uma aplicação para o Cliente. O que acontece em muitos casos é que ou a aplicação demora muito para ser entregue por restrição de prazo e às vezes de custo, ou é entregue no prazo, porém, com a restrição de qualidade afetada. [1] As empresas estão buscando a tecnologia para reduzir custos e ampliarem sua forma de atuação. Estão sofisticando seus sistemas para tomar decisões cada vez mais complexas, com a intenção de ganhar eficiência, eficácia e controle. Tudo isso pode ser observado através de vários indicadores econômicos, como volume de negócios feitos para indústria de software e hardware, proporção de horas de profissionais diretamente ligados à tecnologia por total de horas de profissionais, entre outros. [2] Com esta cobrança do mercado atual por melhores tecnologias, a área de desenvolvimento de software obteve um grande aumento em suas demandas, porém, criados com pouca capacidade de sucesso. [3] Um dos motivos para as empresas não atenderem as demandas de softwares com qualidade é a própria falta dos processos de desenvolvimento serem cumpridos corretamente. Muitas não entendem ou aplicam um processo de engenharia de software da forma que deveriam, comprometendo o resultado dos projetos que por muitas vezes falham ou até mesmo não são finalizados. (BARTIÉ, 2002) Bartié demonstra resultados de um estudo americano sobre a realidade deste mercado (é importante levar em consideração que os americanos são muito mais exigentes e preparados do que o mercado nacional):
  17. 17. 4  Mais de 30% dos projetos são cancelados antes de serem finalizados.  Mais de 70% dos projetos falham nas entregas das funcionalidades esperadas.  Os custos extrapolam em mais de 180% os valores originalmente previstos.  Os prazos excedem em mais de 200% os cronogramas originais. Muitas empresas acreditam que a forma que utilizam para o desenvolvimento funcionará sempre, não percebem que o processo tem avançado, e que para obterem sucesso precisam adquirir um modelo de qualidade. [2] A utilização de software de qualidade garante a segurança nas transações, dos negócios, das pessoas envolvidas e mantém alta disponibilidade dos serviços. Produtos e serviços são considerados aceitáveis se apresentarem desempenho dentro de certos limites. Muito se fala atualmente e muitos estudos confirmam, que os scanners instalados em pontos-de-venda, nos supermercados, lojas de departamentos e outros estabelecimentos registram preços incorretos com um frequência que varia de 1% a 3%, em virtude de erros na base de dados ou defeitos do scanner. Isso significa que somente 97% dos preços estão corretos, o que não impede essas empresas de continuarem operando normalmente. No entanto, na área de software a coisa se complica. Ou o software funciona corretamente ou é requerida uma ação de alteração para acertá-lo. Qual empresa utilizaria um sistema de contabilidade que apresente precisão de 97%? Dos softwares é sempre esperado desempenho sem falhas. Manter a confiabilidade de desempenho em altíssimo nível continua sendo um dos principais desafios da indústria de software. [4] Os softwares que são desenvolvidos sem atender as necessidades especificadas pelo Cliente, ou que, ao serem implantados apresentem erros ou inconsistências geram alto custo tanto para o Cliente quanto para a Empresa. O custo arcado pelo Cliente é de pagar por um produto a ser entregue perfeitamente em uma determinada data e não receber, ou de receber e ter de paralisar os processos por falhas apresentadas no software. Já o custo arcado pela Empresa é de alocar equipes que façam as correções, gerando retrabalho e falta de mão de obra em novos projetos e custear o tempo de atraso para a entrega do software pronto ao Cliente. [5]
  18. 18. 5 Para que as empresas aumentem a produtividade e obtenha redução de custos como muitas almejam, é necessário que os produtos desenvolvidos obtenham qualidade, que não haja retrabalhos e insatisfação do Cliente. [3] Qualidade de Software é a área de conhecimento da Engenharia de Software que objetiva garantir a qualidade do software através da definição e normatização de processos de desenvolvimento. [6] Nos anos 80 o conceito de qualidade passou a ser utilizado na conferência de cada parte garantindo que estaria correta. [2] A preocupação com a qualidade de software é importante devido a algumas razões óbvias. Ninguém gosta de software com bugs1 .Bugs podem causar prejuízos que variam desde a mera necessidade de reiniciar o sistema operacional até a perda de satélites de milhões de dólares (como o Clementine, um satélite construído para designar alvos, no projeto Guerra nas Estrelas, o qual, quando recebeu um comando para mirar um ponto na superfície lunar, ativou os foguetes direcionais e ficou girando até acabar o combustível...). Bugs podem fazer um banco perder milhões e perder a confiança dos cliente sou parar por horas uma companhia telefônica, impedindo a realização de telefones interurbanos (como já ocorreu com a AT&T). Mas não é só isso. Os esforços pela qualidade na indústria automobilística provaram a tempos que a qualidade não tem custo. Ao contrário do que muita gente pensa, os investimentos em qualidade pagam-se em pouco tempo. [7] Muitas empresas deixam de aderir o processo de qualidade, pois, acreditam ter um custo maior, porém, o que temos visto é que praticar a qualidade reduz o custo de muitos projetos devido a possibilidade de se prever os gastos que serão realizados com o processo de qualidade, já correções, retrabalho e falta de produtividade são custos que não são previsíveis. [7] 1 Bugs: Este termo é geralmente usado em informática quando é encontrado um erro em algum programa, ou seja, quando algum programa age de maneira inesperada ou fora do comum. [8]
  19. 19. 6 Tabela 1 - Categorias dos Custos Operacionais da Função Qualidade Fonte: [4] Todo gasto realizado com a qualidade deve ser considerado investimento e possível de prever, já os custos ocasionados por falhas durante o desenvolvimento ou após entregar o produto não são previsíveis e podem causar prejuízos financeiros e perda de confiança pelos clientes. [4] Um dos objetivos de se implantar um processo de qualidade de software é estabelecer um processo que garanta e gerencie o nível de qualidade do produto e do processo de desenvolvimento. As empresas já entenderam que praticar softwares não adequados, além de prejudicar a imagem da organização aumenta significativamente os custos totais do desenvolvimento. Isso consome a rentabilidade dos projetos de software, além de ampliar os riscos de insucesso dos projetos existentes. [2]
  20. 20. 7 2. Qualidade de Software 2.1 Definição da Qualidade Há várias definições que podem ser atribuídas a Qualidade: “Qualidade de Software é um processo sistemático que focaliza todas as etapas e artefatos produzidos com o objetivo de garantir a conformidade de processos e produtos, prevenindo e eliminando defeitos”. (BARTIÉ, 2002 p.16) “A totalidade das características de uma entidade que lhe confere a capacidade de satisfazer as necessidades explicitas e implícitas”. [2] “Conformidades com os requisitos funcionais e de desempenho explicitamente declarados, padrões de desenvolvimento explicitamente documentados e características implícitas, que são esperadas em todo software desenvolvido profissionalmente.” [2] Segundo Silva (2010) [2] há ainda outras três possíveis definições para qualidade:  Estar em conformidade com os requisitos dos Clientes;  Antecipar e satisfazer as necessidades dos Clientes;  Documentar tudo o que se deve ser feito, e fazer tudo o que foi documentado. “O termo tem tomado vários significados, dependendo de quem interpreta e como se aplica”. [9] De acordo com Campos apud Kan (2008) [9] para se obter a Gestão da Qualidade Total (TQM)2 é necessário atingir os seguintes objetivos: 2 A gestão da qualidade total é uma estratégia de administração orientada a criar consciência de qualidade em todos os processos organizacionais. [10]
  21. 21. 8 Figura 1 - Elementos chave do TQM Total Quality Management (Gestão da Qualidade Total) Fonte: [9] Foco do Cliente (Customer Focus) - O objetivo é atingir a satisfação total do cliente. O foco do cliente inclui o estudo das necessidades e vontades do cliente, coleta de requisitos do cliente e a medição e gerenciamento da satisfação do cliente. Melhoria de Processo (Process Improvement) - O objetivo é reduzir as variações de processo e atingir a melhoria da qualidade contínua. Este elemento inclui ambos os processos de negócio e o processo de desenvolvimento do produto. Através da melhoria de processo, a qualidade do produto será reforçada. Lado Humano da Qualidade (Human Side of Quality) - O objetivo é criar a cultura de qualidade por toda a empresa. As áreas de foco incluem liderança, apoio da alta gerência, participação total de todos os colaboradores da empresa, e outros fatores humanos como sociais e psicológicos. Métricas, Modelos, Medições e Análises (Metrics, Models, Measurement and Analysis) - O objetivo é direcionar a melhoria contínua em todos os parâmetros da qualidade por um sistema de medição orientado a metas. [9] Diante da dificuldade de definir a qualidade, Campos apud Pressman (2008) [9] sugere que a qualidade de software seja implementada e não somente uma idéia ou desejo que uma organização venha ter. Com isso as equipes devem levar qualidade em todo o processo de desenvolvimento com a colaboração de todos.
  22. 22. 9 2.2 Histórico da Qualidade Nos tempos anteriores ao século XX, a qualidade era vista somente como responsabilidade do artífice que era responsável pelo desenvolvimento de produtos. Somente em 1916 foi que realmente a função de qualidade passou a ser exercida pelos Laboratórios Bell3 e em seguida por todas as fábricas. (PRESSMAN, 2002) “No inicio do desenvolvimento de software, a atividade de teste era encarada como a simples tarefa de percorrer o código para corrigir problemas já conhecidos. Essas correções eram feitas pelos próprios desenvolvedores, não existindo recursos específicos para esta atividade. Devido esse motivo, os testes eram realizados somente muito tarde, quando o produto já estava quase ou totalmente pronto. Apesar de essa situação estar associada a uma prática muito ruim de desenvolvimento de software, ela ainda continua presente em muitas organizações”. [2] Para koscianski apud Juran e Gryna (1988) [12] a qualidade esta presente desde muitos anos atrás, quando por exemplo para que as construções egípcias tivessem o tamanho correto era usado o “cúbito”, unidade de medida que correspondia ao tamanho do braço do faraó que estivesse no posto, e a cada lua cheia deveriam ser feitas novas medições para cada construção, caso as medições não fossem feitas ou houvessem erros as punições poderiam ser severas até mesmo levando os responsáveis a morte. Ainda segundo Koscianski apud Vincente (2004) [12] podemos encontrar a qualidade também nos templos da Grécia e Roma antiga, catedrais medievais, onde utilizavam apenas compassos e cordas para realizarem estas construções. Mesmo sem ferramentas adequadas, sem instruções de como realizar o “projeto”, todos obtiveram sucesso ao serem finalizados, isto, foi devido ao planejamento realizado, para se iniciar algo tão grandioso deveriam planejar muito bem como seria a execução e os resultados esperados. 3 Bell Telephone Laboratories ou Bell Labs era originalmente o braço de pesquisa e de desenvolvimento AT&T dos Estados Unidos, desenvolvendo uma série de tecnologias consideradas revolucionárias desde comutadores telefónicos, cabos de telefone, transístores, LEDs, lasers, a linguagem de programação C e o sistema operativo Unix. [11]
  23. 23. 10 As empresas de desenvolvimento de software no inicio de suas atividades utilizavam como metodologia de qualidade os próprios desenvolvedores verificando os códigos em busca de falhas e inconsistências, porém, esta não é a melhor prática a se fazer devido a testes viciados, que não forçam o erro. [2] Em 1957 surgiu o conceito de testes de Software, mas muitos ainda utilizavam apenas ao final dos projetos, isto resultava em softwares que ainda geravam muito retrabalho. Somente nos anos 80 foi que as empresas notaram a importância de testes serem realizados paralelamente ao desenvolvimento. Garantindo que cada fase estava correta. [2] Segundo Tamashiro (2010) [13] entre os anos 80 e 90 os resultados dos testes passaram a ser positivos e as empresas passaram a aplicar recursos para obterem as melhores práticas reduzindo os custos com acertos de falhas e o crescimento de áreas próprias de teste. 2.3 Gerenciando a Qualidade Bartié (2002) subdividia a Qualidade de Software em três pilares fundamentais para a boa prática da atividade, o planejamento da qualidade, a garantia da qualidade e o Controle da Qualidade.
  24. 24. 11 Figura 2 - Pilares da Qualidade de Software Fonte: (BARTIÉ, 2002) 2.3.1. Planejando a Qualidade Esta fase será utilizada para identificar quais os padrões de qualidade que serão aplicados a estrutura dos projetos, porém, a utilização destes padrões varia de empresa para empresa ou ditados pelos clientes. (PRESSMAN, 2002) É importante neste momento definir todas as ferramentas e procedimentos estabelecidos, pois servirão como base para futuras revisões ou auditorias. (FIORINI, ARNLT, & BAPTISTA, 1998) 2.3.2. Garantia da Qualidade Processo que será responsável por certificar que as atividades e o os objetivos determinados serão atingidos, garantindo a correta execução do que foi determinado. [12]
  25. 25. 12 Para Gomes (2010) [4], a Garantia da Qualidade tem como objetivo prover confiança sobre a conformidade de produtos e serviços e requisitos especificados e que venham ao encontro das necessidades dos usuários. 2.3.3. Controle da Qualidade É responsável por verificar se os resultados dos projetos estão atendendo os processos da qualidade durante o desenvolvimento. Para medir, é realizado um acompanhamento da eficácia do desenvolvimento, para que, quando a qualidade não seja realizada em algum ponto, haja tempo de executar ações de manutenção mantendo o nível correto de qualidade. (BARTIÉ, 2002) 2.4 Aplicando a Qualidade A qualidade de software é projetada num produto ou sistema. Ela não é imposta após o fato. Por essa razão, a SQA inicia-se de fato com o conjunto de métodos e ferramentas técnicas que ajudam o analista a conseguir uma especificação de elevada qualidade e o projetista a desenvolver um projeto de elevada qualidade. (PRESSMAN, 2002) Para (BARTIÉ, 2002) muitas empresas de desenvolvimento acreditam que o processo é composto por etapas, e desta forma aplicam os testes em um período determinado somente para isto, porém, os testes devem ser realizados desde o inicio do projeto identificando erros nas fases iniciais e reduzindo os custos com manutenção.
  26. 26. 13 Figura 3 - Ciclo de desenvolvimento no qual qualidade resume-se a testes de software Fonte: (BARTIÉ, 2002) O grupo de Qualidade trabalha junto com o projeto de software já durante seus estágios iniciais, estabelecendo planos, padrões e procedimentos, que irão adicionar valor ao projeto de software, e que satisfazem as restrições do projeto e das políticas da organização. Participando no estabelecimento de planos, padrões e procedimentos o grupo de qualidade garante que esses se ajustem às necessidades do projeto. Também verifica se os planos, padrões e procedimentos serão utilizáveis para efetuar as revisões e as auditorias ao longo do ciclo de vida do software. Revisa as atividades do projeto, audita artefatos de software ao longo do ciclo de vida e proporciona uma visão à gerência que permite verificar se o projeto de software está seguindo o planejado. (FIORINI, ARNLT, & BAPTISTA, 1998) Isso determina que seja necessário garantir a qualidade em todas as partes do processo, não iniciando uma nova etapa caso ainda há erros na etapa atual. Antes de analisar os requisitos, deve-se garantir que o conceito do projeto possui qualidade, antes de iniciar a definição da arquitetura do projeto, os requisitos devem ter sido descritos com qualidade, antes de codificar deve-se garantir que a modelagem foi feita corretamente e assim por diante em todas as fases. (BARTIÉ, 2002) “Qualidade não é uma fase do ciclo de desenvolvimento de software, é parte de todas as fases” (BARTIÉ, 2002) O Centro de Pesquisa SEI (Software Engineering Institute) patrocinado pelo Departamento de Defesa dos Estados Unidos realizou um dos trabalhos mais importantes de analise da maturidade de organização das empresas. E o resultado
  27. 27. 14 disso foi a elaboração do CMM (Capability Maturity Model), um modelo que propõe o processo de software com melhoria continua. [2] 2.5 CMM (Capability Maturity Model) 2.5.1 Apresentação do CMM Capability Maturity Model (CMM), foi desenvolvido para estruturar o processo de desenvolvimento de uma forma com mais controle e eficácia. Para que estes sejam alcançados o CMM funciona de forma gradativa, partindo do principio de que a empresa não possui nenhum modelo de organização dos processos, e aumentando a eficiência de etapa em etapa, até que todos as etapas estejam sendo executadas corretamente. [2] O modelo se baseia em cinco níveis de maturidade, no qual estes níveis representam o crescimento da maturidade no desenvolvimento. Este nível de maturidade é avaliado de organização para organização, demonstrando qual o controle que possuem sobre o processo no geral. (BARTIÉ, 2002) Os níveis são incrementais, ou seja, não é possível sair do nível 1 e atingir o nível 3 sem completar o nível 2, e cada um visualiza apenas os pontos em que sua organização permite. (BARTIÉ, 2002)
  28. 28. 15 Figura 4 - Possíveis níveis de maturidade previstos no modelo CMM Fonte: (BARTIÉ, 2002) No nível 1 a organização está sem nenhum modelo de maturidade, e para que esta etapa seja cumprida é importante o desempenho de todos os colaboradores, pois, não possuem ainda os processos que possam auxiliar. Como esta etapa exige maior agilidade, mesmo cumprindo com o especificado, normalmente os prazos e orçamentos não são cumpridos. [14] No nível 2 a definição de como será o gerenciamento de software e como funcionará sua implementação já estão estabelecidos. E para planejar e gerenciar os novos projetos são analisados os pontos que foram eficazes em projetos anteriores, permitindo à organização repetir estes pontos utilizando as melhores práticas. Sempre praticando, documentando, garantindo, treinamento e com foco nas melhorias continuas. [2] Este nível é considerado como um método disciplinado devido ao planejamento e documentação estáveis, e permite que os processos que obtiveram sucesso se repitam em todos os projetos. [2]
  29. 29. 16 No nível 3 todos os processos e procedimentos já estão especificados e documentados. Sendo estes, a base para este nível e sempre adaptados com melhorias continuas. Com os padrões especificados a organização consegue determinar que sejam aplicados em todo o desenvolvimento estabelecendo objetivos. [14] A diferença entre os níveis 2 e 3 é que, no nível 2 são estabelecidos padrões para os projetos, que podem haver particularidades e objetivos diferentes. Já no nível 3 são estabelecidos padrões para a organização como um todo, unidos com os do nível 2. “Como resultado, os processos realizados através da organização são consistentes exceto pelas diferenças permitidas pelos guias.” [14] Neste nível é possível organizar métodos dinâmicos para o desenvolvimento, acrescentando, modificando ou removendo atividades, variando de acordo com as especificações dos projetos. [2] É criado um grupo denominado SEPG (Software Engineering Process Group), onde serão responsáveis por determinar e documentar todas as etapas do processo. Esta equipe determina os pontos do processo possibilitando a “customização” estabelecendo em quais situações e quando serão aplicados. [2] “Neste nível é possível visualizar claramente como cada projeto em execução está evoluindo.” [2] No nível 4 o processo de gerenciamento irá utilizar todas as métricas para monitorar o empenho no processo de desenvolvimento, estabelecendo metas quantitativas. [14] São avaliadas a produtividade e qualidade de todas as etapas do desenvolvimento, como item de uma forma de medição, utilizando um banco de dados que obtenha toda a análise de dados dos processos definidos no projeto.
  30. 30. 17 Sendo estas medições consistentes e com grande definição. Disponibilizando bases para que sejam avaliados os processos do projeto. [2] E o nível 5 após ter todas as metas definidas nos níveis anteriores, os processos passam a ter melhorias contínuas determinadas pelo aprendizado adquirido das causas comuns dos processos, sendo medidos e acompanhados. [14] Este nível tem como papel principal utilizar os resultados do nível 4 para que sejam aplicadas mudanças com o foco na melhoria dos processos para que os objetivos sejam todos atendidos com qualidade. [14] 2.5.2 Impacto da Maturidade Um dado importante que o SEI4 estima é o fato de que as empresas de nível dedicam cerca de 55% dos esforços direcionados para corrigir defeitos do projeto de software desenvolvido. À medida que a empresa vai adquirindo maturidade, esses índices vão sendo gradativamente reduzidos para 35%, 20%, 10% até a empresa alcançar o nível 5 e reduzir esse patamar para 5%. Imagine o impacto do tempo total do desenvolvimento, custo final do projeto, número de profissionais envolvidos e o nível de confiabilidade que esta empresa alcança quando atinge esse patamar de excelência organizacional. (BARTIÉ, 2002) 4 A Software Engineering Institute (SEI) define iniciativas específicas destinadas a resolver os problemas que impedem a maturidade e capacidade das organizações para adquirir, construir e desenvolver sistemas previsivelmente no prazo, dentro do custo esperado, atendendo os requisitos e sem vulnerabilidade. [15]
  31. 31. 18 Figura 5 - Esforço dedicado à correção de defeitos no desenvolvimento de software Fonte: (BARTIÉ, 2002) Para empresas que possuem pouca maturidade, o esforço gerencial para manter software com qualidade é maior, devido a falta de preparação para executar atividades de grande porte, não possuírem organização nos processos e documentação adequada. [2] “A maior parte das organizações é resistente à inovação do processo de desenvolvimento, pois acredita que o aperfeiçoamento é uma atividade impraticável.” [2] 2.6 Qualidade e Defeitos Defeitos de software são os principais motivos que geram retrabalho, custos, não cumprimento de prazos, redução da produtividade e insatisfação do Cliente. (BARTIÉ, 2002) E estes defeitos encontrados nos softwares recebem muitos nomes e definições, como “problemas, falhas, ocorrências, incidentes, não conformidades e
  32. 32. 19 inconsistências. Também podemos empregar palavras existentes na língua inglesa como bugs, crash e abends”. (BARTIÉ, 2002) Qual a melhor palavra para descrever que um software “travou” ou não está agindo de forma correta? [12] 2.6.1 Erro, Defeito e Falha É importante distinguir falha, erro e defeito para que se crie uma linguagem comum entre os membros de uma equipe e para que se possa fazer uma análise de causa raiz quando um problema ocorre.” [16] O erro significa que algo não está funcionando corretamente no software, gerando inconsistências na aplicação. É conseqüência de uma falha, mas não são todas as falhas que resultam em um erro, pois, a seqüência de execução pode não gerá-los. [16] Um defeito no software pode ser originado por omissão de alguma informação, declaração de dados, controles incorretos ou vários outros motivos. Caso um defeito não seja identificado ele passa a ser uma falha na execução do software. [17][17] A falha é quando um software não se comporta da forma esperada, ou não retorna os resultados esperados. [17]
  33. 33. 20 Figura 6 - Erros, defeitos e falhas Fonte: [17] 2.6.2 Bug É um erro no funcionamento comum de um software, também chamado de falha na lógica programacional de um programa de computador, e pode causar discrepâncias no objetivo, ou impossibilidade de realização, de uma ação na utilização de um programa de computador ou apenas uma trava no sistema. [8] O termo é utilizado para descrever problemas que não tem explicação, e esta presente no mundo da informática a muito tempo. Tomas Edison em seus circuitos elétricos já mencionava os bugs. [8] O Bug pode ser designado como um erro na execução de um software, possivelmente resultando em inconsistências nos resultados esperados de um programa. Abaixo a figura demonstra um exemplo da definição de Bug durante a criação do código de um sistema, que quando é executado pelo usuário não se comporta da forma correta, resultando em uma falha. [18]
  34. 34. 21 Figura 7 - Erro de código: "If" sem "End If" Fonte: [18] Há uma imagem de que os bugs são encontrados somente no código fonte. Assim como, entendem que somente o desenvolvedor e a equipe de qualidade são os responsáveis pelos bugs. Nas duas afirmações a visão esta errada, pois os e bugs podem ser gerados em todo o processo no desenvolvimento, como por exemplo, resultados de uma especificação de requisito, análise, modelo de dados ou interface do sistema feitos de forma incorreta. (BARTIÉ, 2002)
  35. 35. 22 Figura 8 - Exemplo de erro na especificação. Fonte: [18] Os erros estão em todas as etapas do processo, porém, estudos reforçam que a maior parte está presente nas fases iniciais do projeto. No produto final são encontrados muitos erros que resultaram da má especificação e clareza dos objetivos que deveriam ser cumpridos. Se a qualidade fosse aplicada desde a definição do projeto muitos erros seriam identificados prematuramente evitando que fossem migrados para as outras fases. (BARTIÉ, 2002)
  36. 36. 23 Figura 9 - Incidência de defeitos nas etapas de desenvolvimento Fonte: (BARTIÉ, 2002) 2.7 O custo da qualidade “O custo da qualidade inclui todos os custos decorrentes da busca da qualidade ou da execução das atividades relacionadas à qualidade.” (PRESSMAN R. , 2002) Os custos investidos em qualidade são todos aqueles investimentos em um produto ou serviço para que atendam a qualidade total e podem ser divididos em custos da conformidade e custos da não conformidade. (BARTIÉ, 2002) Os custos da conformidade são aplicados para alocar pessoas, processos e ferramentas que previnam e detectem os erros do processo durante o desenvolvimento. E os custos da não conformidade são aqueles ligados ao processo de reparação de falhas ocorrido no decorrer do processo ou após a entrega do produto. (BARTIÉ, 2002) A cada uma das fases está determinado um custo. Todos somados resultam no custo total da qualidade contemplando o custo da construção. [19]
  37. 37. 24 Figura 10 - Custo da Qualidade Fonte: [19] Custo de Falhas – Envolve todos os custos associados a produtos defeituosos, que já foram entregues aos usuários ou disponibilizados em produção e que geraram algum tipo de falha. Esses custos referem-se ao retrabalho para reparação de produtos defeituosos, ou a prejuízos decorrentes das falhas no software. Incluem-se nesta categoria, também os custos associados à manutenção de um Help Desk. Custo de Avaliação – Esse custo refere-se ao que é gasto em procedimentos de verificação e em testes dos produtos de software para identificação de defeitos, após a sua construção e antes que sejam disponibilizados para uso ou implantados em produção. Contempla tanto produtos intermediários, como documentos de requisitos, modelos de dados ou especificações, como também o produto de software final. Custo de Prevenção – Mais que um custo, é um investimento realizado para se evitar erros e fazer o trabalho certo na primeira tentativa. É um investimento com retorno a médio ou longo prazo e que contempla a criação de métodos e procedimentos, a melhoria de processos, a capacitação dos profissionais, a aquisição de ferramentas e o planejamento da qualidade. Esse custo ocorre antes da criação do produto. [19] O custo da qualidade passa a ser sempre investimento quando realizado com o intuito de melhorar e garantir o correto desenvolvimento de um produto. Porém,
  38. 38. 25 para que este processo seja aplicado corretamente deve ser aplicado um montante de dinheiro, profissionais e tempo. Para reduzir estes investimentos é importante identificar as atividades com maior importância e criticidade. (BARTIÉ, 2002) Para demonstrar a evidente vantagem de se manter um processo de qualidade Bartié exibe o gráfico da Regra 10 de Myers5 demonstrando que identificar os erros nas fases iniciais do processo custam menos dos que os ocorridos nas fases finais. Figura 11 - Regra 10 de Myers Fonte: (BARTIÉ, 2002) 2.8 A Garantia da Qualidade de Software (GQS) O grupo de Garantia do Software tem como principal papel representar o Cliente, quanto às avaliações sobre o software desenvolvido, analisando se o software atende de forma correta os padrões de qualidade, se a parte técnica 5 A Regra 10 de Myers indica que o custo da correção dos defeitos tende a ser cada vez maior tanto 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. [20]
  39. 39. 26 respeitou adequadamente os papéis para cada atividade dentro do desenvolvimento. (PRESSMAN, 2002) O objetivo da GQS é fornecer resultados sobre a eficiência das etapas utilizadas pelo desenvolvimento e sobre a qualidade do produto que será entregue. Para exibir estes resultados, a equipe realiza um exame meticuloso no software buscando encontrar se existem desvios de padrões e especificações determinadas ou que necessite de melhorias. [21] Esta verificação deve ocorrer em todas as etapas do processo de desenvolvimento com o intuito de prever defeitos antes do produto ser finalizado. [21] Todo processo de desenvolvimento por muitas vezes gera produtos defeituosos, é importante obter um processo que descubra esses defeitos e garanta o bom funcionamento do projeto. Estes defeitos geram problemas tanto para a imagem da empresa quanto para o negócio. E para garantir que não impactem no projeto e que sejam corrigidos foi criada a área a de Testes de Software. (BASTOS, A. et. al., 2007) “A atividade de teste de software combina uma estratégia de múltiplos passos com uma série de métodos de projeto de casos de testes6 que ajudam a garantir uma detecção de erros efetiva”. (PRESSMAN, 2002) 6 Casos de Testes: é aquele documento que possui entradas dentro inseridas no sistema/programa e suas saídas esperadas. Mostra os caminhos percorridos por um módulo, caso de uso ou funcionalidade dentro do projeto. Servem como base para que os testadores possam executar os testes manualmente, mas podemos cria-los com o intuito de automatizar os casos e devem cobrir o máximo de situações possíveis. [22]
  40. 40. 27 3. Testes de Software 3.1 Fundamentos de Teste A atividade de teste é um ponto importante no processo de garantia da qualidade e tem como responsabilidade representar a avaliação final da especificação, projeto e processo de codificação. (PRESSMAN, 2002) A atividade de teste constitui uma anomalia interessante para o engenheiro de software. Durante as fases de definição e desenvolvimento anteriores, o engenheiro tenta construir o software, partindo de um conceito abstrato para uma implementação tangível. Agora, surge a fase de testes. O engenheiro cria uma série de casos de teste que têm a intenção de “demolir” o software que ele construiu. De fato, a atividade de teste é um passo do processo de engenharia de software que poderia ser visto (psicologicamente, pelo menos) como destrutivo, em vez de construtivo.(PRESSMAN, 2002 p.787) Os testes são executados na maioria das empresas como etapa do desenvolvimento, e por muitas vezes é realizado pelos desenvolvedores ou usuários. O objetivo é reduzir os defeitos originados pelo desenvolvimento. (BASTOS, A. et. al., 2007) Em um novo formato, os testes começam a ser realizados por profissionais especializados para esta função, com uma metodologia apropriada e não mais por um desenvolvedor. Pois, nem analistas, nem desenvolvedores, nem usuários possuem capacidade técnica para execução dos testes. (BASTOS, A. et. al., 2007) Se os testes forem realizados com sucesso serão identificados erros no software. A área de testes exibe que o software desenvolvido atende as especificações determinadas pelos requisitos. Além disso, a atividade de teste proporciona confiabilidade no produto. (PRESSMAN, 2002)
  41. 41. 28 É importante saber que a atividade de teste não garante que os bugs não existirão, ela apenas demonstra se há defeitos presentes no software. (PRESSMAN, 2002) 3.2 Pré-conceitos dos testes Para que os testes sejam aplicados de forma correta é necessário eliminar alguns pré-conceitos existentes em muitas equipes:  A equipe de testes é inimiga da área de desenvolvimento: não há o objetivo de demonstrar que alguns são mais competentes que os outros, ou que erram constantemente. Existe apenas o intuito de produzir produtos com qualidade.  Desenvolvedores com pouca qualidade podem testar sistemas: para que os testes tenham a correta funcionalidade é necessário ter uma equipe capacitada, e que por muitas vezes necessitem até de certificados para comprovar sua qualificação.  Após terminar o desenvolvimento de software a equipe de teste realizará seu papel: os testes devem ser executados desde o principio do projeto, os testes executados no final do desenvolvimento são os realizados pelo cliente, para apenas validar que o produto atende suas necessidades. (BASTOS, A. et. al., 2007) Outros pré-conceitos, segundo Davidson (2011) [23]:  “...Implemente, se der tempo a gente testa.”  “o importante é entregar... os testes, deixa que o cliente faz para gente...”  “o prazo vai estourar... Então sacrifique os testes..”  “entregue com bugs, mas entregue em dia, depois agente arruma…”
  42. 42. 29  “sabemos que nosso software está cheio de bugs, então vamos cobrar uma manutenção mensal do nosso cliente para consertá-los…”  “testar não é uma atividade importante…”  ”…como vamos testar se não temos tempo?”  “…testar pra que? perda de tempo.”  “pra desenvolver sem teste é X, com teste é X2…“ Por mais absurdas que pareçam ser estas afirmações, muitas empresas aplicam ainda estes conceitos. (BASTOS, A. et. al., 2007) 3.3 A importância dos Testes Para que um software seja de alta qualidade é imprescindível que os testes sejam realizados. Há um descuido quando isso não ocorre, já que não são analisados os impactos de um produto com má qualidade. O negócio ou mesmo vidas (em caso de software para aparelho médico, aviões e etc.) podem sofrer as consequências de um software sem testes ou que não foram buscados os bugs adequadamente. [24] Exemplo disso: Três anos atrás, o Station Casinos idealizou uma ótima promoção para atrair clientes: oferecer 25 dólares de jogo gratuito em máquinas caça-níqueis a partir de seus cartões de fidelidade eletrônicos. Funcionou como mágica, apostadores afluíram ao cassino em bandos. Era para ser uma boa estratégia de negócios. Porém, em uma sexta-feira, logo depois de iniciada a promoção, quando os jogadores inseriram seus cartões nas máquinas, nada aconteceu. O grande número de pessoas tentando acessá-las e ao mesmo tempo em que o departamento de contabilidade rodava diversas aplicações financeiras travou os servidores que armazenavam toda a informação promocional. Irados, jogadores atiraram seus cartões de fidelidade no chão e iniciaram um tumulto. Uma reação nada boa. [24] O problema foi causado devido à falta de testes para um volume de acessos tão grande, fazendo com que a empresa deixasse de ganhar dinheiro e tivesse que
  43. 43. 30 criar outra promoção para se redimir do erro e os clientes ficaram insatisfeitos com o ocorrido. [24] Outros exemplos: A empresa Symantec proprietária do software antivírus Norton que em junho de 2007 teve de compensar 50 mil vítimas de uma atualização que retirava arquivos de sistema de uso, dando a elas uma extensão de 12 meses da licença do Norton e uma cópia da ferramenta Norton Save & Restore 2.0. (LOPES & CARNEIRO) [25] Em 1988, o navio US Vicennes derrubou um Airbus 320 causando a morte de 290 pessoas, a falha foi atribuída ao software de reconhecimento do navio que confundiu o avião com um F-14. [25] Todo software desenvolvido tem como objetivo atender demandas, e para que seja garantida a eficácia dos programas é necessário testar os softwares, pois, sempre existirá a probabilidade de se existirem defeitos, bem como reduzir custos e identificar as qualidades dos softwares como: “confiabilidade, qualidade, desempenho, usabilidade, portabilidade, segurança, recuperabilidade e outras.” [25] Segue abaixo um modelo de relacionamento entre o desenvolvimento do software os testes.
  44. 44. 31 Figura 12 - Modelo de relacionamento entre desenvolvimento e testes Fonte: (BASTOS, A. et. al., 2007) 3.4 Princípios de Teste Os testes devem ser executados em todas as etapas do projeto, mas, é importante saber identificar até que momento os testes poderão ser executados, para isto há duas situações a serem analisadas. (BASTOS, A. et. al., 2007)  Cobranças sobre prazos de projeto, onde os testes são interrompidos antes do tempo definido, ou seja, não foram realizados todos os testes pré-definidos e o risco de ocorrerem defeitos é muito maior.
  45. 45. 32  Excesso de testes, quando são executados mais testes do que o previsto, ultrapassando o tempo estimado e com um gasto maior do que o necessário. (BASTOS, A. et. al., 2007) Figura 13 - Ponto de equilíbrio dos testes Fonte: (BASTOS, A. et. al., 2007) O custo das falhas que possam vir a ocorrer num ambiente de produção não compensa o gasto adicional de dinheiro para tentar evitá-las. No caso de um software usado nos controles de um avião, o ponto de equilíbrio ficará bastante à direita, ao passo que, no caso de um site Web de páginas estáticas, esse ponto estará bem a esquerda. Quanto mais critico for o software, mais testes serão gastos para garantir a qualidade desse produto. Isso equivale a dizer que quem define a quantidade de testes é a criticidade do negócio. (BASTOS, A. et. al., 2007) 3.5 Técnicas de Teste Durante o processo de desenvolvimento de um software serão aplicados dois tipos de teste, o de verificação e o de validação. O teste de verificação é responsável por certificar a qualidade de todos os pontos do desenvolvimento, concentrando-se
  46. 46. 33 em duas formas de avaliação, a Revisão voltada para a documentação e a Auditoria que garante a qualidade das atividades realizadas. Já o teste de Validação após receber o software finalizado, é responsável por apontar os erros gerados em processos isolados ou no produto completo, para que estes testes abordem todas as áreas do software são definas algumas técnicas para a execução dos mesmos. (BASTOS, A. et. al., 2007) 3.5.1 Testes de Caixa Branca O teste de caixa branca é responsável por avaliar a parte interna do software, atuando diretamente no código fonte avaliando os testes de condição, fluxo de dados, ciclos, caminhos lógicos. [27] O objetivo principal é apontar defeitos utilizando a simulação de condições que realizem corretamente a estrutura feita durante a codificação. Possuem grande eficiência na identificação de erros, porém, são mais difíceis de implantar. (BARTIÉ, 2002)
  47. 47. 34 Figura 14 - Execução Testes Caixa Branca Fonte: (BARTIÉ, 2002) Para a realização dos testes de caixa branca foram definidos testes específicos para cada situação. (BASTOS, A. et. al., 2007) 3.5.1.1 Teste de Estresse O teste de estresse é executado para forçar situações extremas de utilização do software, avaliando até que ponto exigir em memória, espaço em disco e CPU. É importante analisar a quantidade de dados que recebe acima da média estipulada. (BASTOS, A. et. al., 2007) 3.5.1.2 Teste de Execução É responsável por analisar o tempo de resposta, da execução e de performance do software em produção. Em um software feito por etapas e por equipes diferentes este teste seria responsável por executar o teste por completo. [26] 3.5.1.3 Teste de Recuperação Este teste analisa a capacidade do software de recuperar as informações ao ser reiniciado após uma perda da integridade. Exige que o software retorne em uma etapa do processo onde a continuidade não seja afetada. (BASTOS, A. et. al., 2007)
  48. 48. 35 3.5.1.4 Teste de Operação São testes utilizados no ambiente de operação em que atuará, com usuários que irão executar a ação e com os procedimentos determinados verificando se a aplicação irá funcionar adequadamente. (BASTOS, A. et. al., 2007) 3.5.1.5 Teste de Conformidade Verifica se o produto final atende a todas as especificações de padrão, normas, procedimentos e as guias de TI. [26] 3.5.1.6 Teste de Segurança É um procedimento importante para se avaliar a segurança das informações do software, garantindo a confidencialidade e proteção dos dados. Este teste tem o objetivo de evitar que informações sejam acessadas por pessoas não autorizadas comprometendo o negócio ou fornecendo informações para empresas concorrentes. (BASTOS, A. et. al., 2007) 3.5.2 Testes de Caixa Preta É responsável por analisar o comportamento externo do software, sem se preocupar se internamente os processos estão sendo executados corretamente. Para executar são inseridos dados de entrada, os testes são executados e o resultado da execução é comparado ao resultado esperado. Para que o teste seja cada vez mais funcional é importante fornecer todas as entradas de dados possíveis. [27] O teste de caixa preta não exige que o responsável tenha conhecimento lógico da tecnologia aplicada, os testes são mais simples do que o de caixa branca. A única dificuldade de realizar este tipo de teste é exigir que a equipe responsável
  49. 49. 36 pela homologação realize um planejamento detalhado e apurado para que seja possível identificar todos os cenários possíveis. (BARTIÉ, 2002) Figura 15 - Execução Teste Caixa Preta Fonte: (BARTIÉ, 2002) 3.5.2.1 Teste de Requisitos Os testes de requisitos analisam se o software esta executando de forma correta as funcionalidades e se possui capacidade de continuar eficiente após ser utilizado por um período contínuo. (BASTOS, A. et. al., 2007) 3.5.2.2 Teste de Regressão Tem o objetivo de analisar se algo foi alterado de como era realizado antes da nova funcionalidade ser aplicada, ou seja, é retestar etapas já testadas após uma alteração no software. São executados tanto no software quanto na documentação. (BASTOS, A. et. al., 2007) 3.5.2.3 Teste de Tratamento de Erros Estes testes são executados forçando os erros no sistema, para analisar a capacidade do software de lidar com informações incorretas. Exigindo que o responsável pelo teste pense de forma negativa e informe dados de entrada incorretos, analisando a forma de resposta do software. [26]
  50. 50. 37 3.5.2.4 Teste de Suporte Manual Analisa se os manuais e guias para os usuários estão sendo feitos de forma correta, se estão completos. [26] 3.5.2.5 Teste de Interconexão São executados quando o software em questão possui conexão com outros softwares, analisando se os dados estão sendo transferidos de forma correta. (BASTOS, A. et. al., 2007) 3.5.2.6 Teste de Controle Assegura que o processamento seja realizado conforme sua intenção. Entre os controles estão a validação de dados, a integridade dos arquivos, as trilhas de auditoria, o backup e a recuperação, a documentação, entre outros. [26] 3.5.2.7 Teste Paralelo Realizar uma comparação dos dados gerados pela nova versão do software com a versão anterior, exigindo que os dados de entrada sejam os mesmos executando em duas versões do mesmo software, caso os requisitos sejam os mesmo apenas as versões foram alteradas os resultados devem ser iguais nas duas. (BASTOS, A. et. al., 2007) 3.5.3 Testes de Caixa Cinza Os testes de caixa cinza utilizam tanto os testes de caixa preta quanto os testes de caixa branca, envolvendo a estrutura dos dados e os algoritmos. Fornecendo dados de entrada e verificando a execução interna destes dados validando a saída dos mesmos. [26]
  51. 51. 38 3.6 Estágios dos Testes Figura 16 - Fases dos Testes Fonte: (BARTIÉ, 2002) 3.6.1 Teste de Unidade É realizado em unidades menores do sistema, analisando métodos e partes pequenas do código em busca de falhas de execução. Verificando individualmente estas pequenas etapas para garantir que cada uma está sendo executada corretamente. [28] 3.6.2 Teste de Integração Este teste garante que não haverá erros quando todas as etapas individuais do sistema forem executadas de forma integrada. Normalmente são encontrados
  52. 52. 39 erros de transição de dados. Não faz parte deste teste avaliar a conexão com outros sistemas (teste de interconexão). [28] 3.6.3 Teste de Sistema Realiza a execução do sistema como um todo para verificar as funções seguindo os cenários criados para os testes. [26] 3.6.4 Teste de Aceitação Esta fase é realizada pelos usuários do sistema, validando se o que foi desenvolvido atende as especificações solicitadas. É um teste a ser realizado pelo cliente solicitante de forma formal para que avalie se irá aceitar ou não o sistema. [28] 3.7 Elaboração dos Testes 3.7.1 Documentação dos Testes Na etapa de Testes de um projeto, o tempo gasto com a documentação dos testes é de 50% a 60%. (BASTOS, A. et. al., 2007) Através da Norma IEEE 829-19987 foram definidos documentos para a equipe de testes, entre eles o documento de elaboração dos testes. O Plano de Teste é o documento que será origem para os demais documentos. (BASTOS, A. et. al., 2007) Plano de Teste: Documenta todo o planejamento para a realização dos testes, apontando os itens que serão testados, quais atividades serão executadas e os riscos dos testes. Identifica também quais serão os ambientes a serem testados. (BASTOS, A. et. al., 2007) 7 IEEE 829, também conhecido como o Padrão 829 para Documentação de Teste de Software, é um padrão IEEE que especifica a forma de uso de um conjunto de documentos em oito estágios definidos de teste de software, cada estágio potencialmente produzindo seu próprio tipo de documento. O padrão especifica o formato desses documentos, mas não estipula se todos eles devem ser produzidos, nem inclui qualquer critério de conteúdo para esses documentos. [29]
  53. 53. 40 Durante a fase de Elaboração dos Testes serão utilizados três documentos: Especificação do projeto de Teste: Documento detalhado sobre o plano de teste, identificando também os casos de teste e procedimentos que serão utilizados, apresentando os critérios para aprovação. (BASTOS, A. et. al., 2007) Especificação de casos de Teste: Serão descritos os casos de teste, identificando quais os dados de entrada a serem utilizados, quais serão os resultados, ações e formas de execução dos testes. Este documento pode também ser chamado de Plano de Caso de Testes. (BASTOS, A. et. al., 2007) Especificação do procedimento de Teste: Demonstra todas as necessidades para operar o software e os casos de teste com objetivo de atender o planejamento de testes. Este documento tem por objetivo ser seguido sem nenhum imprevisto. (BASTOS, A. et. al., 2007)
  54. 54. 41 Figura 17 - Modelo IEEE STD 829-1998 Fonte: (BASTOS, A. et. al., 2007) 3.7.2 Plano de Casos de Teste É o documento que aponta o planejamento dos testes elaborados de acordo com os requisitos determinados no desenvolvimento do sistema. Determinando os itens a serem testados, o principal objetivo deste documento é registrar a maior quantidade de cenários possíveis. Os cenários serão representados por um grupo de casos de testes que serão verificados de acordo com uma listagem de procedimentos. (BARTIÉ, 2002)
  55. 55. 42 3.7.2.1 Casos de Teste A melhor definição para casos de teste é o maior detalhamento possível de um teste, com especificações de telas e formulários. São identificadas as informações que serão utilizadas durante o teste e quais serão os resultados retornados. Um caso de teste considerado bom deve conter: (BASTOS, A. et. al., 2007)  Identificação das condições de testes: o Pré-condições; o Pós-condições; o Critério de aceitação.  Identificação dos casos de testes (o que testar).  Detalhamento da massa de entrada e de saída.  Critérios especiais, caso necessário, para a geração da massa de teste.  Especificação das configurações de ambiente no qual o teste será executado: sistema operacional, ferramentas necessárias, origem dos dados etc. (onde testar)  Definir o tipo de implementação do teste: automática/manual (como testar).  Listar as interdependências, caso existam, entre os casos de teste. (BASTOS, A. et. al., 2007) 3.7.2.2 Derivação do Caso de Teste Para os testes funcionais um caso de teste costuma ser derivado de um caso de uso. É necessário criar um caso de teste que atenda a cada caso de uso. (BASTOS, A. et. al., 2007) Na metodologia RUP os casos de uso possuem vários caminhos refletindo, os possíveis fluxos básicos e alternativos, sendo identificados pelas setas. (BASTOS, A. et. al., 2007)
  56. 56. 43 Figura 18 - RUP – Caso de Uso Fonte: (BASTOS, A. et. al., 2007) O fluxo básico ou principal, representado pela linha preta e retilínea, é o caminho mais simples através do caso de uso. Cada fluxo alternativo começa no fluxo principal e depois, de acordo com uma condição especifica, é executado. Os fluxos alternativos podem retornar ao fluxo básico (como, por exemplo, os fluxos alternativos 1 e 3 da imagem acima), podem se originar de outro fluxo alternativo (fluxo alternativo 2) ou terminar o caso de uso sem retornar a um fluxo (fluxos alternativos 2 e 4). (BASTOS, A. et. al., 2007) Com os caminhos exibidos na figura é possível identificar os cenários de uso. Possibilitando a criação dos cenários de teste. (BASTOS, A. et. al., 2007) 3.7.2.3 Exemplos de Caso de Teste Casos de Teste elaborados de acordo com a visão de Bastos, A.et. al. (2007). 3.7.2.3.1 Apresentação do Software O software exibirá dois campos: Login e Senha. O software exibirá as seguintes opções de confirmação: Ok e Limpar.
  57. 57. 44 Caso o usuário acione a opção Limpar:  O software deverá excluir as informações de Login e Senha. Caso o usuário acione a opção Ok:  O software verifica o preenchimento do Login e Senha que são campos obrigatórios.  O software valida as informações inseridas nos campos Login e Senha. Exceções do Software E1 – Campos de preenchimento obrigatório. Se o usuário não preencher um dos campos ou os dois:  O software exibirá uma mensagem informativa: “O(s) <<campo>> deve(m) ser preenchido(s)” e retorna para a tela inicial. E2 – Verificação de login e senha. Caso um dos campos não tenha sido preenchido corretamente o software apresentará a mensagem informativa: “O dados não são válidos” e retorna para a tela inicial. E3 – Login bloqueado O software valida se o login informado esta bloqueado, exibe a mensagem informativa: “Login bloqueado” e retorna para a tela inicial. Regras de Negócio RN01 – Bloqueio de Login Caso o usuário realize três tentativas incorretas de acesso ao software, o mesmo irá bloquear o acesso deste login. Regras de Usabilidade US01 – Formatação O campo Login não deverá realizar a diferenciação de letras maiúsculas e minúsculas (case insensitive), já o campo senha deverá realizar esta diferenciação (case sensitive).
  58. 58. 45 SISTEMA EMPRESARIAL Login: Senha: Protótipo da Tela 3.7.2.3.2 Definição Casos de Teste CT01 – Campos Obrigatórios Pré-Condições Acessar a tela de login. Pós-Condições Software exibe mensagem de erro. Detalhamento PA*: O usuário não informa o login ou senha. PA: O usuário aciona a opção Ok. PS**: O software valida se os campos obrigatórios estão preenchidos. PS: O software exibe a mensagem “O(s) <<campo>> deve(m) ser preenchido(s)” Massa de Entrada e Saída Não aplica Critérios Especiais Não aplica Ambiente SO Windows Vista Professional, browser Google Chrome. Implementação Manual Iteração 1ª Interdependências Não aplica. *PA: Passo do Autor **PS: Passo do Software
  59. 59. 46 CT02 – Login incorreto Pré-Condições Acessar a tela de login. Pós-Condições Software exibe mensagem de erro. Detalhamento PA: O usuário informa o login incorreto e senha correta. PA: O usuário aciona o opção Ok. PS: O software valida que os campos foram preenchidos. PS: O software valida se o Login informado esta cadastrado e se a Senha informada é valida. PS: O software exibe a mensagem “Os dados não são válidos”. Massa de Entrada e Saída Login incorreto e senha correta. Critérios Especiais Não aplica Ambiente SO Windows Vista Professional, browser Google Chrome. Implementação Manual Iteração 1ª Interdependências Não aplica. CT03 – Senha incorreta Pré-Condições Acessar a tela de login. Pós-Condições Software exibe mensagem de erro. Detalhamento PA: O usuário insere um Login correto e uma senha incorreta. PA: O usuário aciona a opção Ok. PS: O software valida se os campos foram preenchidos. PS: O software valida se o Login informado esta cadastrado e se a Senha informada é valida. PS: O software exibe a mensagem “Os dados não são
  60. 60. 47 válidos”. Massa de Entrada e Saída Login correto e Senha incorreta. Critérios Especiais Não aplica Ambiente SO Windows Vista Professional, browser Google Chrome. Implementação Manual Iteração 1ª Interdependências Não aplica. CT04 – Login bloqueado Pré-Condições Acessar a tela de login. Pós-Condições Software exibe mensagem de erro. Detalhamento PA: O usuário insere um Login correto e uma senha incorreta por três vezes. Na quarta vez, PS: O software bloqueia o login PS: O software valida se o login está bloqueado PS: O software exibe a mensagem “Login bloqueado”. Massa de Entrada e Saída Login correto e Senha incorreta por quatro tentativas Critérios Especiais Não aplica Ambiente SO Windows Vista Professional, browser Google Chrome. Implementação Manual Iteração 1ª Interdependências Não aplica.
  61. 61. 48 CT05 – Login efetuado corretamente Pré-Condições Acessar a tela de login. Pós-Condições Acessar o software. Detalhamento PA: O usuário informa corretamente o Login e Senha. PA: O usuário aciona a opção Ok. PS: O software valida se os campos foram preenchidos. PS: O software valida se o Login e Senha informados são válidos. PS: O software valida se o Login está bloqueado. PS: O software valida se o Login está inativo. PS: O software autentica o Login. Massa de Entrada e Saída Login correto e Senha correta. Critérios Especiais Não aplica Ambiente SO Windows Vista Professional, browser Google Chrome. Implementação Manual Iteração 1ª Interdependências Não aplica. 3.8 Execução dos Testes Segundo Bastos, A.et. al. (2007) após ser desenvolvido o plano de testes a próxima etapa será a execução dos testes, importante que quanto mais detalhado e fiel ao sistema o plano de testes estiver, mais fácil será o trabalho do testador. Para cada etapa dos testes há um responsável por eles, sendo: Testes Unitários – Programadores Testes de Integração - Analistas de Sistemas
  62. 62. 49 Testes de Sistema – Analistas de Teste Testes de Aceitação – Usuários com a ajuda dos analistas de teste. Quem irá executar os testes e como serão executados deve estar registrado no Plano de Testes.bem como os resultados de cada. (BASTOS, A. et. al., 2007) Abaixo segue figura que exibe como devem ser realizados os testes: Figura 19 - Fluxo dos Testes Fonte: (BASTOS, A. et. al., 2007) 3.8.1 Execução de Testes Unitários Os testes unitários são os primeiros a serem executados, e devem ser executados pelos programadores, os testes são criados durante a etapa de desenvolvimento. O principal objetivo é testar isoladamente cada parte do software para garantir que irão funcionar corretamente. [30]
  63. 63. 50 3.8.2 Execução dos Testes de Integração Para Bastos, A.et. al. (2007) após serem executados todos os testes unitários, os analistas devem executar os testes de integração e garantir que os componentes integrados funcionarão com sucesso. Os itens a serem testados são:  Validação de todos os links entre as diversas camadas;  Controles de Segurança;  Teste de carga e de desempenho / performance dos diversos componentes, considerando-se os bancos de dados e a rede;  Sequência de inclusão, exclusão, consulta e alteração;  Execução completa de uma transação;  Testes para situações especiais, como, por exemplo, um banco de dados vazio ou uma parte da rede fora do ar;  Acurácia dos dados de saída. 3.8.3 Execução dos Testes de Sistema Após todos os testes de integração serem finalizados e realizados com sucesso, começam os testes de sistema. O teste de sistema tem como papel garantir que todos os requisitos do sistema foram atendidos e implantados corretamente. E serão executados pela equipe de testes. (BASTOS, A. et. al., 2007) 3.1.1 Execução dos Testes de Aceitação Serão executados pelos usuários ou gestores do sistema utilizando os próprios requisitos definidos para validar. A equipe de testes pode participar desta validação para auxiliar os usuários. 3.9 Relatórios de Teste A norma IEEE 829-1998 define alguns relatórios para acompanhar o processo de teste dos projetos:  Log de Teste;  Incidentes de Teste;  Sumário de Teste;
  64. 64. 51 Figura 20 - Documentos necessários para o processo de Teste Fonte: (BASTOS, A. et. al., 2007) 3.9.1 Relatório Log de Teste Todas as informações que forem relevantes durante a etapa de testes devem ser registradas neste relatório, é composto pelos seguintes itens:  Identificador: identificador único e específico para o relatório, por exemplo, o nome do sistema com número do release mais data e hora do teste;
  65. 65. 52  Descrição: identificar o que foi testado e o ambiente em que o teste foi executado incluindo hardware, quantidade de memória utilizada, etc;  Atividades e eventos: para cada evento, identificar data/hora, tempo utilizado e responsável;  Descrição da execução: descrever o que foi feito e identificar os responsáveis pela atividade incluindo testadores, observadores e operadores;  Resultados dos procedimentos: para cada execução, descrever os resultados encontrados podendo ser sucesso ou não;  Informações sobre ambiente de teste: informar qualquer condição específica do ambiente de teste, caso seja necessário;  Eventos imprevistos: descrever detalhadamente o que aconteceu antes e depois de uma atividade ou evento inesperado. [31] 3.9.2 Relatório Incidentes de Teste O relatório de incidentes registra todas as informações de diferenças que ocorreram entre o resultado determinado e o realizado durante a realização dos casos de teste. Os itens apontados devem ser detalhados o máximo possível para repassar à equipe de desenvolvimento, é composto pelos itens:  Identificador do relatório: identificador único e específico para o relatório, por exemplo, release testado mais o identificador de um caso de teste;  Sumário da ocorrência: uma breve descrição do incidente; identificar os itens de teste envolvidos indicando sua versão, caso seja necessário; adicionar referência para a especificação do caso de teste, assim o desenvolvedor que for corrigir o defeito terá uma base de documento de teste além do documento de requisitos e adicionar também o relatório de log de teste, se necessário;  Descrição do incidente: prover uma descrição do incidente incluindo os seguintes itens:  Entradas;  Resultados esperados;  Resultados encontrados;  Problemas;  Data e hora do incidente;  Procedimentos para reproduzir o problema;  Ambiente;  Tentativas para repetir o problema;  Testadores;  Observadores. Vale lembrar que outras informações podem ser incluídas sempre que necessário e nem sempre todos os campos acima serão necessários.
  66. 66. 53  Impacto: indicar qual o impacto que o incidente terá no plano de teste de execução podendo falhar, bloquear o(s) testes(s) ou até mesmo uma possível mudança no caso de teste ou requisitos. Se possível, informar a prioridade e severidade do incidente.Os incidentes de teste devem ser armazenados em um repositório e, caso necessário, revisar o relatório de incidentes de teste com as partes interessadas. [31] 3.9.3 Relatório Sumário de Teste O objetivo deste relatório é resumir todas as informações relacionadas aos testes. É composto pelos itens:  Identificador: identificador único e específico para o relatório, por exemplo, release e/ou projeto testado;  Sumário: sumarizar a evolução das atividades de teste identificando os itens testados e o ambiente utilizado para execução dos testes;  Variações: informar qualquer procedimento diferente do que estava especificado no plano de teste e procedimentos de teste; especificar o motivo da utilização do procedimento alternativo;  Avaliações do processo: avaliação resumida do processo adotado contra o especificado no plano de teste; identificar as funcionalidades ou combinações de teste que não foram exercitadas explicando a razão; qualquer ocorrência que possa impactar na qualidade do software/produto deve ser considerada;  Sumário dos resultados: sumarizar os resultados de teste identificando o número de casos de teste executados, número de defeitos encontrados, número de defeitos fechados e abertos, etc;  Avaliação do(s) teste(s): proporcionar uma avaliação global de cada item, incluindo suas limitações. Essa avaliação deve ser baseada nos resultados dos casos de teste e nos critérios de aprovação/reprovação;  Sumário de atividades: resumir os recursos envolvidos no projeto de teste, número total de horas utilizadas no projeto, tempo total utilizado para cada atividade principal, etc;  Aprovações: listar o nome e títulos das pessoas responsáveis pela aprovação do projeto de teste incluindo os relatórios. [31] 3.10 Ferramentas de Teste 3.9.4 Testes em Aplicações Web  Selenium: É um software que permite criar scripts de execução dos testes automatizados. Funciona como uma continuação do Firefox e possibilita salvar, alterar e depurar todos os testes. O download da ferramenta pode ser feito no site http://seleniumhq.org. [32]
  67. 67. 54 Figura 21 - Ferramenta Selenium Fonte: [33]  Watir: Foi desenvolvido para criar testes automatizados para ambiente web. Para realizar os testes o ambiente é realizado diretamente no navegador simulando a utilização do usuário. Pode ser usado nos browsers Internet Explorer, Firefox, Linux e Mac. O download da ferramenta pode ser feito no site http://wtr.rubyforge.org. [34]  BadBoy: É uma ferramenta criada em C++, que armazena todas as atividades realizadas em um browser, permitindo modificar parâmetros, inserir textos, cor e etc. O download da ferramenta pode ser feito no site http://www.badboy.com.au. [35]
  68. 68. 55 Figura 22 - Ferramenta BadBoy Fonte: [35]  Canoo WebTest: É uma ferramenta que possui o código aberto para a criação de testes de automação em ambiente web. O download da ferramenta pode ser feito no site http://WEBtest.canoo.com. [36]
  69. 69. 56 Figura 23 - Ferramenta Canoo WebTest Fonte: [37] 3.9.5 Testes de Desempenho  JMeter: É uma ferramenta da Apache que permite a execução de testes de carga e stress do sistema. O download da ferramenta pode ser feito no site http://jakarta.apache.org/jmeter. [33]
  70. 70. 57 Figura 24 - Ferramenta JMeter Fonte: [38] 3.9.6 Gerenciar Casos de Teste  TestLink: É uma ferramenta que gerencia os casos de teste e execução dos casos O download da ferramenta pode ser feito no site http://www.teamst.org. [33]
  71. 71. 58 Figura 25 - Ferramenta TestLink Fonte: [39] 3.9.7 Gerenciar Defeitos  Bugzilla: É uma ferramenta que se baseia em Web aplicando suporte ao Mozilla, identificando defeitos. O download da ferramenta pode ser feito no site http://www.bugzilla.org. [40]
  72. 72. 59 Figura 26 - Ferramenta Bugzilla Fonte: [40]  Mantis: É uma ferramenta que gerencia defeitos encontrados pela equipe de testes, foi desenvolvida em linguagem PHP e possui o código aberto. O download da ferramenta pode ser feito no site http://www.mantisbt.org. [41]
  73. 73. 60 Figura 27 - Ferramenta Mantis Fonte: [42]
  74. 74. 61 Considerações Gerais Os problemas enfrentados pelas equipes de software são principalmente causados pela falta de conhecimento e organização para gerar produtos com qualidade. Os gastos realizados com softwares “problemáticos” são muito maiores do que se as empresas se preocupassem com o que está sendo feito. A qualidade deve ser encarada como um investimento e uma forma de produzir softwares melhores. Vale salientar que a equipe de Desenvolvimento deve entender que a equipe de Testes irá aprimorar o trabalho realizado. Todos os esforços realizados para se obter um software com qualidade são muito mais rentáveis do que gerar trabalhos, manutenções e perder a confiabilidade dos Clientes.
  75. 75. 62 Referências Meios Impressos  BARTIE, Alexandre. Garantia da Qualidade de Software. Rio de Janeiro: Elsevier, 2002.  BASTOS, Anderson; RIOS, Emerson; CRISTALLI, Ricardo; MOREIRA, Trayahú. Base de conhecimento em teste de software. São Paulo: Martins, 2007.  FIORINI, Soeli T.; STAA, Arnlt Von; BAPTISTA, Renan Martins. Engenharia de Software com CMM. Rio de Janeiro: Brasport, 1998  PRESSMAN, Roger. Engenharia de Software. São Paulo: Makron Books, 2002. Meios Digitais [1].(NOGUEIRA, 2010) Disponível em: http://infoblogs.com.br/frame/goframe.action?contentId=202979 Acessado em 25 de Setembro de 2011 às 20h27min [2].(SILVA, 2010) Disponível em: http://www.artigonal.com/programacao-artigos/a-garantia-da-qualidade-de-software-no- processo-de-desenvolvimento-1836900.html Acessado em: 25 de Setembro de 2011 às 20h28min [3].(TAVARES, 2011) Disponível em: http://qualidadeeteste.blogspot.com/2011/05/qualidade-de-software-parte-i.html Acessado em: 25 de Setembro de 2011 às 21h: 00min
  76. 76. 63 [4].(GOMES N. S., 2010) Disponível em: http://www.fazenda.gov.br/ucp/pnafe/cst/arquivos/Qualidade_de_Soft.pdf Acessado em: 25 de Setembro de 2011 às 21h10min [5].(ENGHOLM, 2010) Disponível em: http://www.livrariacultura.com.br/imagem/capitulo/22123724.pdf Acessado em 25 de Setembro de 2011 às 21h18min [6].(SIMÕES, 2008) Disponível em: http://www.slideshare.net/alsimoes/qualidade-de-software Acessado em 25 de Setembro de 2011 às 21h34min [7].(LOURENÇO, 1997) Disponível em: http://qualidade-de-software.blogspot.com/2010/03/qualidade-de-software-um-compromisso- da.html Acessado em 25 de Setembro de 2011 às 21h48min [8]. (ANDRADE, 2007) Disponível em: http://www.infoescola.com/informatica/bug/ Acessado em 12 de Novembro de 2011 às 16h54min [9].(CAMPOS, 2008) Disponível em: http://www.linhadecodigo.com.br/artigo/1712/Qualidade-Qualidade-de-Software-e-Garantia- da-Qualidade-de-Software-s%C3%A3o-as-mesmas-coisas.aspx Acessado em 29 de Setembro de 2011 às 12h10min
  77. 77. 64 [10]. (WADA, 2007) Disponível em: http://www.cmqv.org/website/artigo.asp?cod=1461&idi=1&moe=212&id=4467 Acessado em 12 de Dezembro de 2011 às 17h07min [11]. (ALCATEL-LUCENT, 2006) Disponível em: http://www.alcatel-lucent.com/wps/portal/BellLabs Acessado em 16 de Novembro 2011 às 13h03min [12]. (KOSCIANKI & SOARES, 2007) Disponível em: http://www.martinsfontespaulista.com.br/anexos/produtos/capitulos/241804.pdf Acessado em 16 de Outubro de 2011 às 13h07min [13]. (TAMASHIRO A. , 2010) Disponível em: http://dftestes.gershon.info/index.php/Cap%C3%ADtulo_1:_Testar_%C3%A9_t%C3%A3o_f% C3%A1cil,_que_at%C3%A9_a_minha_m%C3%A3e_testaria! Acessado em 16 de Outubro de 2011 às 13h21min [14]. (GONÇALVES & BOAS, 2011) Disponível em: http://www.brasilacademico.com/tas/CMM_versao_1_2.pdf Acessado em 12 de Novembro de 2011 às 18h16min [15]. (SOUZA, 2010) Disponível em: http://www.blogcmmi.com.br/gestao/a-historia-do-sei Acessado em 16 de Novembro às 13h11min
  78. 78. 65 [16]. (MARTINS, 2009) Disponível em: http://atitudereflexiva.wordpress.com/2009/07/22/falha-erro-e-defeito/ Acessado em 23 de Outubro de 2011 às 18h23min [17]. (TAMASHIRO, Principais Diferenças entre Erro, Defeito e Falha no Software, 2010) Disponível em: http://qabrasil.blogspot.com/2010/07/principais-diferencas-entre-erro.html Acessado em 23 de Outubro de 2011 às 17h37min [18]. (GALEOTE, 2010) Disponível em: http://blog.prasabermais.com/2010/05/18/qual-a-origem-dos-bugs-de-software/ Acessado em 23 de Outubro de 2011 às 19h21min [19]. (GOMES E. , 2010) Disponível em: http://basedetestedesoftware.blogspot.com/2010/05/o-custo-da-qualidade-de- software.html Acessado em 23 de Outubro de 2011 às 22h32min [20]. (INTELLECTUS, 2011) Disponível em: http://www.intellectusitservices.com.br/index.php/component/content/article/57- frontpage/177-ipad-mania-in-the-uk-as-thousands-await-the-launch- Acessado em 30 de Outubro de 2011 às 11h25min [21]. (MSW, 2000) Disponível em: http://www.mswconsult.com.br/quali_4.html Acessado em 30 de Outubro de 2011 às 11h17min
  79. 79. 66 [22]. (NOGUEIRA, Casos de Teste, 2007) Disponível em: http://www.testexpert.com.br/?q=node/90 Acessado em 30 de Outubro de 2011 às 11h23min [23]. (DAVIDSON, 2011) Disponível em: http://rederia.net/2011/07/23/a-ascensao-do-teste-de-software/ Acessado em 30 de Outubro de 2011 às 12h33min [24]. (TESTEXPERT apud ComputerWorld, 2007) Disponível em: http://www.testexpert.com.br/?q=node/422 Acessado em 30 de Outubro de 2011 às 17h51min [25]. (LOPES & CARNEIRO) Disponível em: http://www.univicosa.com.br/arquivos_internos/artigos/ImportanciadoProcessodeTest edeSoftwareemTI.pdf Acessado em 30 de Outubro de 2011 às 18h31min [26]. (ALMEIDA, 2010) Disponível em: http://www.linhadecodigo.com.br/Artigo.aspx?id=2775 Acessado em 05 de Novembro de 2011 às 14h30min [27]. (TOZELLI, 2008) Disponível em: http://qualidade-de-software.blogspot.com/2010/01/teste-de-caixa-branca.html Acessado em 05 de Novembro de 2011 às 14h10min
  80. 80. 67 [28]. (LOURENÇO, Fases de Testes, 2010) Disponível em: http://www.artigonal.com/programacao-artigos/processo-de-teste-de-software- 505672.html Acessado em 05 de Novembro de 2011 às 15h36min [29]. (AGAPITO, 2007) Disponível em: http://www.testexpert.com.br/?q=node/366 Acessado em 05 de Novembro de 2011 às 17h02min [30]. (SILVA F. R.) Disponível em: http://www.devmedia.com.br/post-22284-Testes-de-software-Teste-Unitario.html Acessado em 06 de Novembro de 2011 às 13h15min [31]. (QUEZADA, 2009) Disponível em: http://gustavoquezada.blogspot.com/2009/08/para-continuar-com-o-assunto-relatorio.html Acessado em 06 de Novembro de 2011 às 15h09min [32]. (CAMPOS R. , 2011) Disponível em: http://www.profissionaisti.com.br/2011/03/testes-automatizados-utilizando-selenium-ide/ Acessado em 06 de Novembro de 2011 às 15h23min [33]. (COSTA, 2008) Disponível em: http://www.testexpert.com.br/?q=node/591 Acessado em 06 de Novembro de 2011 às 15h25min [34]. (SOARES, 2007) Disponível em:
  81. 81. 68 http://www.testexpert.com.br/?q=node/383 Acessado em 06 de Novembro de 2011 às 15h38min [35]. (HEINEBERG, 2008) Disponível em: http://www.testexpert.com.br/?q=node/383 Acessado em 06 de Novembro de 2011 às 15h49min [36]. (PAIVA, 2011) Disponível em: http://teste-software.blogspot.com/2011/06/abaixo-listaremos-algumas-ferrametnas.html Acessado em 06 de Novembro de 2011 às 15h59min [37]. (FREITAS, 2008) Disponível em: http://wilsondev.blogspot.com/2008/07/automao-de-testes-com-canoo-webtest.html Acessado em 06 de Novembro de 2011 às 16h00min [38]. (JAVA, 2011) Disponível em: http://blog.marcoreis.net/2011/08/05/tutorial-rapido-como-rodar-teste-de-carga-com-jmeter/ Acessado em 06 de Novembro de 2011 às 16h10min [39]. (RIBEIRO, 2010) Disponível em: http://blog.marcoreis.net/2011/08/05/tutorial-rapido-como-rodar-teste-de-carga-com-jmeter/ Acessado em 06 de Novembro de 2011 às 16h10min [40]. (MOZILLA EUROPE) Disponível em: http://www.mozilla-europe.org/pt/products/bugzilla/ Acessado em 06 de Novembro de 2011 às 16h24min [41]. (FERNANDO, 2008)
  82. 82. 69 Disponível em: http://www.testexpert.com.br/?q=node/677 Acessado em 06 de Novembro de 2011 às 16h29min [42]. (CAETANO) Disponível em: http://www.devmedia.com.br/articles/viewcomp.asp?comp=8036 Acessado em 06 de Novembro de 2011 às 16h31min
  83. 83. 70 TERMO DE COMPROMISSO E RESPONSABILIDADE Guarulhos, 16 de Novembro de 2011 Pelo presente, eu abaixo assinado declara, sob as penas da lei, que o presente trabalho é inédito e original, desenvolvido especialmente para os fins educacionais a que se destina e que, sob nenhuma hipótese, fere o direito de autoria de outrem. Para maior clareza, firmo o presente termo de originalidade. Débony Schmidt Autenticidade e exclusividade sob as penas da Lei 9610/98

×