Uninter - Qualidade de Software - Gestao em TI

QUALIDADE DE SOFTWARE
AULA 1
Prof.a Maristela Regina Weinfurter Teixeira
1
CONVERSA INICIAL
Olá, seja bem-vindo. Assista ao primeiro vídeo da professora Maristela

Regina Weinfurter Teixeira, que irá apresentar e contextualizar esta disciplina,
bem como os assuntos que serão estudados nesta primeira aula.
CONTEXTUALIZANDO
Vamos trabalhar um conceito importantíssimo dentro da Engenharia de

Software: A Qualidade de Software. É inevitável não associarmos engenharia
de software e qualidade de software, pois quando retomamos o histórico da
engenharia de software percebemos que está se originou devido à terrível crise
do software. E o que teria sido então esta crise? Justamente problemas que
deixaram desenvolvedores noites e noites sem dormir para refazerem milhares
de linhas de código. Segundo Pressman, na década de 90, grandes empresas
falavam em bilhões de dólares por ano que eram desperdiçados em software
que não apresentava as características e as funcionalidades prometidas.
(PRESSMAN, 2011).
São décadas que falamos em engenharia e qualidade de software, porém

continuamos com códigos mal feitos nesse mercado. Estamos falando de 45%
de tempo de inatividade dos sistemas e 100 bilhões de dólares em 2010.
(PRESSMAN, 2011). Alguns especialistas apontam que 3 ou 4 defeitos a cada
1.000 linhas de código são suficientes para que o programa execute de forma
inadequada. Agora, multiplique isto a milhões de linhas de código em vários
produtos comerciais pelo mundo. Sim, é assustador! E como isto reflete nos
custos? Precisamos consertar aquilo que não foi feito corretamente, bem como
aquilo que não passou por bons TESTES! Logo, estamos falando de
RETRABALHO! E as pessoas trabalham e necessitam receber sua
remuneração, logo, quando falamos em códigos mal escritos e ineficientemente
testados, estamos falando que alguém terá que pagar esta conta!
2
Muito bem, falamos dos custos para escrevermos e mantermos
funcionalidades de software, porém, os custos, gastos e investimentos vão além
dos funcionários da área de TI. Quando um software está inativo, são clientes e
mais clientes que são prejudicados, por meio de notas fiscais que não são
emitidas, empresas que deixam de faturar, bancos que deixam de fazer
operações com milhões de correntistas, pedidos que não são recebidos, entre
tantas outras funcionalidades automatizadas que deixam de executar!
Mas não paramos apenas nos problemas de funcionalidades por conta de

erros nos códigos dos programas. São requisitos mal elaborados e validados
com clientes, são aspectos da interação humano-computador que geram
problemas (usabilidade e acessibilidade), são bancos de dados e classes mal
projetados! Se começássemos uma lista de todos os problemas que levam um
software a parar, falhar ou funcionar parcialmente, teríamos algumas páginas
para escrever sobre a ausência da qualidade do software.
Enfim, não obstante, podemos ainda falar sobre os problemas inerentes

ao processo de desenvolvimento de software. Quando pensamos na qualidade
de um produto genérico, logo somos remetidos ao processo pelo qual este
passou para ser fabricado. Software, apesar de não ser um produto, também
caminha dentro de um ciclo de desenvolvimento. Se este ciclo não possuir
processos, atividades e tarefas consolidadas e em conformidade com normas,
metodologias, regras e outras formas de garantia da qualidade, a possibilidade
de nosso produto não atingir a qualidade desejada pelos clientes é grande.
Então, estamos falando da qualidade do software e também do seu processo de

desenvolvimento! Qualidade aplicada a processos e produtos!
Leitura obrigatória
Uma Introdução à Qualidade de Software:
https://www.infoq.com/br/news/2012/05/An-Introduction-Software-Quality
3
Saiba mais
O mercado de software brasileiro conta com o Simpósio Brasileiro de

Qualidade de Software. É um evento anual da Comissão Especial de
Engenharia de Software da Sociedade Brasileira de Computação (SBC) e do
Comitê do Programa Brasileiro da Qualidade e Produtividade em Software
(PBQP-SW), tem como objetivo reunir empresários, profissionais, professores,
pesquisadores e estudantes de diversas áreas, interessados em questões
relativas à qualidade de software, em um evento de divulgação e troca de
experiências, promovendo a integração Universidade – Empresa.
O simpósio está em sua 16.ª edição. Informações, artigos e dissertações

de mestrado sobre a 15.ª edição podem ser encontrados em:
http://sbqs2015.com.br/apresentacao/
Pesquise
Utilize o link abaixo e identifique os temas que mais foram discutidos em

2015. Você verificará várias linhas de atuação da qualidade de software
aplicadas em situações de testes, de requisitos, de melhorias de processos.
Tente encontrar temas que lhe despertem mais interesse, pois a área de
qualidade de software é bastante extensa.
http://sbqs2015.com.br
http://sbqs2015.com.br/apresentacao
 Temas como automatização de testes são discutidos?

 O que fazer para aplicarmos testes a todo o processo de desenvolvimento
de software?
 Quais são as tendências na área de qualidade e testes de software?
4
TEMA 1 - CONCEITOS SOBRE QUALIDADE
Como definirmos o que é qualidade, como saber o que ela representa ou

compreendermos quando ela não existe?
Definir qualidade é algo complexo à primeira vista, porém, com um

exemplo mais prático ficará um pouco mais tangível para você. Vamos
ao exemplo:
Imagine-se em um restaurante, para o qual, em especial hoje, você pagou

mais caro que o seu hábito. Se alguém lhe perguntar se a comida tinha
qualidade, você certamente saberá responder com rapidez, sim, não ou se faltou
algo para que ficasse melhor ainda. Em todos os momentos estamos falando
sobre qualidade de algo, seja do transporte público, demora no atendimento em
alguma loja ou banco. Estamos envoltos com este conceito a todo momento em
nossas vidas, porém, se eu lhe pedir para definir qualidade, você pensará um
pouco para tentar colocar em palavras aquilo que lhe é familiar e ao mesmo
tempo tão subjetivo!
Subjetivo? Sim, porém se você estiver neste mesmo restaurante que lhe
propus anteriormente com outra pessoa, esta poderá ter outra visão sobre a
qualidade da mesma comida! Isso não quer dizer que ela invalidará a sua
avaliação sobre a refeição. Isso nos mostra que precisamos analisar melhor o
que esperamos da qualidade, seja de produtos ou de serviços.
Qualidade, segundo o INMETRO, “é uma variável precisa e mensurável,

oriunda do grau de conformidade do planejado com o executado. Esta
abordagem dá ênfase a ferramentas estatísticas.”. (INMETRO, 2015).
Já para Shigunov Neto (2016), qualidade
é uma filosofia de gestão empresarial ou um modelo de gestão

administrativa que visa atingir permanentemente a melhoria de
produtos ou serviços oferecidos, por meio da mudança dos processos
5
produtivos, da redução de custos, de uma transformação cultural e do
envolvimento e do comprometimento dos trabalhadores.
Alguns nomes são importantes para a área de qualidade, e cada qual tem
um enfoque (SHIGUNOV, 2016). Dentre eles temos:
1. Deming (1950) – Máxima utilidade para o consumidor;

2. Feigenbaum (1951) – Perfeita satisfação do usuário;
3. Juran (1954-1964) – Satisfação das aspirações do usuário. Maximização
das aspirações do usuário e adequação ao uso;
4. Crosby (1979) – Conformidade com os requisitos do cliente.
Quando olhamos pela ótica da Engenharia de Software, podemos dizer

que as palavras-chave para qualidade, em se tratando de software, segue o que
ilustra a Figura 1.
Figura 1: Qualidade de Software
entrega
satisfação do produto boa entrega
dentro do
usuário compatível qualidade dentro prazo
orçamento
Fonte: Pressman, 2011.
A qualidade de software pode ser definida, segundo Pressman, como

“uma gestão de qualidade efetiva aplicada de modo a criar um produto útil que
forneça valor mensurável para aqueles que o produzem e para aqueles que o
utilizam.” Para que isso ocorra, precisamos garantir uma boa gestão de
qualidade, um produto útil e valor agregado tanto para o desenvolvedor quanto
para os stakeholders de um produto de software. Assim como para fabricação
6
de qualquer produto ou prestação de serviços, precisamos ter foco na qualidade
tanto de processos quanto de produtos (resultados).
http://www.inmetro.gov.br/qualidade/iaac/pdf/fundamentos-qualidade.pdf
Saiba mais
Qualidade, qualidade de software e garantia da qualidade de software são as

mesmas coisas?
Quais suas diferenças e complementaridades.
http://www.linhadecodigo.com.br/artigo/1712/qualidade-qualidade-de-software-
e-garantia-da-qualidade-de-software-sao-as-mesmas-coisas.aspx
TEMA 2: DIMENSÕES DA QUALIDADE DE SOFTWARE
Sabemos então que qualidade se aplica tanto a produtos/serviços quanto

aos processos e, em complemento a tudo isto, podemos ainda visualizar a
qualidade sob algumas dimensões (PRESSMAN, 2011):
1. Qualidade do desempenho: funcionalidades e recursos especificados

devem estar de acordo com o produto/serviço entregue;
2. Qualidade dos recursos: o software deve fornecer recursos que
surpreendam e encantem os stakeholders;
3. Confiabilidade: o software deve funcionar sem falhas, erros e disponível
a qualquer momento;
4. Conformidade: o software deve estar de acordo com padrões locais e
externos;
7
5. Durabilidade: o software pode ser mantido ou corrigido sem a geração de
efeitos colaterais;
6. Facilidade de manutenção: o software pode ser mantido ou corrigido por
período de tempo aceitável;
7. Estética: elegância com um fluir único e uma presença difíceis de
quantificar;
8. Percepção: pode ser maculada por produtos anteriores entregues sem
qualidade ou pode ser superestimada por produtos anteriores entregues
com sucesso.
Já segundo o INMETRO (2015), estas dimensões ou categorias da

qualidade podem ser catalogadas da seguinte forma:
1. Desempenho
2. Características
3. Confiabilidade
4. Durabilidade
5. Atendimento
6. Estética
7. Qualidade percebida
8. Conformidade
Podemos observar que mesmo autores diferentes possuem compreensão

muito similar quanto aos quesitos que compõem as dimensões da qualidade de
um produto/serviço.
http://www.inmetro.gov.br/qualidade/iaac/pdf/fundamentos-qualidade.pdf
Saiba mais
O que é o INMETRO?
8
O INMETRO é um instituto nacional de metrologia, qualidade e tecnologia. À
primeira vista, muitos imaginam que ele atende à indústria, porém com a
necessidade cada vez maior por questões relacionadas à qualidade de software,
o mesmo vem atendendo também a esta área que cresce a cada dia no país.
http://www.inmetro.gov.br/inmetro/oque.asp
Caminhamos mais um pouco no conhecimento da qualidade de software

e de processo de software. Pudemos observar alguns pontos importantes para
compreendermos melhor o trabalho que teremos pela frente para garantirmos
todo o processo e atingirmos os melhores resultados na construção de software.
TEMA 3: FATORES DE QUALIDADE
Até o momento falamos sobre conceitos e definições importantes para a

compreensão da qualidade e qualidade de software. Visualizamos que qualidade
não é um conceito novo, mas quando falamos de desenvolvimento de software
ainda temo um caminho longo a trilhar para atingirmos os melhores resultados,
visto que partimos sempre do subjetivo para o objetivo. Partimos de ideias e as
transformamos em códigos que resultam em produtos capazes de agilizar
atividades tanto operacionais quanto estratégicas de nossos stakeholders.
Agora vamos compreender um pouco sobre os fatores de qualidade

atrelados ao software. Observando que teremos três importantes aspectos em
um produto de software (PRESSMAN, 2011):
1. Características operacionais;
2. Habilidade de suportar mudanças;
3. Adaptabilidade a novos ambientes.
9
A figura 2 relaciona estes três aspectos subdivididos em outras
abordagens importantes para considerarmos a qualidade de software.
Figura 2: Fatores de qualidade de software
• Facilidade de manutenção
• Flexibilidade
Revisão do
Produto
• Testabilidade
• Portabilidade
• Reusabilidade
Transição do
Produto
• Interoperabilidade
•Correção
•Confiabilidade
•Usabilidade
Operação do •Integridade
Produto •Eficiência
Começando pelo grupo Revisão do Produto dos fatores de qualidade de

software, teremos as seguintes definições dos subgrupos (PRESSMAN, 2011):
1. Facilidade de manutenção: é o esforço necessário para localização e

correção de um erro dentro de um programa.
2. Flexibilidade: é o esforço necessário para modificação de um programa
que já esteja em operação.
3. Testabilidade: é o esforço necessário para o teste de um programa para
garantia de seu desempenho e função destinada.
10
O próximo grupo, Transição do Produto, possui as seguintes
competências:
1. Portabilidade: é o esforço necessário para transferência de um programa

em um ambiente de hardware/software para outro.
2. Reusabilidade: é o quanto o programa pode ser reutilizado em outras
aplicações, ou partes deste.
3. Interoperabilidade: é o esforço necessário para integração de um
sistema ao outro.
E finalmente, o último grupo, Operação do Produto, possui as seguintes

atribuições:
1. Correção: é o quanto o programa satisfaz a sua especificação e atende

objetivos dos stakeholders.
2. Confiabilidade: é o quanto se pode esperar que um programa realize a
função pretendida com a precisão exigida.
3. Usabilidade: é o esforço necessário para aprender, operar, preparar a
entrada de dados e interpretar a saída de um programa.
4. Integridade: é o quanto o acesso ao software ou dados por pessoas não
autorizadas pode ser controlado.
5. Eficiência: é a quantidade de recursos computacionais e código exigidos
por um programa para desempenhar sua função.
Temos também a versão dos fatores de qualidade segundo a ISO 9126,

que é um padrão desenvolvido para identificação dos atributos fundamentais de
qualidade para software de computador. Segundo esta versão de fatores,
possuímos seis aspectos diferentes (PRESSMAN, 2011):
11
1. Funcionalidade: que corresponde ao grau de satisfação das
necessidades elicitadas.
2. Confiabilidade: é a quantidade de tempo que o software fica disponível

para uso, bem como sua maturidade, tolerância a falhas e facilidade de
recuperação.
3. Usabilidade: diz respeito ao grau de facilidade de utilização do software

(compreensão, aprendizagem e operabilidade).
4. Eficiência: é o grau de otimização do uso dos recursos do sistema

(comportamento em relação a tempo e recursos).
5. Facilidade de manutenção: corresponde à facilidade de correção do

software (facilidade de análise, mudanças, estabilidade e testabilidade).
6. Portabilidade: quão ágil é passar o software de um ambiente

(plataforma) para outro (adaptabilidade, facilidade de instalação, conformidade
e facilidade de substituição).
De acordo com esta visão sobre os fatores de qualidade, é fácil concluir

que teremos um longo caminho a percorrer para construirmos um software com
qualidade, bem como propor um processo capaz de agregar tais requisitos de
qualidade em seu ciclo de vida.
12
TEMA 4: DILEMAS DA QUALIDADE
Estudamos anteriormente o que seriam os princípios básicos da

Qualidade de Software. Agora precisamos mergulhar em um mundo de dilemas
em relação à qualidade do processo de desenvolvimento e do software.
Considere a seguinte entrevista à Bertrand Meyer (VENNERS, 2003 apud
PRESSMAN, 2011):
Se produzirmos um sistema de software de péssima qualidade,

perdemos porque ninguém irá querer comprá-lo. Se, por outro lado,
gastamos um tempo infinito, um esforço extremamente grande e
grandes somas de dinheiro para construir um software absolutamente
perfeito, então isso levará muito tempo para ser completado, e o custo
de produção será tão alto que iremos à falência. Ou perdemos a
oportunidade de mercado ou então simplesmente esgotamos todos os
nossos recursos. Dessa maneira, os profissionais desta área tentam
encontrar aquele meio-termo mágico onde o produto é suficientemente
bom para não ser rejeitado logo de cara, como, por exemplo, durante
uma avaliação, mas também não é o objeto de tamanho
perfeccionismo e trabalho que levaria muito tempo ou que custaria
demasiadamente para será finalizado.
A grande questão encontra-se em um esforço racional e objetivo para

atingirmos a melhor qualidade possível, porém dentro de prazos e custos
tangíveis. Então surge a questão: O que é um software bom o suficiente?
Ele deverá fornecer funções e características de alta qualidade que os

usuários desejam, porém dentro de um tempo e custo dentro do estabelecido
para o projeto do software. (PRESSMAN, 2011).
Agora precisamos olhar para os custos. Qualidade é importante, mas

sempre terá um custo (tempo e dinheiro).
13
Figura 3: Custos da Qualidade
Prevenção
Avaliação
Falhas
Custos de Qualidade
Quando falamos em custos da qualidade precisamos incluir todos os

custos necessários para a busca de qualidade e para a execução de atividades
relacionadas à qualidade ou pela falta de qualidade. Isso é possível quando
reunimos métricas para promoção de uma base de custo corrente da qualidade,
identificando-se oportunidades para redução. Este é dividido em custos de
prevenção, avaliação e falhas (Figura 3).
Os Custos de Prevenção contêm os seguintes itens:
1. Custos de atividades de gerenciamento (planejamento, coordenação,

controle e garantia de qualidade).
2. Custos de atividades técnicas adicionais (requisitos e projeto).
3. Custos de planejamento de testes.
4. Custos de treinamento para todas as atividades anteriores.
Já os Custos de Avaliação incluem custos:
1. Para a execução de revisões técnicas.
14
2. Que abordem a coleta de dados, bem como a avaliação por meio
de métricas.
3. Para testes e depuração dos programas (PRESSMAN, 2011).
Finalmente, os Custos de Falhas comportam:
1. A percepção da necessidade de retrabalhos e correção de erros.

2. Valores relacionados ao efeito colateral no caso dos retrabalhos.
3. Tudo que esteja associado às reuniões para aplicação das métricas de
qualidade. (PRESSMAN, 2011).
Figura 4: Custos da Qualidade de Software X Ciclo de Vida dos Sistemas
Segundo Pressman (2011): “O custo médio da indústria de software para

