Teste de Software: Qualidade e Normas

unidade 2 TESTE DE SOFTWARE Qualidade e unidade 2 Normas e Introdução a Tipos de Testes Prezado estudante Estamos começando uma unidade desta disciplina Os textos que a compõem foram organizados com cuidado e atenção para que você tenha contato com um conteúdo completo e atualizado tanto quanto possível Leia com dedicação realize as atividades e tire suas dúvidas com os tutores Dessa forma você com certeza alcançará os objetivos propostos para essa disciplina OBJETIVO GERAL Estudar as normas relacionadas a qualidade e os tipos de testes OBJETIVOS ESPECÍFICOS Descrever as normas relacionadas à qualidade de software Conceituar e reconhecer os níveis de maturidade de software Apontar as causas e os defeitos em software e o papel do analista de teste de software Diferenciar os tipos de teste de software e suas etapas o que testar como testar e quando testar unidade 2 O conteúdo deste livro é disponibilizado por SAGAH Parte 1 Normas de Qualidade de Software QUALIDADE E TESTE DE SOFTWARE 66 Normas de qualidade de software Objetivos de aprendizagem Ao final deste texto você deve apresentar os seguintes aprendizados Descrever as normas relacionadas à qualidade de software Conceituar a qualidade no ciclo de vida Analisar o modelo de qualidade Introdução A qualidade é um aspecto fundamental de qualquer produto sendo sempre esperada pelo consumidor final Para se obter qualidade uma série de normas de processo buscam padronizar a produção de deter minados produtos No âmbito do software isso não é diferente A qualidade de sistema é alcançada por meio de uma série de normas estabelecidas por orga nizações nacionais e internacionais que buscam padronizar processos e estabelecer formas de alcançar o máximo de qualidade Neste capítulo você vai estudar e ser capaz de descrever as normas relacionadas à qualidade conceituar a qualidade no âmbito do ciclo de vida do software e por fim analisar o modelo de qualidade O que são normas de qualidade As normas de qualidade ajudam desenvolvedores a criarem softwares com as características ideais de qualidade Um software de qualidade é aquele que apresenta diversas características como efi ciência inexistência de erros codifi cação de boa qualidade ser fácil de usar ter rápido desenvolvimento entre outras A criação de produtos de qualidade sejam softwares ou não é geralmente viabilizada por meio de padrões Esses padrões determinam 67 Normas e Introdução a Tipos de Testes UNIDADE 2 Normas de Qualidade de Software PARTE 1 geralmente como um processo deverá ser realizado para que um produto tenha qualidade Na produção industrial por exemplo é comum ouvirmos falar que uma empresa tem uma certificação ISO Isso significa que os produtos dessa empresa são desenvolvidos por meio de um padrão ou que apresentam um padrão final de qualidade especificado por uma norma e a empresa pode garantir a qualidade do produto A certificação dá portanto segurança para o consumidor e confiabilidade para a empresa que desenvolve o produto De maneira geral tanto no âmbito industrial como no que tange aos pro dutos de software existem tanto normas que se referem a elementos finais do produto quanto normas de processo que se referem a como e por quais etapas um produto foi desenvolvido para atingir um padrão de qualidade em nível de processo Mas afinal o que significa ISO ISO é uma sigla para International Stan dardization Organization que em tradução literal significa Organização In ternacional de Normalização A ISO é portanto uma instituição internacional que tem como objetivo criar e publicar padrões de qualidade para diversas áreas incluindo o desenvolvimento de software Além da ISO outra instituição em nível global também se responsabiliza pela criação e publicação de normas A IEC International Electrotechnical Commission que em tradução literal significa Comissão Eletrotécnica Inter nacional desenvolve normas e padrões relacionados às áreas de eletricidade eletrônica e áreas afins No Brasil a Associação Brasileira de Normas Técnicas ABNT também é responsável pela criação e publicação de normas em nível nacional A ABNT se responsabiliza por emitir um padrão que abrange desde elementos muito simples como a padronização de um trabalho acadêmico até a criação de padrões de produção e organização industrial Existem diversas normas relativas à qualidade de software O Quadro 1 a seguir traz um breve resumo de algumas dessas normas Normas de qualidade de software 2 QUALIDADE E TESTE DE SOFTWARE 68 Fonte Adaptado de Vasconcelos et al 2006 apud Gallotti 2017 Nome Descrição Norma ISOIEC 9126 NBR 13596 Define as características de qualidade de software que devem estar presentes em todos os produtos funcionalidade confiabilidade eficiência usabilidade manutenibilidade e portabilidade Norma ISOIEC 12119 Estabelece os requisitos de qualidade para pacotes de software Norma ISOIEC 145985 Define um processo de avaliação de qualidade de produto de software Norma ISOIEC 12207 Define um processo de ciclo de vida de software Norma ISOIEC 90003 Apresenta diretrizes para a aplicação da ISO 9001 por organizações que desenvolvem software para o desenvolvimento fornecimento e manutenção de software Norma ISOIEC 15504 Aprovada como norma em 2003 é focada na avaliação de processos organizacionais Quadro 1 Normas ISOIEC Dentre essas normas cabe destacar a NBR ISOIEC 9126 ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS 2003 sob o título geral Enge nharia de software Qualidade de produto que é uma norma da família das ISO 9000 e versa sobre as características de qualidade de software que devem estar presentes em todos os produtos Essa norma juntamente com a NBR ISOIEC 14598 Avaliação de produto de software substitui a antiga norma NBR 13596 A primeira parte da norma NBR ISOIEC 9126 ASSOCIAÇÃO BRA SILEIRA DE NORMAS TÉCNICAS 2003 se refere à qualidade interna e externa e a segunda se refere à qualidade de uso De acordo com o texto da 3 Normas de qualidade de software 69 Normas e Introdução a Tipos de Testes UNIDADE 2 Normas de Qualidade de Software PARTE 1 própria norma ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS 2003 p 3 ela pode ser utilizada por desenvolvedores para validar a completude de uma definição de requisitos identificar requisitos de software identificar objetivos de projeto de software identificar objetivos para teste de software identificar critérios para garantia de qualidade identificar critérios de aceitação para produtos finais de software Já a norma NBR ISOIEC 14598 ASSOCIAÇÃO BRASILEIRA DE NOR MAS TÉCNICAS 2001 apresenta uma visão geral do processo de avaliação de produtos de software sendo aplicada tanto em componentes como no sistema podendo ser empregada em qualquer fase do ciclo de vida do produto O processo de avaliação nesse sentido é definido pela norma em quatro etapas 1 Definir os requisitos de avaliação 2 Especificar a metodologia de avaliação 3 Projetar o processo de avaliação 4 Executar a avaliação Uma atualização das normas de qualidade de software pode ser encontrada na ISOIEC 25000 2014 com o título geral Systems and Software Quality Requirements and Evaluation SQuaRE Tratase de uma das mais impor tantes normas no âmbito da qualidade de produto e processo de software Ela é uma evolução das normas anteriores fornecendo novas regras e métodos para a qualidade tanto no âmbito de produto como no âmbito de processo A série de normas ISOIEC 25000 se dedica a duas dimensões A primeira diz respeito à qualidade em uso que consiste na qualidade relativa à interação humanocomputador A segunda se refere à qualidade do produto definindo um conjunto de oito características de qualidade internas e externas Koscianski e Soares 2007 ressaltam que a norma 25000 se baseia em outras normas ainda em processo de desenvolvimento o que não exclui a possibilidade de utilização das normas 9126 e 14598 Além disso os autores explicam que o modelo SQuaRE não surgiu para invalidar as normas anteriores mas sim para fornecer um modelo mais organizado e didático para a qualidade de software A seguir detalharemos esses aspectos da qualidade de software Normas de qualidade de software 4 QUALIDADE E TESTE DE SOFTWARE 70 Qualidade no ciclo de vida do software O ciclo de vida de um software consiste em todas as etapas que o produto passará desde os primeiros passos na elicitação de requisitos até o fi m do uso do produto Figura 1 Figura 1 Modelo de ciclo de vida para a qualidade de software na ótica SQuaRE Fonte Adaptada de Koscianski e Soares 2007 Produto Requisitos Implementação Necessidades Requisitos de qualidade em uso Validação Qualidade em uso Qualidade externa Qualidade interna Requisitos de qualidade externa Requisitos de qualidade interna Validação e verificação Verificação No âmbito da qualidade de software podemos elencar a qualidade de uso a qualidade externa e a qualidade interna Conforme mencionado na seção anterior a qualidade em relação ao uso está ligada às percepções do usuário durante o processo de interação já as qualidades interna e externa se referem especificamente aos aspectos do produto de software A qualidade de uso diz respeito a como o software fornece as possibilidades para os usuários atingirem as metas especificadas com eficiência envolvendo eficácia produtividade segurança e satisfação Nesse sentido um software eficiente é aquele que permite que o usuário atinja suas metas com completude A produtividade se refere à capacidade do software e à empregabilidade de recursos em relação à eficácia obtida A segurança se refere à capacidade do software em oferecer níveis aceitáveis de risco Por fim a satisfação se refere a como o software satisfaz as expectativas do usuário em um determinado contexto 5 Normas de qualidade de software 71 Normas e Introdução a Tipos de Testes UNIDADE 2 Normas de Qualidade de Software PARTE 1 Imagine que você está utilizando um software de edição de textos Normalmente quando usamos esse tipo de software precisamos formatar o texto criar tabelas ou adicionar formas ao texto Um editor de texto que apresenta qualidade de uso é aquele que o usuário rapidamente aprende a utilizar conseguindo intuitivamente entender sua interface Ou seja é fácil de usar Além disso o editor de textos pre cisa ser fácil de memorizar de lembrar como se faz por exemplo para inserir uma tabela Esse editor também precisa ser confiável o que significa que ele não pode simplesmente se fechar sem salvar o seu trabalho ele pode fechar mas garantindo que tudo o que você fez pode ser recuperado Esses elementos são fundamentais para o usuário perceber a qualidade do software Por que será que normalmente nós preferimos um editor de textos em relação a todos os milhares que existem no mercado Possivelmente por ele apresentar melhor essas características em contraponto a outros disponíveis no mercado A qualidade interna se refere à estrutura do software no âmbito do có digo Ou seja um software de qualidade é aquele que apresenta padrões de desenvolvimento no âmbito algorítmico Esse aspecto da qualidade se refere a diversos elementos dentro do software como o uso de variáveis classes métodos e outros elementos da estrutura interna do software Imagine a seguinte situação você é um novo integrante da equipe de de senvolvimento de software de uma empresa e se deparou com a necessidade de criar um novo módulo para se comunicar com o programa Quando você abre o códigofonte percebe que cada variável foi declarada de uma forma diferente ora com letra maiúscula ora com letra minúscula algumas foram declaradas com o sinal de e outras foram escritas sem separação Além disso você percebe que as classes e os eventos foram criados sem nenhum tipo de padrão Como você vai poder corrigir problemas ou adicionar um novo módulo para o software Provavelmente você não vai compreender o código do software da empresa e não vai conseguir fazer a manutenção Para solucionar esse problema é preciso não apenas aplicar padrões de desenvolvi mento mas também documentar o software para que qualquer pessoa possa realizar a manutenção Nesse sentido garantir a qualidade interna significa que o software pode ser facilmente compreendido e modificado A qualidade interna é fundamental para todo o ciclo de vida do software e principalmente para as fases de desenvolvimento teste e correção de pro blemas Além disso a qualidade interna pode afetar também a qualidade em Normas de qualidade de software 6 QUALIDADE E TESTE DE SOFTWARE 72 uso uma vez que um software feito de qualquer jeito normalmente apresenta muitas falhas em aspectos de usabilidade A qualidade interna está diretamente ligada à manutenibilidade do software pois um software que não apresenta um padrão de desenvolvimento é extremamente difícil quanto à realização de qualquer tipo de manutenção seja ela uma correção de problemas ou a criação de novos módulos A qualidade externa de acordo com Koscianski e Soares 2007 p 209 é uma estimativa da qualidade em uso ambas podem ser muito próximas mas não são equivalentes Isso significa que a qualidade externa é uma aproximação uma expectativa em relação à qualidade durante o processo de utilização do software Nesse sentido a qualidade do produto nesse âmbito é estimada por meio de testes que buscam simular a utilização do produto pelo usuário Uma questão importante no âmbito do ciclo de vida é que as visões de qualidade mudam durante o ciclo de vida do software ISOIEC 9126 o que pode acarretar em perspectivas de qualidade distintas em cada uma das fases Por exemplo no início do desenvolvimento do software podese esperar do sistema um determinado comportamento que poderá mudar durante o processo de desenvolvimento Os aspectos de qualidade em uso interna e externa estão intimamente ligados com a elicitação de requisitos Em especial a percepção da qualidade em uso está diretamente ligada ao fato de o sistema fornecer as funções que o usuário julga necessárias Lembrando que em linhas gerais o conceito de qualidade de um software se refere à capacidade desse produto de satisfazer os requisitos para os quais ele foi desenvolvido Entender a qualidade nessas três perspectivas permite elicitar requisitos que satisfaçam a qualidade em uso a qualidade interna e a qualidade externa Nesse caminho a ISOIEC 25030 ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS 2008 orienta que se estabeleçam requisitos de qua lidade como parte do processo de especificação de requisito Dessa forma a norma possui um foco nos requisitos de qualidade na perspectiva do software Ainda de acordo com a norma o software faz parte de um sistema maior que engloba outros elementos como hardware sistema operacional e dados para a utilização do software A Figura 2 demonstra a relação entre o software e os outros elementos que constituem o sistema 7 Normas de qualidade de software 73 Normas e Introdução a Tipos de Testes UNIDADE 2 Normas de Qualidade de Software PARTE 1 Figura 2 Relação entre o software e outros elementos de um sistema Fonte Adaptada de NBR ISOIEC 25030 ABNT 2008 Processos Comunicação Comunicação Comunicação Comunicação Sistema mecânico Desempenhados por pessoas Sistema empresarial Sistema de informações Sistema computacional Computador Hardware Operação Sistema Aplicativo Sofware Dados Sistema computacional Computador Hardware Operação Sistema Aplicativo Sofware Dados Especificar requisitos de qualidade de software contribui para o desen volvimento de um produto que seja consistente sendo necessário que esses requisitos estejam relacionados com as características do modelo de qualidade Modelos de qualidade Segundo Koscianski e Soares 2007 a ideia de um modelo de qualidade é bastante antiga estando presente em publicações ainda dos anos 1970 Tais modelos surgem da tentativa de especifi car padrões no desenvolvimento de software Essas iniciativas aparecem na literatura como trabalhos isolados de diversos autores estando relacionadas aos mais diversos tipos de software Nesse sentido Koscianski e Soares 2007 lecionam que o modelo SQuaRE surge de uma maneira muito sólida buscando atender às demandas necessárias de qualidade de uma forma eficiente e ao mesmo tempo didática oferecendo uma linguagem com vocabulário simples e válido internacionalmente Nesse modelo podemos observar que a ISOIEC 25000 está organizada da seguinte forma ISOIEC 2500n Divisão Gestão da Qualidade ISOIEC 2501n Divisão Modelo de Qualidade Normas de qualidade de software 8 QUALIDADE E TESTE DE SOFTWARE 74 ISOIEC 2502n Divisão Medição da Qualidade ISOIEC 2503n Divisão Requisitos de Qualidade ISOIEC 2504n Divisão Avaliação da Qualidade No link a seguir você terá acesso a uma tese de doutorado que detalha como se dá a organização da norma ISO 2500 httpsgooglb1hCfz A qualidade em uso no modelo SQuaRE é caracterizada pela efetividade produtividade segurança e satisfação As qualidades externa e interna são descritas em um modelo hierárquico oriundos da norma ISO 9126 2003 A Figura 3 a seguir demostra a hierarquia das qualidades interna e externa Figura 3 Modelo de qualidade segundo a ISO 9126 Fonte Adaptada de Koscianski e Soares 2007 Qualidade externainterna Funcionalidade Manutenibilidade Usabilidade Segurança Acurácia Interoperabilidade Adequabilidade Testabilidade Estabilidade Modificabilidade Analisabilidade Atratividade Compreensibilidade Apreensibilidade Operabilidade Confiabilidade Maturidade Tolerância a falhas Recuperabilidade Eficiência Comportamento temporal Utilização de recursos Portabilidade Adaptabilidade Instalabilidade Coexistência Substitutibilidade 9 Normas de qualidade de software 75 Normas e Introdução a Tipos de Testes UNIDADE 2 Normas de Qualidade de Software PARTE 1 Koscianski e Soares 2007 explicam que esse modelo garante que a análise de uma categoria de qualidade seja sempre considerada isoladamente Ou seja ao se analisar a confiabilidade não se consideram os fatores relativos a outras seções como a funcionalidade Nesse sentido essa separação hierárquica con tribui para a elicitação de requisitos específicos para cada uma das categorias Vejamos a seguir as categorias de qualidade de software Funcionalidade o software satisfaz as necessidades do usuário Ou seja apresenta as funções necessárias no âmbito do que o usuário precisa Por exemplo em um editor de textos o software permite formatar a fonte criar confi gurações personalizadas e imprimir o documento Esses elementos se referem às funcionalidades disponíveis Nas palavras de Koscianski e Soares 2007 p 211 a funcionalidade diz respeito àquilo que o software faz quando solicitado pelo usuário como por exemplo imprimir um relatório apresentar dados na tela ou registrar uma informação em uma base de dados Confi abilidade o software mantém um nível de desempenho confi ável ou seja evita falhas e é capaz de se recuperar de erros As falhas são o calcanhar de Aquiles de um software Infelizmente enquanto os sistemas forem feitos por seres humanos as falhas mesmo que em pequena escala sempre estarão presentes Contudo minimizar essas falhas e garantir que o sistema seja capaz de se recuperar é fundamental para manter a confi abilidade Portabilidade o software pode ser transferido de um sistema para outro ou pode trabalhar de forma compatível com outros sistemas Isso signifi ca por exemplo que um software possa rodar em vários sistemas operacionais ou que um software desenvolvido por uma determinada empresa seja capaz de se comunicar com outro A falta de portabilidade é comum na nossa vida Imagine quantas vezes você gostaria que um software fosse capaz de se comunicar com outro para realizar alguma tarefa Por exemplo garantir que um relatório seja compatível com um aplicativo de planilha eletrônica ou que a própria planilha eletrônica consiga realizar uma conexão com o banco de dados e extrair as informações Para muitos softwares essa é uma realidade muito comum porém para outros não há compatibilidade Usabilidade o software precisa ser simples de fácil aprendizagem e de fácil memorização Para Koscianski e Soares 2007 p 215 a usabili dade representa basicamente o quão fácil é usar o produto A usabilidade de Normas de qualidade de software 10 QUALIDADE E TESTE DE SOFTWARE 76 um software está diretamente ligada à interface e às escolhas de design que basearam a construção da interface do sistema Efi ciência o software executa ações de acordo com as expectativas do usuário de forma rápida A efi ciência está diretamente ligada a questões de hardware e desempenho Por exemplo ainda hoje ao se desenvolver aplicativos para dispositivos móveis é necessário trabalhar geralmente com uma quantidade limitada de memória e um espaço em disco ligeiramente inferior às confi gurações disponíveis em um computador convencional Isso demanda que o software seja desenvolvido de forma a ocupar pouca memória e pouco espaço em disco para garantir que seja efi ciente Usar um aplicativo que consome toda a memória do smartphone por exemplo seria bastante incômodo pois o sistema falharia logo a efi ciência da aplicação estaria comprometida A efi ciência está ligada do ponto de vista da engenharia de software à elici tação dos requisitos não funcionais Manutenibilidade o software é de fácil manutenção e pode ser modifi cado de forma a contemplar melhorias ou extensões A capacidade de manutenção do software está diretamente relacionada à qualidade interna Como já men cionado a padronização do ponto de vista do código é fundamental para manter a qualidade Por fim é importante considerar que o modelo de qualidade SQuaRE fornece diversas formas para que se obtenha o melhor no âmbito da qualidade de software apresentando não apenas regras mas um horizonte a ser seguido do ponto de vista da qualidade do produto de software ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS ABNT NBR ISOIEC 91261 software engineering product quality part 1 quality model Rio de Janeiro ABNT 2003 ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS ABNT NBR ISOIEC 145981 tecno logia de informação avaliação de produto de software parte 1 visão geral Rio de Janeiro ABNT 2001 ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS ABNT NBR ISOIEC 25030 engenharia de software requisitos e avaliação da qualidade de produto de software SQuaRE requisitos de qualidade Rio de Janeiro ABNT 2008 11 Normas de qualidade de software 77 Normas e Introdução a Tipos de Testes UNIDADE 2 Normas de Qualidade de Software PARTE 1 GALLOTTI G M A Org Qualidade de software São Paulo Pearson Education 2017 INTERNATIONAL ORGANIZATION FOR STANDARDIZATION ISO ISOIEC 250002014 software engineering system and software quality requirements and evaluation SQuaRE Genebra ISO 2014 KOSCIANSKI A SOARES M S Qualidade de software aprenda as metodologias e técnicas mais modernas para o desenvolvimento de software 2 ed São Paulo Novatec 2007 Leitura recomendada ROCHA A R C MALDONADO J C WEBER K C Qualidade de software São Paulo Prentice Hall 2001 Normas de qualidade de software 12 QUALIDADE E TESTE DE SOFTWARE 78 ENCERRA AQUI O TRECHO DO LIVRO DISPONIBILIZADO PELA SAGAH PARA ESTA PARTE DA UNIDADE PREZADO ESTUDANTE unidade 2 O conteúdo deste livro é disponibilizado por SAGAH Parte 2 CMM e CMMI QUALIDADE E TESTE DE SOFTWARE 80 CMM e CMMI Objetivos de aprendizagem Ao final deste texto você deve apresentar os seguintes aprendizados Conceituar os níveis de maturidade de software Reconhecer cada um dos níveis da maturidade de software Demonstrar os níveis de CMM e CMMI Introdução O modelo de referência CMM do inglês capability maturity model ou mo delo de maturidade em capacitação também conhecido como software CMM SWCMM surgiu na década de 1980 nos Estados Unidos O CMMI do inglês capability maturity model integration ou modelo integrado de maturidade em capacitação por sua vez é a evolução do CMM e contém práticas necessárias à maturidade em disciplinas específicas Tais modelos de referência buscam de uma forma geral descre ver estágios de maturidade pelos quais passam o desenvolvimento de software buscando a melhoria contínua e a qualidade de software Muitas organizações no mundo todo têm adotado esses modelos com o objetivo de possibilitar a elevação da maturidade de suas equipes nas atividades relacionadas ao software Neste capítulo você vai estudar os níveis de maturidade de software identificando e analisando os níveis de CMM e CMMI Níveis de maturidade de software O CMM é um modelo de capacitação de processo de software desenvolvido pelo Instituto de Engenharia de Software que em inglês atende pela sigla SEI e patrocinado pelo Departamento de Defesa dos Estados Unidos A primeira versão do CMM foi publicada em agosto de 1991 e tinha como principal objetivo fazer com que as empresas conheçam e melhorem seus processos de desenvolvimento de software com base em práticas predefi nidas 81 Normas e Introdução a Tipos de Testes UNIDADE 2 CMM e CMMI PARTE 2 A maturidade de uma organização ou de um projeto está associada com o conhecimento adquirido ao longo do tempo e acima de tudo em poder trans formálo em resultados O modelo CMM comporta cinco níveis de maturidade 1 Inicial nesse nível os processos são caóticos não existe ambiente estável dependendo totalmente do bom trabalho de funcionários da organização não existe gerenciamento de projeto disciplina organi zação ou planejamento É o nível mais básico em que há muito a se melhorar durante o desenvolvimento de um projeto 2 Repetitivo nesse nível são estabelecidas técnicas de gerenciamento de projeto com um mínimo de disciplina sendo o desenvolvimento de projeto repetido garantindo que os requisitos sejam gerenciados e que os processos sejam planejados executados medidos e controlados sendo descritos em normas procedimentos ferramentas e métodos A disciplina do processo refletida pelo nível de maturidade 2 ajuda a garantir que as práticas existentes sejam mantidas durante períodos de estresse Quando essas práticas estão em vigor os projetos são executados e gerenciados de acordo com seus planos documentados 3 Definido no nível de maturidade 3 uma organização atingiu todos os objetivos específicos e genéricos das áreas de processo atribuídas aos níveis de maturidade 2 e 3 Nesse terceiro nível os projetos são bem caracteri zados e entendidos há padrões estabelecidos os processos são descritos com mais detalhes e rigor e são proativos Os padrões as descrições de processo e os procedimentos de um projeto são adaptados do conjunto de processos padrão da organização para se adequar a um projeto ou unidade organizacional em particular Os processos são tipicamente descritos com mais detalhes e com mais rigor do que no nível de maturidade 2 4 Gerenciado quantitativamente no nível de maturidade 4 uma orga nização atingiu todos os objetivos específicos das áreas de processo atribuídas aos níveis de maturidade 2 3 e 4 e as metas genéricas atri buídas aos níveis de maturidade 2 e 3 Nesse nível há previsibilidade do desempenho do processo tornandoo previsível quantitativamente são selecionados subprocessos que contribuem significativamente para o desempenho geral do processo Esses subprocessos selecionados são controlados usando técnicas estatísticas e outras técnicas quantitativas 5 Em otimização no último nível tendo sido atingidas todas as metas dos níveis anteriores os processos passam a ser continuamente melhorados com base em uma compreensão quantitativa das causas comuns de variação inerentes aos processos Os objetivos quantitativos de melhoria CMM e CMMI 2 QUALIDADE E TESTE DE SOFTWARE 82 de processos para a organização são estabelecidos continuamente revisados para refletir os objetivos de mudança nos negócios e usados como critérios no gerenciamento da melhoria de processos Cada nível de maturidade com exceção do primeiro é composto por áreas chaves de processo KPAs do inglês key process areas Cada uma dessas áreaschave identifica atividades a serem seguidas pela empresa para atingir os objetivos de desenvolvimento da capacidade do processo Segundo Pressman e Maximn 2016 p 828 O CMM original foi desenvolvido e atualizado pelo Software Engineering Institute na década de 1990 como um framework SPI completo Hoje evoluiu tornandose o CMMI Capability Maturity Model Integration um metamodelo de processo abrangente qualificado em uma série de capacidades de sistema e engenharia de software que devem estar presentes à medida que as organi zações alcançam diferentes níveis de capacitação e maturidade de processo Assim o CMMI além de ser uma evolução do CMM é uma abordagem de melhoria de processos que fornece elementos essenciais de processos eficazes podendo ser usado para guiar a melhoria de um projeto uma divisão ou uma organização inteira O CMMI possui duas representações contínua ou por estágios Essas representações permitem à organização utilizar diferentes caminhos para a melhoria de acordo com seu interesse A representação contínua é caracterizada por níveis de capacidade sendo utilizada para melhor atender aos objetivos de negócio da empresa Já a representação por estágios é caracterizada por níveis de maturidade buscando uma melhoria baseada em estágios A Figura 1 mostra a diferença entre essas representações com base em Koscianski e Soares 2007 Figura 1 Comparação entre a representação por estágios e a representação contínua Fonte Adaptada de Koscianski e Soares 2007 Respresentação por estágios Caracteristicas comuns compromisso e habilidade com excuçãodireção e verificação da implementação Nível de maturidade 1 Nível de maturidade 2 Nível de maturidade 5 Área de processo 1 Área de processo 2 Objetivos específicos Objetivos genéricos Práticas específicos Práticas genéricos Respresentação contínua Práticas específicos Práticas genéricos Objetivos específicos Objetivos genéricos Níveis de capacidade Área de processo nº Área de processo 2 Área de processo 1 3 CMM e CMMI 83 Normas e Introdução a Tipos de Testes UNIDADE 2 CMM e CMMI PARTE 2 O CMMI por representação contínua não classifica uma organização em níveis discretos mas considera as áreas de processo individualmente sendo possível à organização escolher as áreas de processo a serem aprimoradas Vejamos os níveis de capacidade do CMMI por representação contínua 0 Incompleto corresponde à ausência de qualquer modelo de processo de desenvolvimento o que torna difícil prospectar desenvolvimentos futuros Se o processo é implementado o nível 0 é atribuído quando um dos objetivos não é satisfeito 1 Executadorealizado o processo é executado de modo a completar o trabalho necessário para a execução de um processo cumprindo os objetivos mínimos de desenvolvimento conforme sua área para estar no nível 1 2 Gerenciadogerido cada processo cumpre os requisitos do nível 1 há planejamento da execução de um processo e confronto entre o planejado e o executado Os processos são monitorados controlados e revisados Há definição de requisitos e objetivos Ações corretivas são tomadas quando o resultado desvia do que foi planejado 3 Definido um processo no nível 3 cumpriu todos os requisitos do nível 2 Há nova construção de processo mediante a descrição do processo existente processos padronizados são estabelecidos e melho rados continuamente 4 Gerenciado quantitativamente a área de processo é controlada e melhorada quantitativamente por exemplo aplicandose técnicas esta tísticas Dados são coletados e analisados quantitativamente formando uma base de dados para apoio quanto à tomada de decisões 5 Otimizado um processo otimizado cumpre todos os requisitos do nível 4 A área de processo é adaptada e otimizada com vistas a estabilizar eventuais variações buscando melhoria contínua com base em recursos tecnológicos e de inovação Já o CMMI por estágios é compatível com a versão anterior do CMM para software e define um caminho claro de aprimoramento para as organizações que é atingido pela implementação das áreas de processo associadas a cada nível Segundo Vetorazzo 2018 são níveis de maturidade do CMMI por estágios Figura 2 Nível 1 Inicial no nível de maturidade inicial não há ambiente estável os processos são caóticos e não há padrões a serem seguidos CMM e CMMI 4 QUALIDADE E TESTE DE SOFTWARE 84 Os processos podem ter alto custo de desenvolvimento podem ocorrer atrasos e problemas no cumprimento de requisitos Nível 2 Gerenciadogerido nesse nível há grande preocupação em seguir um planejamento com análise do andamento das tarefas desig nadas Há maior possibilidade de cumprimento de prazos requisitos objetivos e padrões considerando o acompanhamento por gerentes Nível 3 Definido no 3º nível há padronização e os processos são bem caracterizados e entendidos Há padrões ferramentas procedimentos e métodos bemdefinidos Há detalhe e rigor na descrição dos processos Nível 4 Quantitativamente gerenciadoGerido quantitativamente nesse nível os processos são controlados com base em métodos esta tísticos números o que permite que sejam mais bem compreendidos e comparados facilitando o acompanhamento do desempenho da empresa Há armazenamento de informações em banco de dados o que auxilia na tomada de decisões Nível 5 Em otimização no último nível a busca pela melhoria con tínua dos processos é o principal foco podendo ser obtida com o uso de novas tecnologias e inovações estabelecendose objetivos de melhoria Frequentemente esses objetivos são medidos e avaliados fazendo com que seja criado um ciclo de melhoria contínua dos processos Figura 2 Níveis de maturidade do CMMI por estágios Fonte ISD Brasil 2019 documento online Foco contínuo na melhorias dos processos Processos são medidos e controlados Processos são caracterizados pela organização e são proativos Processos são caracertizados por projeto e as açôes são frequentemente reativas Processos são imprevisíveis pouco controlados e reativos Inicial Gerenciado Defnido Quatitativamente Gerenciado Otimização 1 2 3 4 5 5 CMM e CMMI 85 Normas e Introdução a Tipos de Testes UNIDADE 2 CMM e CMMI PARTE 2 Conforme Morgado et al 2007 documento online o modelo de maturidade CMMI descreve um caminho evolucionário que começa com processos imaturos inicial e segue até um processo maduro e disciplinado otimizado onde é possível o controle do processo de produção de software por meio de métricas e modelos estatísticos É importante salientar que o processo do CMMI inclui três disciplinas ou corpos de conhecimento body of knowledge sendo elas 1 Engenharia de sistemas é uma ciência aplicada para o desenvolvimento e a manutenção de produtos de alta complexidade como carros aviões chips de computador entre outros 2 Engenharia de software é uma ciência aplicada para a especificação o desenvolvimento a manutenção e a criação de software com a aplicação de tecnologias e práticas de gerência de projetos e outras disciplinas buscando organização produtividade e qualidade 3 Engenharia de hardware está diretamente relacionada com os processos que envolvem os componentes físicos Ou seja projetar desenvolver testar produzir instalar e integrar dispositivos Estuda as técnicas as metodologias e os instrumentos computacionais que automatizam processos e desenvolvem soluções baseadas no uso do processamento de dados Em março de 2018 foi disponibilizada a versão 20 do CMMI em que o conceito de nível está contido em cada área de processo PA com foco em prover conteúdo informativo em linguagem simples e conteúdo específico para desenvolvimento de produtos com conceito ágil e metodologia Scrum Áreaschave de processo As KPAs são os requisitos para a obtenção de um nível no CMM e são cumu lativas ou seja para a organização atingir um nível de maturidade ela deve CMM e CMMI 6 QUALIDADE E TESTE DE SOFTWARE 86 satisfazer todas as KPAs daquele nível e do nível anterior Cada uma dessas KPAs identifi ca atividades a serem seguidas pela empresa para atingir os objetivos de desenvolvimento da capacidade do processo Vejamos Nível 1 nível inicial em que há defi ciência no planejamento e difi culdades na realização de previsões os processos são desorganizados e até caóticos Nível 2 no nível repetível as técnicas básicas de gerenciamento de projetos são estabelecidas há maior probabilidade de cumprir os compromissos de requisitos prazos e custos desde que semelhantes a outros realizados ante riormente Nesse nível as áreaschave são gerência de requisitos planejamento de projetos supervisão e acompanhamento de projetos Nível 3 no nível defi nido processos utilizados são estabelecidos e padro nizados em toda a organização sendo as áreaschave foco no processo de organização definição do processo de organização programa de treinamento Nível 4 no nível gerenciado quantitativamente há monitoramento e controle dos processos por meio da coleta e análise de dados estabelecendose metas quantitativas de qualidade de produtividade para as atividades do processo e para os produtos As áreaschave são gerência quantitativa de processos e gerência de qualidade do software Nível 5 no nível de otimização há engajamento na melhoria contínua dos processos por meio do monitoramento do feedback dos processos atuais e da introdução de processos inovadores As áreaschave são prevenção de defeitos gerência da evolução dos processos e gerência da evolução das tecnologias 7 CMM e CMMI 87 Normas e Introdução a Tipos de Testes UNIDADE 2 CMM e CMMI PARTE 2 Em sua representação contínua as áreaschave são divididas conforme o Quadro 1 a seguir Fonte Adaptado de Koscianski e Soares 2007 Gerência de processos Foco no processo Definição do processo Treinamento Desempenho de processo Inovação e implantação Gerência de projeto Planejamento de projeto Controle e monitoramento de projeto Gerência de acordo com fornecedores Gerência de projeto integrada Gerência de riscos Integração da equipe Integração de fornecedores Gerência quantitativa de projeto Engenharia Gerência de requisitos Gerência de desenvolvimento Solução técnica Integração de produto Verificação Validação Suporte Gerência de configuração Garantia de qualidade de produto e processo Medida e análise Análise de decisão e resolução Ambiente organizacional para integração Resolução e análise de causas Quadro 1 Divisão das áreaschave na representação contínua CMM e CMMI 8 QUALIDADE E TESTE DE SOFTWARE 88 Quanto ao CMMI por estágio a maturidade é medida por um conjunto de processos Assim também é necessário que todos os processos atinjam o nível de maturidade de determinado nível para que a empresa alcance o nível de maturidade desejado Em sua representação por estágios as áreaschave são divididas conforme o Quadro 2 a seguir Nível 1 Inicial Não possui áreas de processo Nível 2 Gerenciadogerido Gerenciamento de requisitos REQM requirements management Planejamento de projeto PP project planning Acompanhamento e controle de projeto PMC project monitoring and control Gerenciamento de acordo com fornecedor SAM supplier agreement management Medição e análise MA measurement and analysis Garantia da qualidade de processo e produto PPQA process and product quality assurance Gerência de configuração CM configuration management Nível 3 Definido Desenvolvimento de requisitos RD requirements development Solução técnica TS technical solution Integração de produto PI product integration Verificação VER verification Validação VAL validation Foco de processo organizacional OPF organizational process focus Definição de processo organizacional OPD organizational process definition Treinamento organizacional OT organizational training Gerenciamento integrado de projeto IPM integrated project management Gerenciamento de riscos RSKM risk management Análise de decisão e resolução DAR decision analysis and resolution Quadro 2 Divisão das áreaschave na representação por estágios Continua 9 CMM e CMMI 89 Normas e Introdução a Tipos de Testes UNIDADE 2 CMM e CMMI PARTE 2 As áreas de processo variam com base no modelo escolhido não sendo as mesmas áreas para todos os modelos CMMIDEVCMMI para desenvolvimento CMMIACQ CMMI para aquisição ou CMMISVCCMMI para serviços Os níveis de CMM e CMMI O CMMI como dito anteriormente pode ser considerado uma evolução do CMM tendo como objetivo melhorar os processos das empresas e fazer com que esses processos sejam executados da melhor maneira e com o menor custo Existem alguns sintomas de falhas no processo como compromissos não cumpridos entregas atrasadas surpresas com custos não planejados falta de progresso problemas de qualidade defeitos no produto reclamações dos clientes entre outros que geram a necessidade de melhoria no processo de software como a utilização dos modelos CMM e CMMI Quanto ao CMMI o nível inicial tem como cenário o acúmulo de trabalho o abandono de planos e procedimentos os defeitos no produto os clientes e funcionários insatisfeitos a pouca repetibilidade a dificuldade em realizar previsões e a dependência de cada colaborador que se abandona a empresa é motivo de sofrimento para esta Todavia é importante observar que o fato Nível 4 Quantitativamente gerenciadogerido Desempenho de processo organizacional OPP organizational process performance Gerenciamento quantitativo de projeto QPM quantitative project management Nível 5 Otimização Gestão do desempenho organizacional OPM organizational performance management Análise causal e resolução CAR causal analysis and resolution Quadro 2 Divisão das áreaschave na representação por estágios Continuação CMM e CMMI 10 QUALIDADE E TESTE DE SOFTWARE 90 de uma empresa ter processos desorganizados e caóticos não significa dizer que tem produtos finais ruins No entanto para que bons produtos sejam entregues geralmente é necessário um esforço enorme dos colaboradores além de aumento de custos e excesso de prazo Nesse primeiro nível não é possível repetir sucessos anteriores já que estes estarão ligados mais a sucessos individuais de um colaborador por exemplo que se sair da empresa vai deixar a empresa desfalcada de mão de obra do que ao sucesso organizacional Além disso é comum a empresa negligenciar algumas fases do processo como a de documentação e a de testes A mudança para o nível 2 de maturidade consiste na realização de sete áreas de processo que contribuem para a eficiência da gerência de projeto conforme mostra o Quadro 2 O nível gerenciado pode ser alcançado com a contratação de gerentes de projeto profissionais e experientes permitindo que eles façam seus trabalhos Por exemplo podem existir datas de entrega definidas no cronograma as quais serão constantemente acompanhadas O gerente de projeto então conseguirá identificar a eventual possibilidade de atraso e tentará solucionar o problema por exemplo alocando mais pessoas em determinada tarefa O segundo nível de maturidade gerenciado não garante o sucesso do projeto mas aumenta a consciência do que está acontecendo As organiza ções que usam as práticas do nível 2 de maturidade geralmente usam dados e métricas para garantir que seus projetos estejam dentro do orçamento no prazo e que os objetivos sejam cumpridos Organizações nesse nível têm maior probabilidade de cumprir compro missos relacionados a requisitos custos e prazos quando se trata de projetos semelhantes a outros já realizados Elas são disciplinadas a executar projetos mas não têm preparo para mudanças já que são incapazes de prever o resultado da adoção de novas ferramentas e métodos ou do desenvolvimento de novos produtos por exemplo organizações que desenvolvem software para web e adquirem experiência na área para projetos futuros O nível 3 de maturidade definido diferese do nível 2 porque nele há o desenvolvimento de uma maneira organizacional de fazer negócios A mudança para o nível 3 de maturidade consiste na realização de onze áreas de processos que contribuem para a padronização dos processos na organização conforme mostra o Quadro 2 Uma organização que esteja no terceiro nível deve contar com pessoas que são especialistas em gerenciamento de processos trabalho técnicooperacional de entrega desenvolvimento ou serviços etc e mudança organizacional e desenvolvimento O objetivo é facilitar a comunicação e a 11 CMM e CMMI 91 Normas e Introdução a Tipos de Testes UNIDADE 2 CMM e CMMI PARTE 2 coordenação em toda a organização e aprender e compartilhar observações dos sucessos e fracassos de outros projetos Além disso buscase estabelecer normas de desempenho sobre como realizar o trabalho materialmente essencial da organização e implementar mecanismos para melhoria contínua aprendizado crescimento estratégico e tomada de decisões As organizações do nível 3 devem utilizar dados e métricas que ajudem a entender seus custos internos e sua eficácia No nível 3 estabelecese uma infraestrutura de processos que permite adaptação a mudanças há padronização de ferramentas e o conhecimento se torna qua litativo sobre os processos que são bem documentados A equipe trabalha de forma interativa as atividades são planejadas estáveis e repetitivas existe treinamento de pessoal e como consequência há uma melhora na qualidade de software pois custos tarefas e prazos estão sob controle Ou seja no nível 3 os procedimentos são padronizados e devem prever a aplicação em projetos diferentes Já no nível 4 de maturidade os projetos as decisões tomadas e a qualidade de processos serviços e produtos são todos medidos com base em números A mudança para o nível 4 de maturidade consiste da realização de duas áreas de processos que contribuem para a gerência quantitativa dos processos na organização conforme mostra o Quadro 2 Nesse nível há um tratamento quantitativo medindose sempre a qualidade da produtividade Há bases de dados e métricas quantitativas são estabelecidas para avaliar os processos e produtos Há também gerenciamento de riscos de forma que os produtos tendem a apresentar maior qualidade Assim a diferença do nível 4 para o 3 de maturidade é que há um aumento da previsibilidade do desempenho de processos Por fim a mudança para o nível 5 de maturidade consiste na realização de duas áreas de processos que contribuem para a otimização dos processos na organização conforme mostra o Quadro 2 O nível 5 traz processos em melhoria contínua otimizados para as necessidades de cada momento com identificação dos pontos fracos adoção de novas tecnologias resolução de defeitos e estudo das causas e das lições que serão utilizadas em processos seguintes Os níveis de maturidade 4 e 5 são muito originais Juntos são chamados de alta maturidade no CMMI Nesses níveis há adição de especialistas no uso de técnicas quantitativas para gerenciar o desempenho tático estratégico e operacional da organização Utilizamse os dados dos níveis 2 e 3 para ajudar a controlar a variação e tornar as operações mais previsíveis CMM e CMMI 12 QUALIDADE E TESTE DE SOFTWARE 92 As organizações de níveis de maturidade 4 e 5 são melhores em prever seu desempenho e gerenciar seu trabalho do que as empresas com recursos de nível 3 Há além disso maior conscientização de como seus processos funcionam e se podem ou não confiar em seus processos para alcançar os resultados desejados As principais abordagens a serem feitas pelas organizações de nível de maturidade 3 para melhorar o desempenho é trabalhar na eliminação de desperdícios reduzindo a contagem de colaboradores efetuando mudanças frequentes na estrutura organizacional e linearmente aumentando o crescimento marginal por meio do aumento das vendas O espírito do CMMI deve ser sempre adotado encarandose o desenvolvi mento do software com seriedade planejamento e controle sendo o CMMI uma conquista importante para a melhoria do desenvolvimento de software ISD Brasil O que é CMMI 2019 Disponível em httpwwwisdbrasilcombroque ecmmiphp Acesso em 29 jan 2019 KOSCIANSKI A SOARES M S Qualidade de software aprenda as metodologias e técnicas mais modernas para o desenvolvimento de software 2 ed São Paulo Novatec 2007 MORGADO G P et al Práticas do CMMI como regras de negócio Production São Paulo v 17 n 2 p 383394 Aug 2007 Disponível em httpwwwscielobrscielo phpscriptsciarttextpidS010365132007000200013 Acesso em 29 jan 2019 PRESSMAN R S MAXIN B R Engenharia de software uma abordagem profissional 8 ed Porto Alegre Bookman 2016 VETORAZZO A S Engenharia de software Porto Alegre SAGAH 2018 13 CMM e CMMI QUALIDADE E TESTE DE SOFTWARE 94 ENCERRA AQUI O TRECHO DO LIVRO DISPONIBILIZADO PELA SAGAH PARA ESTA PARTE DA UNIDADE PREZADO ESTUDANTE unidade 2 O conteúdo deste livro é disponibilizado por SAGAH Parte 3 Introdução aos Testes de Software QUALIDADE E TESTE DE SOFTWARE 96 Introdução aos testes de software Objetivos de aprendizagem Ao final deste texto você deve apresentar os seguintes aprendizados Definir teste de software Apontar as causas de defeitos em software e o papel do analista de teste de software Explicar a qualidade de software e o papel do teste de software na obtenção dela Introdução O teste de software mostra as falhas do sistema antes que o desenvol vimento seja concluído A partir desse teste é possível assegurar que as funcionalidades solicitadas estejam presentes e de acordo com o esperado Quando as falhas são corrigidas nas fases finais do projeto o custo é maior do que se fossem solucionadas no início Por isso muitas empresas profissionais e equipes preferem fazer um desenvolvimento orientado aos testes Neste capítulo você vai conhecer a definição de teste de software Você também vai ver quais são as causas de defeitos em softwares e qual é o papel do analista de teste Além disso você vai aprender mais sobre a qualidade dos softwares e o papel do teste na obtenção dela Teste de software Cada vez mais pessoas e organizações utilizam softwares para automatizar e facilitar trabalhos no dia a dia Por isso é necessário que o funcionamento dos softwares seja correto ou seja que eles executem as suas funções sem produzir erros 97 Normas e Introdução a Tipos de Testes UNIDADE 2 Introdução aos Testes de Software PARTE 3 A verificação dos softwares ocorre por meio de testes realizados antes da en trega do produto aos consumidores O teste é a última etapa do desenvolvimento de um software Como você deve imaginar é uma fase de suma importância Por meio dela é possível verificar e resolver problemas e bugs caso ambos sejam encontrados O teste de software tem como objetivo encontrar erros e produzir softwares com a maior qualidade possível tornandoos seguros e confiáveis para utilização A qualidade de software segundo Pressman e Maxim 2016 deve ser implementada por meio de atividades que se concentram na gestão de qua lidade tais como padrões IEEE e ISO revisões e auditorias testes coleta e análise de erros e defeitos gerenciamento de mudanças educação gerência de fornecedores administração de segurança proteção e gestão de riscos Afinal um programa de computador é um produto que utiliza diversas linguagens de programação tendo disponível uma rigorosa abordagem para a especificação dos requisitos a análise o projeto o desenvolvimento e os testes de software PRESSMAN MAXIM 2016 Para a realização dos testes utilizase um plano de teste que é um do cumento de planejamento do projeto de teste O plano de teste deve conter todas as etapas de validação e verificação do software a serem observadas A validação compreende o processo de examinar se o software satisfaz ou não a necessidade do usuário Validase o software que é compatível com os requisitos solicitados Por sua vez a verificação de software é o processo que confirma que o programa satisfaz todos os requisitos Na Figura 1 a seguir veja que tipos de teste devem fazer parte do plano de teste Figura 1 Plano de testes de alto ní vel Fonte APAICRVS 201 Introdução aos testes de software 2 QUALIDADE E TESTE DE SOFTWARE 98 Os módulos de software são testados de forma individual para que os erros sejam identificados e eliminados Caso o produto seja um software a questão dos testes tornase muito mais complexa Os requisitos de software podem variar entre os diferentes ambientes de software básico nos quais os programas vão ser instalados pois pode haver incompatibilidade Por exemplo um software que foi desenvolvido para funcionar em um sistema operacional do Windows pode não ter o mesmo funcionamento em um sistema operacional da Apple O teste de configuração ou instalação é responsável por emitir o resultado pertinente a essa questão Os testes são classificados de diferentes formas Veja a seguir Teste de componentes componentes do software são testados isoladamente Teste de montagem componentes do software são testados em conjunto Teste de produto o software é testado para confirmar que os requisitos funcionais estão presentes Teste de integridade de sistema testa a robustez do software ou seja a resistência a falhas Teste de aceitação do utilizador usuários finais utilizam casos e cenários para provar que o sistema se adequa à sua finalidade Teste de desempenho o sistema é testado em relação à velocidade ou à eficácia conforme definição nos requisitos não funcionais Teste de performance avalia a capacidade de resposta a disponibili dade a confiabilidade e a robustez do software diante de determinada carga de trabalho em condições específicas e por determinado tempo O objetivo é verificar comportamentos diferentes que condições diversas podem gerar Teste de estresse o sistema é testado até o ponto de ruptura para avaliar características de falhas Teste de integração verifica se um ou mais componentes combinados funcionam de maneira satisfatória Teste de usabilidade é realizado com foco na experiência do usuário analisando a consistência da interface o layout o acesso a funciona lidades a facilidade de utilização e a viabilidade da manipulação do sistema pelo usuário Teste de configuração ou instalação verifica como o software se comporta ao ser instalado em diferentes configurações de software e hardware 3 Introdução aos testes de software 99 Normas e Introdução a Tipos de Testes UNIDADE 2 Introdução aos Testes de Software PARTE 3 Teste de segurança verifica se o sistema e os dados são acessados de forma segura somente por quem executa as ações Teste funcional verifica os requisitos funcionais as funções e os casos de uso ou seja analisa se a aplicação faz o que deveria fazer Teste de unidade testa um componente de forma isolada Teste de volume verifica o comportamento do sistema funcionando com o volume normal de dados e transações envolvendo o banco de dados durante um longo período Geralmente os testes são realizados por um grupo de profissionais Entre os testes realizados estão o teste de caixabranca que verifica se o códigofonte foi implementado corretamente e o teste de caixapreta que verifica se as principais funções do sistema estão de acordo com os requisitos solicitados pelo cliente Há também os testes de caixacinza que são testes funcionais ou estruturais também chamados de testes de regressão À medida que são liberadas novas versões novos bugs podem ser incluídos O teste de caixabranca utiliza a perspectiva interna do sistema para realizar a modelagem dos casos de teste no software isso se refere ao códigofonte no hardware a cada nó do circuito No teste da caixapreta essa perspectiva interna é desconhecida e são testadas e mensuradas somente interfaces do software Porém as duas técnicas podem ser utilizadas em conjunto dando origem à técnica da caixacinza em que é feita a modelagem de teste conhecendose a estrutura interna do sistema porém a execução ignora esse aspecto assim como ocorre no teste de caixapreta Um erro simples pode ocasionar danos graves inclusive à vida O Patriot era um software de balística e orientação de mísseis utilizado na Guerra do Golfo No momento do seu uso ocorreu um erro de arredondamento Assim o software calculou incorretamente o tempo ignorando os mísseis Scud vindos do Iraque O erro ocasionou a morte de 28 soldados e deixou outros 100 feridos Uma questão importante que você deve considerar em testes de softwares é o custo da verificação dos softwares Além disso existem ferramentas de suporte Veja os exemplos a seguir Introdução aos testes de software 4 QUALIDADE E TESTE DE SOFTWARE 100 qTest ferramenta de teste de desempenho Testlink ferramenta open source de gerenciamento de testes de software que possibilita que equipes de teste trabalhem de forma sincronizada Loadrunner ferramenta de teste de software da Micro Focus utili zada para testar aplicativos medir o comportamento do sistema e o desempenho sob a carga Como você pode notar é um grande desafio escolher e planejar a com binação adequada de técnicas que serão aplicadas nos testes de software e ao mesmo tempo satisfazer os custos previstos para o desenvolvimento do projeto Acesse o link a seguir para ler a respeito de defeitos erros e falhas relacionados a testes de software httpsqrgopagelinkznWEQ Causas e defeitos em software e o papel do analista de teste Defeitos bugs são imperfeições ou problemas que podem ser encontrados no software ou em seus processos de levantamento de requisitos análise e projeto Os defeitos também podem decorrer de algo que foi implementado de maneira errada no códigofonte Porém os bugs não são causados somente por erros de programação Segundo o International Software Testing Qualifi cations Board 2016 selo de qualidade para testadores de software criado em 2002 há diferenças entre um bug um erro e uma falha Veja a seguir Bug tratase do resultado de um erro de código Uma anomalia é gerada no funcionamento do software por meio de uma instrução errada ou um comando incorreto Erro é decorrente da ação humana Um resultado incorreto é produzido como uma falha de escrita em um códigofonte Falha é o resultado da execução de um defeito gerado no código 5 Introdução aos testes de software 101 Normas e Introdução a Tipos de Testes UNIDADE 2 Introdução aos Testes de Software PARTE 3 Durante as fases de análise de requisitos especificação desenho e codificação do sistema podem ocorrer erros ou defeitos Eles geralmente são causados por especificações de requisitos realizadas de maneira errada requisitos interpretados de forma incorreta pelos analistas especificações funcionais e especificações técnicas mal formuladas códigosfonte implementados de forma incorreta dados de entrada ou de saída errados ou inconsistentes bugs corrigidos de forma errada A correlação existente entre as causas e os defeitos gerados está representada no Quadro 1 a seguir Defeito Causa Não tratamento de erros Falta de precaução contra travamentos e comportamentos inesperados do sistema em relação às funcionalidades bem como não antecipação de falhas e possíveis erros Erro de cálculo Cálculos realizados de forma incorreta como estouro de tama nho de campos e algoritmos implementados de forma errada Por exemplo no caso de implementação em formulários o tama nho de um campo pode não ser o mesmo esperado no banco de dados nesse caso os dados não serão salvos corretamente Manipulação de dados Dados tratados de forma errada como datas e campos nulos Códigofonte Não realização do controle correto do códigofonte do software recursos que não tenham sido previstos e que este jam implementados no código Documen tação Não manutenção da documentação atualizada de acordo com o que foi solicitado assim como das mudanças realizadas ao longo do projeto todas devem ser devidamente registradas Testes Ausência de planejamento execução e definição de escopos de desenvolvimento adequados falta de uma política de testes Usabilidade Dificuldades de usabilidade no que diz respeito à facilidade de uso à forma como são dispostas as informações na tela a interface agradável etc Quadro 1 Correlação entre causas e defeitos gerados Introdução aos testes de software 6 QUALIDADE E TESTE DE SOFTWARE 102 As causas dos defeitos geralmente se relacionam à especificação Entre elas você pode considerar erros no levantamento dos requisitos questões de design e erros na implementação do códigofonte Entre essas causas a que se destaca é o levantamento dos requisitos Nesse sentido o analista de sistemas deve estar atento às mudanças aos requisitos e à implementação O profissional de teste de software tem como premissa realizar a análise do sistema sob a visão dos testes para que possa modelar e construir os casos de testes Os casos de testes são um conjunto de condições valores de en trada précondições de execução entre outros elementos desenvolvidos para determinado objetivo ou condição O analista de teste deve analisar o software de forma criteriosa prestar atenção aos detalhes entender as falhas de software conhecer o sistema ou aplicativo de teste e ter experiência em testes Além disso ele deve conhecer técnicas por exemplo UML linguagem que define artefatos que ajudam nas tarefas de modelar e documentar os sistemas orientados a objetos modelo V modelo de verificação e validação em que se observa se o software está sendo desenvolvido da maneira correta e se ele atende ao que foi solicitado normas normas e padrões de qualidade tais como ISO 9000 e ISO 9126IEC banco de dados estrutura do banco de dados ferramentas de teste ferramentas que auxiliam nos testes de software Entre as funções do analista de teste você pode considerar estabelecer estratégias planejar executar e monitorar testes de software identificar os itens que deverão ser avaliados pelo teste definir tipos de testes de acordo com os dados de entrada coletar e gerenciar os dados de testes avaliar o resultado de cada ciclo de teste 7 Introdução aos testes de software 103 Normas e Introdução a Tipos de Testes UNIDADE 2 Introdução aos Testes de Software PARTE 3 A qualidade do software e o papel do teste Um software de qualidade é aquele que satisfaz as necessidades dos usuários Pressman e Maxim 2016 defi nem a qualidade de software como uma gestão 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 Existem fatores de qualidade internos e externos Em relação aos fatores internos tratandose da estrutura do software a avaliação é relacionada sob a visão do desenvolvedor Geralmente quem realiza é o responsável por toda a manutenção do software inclusive pela modularidade pela portabilidade etc Os sistemas de software devem ser rápidos confiáveis fáceis de usar legíveis modulares estruturados e assim por diante Mas esses adjetivos descrevem dois tipos diferentes de qualidades Há por exemplo qualidades como velocidade ou facilidade de uso cuja presença ou ausência em um produto de software pode ser detectada pelos usuários Essas propriedades podem ser chamadas de fatores de qualidade externos A chave para alcançar esses fatores externos está nos internos para que os usuários aproveitem qualidades visíveis os designers e implementadores devem ter aplicado técnicas internas o que garante as qualidades ocultas MEYER 1997 Entre os fatores externos você pode considerar modularidade software constituído por módulos portabilidade facilidade de utilizar o mesmo software em ambientes diferentes correção realização de tarefas de acordo com a especificação de requisitos Pressman e Maxim 2016 mencionam os fatores de qualidade ISO 9126 que definem os atributos fundamentais de qualidade de um software para computador Esse padrão ISO identifica seis atributos fundamentais de qua lidade de software funcionalidade implica a satisfação das necessidades declaradas com adequabilidade exatidão conformidade e segurança confiabilidade é medida pela probabilidade de ocorrência de falhas usabilidade é medida por fatores não quantificáveis entre eles os itens de interface Introdução aos testes de software 8 QUALIDADE E TESTE DE SOFTWARE 104 eficiência implica a boa utilização de recursos como memória e processadores extensibilidade é a possibilidade de adaptação a novas inclusões facilidade de manutenção significa que a correção pode ser realizada no software com base nos atributos de facilidade de análise realização de mudanças estabilidade e testabilidade A seguir veja os fatores definidos pela norma ISO 9126 2001 para que o software tenha um nível de qualidade adequado Correção implica a capacidade de o software realizar as tarefas de forma precisa ou seja de acordo com os requisitos especificados pelo cliente Extensibilidade é a forma como se podem inserir modificações no software ou seja ele deve ser flexível o suficiente para que modificações sejam realizadas de forma fácil Reusabilidade é a facilidade com que os softwares podem ser reutili zados totalmente ou em partes para novas aplicações Isso faz com que haja economia e níveis de qualidade satisfatórios durante a produção de novos softwares pois ocorrerá menor esforço na escrita e menor risco de erros Robustez confiabilidade essa capacidade mostra que o software funciona mesmo em condições não validadas nas especificações dos requisitos Compatibilidade referese à facilidade de combinar softwares com outros componentes Ou seja ao ser utilizado o software deve fun cionar plenamente sem interferir em outras aplicações Dessa forma não deve haver problemas devido à execução de dois ou mais tipos de softwares ao mesmo tempo Como exemplo considere a estrutura de dados padronizada as interfaces homemmáquina padronizadas ou ainda a padronização de formatos de arquivos Portabilidade é a facilidade com que um software pode ser transposto de um ambiente para outro de acordo com os subatributos adaptabili dade facilidade de instalação conformidade e facilidade de substituição PRESSMAN MAXIM 2016 É um dos fatores difíceis de se obter pois nem sempre é possível alinhar o software às diferentes plataformas sistemas operacionais e periféricos 9 Introdução aos testes de software 105 Normas e Introdução a Tipos de Testes UNIDADE 2 Introdução aos Testes de Software PARTE 3 Eficiência esse fator está diretamente relacionado à utilização racional dos recursos de hardware e do sistema operacional em que o software será instalado Entre esses recursos estão memória recursos gráficos bibliotecas entre outros A garantia da qualidade de um software Software Quality Assurance SQA envolve vários aspectos Entre eles a adoção de normas e padrões internacionais ISO e IEEE as revisões técnicas e os testes de software utilizados para encontrar erros a análise e a coleta de erros as auditorias para assegurar que as diretrizes sejam seguidas o gerenciamento de mudanças a educação continuada dos engenheiros de software a gerência dos fornecedores e a adoção de políticas de segurança e gestão de riscos APAICRVS Planeamento de implementaç ã o 6 definir o plano de abordagem e testes S l s n 201 Disponível em httpwwwcrvsdgborgptactivitiesplaneamento deimplementaccca7acc83o6definiroplanodeabordagemetestes Acesso em 27 jun 2019 INTERNATIONAL SOFTWARE TESTING QUALIFICATIONS BOARD Home S l s n 2016 Disponível em httpswwwistqborg Acesso em 27 jun 2019 ISO ISOIEC 91261 Software engineering Product quality Rio de Janeiro ISO 2001 MEYER B Objectoriented software construction New Jersey Prentice Hall 1997 PRESSMAN R MAXIM B Engenharia de software uma abordagem profissional 8 ed Porto Alegre AMGH 2016 Introdução aos testes de software 10 QUALIDADE E TESTE DE SOFTWARE 106 ENCERRA AQUI O TRECHO DO LIVRO DISPONIBILIZADO PELA SAGAH PARA ESTA PARTE DA UNIDADE PREZADO ESTUDANTE Leituras recomendadas ALMEIDA C Introdução ao teste de software S l s n 201 Disponível em httpwww linhadecodigocombrartigo2775introducaoaotestedesoftwareaspx Acesso em 27 jun 2019 DEVMEDIA Testes de software entendendo defeitos erros e falhas Rio de Janeiro DEVMEDIA 2019 Disponível em httpswwwdevmediacombrtestesdesoftware entendendodefeitoserrosefalhas22280 Acesso em 27 jun 2019 KOSCIANSKI A SOARES M Qualidade de software 2 ed São Paulo Novatec 2007 PEZZÈ M YOUNG M Teste e análise de software processos princípios e técnicas Porto Alegre Bookman 2008 SCHACH S R Engenharia de software os paradigmas clássicos orientado a objetos Porto Alegre AMGH 2010 SOFTWARE SYSTEMS ENGINEERING STANDARDS COMMITTEE IEEE standard glossary of software engineering terminology S l IEEE 2019 Disponível em httpstandards ieeeorgfindstdsstandard610121990html Acesso em 27 jun 2019 SOUZA K GASPAROTTO A A importância da atividade de teste no desenvolvimento de software In ENCONTRO NACIONAL DE ENGENHARIA DE PRODUCAO 33 2013 Anais Salvador 2013 Disponível em httpwwwabeproorgbrbibliotecaene gep2013TNSTO17700723030pdf Acesso em 27 jun 2019 TARGETTRUST Os principais tipos de testes de software In TARGETTRUST S l s n 2015 Disponível em httpstargettrustcombrblogos13principaistiposdetestes desoftware Acesso em 27 jun 2019 11 Introdução aos testes de software unidade 2 O conteúdo deste livro é disponibilizado por SAGAH Parte 4 Tipos de Teste QUALIDADE E TESTE DE SOFTWARE 108 Tipos de teste Objetivos de aprendizagem Ao final deste texto você deve apresentar os seguintes aprendizados Explicar os fundamentos dos testes de software Descrever a verificação a validação estática a validação dinâmica e as categorias de teste de software Diferenciar os tipos de teste de software e suas etapas o que testar como testar e quando testar Introdução Existem vários tipos de testes de software Eles podem ser realizados por diferentes pessoas em diversas fases do projeto e com objetivos distintos É importante conhecêlos para entender a sua importância e a sua aplicação durante todo o ciclo de vida do projeto de software Neste capítulo você vai estudar os fundamentos e os tipos de testes de software Também vai conhecer a verificação a validação estática a validação dinâmica e as categorias de testes de software Além disso vai ver os tipos de teste de software e as suas etapas Fundamentos dos testes de software As áreas de engenharia costumam combinar atividades de projeto e construção com atividades de verifi cação intermediária do que está sendo produzido e de verifi cação fi nal do produto pronto Tudo isso seve para que as falhas erros e defeitos sejam identifi cados reduzidos e até mesmo eliminados por completo Na ciência da computação a disciplina de engenharia de software trata seus produtos informatizados da mesma forma Durante o trabalho de desen volvimento de um software de qualidade tanto as atividades de projeto quanto as atividades de verificação têm papel fundamental para o sucesso final As atividades de verificação podem ser entendidas como as atividades de testes 109 Normas e Introdução a Tipos de Testes UNIDADE 2 Tipos de Teste PARTE 4 Como todo projeto o desenvolvimento de um produto de software envolve uma equipe formada por pessoas Naturalmente durante o ciclo de vida do projeto é necessária a comunicação entre os integrantes da equipe É principalmente por esse motivo que os problemas nos softwares acontecem E também é por isso que as atividades de teste são tão importantes Afinal as pessoas possuem formações lógicas opiniões e maneiras de trabalhar diferentes Mesmo que todas trabalhem juntas para atingir o mesmo objetivo tendem a realizar suas atividades da maneira mais fácil o que nem sempre pode resultar em um trabalho coeso e funcional ao final do projeto As atividades de teste são fundamentais para os projetos de desenvolvimento de software principalmente pelos seguintes motivos PEZZÈ YOUNG 2008 descobrir defeitos falhas e erros no software antes que ele seja entregue ao cliente demonstrar que o software atende aos requisitos e às necessidades dos usuários que vão realizar as suas tarefas por meio dele garantir maior segurança aos usuários na utilização do software entregue aumentar a possibilidade de continuidade do negócio dos clientes melhorar a qualidade dos softwares produzidos devido à experiência adquirida com os projetos desenvolvidos melhorar a imagem do software e da própria fábrica de software perante os clientes e usuários por fornecer produtos que atendem às suas expectativas diminuir ao máximo o tempo e as despesas gastos na correção de problemas As atividades de projeto e de testes podem ser utilizadas para projetos de diferentes tipos Isso inclui desde aqueles mais simples até os mais complexos que resultam em produtos extremamente customizados pelo cliente e cujo sucesso é altamente necessário A escolha dessas atividades depende do tipo de projeto do produto que se quer produzir dos requisitos de qualidade e da maneira como será feito o desenvolvimento As atividades de testes dos produtos fabricados em série envolvem um con junto predefinido e sistematizado de análises e testes Tais análises e testes são capazes de indicar se o produto satisfaz o nível de qualidade esperado para ele Os softwares por sua vez por serem mais personalizados de acordo com o cliente precisam de conjuntos específicos de análises e testes A ideia é atender também a níveis de qualidade individuais de cada projeto Quanto mais complexo for o software mais complexas serão as atividades de verificação e testes envolvidas Tipos de teste 2 QUALIDADE E TESTE DE SOFTWARE 110 Nas indústrias onde a fabricação de produtos é muito repetitiva é comum que as atividades de verificação sejam feitas em apenas partes dos produtos ou nos produtos finais mas em esquema de amostragem Ou seja apenas algumas peças são escolhidas para serem testadas Isso acontece porque devido ao alto nível de padronização o processo de fabricação já é bastante confiável Assim testar cada produto de maneira individual poderia trazer uma despesa extra desnecessária Por outro lado se os produtos forem computadores carros aviões navios instrumen tos cirúrgicos cofres e outros de grande importância mesmo que sejam fabricados em série é necessário verificálos de maneira individual antes que sejam entregues aos seus usuários finais Isso acontece porque são artefatos em que a qualidade precisa ser muito elevada e as falhas nem sempre são toleradas Já no caso dos softwares os testes e as atividades de verificação são essenciais e devem ser feitos sempre de maneira individualizada O motivo é que via de regra cada software produzido atende às expectativas de um só cliente Nesse sentido o software deve ser testado durante o seu desenvolvimento até a entrega ao usuário final O custo das atividades de análise verificação e testes geralmente corres ponde a mais da metade do custo total previsto para todo o desenvolvimento e ainda para a manutenção de um projeto de software Já existem algumas ferramentas e técnicas que podem ser utilizadas em tempo de programação para diminuir os erros e falhas de desenvolvimento Contudo ainda não existe uma maneira de eliminar completamente os problemas de um software para que ele seja entregue perfeito ao usuário final Apesar de parecer um paradoxo a verdade é que a tentativa de destruir a confiabilidade de um software por meio da identificação de erros defeitos e falhas resulta no aumento da sua confiabilidade Isso acontece pois uma vez corrigidos todos os problemas o produto entregue ao cliente atende objetiva mente às suas necessidades tornando agradável a experiência de utilizálo É importante você notar que quanto mais cedo os testes forem iniciados menores serão o custo e o prazo utilizados na correção dos problemas encontra dos Por isso existem estágios pelos quais os testes de software normalmente passam PRESSMAN 2011 Veja a descrição dos estágios a seguir e depois observe a Figura 1 Planejamento elaboração e revisão da estratégia e do plano de teste Preparação preparação do ambiente de testes incluindo equipamentos softwares rede pessoal e ferramentas 3 Tipos de teste 111 Normas e Introdução a Tipos de Testes UNIDADE 2 Tipos de Teste PARTE 4 Procedimentos iniciais elaboração de um documento que estabelece o acordo entre as partes envolvidas nos testes objetivo pessoal res ponsabilidades etc Especificação elaboração e revisão dos casos de teste manuais roteiros de testes e automáticos scripts Execução execução dos testes planejados conforme os casos de teste elaborados e geração dos registros de resultados relatórios de testes Entrega conclusão do processo de testes com a entrega da parte ou do todo do sistema Figura 1 Estágios dos testes de software Os problemas que um software pode apresentar são inúmeros e dife renciados para cada projeto assim como as maneiras de identificálos e de corrigilos É por esse motivo que não existe uma maneira correta e predefinida de estabelecer as atividades e etapas envolvidas nos testes de software É preciso analisar o projeto em questão para identificar a melhor maneira de aplicar as atividades de testes ao longo do desenvolvimento do produto de software Tipos de teste 4 QUALIDADE E TESTE DE SOFTWARE 112 Verificação validação estática validação dinâmica e categorias de teste de software Antigamente era comum que a fabricação dos softwares englobasse todas as atividades de análise e testes apenas no fi nal do ciclo de vida de desenvol vimento Existia um profi ssional que se chamava testador e a sua atividade básica consistia em realizar a execução de casos de teste para um produto completamente pronto Atualmente as empresas fabricantes de softwares já conseguem compre ender melhor que a realização dos testes faz parte do processo de verificação e validação Tal processo por sua vez é fundamental para a avaliação e para a manutenção da qualidade requerida de um produto de software A verificação e a validação têm como propósito principal garantir que o software esteja adequado aos seus objetivos e que atenda às expectativas dos clientes Em outras palavras essas etapas garantem que o software cumpra as suas especificações aquilo a que ele se propõe PEZZÈ YOUNG 2008 Na verificação existe uma análise para entender se o software atende aos requisitos funcionais e não funcionais que foram definidos para ele A atividade de validação consiste em verificar se o software atende às expectativas e necessidades do usuário final Apesar de esses dois termos terem significados diferentes as duas atividades não acontecem de maneira independente ou sequencial As atividades de verificação e de validação têm início até mesmo antes que um projeto de desenvolvimento de software seja idealizado Isso porque é preciso que os gestores de projeto e de tecnologia de informação tenham em mente se a sua equipe possui as competências necessárias Ou seja eles devem verificar se a sua equipe tem o conhecimento a habilidade e a atitude necessárias para desenvolver produtos de software que satisfaçam às necessidades e expectativas dos usuários Essa verificação se chama estudo de viabilidade 5 Tipos de teste 113 Normas e Introdução a Tipos de Testes UNIDADE 2 Tipos de Teste PARTE 4 Na área da administração a competência de um funcionário é definida pelo conjunto de três elementos Veja a seguir Conhecimento é o saber É tudo o que se adquire por meio de cursos treinamentos livros experiência de vida Habilidade é o saber fazer É aquilo que depende de prática de treino de saber lidar com os acertos e com os erros cometidos Atitude é o querer fazer É a ação necessária para colocar em prática os conheci mentos e a habilidade Normalmente é o elemento essencial para mudanças de procedimentos Se o estudo de viabilidade for positivo e indicar que a equipe é capacitada para participar do projeto então as atividades de verificação e validação começam Elas ocorrem juntamente às atividades de desenvolvimento tendo fim depois que o produto final for liberado para o cliente Atualmente é natural que os produtos de software sejam entregues em etapas passando por reavaliações e ajustes dos requisitos caso sejam neces sários Por esse motivo é muito importante que as atividades de verificação e validação sejam pensadas de antemão para que se consiga cumprir a previsão de custos e prazos O estudo de viabilidade é a primeira atividade que deve ser realizada em um projeto de software rumo à entrega de um produto satisfatório Esse estudo está aliado às atividades de verificação validação e desenvolvimento São as atividades de verificação que avaliam se o produto que está sendo construído tem coerência com os requisitos e com a qualidade esperada tanto nas entregas em etapas como no produto final No caso das atividades de validação é avaliado se existe coerência entre os produtos intermediários e o final apresentados ao usuário Além disso são avaliadas as expectativas do usuário para o software PEZZÈ YOUNG 2008 Em seguida é preciso escolher o conjunto de técnicas de teste e de análise necessárias Para isso é preciso levar em consideração o nível de qualidade esperado o custo o prazo e os recursos disponíveis para o desenvolvimento do software É possível combinar as técnicas e as ferramentas disponíveis o que pode trazer ganhos para o andamento do projeto Em síntese nenhuma técnica de teste ou análise serve sozinha a todos os objetivos A seguir você pode ver as razões primárias para combinar técnicas PEZZÈ YOUNG 2008 Tipos de teste 6 QUALIDADE E TESTE DE SOFTWARE 114 Eficácia para diferentes classes de erros por exemplo condições de corrida são muito difíceis de se encontrar com teste convencional mas podem ser detectadas com análise estática Aplicabilidade em diferentes etapas do projeto por exemplo você pode aplicar técnicas de inspeção inicialmente aos requisitos e re presentações de projeto que não são apropriados para análises mais automáticas Diferenças de objetivos por exemplo o teste sistemático não randô mico busca maximizar a detecção de falhas mas não pode ser usado para medir confiabilidade para isso o teste estatístico é necessário Compromissos entre custo e garantias por exemplo você pode utilizar uma técnica relativamente custosa para garantir algumas propriedades essenciais de componentes centrais como um kernel de segurança enquanto as mesmas técnicas seriam caras demais se aplicadas a todo o projeto Logo no início do desenvolvimento do projeto o detalhamento dos re quisitos do software deve ser escrito de maneira que seja possível fazer a verificação automatizada ou de forma manual pelos próprios desenvolvedores e testadores A lista de verificação que deve ser feita pode ser fundamentada em experiências com erros anteriores de outros projetos ou somente nos requisitos identificados para cada parte do software É importante você entender que quando a validação é feita utilizando padrões e ferramentas automatizadas de testes esse tipo de validação é cha mado de estático Já quando a validação é feita de maneira diferente para cada funcionalidade ou para cada sistema levandose em conta que cada produto de software tem suas características próprias esse tipo de validação se chama dinâmico e normalmente é feito de maneira manual Mais adiante o plano de teste precisa se basear nas especificações de requisitos do software no códigofonte dos programas e em toda a documen tação disponível Via de regra as inspeções de códigofonte se resumem em solicitar que seja feita uma revisão por outro desenvolvedor que não aquele que programou o código Isso porque é mais provável que alguém que não realizou a tarefa consiga identificar problemas e erros Durante o desenvolvimento os desenvolvedores realizam testes unitários de funcionalidades para verificar se cada parte do software isoladamente realiza as atividades que foram solicitadas Nesse ponto é preciso que sejam documentadas todas as diferenças entre aquilo que era esperado e o que é produzido até o momento 7 Tipos de teste 115 Normas e Introdução a Tipos de Testes UNIDADE 2 Tipos de Teste PARTE 4 Quando o projeto já está mais adiantado os casos de teste se apresentam como uma técnica para principalmente verificar as interfaces com os usuários e identificar o quanto os testes unitários utilizam cada interface Isso serve para indicar se as especificações de interface estão completas ou não Por fim os testes de integração que são elaborados pela equipe de qualidade ou por aqueles analistas que tiverem esse papel testam as funcionalidades de maneira integrada A ideia é indicar se elas funcionam quando precisam se comportar como um sistema São testados os diferentes caminhos possíveis dentro dos programas identificando se o sistema funciona de maneira global Testes de software e suas etapas Ainda que o planejamento do desenvolvimento de um produto de software tenha sido elaborado de maneira detalhada e cuidadosa é praticamente impossível que as partes do software ou o produto fi nal sejam entregues sem algum tipo de problema como defeitos erros e falhas PEZZÈ YOUNG 2008 Um produto de software pode apresentar problemas A seguir veja como esses problemas podem ser classificados Erro é qualquer erro humano que resulta em algo incorreto Um erro acontece quando existe uma diferença entre o valor obtido em uma operação matemática e o valor que era esperado Defeito é qualquer inconsistência do software evidenciando algo que foi imple mentado ou programado de maneira incorreta Um exemplo acontece quando existem incorreções nas linhas de códigofonte Todo defeito é causa de erros mas por outro lado se a linha que estiver incorreta jamais for executada o erro não vai acontecer Falha é qualquer comportamento inesperado realizado pelo software Uma falha pode ter sido gerada por vários erros mas alguns erros podem nunca gerar uma falha É o caso de uma operação aritmética que é programada e não é usada Os testes de software servem para identificar de maneira antecipada todo e qualquer erro defeito ou falha Assim é possível evitar que eles apareçam quando o software for entregue para o cliente Dessa maneira as correções são feitas antes da finalização Antigamente era normal que os testes fossem Tipos de teste 8 QUALIDADE E TESTE DE SOFTWARE 116 realizados somente depois de finalizada a fase de desenvolvimento A ideia era dessa maneira encontrar todos os problemas e resolvêlos Atualmente é de conhecimento geral que é preciso efetuar testes ao longo de todo o desenvolvimento para evitar custos e prazos diferentes daqueles previstos inicialmente Afinal determinados problemas quando encontrados podem significar o retorno de todo um projeto para as fases iniciais Nesse sentido existem vários tipos de testes que podem ser realizados durante um projeto de software Tais testes se aplicam a diferentes propósitos como você pode ver a seguir PRESSMAN 2011 Teste unitário normalmente é realizado pelos próprios desenvolvedo res nas porções menores do software que estão sendo desenvolvidas no momento de maneira individualizada Ele serve para verificar se as partes do software funcionam de maneira isolada das demais partes do sistema Teste de caixa branca avalia a parte interna do software seu código fonte Ele serve para identificar problemas na lógica de programação e também na estrutura do programa observando elementos como as condições usadas os laços de repetição e o fluxo tomado pelos dados O testador deve lembrarse de verificar se o nível de segurança e confiança exigido está sendo implementado Teste de caixa preta avalia a parte externa do software o seu modo de funcionamento Esse tipo de teste serve para identificar se o software está funcionando como deveria se os dados informados resultam nas informações pretendidas e se de maneira geral o sistema faz o que ele deveria fazer Teste de caixa cinza é uma combinação dos testes de caixa branca e de caixa preta pois ele avalia os aspectos internos e também os aspectos externos do software as suas entradas o fluxo dos dados e as saídas Teste de regressão tem a função de testar cada nova versão do software toda vez que uma funcionalidade for modificada Ou seja toda a parte pronta do software será testada novamente para verificar se alguma novidade resultou em problema Esse tipo de teste é muito importante para indicar se erros que já haviam sido corrigidos não voltaram a se manifestar Teste de integração tem como propósito verificar se as porções me nores testadas anteriormente pelos testes unitários têm condições de funcionar em conjunto formando um sistema Esse teste é muito importante pois funcionalidades que operam perfeitamente de maneira 9 Tipos de teste 117 Normas e Introdução a Tipos de Testes UNIDADE 2 Tipos de Teste PARTE 4 isolada podem apresentar problemas quando tentam por exemplo realizar o fluxo de dados de uma parte do sistema para outra Teste de volume esse teste tem como objetivo avaliar até que limites um software pode ser utilizado ou seja qual é o seu limite de suporte a informações ou tráfego sem que apresente nenhum problema Teste de performance dividese em outros três tipos listados a seguir Teste de carga verifica o software como um todo em condições normais de uso avaliando o tempo de resposta das operações quantas operações podem ser executadas em determinado período de tempo quantos usuários simultâneos gravando dados podem existir entre outros aspectos Teste de estresse identificados os limites do software por meio dos testes de volume esse teste serve para levar o software aos seus limites A ideia é verificar em que ponto ele para de funcionar corretamente Teste de estabilidade verifica se o software se mantém funcionando de maneira adequada depois de ser utilizado por um longo período de tempo Teste funcional ou de funcionalidade verifica se o software como um todo bem como cada parte dele faz exatamente o que deveria fazer ou seja se os casos de uso foram corretamente descritos e desenvolvidos Teste de segurança verifica se o software permite que os dados sejam acessados somente pelos perfis determinados para cada parte específica do sistema ou para cada funcionalidade Teste de usabilidade é realizado por usuários e não por analistas O seu propósito é verificar se o software satisfaz as necessidades do usuário Esse teste serve para identificar a forma como o usuário utiliza as funcionalidades do software na tentativa de apontar partes do sistema em que ele apresenta maior dificuldade de interação Como esse teste é feito pelos clientes é importante o acompanhamento de analistas para documentar comentários sugestões e reclamações Teste de aceitação serve para verificar se o produto de software está pronto para ser entregue ao cliente ou seja se ele está pronto para entrar em produção Geralmente esse teste é realizado por alguém indicado pelo cliente ou ainda por um testador especializado que não tenha participado do projeto mas que tenha grande conhecimento acerca dos requisitos do software Tipos de teste 10 QUALIDADE E TESTE DE SOFTWARE 118 Teste de instalação tem como propósito verificar se o software é pas sível de ser instalado de maneira correta em diferentes hardwares com diferentes sistemas operacionais e diferentes disposições de memória rede entre outros aspectos Teste de configuração serve para identificar se o software funciona de maneira adequada no hardware para o qual foi planejado e no qual será instalado Teste de manutenção avalia se determinada mudança em algum as pecto do software resultou em falhas no seu funcionamento como um todo PEZZÈ M YOUNG M Teste e análise de software processos princípios e técnicas Porto Alegre Bookman 2008 PRESSMAN R S Engenharia de software uma abordagem profissional 7 ed Porto Alegre AMGH 2011 11 Tipos de teste ENCERRA AQUI O TRECHO DO LIVRO DISPONIBILIZADO PELA SAGAH PARA ESTA PARTE DA UNIDADE PREZADO ESTUDANTE Se você encontrar algum problema nesse material entre em contato pelo email eadproducaounilasalleedubr Descreva o que você encontrou e indique a página Lembrese a boa educação se faz com a contribuição de todos CONTRIBUA COM A QUALIDADE DO SEU CURSO Av Victor Barreto 2288 Canoas RS CEP 92010000 0800 541 8500 eadproducaounilasalleedubr