Normas e Modelos de Testes de Software

Prévia do material em texto

<p>Conteudista: Prof.ª Dra. Marise de Barros Miranda</p><p>Revisão Textual: Prof.ª Dra. Selma Aparecida Cesarin</p><p>Objetivos da Unidade:</p><p>Identificar soluções de Mercado para implantação de Testes Automatizados de Software;</p><p>Estabelecer um Processo de Testes de Software mais eficaz e mais integrado;</p><p>Criar, relacionar, revisar e corrigir Processos de Testes que cubram a maior parte possível</p><p>de atividades de ciclo de vida, estáticas e dinâmicas, relacionadas ao planejamento, à</p><p>preparação e à avaliação de produtos de Software;</p><p>Testar produtos que satisfaçam requisitos especificados, cuja finalidade é demonstrar sua</p><p>adequação ao uso final e a detecção de defeitos.</p><p>📄 Contextualização</p><p>📄 Material Teórico</p><p>📄 Material Complementar</p><p>Normas e Modelos de Maturidade de Testes de Software</p><p>📄 Referências</p><p>Nos tempos atuais, é difícil para a Indústria de Software fazer produtos sem nenhum defeito devido ao</p><p>tamanho e à complexidade do Software, que aumentam rapidamente, com clientes e usuários exigindo cada</p><p>vez mais, mais funcionalidades e também, que as mesmas sejam desenvolvidas em menos tempo.</p><p>Embora as Fábricas de Software tenham investido esforços substanciais para melhorar a qualidade de seus</p><p>produtos, parece que alcançar zero defeito fica sempre muito distante.</p><p>Para melhorar a qualidade do produto, frequentemente, a indústria se concentra em melhorar seu Processo</p><p>de Desenvolvimento, todavia, dedica cada vez menos esforços para as atividades de Teste e controle de</p><p>qualidade.</p><p>No passado, os Testes eram restritos à depuração do Código, o que levava a maioria das Organizações de</p><p>Desenvolvimento de Software a não diferenciarem o Teste do software, da Depuração de Código.</p><p>Da mesma maneira, o framework de integração Capability Maturity Model (CMMI) foi frequentemente</p><p>considerado como padrão da Indústria de Desenvolvimento, no sentido de melhoria de Processos de</p><p>Software, concentrando-se em apenas 30% a 40% das atividades de Teste.</p><p>Por esse motivo, a integração do Test Maturity Model (TMMI) foi desenvolvida para preencher a lacuna que</p><p>o CMI, e é posicionada como vários modelos de Teste deixaram, e é posicionada como um modelo</p><p>complementar ao CMMI.</p><p>O Framework TMMI contém níveis pelos quais uma Organização passa conforme seu Processo de Teste e</p><p>evolui de um processo de Teste ad hoc, como, para Teste Gerenciado, Teste Definido, Teste Medido e Teste</p><p>1 / 4</p><p>📄 Contextualização</p><p>Otimizado.</p><p>A realização de cada estágio ou nível garante à etapa seguinte a melhoria adequada.</p><p>O TMMI norteia o processo de Teste. Já a família da ISO/IEC 29119, normatiza os procedimentos dos</p><p>Testes.</p><p>Essa norma surgiu em 2013, substituindo os anteriores padrões de Teste de Software, tais como, IEEE 829 –</p><p>Test Documentation, IEEE 1008 Unit Testing, e as normas BS 7925 – 1 e 2 – Vocabulary of Terms in</p><p>Software Testing e Software Component Testing Standard, respectivamente.</p><p>Vale notar, que a utilização de Normas não garante a qualidade dos Testes, mas garante que todas as</p><p>Empresas de Desenvolvimento de Software realizem seus Testes de maneira semelhante, e que a</p><p>comunicação, interoperabilidade e a integração entre os produtos dessas Empresas sejam facilitadas por</p><p>essa abordagem semelhante.</p><p>Por esse motivo, o uso de padrões facilita a obtenção de parâmetros de comparação para um mesmo</p><p>atributo.</p><p>Nesse cenário, no Teste de Software, em geral, utilizamos Normas oriundas de duas entidades, a saber:</p><p>A maneira mais moderna de padronizar e entender os Testes é tratar a tarefa como parte do</p><p>Desenvolvimento de Software. Em vez de ter Testadores e Desenvolvedores, tem-se um Grupo de</p><p>Desenvolvimento.</p><p>ISO: International Organization for Standardization (Organização Internacional para</p><p>Padronização);</p><p>IEEE: Institute of Electrical and Electronics Engineers (Instituto de Engenheiros Eletricistas e</p><p>Eletrônicos).</p><p>Em vez de ter Fases de Desenvolvimento e Fases de Teste, tem-se uma fase de Desenvolvimento que</p><p>produz Código entregável quando concluído.</p><p>A padronização, nesse cenário, é tecida na Prática de Desenvolvimento.</p><p>Os Testes programáticos – Testes de unidade, Testes de API e Testes na interface do usuário – tornam-se</p><p>muito importantes porque se deseja um Código bom e mutável.</p><p>Os Testes acontecem em conjunto com o desenvolvimento. Se a Boa Prática da Padronização de Testes</p><p>funcionar eficientemente, Testes automatizados funcionando eficientemente serão consequências.</p><p>Modelo TMMI</p><p>Indivíduos, Equipes e Organizações sempre têm se esforçado para melhorar os processos que suportam</p><p>suas práticas de Desenvolvimento de Software.</p><p>O Setor de TI estabelecido há muito tempo, geralmente é responsável por altos padrões de qualidade. As</p><p>partes interessadas que exigem melhorias constantes nas práticas de TI são muitas – clientes,</p><p>investidores, reguladores, funcionários e concorrentes.</p><p>CMMI (Capability Maturity Model Integration)</p><p>Em resposta à crescente demanda por qualidade, o Capability Maturity Model (CMM) e, em seguida, o</p><p>(CMMI) procuraram sucessivamente regular as práticas de desenvolvimento Capability Maturity Model</p><p>Integration de Software e ajudar as Organizações de TI a alcançar padrões mais elevados de qualidade e</p><p>produtividade.</p><p>Nas últimas três décadas, a adoção e Certificação do CMMI (Figura 1) e seus estágios, gradualmente se</p><p>tornaram um dos pilares para uma Organização madura e é considerada um Padrão do Setor e uma</p><p>Obrigação.</p><p>2 / 4</p><p>📄 Material Teórico</p><p>Figura 1 – CMMI representado por estágios</p><p>Fonte: Adaptada de Wikimedia Commons</p><p>O foco principal de todas as melhorias nos Processos de TI tem sido o planejamento e o desenvolvimento.</p><p>O CMMI tenta cobrir todos os estágios do ciclo de vida de Desenvolvimento de Software – no entanto, é</p><p>empregado, principalmente, para amadurecer as práticas de desenvolvimento.</p><p>No entanto, os Testes de Software constituem cerca de 30% a 40% de todo o esforço do Projeto. Na prática,</p><p>o CMMI não empreende esforços dedicados a melhorar especificamente os processos de Teste, sequer</p><p>automatizados.</p><p>Para suprir a lacuna do CMMI, surge o TMMI – Test Maturity Model Integration, cuja base apresenta um</p><p>conjunto de processos e práticas têm como objetivo o de melhorar os processos de Teste dos Produtos de</p><p>Software.</p><p>O TMMI é considerado uma prática complementar ao CMMI. O TMMI (Modelo Integrado de Maturidade de</p><p>Testes) define níveis de maturidade específicos e diretrizes para subir em cada nível/etapa (Figura 2).</p><p>Figura 2 – Níveis de Maturidade de Testes de Software</p><p>Fonte: Adaptada de tmmi.org</p><p>Quando se analisam os níveis de maturidade de Testes de Software, faz-se necessário comparar com o</p><p>Departamento de Desenvolvimento e ou Testes, para compreender qual estágio corresponde à Equipe que</p><p>executa os Testes.</p><p>As Equipes precisam revisar os níveis de maturidade definidos e identificar o nível que representa com mais</p><p>precisão as práticas de Testes atuais, relacionadas aos Projetos da Empresa.</p><p>Antes de pensar em Testes automatizados, é necessário que se analise como os processos de Testes são</p><p>executados, se são proativos ou reativos.</p><p>Há mecanismos definidos para uma triagem de Testes, priorizando os mais complexos e os que não</p><p>necessariamente precisam de correção.</p><p>É preciso fazer uma boa análise dos Processos de Testes, antes de decidir automatizá-los. Por esse motivo,</p><p>o framework TMMI pode ajudar a decidir o que priorizar e o que automatizar, quanto aos Testes de Software.</p><p>É preciso ter um mecanismo definido para a triagem de defeitos. A decisão de esperar até que haja mais</p><p>defeitos do que podem ser corrigidos, antes mesmo de pensar em priorizar os bugs mais urgentes, que</p><p>também precisam ser corrigidos imediatamente, está na contramão daqueles defeitos que podem esperar</p><p>até a liberação de uma nova versão.</p><p>Conhecendo os Níveis do TMMI</p><p>Etapa 1 (Inicial)</p><p>Nesse nível, o Teste é puramente ad hoc, ou seja, não estruturado e desorganizado. As Equipes de Nível 1</p><p>não se importam com o planejamento criterioso, nem mesmo, com a adoção de padrões. Tem por objetivo,</p><p>a</p><p>entrega do produto dentro do prazo e sem grandes problemas de qualidade. Apenas executam alguns Testes</p><p>específicos como mínimo controle de falhas, e vão corrigindo conforme a demanda apontada pelo cliente.</p><p>Como fica esse produto no Mercado?</p><p>Etapa 2 (Gerenciado)</p><p>Aqui, as Equipes de Teste têm regras, procedimentos e alguns padrões implantados e documentados,</p><p>garantindo minimamente que os processos de Testes possam ser repetíveis.</p><p>Produto lento, instável, performance inesperada;</p><p>Se há Testes, funciona como um apoio para depuração de erros ou falhas;</p><p>Os processos de Testes não são documentados: vão corrigindo à medida que o cliente aponta as</p><p>falhas.</p><p>De alguma forma, esse nível facilita a integração e a solução de falhas futuras. Um ponto em comum é que,</p><p>de alguma maneira, ocorre uma Gestão de Projetos.</p><p>Como fica esse produto no Mercado?</p><p>Etapa 3 (Definido)</p><p>Neste nível, o Teste não é mais confinado a uma fase que segue apenas a codificação. Nesta etapa, há uma</p><p>clara integração com o ciclo de vida do Software no seu conjunto.</p><p>Estão presentes, avaliações do controle de qualidade. Não é ainda um Processo de Teste dinâmico, sequer</p><p>Testes Automatizados.</p><p>A distinção fundamental entre esta e a Etapa 2 é o escopo dos padrões, descrições de processos e</p><p>procedimentos.</p><p>Aqui, nesta etapa, as Equipes compartilham conhecimento e melhores práticas com seus colegas. Eles</p><p>também podem ter opções de treinamento no trabalho.</p><p>Como fica esse produto no Mercado?</p><p>Vários tipos de Técnicas de Testes são utilizados, como Teste de Fumaça, Teste Unitário,</p><p>Teste de Integração, Teste de Regressão e Teste de Aceitação do Usuário, entre outros;</p><p>O processo é repetível e tem documentação bem elaborada;</p><p>O Teste ainda é realizado tarde, não considerando o ciclo de vida de desenvolvimento de</p><p>Sistemas.</p><p>O Teste começa já na fase de coleta de requisitos;</p><p>Treinamentos ocorrem concomitantes ao desenvolvimento;</p><p>Etapa 4 (Métricas)</p><p>Tudo que é controlado ou exige níveis de qualidade precisa ser medido. Nesta etapa, as Equipes de Teste</p><p>exigem medidas quantitativas quanto aos Processos de Desenvolvimento.</p><p>Decorre daí a possibilidade de mapear e identificar processos com problemas. Nesta etapa, a Equipe de</p><p>Testes evolui junto com os processos de Testes, criando melhorias nos resultados dos Testes e do produto</p><p>de Software, quanto à qualidade, à confiabilidade, à estabilidade, à portabilidade e à manutenibilidade.</p><p>Aqui, ferramentas e padrões próprios ou de Mercado são utilizados pelas Equipes. A Automação de Testes é</p><p>adotada mais frequentemente.</p><p>Como fica esse produto no Mercado?</p><p>Etapa 5 (Otimização)</p><p>Aqui as Abordagens e Práticas de Testes estão bastante dominadas. Além da proficiência dos Testes, há</p><p>constantes esforços da Equipe para melhorar os seus processos de Testes.</p><p>O esforço está na busca constante por menores tempos de Testes, com alto grau de eficiência e, por esse</p><p>motivo, os Testes automatizados são de extrema importância, pois buscam a otimização do tempo para as</p><p>detecções de falhas e correções cada vez em tempos menores.</p><p>Criação de abordagens de Teste mais específicas.</p><p>O Teste passa a ser um Processo medido, portanto, candidato à automação;</p><p>Revisões e inspeções regulares implementadas de forma automatizada;</p><p>A Equipe visa a tornar os Testes mais eficazes, utilizando a automação de Testes.</p><p>Adotam a Automação de Testes em todas as etapas que forem possíveis dentro do ciclo de</p><p>desenvolvimento, buscam com isso a redução dos custos e prazos, sem perder o foco na qualidade do</p><p>produto.</p><p>Como fica esse produto no Mercado:</p><p>Em resumo, o Modelo de Processo TMMI orienta a evolução do Processo de Teste para melhoria contínua</p><p>do controle de qualidade. A adoção e a implantação do TMMI requerem tempo e esforços da Equipe, e</p><p>disposição da Empresa para dar a devida importância à área de Testes.</p><p>Os Testes automatizados com segurança e qualidade dependem da maturidade da Equipe e a abordagem</p><p>qualitativa em relação aos Testes de Software.</p><p>Denota-se que o alcance das Etapas mais avançadas no TMMI é bastante complexa, exigindo grande</p><p>esforço da Equipe de Testes. No entanto, outros modelos de maturidade podem ser iniciados antes de se</p><p>aventurar em conquistas das etapas mais avançadas do TMMI.</p><p>TPI (Test Process Improvement – Melhoria do Processo de Teste)</p><p>Com o Modelo TPI, cada parte do Processo de Teste, como Planejamento de Testes, Métricas De Testes e</p><p>Ambiente de Teste, dentre outras, é coberta por Áreas pré-definidas.</p><p>Esse Modelo tem 4 níveis de maturidade:</p><p>Métricas de Processo de Testes são sempre usadas;</p><p>Estabilidade de previsão no prazo para encontrar bugs, corrigir e concluir o Projeto no tempo</p><p>previsto;</p><p>Adquirem expertise para trabalhar na prevenção de defeitos e otimização de Processos de</p><p>Testes.</p><p>Cada uma das Áreas principais é avaliada por meio de pontos de verificação predefinidos em cada Nível de</p><p>maturidade.</p><p>Com base nos resultados da avaliação, uma matriz de maturidade (Tabela 1) é desenvolvida para auxiliar na</p><p>visualização e resumir as Áreas-chave.</p><p>Tabela 1 – Exemplo aplicado de TPI</p><p>Inicial;</p><p>Controlada;</p><p>Eficiente;</p><p>Otimizado.</p><p>O TPI destaca 19 áreas chave, incluindo a Gestão dos Testes automatizados.</p><p>Parâmetros para a composição da Matriz Genérica de Maturidade dos Processos de Testes (Tabela 2):</p><p>Tabela 2 – Escala para desenvolver Matriz de Maturidade do Modelo TP</p><p>Ciclo de vida (L)</p><p>Atividades de teste em conexão com o</p><p>Ciclo de Desenvolvimento</p><p>Organização de boa qualidade (O)</p><p>Ciclo de vida (L)</p><p>Atividades de teste em conexão com o</p><p>Ciclo de Desenvolvimento</p><p>Infraestrutura e ferramentas</p><p>adequadas (I) e técnicas (T)</p><p>Que podem ser facilmente</p><p>aplicadas às Atividades de Teste</p><p>Níveis de maturidade A – D</p><p>A corresponde ao nível de</p><p>maturidade mais baixo e D ao mais</p><p>alto</p><p>Classificação em 14 Escalas de Maturidade</p><p>Escala 0 Ad hoc</p><p>Escalas 1 – 5 Controlado</p><p>Escalas 6 – 10 Eficiente</p><p>Escalas 11 – 13 Avançado</p><p>A definição dos objetivos de melhoria e sua execução são customizados de acordo com as necessidades e as</p><p>capacidades das organizações de Teste.</p><p>O Modelo TPI é independente de todos os modelos de melhoria do Processo de Desenvolvimento</p><p>de Software devido à sua natureza genérica. Abrange a Engenharia de Teste como Sistemas de suporte à</p><p>decisão.</p><p>Assim como no TMMI, um nível de maturidade superior requer o cumprimento de todos os requisitos de</p><p>níveis inferiores.</p><p>Além disso, para cada Área-chave, o modelo TPI fornece uma descrição do que deve ser feito para atingir</p><p>um nível junto com um conjunto de pontos de verificação para cada escala.</p><p>Os pontos de verificação são requisitos obrigatórios para um determinado nível (A a D). Isso ajuda a Equipe</p><p>a tomar uma decisão fundamentada sobre a qualidade dos Testes em sua Organização.</p><p>A matriz é usada para visualizar o estado atual do projeto e traçar um Plano de Melhorias. Basicamente,</p><p>melhorias aqui significam buscar um nível de maturidade mais alto.</p><p>Um processo de QA maduro ajuda as Equipes de Projeto a mitigar todos os tipos de situações inesperadas</p><p>que podem surgir a qualquer momento. Mas como montar um processo maduro?</p><p>Isso exige um Modelo de Maturidade de QA adequado que esteja de acordo com os processos de negócios</p><p>e especificações.</p><p>Os principais modelos são:</p><p>Modelos personalizados: esses modelos são elaborados para uma determinada Empresa no que</p><p>diz respeito às especificidades do negócio e/ou às necessidades do cliente. Não</p><p>recomendado;</p><p>Modelos mundialmente reconhecidos TMMI e TPI:</p><p>Modelo TMMI: este modelo reconhecido globalmente é uma ferramenta poderosa para avaliar e</p><p>melhorar a maturidade do Processo de Testes. Porém, o TMMI é mais adequado para grandes</p><p>Empresas, pois sua implantação requer investimentos consideráveis em termos financeiros,</p><p>conhecimento e mão de obra;</p><p>Modelo TPI: o modelo TPI é reconhecido mundialmente. Ao contrário do TMMI, este modelo</p><p>atende a qualquer tipo de Empresa. Ele fornece diretrizes fáceis de seguir (descrições de nível</p><p>de maturidade, pontos de verificação) que</p><p>ajudam o fornecedor a avaliar a maturidade de seu</p><p>processo de forma independente e delinear o caminho para melhorias futuras.</p><p>Os modelos descritos são amplamente difundidos, mas não são os únicos. Assim, qualquer Empresa</p><p>envolvida em Teste de Software pode escolher um modelo que melhor se adapte às suas necessidades de</p><p>negócios. Isso ajudará a reduzir o número de situações não gerenciáveis.</p><p>Estrutura Geral da Norma ISO/IEC/IEEE 29119</p><p>O Teste de Software é uma parte essencial do Ciclo de Desenvolvimento de Software. É considerada uma</p><p>atividade importante na qual o Software é validado em conformidade com requisitos e especificações.</p><p>Um novo padrão internacional de Teste de Software foi formado pela International Normalization</p><p>Organization (ISO) e International Electrotechnical Commission (IEC) no ano de 2013. ISO/IEC/IEEE 29119 é</p><p>um conjunto de normas para padronização que cobre Sistemas e Software especificamente para Testes.</p><p>Testes de Software</p><p>Esta é a primeira parte do padrão ISO/IEC/IEEE 29119. Ele se concentra nas principais definições e</p><p>conceitos de Teste de Software para melhor compreensão dos padrões internacionais.</p><p>O Teste de Software como conceito é importante por muitos motivos, tais como informações sobre a</p><p>qualidade do item sendo testado geralmente exigidas pelos tomadores de decisão, o item em Teste pode</p><p>não funcionar conforme o esperado e precisa ser verificado e validado.</p><p>A avaliação deve ocorrer ao longo do ciclo de vida do Software que está sendo desenvolvido. Geralmente, é</p><p>aceitável que um Software perfeito seja impossível de ser alcançado.</p><p>Processos de Teste ISO/IEC/IEEE 29119-2</p><p>Essa parte da norma tem por objetivo apresentar como identificar os processos de Teste que podem ser</p><p>usados para gerenciar, administrar e implementar Testes de Software nas Organizações. A norma fornece</p><p>descrições comuns de processos de Teste junto com diagramas descritivos que se aplicam a todos os</p><p>modelos de Teste de Software.</p><p>Processo de Monitoramento e Controle de Teste</p><p>O Processo de Monitoramento e Controle de Teste examina se o andamento do Teste está alinhado ao plano</p><p>de Teste organizacional e à política de Teste da Organização.</p><p>Se a variação for detectada, o Plano de Correção deve ser executado para remover a variação.</p><p>Processo de Conclusão de Teste</p><p>O Processo de Conclusão do Teste é um Teste de Verificação a ser executado quando o Teste das</p><p>atividades é concluído.</p><p>É usado como Teste de Verificação para realizar o Teste feito no Teste do Sistema ou Teste de Desempenho</p><p>para testar o Projeto Geral.</p><p>É considerado um Teste satisfatório deixando o ambiente de Teste em boas condições. A comunicação com</p><p>as partes interessadas deve ocorrer quando o Teste geral for concluído.</p><p>Processos de Teste Dinâmicos</p><p>Este tipo de Teste é usado para realizar o Teste Dinâmico em uma fase específica de Teste, por exemplo,</p><p>Teste de Unidade, Sistema, Integração e Aceitação.</p><p>Quatro tipos de Processo de Teste dinâmico estão disponíveis: Projeto e Implementação de Teste,</p><p>configuração e Manutenção do Ambiente de Teste, Execução de Teste e Relatórios de Incidentes de Teste.</p><p>Esses processos normalmente são considerados parte da implementação da estratégia de Teste no Plano</p><p>de Teste na fase de Teste.</p><p>Projeto de Teste e Processo de Implementação</p><p>Neste Processo, casos de Teste e Procedimentos são derivados, normalmente documentados nas</p><p>especificações de Teste, mas podem ser executados imediatamente.</p><p>Possivelmente, os ativos de Teste armazenados podem ser usados durante esse Processo como Teste de</p><p>Regressão. Esse processo pode ser interrompido ou reiniciado no caso de relatar um novo incidente.</p><p>Processo de Configuração e Manutenção do Ambiente de Teste</p><p>Este Processo é usado para criar e manter o ambiente em que os Testes são realizados. Pode envolver</p><p>mudanças no ambiente de Teste com base no resultado dos Testes anteriores.</p><p>O ambiente de Teste pode mudar dependendo dos Processos de Gerenciamento de Configuração.</p><p>As tarefas e as atividades nesse Processo são: estabelecimento do Ambiente de Teste e manutenção do</p><p>Ambiente de Teste.</p><p>Processo de Execução de Teste</p><p>Este processo é utilizado para executar os Procedimentos de Teste que são gerados como resultado do</p><p>design do Teste e do Processo de Implementação.</p><p>O Processo de Execução de Teste pode exigir a execução várias vezes, pois todos os procedimentos de</p><p>Teste disponíveis não podem ser executados em uma única interação.</p><p>Além disso, quando um problema é corrigido, o Processo de Execução do Teste deve ser executado</p><p>novamente. As atividades envolvidas nesse Processo são: execução do Procedimento de Teste,</p><p>comparação dos Resultados do Teste e registro da Execução do Teste.</p><p>Processo de Relatório de Incidentes de Teste</p><p>Esse Processo é usado para relatar incidentes de Teste como resultado da detecção de falha, itens com</p><p>comportamento inesperado ou incomum durante a execução do Teste ou em caso de Reteste.</p><p>As atividades envolvidas são analisar o resultado do Teste e criar ou atualizar os resultados do incidente.</p><p>Documentação de Teste ISO/IEC/IEEE 29119-3</p><p>A parte da documentação do Teste determina os formulários e os modelos de Teste de Software que podem</p><p>ser usados por Organizações, Projeto específico ou atividade única de Teste.</p><p>Ele contém documentos definitivos que são considerados como uma saída de processos de Teste.</p><p>Esses documentos podem ter várias versões, estando tal questão relacionada ao Gerenciamento de</p><p>configuração.</p><p>Técnicas de Teste ISO/IEC/IEEE 29119-4</p><p>Esta parte especifica e identifica Técnicas de Teste que podem ser usadas com Processos de Teste.</p><p>O público-alvo dessa parte são Testadores, Gerentes de Teste e Desenvolvedores, especialmente, aqueles</p><p>que são responsáveis pelo Gerenciamento e pela Implementação de Software.</p><p>Nesta parte, as Técnicas de design de Teste são definidas para Teste baseado em Especificação, Teste</p><p>baseado em Estrutura e Teste baseado em experiência.</p><p>Em Testes baseados em Especificações, a principal fonte de informação usada para projetar Casos de</p><p>Teste é a base de Teste, por exemplo, necessidades do usuário, requisitos, especificações e modelos.</p><p>Em Testes baseados em Estrutura, o Código-fonte ou a estrutura do modelo são usados como fonte de</p><p>informações para desenvolver casos de Teste.</p><p>Em Testes baseados na experiência, a fonte primária de informações é a experiência e o conhecimento dos</p><p>testadores.</p><p>Além disso, todos esses tipos de Testes são usados para gerar resultados esperados. Essas técnicas de</p><p>design de Teste não são essenciais, mas consideradas complementares. No entanto, eles são eficazes se</p><p>aplicados em combinação.</p><p>Os termos, Teste baseado em Especificação e Teste baseado em Estrutura também são conhecidos como</p><p>Teste de Caixa Preta e Teste de Caixa Branca.</p><p>Teste Orientado por Palavras-chave ISO/IEC/IEEE 29119-5</p><p>O Teste orientado por Palavra-chave é uma abordagem de especificação de Teste que, geralmente, é usada</p><p>para auxiliar na Automação de Teste e na criação de Estrutura de Automação de Teste.</p><p>Pode ser usado se nenhuma abordagem de automação de Teste for planejada ou existir. Esse tipo de Teste</p><p>pode ser aplicado a todos os níveis de Teste, como Teste de Componente e Teste de Sistema, ou até</p><p>mesmo para tipos de Teste, como Teste Funcional e Teste de Confiabilidade.</p><p>As vantagens de aplicar o Teste Orientado por Palavras-chave para o Sistema são: tornar o Sistema mais</p><p>fácil de usar, compreensível, sustentável, reutilizável, de suporte à automação e econômico.</p><p>Automatização de Práticas do TMMI</p><p>Cada atividade do Processo de Testes possui um ou mais passos a serem realizados, incluindo a</p><p>possibilidade de automação do Teste. Para que a atividade de Teste possa ser considerada concluída, as</p><p>respostas aos defeitos devem ter sido sanadas.</p><p>Um exemplo de fluxo de Teste, sob a perspectiva TMMI, pode ser considerado na Figura 3. A primeira</p><p>atividade do processo, “Especificar Caso de Teste”, tem o passo “Criar caso de Teste”, que consiste em</p><p>escrever</p><p>baseando-se no documento de especificação de casos de uso ou no Backlog do Produto.</p><p>Depois, cria o Teste com base na especificação documentada, sempre verifica a possibilidade de</p><p>automatizar o Teste, depois executa o Teste automatizado e mede:</p><p>Figura 3 – Fluxo de tarefas e Automatização de Testes padrão</p><p>Depois da execução, além da medida, o fluxo segue se o Teste reportou defeitos ou cobertura abaixo da</p><p>tolerada. Caso positivo, segue para reparo e reinicializa o Teste automatizado. Caso não apresente mais</p><p>defeitos, fim do Teste e Relatórios.</p><p>Uma Planilha de Gerenciamento do Fluxo de Teste Automatizado pode ser gerada conforme a Tabela 3, de</p><p>acordo com os padrões do TMMI.</p><p>Tabela 3 – Fluxo de Controle do Processo de Teste</p><p>Atividades para</p><p>Execução do Teste</p><p>Ações relacionadas às</p><p>Atividades do Tester</p><p>Práticas aderentes TMMI</p><p>Especificação do</p><p>Caso de Teste</p><p>Definir a Abordagem e a</p><p>Técnica de Teste;</p><p>Identificar itens e</p><p>parâmetros a serem</p><p>testados;</p><p>Planejar a Equipe de</p><p>Testes.</p><p>Criar Teste</p><p>Identificar e priorizar Casos</p><p>de Testes.</p><p>Criar a automação do</p><p>Teste</p><p>Implementar Ambiente de</p><p>Teste Automatizado.</p><p>Execução do Caso</p><p>de Teste</p><p>Executar Casos de</p><p>Teste</p><p>Executar caso de Teste</p><p>automatizado;</p><p>Medir Teste.</p><p>Atividades para</p><p>Execução do Teste</p><p>Ações relacionadas às</p><p>Atividades do Tester</p><p>Práticas aderentes TMMI</p><p>Reportar Defeitos</p><p>Documentar Defeitos</p><p>Reparar Defeitos</p><p>Relatar incidentes de Teste;</p><p>Executar ações</p><p>apropriadas para corrigir</p><p>Incidentes de Testes.</p><p>Compartilhamento</p><p>da Equipe</p><p>Gerar Documentação</p><p>Conduzir revisões de</p><p>qualidade do produto.</p><p>Testes Preventivos Analisar problemas.</p><p>O fluxo deve conter as ações elencadas na Tabela. A Tabela é um marco de atividades, mas aqui funciona</p><p>como um exemplo apenas. Outras ações e atividades podem ser incluídas ou retiradas.</p><p>Ferramentas de Execução Automática e Frameworks: Casos de Uso</p><p>de Testes Automatizados de Software</p><p>Para realizar os Testes Automatizados, três conjuntos básicos são necessários:</p><p>Utilizar uma ferramenta de execução nos Testes automatizados;</p><p>Os frameworks podem ser seguidos para garantir a qualidade dos Testes;</p><p>Os casos de uso são desenhados para serem aplicados nos Testes.</p><p>Definir a ferramenta de execução não é algo trivial. É muito como o Tester lida com ela e como a domina.</p><p>Ferramentas de execução de Testes Automatizados são Programas Comerciais ou Não comerciais que</p><p>auxiliam muito o Tester nas tarefas de testagem e, principalmente, na sua automatização.</p><p>A seguir, um resumo qualificado (Tabela 4) de algumas ferramentas e suas especificações conforme a</p><p>experiência do Tester:</p><p>Tabela 4 – Resumo qualificado de Ferramentas de Testes unitários e automatizados</p><p>O tipo de aplicação do Teste pode ser feito em Aplicações para web, Aplicações mobile e Aplicações</p><p>desktop, entre outras.</p><p>Os Sistemas Operacionais dos Computadores são listados na Linha de Suporte a Plataformas.</p><p>As ferramentas suportam algumas Linguagens de Programação, as mais utilizadas atualmente são: Java,</p><p>Python, C++, C# e JavaScript, entre outras.</p><p>Algumas ferramentas exigem um nível mais avançado de conhecimento em programação para poder usá-la.</p><p>Além de experiência com scripts de Testes. Outras não possuem essa exigência que pode estar relacionada</p><p>à especificidade da Linguagem de Programação.</p><p>Com relação à facilidade de uso, algumas ferramentas exigem experiência e outras são muito fáceis de</p><p>usar.</p><p>Por último, ao adotar uma ferramenta, deve-se levar em consideração, principalmente para utilizá-la em</p><p>Testes Automatizados, a licença de uso. No Mercado, existem boas ferramentas com Licença Open Source,</p><p>Licença Aberta, sem custos e outras ferramentas com custos anuais para uso comercial.</p><p>Definida a ferramenta, ainda pode mudar de acordo com o cenário de Testes a ser testado.</p><p>A definição da ferramenta, neste ponto, significa o domínio dela, maximizando o potencial de uso.</p><p>Assim, poderá ser viabilizado o Teste em função da capacidade de domínio da ferramenta pelo Tester.</p><p>E o framework?</p><p>O framework de Testes é um conjunto de regras e itens que ajudam a realizar os Testes. Como já visto, o</p><p>TMMI, o TPI e outros ainda podem ser usados com o objetivo de seguir uma rotina compreensível pela</p><p>Equipe, e que produza algum resultado. Vai depender sempre do grau de maturidade da Empresa ou da</p><p>Equipe, dada a importância dos Testes de Software e a qualidade que se quer alcançar no produto</p><p>desenvolvido.</p><p>Já o caso de Teste é exatamente o que precisa ser testado. Os formatos dos casos de Teste podem variar</p><p>de uma Organização para outra, mas usar um formato de caso de Teste padrão para escrever casos de</p><p>Teste é um passo mais perto de configurar um processo de Teste para o projeto.</p><p>Existem várias Ferramentas de Gerenciamento de Casos de Teste. Todas elas são pagas e disponibilizam</p><p>apenas versões trial de 15 a 30 dias.</p><p>Por um lado, facilitam a gestão dos casos de Teste, mas criam uma certa complexidade pela necessidade</p><p>de incluir muitos parâmetros que contribuem para a geração de métricas e relatórios.</p><p>Aqui, a opção de um template já será o suficiente para ter uma boa quantidade de informações dos casos de</p><p>Teste (Figura 4).</p><p>Figura 4 – Exemplo de Caso de Teste (Case Test) de login em navegador</p><p>Fonte: Acervo do conteudista</p><p>Este é um exemplo de uma sequência de passos para realizar um simples Teste de login em uma página</p><p>web.</p><p>Existem várias Ferramentas de Gerenciamento de Testes Cases, que permitem a geração de Relatórios e</p><p>Rastreabilidade de Testes.</p><p>Na Figura 5, está um exemplo de Ferramenta de Gerenciamentos de Casos de Testes. Existem várias no</p><p>Mercado, sendo a maioria delas paga. As versões free são apenas trials com uso livre por 14 a 30 dias na</p><p>forma grátis.</p><p>Figura 5 – Exemplo de ferramenta de gerenciamento de Testes TestRail QA</p><p>Fonte: Reprodução</p><p>Essas ferramentas se propõem a ajudar a gerenciar Testes Cases, falhas, quantidades de Testes que</p><p>passaram e descrição dos scripts, dentre outras informações.</p><p>O Processo de Gerenciamento de Teste envolve o conjunto de tarefas/atividades mencionadas a seguir.</p><p>Esse processo é crítico, orientado a detalhes e instrumental para garantir que todo o esforço de Teste seja</p><p>bem-sucedido.</p><p>As atividades diárias do testador incluem:</p><p>Criação e manutenção de liberação/ciclo de projeto/informações de componentes;</p><p>Criar e manter os artefatos de Teste específicos para cada versão/ciclo para o qual se tem: requisitos,</p><p>casos de Teste etc.;</p><p>Estabelecer rastreabilidade e cobertura dos Testes ativos;</p><p>Suporte de execução de Teste – criação de suíte de Teste, captura de status de execução de</p><p>Teste etc.;</p><p>Coleta de métricas/geração de relatório-gráfico para análise;</p><p>Rastreamento de bugs/gerenciamento de defeitos.</p><p>Indicações para saber mais sobre os assuntos abordados nesta Unidade:</p><p>Site</p><p>T&M</p><p>Conheça mais sobre uma tendência de robotização de tarefas de Testes. Acesse o link e analise como o</p><p>Charles atua em diversas frentes do desenvolvimento Agile e, principalmente, nos Testes Automatizados.</p><p>Clique no botão para conferir o conteúdo.</p><p>ACESSE</p><p>Leitura</p><p>Charles – Robô para Automação com Zero de Programação</p><p>O arquivo disponível no link a seguir apresenta mais detalhes sobre a robotização de tarefas de Testes.</p><p>3 / 4</p><p>📄 Material Complementar</p><p>https://bit.ly/3oOKB6B</p><p>Clique no botão para conferir o conteúdo.</p><p>ACESSE</p><p>Documento TMMI</p><p>Faça dowload do documento TMMI no mundo Agile Versão 1.3, produzido pelo TMMI Foundation, cujo editor</p><p>responsável é Erik van Veenendaa. Esse documento explica como a combinação de uma abordagem Agile</p><p>para Desenvolvimento de Software com o modelo de aprimoramento de processo de Teste TMMI é uma rota</p><p>possível para atingir seus objetivos de negócios.</p><p>Explica como o TMMI pode ser usado e aplicado de forma benéfica em um contexto Agile. Alternativas</p><p>comprovadas são fornecidas às abordagens de Teste tradicionais que implementam práticas de TMMI</p><p>mantendo e, talvez, até aumentando a agilidade.</p><p>Clique no botão para conferir o conteúdo.</p><p>ACESSE</p><p>Learn How To Write</p><p>Test Cases Effectively</p><p>A REQTEST mostra em seu blog, de 2012, ainda muito atual, por conta da crescente evolução dos Testes</p><p>automatizados, como a escrita de casos de Teste é uma parte importante do Processo de Teste de</p><p>Software, sendo primordial escrever casos de Teste de forma eficaz para que o Teste seja bem-sucedido.</p><p>O blog mostra o passo a passo como escrever um caso de Teste bem detalhado. Existem muitas maneiras</p><p>diferentes de escrever casos de Teste. Este blog dará a você exemplos de estruturas comuns que você</p><p>pode usar e adaptar para atender às suas necessidades.</p><p>Clique no botão para conferir o conteúdo.</p><p>https://bit.ly/3fih8id</p><p>https://red.ht/3yCZmy0</p><p>ACESSE</p><p>Overview of Software Testing Standard ISO/IEC/IEEE 29119</p><p>Acesse o Artigo para saber de forma objetiva todos os detalhes dessa norma de Testes de Software. Este</p><p>documento fornece uma visão geral do padrão de Teste de Software ISO/IEC/IEEE 29119. As partes</p><p>incluídas do padrão são: conceitos e definições, Processos de Teste, Documentação de Teste, Técnicas de</p><p>Teste e Teste Orientado por Palavras-chave.</p><p>Clique no botão para conferir o conteúdo.</p><p>ACESSE</p><p>https://bit.ly/2QQCkTj</p><p>https://bit.ly/3fNmalQ</p><p>AURI, M.; RIZZO, V. et al. Automatização de Teste de Software com ferramentas de</p><p>Software livre. Rio de Janeiro: Elsevier, 2018.</p><p>GARCIA, D. A importância da Transformação Digital: porque as Empresas devem</p><p>adotá-la para se manterem competitivas na era digital. Curitiba: Do autor, 2020.</p><p>IMONIANA, J. O. Auditoria de Sistemas de informação. 3.ed. Rio de Janeiro Atlas</p><p>2016. (e-book)</p><p>PALANI, N. Software Automation Testing Secrets Revealed Part1: Cucumber</p><p>BDD, Selenium Webdriver, Protractor, Selenium Grid, Appium, TestNG, Jenkins,</p><p>UFT, RFT, Visual Studio, Excel... based Automation Testing (English Edition).</p><p>Editora: Educreation Publishing, 2018. (e-book)</p><p>4 / 4</p><p>📄 Referências</p>