correção de um defeito durante a geração de código é de aproximadamente 977
dólares por erro. Para correção do mesmo erro na fase de testes é de 7136 por
erro”. Ou seja, à medida que avançamos no projeto, encontrar e corrigir um erro
torna-se cada vez mais caro. A Figura 4 nos demonstra graficamente, em
milhares de dólares, o quanto encontrar erros e falhas em um projeto de software
torna-se drasticamente mais caro à medida que evoluímos nas etapas do projeto.
15
Além de todos estes custos, ainda entramos nos quesitos riscos,
responsabilidade civil, segurança e o impacto das ações administrativas sobre o
processo de desenvolvimento de software, considerando-se aspectos de
qualidade. Quanto aos riscos, encontramos pessoas que entregam seus
empregos, segurança, entretenimento, decisões e a vida em software. Com isso,
precisamos avaliar os riscos envolvidos quando um software possui falhas e
erros. Isso deve ser muito bem pensado ao se desenvolver um software que
envolva altos riscos.
Outro aspecto fica por conta de sistemas que se tornam lentos, com
recursos e funções suscetíveis a erros sem a aprovação dos usuários, tornando
o pagamento pelo software algo que entra na esfera judicial. Usuários dizem que
os desenvolvedores foram negligentes, ocasionando um problema sério de fluxo
de caixa para a empresa desenvolvedora.
A segurança é um requisito extremamente importante atualmente, visto a

quantidade de sistemas via Web e aparelhos móveis. A segurança implica
diretamente em questões de falhas arquiteturais. E, finalmente, quanto às
questões administrativas, encontramos problemas relacionados a estimativas,
cronogramas e riscos que acabam por interferir em todo o processo de
desenvolvimento e qualidade do processo.
Terminamos com o seguinte pensamento de Meskimen

(PRESSMAN, 2011): “Nunca há tempo para fazer a coisa certa, mas sempre há
tempo para fazê-la de novo. Meu conselho: tomar o tempo necessário para fazer
certo da primeira vez quase nunca é uma decisão errada.”
16
TEMA 5: ALCANÇANDO A QUALIDADE DE SOFTWARE
Chegamos até aqui com muitas definições, conceitos e filosofando sobre

o que é e o que não é qualidade. Como pensarmos em todas as questões
relacionadas à qualidade do processo e do software. Realmente, a qualidade de
software é uma área extensa e que merece um esforço reflexivo bastante
grande, porque depois que estivermos inseridos em um projeto e este estiver no
ar, não há mais tempo para refletirmos. A reflexão fica por conta primeiramente
de nossa visão bastante clara sobre os problemas futuros que podemos ter e
que, por meio de algumas iniciativas relacionadas à qualidade, poderemos evitar
em nossos projetos e em nossa vida profissional.
Vamos então listar algumas ações de controle de qualidade e garantia da

qualidade que poderão salvar nossos projetos e nossas noites e finais de
semana de trabalho ou retrabalho (PRESSMAN, 2011):
1. Métodos de engenharia de software: primeiro passo, compreender com

clareza qual é o problema a ser resolvido. Sermos capazes de criar um
projeto adequado ao problema.
2. Técnicas de gerenciamento de software: Estimativas de datas plausíveis,
cronogramas sem atalhos e planejamento de riscos orientado a
problemas e não ao caos.
3. Controle de qualidade: Conjunto de ações de engenharia de software para
auxiliar na garantia de que cada produto atinja suas metas de qualidade.
Modelos revistos e códigos inspecionados, corrigidos antes dos testes.
Testes para descoberta de erros na lógica, na manipulação dos dados e
na comunicação da interface. Feedbacks com a equipe de software.
4. Garantia da qualidade: infraestrutura com métodos sólidos de engenharia
de software, gerenciamento racional de projeto e ações de controle
de qualidade
17
Conforme os anos passam na história da engenharia de software, nossos
critérios de qualidade de software crescem, tornando-os cada vez mais efetivos.
Utilizarmos, por exemplo, a ISO 9126 estabelecerá características de
confiabilidade, usabilidade, facilidade de manutenção, funcionalidade e
possibilidade como indicadores da existência da qualidade de software.
(PRESSMAN, 2011).
E não temos como fugir, a qualidade de software só existe quando

olharmos para os métodos da engenharia de software, práticas administrativas
consistentes e controle de qualidade completo. Não podemos esquecer que os
custos e desastres em relação à falta de qualidade, tanto do processo quanto do
software, serão substanciais e muitas vezes insolúveis.
TROCANDO IDEIAS
Que tal analisarmos, diante de nossa pouca ou muita experiência e de

exemplos de outros, qual a real importância da qualidade de software e quão
extensa esta área pode ser dentro da área de desenvolvimento de software?
SÍNTESE
Quando falamos de qualidade de sistemas ou processos de

desenvolvimento, não estamos querendo discutir metodologias, técnicas e
ferramentas para colocarmos em nosso currículo. A qualidade vai além da sala
de aula. Ela é um elemento fundamental para o sucesso ou a sua ausência para
o fracasso de um software. Vimos que quando pensamos em qualidade não
18
estamos falando apenas em tirarmos os erros de código, não que isto não seja
importante, mas estamos vislumbrando o software como um conjunto não só de
códigos que seguem uma determinada lógica, mas um software que manipule
dados e se comunica com pessoas. Usuários estão cada vez mais exigentes e
querem respostas rápidas, eficientes, confiáveis, por meio de interfaces simples.
Nosso desafio então é aplicarmos a qualidade de software, observando-se
obviamente o escopo de nosso projeto diante de seus custos. Não temos como
fazer milagres, mas podemos nos cercar de pontos importantes a serem
analisados diante de todo o processo de software, vislumbrando um software e
um processo de desenvolvimento de software que busque sua excelência
em qualidade.
REFERÊNCIAS
INMETRO. Fundamentos da Qualidade. Disponível em:

<http://www.inmetro.gov.br/qualidade/iaac/pdf/fundamentos-qualidade.pdf>.
Acesso em: maio de 2016.
LÉLIS, E. C. Gestão da qualidade. São Paulo: Pearson Prentice Hall, 2012.
PRESSMAN, R. S. Engenharia de software: uma abordagem profissional. 7.

ed. Porto Alegre: AMGH, 2011.
SOMMERVILLE, I. Engenharia de software. 9. ed. São Paulo: Pearson

Prentice Hall, 2011.
SHIGUNOV NETO, A. Introdução à gestão da qualidade e produtividade:

conceitos, história e ferramentas. Curitiba: InterSaberes, 2016.
VENNERS, B. Design by contract: a conversation with Bertrand Meyer. Artima

Developer, December 8, 2003. Disponível em:
<www.artima.com/intv/contracts.html>.
19
XIV Simpósio Brasileiro de Qualidade de Software. Anais. 17-21 de agosto de
2015. Manaus. Disponível em:
<https://drive.google.com/file/d/0B4ZBCAydIkutSUFuVVhCdXVnbDA/view>.
20
AULA 2
1
CONVERSA INICIAL
Olá, seja bem-vindo. Assista ao segundo vídeo da professora Maristela
bem como os assuntos que serão estudados nesta aula.
CONTEXTUALIZANDO
Após conhecermos um pouco sobre a qualidade de software, vamos
estudar sua amplitude por meio de conceitos da garantia da qualidade
de software. A garantia da qualidade de software (SQA), segundo
Pressman (2011), contém as seguintes etapas:
1. Um processo de SQA.
2. Tarefas específicas e controle da qualidade (revisões técnicas e
estratégia de testes multiescalonados).
3. Prática efetiva de engenharia de software (métodos e ferramentas).
4. Controle de todos os artefatos de software e as mudanças feitas nesses
produtos.
5. Um procedimento para garantir a conformidade com os padrões de
desenvolvimento de software.
6. Mecanismos de medição e de relatórios.
A garantia da qualidade pode-se dizer que é um conjunto de atividades

essenciais para qualquer empresa de produtos a serem usados por terceiros,
isso falando em termos gerais. Agora, focando na área de desenvolvimento de
software, até os anos 60 a qualidade no desenvolvimento de software era de
responsabilidade exclusiva de cada programador. Nos anos 70, as coisas
começam a mudar e surge então a preocupação na criação de padrões para
garantia da qualidade no desenvolvimento de software, em especial pela
indústria militar dos Estados Unidos, o que rapidamente foi absorvido por todo o
mercado de software. (PRESSMAN, 2011). E tal preocupação cresceu à medida
que o software passou a ser integrado em cada aspecto da vida cotidiana.
2
Desenvolver softwares nos dias atuais deixou de ser algo para
programadores independentes e solitários e se tornou um trabalho que
experimenta a colaboração e cooperação entre profissionais com
especializações dentro da engenharia de software e de outras áreas. Assim,
vamos verificar, claro que cuidando das devidas proporções de tamanhos de
projetos e empresas desenvolvedoras, profissionais especializados no projeto,
na codificação, em testes e outras tantas atividades que agregam os cuidados
que a garantia da qualidade de software nos oferece.
SOMMERVILLE, 2011
Saiba mais
Este curta metragem é pequeno, mas ao mesmo tempo nos traz uma boa
percepção do que é desenvolvermos um software apenas por meio da tentativa
e erro em vez de irmos direto às muitas orientações sobre como podemos ter
mais produtividade, melhoria de processos e um produto/serviço que de fato
atenda a nossos usuários.
https://www.youtube.com/watch?v=LOyX-vgdQGQ
Consulte também livros da biblioteca virtual ou sites da internet que falem

sobre garantia da qualidade.
Antes de entrarmos de fato na garantia da qualidade de software,

pesquise sobre o assunto, focado para produtos e serviços em geral. Você é
consumidor de algum tipo de produto ou serviço e então liste o que é bom ou
ruim em algum produto/serviço para que logo após reflita sobre:
1. O que poderia melhorar neste produto?
2. Como isto poderia ser feito?
3. Como será o processo de fabricação/serviço até que eu receba meu
produto/serviço?
3
Quando fazemos este exercício com algo que nos afeta diretamente, fica
mais fácil compreendermos e absorvermos todas as preocupações da garantia
da qualidade de software.
TEMA 1: ELEMENTOS DA GARANTIA DA QUALIDADE DE SOFTWARE
Para prosseguirmos na nossa trajetória sobre garantia da qualidade,

vamos compreender a ideia da estrutura de gerenciamento de software segundo
(HUMPHREY,1989 apud SOMMERVILLE, 2011):
1. Introdução ao produto. Uma descrição do produto, seu

mercado pretendido e as expectativas de qualidade do produto.
2. Planos de produto. As datas críticas de release e
responsabilidades para o produto, junto com os planos para a
distribuição e prestação de serviço do produto.
3. Descrições de processo. Os processos de desenvolvimento e
serviço são padrões que devem ser usados para o gerenciamento e
desenvolvimento de produto.
4. Metas de qualidade. As metas de qualidade e planos para o
produto, incluindo uma identificação e uma justificativa para os
atributos críticos de qualidade do produto.
5. Riscos e gerenciamento de riscos. Os riscos mais importantes
que podem afetar a qualidade do produto e as ações que devem ser
tomadas ao lidar com eles.
Seguindo estas ideias, podemos dividir a garantia da qualidade

de software em três categorias (CAMPOS, 2016), que podem ser visualizadas
na Figura 1:
4
Figura 1: Elementos da Garantia da Qualidade de Software
Teste de
Software
Gerenciamento
de Controle de
Configuração Qualidade
de Software
Fonte: adaptado de Campos, 2016.
1. Teste de Software: Inclui atividades de verificação e validação. É

importante que o software seja testado para verificação desde o início da
elicitação dos requisitos funcionais e não funcionais até o momento de
entrega do software.
2. Controle da Qualidade: nesta fase se monitora o trabalho, observando
se os requisitos estão sendo satisfeitos. Revisar e remover defeitos antes
que o software seja entregue. Cheklists bem definidos e especificados no
plano de garantia da qualidade. Dentro das revisões, inspeção é
considerado como um sinal de grande grau de maturidade do processo
de controle de qualidade.
3. Gerenciamento de Configuração de Software: fase em que
se identifica, rastreia e controla mudanças nos elementos do software de
um sistema. Ele ainda controla a evolução do sistema de
software, gerenciando versões dos componentes de software e
seus relacionamentos.
Caminhando mais um pouco, podemos ampliar nossas preocupações e

atividades que se concentram na gestão e garantia da qualidade
(PRESSMAN, 2011):
5
1. Padrões: IEEE, ISO e outras organizações de padronizações.
2. Auditorias e Revisões: revisões técnicas são atividade de controle de
qualidade para revelação de erros. Auditoria é um tipo de revisão para
nos assegurar de que as diretrizes de qualidade estejam sendo seguidas.
3. Testes: fazem parte do controle de qualidade com o objetivo principal a
descoberta de erros.
4. Coleta e análise de erros/defeitos: melhoria do desempenho das
melhores práticas para garantia da qualidade por meio de medições.
5. Gerenciamento de mudanças: são aspectos negativos dentro do
desenvolvimento de software, porém ocorrem a todo instante.
6. Educação: aperfeiçoamento dos desenvolvedores e interessados.
7. Gerência de fornecedores: pacotes comerciais, software sob
encomenda devem ser avaliados por meio da garantia de qualidade de
software antes da aquisição.
8. Administração da segurança: crimes cibernéticos e novas
regulamentações governamentais quanto à privacidade devem fazer
parte das políticas de proteção de dados em todos os níveis.
9. Proteção: o software envolve vidas humanas e o impacto de defeitos e
falhas pode ser catastrófico.
10. Administração de riscos: garantir a gestão de riscos de forma
apropriada em relação aos planos de contingência.
Com base nestes elementos, sabemos que temos várias subáreas para
nos preocuparmos e estudarmos até o final deste módulo para conseguirmos
dimensionar em nosso dia a dia em como garantir a qualidade dos processos de
desenvolvimento de software e do próprio software resultante.
SOMMERVILLE, 2011
CAMPOS, 2016
6
Saiba mais
Este artigo nos traz outra forma de visualizar o gerenciamento da qualidade de
software e assegurar a garantia da mesma:
http://tenstep.com.br/blog/?p=839
TEMA 2: TAREFAS, METAS E MÉTRICAS
Garantir a qualidade de software pressupõe que temos métricas que nos

auxiliam por meio de estatísticas para acompanhamento dos resultados do
processo de desenvolvimento de software. E esta é composta por um conjunto
de tarefas, que tem por responsabilidade o planejamento, supervisão,
manutenção de registros, análise e relatórios. (PRESSMAN, 2011). O pessoal
da garantia da qualidade tem por responsabilidade auxiliar a equipe de software
na obtenção de um produto final com alta qualidade. Essa mesma equipe de
garantia da qualidade para cada projeto prepara um plano de atividades de
garantia da qualidade, participa no desenvolvimento da descrição da gestão de
qualidade do projeto, revisa as atividades de engenharia de software para
verificação das conformidades, audita produtos de software resultantes para
verificação de sua conformidade, garante que desvios de trabalho de software e
produtos resultantes sejam documentados e registra qualquer não aderência,
bem como relata ao gerenciamento superior do projeto.
As ações do grupo de garantia da qualidade devem atingir um conjunto

de metas pragmáticas (PRESSMAN, 2011):
1. Qualidade dos requisitos: correção, completude e consistência do

modelo de requisitos.
2. Qualidade do projeto: avaliação de todo elemento do modelo de projeto
para garantir que apresente alta qualidade e que o projeto esteja de
acordo com os requisitos.
7
3. Qualidade do código: tanto o código-fonte quanto os produtos
relacionados devem estar em conformidade com os padrões locais de
codificação e apresentar características para facilitar a manutenção.
4. Eficácia do controle de qualidade: a equipe de software aplica recursos
limitados para obtenção da maior probabilidade possível de atingir um
resultado de alta qualidade. Agora vamos detalhar estas metas e
identificar atributos indicadores de qualidade para cada meta discutida
(adaptado de HYA, 96 apud PRESSMAN, 2011). Veja a tabela 1 a seguir:
Tabela 1: Metas, atributos e métricas para qualidade de software
Meta Atributo Métrica

Ambiguidade Número de modificadores ambíguos
Qualidade das
necessidades
Completude Número de TBA, TBD
Compreensibilidade Número de seções/subseções
Volatilidade Número de mudanças por requisito

Tempo por atividade quando solicitada a mudança
Facilidade de atribuição Número de requisitos não atribuíveis ao projeto/código
Clareza do modelo Número de modelos UML

Número de páginas descritivas por modelo
Número de erros UML
Integridade da Existência do modelo da arquitetura
Qualidade do
arquitetura
projeto
Completude dos Número de componentes que se atribui ao modelo da
Qualidade do
componentes arquitetura
código
Complexidade da Número médio de cliques para chegar a uma função ou
interface conteúdo típico
Layout apropriado
Padrões Número de padrões usados
Complexidade Complexidade ciclométrica
8
Facilidade de Fatores de projeto
manutenção
Compreensibilidade Porcentagem de comentários internos
Convenções de atribuição de variáveis
Reusabilidade Porcentagem de componentes reutilizados
Documentação Índice de legibilidade
Alocação de recursos Porcentagem de horas de pessoa por atividade
Eficiência do
Taxa de completude Tempo de finalização real versus previsto
controle de
Eficácia da revisão Ver métricas de revisão
qualidade
Eficácia dos testes Número de erros encontrados
Esforço exigida para corrigir um erro
Origem do erro
Temos ainda uma longa jornada dentro do incrível mundo da garantia da

qualidade. Conseguirmos atingir todas as metas expostas na tabela 1 é uma
tarefa árdua. Caminharemos para o próximo tema com a ideia de tornarmos
estas metas e métricas em estatísticas eficientes.
SOMMERVILLE, 2011
CAMPOS, 2016
Saiba mais
Alguns links interessantes que falam sobre gestão e garantia da qualidade:
www.asq.org/software
www.sei.cmu.edu
www.isospice.com
TEMA 3: ESTATÍSTICA
Já conversamos sobre metas e métricas, agora vamos falar a respeito da

estatística da garantia da qualidade. Esta reflete uma tendência crescente em
9
toda a indústria de software. Segundo Pressman (2011), a estatística da
qualidade implica nas seguintes etapas:
1. Informações sobre erros e defeitos coletados e classificados.
2. Associação de cada erro e defeito a sua causa (erros de projeto, violação
de padrões, comunicação inadequada com cliente).
3. Uso do princípio de Pareto (80% dos defeitos podem ser associados a
20% de suas possíveis causas), isolando 20% a poucas causas vitais.
4. Correção dos problemas que provocaram os erros e defeitos.
Aparentemente, pode-se pensar que é tão simplista, mas este tipo de
conceito já impacta na criação de uma gestão de qualidade adaptativa com
mudanças feitas e melhorias nos elementos do processo que introduziram
os erros.
Vamos listar algumas causas mais comuns encontradas em estatísticas
deste tipo:
1. (IES) Especificações incompletas.
2. (MCC) Problema com interpretação da comunicação com o cliente.
3. (IDS) Desvio intencional nas especificações.
4. (VPS) Violação dos padrões de programação.
5. (EDR) Erro na representação de dados.
6. (ICI) Interface inconsistente de componentes.
7. (EDL) Erro na lógica de projeto.
8. (IET) Testes incompletos ou errados.
9. (IDD) Documentação incompleta ou sem precisão.
10. (PLT) Erro na tradução do projeto para linguagem de programação.
11. (HCI) Interface homem-computador ambígua ou inconsistente.
12. (MIS) Outros.
É claro que esta lista nos dá uma ideia de algumas causas encontradas e
não necessariamente serão adotadas dessa forma. Para cada empresa é
importante observação e experimentos até que se encontrem as causas mais
10
aderentes aos projetos. A Figura 2 reflete a utilização desta lista para
exemplificação de como coletarmos estes dados.
Figura 2: Coleta de dados para estatística de garantia da qualidade
Uma vez apurada estatisticamente nossos problemas, conseguiremos

aperfeiçoar substancialmente a qualidade de nossos processos e produtos. Ao
aplicarmos a estatística e o princípio de Pareto, sintetizaremos em uma única
sentença, segundo Pressman (2011): “Invista seu tempo concentrando-se em
coisas que realmente importam, mas, primeiramente, certifique-se de ter
entendido aquilo que realmente importa!”.
SOMMERVILLE, 2011
CAMPOS, 2016
11
TEMA 4: CONFIABILIDADE DE SOFTWARE
Agora vamos falar um pouco sobre a confiabilidade do software,

pensando um pouco nas consequências caso esse falhe frequentemente e
repetidamente. Não iremos nos importar se os outros fatores de qualidade são
aceitáveis, o fato é que isto atrapalha em muito a produtividade de quem o
esteja utilizando.
Aqui estamos pensando nas falhas de programas de computador em um
determinado ambiente por um determinado tempo. Podemos estimar que um
programa, após oito horas em funcionamento, tenha um grau de confiabilidade
de 0,999, ou seja, é provável que ele opere corretamente e sem falhas por
999 vezes.
Para compreendermos o conceito de confiabilidade de software, precisaremos

refletir sobre o que é falha. Falha é um termo que corresponde à falta de
conformidade com os requisitos de software. Mesmo essa definição possui
algumas variações. As falhas podem ser apenas problemáticas ou catastróficas.
Quando uma falha pode ser corrigida em segundos, outras precisarão até de
meses para serem corrigidas. E outro perigo é que, após a correção de tal falha,
esta pode resultar na introdução de outros erros que resultarão em outras falhas.
E este tema vem de longa data. Já tentaram trabalhar falhas por meio da
teoria da confiabilidade de hardware para previsão da confiabilidade de software
— matemática — (PRESSMAN, 2011). Todas as falhas de software podem ser
associadas a problemas de projeto ou implementação. Uma medida de
confiabilidade simples pode ser encontrada pelo uso da seguinte fórmula:
MTBF=MTTF+MTTR, em que MTBF (tempo médio entre falhas), MTTF (tempo

médio para falhar) e MTTR (tempo médio para reparar).
Há uma polêmica entre pesquisadores que acreditam que o MTBF é uma

medida mais útil do que quaisquer outras métricas de software, dentro da
garantia da qualidade. E tal fato ocorre porque o usuário se preocupa com falhas
e nunca com o número total de defeitos. Se observarmos, cada defeito em um
12
programa não representa a mesma taxa de falhas, além de como o número total
de defeitos pode sinalizar indicação da confiabilidade de um sistema. Como
medida para garantira a confiabilidade, temos a falha ao longo do tempo (FIT),
que é uma medida estatística para estimar quantas falhas um componente
poderá ter ao longo de um bilhão de horas de operação. (PRESSMAN, 2011).
Além da confiabilidade, precisamos nos preocupar com a disponibilidade de
software, ou seja, a probabilidade de que um programa esteja operando de
acordo com os requisitos em um dado instante:
Disponibilidade = (MTTF)/(MTTF+MTTR)*100%
Para finalizarmos este assunto, vamos trabalhar o conceito de proteção

de software. Esta atividade, também da garantia da qualidade, concentra-se na
identificação e avaliação de potenciais problemas que podem afetar
negativamente o software e provocar falha em todo o sistema.
Estas são questões que também devem ser tratadas e consideradas em

um bom planejamento de garantia de qualidade no processo de desenvolvimento
de um software.
SOMMERVILLE, 2011
CAMPOS, 2016
TEMA 5: PADRÕES DE QUALIDADE
Chegamos até aqui com muitas definições, conceitos e avaliando os

detalhes importantes para garantirmos a qualidade do processo de
desenvolvimento de software. Agora vamos conversar sobre padrões de
software. Estes padrões desempenham um papel muito importante no
gerenciamento da qualidade de software segundo (SOMMERVILLE, 2011).
Precisamos escolher ferramentas e métodos para suportar o uso desses
13
padrões. Após esta escolha, definimos processos específicos para o
monitoramento do uso dos padrões e verificação se os mesmos estão sendo
seguidos. A figura 3 demonstra essa qualidade baseada em processos.
Figura 3: Qualidade com base em processos
Definir processo Desenvolver Desenvolver

produto produto
Melhorar Qualida
processo de ok?
Padronizar
processo
Fonte: Sommerville, 2011.
Padrões são importantes por várias razões, entre elas, segundo

Sommerville (2011):
1. Capturar conhecimento da organização.
2. Fornecer um framework para definição do significado de qualidade para a
organização.
3. Ajudar na continuidade dos trabalhos realizados por um profissional e
continuado por outro.
4. Padrões de produto aplicam-se a produto de software que está em
desenvolvimento. (Documentação).
5. Padrões de processo que os definem para serem seguidos durante todo
o processo de desenvolvimento de software. É importante que
encapsulem as boas práticas de desenvolvimento.
14
Os padrões entregam valor sob a forma de maior qualidade de produto.
Organismos nacionais e internacionais apoiam a produção de padrões. Entre
eles encontram-se: ANSI, BSI, OTAN e IEEE. Tais padrões estão em linguagens
de programação como Java e C++, notações, gráficos, símbolos e
procedimentos para derivação e escrita de requisitos de software, procedimentos
de garantia de qualidade e processos de verificação e validação de software.
O framework de normas ISO 9001 aplica-se a organizações que projetam,
desenvolvem e mantêm produtos, inclusive software. Este foi desenvolvido em
1987, e sua mais nova revisão é de 2008. Este define princípios gerais da
qualidade, descreve os processos gerais de qualidade e estabelece os padrões
organizacionais e os procedimentos que devem ser definidos. Estes são
documentados em um manual de qualidade da organização. Na Figura 4
encontramos os processos essenciais da ISO 9001.
Figura 4: Processos Essenciais da ISO 9001
15
Além da ISO 9001, temos também a IEEE 829-2008, uma norma
adequada aos padrões do PMI para gerência de projetos. Neste caso,
consideramos a fase de testes como um projeto paralelo ao desenvolvimento de
software, seguindo as abordagens desta norma. Ela trata exclusivamente de
teste de software, suprindo uma carência dos padrões da PMI. Segundo esta
norma, a atividade de teste de software deve fornecer informações objetivas
sobre a qualidade do software que está em desenvolvimento.
Sabemos que a certificação ISO 9001 não garante completamente que o
desenvolvimento de software e o produto final de fato estejam de acordo com o
que nossos usuários precisam e esperam, mas que todos os processos estão
em conformidade com a norma. É claro que se a empresa é certificada, ela fará
o possível para garantir tanto processos quanto software de acordo com o
desejado pelos usuários finais.
SOMMERVILLE, 2011
CAMPOS, 2016
TROCANDO IDEIAS
Refletir sobre a introdução da garantia de qualidade, por meio de metas,

métricas, estatísticas e padrões em projetos de desenvolvimento de software.
Quais seriam os custos para introduzirmos tantas avaliações, correções e
padronizações? Precisaríamos de profissionais habilitados para tais tarefas, ou
bastaria utilizarmos o próprio pessoal do desenvolvimento?
SÍNTESE
Estudamos até aqui sobre elementos importantes para garantia da

qualidade. Tanto o gerenciamento quanto a garantia da qualidade querem
16
assegurar que o software tenha poucos defeitos e esteja em conformidade com
padrões de manutebilidade, confiabilidade e portabilidade. Os padrões são muito
importantes para a garantia de qualidade, pois por meio de suas melhores
práticas oferecem uma base para construção de software de boa qualidade.
O processo de documentação, que é um elemento bastante importante dentro
da área de qualidade, pode ser baseado em um conjunto de procedimentos da
garantia de qualidade sugeridas pela ISO 9001. Optar por revisões e inspeções
garantirão melhoria no processo e no produto. As revisões dos entregáveis são
técnicas usadas para avaliação da qualidade, enquanto que inspeção de
programas ou revisão em pares buscam possíveis erros e omissões. Quando
falamos em medição de software, usamos coleta de dados quantitativos capazes
de subsidiarem métricas de software para garantir a qualidade tanto do produto
quanto do processo.
REFERÊNCIAS
CAMPOS, F. M. Qualidade, qualidade de software e garantia da qualidade
de software são as mesmas coisas?. Disponível em:
e-garantia-da-qualidade-de-software-sao-as-mesmas-coisas.aspx em maio de
2016.
INMETRO. Fundamentos da Qualidade. Disponível em:

<http://www.inmetro.gov.br/qualidade/iaac/pdf/fundamentos-qualidade.pdf>.


17


18
AULA 3
1
CONVERSA INICIAL
Olá, seja bem-vindo. Assista ao terceiro vídeo da professora Maristela

CONTEXTUALIZANDO
Estudamos questões importantes para a garantia da qualidade, e um

conjunto de atividades de suma importância para a qualidade tanto do software
quanto de seu processo são os testes. A estratégia de testes de software nos
oferece roteiros que descrevem passo a passo cada procedimento a ser aplicado
e em qual momento do processo de desenvolvimento. Sendo assim, toda
estratégia de teste deve incorporar planejamento de teste, projeto de casos de
teste, execução dos testes e avaliação dos dados resultantes, segundo
(PRESSMAN, 2011).
Historicamente a execução de testes vem se transformando há
décadas (RIOS, 2008). Nos anos 70, os testes eram feitos pelos próprios
desenvolvedores, e a nossa garantia era de que o produto funcionasse. Entre os
anos 80 e 90 já tínhamos testes feitos pelos desenvolvedores e usuários para
garantia dos requisitos iniciais do projeto. Entre os anos 90 e 2000, a garantia se
baseava no produto funcionando, atendendo os requisitos e sem defeitos. Estes
testes eram executados por meio de processos de testes feitos pelos
desenvolvedores, usuários e testadores. Nos últimos anos, a complexidade tanto
do desenvolvimento quanto dos testes aumentou significativamente, incluindo
agora questões de segurança e performance.
Mas quando olhamos para nosso dia a dia no desenvolvimento de
software, quase que todos os problemas se tornam um bug. Sim, bug é
considerado um defeito, uma falta, um problema, um incidente, uma anomalia ou
qualquer outro problema que ocorra durante a execução de nosso software.
2
(PINHEIRO, 2015). Também temos uma definição mais formal sobre bug
(PATTON, 2005 apud PINHEIRO, 2015):
Um bug ocorre quando uma ou mais das opções abaixo for verdadeira:
 O software NÃO faz algo que a especificação diz que ele deveria
fazer;
 O software FAZ algo que a especificação diz que ele NÃO
deveria fazer;
 O software faz algo que a especificação não menciona;
 O software NÃO faz algo que a especificação NÃO menciona,
mas deveria mencionar; e
 O software é difícil de usar, entender, ou na visão do testador
pode ser visto pelo usuário final como não estando correto.
E o velho discurso vem à tona novamente: “O custo de um bug está

diretamente associado à fase do ciclo de desenvolvimento em que o bug é
encontrado. Um bug encontrado durante a especificação pode custar um dólar.
O mesmo bug encontrado no release pode custar 100 vezes mais.” (PINHEIRO,
2015). Quando analisamos os erros, 85% são simples de correção (menos de 1
hora), 1% dos erros leva mais que alguns dias para correção, 80% do esforço de
manutenção é gasto com 20% dos erros. (PINHEIRO, 2015).
Agora falando um pouco mais sobre os famosos bugs, eles podem ser
classificados em 3 principais tipos (PINHEIRO, 2015):
 ERRO, que ocorre devido à ação humana, resultado de um software com
defeitos;
 DEFEITO, o qual ocorre devido a problemas de informações, de dados,
de instruções incorretas; e
 FALHA, que ocorre quando um programa não se comporta conforme o
estabelecido ou apresenta resultados inconsistentes.
3
Figura 1: Erros, defeitos e falhas
Fonte: Claudio, 2016.
Teremos muito a evoluir para atingirmos níveis de excelência na área de

testes de software. Uma das grandes consequências da importância desta área
dentro do desenvolvimento de software encontra-se nos vários cursos de
pós-graduação espalhados mundo afora para suprir uma grande carência de
profissionais. Isso porque, normalmente, os estudantes gostam de atuar no
desenvolvimento dos projetos de software como desenvolvedores ou analistas,
mas dificilmente gostam de atuar como profissionais da área de testes. É uma
área que exige um grau de detalhe bastante grande, o que por vezes torna-se
cansativo e repetitivo para alguns perfis de profissionais.
SOMMERVILLE, 2011
Saiba mais
http://www.linhadecodigo.com.br/artigo/2775/introducao-ao-teste-de-
software.aspx
4
Gostaria que agora você olhasse e refletisse sobre o número de
oportunidades profissionais que esta área de qualidade de software pode
oferecer-lhe. Utilize o link: <http://ibqts.com.br/> para compreender e ampliar sua
visão sobre possibilidades de atuação na área de engenharia de software,
focando em questões de qualidade e testes de software. Liste as certificações
existentes, bem como suas finalidades dentro do processo de desenvolvimento
de software.
http://ibqts.com.br/
TEMA 1: O QUE É TESTE DE SOFTWARE?
Nada melhor do que compreendermos sempre as definições e conceitos

existentes para uma nova área de conhecimento que estejamos estudando.
Então vamos à pergunta mais simples desde que iniciamos nossos encontros: O
que é teste de software? “Teste de software é um conjunto de atividades que
podem ser planejadas com antecedência e executadas sistematicamente. ”,
segundo Pressman (2011). Todo teste deverá contar com um modelo (template)
para utilização de técnicas específicas de projeto de caso, de teste e métodos
de testes. Toda estratégia de testes deve acomodar testes de baixo nível, para
verificação de um pequeno segmento de código fonte, bem como testes de alto
nível, que validem funções do sistema de acordo com os requisitos elicitados.
Cada estratégia fornece diretrizes para que o profissional responsável consiga
cumprir uma série de metas. Não é novidade que desenvolvemos software
sempre sob pressão em relação a prazos e custos, então, é importante obtermos
formas de medição do progresso dos testes bem como dos problemas revelados
e corrigidos o mais breve possível dentro do processo de desenvolvimento de
software.
A triste notícia é que podemos seguir muitos métodos, adotar muitas

técnicas, adotar certificações de padrões de qualidade, mas mesmo assim ainda
não ficaremos livres dos bugs. Diríamos que ainda é impossível testarmos todas
5
as possibilidades de formas e alternativas de entrada de dados, bem como as
diversas possibilidades e condições criadas pela lógica de algoritmos de cada
desenvolvedor. Há estimativas que garantem que a média do número de defeitos
em programas liberados para testes é de 1 a 3 por 100 instruções executáveis
(RIOS, 2008). E então você se perguntará: Se não conseguimos atingir 100% de
excelência na área de testes, por que testar? Teremos que lembrá-lo que o
propósito dos testes é a descoberta e correção dos problemas com foco na
melhoria e na qualidade do software. Então, quanto ele deve melhorar? De
acordo com o que a empresa está consciente em investir numa equipe de testes,
capaz de tornar a quantidade de defeitos tendendo a zero. Logo, quanto mais
tempo e recursos financeiros dedicados ao processo de testes, mais perto da
satisfação do cliente chegaremos.
Nunca devemos esquecer que o processo de desenvolvimento de

software é feito por seres humanos, e que, apesar dos melhores métodos ou
técnicas, profissionais também erram. E alguns problemas, dos quais já
conversamos, podem advir de uma especificação incompleta ou errada, com
limitações de hardware ou software, com uma base de dados organizada não da
melhor forma, além de obviamente erros nos algoritmos.
Compreendemos que por mais que criemos técnicas, métodos e

ferramentas que apoiam o teste de software, continuaremos uma longa jornada
com seres humanos que, em algum momento, podem errar por problemas
simples, como falha na comunicação com seus stakeholders. Então, quando
falamos de testes de software, estamos olhando para o produto e para o
processo como um todo, e acabamos entrando em questões que não são
meramente técnicas, mas subjetivas em relação à comunicação humana.
SOMMERVILLE, 2011
6
Saiba mais
O IBQTS, Instituto Brasileiro de Qualidade em Testes de Software, é uma
entidade de caráter de pesquisa e órgão certificador de profissionais da área
de Engenharia de Requisitos e Engenharia de Testes de Software, reconhecido
oficialmente por empresas e instituições de ensino, tanto no Brasil quanto no
exterior.
As certificações fornecidas pelo Instituto qualificam analistas de sistemas

e negócio, desenvolvedores e testadores com interesse em obter um atestado
de reconhecimento técnico válido para o mercado nacional e internacional,
e estão aderentes a padrões internacionais de qualidade.
Fundado em 2006, o IBQTS nasceu com a missão de aprimorar a

capacidade produtiva dos profissionais de TI, melhorando a qualidade dos
requisitos, desenvolvimento e testes. Com a necessidade cada vez maior de
profissionais qualificados, o instituto certifica profissionais para a crescente
competição internacional nas áreas de Engenharia Testes e Requisitos. Essas
certificações oferecem a oportunidade de um diferencial competitivo.
Disponível em: http://ibqts.com.br/
TEMA 2: PROCESSOS DE TESTES
Como temos falado ao longo de nossos módulos que envolvem o

desenvolvimento de software, sempre voltamos ao assunto: processo!
Sim, processos são responsáveis pela organização de todas as tarefas e
atividades que sejam necessárias para que atinjamos algum resultado em
nossos projetos. E com o projeto de testes de software não é diferente! O
processo de teste deve ter como base uma metodologia que seja aderente à
metodologia que adotamos para o desenvolvimento do software. Deve possuir
especialistas qualificados, ambiente e ferramentas adequados para que os
resultados sejam alcançados. (RIOS, 2008). Uma metodologia de teste está
descrita em um documento que organiza a atividade de teste dentro do contexto
7
do domínio do problema ou da organização. Esta metodologia deverá conter as
fases do seu ciclo de vida, como por exemplo na Figura 2.
Figura 2: Fases do ciclo de vida do processo de testes
Planejamento
Procedimentos Especificação Execução Entrega

iniciais
Preparação
Fonte: Rios, 2008.
Observando cada fase desta proposta de metodologia de testes, podemos

descrevê-las da seguinte forma:
Procedimentos Iniciais: consideram a elaboração de um documento chamado

Guia Operacional de Testes (GOT), que estabelece o acordo entre as partes
envolvidas no projeto de teste (usuários, desenvolvedores, pessoal de testes
e de produção).
Planejamento: consiste na elaboração e revisão da estratégia a ser adotada

no plano de testes.
Preparação: consiste no ambiente de teste (equipamentos, rede, pessoal,

software e ferramentas).
Especificação: elaboração e revisão dos casos de teste (ou scripts de teste),

uso de ferramentas de automação e roteiros de teste e execução dos testes de
verificação da documentação do sistema. Testes estáticos.
Execução: execução de todo planejamento de testes conforme os casos de

teste e roteiros de teste, registrando-se os resultados.
Entrega: entrega do sistema testado e de dos devidos registros.
8
Na tabela 1 mostramos um detalhamento de cada fase de um processo
de testes com suas ações requeridas e verificações.
Processo de Processo de Verificação/

Ações Requeridas
Teste Desenvolvimento Validação
Planejam
Planejamento do Integração dos planos. Verificação (Revisões

projeto de Preparação da estratégia de / WalkThrough /
ento
desenvolvimento testes e planos de testes. Inspeção)
Revisão dos planos de

Especificação
testes
Elaboração e revisão dos Verificação (Revisões
Projeto lógico e físico casos de teste e dos roteiros / WalkThrough /
de teste Inspeção)
Atualização do plano de
projeto de desenvolvimento
Verificação (Revisões
/ WalkThrough /
Execução
Busca de defeitos e Inspeção e testes

Construção
correções unitário, de
integração de
sistema)
É sempre bom lembrarmos que quanto mais tarde um defeito for

identificado, mais caro ficará para corrigi-lo. O aumento é sempre exponencial
em relação ao trabalho de testes através das fases do projeto.
SOMMERVILLE, 2011
TEMA 3: TIPOS DE TESTE
Percebemos que precisamos montar um bom plano de ação e execução

de testes que seja adequado ao tamanho de nosso projeto de desenvolvimento,
pois envolverá um valor relativamente alto ao considerarmos o melhor dos
9
mundos. Vamos classificar estes testes existentes e suas características para
compreendermos o que utilizar e em qual momento do nosso planejamento e
execução de testes.
Tipos de teste segundo Rios (2008):
 Testes de regressão: garantem que o software atenda aos requisitos
mesmo depois de sofrer manutenções. Um conjunto de dados e scripts
contém uma baseline e executam para verificação de mudanças
introduzidas posteriormente. Discrepâncias são resolvidas antes de se
atingir o próximo nível de testes.
 Testes de carga: avaliam a resposta de um software com pesada carga
de dados e/ou grande número de usuários simultaneamente para
verificação do nível de escalabilidade, confrontando o tempo de
resposta ou falha.
 Teste de estresse: simulação de situações que possam ocorrer em
produção, como falta de memória, falta de espaço em disco.
 Teste Back-to-back: executado em versões diferentes do software com
comparação dos resultados.
 Teste de configuração: verifica a aptidão do software para rodar em
diferentes versões ou configurações de ambientes (hardware, browsers
ou versões de browsers).
 Teste de usabilidade: verificação do nível de facilidade de uso do
software pelos usuários. Efetuado principalmente em aplicações Web em
decorrência do grande número de navegações entre páginas. Clareza de
linguagem, mensagens de erro e links para páginas também são testados.
 Testes de instalação: verificação da instalação parcial, total ou
atualização de aplicativo.
 Testes de Segurança: validação da capacidade e qualidade da
recuperação do software após crashes, falhas de hardware ou outros
problemas catastróficos.
10
 Teste de compatibilidade: validação da capacidade do software em
executar em um ambiente específico (hardware/software/sistema
operacional/rede).
 Teste de desempenho: garante que o sistema atenda aos níveis de
desempenho e tempo de resposta acordados com os usuários e definidos
nos requisitos. (Performance).
 Testes funcionais: grupos de testes que avaliam a especificação versus
a implementação.
 Testes de qualidade de código: verificação do código fonte dos
programas em conformidade com padrões, melhores práticas, instruções
não executadas entre outros.
 Testes de alterações: rastreiam alterações de programas durante o
processo de testes.
 Testes de recuperação de versões: verificação da capacidade de
retorno a uma versão anterior do sistema.
 Testes de interoperabilidade: avaliação das condições de integração
com outros ambientes/sistemas (troca de informações).
 Testes de sobrevivência (confiabilidade ou disponibilidade):
avaliação da capacidade do software em continuar operando quando
algum outro elemento pare de funcionar ou fique inoperante (hardware,
por exemplo).
 Testes estáticos: avaliação da documentação do projeto (modelos,
requisitos).
 Testes embutidos: avaliação da integração entre hardware e software.
 Testes de verificação do site Web: verificação de problemas com
determinados sites Web (links inválidos, arquivos órfãos, páginas lentas).
 Testes de conferência de arquivos: verificação da alteração de arquivos
utilizados.
 Testes Alfa: executados em ambiente de desenvolvimento na
proximidade da conclusão.
11
 Testes Beta: executados durante a fase desenvolvimento e testes, mas
praticamente concluídos, com o maior número possível de defeitos e
problemas encontrados antes do release final.
Além de toda essa classificação de tipos de testes, temos ainda o que

chamados de técnicas de testes e níveis de testes.
Como técnicas de testes, temos testes de caixa preta e de caixa branca.
Os testes de caixa preta testam a funcionalidade e sua aderência aos requisitos
sem conhecimento do código e da lógica interna do sistema em teste, enquanto
que os testes de caixa branca testam cláusulas de
código, lógica interna e cada componente codificado, além de outros
elementos técnicos.
Estágios ou níveis de testes, segundo Rios (2008), consideram os seguintes
grupos:
 Testes unitários: estágio mais baixo na escala de testes. São testes de

componentes versus suas especificações para que características e
funcionalidades sejam verificadas independentemente do sistema total.
Realizados pelos desenvolvedores.
 Testes de integração: execução de uma combinação de componentes
para verificação da execução em conjunto, conforme as especificações.
Realizados pelos desenvolvedores.
 Testes de sistema: realizados pela equipe de testes, observando a
execução completa do sistema e seus subsistemas, dentro de um
ambiente operacional controlado, para validação das funcionalidades
do sistema. Uso de dados de teste para validação de situações
mais próximas da realidade, que ocorrerá no momento do ambiente
de produção.
 Testes de aceitação: testes finais de execução do sistema, juntamente
com usuários, tendo-se em mente que as soluções deverão atender aos
objetivos do negócio e dos requisitos. Funcionalidade e usabilidade são
12
observadas neste momento. Usuários com suporte da equipe técnica de
testes são responsáveis por este teste.
Vimos que há uma quantidade razoável de tipos de testes, níveis e

estágios. Só de observarmos toda esta possibilidade de testes, podemos
concluir a quão custosa pode ser a tarefa de teste de software. Por isso é
importante adotarmos um plano aceitável de acordo com o tamanho do projeto
de software e de sua equipe de desenvolvimento e testes.
SOMMERVILLE, 2011
CAMPOS, 2016
Saiba mais
Os 13 principais tipos de testes de software:
http://www.targettrust.com.br/blog/desenvolvimento/testes/os-13-principais-
tipos-de-testes-de-software/
TEMA 4: REVISÕES E INSPEÇÕES
Como a área de garantia da qualidade de software é muito abrangente, é

comum errarmos ao utilizarmos determinados termos técnicos. Os termos
comumente utilizados erroneamente são: revisões, inspeções, validações
e verificações.
Vamos iniciar pelos termos revisões e inspeções. As inspeções e
revisões de software são atividades e técnicas estáticas que avaliam
problemas na construção de software sem a necessidade de que o software seja
executado em um ambiente computacional.
Encontramos normalmente o processo de revisão estruturado em três

fases (Sommerville, 2011):
13
1. Atividade de pré-revisão: são atividades preparatórias essenciais para
a eficácia da revisão. Atividades relacionadas com planejamento e
preparação da revisão. Envolve uma equipe de revisão, organização de
tempo e lugar para que ocorram as revisões. Os envolvidos compreendem
o que o software deverá fazer, bem como os documentos de padrões
relevantes. Os revisores podem fornecer comentários sobre o software,
caso não participem de alguma reunião de revisão.
2. Reunião de revisão: durante a reunião o líder da revisão encaminha um
documento com todos os problemas e questões de qualidade a serem
discutidos. Este líder será responsável por garantir que todos os
comentários escritos sejam considerados no relatório final. Além dos
comentários, deverão ser registradas todas as ações corretivas
acordadas durante a reunião.
3. Atividades pós-revisão: todas as questões e problemas levantados
devem ser abordados. Esse processo envolve a correção de bugs de
software, refatoração de software entre outras técnicas para que esteja
em conformidade com os padrões de qualidade ou necessidade de nova
redação de documentos. Ao término, o presidente do grupo de revisões
deve averiguar se todos os comentários foram levados em consideração.
Dependendo do caso, será necessária nova reunião para apuração da
conformidade com as reuniões de revisão.
A Figura 3 nos demonstra de forma objetiva o processo de revisão de

software, seguindo as atividades tratadas anteriormente.
14
Figura 3: Processo de revisão de software
Em um desenvolvimento ágil, o processo de revisão de software

geralmente é mais informal. Por exemplo, na metodologia de desenvolvimento
SCRUM, ocorre uma reunião de revisão após a conclusão de cada iteração do
software (revisão de Sprint), na qual os problemas e as questões de qualidade
podem ser discutidos. Já na XP (Extreme Programming), a programação em
pares garante que o código esteja sendo examinado e revisto à medida que esse
é desenvolvido pela equipe. As reuniões diárias de equipe trabalham as
questões de qualidade. Normalmente, as abordagens ágeis não adotam
padrões, logo as questões de conformidade são desconsideradas.
Sempre é um contraponto a questão do uso de métodos ágeis para
desenvolvimento quando abordamos questões de qualidade. A essência destes
métodos encontra-se justamente na desburocratização e em não exagerar na
documentação de software. Porém, percebemos o quanto é necessária a
geração de documentos e modelos para efetuarmos a garantia da qualidade por
meio de testes, inspeções, revisões e conformidade com padrões.
Tomando o rumo das inspeções de programas, estas são consideradas

revisões em pares, nas quais membros da equipe colaboram para a descoberta
de bugs no programa em desenvolvimento. Modelos de UML podem ser
checados pela utilização de casos de teste. As inspeções auxiliam na descoberta
de problemas com testes, melhorando a eficácia desses testes ao se detectar
15
bugs no programa. Elas envolvem equipes de diferentes origens, as quais
revisam linha por linha o código-fonte dos programas, buscando defeitos e
problemas e os descrevem em relatórios nas reuniões de inspeção. Os defeitos
podem ser erros lógicos, anomalias no código ou detalhes dos modelos de
projeto.
O interessante é lembrarmos que inspeções e revisões são estáticas e
podem ser aplicadas tanto em código de programas quanto em modelos e
documentação de projeto de software. Elas podem ser prejudicadas quando
utilizamos métodos ágeis para o desenvolvimento de software, uma vez que a
utilização de documentações com modelos do projeto não é comum em
desenvolvimento ágil.
SOMMERVILLE, 2011
TEMA 5: VERIFICAÇÕES E VALIDAÇÕES
Conversamos sobre inspeções e revisões e agora nos resta

compreendermos melhor o que são verificações e validações quando falamos
em garantia da qualidade de software. Teste de software é um elemento muitas
vezes conhecido como validação e verificação (V&V). Segundo Pressman
(2011), “verificação refere-se ao conjunto de tarefas que garantem que o
software implemente corretamente uma função específica. Validação refere-se
a um conjunto de tarefas que asseguram que o software foi criado e pode ser
rastreado segundo os requisitos do cliente.”
Se fôssemos transformar em duas perguntas, teríamos as seguintes
questões:
“Verificação: Estamos criando o produto corretamente?” (PRESSMAN,
2011).
“Validação: Estamos criando o produto certo?” (PRESSMAN, 2011).
16
Esta definição V&V contém muitas atividades da garantia da qualidade de
software. Incluem atividades como revisões técnicas, auditorias de qualidade e
configuração, monitoramento de desempenho, simulação, estudo de viabilidade,
revisão de documentação, revisão de base de dados, análise de algoritmo, teste
de desenvolvimento, teste de usabilidade, teste de qualificação, testes de
aceitação e teste de instalação (PRESSMAN, 2011). A garantia e a qualidade
utilizam o teste como último elemento para estimar mais pragmaticamente seus
erros descobertos. Na fase de verificação, utilizamos todos ou alguns dos testes
que foram classificados no tema “tipos de testes”. Lá pudemos conhecer um
pouco de cada tipo de teste e sua importância para a qualidade de software.
Ao terminarmos a fase de verificação com o uso das técnicas escolhidas
para cada projeto, voltamo-nos para a fase de validação. Agora nos
preocuparemos com o sistema que é visualizado e reconhecido pelos usuários.
Seu principal objetivo é apontar o sucesso do funcionamento do software,
confrontando o esperado com o realizado. Os testes da validação demonstram
conformidade com os requisitos. Logo, é importante que o plano de testes
descreva as classes de testes a serem conduzidas e um procedimento de testes
para definição dos casos de testes específicos que garantam os requisitos
funcionais de acordo com as expectativas dos clientes. Alguns exemplos de
requisitos cumpridos estarão em conformidade com transportabilidade,
compatibilidade, recuperação de erro, manutenibilidade. Caso sejam
descobertos desvios de especificação, cria-se uma lista de deficiências que
serão corrigidas conforme um plano com prazos e negociações junto aos
clientes.
Percebemos até aqui que o tema sobre garantia da qualidade de processo
e de software é extenso e carece de adaptação a cada tipo e tamanho de projeto.
Que há diferenças conceituais entre revisões, inspeções, verificações e
validações. Que cada uma tem seu grau de importância dentro do nosso
processo de testes e qualidade de software. Que entraremos num dilema ao
utilizar métodos ágeis com a aplicação de garantia da qualidade de software.
Mas nada que não possa ser resolvido utilizando-se do bom senso. A área de
17
engenharia de software é muito ampla e repleta de métodos, técnicas,
ferramentas e frameworks. Cabe a cada líder de projeto adaptar o que seja mais
conveniente com o intuito de garantir um processo e um software com qualidade
esperada pelos stakeholders.
SOMMERVILLE, 2011
http://www.devmedia.com.br/a-importancia-da-validacao-e-da-
verificacao/24559
TROCANDO IDEIAS
Refletir sobre a introdução da garantia de qualidade, utilizando os

conceitos de inspeções, revisões, verificações e validações em projetos que
utilizem métodos ágeis. Quais as maneiras de garantirmos a qualidade sem
perdermos a essência destes métodos de desenvolvimento de software?
SÍNTESE
Estudamos até aqui sobre inspeções, revisões, verificações e

validações de software para garantia da qualidade. Nosso objetivo é termos
uma visão geral sobre as várias formas de efetuarmos testes, sejam eles
estáticos ou dinâmicos. Sejam eles em modelos seguindo nossos casos de
testes ou a nível de classes, componentes, código-fonte, integração ou
quaisquer outros tipos. Nosso desafio é a entrega de um software que alcance
os resultados esperados com a menor quantidade possível de erros e falhas.
Que nossos sistemas sejam usáveis, seguros, portáveis, de fácil manutenção,
que nos assegure de riscos. Percebemos que há uma diferença quando
conceituamos erro, defeito ou falha. Lembrando então que (CLAUDIO, 2016):
 ERRO, que ocorre devido à ação humana, resultado de um software com
defeitos;
18
 DEFEITO, o qual ocorre devido a problemas de informações, de dados,
de instruções incorretas; e
 FALHA, que ocorre quando um programa não se comporta conforme o
estabelecido ou apresenta resultados inconsistentes.
Enfim, nossa expectativa é conseguirmos traçar um panorama sobre o

que é melhor e adaptável a cada tipo e tamanho de projeto para o qual estejamos
atuando. Vimos também o quão importante são as equipes de revisões, as
reuniões de inspeções, os documentos gerados após a aplicação dos testes,
bem como os planos de ação para melhorarmos e deixarmos o nosso software
cada vez mais próximo das expectativas reais de
nossos usuários.
REFERÊNCIA
CLAUDIO, A. Testes de Software. Disponível em:

<http://www.devmedia.com.br/artigo-engenharia-de-software-introducao-a-
teste-de-software/8035>. Acesso em: maio de 2016.

PINHEIRO, A. F. Fundamentos da engenharia de software: qualidade com

testes e gerência. v. 6. Pernambuco, Amazon Publishing, 2015.

RIOS, E. Documentação de teste de software. 2. ed. Iteste: Instituto de teste

de software. 2008.
19

20
AULA 4
1
CONVERSA INICIAL
Olá, seja bem-vindo. Assista ao quarto vídeo da professora Maristela
CONTEXTUALIZANDO
Já conversamos sobre inspeções, revisões, verificações e validações
de software para garantia da qualidade. Compreendemos também a diferença
entre erros, defeitos e falhas em nossos sistemas. Vamos explorar agora as
diferenças entre alguns tipos de software para conseguirmos adaptar técnicas a
cada plataforma diferente. Perceberemos que não temos a necessidade de
utilizarmos todas as técnicas que estudamos, porém, como agrupá-las da melhor
forma para ganharmos um resultado mais próximo do esperado por nossos
usuários finais. Resultados estes que por vezes independem de requisitos
funcionais, como no caso dos testes de sistemas que agrupam técnicas de testes
capazes de garantir segurança, disponibilidade entre tantas outras questões não
funcionais extremamente importantes para o bom funcionamento de um
software.
Escolhemos trabalhar com software convencional, orientado a objetos e
para Web. Não conseguiremos abordar exatamente todos os ambientes e
plataformas, mas seguramente são os tipos mais comuns existentes no
mercado. A partir destes, verificaremos que os demais utilizam muitas
características existentes nestes três tipos escolhidos para nossos estudos.
Quando falamos em software convencional, podemos exemplificar como
um sistema de ERP, ou simplesmente um sistema de controle de horas.
Normalmente possuem interfaces padronizadas, com menus e submenus e que
executam geralmente em um formato cliente-servidor. Apesar de critérios de
segurança, disponibilidade e escalabilidade serem importantes, tendem a utilizar
testes mais focados nas funcionalidades e requisitos do sistema. O que mudaria
para um sistema orientado a objetos? Estamos falando da preocupação com
2
elementos importantes para a orientação a objetos, tais como reusabilidade,
funcionamento individual e colaborativo das classes, instanciações e hierarquias.
Precisamos ter um olhar bastante focado na integração de classes por meio de
seus métodos que nos gerem resultados esperados. Porém, quando falamos de
sistemas para Web, precisaremos lembrar que estamos trabalhando dentro de
um ambiente multidisciplinar com algum grau de complexidade e integração.
Precisaremos planejar testes eficientes e abrangentes, que avaliem, verifiquem
e inspecionem questões relacionadas à interação humano-computador,
simulações, multimídia, links, hipertextos, segurança, escalabilidade, segurança
e disponibilidade! Ufa! De fato, nossa preocupação com testes aumenta quando
temos a grande rede mundial envolvida em nosso modesto projeto!
SOMMERVILLE, 2011
Saiba mais
O que é Web?
https://www.infoq.com/br/news/2015/03/o-que-e-web
https://www.youtube.com/watch?v=cl_g0osRYBw
Talvez você esteja pensando: Estamos dando tanto enfoque ao ambiente

Web quando falamos em testes. E estamos sim! A tendência por sistemas para
Web e para aplicativos móveis cresce exponencialmente.
Os grandes problemas com erros, falhas e defeitos também são
maiores neste ambiente, que não é nem um pouco “controlado”!
Pensando nisso, utilize a seguinte sentença, obtida por meio do link
<https://www.infoq.com/br/news/2015/03/o-que-e-web>, para você pesquisar
mais sobre a W3C e testes de software:
“A visão "o que pode ser feito no navegador Web" tem mudado para o
que agora é chamado de Plataforma Web [...] e sendo o elemento
3
central do que está acontecendo no W3C. O W2C tem focado muito
em tornar a Web em uma plataforma que pode competir com os seus
concorrentes, isto é o iOS e Android.
O que você encontrou que possa subsidiar testes de software para Web
e garantia da qualidade de processos de desenvolvimento para Web?
https://www.infoq.com/br/news/2015/03/o-que-e-web
http://www.w3c.br/Home/WebHome
TEMA 1: TESTE PARA SOFTWARE CONVENCIONAL
O grande objetivo do teste é encontrarmos erros, e um bom teste é aquele

que induz a uma alta probabilidade de encontro desses erros. Logo, devemos
planejar nosso projeto de testes com a mente da “testabilidade”. Segundo James
Bach in apud (Pressman, 2011): “Testabilidade de software é simplesmente a
facilidade com que o programa de computador pode ser testado”. Quando
falamos em testabilidade temos que ter em mente 7 atributos importantes,
conforme a figura 1.
Figura 1: Atributos Importantes da Testabilidade
Testabilidade
Operabilidade Observabilidade Controlabilidade
Decomponibilidade SImplicidade Estabilidade
4 Compreensibilidade
Um bom teste não é redundante, opta-se por não ser muito simples e nem
muito complexo e revela erros de acordo com um tempo e recursos delimitados
para indução de erros. E, principalmente, deve ter um olhar interno e outro
externo.
Nossos produtos devem ser testados em duas frentes:
1. Conhecimento de função especificada demonstrando que essa é

operacional. (Caixa Preta).
2. Conhecimento da garantia de integração, ou seja, operações internas são
realizadas de acordo com as especificações. (Caixa branca).
O teste caixa-preta faz referência a testes realizados na interface do

software. Um teste caixa-preta examina alguns aspectos fundamentais
de um sistema, com pouca preocupação em relação à estrutura lógica
interna do software. O teste caixa-branca fundamenta-se em um
exame rigoroso do detalhe procedimental. Os caminhos lógicos do
software e as colaborações entre componentes são testados
exercitando conjuntos específicos de condições ou ciclos.
(PRESSMAN, 2011).
Testes de Caixa-Branca
1. Teste de caminho básico: São criados casos de teste para exercitar o
conjunto básico de execução de todas as instruções de um programa pelo
menos uma vez durante o teste. Podemos utilizar as seguintes notações:
a. Grafo de fluxo: um grafo representa o fluxo de controle lógico

utilizando a notação da Figura 2.
5
Figura 2: Notação de Grafo de Fluxo
b. Caminhos de programa independentes: é qualquer

caminho para que o programa seja introduzido pelo menos com um
novo conjunto de comandos para uma determinada condição
(Figura 3).
Figura 3: Caminhos de programa independentes
6
c. Derivação de casos de testes: método de teste de caminho base
pode ser aplicado a projeto procedimental. Aqui ele se torna um
caminho básico como uma série de passos (Figura 4).
Figura 4: Derivação de casos de testes
7
d. Matrizes de grafos: este procedimento deriva um grafo de fluxo
até que um conjunto de caminhos-base seja determinado para uma
possível automatização (Figura 5).
Figura 5: Matrizes de grafos
2. Teste de estrutura de controle: Neste tipo de teste o foco encontra-se

nas estruturas básicas de controle dentro de um algoritmo. Testes de
condição, de fluxo de dados e testes de ciclo.
Figura 6: Controle de Estrutura
8
Testes de Caixa-Preta
Os testes de caixa-preta devem abordar questões tais como:
 Funções incorretas ou faltantes;

 Erros de Interface;
 Erros em estruturas de dados ou acesso a base de dados externas;
 Erros de comportamento ou desempenho;
 Erros de inicialização ou término.
1. Métodos de teste com base em grafo: compreensão dos objetos

modelados no software e suas relações. Criação de um grafo que liga
objetos com propriedades de nós e pesos são atribuídos a cada nó. (figura
6).
Figura 6: Método de testes com base em grafo
9
2. Particionamento de equivalência: divisão do domínio de entrada de um
programa em classes de dados para criação de casos de testes.
3. Análise de valor limite: técnica de projeto de casos de teste que
complementa o particionamento de equivalência. Muitas vezes aplicado
intuitivamente por engenheiros de software para detecção de erro.
4. Teste de matriz ortogonal: para domínio de entrada pequeno, mas muito
grande para acomodar o teste exaustivo. Aplicada a uma lógica
defeituosa de um componente, por exemplo.
5. Testes Baseados em Modelos: Técnica de caixa preta que usa
informações contidas no modelo de requisitos como base para geração
de casos de teste. Utilizam diagramas de estado da UML.
6. Testes para ambientes, arquiteturas e aplicações especializadas:
a. Teste de interfaces;
b. Teste de arquitetura cliente-servidor (função da aplicação, servidor,
base de dados, transação e comunicação);
c. Teste de documentação e recursos de ajuda;
d. Teste para sistema em tempo real (tarefa, comportamento,
intertarefa, sistema).
Além dos testes de caixa-preta e caixa-branca, temos padrões para teste

de software para descrição de soluções de problemas específicos de um projeto.
Descrevem geralmente problemas comuns de teste e soluções para auxiliar na
condução de outros métodos e técnicas de testes. Fornecem geralmente
diretrizes para o início das atividades de teste, além de fornecerem vocabulários
para solucionadores de problemas, atenção nas forças por trás de um problema
e estimular o pensamento iterativo. Por exemplo, temos o Teste de Cenário,
que descreve uma técnica para exercitarmos o software a partir do ponto de vista
dos usuários. Uma falha neste tipo de teste nos remete a problemas de requisitos
visíveis para o usuário.
Observando toda esta proposta de técnicas e padrões de testes,

parece-nos que a etapa de testes dentro do processo de desenvolvimento de
10
software é interminável. O que precisamos estar bem atentos é que não
conseguiremos utilizar todas as técnicas existentes. Precisamos aprender a
planejar nossos testes de tal forma que se adaptem de forma equilibrada um
bom plano e uma execução de testes, capaz de fazer com que atinjamos o nosso
principal objetivo: superar as expectativas de nossos usuários.
SOMMERVILLE, 2011
Saiba mais
https://www.youtube.com/watch?v=mDy2QV96Q1g
TEMA 2: TESTE PARA SOFTWARE ORIENTADO A OBJETOS
Muitas das técnicas que estudamos anteriormente se aplicam também a

software orientado a objetos, no entanto, para testarmos adequadamente um
sistema orientado a objetos, devemos ter em mente três questões importantes
(PRESSMAN, 2011):
1. A definição dos testes deve incluir técnicas de descoberta de erro

aplicadas à análise orientada a objetos e modelos de projeto.
2. A estratégia de teste de unidade e integração deve mudar
significativamente.
3. O projeto de casos de teste precisa considerar características especiais
do software orientado a objeto.
Segundo Pressman (2011):
A arquitetura do software orientado a objeto (OO) resulta em uma série

de subsistemas em camadas que encapsulam classes colaboradoras.
Cada um desses elementos de sistema (subsistemas e classes)
executa funções que ajudam a satisfazer os requisitos do sistema. É
necessário testar um sistema orientado a objeto em diversos níveis em
um esforço para descobrir erros que podem ocorrer à medida que as
11
classes colaboram uma com as outras e os subsistemas se comunicam
através das camadas da arquitetura.
Ao testarmos projetos orientados a objetos, teremos alguns itens

importantes a serem considerados:
1. Exatidão dos modelos de análise e projeto orientados a objetos

(OOA e OOD);
2. Consistência dos modelos OO;
3. Testarmos unidades em contexto OO;
4. Testarmos integração em contexto OO;
5. Validação em contexto OO.
Algumas técnicas, além de podermos aplicar testes de caixa-branca já

estudados anteriormente:
1. Teste baseado em falhas: satisfação dos requisitos começa no modelo

de requisitos e termina possíveis falhas no projeto ou código.
2. Testes de hierarquia de classe: teste da herança e derivação entre
as classes.
3. Teste baseado em cenário: auxilia com especificações incorretas,
interações entre subsistemas. Concentra-se no que o usuário faz no
software e detecta tarefas que os usuários precisam executar.
4. Teste aleatório para classes: observação do comportamento
mínimo de uma instanciação de uma classe seguindo um roteiro de
operações (métodos).
5. Teste de participação em nível de classe: Entradas e saídas
são classificadas e casos de testes são projetados para exercitar
cada categoria.
6. Caso de teste interclasse: testa a colaboração entre classes com base
nos cenários e testes comportamentais.
Como sempre, nosso objetivo é o encontro do maior número de erros com

um mínimo de esforço. Não foge do que estudamos para testes de software
12
convencionais. A visão dos testes deve incluir revisão de requisitos e modelo de
projeto, além dos testes de classes, individualmente e na colaboração e troca de
mensagens entre si. No caso de software OO, as Threads merecem uma
atenção especial, observando-se detalhes do projeto ao código das mesmas. O
teste com base em cenário é um dos tipos dominantes para validação de
sistemas orientados a objeto.
SOMMERVILLE, 2011
CAMPOS, 2016
Saiba mais
Alguns links interessantes que falam sobre gestão e garantia da qualidade:
www.asq.org/software
www.sei.cmu.edu
www.isospice.com
TEMA 3: TESTE PARA SOFTWARE NA WEB
Ao estudarmos técnicas de testes para software convencional e para

orientados a objetos, percebemos que há técnicas que podem ser utilizadas em
ambos os tipos de software. Com testes para software na Web não é diferente,
porém, se você assistiu os dois vídeos que nos falam sobre o que é Web e seu
histórico, você deve ter ficado exausto só em pensar em quantas coisas fazemos
hoje diariamente por esse meio. Para construirmos softwares baseados na Web
não é diferente.
As dimensões da qualidade para software na Web são altamente
relevantes e carece de muita observação (PRESSMAN, 2011):
1. Conteúdo: Avaliações devem ocorrer no nível sintático e semântico.
Ortografia, pontuação e gramática em documentos com base em texto
13
para ocorrências de sintaxe. Exatidão das informações, consistência e
ausência de ambiguidade no caso da semântica.
2. Função: para descobrirmos erros de falta de conformidade de requisitos,
instabilidade e inconformidade com padrões apropriados (Ajax, HTML).
3. Estrutura: extensibilidade a novos conteúdos e novas funcionalidades.
4. Usabilidade: facilidade de uso, sintaxe e semântica necessárias.
5. Navegabilidade: experimentação de links impróprios, errados, inativos ou
quaisquer outros erros de navegação.
6. Desempenho: cargas extremas devido à enorme quantidade de usuários
simultâneos.
7. Compatibilidade: adequação a servidores, ambientes, plataformas e
browsers.
8. Interoperabilidade: interface adequada para outras aplicações ou bases
de dados.
9. Segurança: investigação de vulnerabilidades potenciais.
A estratégia de testes para software Web pode considerar princípios básicos de

testes de software convencionais e orientados a objetos e seguir a seguinte
abordagem (PRESSMAN, 2011):
1. Revisão do modelo de conteúdo;

2. Revisão dos casos de uso;
3. Revisão da navegabilidade;
4. Testes de unidade;
5. Testes de navegação;
6. Testes de compatibilidade com ambientes e configurações diferentes;
7. Testes de segurança;
8. Testes de desempenho.
A Figura 7 ilustra uma ideia de planejamento de testes aplicada a software

para Web.
14
Figura 7: Planejamento de Testes para software Web

Um teste bastante importante em software para Web é para interface, pois
experimenta mecanismos de interação e valida aspectos estéticos da interface
de usuário. A Figura 8 nos demonstra todas as camadas de interação existentes
na interface Web.
Figura 8: Camadas de interação na Interface Web
15
Quando pensamos na interface, precisamos lembrar que há um conjunto
de elementos a serem testados:
1. Links
2. Formulários
3. Script no lado do cliente
4. HTML dinâmico
5. Janelas Pop-up
6. Scripts CGI
7. Conteúdo encadeado (streaming)
8. Cookies
9. Mecanismos de interface específicos do aplicativo
Ainda falando sobre interface, precisamos dar atenção aos testes de

usabilidade, acessibilidade e compatibilidade. Para usabilidade podemos
observar os itens importantes na Figura 9.
Figura 9: Fatores considerados em testes de usabilidade
Vimos que há um esforço bem pontual em relação à interface, pois essa

agrega muitas características e elementos importantes para um sistema na Web.
Mas além desta atenção, não podemos esquecer dos já falados testes de
16
desempenho (carga e estresse), segurança, configuração, testes do lado do
servidor e testes do lado do cliente.
SOMMERVILLE, 2011
CAMPOS, 2016
Saiba mais
Só para lembrarmos de todos os detalhes que são envolvidos na grande teia

mundial. Assista, é bem curtinho e muito legal:
https://www.youtube.com/watch?v=mDy2QV96Q1g
TEMA 4: TESTES DE SISTEMA
Com o crescente número de sistemas para Web, para vários tipos de

equipamentos móveis e embarcados e totalmente integrados, trocando
informações a todo instante, não há como deixarmos de falar sobre uma questão
importantíssima para nossos usuários, a segurança. Ações que prejudiquem
pessoas é o alvo mais comum para acessos impróprios e ilegais dos hackers.
Teste de sistema é na realidade uma série de diferentes testes cuja
finalidade primária é exercitar totalmente o sistema. Embora cada um
dos testes tenha uma finalidade diferente, todos funcionam no sentido
de verificar se os elementos do sistema foram integrados
adequadamente e executam as funções a eles alocadas.
(PRESMMAN, 2011).
A figura 10 representa alguns testes possíveis na adoção de testes

de sistema.
17
Figura 10: Testes de Sistema
Testes de
Recuperação
Testes de
Segurança
Testes de Testes por

Sistema Esforço
Testes de
Desempenho
Testes de
Disponibilização
A partir da Figura 10, vamos detalhar cada um dos testes citados

como importantes para agregar o planejamento de um teste de sistema
(Pressman, 2011):
1. Testes de Recuperação: falhas em equipamentos não são coisas

incomuns. Depois de tais situações, um sistema de computador deve ser
capaz de ser recuperado e retomar o processo em pouco ou nenhum
tempo de parada. Logo, sistemas devem ser tolerantes a falhas e que não
devem causar a paralisação total do sistema. Quando não é possível
tamanha agilidade, o período de tempo para retorno do sistema deve ser
determinado e previsto, caso contrário, poderemos ter sérios prejuízos,
geralmente financeiros.
“Teste de recuperação é um teste do sistema que força o software a falhar
de várias formas e verifica se a recuperação é executada corretamente.”
(PRESSMAN, 2011). A recuperação pode ser automática, então a
reinicialização, mecanismos de verificação, recuperação de dados devem
ser avaliados. Caso a recuperação precise de intervenção humana,
precisamos determinar o tempo médio de reparo e avaliá-lo se está dentro
de um limite aceitável.
18
2. Testes de Segurança: segurança é um tempo altamente relevante e
sério. Os ataques podem ser por diversão de harckers, funcionários
insatisfeitos que invadam por vingança, pessoas desonestas para ganhos
ilícitos. A realidade da segurança é muito variada e gera muitas dores de
cabeça aos profissionais de TI em geral. Esse tipo de teste tenta verificar
se mecanismos de proteção incorporados ao sistema de fato o protegerão
contra acessos indevidos. Durante este tipo de teste, os testadores devem
simular que estejam invadindo o sistema, e neste caso vale tudo! São
senhas obtidas por meios externos, ataques ao sistema personalizado
para romper defesas, sobrecarregar o sistema e, neste caso, o sistema
recusa acesso a outros, invasões durante a recuperação, exame de
dados que não estão em segurança ou até mesmo encontrar a chave de
entrada para o sistema. Um bom teste de segurança será capaz de invadir
o sistema e o papel do criador do sistema é tornar o custo da invasão
maior do que o valor das informações que poderiam ser obtidas.
3. Testes de Esforço: testes de esforço ou de estresse colocam programas

em situações anormais. O testador deve executar testes de esforço
perguntando até onde podemos forçar o sistema para que ele falhe?
Geralmente este teste demanda recursos em quantidade, frequência ou
volumes anormais. Testes que gerem dez interrupções por segundo,
quando uma ou duas é a média normal. A taxa de entrada de dados pode
ser aumentada de uma certa magnitude para determinar como as funções
de entrada respondem. Execução de casos de teste que causem
problemas de memória em um sistema operacional virtual. Casos de
testes que causem excessiva procura por dados residentes em disco. O
testador tentará quebrar o programa. Há uma variação deste tipo de teste
denominada teste de sensibilidade. Geralmente para software
matemático, um intervalo extremamente pequeno de dados, dentro de um
limite válido, pode causar um processamento extremo com erros e
profunda degradação do desempenho. Geralmente associado à
19
combinação de números para causar instabilidade ou processamento
inadequado.
4. Testes de Desempenho: São desenvolvidos para testar o desempenho

em tempo de execução do software dentro de um contexto de sistema
integrado. Feito em etapas e utilizando até mesmo o nível de unidade. O
desempenho individual pode ser avaliado durante os testes, porém o
verdadeiro desempenho só pode ser avaliado com o conjunto de todos os
elementos integrados no sistema. Geralmente são acoplados ao teste de
esforço e exigirão instrumentação de hardware e software.
É necessária a medição e, também, o monitoramento de intervalos de
execução, log de eventos para verificação dos estados da máquina
regularmente. Ao monitorar o sistema com instrumentos, poderemos
descobrir situações que levam à degradação e possível falha
do sistema.
5. Testes de Disponibilização: Operação do software em plataforma e

ambientes operacionais variados. Este teste também pode ser chamado
de configuração. Examina todos os procedimentos de instalação de
software especializado de instalação que podem ser utilizados pelos
clientes e toda a documentação usada pelos usuários finais. Por exemplo,
aplicativos disponibilizados em lojas para baixarmos em Linux, Mac OS,
Windows, Solaris ou até mesmo em equipamentos móveis. É importante
que testes de segurança sejam integrados aos testes de disponibilização,
devido à grande vulnerabilidade e possibilidades de falhas graças aos
diversos ambientes e plataformas a serem testados.
Testes de sistemas não devem ser deixados de lado e nem tão pouco
subestimados. A questão de segurança dos dados e disponibilidade do sistema
são essenciais para as organizações que possuem software utilizado por muitos
usuários em todo o Mundo.
20
PRESSMAN, 2011 – Páginas 473 a 488.
Saiba mais
Existem muitas ferramentas para o planejamento e gerenciamento de testes.

Ferramentas auxiliam a equipe de software no planejamento da estratégia de testes
escolhida e o gerenciamento do processo de teste enquanto ele é executado. Link
para algumas delas:
www.testmanagement.com
www.compuware.com/
www.opensourcetesting.org
https://www.devexpress.com
http://ww3.qualitylabs.org/
http://www.bug-tracking.info/
http://www.methodsandtools.com/
TROCANDO IDEIAS
Que tal você navegar no link <www.opensourcetesting.org> e verificar a

infinidade de ferramentas para automação de testes de
software? Tente identificar o quanto elas automatizam seus processos de
testes e como poderiam ser utilizadas no dia a dia. Tente baixar uma delas,
talvez alguma ferramenta para HTML, e veja o esforço necessário para que
você planeje e execute algum tipo de teste em uma página Web! Vamos
tentar?
21
SÍNTESE
Estudamos até aqui sobre elementos importantes para testarmos software

de acordo com alguns tipos de ambientes e plataformas, inclusive pensando na
integração do sistema. Sabemos que o teste de software absorve uma grande
gama do esforço técnico dentro da concepção e do desenvolvimento de
software. Porém, uma estratégia de planejamento, execução e controle, mesmo
que pequenos, conseguirão nos auxiliar a eliminar erros, defeitos e falhas mais
grotescos de um software.
Em um software convencional, o objetivo é atingido por meio de uma série
de passos de teste. Testes de unidade e de integração são responsáveis pela
verificação funcional dentro da arquitetura do software. Os testes de validação
auxiliarão na rastreabilidade do software. Cada um dos testes utilizará técnicas
e ferramentas auxiliando o projeto de casos de testes.
Quando falamos em software orientado a objetos, precisamos utilizar
testes que exercitem operações dentro de uma classe e depois na sequência de
execução para integração. Conjuntos de classes respondem a uma entrada ou
evento em sequência. Testes com base em uso demonstrarão como as classes
estão colaborando entre si.
Testes para sistemas para Web são projetados para exercitar conteúdo,
funcionalidade, interface, navegação, desempenho e segurança. O esforço de
teste para sistemas web é grande, porém, os resultados são excelentes, visto
que uma invasão ou uma utilização simultânea não esperada poderiam causar
catástrofes ao sistema.
REFERÊNCIA
22



23
AULA 5
1
CONVERSA INICIAL
Olá, seja bem-vindo. Assista ao quinto vídeo da professora Maristela

CONTEXTUALIZANDO
O conteúdo de qualidade de software é bastante abrangente. Já falamos

sobre questões relacionadas à gestão da qualidade, à garantia da qualidade e
descemos a níveis de definições sobre erros, defeitos e falhas possíveis em um
software ou em seu projeto, bem como estudamos as diferenças cruciais entre
revisões, inspeções, verificações e validações de software.
Discorremos ainda sobre questões de normas, sua importância para
auxiliar-nos em nossos planos de testes. Vamos conversar agora um pouco
sobre documentação de nossos planos e execuções de testes. Como podemos
documentar, de forma suficiente, todo o nosso trabalho, cuja finalidade é garantir
a tão sonhada expectativa de nosso cliente?
Para relembrar, padrões são importantes por várias razões, entre elas
(SOMMERVILLE, 2011):
1. Capturar conhecimento da organização.

2. Fornecer um framework para definição do significado de qualidade para a
organização.
3. Ajudar na continuidade dos trabalhos realizados por um profissional e
continuado por outro.
4. Padrões de produto aplicam-se a produto de software que está em
desenvolvimento. (Documentação).
5. Padrões de processo que os definem para serem seguidos durante todo
o processo de desenvolvimento de software. É importante que
encapsulem as boas práticas de desenvolvimento.
2
Estes padrões são construídos e mantidos por várias instituições, entre
elas: ANSI, IEEE e W3C. Já estudamos alguns detalhes da ISO 9001 em outro
encontro, porém vamos trabalhar neste momento a IEEE 829-2008, uma norma
adequada aos padrões do PMI para gerência de projetos. Nosso objetivo agora
é trabalhar questões relacionadas à documentação, porém, vamos relembrar
como seria um planejamento da garantia de qualidade fornecida pela ISO 9001,
conforme a Figura 1.
Figura 1: Planejamento da Garantia da Qualidade
Uma característica forte da ISO 9001 é a criação da documentação de

todos os processos capturados para cada projeto de desenvolvimento de
software. Com a IEEE 829-2008 não é diferente, porém, ela se preocupa com a
documentação de todo o processo de testes. Ela nos orienta sobre a construção
de documentos de testes que padronizam e direcionam nossos testes de
software. Padronização de documentos é um item importante se quisermos
ganhar produtividade e eficácia em nossas atividades de testes.
Essa norma abrange um conjunto de documentos padronizados para
organizar o planejamento, a especificação e os relatórios de testes. Um ciclo
básico de sua atuação pode ser visualizado na Figura 2.
3
Figura 2: Ciclo de vida do projeto de teste de software
Planejar Projetar Executar Analisar

Testes Testes Testes Resultado
s
Gerenciar
Defeitos
Os documentos previstos nessa norma são aderentes a qualquer tipo de

ciclo de vida de desenvolvimento de software que você venha a utilizar, inclusive
métodos ágeis.
Geramos então nosso plano de testes, documento básico de
planejamento, que nos designará o escopo de referência durante a execução do
teste, além de ser utilizado como documento de comunicação com o cliente
(RIOS, 2008). Algumas organizações adotam a elaboração de um documento de
Estratégia de Teste também. E esta estratégia deverá estar contida em nosso
plano de testes. Algumas nomenclaturas são importantes na construção desse
nosso plano de testes, entre elas a consideração do nível de integridade que
cada componente de nosso software representa para nossos usuários.
Por exemplo:
Nível Descrição da consequência da falha ou defeito

4 - Catastrófico Perdas de vidas, falha completa da missão projetada, grandes
perdas da segurança do software, perdas financeiras e sociais.
4
3 - Crítico Danos permanentes em pessoas, falha parcial na missão,
impactos financeiros ou econômicos para organização de grau
extenso, danos sociais extensos.
2 - Marginal Injúrias causadas a pessoas, degradação secundária da
missão, perdas financeiras ou sociais moderadas.
1 - Desprezível Consequências desprezíveis em todos os níveis.
Outra classificação importante é sobre os atributos de qualidade:

1. Complexidade
2. Risco
3. Segurança
4. Integridade dos dados
5. Desempenho ou performance.
Quanto à integridade do software, a tabela abaixo relaciona em quatro

níveis (RIOS, 2008):
Nível Descrição
4 O software necessita funcionar corretamente, caso contrário graves
consequências ocorrerão (vidas, danos ambientais, perdas financeiras,
econômicas). Plano de mitigação deve ser executado.
3 O software deve funcionar corretamente ou os resultados não serão
alcançados, causando sérias consequências. Plano de mitigação parcial
ou integral é aplicado.
2 O software deve funcionar corretamente ou os resultados devem ser os
esperados, caso contrário teremos consequências pequenas. Plano de
mitigação parcial é executado.
1 O software necessita funcionar corretamente e seus resultados
alcançados, teremos consequências desprezíveis. Plano de mitigação
desnecessário.
5
Estas são algumas questões abordadas pela norma para que possamos
iniciar nosso plano e projeto de testes e obtermos resultados objetivos e factíveis
de medição.
SOMMERVILLE, 2011
Pesquise
Busque mais informações sobre normas e padrões que possam auxiliar
tanto na elaboração de um bom plano de testes quanto de sua documentação.
Avalie e compare características em comum destas normas.
TEMA 1: PROJETO DE TESTES
Após todo o levantamento e criação de nosso plano de testes, a próxima

fase chama-se projeto de teste. E este projeto deve ser documentado. Para isso,
teremos a IEEE 928-2008 como base para nosso projeto. Um dos propósitos do
documento de Projeto de Teste é abordar o refinamento dos testes do Plano de
testes para identificação dos requisitos e funcionalidades que deverão ser
testadas e quais os tipos de testes que adotaremos. Muitas vezes, você pode já
preparar esta documentação em conjunto com a documentação do plano de
testes. Quando falamos de um projeto maior, sempre é importante termos as
duas documentações separadas, pois conseguiremos controlar melhor os
artefatos gerados pelos testes.
Um bom Projeto de Testes deveria conter os seguintes itens, segundo a

IEEE 928-2008 (RIOS, 2008):
1. Introdução
a. Identificador
b. Escopo
c. Referências
6
2. Detalhes deste nível de Projeto
a. Funcionalidades (features) a serem testadas
b. Abordagem refinada
c. Casos de Teste com identificação
d. Critérios de passagem e falha por funcionalidades
e. Entregáveis
3. Geral
a. Glossário
b. Procedimentos de alterações do documento e histórico
de alterações.
Casos de Teste
Segundo Rios (2008):
Uma unidade de teste que será executada pelo testador, seja
manualmente ou automaticamente. Esse é constituído pelos seguintes
campos:
1. Introdução
a. Identificador do documento
b. Escopo
c. Referências
d. Contexto
e. Notas para descrição
2. Detalhes para cada caso de teste
a. Identificador do caso de teste
b. Objetivos
c. Especificações de entrada
d. Especificações de saída
e. Necessidades de ambiente
f. Requisitos ou procedimentos especiais
g. Dependências entre casos de teste
3. Global
a. Glossário
b. Procedimentos de alterações do documento e histórico de
alterações.
7
Exemplo de um Caso de Teste:
Caso de teste: Login e Senha válidos
Fonte: Rios, 2008.
Procedimentos de Teste
Especificação dos passos necessários para execução de um grupo de
casos de teste. Algumas empresas possuem uma terminologia Roteiro de Teste
para definição de cada grupo. Esse é constituído pelos seguintes campos:
1. Introdução
b. Escopo
c. Referências
8
d. Relações com outros documentos e procedimentos
2. Detalhes
a. Entradas, saídas e requisitos especiais
b. Ordem para execução dos casos de teste
3. Global
a. Glossário
b. Procedimentos de alterações do documento e histórico de
alterações.
Estes são alguns artefatos e elementos importantes para documentação

do planejamento e projeto de nossos testes de software. Estudaremos na
sequência relatórios gerados através da aplicação de nossos planos de testes.
SOMMERVILLE, 2011
TEMA 2: RELATÓRIOS DE TESTES
Em continuidade à nossa documentação do plano e projeto de testes,

teremos a documentação dos relatórios que nos auxiliarão na garantia da
qualidade de nossos testes. Teremos um conjunto de vários relatórios que nos
apoiarão em cada fase de testes, bem como no acompanhamento da evolução
da qualidade do processo e do software em si.
Iniciaremos pelo Relatório de Log. Esse relatório fornece um registro
cronológico das ocorrências de todo o processo de execução de testes. É muito
importante o registro de “Quem” fez “O quê” e “Quando”!
Relatório de Log
1. Introdução
b. Escopo
c. Referências
9
2. Detalhes
a. Descrição
b. Descrição da execução
c. Resultados
d. Informações sobre o ambiente
e. Eventos anormais
f. Qualquer situação que causou interrupção do teste
g. Entradas das atividades e eventos
3. Global
a. Glossário
Na sequência, temos o relatório de anomalias. Em algumas empresas,

essa documentação tem o nome de Relatório de Defeitos. Muitas vezes são
utilizadas ferramentas de automação para registro dos defeitos.
Relatório de Anomalias
1. Introdução
b. Escopo
c. Referências
2. Detalhes
a. Sumário
b. Data da anomalia
c. Contexto
d. Descrição da anomalia
e. Descrição da execução
f. Resultados
g. Informações sobre o ambiente
h. Eventos anormais
i. Qualquer situação que causou interrupção do teste
10
3. Global
a. Procedimentos de alterações do documento e histórico das
alterações
O próximo relatório serve como registro para monitoramento do projeto de

teste. Utilizado nas reuniões periódicas por meio do Plano de Teste.
Relatório de Estado
1. Introdução
b. Escopo
c. Referências
2. Detalhes
a. Sumário
b. Alterações do planejado
c. Métricas de estado do teste
3. Global
a. Procedimentos de alterações do documento e histórico
das alterações
Há um relatório de nível de teste que será feito para cada tipo de teste
adotado em nosso plano, tais como teste de unidade, teste de integração, teste
de sistema e teste de aceitação.
Relatório de Nível de Teste
1. Introdução
b. Escopo
c. Referências
2. Detalhes
a. Visão geral dos resultados do teste
b. Resultados detalhados do teste
11
c. Racional das decisões
d. Conclusões e recomendações
3. Global
a. Glossário
das alterações
Para finalizarmos, temos o relatório Máster de Teste, cujo objetivo é fazer

um resumo dos relatórios de nível de teste. Teremos dados sintetizados para
conseguirmos gerar nossas métricas para acompanhamento e avaliação da
evolução da qualidade de nossos testes.
Relatório Máster de Teste
1. Introdução
b. Escopo
c. Referências
2. Detalhes
a. Visão geral dos resultados do teste
b. Resultados detalhados do teste
c. Racional das decisões
d. Conclusões e recomendações
3. Global
a. Glossário
das alterações
Poderíamos resumir as etapas do ciclo de vida de projeto de testes com

seus diversos relatórios conforme a tabela abaixo:
12
Etapas do ciclo de vida Documentos produzidos
Planejar Teste Plano Máster de Teste
Plano de teste
Projetar Teste Projeto de Teste
Casos de Teste
Procedimentos de Teste
Relatório de Passagem de Itens de Teste
Executar Teste Script de Teste
Relatório de Estado de Teste
Relatório de Anomalias
Relatório de Log de Teste
Gerenciar Defeitos Relatório de Incidentes
Relatório de Log de Teste
Analisar Resultados Relatórios de Teste (Sumário)
Relatório Máster de Teste
Para cada fase do projeto de testes, possuímos categorizações

profissionais responsáveis, tais como líder de projeto, analistas de teste
e testadores.
Estas são práticas e modelos de relatórios descritos em nossa norma IEEE 298-
2008. Elas devem sempre serem adaptadas, de acordo com nossos objetivos
finais, bem como com o quanto estamos dispostos a investir em tempo e dinheiro
em projetos de testes de software.
SOMMERVILLE, 2011
TEMA 3: MÉTRICAS DE TESTES
A medição é um elemento-chave para o bom acompanhamento da

evolução e implantação de melhorias, seja no processo de desenvolvimento ou
testes de software.
Medição é o processo pelo qual números ou símbolos são anexados
aos atributos de entidades no mundo real para defini-los de acordo com
13
regras claramente estabelecidas. Nas ciências, físicas, medicina,
economia e mais recentemente nas ciências sociais, podemos medir
os atributos antes considerados incomensuráveis. É claro que essas
medidas não são tão refinadas como muitas feitas nas ciências físicas,
mas existe [e são tomadas decisões importantes com base nelas].
Percebemos que a obrigação de tentar ‘medir o incomensurável’ para
melhorar nossa compreensão de entidades particulares é tão poderosa
na engenharia de software quanto em qualquer outra disciplina.
(PRESSMAN, 2011).
Muitos são os que garantem que software é incomensurável e que

tentativas de medições devem ser adiadas.
Temos as métricas para o desenvolvimento de software, que envolverá
questões relacionadas ao código-fonte, classes, objetos, requisitos, arquitetura
de software, entre outros, e há métricas focadas nos testes de software. Iremos
trabalhar em métricas que são base para análise, projeto e código para condução
dos projetos e execução dos casos de testes. Por exemplo, testes de integração
são apoiadas por métricas dos projetos de arquitetura. Testes de caminho básico
dependem de métricas de complexidade ciclomática, por nível de componente.
Em geral, as métricas de teste possuem duas classificações

(PRESSMAN, 2011):
1. Métricas de previsão do número provável de testes necessários em vários
níveis de testes; e
2. Métricas que focalizam a abrangência do teste para determinado
componente.
Tipos de Métricas aplicadas a Testes de Software:
1. Métricas de Halstead: estas métricas correspondem ao percentual de

trabalho de teste geral a ser alocado a um módulo k que pode ser
estimado utilizando-se a seguinte relação:
a. Porcentagem de trabalho de teste (k)= e(k)/Σe(i), em que
E=V/PL
14
PL=1/(n1/2)*(N2/n2)
sendo V= volume de programa e PL=nível.

A somatória é de todos os módulos do sistema
(PRESSMAN, 2011).
2. Métricas para teste OO: elas indicam de forma geral, o trabalho de

teste necessário para que o sistema OO seja exercitado. Lembrando
que encapsulamento e herança são dois aspectos importantes para
esta métrica.
a. Falta de coesão com métodos (LCOM): neste caso, quanto maior
for o LCOM, mais estados precisaremos testar.
b. Porcentagem pública e protegida (PAP): relacionada aos atributos
públicos que herdam de outras classes e visíveis. Os atributos
protegidos são acessíveis por métodos em suas subclasses. Tal
métrica traz um percentual de atributos públicos ou protegidos e
altos valores de PAP aumentam a probabilidade de efeitos
colaterais entre classes, isso porque os atributos possuem um alto
grau de acoplamento.
c. Acesso público a membros de dados (PAD): é a indicação do
número de classes ou métodos que acessam atributos de outra
classe e, com isso, violando o encapsulamento. Valores elevados
de PAD geram efeitos colaterais entre classes.
d. Número de classes-raiz (NOR): quantidade de hierarquias distintas
de classe descritas no modelo de um projeto. Estes testes devem
ser desenvolvidos em conjuntos de testes para cada classe-raiz
além de sua hierarquia correspondente. Um alto número de NOR
corresponde a um grande trabalho de teste. (PRESSMAN, 2011)
15
Há também métricas para manutenção, que não deixariam de incluir
testes, pois a manutenção prevê o acerto/correção de problemas identificados
na operação de um sistema existente.
Vimos então que as duas principais métricas para testes de software

fornecem uma variedade de métricas que podem ser usadas para avaliar a
qualidade do programa. Observamos também que ainda há poucas métricas e
pouco uso de métricas para testes e manutenção de software, porém muitas
outras orientadas, em especial para software orientado a objetos e que tenham
sido propostas para avaliação da testabilidade de sistemas OO.
SOMMERVILLE, 2011
TEMA 4: MÉTRICAS DE QUALIDADE DE SOFTWARE
Métricas para erros de produto por ponto de função, erros descobertos

por horas de revisão e erros descobertos por horas de teste proporcionam
informações sobre a eficácia de cada atividade sugerida pela métrica de
qualidade do processo de desenvolvimento e testes de software
(PRESSMAN, 2011). Vamos tratar agora de alguns indicadores muito úteis para
nossas equipes de projeto:
1. Correção: cada programa precisa operar corretamente ou terá pouca ou

nenhuma utilidade para seus usuários. A medida mais comum para
exatidão é o número de defeitos por KLOC, no qual um defeito é definido
como uma ocorrência de falta de conformidade com os requisitos. Os
defeitos são contados durante um período de tempo padrão, que pode ser
de um ano, um semestre, dependendo do tamanho do projeto.
2. Manutenibilidade: o esforço para manutenção geralmente é alto e
custoso. Este indicador nos relata se o programa é fácil ou não de ser
corrigido, se esse é adaptado a mudanças de ambiente, solicitações de
16
melhorias pelo cliente ou alterações nos requisitos. A métrica funciona
orientada ao tempo médio de alteração (mean-time-to-change - MTTC).
Quanto mais baixo o MTTC, mais fáceis de manutenção são
os programas.
3. Integridade: este item se tornou, nos últimos anos, cada vez mais
importante, em especial no que tange a questões de segurança (hackers,
terroristas). Ele mede a habilidade de um sistema em resistir a ataques,
que podem ser feitos por programas, dados ou documentos. Para
medirmos a integridade precisamos definir atributos de ameaça e
segurança. Ameaça corresponde à probabilidade de ataque em um
intervalo de tempo. Segurança é a probabilidade de um ataque ser
repelido. Integridade = Σ[1-(ameaça*(1-segurança))].
4. Usabilidade: A usabilidade é uma tentativa de quantificação da facilidade

de uso e pode ser medida em termos das características já revisadas nos
testes de usabilidade.
Além desses indicadores, podemos também trabalhar a eficiência na

remoção de defeitos. Essa métrica traz benefícios para o projeto e nos diz o
quanto o processo é eficiente na remoção de defeitos (DRE).
DRE=E/(E+D), sendo que E é o número de erros encontrados antes que o

software seja implantado, e D é o número de defeitos depois do
sistema entregue.
A triste realidade é que a maioria avassaladora de desenvolvedores de

software não mede nada! Infelizmente porque há pouca vontade de começar ou
até mesmo problemas de falta de pessoas na equipe e de investimentos
financeiros. Métricas podem parecer, à primeira vista, algo que traga mais
trabalho, gere relatórios, gere análises e mais reuniões. Porém, quando falamos
de um projeto de médio a grande porte, ganharemos muito em resultados, tanto
na melhoria dos processos quanto nos resultados de testes do software.
17
SOMMERVILLE, 2011
CAMPOS, 2016
TEMA 5: MELHORIA NO PROCESSO DE SOFTWARE
É interessante pensar que embora estejamos chegando na segunda

década do século 21, muitas grandes organizações ainda precisam “fazer
acontecer a engenharia de software.” (PRESSMAN, 2011).
O termo melhoria do processo de software (SPI) pode ser considerado
uma estratégia que transforma a abordagem existente para o desenvolvimento
de software, considerando que este seja mais confiável nos quesitos qualidade,
prazo e entrega.
Toda SPI deve considerar um retorno de investimento. É possível a
redução considerável de problemas em um software. Pode ainda contribuir para
a garantia da diminuição do número de defeitos e volume de retrabalho causados
por problemas de qualidade, além dos custos de manutenção, suporte do
software e outros custos indiretos que acontecem na entrega de um software
com atraso. (PRESSMAN, 2011).
A estrutura da SPI avalia a maturidade do processo de software e
incorpora uma série de indicadores de qualidade de processo, que conduzirá o
software à qualidade desejada.
Temos a CMMI (Capability Maturity Model), segundo Pressman (2011):
[...] que é um modelo de maturidade aplicado no contexto de uma

estrutura SPI. Ela possui cinco níveis: 5-Otimizado, 4-Controlado, 3-
Definido, 2- Reproduzível e 1-Inicial. Geralmente o que encontramos
nas organizações são considerados níveis de imaturidade e
catalogados da seguinte forma: 0-Negligente, 1-Obstrutivo, 2-
Arrogante e 3-Sabotador. Todos falam da negligencia, do descrédito
consciente de esforços de melhoria do processo de software. Falta de
incentivo e mal desempenho.
18
Educação e treinamento também são itens que beneficiam nosso
ambiente de desenvolvimento de software. Percepções incorretas de processos
e práticas conduzem a decisões inadequadas, acarretando resultados não
desejados. Compreensão de conceitos, métodos genéricos, tecnologias,
ferramentas específicas e outros tópicos relacionados à qualidade não são
uma questão de conteúdo, mas de aprimoramento da consciência coletiva para
o uso destas, buscando alcançarmos melhores resultados em nossos processos
e produtos.
Mensuração indica que estamos trabalhando com fatores qualitativos e
quantitativos. Queremos resultados subjetivos, mas para isto precisamos apurar
nossos números e percentuais que indicam o quanto estamos evoluindo e
acertando.
Além da CMMI, podemos considerar outras estruturas de SPI, tais como
(PRESSMAN, 2011):
1. SPICE: iniciativa internacional para suporte a avaliação de
processo da ISO e outros padrões relacionados ao ciclo de vida.
2. ISO/IEC 15504: para avaliação de processo.
3. Bootstrap: para organizações de pequeno e médio porte em
conformidade com SPICE.
4. PSP e TSP: processo em detalhes para medição em processos
de desenvolvimento de software.
5. TickIT: método de auditoria para conformidade com ISO
9001:2000.
Maturidade no processo de desenvolvimento de software, bem como dos

testes de software, são questões relacionadas a indicadores que proporcionam
uma sensação qualitativa sobre a eficiência relativa do processo em uso.
Melhoria de nossos processos requer educação e treinamento de nossa equipe.
Todos devem abraçar a nova forma de pensar e desenvolver software.
TROCANDO IDEIAS
Fórum: Se você atua na área de TI ou tem algum tipo de relacionamento com
pessoas que já atuam, tente trocar ideias de como a área de testes,
documentações e métricas de testes são observadas nas organizações que você
19
conheça. Caso você não tenha experiência ou não tenha contato direto, tente
pesquisar na internet o quão explorado e praticado é este tema.
SÍNTESE
Garantir que a documentação de testes, o planejamento, a execução e

seu controle sejam feitos de tal forma que consigamos extrair os melhores
resultados possíveis ainda nos parece algo inatingível. Claro que não é irreal,
porém, ainda são poucas as empresas que se preocupam ou dispõem de
recursos para investir em uma questão tão vital para nosso processo e software
com defeito zero! Além das divergências de opiniões, em especial por conta do
paradigma das metodologias ágeis, que prezam pela minimização de
documentos e modelos.
Vimos que podemos assegurar, por meio de métricas, ganhos e
evoluções dos nossos projetos de testes de software. Elas existem tanto para o
desenvolvimento quanto para os testes, porém são ainda desconsideradas, ou
por falta de recursos ou por falta de interesse.
Por mais que evoluamos na engenharia de software, nossa área carece
de maior utilização de modelos, técnicas e ferramentas que auxiliem,
automatizem e gerem estatísticas de evolução de nossos serviços e produtos.
Tão parecida com a área de TI como um todo. Precisamos tornar nosso
desenvolvimento e nossos testes mais mensuráveis possível. Assim
conseguiremos atacar diretamente aquilo que nos torna mais vulneráveis
durante todo o processo de engenharia de software.
REFERÊNCIA

20
RIOS, E. Documentação de teste de software. 2. Ed. Iteste: Instituto de teste de
software. 2008.




21
AULA 6
1
CONVERSA INICIAL
Olá, seja bem-vindo. Assista ao sexto vídeo da professora Maristela
CONTEXTUALIZANDO
Ao percorrermos os caminhos da gestão e garantia da qualidade no
desenvolvimento de software, percebemos que há uma concentração bastante
grande na área de testes, sejam eles inspeções, revisões, validações ou
verificações. Vimos que há divergências de opiniões, pois quando olhamos
profundamente para a área de qualidade total, percebemos que não
conseguimos escapar dos inúmeros documentos, auditorias, controles e
estatísticas, porém, encontramos um manifesto em prol de metodologias ágeis
para garantir menos papel e mais produtividade. Parece-nos antagônico então
pensarmos em qualidade versus agilidade! Observando essas variadas formas
de se pensar produtividade e qualidade em processos de desenvolvimento de
software, vamos focar em melhoria contínua, tentando agregar conceitos mais
conservadores (documentais e grande número de recursos humanos e
financeiros), bem como para equipes mais ágeis (com poucos recursos e
focadas num bom custo com um bom prazo de entrega)!
Assim iniciamos falando sobre o que seria melhoria contínua. E esse
termo não surge na área de informática, assim como o termo qualidade não é
proveniente desta. A melhoria contínua tem origem na Terra do Sol Nascente
(Japão), e o termo original para isso é KAIZEN. Kaizen agrega um significado de
“melhoria contínua nos âmbitos do trabalho, família, pessoal e social.” (ADAMI,
2016). O grande propósito do Kaizen consiste no aprimoramento diário e
constante de nossas atividades (profissionais ou pessoais) para aumento da
produtividade, poupando tempo, recursos, esforços, bem como humanizando as
relações.
Para a administração, a expressão refere-se a uma filosofia de vida e não
simplesmente a um conjunto de ferramentas. Para Costa Junior (2012), Kaizen
2
é “um processo de aprimoramento contínuo, que consiste na busca de melhorias
pela inovação dos processos produtivos, dos métodos, dos produtos, das regras
e dos procedimentos.” Ele procura eliminar problemas por meio da identificação
de ideias de melhoria, com a participação de todos na resolução dos mesmos.
Não teremos apenas indicadores de performance,
mas mediremos a taxa de melhoramentos, aplicando ações de
melhoria e implementações em um determinado período de tempo
(COSTA JUNIOR, 2012).
Ao aplicarmos a ideia do Kaizen, desejamos alguns dos seguintes
resultados (COSTA JUNIOR, 2012):
 Melhorias nos processos produtivos;
 Adaptação ou adequação dos postos de trabalho, das
máquinas e dos equipamentos;
 Adequação dos métodos de trabalho;
 Redução de desperdícios em processos;
 Capacitação e envolvimento dos colaboradores;
 Aumento de produtividade.
É interessante notarmos que o Kaizen possui alguns princípios básicos:
1. Abandono de ideias fixas e rejeição do estado atual das coisas;

2. Não explicar o que não se pode fazer, mas refletir sobre como fazer;
3. Acatar e utilizar de imediato boas ideias para alcançarmos as melhorias;
4. Não conseguiremos a perfeição, mas 60% já é um ótimo resultado;
5. Correção dos erros de imediato e no local;
6. Dificuldades devem ser encaradas como desafios;
7. Procurar causas reais para solução perfeita;
8. Experimentar e validar; e
9. Melhorias são infinitas.
Nosso esforço nessa aula será buscar e mostrar ideias e alternativas para
conseguirmos exercitar a filosofia do Kaizen, demonstrando que é possível
3
aplicarmos engenharia de software e qualidade de software, mesmo que com o
mínimo de documentação, observando que nosso alvo será sempre superar as
expectativas de nossos usuários!
Pesquise
Percebemos que melhoria contínua tem origem no Japão. Várias
ferramentas, técnicas, filosofias que foram incorporadas à Teoria Geral da
Administração possuem origem em estudos e experimentos japoneses. Busque
dentro da Engenharia de Software, ou mais precisamente dentro da área de
qualidade de software visualizar outras técnicas, ferramentas ou métodos que
possam ter origem nessas filosofias de produtividade. Vamos refletir e analisar
o quanto podemos melhorar em nossa produtividade e em serviços e processos
com mais qualidade.
TEMA 1: CMMI
Dentro das estratégias de melhoria contínua, a ideia da CMMI é

interessante, pois transforma todo o processo de desenvolvimento de software
em um ambiente controlado e com alta excelência nas definições e execuções
dos processos.
Originalmente, CMM (Capability Maturity Model) foi desenvolvida pelo

Instituto de Engenharia de Software na década de 1990 como uma estrutura da
SPI (Melhoria do Processo de Software). Evoluiu então para CMMI como um
metamodelo de processo abrangente e qualificado para colaborar com a
maturidade do processo de desenvolvimento de software. Esse metamodelo
representa o processo de duas maneiras diferentes: modelo contínuo e
encenado. Descreve um processo em duas dimensões (Figura 1).
4
Figura 1: Dimensões do metamodelo CMMI
Ele possui uma série de níveis, que são devidamente avaliados por
profissionais especializados pelo Instituto de Engenharia de Software
(CMM07 apud PRESSMAN, 2011):
Nível 0: Incompleto – a área de processo (por exemplo,

gerenciamento de requisitos) não funciona ou não atinge todas as
metas e objetivos definidos pela CMMI para a capacidade nível 1 para
a área de processo.
Nível 1: Executado – todas as metas específicas da área de processo

(definida pela CMMI foram satisfeitas. Estão sendo executadas as
tarefas necessárias par produzir os artefatos definidos.
Nível 2: Controlada – todos os critérios do nível de capacidade 1

foram satisfeitos. Além disso, todo o trabalho associado com a área de
processo está de acordo com uma política definida em termos de
organização; todas as pessoas que estão fazendo o trabalho têm
acesso a recursos adequados para executar o trabalho; os
interessados são envolvidos ativamente na área de processo conforme
necessário; todas as tarefas e produtos são monitorados, controlados
e revisados; e são avaliados quanto à conformidade com a descrição
de processo. (CMM07).
5
Nível 3: Definido – todos os critérios do nível de capacidade 2 foram
satisfeitos. Além disso, o processo é adaptado com base no conjunto
de processos padronizados da organização de acordo com as regras
de adaptação da organização, e dos produtos acabados, medidas e
outras informações de melhoria de processo para agregar valores ao
processo organizacional (CMM07).
Nível 4: Controlado quantitativamente – todos os critérios do nível

de capacidade 3 foram satisfeitos. Além disso, a área de processo é
controlada e melhorada usando medição e avalição quantitativa. São
estabelecidos objetivos quantitativos para qualidade e desempenho de
processo e utilizados como critérios no controle do processo. (CMM07).
Nível 5: Otimizado – todos os critérios do nível de capacidade 4 foram

satisfeitos. Além disso, a área de processo é adaptada e otimizada
usando meios quantitativos (estatísticos) para atender à mudança de
necessidades do cliente e melhorar continuamente a eficiência da área
de processo em consideração.
A CMMI define cada área de processo em termos de metas específicas e

as práticas específicas para que as metas sejam atingidas. Práticas específicas
são refinamentos de uma meta, que são transformadas em uma série de
atividades relacionadas ao processo. (PRESSMAN, 2011).
A Figura 2 ilustra as áreas de processo, necessárias para cada nível de
maturidade da CMMI.
6
Figura 2: Áreas de Processo da CMMI
Com a implantação da CMMI em uma empresa que desenvolva software,

certamente atingiremos muitos dos níveis desejados em termos de qualidade
dos processos e dos produtos finais. E isso não sairá barato. Envolverá muito
recurso humano e de capital, porém, dependendo do tamanha da empresa, o
retorno disso virá a médio e longo prazo, com a conquista de maiores e melhores
clientes que prezam pela excelência na prestação de serviços e produção de
software.
SOMMERVILLE, 2011
7
TEMA 2: KANBAN
O método Kanban, aplicado ao desenvolvimento de software, percorre a
ideia de não sobrecarregar a equipe de criação do software. Contém princípios
básicos que consideram que a equipe deve iniciar uma nova tarefa quando é
capaz de realizá-la. Deve aceitar mudanças incrementais e evolutivas
estimuladas pelo método Kanban, respeitando os atuais processos, papéis
e responsabilidades. Mas o que é Kanban e no que ele poderá nos auxiliar na
garantia da qualidade de processo e de software?
“Kanban é uma palavra japonesa que significa ‘cartão ou cartaz’, que pode ser
utilizada como cartão ou carta Kanban e tem a finalidade de representar um
sinal.” (COSTA JUNIOR, 2012).
Ainda segundo Costa Junior (2012):
Kanban é uma ferramenta de informação que auxilia a fabricação

correta de produtos, nas quantidades corretas e no tempo correto, em
todos os estágios da produção. Por isso, constitui-se em um sistema
físico de controle da movimentação de materiais ou de contêiner, que
se faz como o uso de cartões.
Uma das grandes vantagens da utilização de Kanban fica por conta de

suas características de fácil gerenciamento das ordens de produção, fácil
compreensão por toda a organização e baixo custo de implementação. Além
claro, da rapidez nas tomadas de decisões e autonomia nas decisões pelo
sequenciamento das ordens de produção.
Como cita Costa Junior (2012), basicamente a ferramenta é composta por
1. Fila de espera (sequenciador da produção);

2. Quadro Kanban (gerenciamento das ordens);
3. Padronização dos contêineres (cartões);
Parece simples? Sim, e é bastante simples, por isso a ideia da junção de

Kanban a processos de desenvolvimento de software ágeis.
8
O Kanban, na área de TI, torna-se digital, mas o conceito de quadro e
cartões continuam os mesmos. Algumas empresas preferem até adotar a forma
física, pois a visualização em painéis, tabuleiros, lousas e paredes cria uma
sensação de movimento e evolução do processo. Um dos pontos importantes do
Kanban aplicado para garantia da qualidade encontra-se na busca pela
maturidade da produção. Isso é fundamental para a equipe que busca aprender
a construir código de alta qualidade e equilíbrio no trabalho em andamento para
cumprimento de metas e prazos. Aqui a qualidade está atrelada à velocidade no
nível de produção, no desempenho da equipe e na
eliminação de retrabalhos. A figura 3 nos exemplifica um modelo de sinalizador
visual Kanba.
Figura 3: Sinalizador visual Kanban
Fonte: Mariotti, 2016.
O Kanban auxilia no rastreio e demonstração visual do progresso das

atividades em andamento e na redução rápida do lead-time. Lead-time consiste
no tempo decorrido entre a entrada da solicitação pelo cliente até o momento da
9
disponibilização para o mesmo do software. Para quem atua de acordo com a
metodologia Scrum, um dos desafios enfrentados é o atraso na entrega
conforme o Sprint. A entrega em atraso representa riscos e afeta o desempenho
da produção, bem como o resultado de valor entregue para o cliente. Ele espera
que todos atuem em conjunto em cada atividade, não iniciando outra até que
cada atividade seja encerrada.
Então o Kanban vem agregar em muito um excelente requisito para
aplicarmos garantia de qualidade em nossos processos de desenvolvimento de
software para os quais não temos nem tempo, recursos humanos e financeiros
para adoção de metodologias mais elaboradas.
COSTA JUNIOR, 2012
MARIOTTI, 2016
Saiba mais
http://www.sabesim.com.br/Kanban-
landing/?gclid=CKapyaH0gc0CFVIFkQodxGoP8w
TEMA 3: DESENVOLVIMENTO BASEADO EM TESTE
Uma nova tendência é o desenvolvimento com base em teste

(test-driven development – TDD). Nesse tipo de desenvolvimento os requisitos
para um componente de software servem de base para a criação de uma série
de casos de teste que exercitam a interface e tentam encontrar erros nas
estruturas de dados e funcionalidade fornecida pelo componente. Ela não é
exatamente uma nova tecnologia, mas uma tendência que enfatiza o projeto de
casos de testes antes que o próprio código-fonte exista! (PRESSMAN, 2011).
Como o TDD funciona? Vamos observar a Figura 4.
10
Figura 4: Fluxo de funcionamento do TDD
O processo segue um fluxo procedural (figura 4), para o qual criamos cada
caso de teste, escrevemos um segmento de código, executamos os testes e os
refazemos (corrigimos) até que estejam de acordo com cada caso de teste. Logo,
nosso sistema será escrito em pequenos
incrementos (subfunções) e nenhum código é escrito sem um caso de teste bem
definido. Os testes comandam o projeto detalhado de componentes e códigos-
fontes resultantes.
Aqui fica mais uma tendência para os desenvolvedores de metodologias
ágeis, num caso bem aderente ao método XP (Extreme Programming). Entramos
novamente então com a prática de garantia de qualidade, porém de forma mais
simplificada, enxuta e que apoia o processo de desenvolvimento. Em
consonância com método ágeis, teremos um feedback rápido sobre novas
11
funcionalidades, um código mais limpo, segurança no Refactoring, segurança na
correção de bugs, mais produtividade, aplicação flexível. Refactoring ou
refatoração é o momento que analisamos nosso código para nosso teste passar.
Retiramos duplicidades, renomeamos variáveis, extraímos métodos, classes,
interfaces e utilizamos algum padrão conhecido. Nosso código ficará mais
funcional após a refatoração. (GAMA, 2016).
SOMMERVILLE, 2011
Saiba mais
http://agiledata.org/essays/tdd.html
TEMA 4: QUALIDADE DE SOFTWARE E O BRASIL
O Brasil iniciou uma proposta na década de 1996 para alcance da

excelência do software brasileiro, criando a SOFTEX (Associação para
Promoção da Excelência do Software Brasileiro). Dentre as iniciativas da
associação, encontravam-se fomento e promoção da indústria brasileira de
software e serviços de TI, capacitando e promovendo a criatividade,
competência e fonte de talentos. Abaixo do Ministério da Ciência, Tecnologia e
Inovação (MCTI), tornou-se um programa que beneficia mais de 2 mil empresas
em todo o território nacional por meio de uma rede de 20 agentes regionais
(SOFTEX, 2016).
Dentro do Programa SOFTEX temos o Projeto denominado MPS.BR,
criado em 2003. Nada mais é que um projeto que visa impulsionar a melhoria da
capacidade de desenvolvimento de software e serviços para empresas
brasileiras. (SOFTEX, 2016).
12
Uma das iniciativas desse projeto resultou no desenvolvimento do Modelo
de Referência para Melhoria do Processo de Software Brasileiro
(MPS-SW), levando em consideração normas e modelos internacionalmente
reconhecidos, além de boas práticas da engenharia de software e necessidades
de negócio da indústria de software brasileira. (SOFTEX, 2016). Veja Figura 5 a
seguir.
Com o MPS-SW foi possível estabelecer um caminho economicamente

viável para que organizações, incluindo as pequenas e médias
empresas, alcancem os benefícios da melhoria de processos e da
utilização de boas práticas da engenharia de software em um intervalo
de tempo razoável. Ele trouxe para a indústria nacional ganhos
comprovados de competitividade, por isso é considerado um marco
que representa a evolução da qualidade do software desenvolvido no
país. (SOFTEX, 2016)
Figura 5: Componentes do Modelo MPS
“A iniciativa conta com o financiamento do Banco Interamericano de

Desenvolvimento (BID), a Financiadora de Estudos e Projetos (FINEP), o
13
Ministério da Ciência, Tecnologia e Inovação (MCTI) e o Serviço Brasileiro de
Apoio às Micro e Pequenas Empresas (SEBRAE).” (SOFTEX, 2016).
As bases do MPS.BR são encontradas em:
1. ISO/IEC 12207:2008
2. ISO/IEC 15504
3. ISO/IEC 20000
4. CMMI-DEV
5. CMMI-SVC
Da mesma forma que a CMMI, o MPS.BR possui níveis de avaliação para

classificar os processos de desenvolvimento de software de empresas
brasileiras. Em geral, o CMMI é altamente dispendioso para implantação. Uma
excelente proposta do Programa SOFTEX foi a criação de uma forma de
certificação nacional, a qual pode ser implantada em colaboração com várias
empresas por meio de uma das regionais do Programa Softex.
‘Você pode pensar: mas eu vou implantar o MPS.BR em colaboração com

meus concorrentes? Não é essa a visão que você deve ter. Você deve pensar
que se você, como empresa de desenvolvimento de software, deseja seguir
métodos, padrões e métricas que lhe garantam maior confiabilidade em seus
processos e produtos, é a forma mais acessível e rápida.
SOFTEX, 2016
TEMA 5: GRANDES DESAFIOS
Uma grande tendência para a área de computação é inegável, o software

se tornará cada vez mais complexo. Se observarmos o que estudamos até aqui
sobre testes de software, utilizamos apenas software convencional, orientado a
objetos e para Web. Mas quando olhamos ao nosso redor, o que vemos?
14
Software embarcado (automóveis, eletrodomésticos, etc.), computadores
descartáveis, interação com um ambiente (conjunto de periféricos,
computadores e outros aparelhos), e por aí a fora. Assim, poderíamos catalogar
um pouco sobre as nossas novas características a serem abordadas para a
garantia da qualidade do processo de desenvolvimento de software
(PRESSMAN, 2011):
1. Multifuncionalidade: um conjunto cada vez maior de funções num único

dispositivo. Exemplo: celular que serve para comunicação, fotos,
calendário, mídias digitais, entre tantas outras utilidades.
2. Temporização: dispositivos digitais reagindo a estímulos

externos. Sensores que fazem com que se dependa menos da
intervenção humana.
3. Novas interações com o ser humano: teclado e mouse são periféricos

que deixaremos de ver em breve. Então, modelar outros tipos de interação
se tornam um desafio cada vez maior.
4. Arquiteturas complexas: várias CPUs, barramentos sofisticados,

sensores, interface humana mais sofisticada, componentes de segurança.
Exemplo? Automóveis.
5. Sistemas heterogêneos distribuídos: componentes de tempo real

embutido e conectado por meio de redes sem fio ou Internet.
6. Criticidade: sistemas que envolvem um nível altíssimo de questões de

segurança. Exemplo: aviões.
7. Variabilidade de manutenção: o tempo útil de nossos dispositivos

digitais não se prolonga além de 3 anos. Mas automóveis, aviões entre
outros ainda terão um tempo maior de vida.
15
No que isso interfere na garantia da qualidade de processos de software?
Certamente teremos no futuro uma disciplina de Qualidade de Software I e II
para cobrirmos todas as necessidades de variação de acoplamento entre
software, hardware e comunicação.
SOMMERVILLE, 2011
CAMPOS, 2016
TROCANDO IDEIAS
Refletir sobre a introdução da garantia de qualidade, utilizando metas,

métricas, estatísticas e padrões em projetos de desenvolvimento de software.
Quais seriam os custos para introduzirmos tantas avaliações, correções e
padronizações? Precisaríamos de profissionais habilitados para tais tarefas, ou
bastaria utilizarmos o próprio pessoal do desenvolvimento?
SÍNTESE
Estudamos até aqui sobre elementos importantes para garantia da

qualidade. Tanto o gerenciamento quanto a garantia da qualidade querem
assegurar que o software tenha poucos defeitos e esteja em conformidade com
padrões de manutebilidade, confiabilidade e portabilidade. Os padrões são muito
importantes para a garantia de qualidade, pois, por meio de suas melhores
práticas, oferecem uma base para construção de software de boa qualidade. O
processo de documentação, que é um elemento bastante importante dentro da
área de qualidade, pode ser baseado num conjunto de procedimentos da
garantia de qualidade sugeridas pela ISO 9001. Optar por revisões e inspeções
garantirão melhoria no processo e no produto. As revisões dos entregáveis são
16
técnicas usadas para avaliação da qualidade, enquanto que inspeção de
programas ou revisão em pares buscam possíveis erros e omissões. Quando
falamos em medição de software, usamos coleta de dados quantitativos capazes
de subsidiarem métricas de software para garantir a qualidade tanto do produto
quanto do processo.
REFERÊNCIA
ADAMI, A. Kaizen. Disponível em:

<http://www.infoescola.com/sociedade/Kaizen/>. Acesso em: maio de 2016.
COSTA JUNIOR, E. L. Gestão em processos produtivos. Curitiba:

Intersaberes, 2012.
GAMA, A. Test Drive Development: TDD simples e prático. Disponível em:

<http://www.devmedia.com.br/test-driven-development-tdd-simples-e-
pratico/18533>. Acesso em: 2016 em maio de 2016.

MARIOTTI, F.S. Kanban: o ágil adaptativo: introduzindo Kanban na equipe

ágil. Disponível em:
<http://www.garcia.pro.br/EngenhariadeSW/artigosMA/A6%20-%2045-6-
%20Kanbam.pdf>. Acesso em: maio de 2016.

SOFTEX. Disponível em: <http://www.softex.br/mpsbr/>. Acesso em: maio de

2016.
17
GUIA GERAL DO MPS.BR. Disponível em: <http://www.softex.br/wp-
content/uploads/2013/07/MPS.BR_Guia_Geral_Software_2012-c-ISBN-1.pdf>.


18

Uninter - Qualidade de Software - Gestao em TI

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Uninter - Qualidade de Software - Gestao em TI

Enviado por

Direitos autorais:

Formatos disponíveis

QUALIDADE DE SOFTWARE

Prof.a Maristela Regina Weinfurter Teixeira

Olá, seja bem-vindo. Assista ao primeiro vídeo da professora Maristela

Vamos trabalhar um conceito importantíssimo dentro da Engenharia de

São décadas que falamos em engenharia e qualidade de software, porém

Mas não paramos apenas nos problemas de funcionalidades por conta de

Enfim, não obstante, podemos ainda falar sobre os problemas inerentes

Então, estamos falando da qualidade do software e também do seu processo de

Uma Introdução à Qualidade de Software:

O mercado de software brasileiro conta com o Simpósio Brasileiro de

O simpósio está em sua 16.ª edição. Informações, artigos e dissertações

Utilize o link abaixo e identifique os temas que mais foram discutidos em

 Temas como automatização de testes são discutidos?

Como definirmos o que é qualidade, como saber o que ela representa ou

Definir qualidade é algo complexo à primeira vista, porém, com um

Imagine-se em um restaurante, para o qual, em especial hoje, você pagou

Qualidade, segundo o INMETRO, “é uma variável precisa e mensurável,

Já para Shigunov Neto (2016), qualidade

é uma filosofia de gestão empresarial ou um modelo de gestão

1. Deming (1950) – Máxima utilidade para o consumidor;

Quando olhamos pela ótica da Engenharia de Software, podemos dizer

Figura 1: Qualidade de Software

Fonte: Pressman, 2011.

A qualidade de software pode ser definida, segundo Pressman, como

Qualidade, qualidade de software e garantia da qualidade de software são as

Quais suas diferenças e complementaridades.

TEMA 2: DIMENSÕES DA QUALIDADE DE SOFTWARE

Sabemos então que qualidade se aplica tanto a produtos/serviços quanto

1. Qualidade do desempenho: funcionalidades e recursos especificados

Já segundo o INMETRO (2015), estas dimensões ou categorias da

Podemos observar que mesmo autores diferentes possuem compreensão

Caminhamos mais um pouco no conhecimento da qualidade de software

TEMA 3: FATORES DE QUALIDADE

Até o momento falamos sobre conceitos e definições importantes para a

Agora vamos compreender um pouco sobre os fatores de qualidade

Figura 2: Fatores de qualidade de software

Fonte: Pressman, 2011.

Começando pelo grupo Revisão do Produto dos fatores de qualidade de

1. Facilidade de manutenção: é o esforço necessário para localização e

1. Portabilidade: é o esforço necessário para transferência de um programa

E finalmente, o último grupo, Operação do Produto, possui as seguintes

1. Correção: é o quanto o programa satisfaz a sua especificação e atende

Temos também a versão dos fatores de qualidade segundo a ISO 9126,

2. Confiabilidade: é a quantidade de tempo que o software fica disponível

3. Usabilidade: diz respeito ao grau de facilidade de utilização do software

4. Eficiência: é o grau de otimização do uso dos recursos do sistema

5. Facilidade de manutenção: corresponde à facilidade de correção do

6. Portabilidade: quão ágil é passar o software de um ambiente

De acordo com esta visão sobre os fatores de qualidade, é fácil concluir

Estudamos anteriormente o que seriam os princípios básicos da

Se produzirmos um sistema de software de péssima qualidade,

A grande questão encontra-se em um esforço racional e objetivo para

Ele deverá fornecer funções e características de alta qualidade que os

Agora precisamos olhar para os custos. Qualidade é importante, mas

Quando falamos em custos da qualidade precisamos incluir todos os

Os Custos de Prevenção contêm os seguintes itens:

1. Custos de atividades de gerenciamento (planejamento, coordenação,

Já os Custos de Avaliação incluem custos:

1. Para a execução de revisões técnicas.

Finalmente, os Custos de Falhas comportam:

1. A percepção da necessidade de retrabalhos e correção de erros.

Figura 4: Custos da Qualidade de Software X Ciclo de Vida dos Sistemas

Fonte: Pressman, 2011.

Segundo Pressman (2011): “O custo médio da indústria de software para