materialestudoPA1.pdf

Este trabalho está licenciado com uma Licença Creative Commons Atribuição-NãoComercial-SemDerivações 4.0 Internacional.  FUNDAMENTOS E MODELOS DE TESTE DE SOFTWARE Sumário 1. Princípios, Pilares e Modelos de Teste de Software 2. Fases da atividade de teste, li...

Este trabalho está licenciado com uma Licença Creative Commons Atribuição-NãoComercial-SemDerivações 4.0 Internacional.  FUNDAMENTOS E MODELOS DE TESTE DE SOFTWARE Sumário 1. Princípios, Pilares e Modelos de Teste de Software 2. Fases da atividade de teste, limitações e impactos dos testes 3. Critérios de teste de software 4. Papel do analista de testes, certificações, equipes de times ágeis Sumário clicável  Voltar ao sumário Neste Percurso de Aprendizagem, averiguaremos Olá os principais conceitos a serem considerados no entendimento inicial da área de qualidade de software. Descobriremos quais são as fases da atividade de teste levadas em consideração em cada momento de construção do software, juntamente com as suas limitações e os impactos dos testes no ciclo de desenvolvimento de um projeto. Abordaremos os critérios de teste com intuito de descobrir quais os principais pontos a serem levados em consideração para os testes. E no final deste Percurso, aprenderemos sobre quais são os papéis do analista de teste nas equipes de modelo tradicional e ágil de desenvolvimento de software, descobrindo também as certificações da área. 4  1. Voltar ao sumário Princípios, Pilares e Modelos de Teste de Software Você já deve ter notado que o ciclo de desenvolvimento de software é complexo e com muitas etapas, pois aborda desde a concepção das ideias de um produto de software, passando pela especificação de requisitos, estabelecimento de design e modelagem, codificação e testes do sistema, até a sua devida entrega e posterior manutenção. Neste contexto, cabe a nós nos perguntarmos como garantir que cada parte de todo este processo seja executada com qualidade, seguindo as diretrizes, padrões e normas cabíveis e, muito mais do que isso, atendendo às expectativas do usuário, bem como às especificações de requisitos. 1.1 O que é qualidade? Segundo o dicionário Oxford Languages, qualidade significa avaliar algo em termos que atenda a um grau positivo ou negativo em relação à excelência. Diz, ainda, que são propriedades que podem determinar a essência ou a natureza de determinada coisa ou alguém. Em um nível mais pragmático, David Garvin, da Harvard Business School, sugere que “qualidade é um conceito complexo e multifacetado” que pode ser descrito segundo cinco pontos de vista diferentes. A visão transcendental sustenta (assim como Pirsig) que qualidade é algo que se reconhece imediatamente, mas não se consegue definir explicitamente. A visão do usuário enxerga a qualidade em termos das metas específicas de um usuário. Se um produto atende a essas metas, ele apresenta qualidade. A visão do fabricante define qualidade em termos da especificação original do produto. Se o produto atende às especificações, ele apresenta qualidade. A visão do produto sugere que a qualidade pode ser ligada às características inerentes (p. ex., funções e recursos) de um produto. Finalmente, a visão baseada em valor mede a qualidade tomando como base o quanto um cliente estaria disposto a pagar por um produto (PRESSMAN; MAXIM, 2021, p.311). Na realidade, qualidade engloba todas essas visões e outras mais. Como, por exemplo, qualidade do projeto, que diz respeito a todo o procedimento e construção de produtos de forma geral, absorvendo questões relacionadas desde a ótima qualidade de material de construção de determinado produto a especificações de tolerância, eficiência e eficácia. Podemos falar, ainda, em qualidade de projeto de software, que está correlacionada com o sucesso de atendimento aos desejos dos usuários, atendimento de requisitos, levando em consideração tempo e custos. 5  Voltar ao sumário 1.2 Qualidade de software Nos últimos tempos, vem se discutindo cada vez mais sobre o que é qualidade e como este termo está inserido dentro da área de tecnologia. No sentido mais geral, a qualidade de software pode ser definida como: uma gestão de qualidade efetiva aplicada de modo a criar um produto útil que forneça valor mensurável para aqueles que o produzem e para aqueles que o utilizam (PRESSMAN; MAXIM, 2021, p.311). Quando falamos em gestão de qualidade efetiva, referimo-nos a toda parte de apoio administrativo e de infraestrutura voltada para estabelecer a melhor construção possível de um software. Desta maneira, procedimentos, como gerenciamento de mudanças e revisões, estão diretamente relacionados a entregas de software mais consistentes. Construir produtos úteis significa dizer que o produto atende às expectativas do usuário no que diz respeito a estar de acordo com os itens que foram solicitados, em termos de conteúdo, de funcionalidades e de recursos. Neste quesito, entram questões relacionadas aos usuários se sentirem seguros em operar o sistema e a ter isenção de erros. Os requisitos funcionais e não funcionais devem ser atendidos para que se entenda que o produto de software está atendendo à qualidade esperada. Ao falarmos de agregar valor, estamos nos referindo aos benefícios gerados com a entrega do produto de software. Deste modo, agrega-se valor ao usuário quando são satisfeitas as necessidades reais do usuário em relação ao atendimento de resolução dos problemas explanados por eles, bem como há valor agregado em relação à satisfação de qualidade para quem fabrica o software, quando há menos manutenções reativas (correções de erros quando o software está em funcionamento) e proativas (inserções de melhorias para correções de problemas que não atrapalham a operacionalidade do software) a serem feitas no sistema. Outro ponto positivo relacionado ao software com alta qualidade para visão do fabricante é a redução das demandas de suporte ao usuário, além de demandar menos treinamentos. Se tivermos software com qualidade alta, serão despendidos mais tempo em construir novas funcionalidades e a preocupação com manutenções será quase ausente. Além disso, o software de alta qualidade oferece aos usuários a oportunidade de agilizar parte de um processo de negócio. Em termos gerais, o usuário terá: maior receita gerada, maior rentabilidade e maior disponibilidade de informações importantes para o negócio. 1.3 Qualidade do processo e produto A qualidade de um software está diretamente relacionada com a qualidade do processo de desenvolvimento. Um bom processo de software não garante que os produtos de software produzidos são de boa qualidade; é apenas um indicativo de que a organização (instituição/empresa) é capaz de produzir bons produtos de software. Podemos, ainda, citar alguns exemplos de sintomas de que há falha no processo de desenvolvimento: quando há entregas atrasadas; ou envolve custos maiores, pois não foram planejados; quando há cortes no projeto de desenvolvimento de última hora; ou mesmo a falta de visibilidade do progresso de desenvolvimento; quando há muito retrabalho em termos de requisitos novos aparecendo em tempo de codificação ou testes; quando o produto entregue não funciona e há reclamações constantes do cliente ou até mesmo é evidenciada uma frustação das pessoas envolvidas no desenvolvimento. 6  Voltar ao sumário Todos esses problemas podem ser tratados de uma forma que se trabalhem os procedimentos, métodos, pessoas, treinamento, motivação, ferramentas e equipamentos. Deste modo, o processo é a intersecção deste conjunto em forma de atividades, ações e tarefas a serem realizadas. Hoje, é possível trabalhar melhoria de processos, através da aplicação de Modelos de Melhoria de Processos de Software. Estas são uma estrutura genérica que descreve as fases, atividades e recursos necessários para um esforço bem- sucedido de melhoria de processo. Algumas das diversas iniciativas para subsidiar a melhoria do processo podem ser conferidas abaixo: CMMI – CMMI significa Capability Maturity Model Integration (Modelo de Capaci- dade e Maturidade Integrado) e como o próprio nome diz é um modelo contendo um conjunto de práticas que servem de referência para que empresas possam me- lhorar os processos e o desempenho no desenvolvimento de produtos e serviços. MPSBr – Melhoria do Processo de Software Brasileiro é um programa da Softex com apoio do Ministério da Ciência, Tecnologia e Inovações (MCTI). Com início em dezem- bro de 2003, o programa tem como objetivo melhorar a capacidade de desenvolvi- mento de software, serviços e as práticas de gestão de RH na indústria de TIC. ISO/IEC 15504/SPICE - padrão que define um conjunto de requisitos para avalia- ção do processo de software. A finalidade do padrão é auxiliar as organizações no desenvolvimento de uma avaliação objetiva da eficácia de um processo qualquer de software. Quando há a intenção de uma empresa em investigar os seus próprios processos para descobrir a aderência em relação aos modelos, é realizada uma auditoria por alguma instituição competente especialista no modelo escolhido. 1.4 Fatores de qualidade Na literatura existem diversos estudos sobre quais fatores de qualidade são importantes para o produto. Alguns desses fatores são conhecidos como: fatores Mc Call e ISO 9126. 1.4.1 – Fatores McCall Os fatores McCall são um conjunto de fatores que avalia o software sob alguns aspectos diferentes. Na Figura 1, é possível vermos graficamente a distribuição dos fatores por área. O primeiro aspecto avaliado é em relação à operação do produto. Neste caso, a operação do produto compreende como ele é utilizado pelos usuários. Sob esses aspectos, temos os seguintes fatores: fatores a serem analisados como, correção, confiabilidade, eficiência, integridade e usabilidade. O segundo ponto de vista é a revisão do produto, e aqui é analisado tudo que diz respeito à manutenção do produto. Os fatores que integram essa vertente são: a manutenibilidade, flexibilidade e testabilidade. Já terceira parte diz respeito à implantação do produto, que é quando analisamos a adaptação do ambiente para diferentes situações, em razão do produto. Os fatores que englobam esta vertente são: portabilidade, reusabilidade e interoperabilidade. 7  Voltar ao sumário Figura 1 – Fatores de qualidade de software de McCall Fonte: Adaptado de Pressman e Maxim (2021) por EAD Unifor. Segundo Pressman (2021), podemos definir cada fator da seguinte forma: Correção. O quanto um programa satisfaz a sua especificação e atende aos objetivos da missão do cliente. Confiabilidade. O quanto se pode esperar que um programa realize a função pretendida com a precisão exigida. Eficiência. A quantidade de recursos computacionais e código exigidos por um programa para desempenhar sua função. Integridade. O quanto o acesso ao software ou dados por pessoas não autorizadas pode ser controlado. Usabilidade. Esforço necessário para aprender, operar, preparar a entrada de dados e interpretar a saída de um programa. Facilidade de manutenção. Esforço necessário para localizar e corrigir um erro em um programa. Flexibilidade. Esforço necessário para modificar um programa em operação. Testabilidade. Esforço necessário para testar um programa de modo a garantir que ele desempenhe a função destinada. Portabilidade. Esforço necessário para transferir o programa de um ambiente de hardware e/ou software para outro. Reusabilidade. O quanto um programa [ou partes de um programa] pode ser reutilizado em outras aplicações — relacionado com o empacotamento e o escopo das funções que o programa executa. Interoperabilidade. Esforço necessário para integrar um sistema a outro (PRESSMAN; MAXIM, 2021, p.313). O conjunto desses fatores proporciona a identificação de melhorias nos produtos de software, de modo a serem avaliados baseados em uma lista de critérios pré-estabelecidos 8  Voltar ao sumário em um checklist previamente testado. 1.4.2 – Fatores ISO 9126 O padrão ISO 9126 foi criado para estabelecer diretrizes básicas de avaliação do produto de software que são estabelecidas em cima de seis atributos: funcionalidade, confiabilidade, usabilidade, eficiência, facilidade de manutenção e portabilidade. A funcionalidade diz respeito ao grau de satisfação de atendimento aos atributos relacionados à adequabilidade e à conformidade, com os requisitos e com segurança. A confiabilidade diz respeito à maturidade do sistema em relação a tolerar falhas e à facilidade de se recuperar de erros. A usabilidade se refere à facilidade de uso do sistema pelos usuários, fornecendo como os subatributos o grau de facilidade de aprendizagem e a operabilidade. A eficiência é o grau de otimização do uso do software, estabelecendo inclusive a melhor utilização de recurso de hardware. A facilidade de manutenção diz respeito ao quão fácil é fazer as alterações no sistema e o quão fácil é o sistema ser testável, além de se basear na estabilidade do sistema. A portabilidade é entendida como o grau de adaptabilidade do sistema em relação a outros dispositivos de hardware e também ao ambiente em que está inserido o software. Neste atributo, também confere a facilidade de realizar as instalações e a facilidade de substituição. 1.4.3 – Fatores desejados Uma vez que o produto de software é construído, existem preocupações sobre quais critérios de qualidade devem ser levados em consideração. Normalmente, estabelece- se uma avaliação para que seja quantificado e mensurado em cima dos critérios como de intuição, que é o grau em que a interface segue os padrões de uso; eficiência, cuja operação é fácil e eficaz; robustez, que é o grau com que o software trata os dados incorretos e se recupera de erros; e riqueza, que estabelece um sistema rico em recursos essenciais. 1.5 Verificação e validação Para atestar se um determinado software está de acordo com os parâmetros estabelecidos, é preciso averiguá-lo sob a perspectiva de estar correto ou se atende às expectativas do usuário. Estas ações são denominadas como “verificar” e “validar” um sistema, respectivamente. Quando falamos em verificação, precisamos nos perguntar se estamos construindo o produto corretamente, e é neste momento que é verificada se a implementação está correta. Visa estabelecer se as funcionalidades dos sistemas estão codificadas de forma devida. Já quando falamos em validação, estabelecemos se o que o foi construído do produto corresponde às expectativas do usuário, determinando se o software atende aos requisitos exigidos pelo cliente. 9  Voltar ao sumário 1.6 Erro, defeito e falha Quando falamos em qualidade e em detectar possíveis pontos de melhoria, devemos esclarecer as diferenças de definições entre o que seria um erro, um defeito e uma falha. Na Figura 2, é sintetizada essa diferença. Figura 2 – Definição e relação entre erro, defeito e falha. Fonte: Elaborado por EAD Unifor (2022). Um erro é algo cometido pelo ser humano. Neste caso, o humano deixa de fazer algum procedimento importante dentro da construção de um determinado produto de software. O defeito é o resultado do erro humano. O defeito é causado pelo erro humano, e possui esta definição quando é identificado em ambiente de desenvolvimento ou de homologação (são ambientes em que não há contato do usuário final com o produto). Já a falha é a consequência do erro causado pelo humano que não foi identificado em tempo de desenvolvimento ou homologação e que ao chegar para a utilização do usuário pode causar uma falha na operação do sistema, fazendo com que ele fique inoperável pelo usuário. 1.7 Custo da qualidade No mercado atual existe uma preocupação muito forte em desenvolver produtos com qualidade. Há um dilema sobre a inserção de qualidade nos produtos de software, visto que para aumentar o nível de qualidade, exige-se investimento pesado em tempo e em dinheiro. É claro que a ausência de investimento em qualidade pode acarretar mais prejuízos e danos, que muitas vezes não são só percebidos pelos usuários com sistemas de má qualidade e com constantes falhas, mas também pelas empresas ou por quem investiu na construção do sistema, pois precisará gastar mais tempo e recurso para a resolução dos problemas que surgirão durante a utilização do sistema pelos usuários. Na verdade, a principal pergunta que precisamos colocar em check é: em qual momento devemos nos preocupar com qualidade? A resposta é que a qualidade deve estar presente em todo o ciclo de desenvolvimento do software, mas o ponto crucial diz respeito ao momento ideal para reparar erros que podem ser encontrados durante o desenvolvimento de um sistema. Na Figura 3, podemos constatar o custo relativo para correção de erros e defeitos em relação às fases de desenvolvimento de um software. 10  Voltar ao sumário Figura 3 – Custo relativo para correção de erros e defeitos. Fonte: Adaptado de Pressman e Maxim (2021) por EAD Unifor. Segundo Pressman (2021), há vários tipos de custos envolvidos em uma construção de sistema. São eles: o custo de qualidade, o custo de prevenção, o custo de avaliação e o custo de falhas. Este último tipo de custo envolve a preocupação do momento em que os defeitos e as falhas serão encontrados. Os defeitos encontrados em tempo de desenvolvimento são bem mais baratos de serem corrigidos do que quando percebidos quando um sistema já foi lançado e está em operação com o usuário. 11  2. Voltar ao sumário Fases da atividade de teste, limitações e impactos dos testes Para que sejam executados testes coerentes e eficazes, é importante atentarmos para a estratégia de teste de software. Estas estratégias devem abordar as perspectivas de qualidade em diferentes níveis e visões da construção do sistema. Uma estratégia de teste de software deve acomodar testes de baixo nível, necessários para verificar se um pequeno segmento de código fonte foi implementado corretamente, bem como testes de alto nível, que validam as funções principais do sistema de acordo com os requisitos do cliente. Uma estratégia deve fornecer diretrizes para o profissional e uma série de metas para o gerente. Como os passos da estratégia de teste ocorrem no instante em que as pressões pelo prazo começam a aumentar, deve ser possível medir o progresso no desenvolvimento, e os problemas devem ser revelados o mais cedo possível (PRESSMAN; MAXIM, 2021, p.373). Muitos podem pensar que uma boa estratégia de teste seria quem desenvolveu o sistema realizar os testes dele, afinal quem construiu o sistema deve conhecer cada detalhe de funcionamento do sistema como nenhuma outra pessoa poderia conhecer. A verdade é que essa estratégia citada no parágrafo anterior não confere como uma boa prática em relação aos testes. Não, no sentido de ter de averiguar todas as perspectivas do funcionamento do sistema. É claro que o desenvolvedor precisa e deve realizar os testes do seu próprio código, mas não é o suficiente para garantir a qualidade dele, pois pode haver enviesamento de intenção, uma vez que o desenvolvedor tende a demonstrar que o sistema está isento de qualquer defeito. Outra estratégia que podemos citar é entregar o software para uma equipe independente de testes, que não conhece o sistema, e ela realiza o teste com o intuito de “quebrar” o sistema. De longe essa parece ser uma ótima opção, pois indica a busca de diferentes visões para a execução dos testes. No entanto, entregar o sistema para pessoas que não conhecem o negócio e propósito do sistema pode culminar em problemas estratégicos da própria execução dos testes. Então, neste caso, o ideal é acompanhar essas equipes independentes de testes, garantindo que o desenvolvedor e todos envolvidos no teste trabalhem juntos. Há ainda um terceiro pensamento estratégico, que seria incluir os testadores do sistema, apenas no final da codificação, logo quando o sistema se torna “executável”. E este é um equívoco comum das equipes de desenvolvimento de software. A função de um analista de teste está muito além de somente realizar a execução do teste. É imprescindível que este profissional esteja presente durante todo o ciclo de vida do sistema, inclusive na fase das concepções de ideias e levantamento de requisitos até a entrega final do projeto. Como vimos, é possível que haja desalinhamento de percepções e estratégias perante a etapa de testes de um sistema. Nas seções seguintes, veremos algumas estratégias que podem ser adotadas perante o processo de software, bem como os desafios inerentes ao procedimento de “teste”. 12  Voltar ao sumário 2.1 – Fases da atividade de teste Segundo Pressman e Maxim (2021), podemos entender o processo de criação de um sistema como uma espiral, assim como podemos ver na Figura 7, onde o princípio das atividades se estabelece na engenharia de sistema, que tem como pressuposto nos dizer o propósito de construção do sistema. Figura 4 – Estratégia de teste Fonte: Adaptado de Pressman e Maxim (2021) por EAD Unifor. Ainda visualizando a Figura 4, percebemos o processo de software interpretando a figura da camada mais externa para a mais interna. Logo após os objetivos estabelecidos, é o momento de realizar o levantamento dos requisitos, que tem como principal característica a idealização dos requisitos funcionais, que são aqueles que descrevem as funcionalidades que o sistema terá, bem como os requisitos não-funcionais, que definem o comportamento do sistema em termos de usabilidade, desempenho, espaço, confiança, proteção, operacionalidade, ambientais, interoperabilidade, segurança, éticos, dentre outros, além de estabelecer todas as regras de negócio e critérios de validação do sistema. Mais em seguida, no interior da espiral, vemos o projeto, que é onde são estabelecidas a modelagem e o design do sistema e, por fim, a codificação. Considerando o desenho do processo de teste em espiral, pode ser sugerida uma estratégia de teste iniciando pelo teste de unidade, posicionado na parte mais interna da espiral. O teste de unidade tem como objetivo verificar cada parte interna do sistema, sendo ele: um componente, classes ou métodos do sistema. Depois, verifica-se o teste de integração, que tem como intuito realizar os testes perante a arquitetura do sistema, na qual identifica como o sistema se comporta com todos os seus componentes em funcionamento. Logo em seguida, temos o teste de validação que tem o intuito de verificar se os requisitos estão sendo atendidos no software construído, tais quais foram estabelecidos. E mais externo à espiral, vemos a estratégia dos testes de sistema que averigua todo o comportamento do sistema em conjunto com o seu ambiente externo, a fim de analisar o sistema como um todo. É importante ressaltar que para utilizar a estratégia de teste sugerido por Pressman e Maxim, deve-se percorrer a espiral da parte mais interna e externa, no sentido horário. 13  Voltar ao sumário 2.1.1 – Teste de unidade Esta estratégia de teste é conhecida também como teste de componente. E é o primeiro nível de teste. Ele assegura que cada funcionalidade especificada para o componente tenha sido implementada corretamente. O enfoque desse nível de teste é averiguar a lógica interna do comportamento das funcionalidades, bem como a sua estrutura de dados. Nesta fase, o objetivo é encontrar falhas (bugs), adquirir confiança e reduzir riscos em partes individuais do sistema, antes que estas partes sejam integradas para compor o sistema. Este teste está incluso nos papéis de responsabilidade do desenvolvedor e deve ser feito após o término do desenvolvimento da unidade do programa, sempre realizado no ambiente de desenvolvimento de software. Além disso, quando é detectada uma falha, a correção é feita sem a necessidade de o desenvolvedor reportar qualquer procedimento de forma oficial. Este tipo de teste deve ser o mais simples possível e deve ser pensado especificamente para a parte em questão a ser testada, pois o teste adequado do componente só é possível durante os testes de integração. Na Figura 5, é possível vermos como aplicar os testes unitários. Por definição, temos o driver, que é o controlador, onde há uma função que envia dados ao módulo a ser testado. Como exemplo, podemos citar uma “main”, quando estamos falando de testes para sistemas orientados a objeto. O stub, que é o controlado, é uma função chamada pelo módulo que está sendo testado. Esses dois tipos de funções simulam o fluxo de informações entre o módulo em teste e os demais a serem integrados. Figura 5 – Esquema de um teste unitário Driver 1 Função A MÓDULO 1 MÓDULO 2 Fonte: Elaborado por EAD Unifor (2022). Com base em testes unitários, podemos identificar alguns tipos de problemas. Dentre eles, podemos citar como exemplo: inicialização incorreta de variáveis; operadores ou precedência aritmética incorreta; falta de precisão; comparações com tipos de dados diferentes; tipos de dados incorretos; comparação de variáveis incorretas; loops incorretos ou infinitos; alterações indevidas no conteúdo de variáveis; uso de recursos de memória; acessos a rede etc. 14  Voltar ao sumário 2.1.2 – Teste de integração Os componentes são construídos e testados separadamente. Com isso, ao serem agrupados, deve-se verificar se eles interagem de forma correta. A essa ação, damos o nome de teste de integração. O teste de integração é o segundo nível de teste e tem como enfoque verificar se os componentes se comunicam conforme o especificado. Tem por objetivo encontrar defeitos, adquirir confiança e reduzir os riscos na comunicação entre os componentes, quando unidos para formar o sistema em questão. Os testes realizados nesse nível auxiliam na construção da arquitetura do software buscando os erros associados às interfaces. A maior dificuldade em colocar todos os módulos juntos está em considerar os dados que podem ser perdidos; ou um componente pode ter efeito imprevisto ou adverso sobre outro; ou ainda os componentes em conjuntos podem não produzir a funcionalidade desejada. Os testes de integração são realizados após a construção dos componentes que devem ser integrados e que já tenham sido passados pelo teste unitário. O ideal é que esse tipo de teste seja realizado em ambiente de desenvolvimento, podendo ser realizado por desenvolvedores, testadores, analista de sistemas, DBA, dentre outras funções. Há ainda mais um nível de teste de integração, sendo que pode se haver teste de integração entre componentes ou teste de integração entre sistemas. Este último só é realizado após o teste de sistema. Já em relação aos métodos de teste de integração, existem dois, sendo eles: big bang ou incremental. No método Big Bang, todos os componentes já testados são combinados de uma única vez e testados em conjunto. Neste tipo de método há um caos, que dependendo do projeto não é adequado, além de ser difícil de rastrear algum erro que possa ser encontrado. Já no método incremental, os componentes são desenvolvidos e testados em partes, o que proporciona maior facilidade para encontrar erros e maior probabilidade de ser testado por completo. O método incremental se divide ainda em dois tipos: Top-down e Bottom-up. No primeiro, a integração dos componentes ocorre de cima para baixo, iniciando-se com o programa principal (main) e acrescentando-se os módulos subordinados. Inicia através do teste do programa principal e utiliza stubs para os níveis abaixo, onde cada stub vai sendo substituído por um componente, como mostra a Figura 6. Os módulos são integrados um a um e testados. O processo se repete até toda estrutura do programa ser construída. 15  Voltar ao sumário Figura 6 - Esquema de teste de integração incremental top-down Fonte: Elaborado por EAD Unifor (2022). Já no método Bottom-up, a integração dos componentes ocorre de baixo para cima, iniciando-se com a construção e teste de módulos da estrutura do programa nos níveis mais baixos. Utilizam-se drivers para os níveis acima e componentes de baixo nível são agregados em clusters de acordo com subfunções específicas que realizem. Um driver é acrescentado para coordenar a entrada e a saída dos dados do cluster. O cluster gerado é testado e o driver é removido e substituído pelo(s) módulo(s) acima. O processo se repete até que toda estrutura do programa esteja construída, como mostra a Figura 7. 16  Voltar ao sumário Figura 7 - Esquema de teste de integração incremental bottom-up Fonte: Elaborado por EAD Unifor (2022). Existem alguns pontos importantes a serem considerados sobre os métodos incrementais top down e bottom up. No Quadro 1, podemos constatar alguns desses pontos: Quadro 1 – Pontos sobre top-down e bottom-up Fonte: Elaborado por EAD Unifor (2022). 17  Voltar ao sumário 2.1.3 – Teste de sistema O teste de sistema é o terceiro nível de teste e tem como foco o sistema como um todo para validar a exatidão e a perfeição na execução das funções requeridas. Este teste deve ocorrer após todos os testes de integração e neste momento toda a arquitetura do sistema está completa ou muito próxima disso. O objetivo deste teste é encontrar defeitos, adquirir confiança e reduzir riscos no comportamento global e particular do sistema. É esperado que o ambiente no qual este teste irá ser realizado seja muito próximo do ambiente de produção (ambiente de utilização real do sistema). Este tipo de teste é realizado com base nas especificações de requisitos, especificações de riscos, processos de negócios, casos de uso, ou outras descrições de alto nível do comportamento, interações e recursos do sistema. Além disso, o momento de realização desses testes é após o término da integração do componente e deve ser realizado especificamente no ambiente de teste por um analista de teste. Nos testes de sistema, deve-se tratar de requisitos funcionais (operação esperada das funcionalidades) e não-funcionais relacionados a desempenho, volume, robustez etc. Neste caso, podemos citar alguns tipos: Teste de Recuperação - força o sistema a falhar de diversos modos e verificar se a recuperação é realizada de forma adequada. Teste de Segurança - verifica se os mecanismos de segurança vão protegê-lo duran- te invasão imprópria. Teste de Estresse - submete o sistema a situações anormais, como, por exemplo, aumentar a velocidade de entrada dos dados para verificar como as funções vão reagir. Teste de Desempenho - testa o desempenho do software durante a execução. 2.1.4 – Teste de validação Este é o último nível de teste antes da implantação no ambiente de produção, e é também conhecido como teste de aceitação. Tem como objetivo verificar se o sistema está pronto para ser implantado em ambiente produtivo com base nos critérios de aceitação. Este é realizado após o término dos testes de sistema e deve ser executado pelo usuário ou alguém responsável pelo sistema. Além disso, este tipo de teste pode ser realizado em ambiente de aceite ou homologação ou de produção. 18  Voltar ao sumário Existem ainda alguns tipos de teste de aceitação. São eles: Teste de aceitação do usuário - usuário conhecedor do negócio verifica se o sistema está apropriado para o uso. É apropriado quando quem vai usar o sistema não é quem está pagando pelo sistema. Teste operacional - teste conduzido para avaliar um componente ou sistema em seu ambiente operacional. Teste de contrato e regulamento - verifica a conformidade dos requisitos, re- gulamentos ou normas contratualmente acordados ou de exigência legal. Teste alfa e teste beta - quando o software é desenvolvido para ser um produ- to a ser usado por vários clientes, é inviável realizar testes de aceite com cada um. A opção é realizar teste de campo para obter feedback de clientes em potencial. O teste alfa ocorre na empresa fabricante do produto, é executado pelo cliente e há presença de desenvolvedores. Já o teste beta, ocorre nas instalações do cliente em potencial, é executado pelo cliente e o desenvolve- dor normalmente não está presente. 2.2 – Limitações e impactos dos testes Nem mesmo uma estratégia entendida como perfeita para a realização de testes de software consegue se sobressair com excelência ao fracasso, se não for tomado o devido cuidado com alguns problemas e obstáculos em relação aos testes. Um dos problemas comuns é a ineficiência de especificação de requisitos do produto de uma maneira quantificável muito antes de começar o teste. Além disso, é de extrema importância que se definam explicitamente os objetivos do teste de forma mensurável. Com isso, um dos pontos cruciais dos testes é entender os diversos perfis de usuário do software para a construção das categorias dos usuários, bem como somando ao desenvolvimento de um plano de teste eficaz, cobrindo o teste do ciclo rápido. O software deverá ser projetado de maneira a usar técnicas de sugestões de diagnóstico de defeitos e as revisões técnicas devem ser eficazes e realizar um filtro nos artefatos gerados no projeto, antes da realização dos testes propriamente dita. As revisões técnicas são importantes também para avaliar a estratégia de testes, bem como os cenários de teste; além de serem complementares ao desenvolvimento de uma abordagem de melhoria contínua para o processo de teste. 19  3. Voltar ao sumário Critérios de teste de software Até aqui foram vistos alguns conceitos fundamentais para o entendimento e realização dos procedimentos adequados e corretos no que diz respeito a verificar e validar artefatos gerados durante o ciclo de vida de desenvolvimento de software. Ao idealizarmos um conjunto de testes de software, perguntamos sobre se aqueles testes e aquela quantidade são razoáveis para averiguar de fato a qualidade do sistema em questão. É neste instante que nos deparamos com a seguinte indagação: mas, quantos testes são suficientes para atestar o sucesso de um programa? Quando se entende que a fase de teste terminou ou se ele conseguiu atingir o objetivo? Será que se garantirmos que todos os meus testes foram realizados e que não há nenhum defeito no sistema verificado, é o suficiente para dizermos que foi finalizada a etapa de teste? Um primeiro aspecto a que temos de ficar atentos é que o teste não é um meio de dizer que determinado sistema está isento de defeitos, uma vez que ao ser executado em ambientes diferentes, por exemplo, um mesmo sistema pode possuir comportamentos distintos. No entanto, alguns pontos a serem analisados e planejados perante as ideias de realização de teste podem ser conferidos nas seções a seguir. Veremos alguns aspectos importantes a se considerar sobre os critérios que podem ser levados em consideração para que sejam respondidas as perguntas do parágrafo anterior. 3.1 - Critérios de “pronto” A primeira ideia que vem à cabeça é o momento que pode ser considerado o software como pronto. Do ponto de vista do desenvolvedor, o “pronto” pode significar o término da codificação do sistema, o que é uma inverdade, pois para entender como finalizado um sistema, é preciso passar pela etapa de teste, bem como pela validação do usuário final. Uma vez que chega à etapa de teste, saber o momento de finalização dos testes é uma etapa um tanto quanto duvidosa. Na literatura existem alguns critérios para nos apoiar a identificar e planejar qual é o escopo necessário para realização de teste. Uma das primeiras perspectivas é de que o teste nunca acaba, sendo que quando os engenheiros de software finalizam a etapa dos testes nos ambientes cabíveis, o sistema continuará em execução perante a utilização do usuário final. Por isso, com essa visão, há quem entenda que o ato de testar um sistema nunca acaba, apenas muda de responsável. Um segundo critério para finalização de um teste, um tanto quanto desconcertante, diz respeito a quando o tempo do projeto ou o dinheiro relacionado à execução do projeto acabam. Na verdade, os dois critérios citados são uma perspectiva informal da finalização de um teste. De forma pragmática, a literatura nos traz algumas possiblidades de analisar se a quantidade de teste foi suficiente. Uma dessas técnicas de definição de critério é a técnica de engenharia de software chamada sala limpa. Esta sugere técnicas de uso estatístico que executam uma série de testes derivados de uma amostragem estatística de todas as execuções possíveis do programa por todos os usuários em uma amostra escolhida. 20  Voltar ao sumário Há também abordagens que abrangem modelagem estatística e a teoria da confiabilidade para serem determinados os critérios de validação de um teste. A técnica de teste por amostragem tem como principal objetivo permitir a inferência estatística em atividades de teste. Devido à impossibilidade de considerar todos os dados de um sistema, é retirado um dado amostral que será utilizado como base e a partir dele serão realizadas conclusões prováveis em maior ou menor grau, dependendo do número de dados considerados e como essa seleção foi feita, gerando assim conclusões incertas. Entretanto, quando essas informações são avaliadas seguindo certos princípios que regem uma pesquisa, o grau de incerteza da inferência estatística pode ser mensurado (NEGRINI, 2014). Já a teoria da confiabilidade se baseia na medição da estabilidade e no desempenho da aplicação durante um determinado período de tempo, sob diferentes condições de teste. Em suma, o teste de confiabilidade visa analisar a integridade, conformidade e interoperabilidade do software, incorporando os resultados de testes não funcionais, como os testes de segurança e estresse, aos testes funcionais. Esse teste pode ser descrito com base em algumas características, sendo elas: recuperabilidade, que visa entender se o software consegue se recuperar após uma falha; maturidade, que compreende a frequência com que a aplicação apresenta falhas inesperadas; tolerância a falhas, que visa entender como o software se comporta quando uma falha ocorre; e conformidade, que averigua se a aplicação está de acordo com normas e convenções previstas em leis. De forma geral, é mais adequado saber o momento em que se atingiu o objetivo do teste, quando são coletadas métricas durante o teste do software e utilizados modelos existentes de confiabilidade de software. Com isto, é possível desenvolver diretrizes significativas para responder à questão de quando de fato se termina um teste. 3.2 - Técnicas e critérios de teste Uma das dificuldades percebidas para entender a quantidade ideal de testes a ser realizada, é o entendimento intrínseco do domínio da aplicação. Vamos supor um caso no qual há um programa que calcula a operação de potência entre dois números, cujo cálculo matemático se dá em um número x elevado a um número y (). Em um primeiro momento, entende-se que a quantidade ideal de testes para este programa é levar em consideração cada elemento do domínio da aplicação, que, no caso, seriam todos os elementos inteiros do nosso universo numérico. Na verdade, essa abordagem é infactível, visto a cardinalidade do domínio. Os autores Delamaro, Jino e Maldonado (2013) explicam melhor este cenário, sugerindo o seguinte raciocínio: y No programa que computa X , o domínio é formado por todos os pares de números inteiros (x, y), o que produz um conjunto de cardinalidade 2n ∗ 2n, onde n é o número de bits usado para representar um número inteiro. Em uma arquitetura com 32 bits isso representa 264 = 18446744073709551616. Se cada caso de teste pudesse ser executado em 1 milissegundo, precisaríamos de 5.849.424 séculos para executá-los todos (DELAMARO; JINO; MALDONADO, 2013, p. 3). Deste modo, é preciso interpretar as representações do domínio da aplicação para que se possa realizar o teste com um subconjunto do universo de testes possíveis para essa dada situação. O objetivo principal de utilizarmos esta estratégia é identificar porções pequenas do universo maior e submeter o programa ao teste. A isso, damos o nome de “subdomínio”. Os subdomínios são caracterizados por trazerem uma ideia de “dados semelhantes”. 21  Voltar ao sumário Então, vamos imaginar alguns cenários de testes para o nosso programa de calcular potência. Digamos que temos, inicialmente, dois cenários a serem validados, sendo o primeiro cenário de teste x=3 e y=-5. O resultado esperado para o cálculo dessa potência seria um erro, uma vez que estamos tratando apenas de números inteiros, pois o resultado de potência com o expoente negativo é um número real; e no segundo cenário de teste, podemos ter x=3 e y=-10 e o comportamento do resultado esperado seria o mesmo do caso anterior. Neste caso, percebemos que não é necessário testar o programa com os dois casos de testes citados, pois dada a implementação, intuitivamente espera-se que o sistema se comporte de maneira semelhante para ambos os casos de teste. Interpreta- se, então, que qualquer cenário de teste que tenha x como um número positivo e y como um número negativo, é esperado resultar em um erro. A este comportamento semelhante, dizemos que estes cenários de testes pertencem ao mesmo subdomínio, por isso, basta executar o teste do programa com apenas um cenário deste subdomínio. Com isso, se conseguirmos identificar pelo menos um caso de teste para cada subdomínio do programa em questão, entende-se que conseguiremos representar cada um dos elementos a serem testados no programa com um número reduzido de testes. Na verdade, há duas formas mais popularmente conhecidas para se conseguir selecionar elementos a serem testados de cada subdomínio de um programa. A primeira é o que se chama de “teste aleatório”, em que um grande número de casos de teste é selecionado aleatoriamente, de modo que, probabilisticamente, se tenha uma boa chance de que todos os subdomínios estejam representados no conjunto de teste T. A segunda é o “teste de partição” ou, mais corretamente, “teste de subdomínios”, no qual se procura estabelecer quais são os subdomínios a serem utilizados e, então, selecionam-se os casos de teste em cada subdomínio. Cada uma dessas abordagens tem suas vantagens e desvantagens. Em relação ao teste de subdomínios, fica a questão de como identificar os subdomínios para, então, fazer a seleção de casos de teste. O que ocorre, na prática, é que são estabelecidas certas “regras” para identificar quando dados de teste devem estar no mesmo subdomínio ou não. Em geral, são definidos “requisitos de teste”, por exemplo, executar determinada estrutura do programa. Os dados de teste que satisfazem esse requisito pertencem ao mesmo subdomínio. Dessa forma, dependendo do tipo de regra que se utiliza, são obtidos subdomínios diferentes e, portanto, conjuntos diferentes de teste. Tais regras são chamadas “critérios de teste”. Podemos identificar três tipos diferentes de critérios: funcionais, estruturais e baseados em defeitos (ou erros) (DELAMARO; JINO; MALDONADO, 2013, p. 3). Na técnica funcional, os critérios e os requisitos de teste são estabelecidos a partir da função de especificação do software; na técnica estrutural, os critérios e requisitos são derivados essencialmente a partir das características de uma particular implementação em teste; e na técnica baseada em defeitos, os critérios e requisitos de teste são oriundos do conhecimento sobre defeitos típicos cometidos no processo de desenvolvimento de software (VICENZI, 2021). 3.3 - Metas, atributos e métricas Todo o conjunto de atividades e de ações descritas até aqui é motivador para conseguir alcançar algumas metas de qualidade. Vamos analisar adiante cada uma dessas metas. 22  Voltar ao sumário Em relação à qualidade dos requisitos, o documento de requisito é uma das principais fontes das quais se baseiam os testes de software, por isso uma das preocupações nas as quais devemos estar fortemente ligados é na completude deste documento. Além de garantir a correção e a consistência do modelo de requisito, pois é esse documento que será base para todos os outros artefatos gerados durante a construção do software. Deste modo, é de suma importância que todos os envolvidos no desenvolvimento do software estejam a par de cada detalhe de elaboração deste documento de requisito, garantindo um alto nível de qualidade. Sobre a qualidade do projeto, um ponto de suma importância, e que deve ser alinhado junto às expectativas do que o sistema irá realizar em caráter operacional, é estabelecer o que se espera do projeto que norteia a construção deste sistema. É importante criar marcos durante o projeto, além de medir adequadamente os passos sobre cada entrega do projeto, seja ele no momento de modelagem, de codificação ou de testes. A equipe de qualidade deve ficar atenta aos indicadores que podem ferir a qualidade do projeto, como, por exemplo, alguma diretriz de qualidade que não está sendo seguida. Referente à qualidade do código, todos os artefatos gerados durante o desenvolvimento de um sistema devem atender a altíssimos padrões de qualidade, seja ele o código-fonte ou outros artefatos relacionados ao desenvolvimento, como, por exemplo, o documento arquitetural que nos diz como será o comportamento do sistema perante as integrações dos demais sistemas que possam existir em comunicação com mesmo. A equipe de qualidade deve garantir uma inspeção forte sob o código do sistema para garantir que as boas práticas de codificação estão sendo atendidas. Por fim, a eficácia do controle de qualidade está relacionada com a equipe de qualidade, que deve sempre ficar dispostos a verificar a melhor forma de aplicar os recursos para obter o maior nível de qualidade possível de todos os artefatos gerados na construção do sistema. As pessoas dessa área devem ser as evangelizadoras da qualidade. No Quadro 2, sugerido por Pressman e Maxim (2021), identificam-se os atributos indicadores da existência de qualidade para cada uma das metas discutidas. Também são mostradas as métricas que podem ser utilizadas para indicar a força relativa de um atributo. Quadro 2 - Metas, atributos e métricas para qualidade de software 23  Voltar ao sumário Fonte: Adaptado Pressman e Maxim, (2021) por EAD Unifor. 24  Voltar ao sumário Como podemos ver, há um conjunto de atributos relacionados com cada meta, e um ponto muito importante são as mensurações das métricas. Uma vez que conseguimos identificar e coletar os dados através das métricas, é possível estabelecermos tomada de decisões para qual rumo o projeto deve tomar ou melhor, para qual perspectiva a qualidade de software deve ser pensada. Vejamos, como exemplo, o atributo de volatilidade, que pode ser percebido através da métrica do número de mudanças por requisito. Quando as mudanças sobre determinado requisito acontecem de forma contínua, pode ser um indício de que algo está equivocado no levantamento do requisito. É possível tirarmos como conclusão, por exemplo, que o cliente não tem certeza sobre o que quer ou mesmo que aquela funcionalidade pode não estar pensada adequadamente. Um segundo exemplo, que podemos trazer à tona, é referente à meta de eficiência de controle de qualidade. Especificamente, a eficácia dos testes, que é calculado através do número de erros encontrados e de sua gravidade; além ainda de somar-se a outra métrica que seria o esforço exigido para corrigir um erro. Essas duas métricas podem nos trazer visões importantes sobre a evolução de codificação do sistema. Então, digamos que durante o momento dos testes de uma determina aplicação é encontrado um defeito de pouca gravidade, mas que se repete durante muitas vezes durante os testes. Isso pode nos trazer indícios de que há algo errado com a codificação do sistema. Se o defeito é simples, isso quer dizer que não seria algo que impactasse na evolução dos testes do sistema, mas, como no exemplo citado, acontece com grande frequência, o esforço de corrigir o mesmo problema durante vários momentos da construção do sistema resulta em desperdício de tempo e dinheiro na construção do sistema, uma vez que as pessoas que estão envolvidas neste desenvolvimento terão retrabalho sobre a mesma situação. Neste caso, o ideal é o desenvolvedor e o analista de teste analisar a causa raiz do problema para que seja corrigido e que não haja mais incidência da mesma situação. 25  4. Voltar ao sumário Papel do analista de testes, certificações, equipes de times ágeis Agora que você já viu os conceitos fundamentais da área de qualidade, bem como de testes de software, analisaremos neste Circuito de Aprendizagem o papel do analista de teste, de uma forma singular, e vamos averiguar esse papel e as suas particularidades, quando falarmos de diferentes perspectivas de desenvolvimento do software. Isso porque, uma vez que é escolhido o modelo de desenvolvimento do ciclo de vida do software, o papel do analista de teste pode variar algumas de suas responsabilidades e funções dentro da equipe. Fecharemos este Percurso de Aprendizagem conhecendo algumas possibilidades de certificações na área de teste de software, estabelecendo a importância que as mesmas incidem na carreira do profissional da área e o valor que possuem no mercado de trabalho. 4.1 – Papel do analista de testes O analista de teste é o responsável por identificar e definir os testes exigidos, monitorar o processo de teste em detalhes e os resultados em cada ciclo de teste e avaliar a qualidade geral. Deve garantir a qualidade dos componentes produzidos por meio da verificação de evidência de testes e utilização de técnicas especializadas em testes de programas e sistemas. Podemos citar como algumas atribuições do analista de testes as seguintes: Compreender a arquitetura do produto a ser testado; Planejar a estratégia de testes, para executar testes e encontrar as questões ocultas; Analisar os prós e os contras do plano específico, bem como os riscos liga- dos a cada um dos componentes e interfaces do produto; Analisar o código que precisa testar; Executar casos de teste com perícia; Coletar as evidências para documentar os testes e os defeitos detectados; Trabalhar com guias e ferramentas de automação; Manter-se a par dos aspectos técnicos da infraestrutura do projeto (por exem- plo, navegadores, bases de dados, línguas etc.); Analisar e registar questões, e fornecer feedback apropriado. 26  Voltar ao sumário No que diz respeito às habilidades e às competências, que são qualidades que um profissional possui naturalmente para desenvolver algo ou atributos que são desenvolvidos ou aperfeiçoados através de experiências ao longo da carreira, são: Boa habilidade analítica; Uma mente desafiadora e curiosa; Atenção aos detalhes e tenacidade; Entendimento de falhas de softwares comuns; Conhecimento de todos os aspectos do processo de engenharia de software; Conhecimento do domínio (muito desejável); Conhecimento do sistema ou aplicativo em teste (muito desejável); Conhecimentos básicos de base de dados; Trabalhar com ferramentas de Gestão de Testes; Trabalhar com ferramentas de detecção de defeitos/Bug testing; Trabalhar com ferramentas de Automação (web, mobile e APIs); Fortes conhecimentos da língua inglesa. 4.1.1 – Analista de teste e Analista de qualidade O trabalho de Analista de Testes está conectado à qualidade do produto e, muitas vezes, ele pode atuar também como Analista de Qualidade ou, no termo em inglês, Quality Assurance (QA). Nesse caso, o analista não valida apenas o produto, mas todo o processo de criação, da concepção inicial da ideia do software à entrega do produto. Em resumo, Quality Assurance foca em garantir que o produto ou serviço tenha a melhor qualidade possível. Para isso, o profissional analisa todos os passos da sua criação e o modo de trabalho das equipes que participaram do desenvolvimento, testando objetivos, desempenho e agilidade. Esse olhar mais global ajuda a maximizar resultados, já que os testes de QA podem encontrar erros no início do processo que poderiam ter ficado sem correção até a fase final, caso esse profissional não existisse. Isso evita perda de tempo, dinheiro e ainda fideliza o cliente e o consumidor. De modo geral, o analista de teste seria aquele envolvido especificamente na área de testes de software, elaborando casos de testes e executando. Já o analista de qualidade seria aquela pessoa envolvida no trabalho que define um processo de desenvolvimento de software e depois certifica esse processo. 4.2 – Equipes de times ágeis Quando pensamos no desenvolvimento tradicional de software, já vem à mente o modelo cascata. Este modelo se caracteriza por abordar os processos de desenvolvimento de um sistema por etapas, iniciando com a etapa de comunicação, na qual se estabelece o início do projeto junto com a análise de viabilidade e os levantamentos iniciais dos requisitos. Após isso, percorre todas as etapas passando pelo planejamento, modelagem, construção e entrega do software. 27  Voltar ao sumário É sabido que nos modelos tradicionais, como o cascata, o analista de teste só tem contato com o sistema após a sua codificação e não há contato com o cliente ou usuário final do sistema. Neste modelo citado, a atividade de testes se encontra na fase de construção do sistema. Percebemos que o analista de teste só vai ser incluso no processo de desenvolvimento do sistema, muito após as tomadas de decisão mais importantes para a construção do sistema. Isso pode gerar alguns problemas, como, por exemplo, encontrar falhas que advêm de documentações muito tardiamente e, consequentemente, esses problemas vão se estendendo para as outras etapas do desenvolvimento do sistema, que muito provavelmente só serão identificados na fase de teste. Este é um equívoco comum à maioria das empresas, o analista de teste é incluso no processo apenas no final da etapa de construção do sistema. Grande parte dos motivos que levam as empresas a optar por essa inclusão tardia do profissional de teste no processo de desenvolvimento advém da cultura organizacional da empresa, que trabalha da mesma forma por muitos e muitos anos, e nem sempre é possível mudar do dia para a noite. Com o advento do manifesto ágil, muitas empresas têm mudado o seu mindset, procurando estabelecer novas formas de metodologias de desenvolvimento de software, as quais são conhecidas como modelos ágeis. De uma forma geral, a filosofia ágil vem com pensamentos disruptivos em relação ao desenvolvimento de software. Os valores ágeis passam a visualizar mais os indivíduos e as suas interações do que processos e ferramentas, além de que pressupõem que software em funcionamento é melhor do que documentação abrangente. Além de que, focar na colaboração com o cliente, mais do que negociar contratos e a resposta a mudanças, é uma premissa essencial, mais do que seguir um plano. Deste modo, o perfil da equipe de desenvolvimento ágil passou a ser mais autônomo, construindo uma perspectiva de autonomia para tomada de decisões do time envolvido no desenvolvimento de um sistema. Isso quer dizer que todos os indivíduos que pertencem a uma equipe ágil precisam participar de todo o processo de desenvolvimento de um sistema, desde a sua concepção até a entrega, com o intuito de evitar problemas de comunicação e facilitar o entendimento do que precisa ser desenvolvido. Cada metodologia ágil pressupõe um conjunto de funções diferentes para cada pessoa envolvida no projeto, mas de forma genérica essas equipes devem ser um grupo de pessoas com um objetivo comum, que sejam flexíveis na maneira de trabalhar e mais adaptáveis ​​às mudanças nos requisitos dos clientes. Uma coisa que os distingue das equipes tradicionais é que são indivíduos autodirigidos e auto-organizados que praticam a liderança compartilhada. Outra característica comum que muitas pessoas associam às equipes ágeis é a multifuncionalidade. Elas colocam o foco na generalização de especialistas que podem contribuir para vários domínios em vez de apenas para os seus próprios. A ideia é cruzar as habilidades das pessoas em uma única equipe com o objetivo de eliminar transferências e dependências. Equipes ágeis são formadas por grupos pequenos de pessoas. Entre cinco e seis pessoas com habilidades distintas para o cumprimento do objetivo. Sendo assim, é preciso criatividade e um time altamente capacitado tecnicamente, capaz de se adaptar às mudanças e superar os desafios que possam surgir. 28  Voltar ao sumário 4.3 – Certificações Uma curiosidade frequente para quem atua na área de qualidade de software é saber quais as certificações da área, mais especificamente voltadas para os testes de software. A principal dúvida que surge pelos profissionais que atuam ou gostariam de atuar como QA é se é obrigatório tirar alguma certificação de teste para conseguir ingressar no mercado de trabalho neste ramo. A resposta é que não é obrigatório tirar certificação para atuar com testes de software. No entanto, as certificações não só garantem um emprego mais bem remunerado, como também ajudam os empreendimentos a reduzir os riscos para que o software desejado por eles possa ser aceito por seus clientes globalmente. Por tanto, ter certificações na área valoriza ainda mais o seu currículo profissional, por isso, vamos conhecer algumas delas a seguir. 4.3.1 – CAST (Certified Associate in Software Testing) O CAST, também conhecido por Associado Certificado em Teste de Software, identifica profissionalmente a capacidade de um candidato, ao mesmo tempo em que demonstra os princípios de teste de software e suas práticas de qualidade em um nível fundamental. Alguns pré-requisitos para se tirar a certificação são: 3 ou 4 anos de graduação em instituição de nível universitário (credenciada); 2 anos de graduação em instituição de nível universitário (credenciada) + 1 ano de experiência na área de serviços de TI; 3 anos de experiência na área de serviços de TI. Para se candidatar à certificação CAST, você deve se enquadrar em um dos três pontos citados. A taxa dessa certificação é de 100 dólares americanos e pode-se pagar online após ler atentamente as condições de pagamento. Além de tudo isso, a certificação testará seus conhecimentos em diversas áreas de habilidade. Eles serão como construir um ecossistema de teste de software, tendo em mente as condições e as influências ao redor, seu vocabulário sobre métodos e abordagens de teste de software, gerenciando o projeto de software alocado por meio de comunicação, monitoramento, pessoal, orçamento e programação. Além disso, existem algumas outras áreas de habilidade, como a magnitude do(s) risco(s) associado(s) ao ciclo de vida do sistema de software atual de implantação, design dos casos de teste (como caixa preta), revisões de pontos de verificação e as exceções necessárias, teste de tecnologias especializadas de aplicativos móveis ou aplicativos baseados em nuvem, e relatórios dos testes após coletar as métricas e gráficos dos dados interpretados. 4.3.2 - CSQA (Certified Software Quality Analyst) Conhecida pela sua tradução para o português, como Certificação de Analista de Qualidade de Software, esta certificação permite-lhe receber reconhecimento desde que a candidatura seja identificada e avaliada com base no nível de competência profissional. 29  Voltar ao sumário Graduação de 4 anos em instituição de nível universitário [credenciada] + 2 anos de experiência na área de serviços de TI; Graduação de 3 anos em instituição de nível universitário [credenciada] + 3 anos de experiência na área de serviços de TI; Graduação de 2 anos em instituição de nível universitário [credenciada] + 4 anos de experiência na área de serviços de TI; 6 anos de experiência na área de serviços de TI. Para sua candidatura ser qualificada, você precisa atender a um dos pontos citados. Apesar de todos esses quatro pré-requisitos, a taxa de certificação CSQA é de 350 dólares americanos ou $450. Você deve acessar a seção de política de pagamento para saber com precisão sobre os termos e condições. De fato, a certificação testará seus conhecimentos sobre a avaliação de produtos de software e serviços conectados de acordo com os conceitos e princípios de Garantia de Qualidade; definir, implementar e melhorar as iniciativas de liderança de controle de qualidade alinhadas com o comportamento e compromisso com a gestão, avaliando as linhas de base dos módulos de software para que as organizações possam medir de forma proativa a satisfação geral do cliente. Não só isso, mas também o conhecimento sobre terceirização e COTS nas auditorias de controle interno é cruzado, o que pode simplificar os planos de garantia de qualidade endereçados. 4.3.3 – Certificação do International Software Testing Qualifications Board (ISTQB) O ISTQB, conhecido também como Conselho Internacional de Qualificações de Teste de Software, dispõe de diversas certificações na área de teste. Esta certificação é mais amplamente reconhecida para teste de software em um nível básico, bem como em um nível avançado. Atualmente, a certificação de nível de especialista está sendo desenvolvida. Para todos esses níveis, os grupos de trabalho do ISTQB estão operando internacionalmente para que os candidatos possam se preparar bem para funções como testadores de software, gerentes de teste, analistas de teste, diretores de TI e gerentes de QA, fornecendo, inclusive, materiais de estudos, como, por exemplo, o Syllabus. As certificações estão organizadas em três níveis: Foundation; Advanced e Expert: O nível Foundation é o mais “básico”. É onde se insere a certificação: CTFL Foundation Level; CTFL Agile Tester; CTFL Model Based Test; No nível Advanced se inserem as certificações: CTAL-TTA (Technical Test Analyst); CTAL-TA (Test Analyst); CTAL-TM (Test Manager); CTEL-ST (Security Testing) e CTEL-TA (Test Automation); No nível Expert encontram-se as seguintes: CTEL-TM (Test Management) e CTEL-ITP (Improving the Test Process). Para os candidatos que desejam receber a certificação de nível avançado, eles devem possuir a certificação Fundacional. 30  Voltar ao sumário A ABRAMTI (entidade sem fins lucrativos) é mantenedora do BSTQB (Brazilian Software Testing Qualifications Board) ou, traduzindo, Conselho Brasileiro de Qualificações para Teste de Software. É um dos Conselhos Membros do ISTQB, e seu representante exclusivo no território nacional. O BSTQB é responsável pela tradução e gestão do corpo de conhecimento (Syllabus) e realização de Exames Oficiais de Certificação Internacional em Teste de Software no Brasil. Confira na Figura 8 algumas das certificações possíveis na área. Figura 8 – Certificações pelo BSTQB Fonte: Adaptado de ABRAMTI (2006) por EAD Unifor. 4.3.4 – Engenheiro de Qualidade Certificado (CQE) Há um exame em duas modalidades. O primeiro é entregue por computador (em inglês), que contém 175 questões no total, que você precisa responder em 5 horas e 18 minutos; destas, 160 perguntas são do tipo de múltipla escolha e 15 perguntas que não têm pontuação, o que significa que não afetarão suas notas finais. Há também o exame de papel e lápis (em inglês, português, espanhol, mandarim e coreano em certos locais) para engenheiro de qualidade certificado. Tem 160 questões que precisam ser concluídos em 5 horas. Você deve ter 8 anos de experiência em uma ou mais áreas do CQE ou um mínimo de 3 anos de experiência (tempo integral, função remunerada como estagiário ou funcionário) na posição de tomada de decisão (você deve estar envolvido na execução e no controle dos processos de inspeção de qualidade) em qualquer uma de suas áreas. 31  Voltar ao sumário 4.3.5 – Gerente Certificado de Teste de Software (CMST) Esta certificação avalia as capacidades e competências dos candidatos inclinados para o teste de software. Para ser candidato a esta certificação, deve-se atender a um dos seguintes pontos: Bacharelado em Ciência da Computação ou outra área da engenharia por uma ins- tituição de nível universitário (credenciada) + 4 anos de experiência na área de ST; Grau de associado + 6 anos de experiência na área de ST; 8 anos de experiência na área de ST. Além disso, existem 100 questões de múltipla escolha das quais o candidato deve responder 70 corretamente para passar na certificação CMST, cuja taxa é de 450 dólares americanos. Em uma base geral, esta certificação avaliará sua candidatura com base no planejamento de recursos, rastreabilidade e controle de vários processos de teste, implementação e design do produto que atenderá aos requisitos dos clientes e manutenção de lançamentos em algum lugar relacionado aos padrões de qualidade do mercado. 32  Voltar ao sumário REFERÊNCIAS ABNT - Associação Brasileira de Normas Técnicas. NBR ISO 9126: Engenharia de software – Qualidade do produto. Rio de Janeiro, 2003. 21p. ABRAMTI (Brasil, São Paulo, Osasco). Quem somos. Osasco, SP, 2006. Disponível em: https://bstqb.org.br/b9/. Acesso em: 27 nov. 2022. BOEHM, Barry; BASILI, Victor R. Software defect reduction top 10 list. Software engineering: Barry W. Boehm’s lifetime contributions to software development, management, and research, v. 34, n. 1, p. 75, 2007. CATHO (Brasil, São Paulo, Barueri). Analista de testes. Barueri, SP, 2022. Disponível em: https://www.catho.com.br/profissoes/analista-de-testes/. Acesso em: 28 nov. 2022. DELAMARO, Marcio; JINO, Mario; MALDONADO, Jose. Introdução ao teste de software. Elsevier Brasil, 2013. ISD, Brasil. O que é CMMI?. [S. l.], 2022. Disponível em: http://www.isdbrasil.com.br/o- que-e-cmmi.php. Acesso em: 25 dez. 2022. NEGRINI, Célia. Entendendo o teste de software por amostragem. DEVMEDIA, 2014. Disponível em: https://www.devmedia.com.br/entendendo-o-teste-de-software-por- amostragem/31377. Acesso em: 25 nov. 2022. PRESSMAN, Roger S.; MAXIM, Bruce R. Engenharia de software: uma abordagem profissional. 9ª Edição. McGraw Hill Brasil, 2021. SILVA, Mauro César da. CMMI para iniciantes. [S. l.], 2022. Disponível em: http://www. linhadecodigo.com.br/artigo/1401/cmmi-para-iniciantes.aspx. Acesso em: 22 nov. 2022. VICENZI, Auri Marcelo Rizzo et al. Programação e desenvolvimento dirigido por testes em Python. Gitbook: [s. n.], 2021. Disponível em: https://aurimrv.gitbook.io/tdd-python/. Acesso em: 27 nov. 2022. 33  Voltar ao sumário UNIVERSIDADE DE FORTALEZA (UNIFOR) Presidência AUTORA Lenise Queiroz Rocha ANA KLYSSIA MARTINS VASCONCELOS Vice-Presidência Manoela Queiroz Bacelar Mestra em Sistemas de Informação pela Universidade de Reitoria São Paulo. Especialista em UX (Experiência do Usuário) Fátima Maria Fernandes Veras pela Universidade Anhembi Morumbi. Bacharela em Sis- Vice-Reitoria de Ensino de Graduação e Pós-Graduação temas de Informação pela Universidade Federal do Ceará. Maria Clara Cavalcante Bugarim Possui experiência na área de Sistemas de Informação com ênfase em Engenharia de Software, Gestão de Pro- Vice-Reitoria de Pesquisa jetos, Governança de TI e Qualidade de Software. Atuou José Milton de Sousa Filho como professora de graduação e pós-graduação na insti- Vice-Reitoria de Extensão tuição de ensino superior Anhembi Morumbi. Atualmente Randal Martins Pompeu é analista de qualidade de software na Wipro Brasil, com atuação na M. Dias Branco, e atua como professora desta Vice-Reitoria de Administração instituição. José Maria Gondim Felismino Júnior Diretoria de Comunicação e Marketing Ana Leopoldina M. Quezado V. Vale Diretoria de Planejamento Marcelo Nogueira Magalhães Diretoria de Tecnologia José Eurico de Vasconcelos Filho Diretoria do Centro de Ciências da Comunicação e Gestão Danielle Batista Coimbra Diretoria do Centro de Ciências da Saúde Lia Maria Brasil de Souza Barroso Diretoria do Centro de Ciências Jurídicas Katherinne de Macêdo Maciel Mihaliuc Diretoria do Centro de Ciências Tecnológicas Jackson Sávio de Vasconcelos Silva RESPONSABILIDADE TÉCNICA COORDENAÇÃO DA EDUCAÇÃO A DISTÂNCIA Coordenação Geral Andrea Chagas Alves de Almeida Supervisão de Planejamento EAD Identidade Visual / Arte Ana Flávia Beviláqua Melo Francisco Cristiano Lopes de Sousa Paulo Renato Mendes Almeida Supervisão de Recursos EAD Francisco Weslley Lima Editoração / Diagramação Emanoel Alves Cavalcante Analista Educacional - Pedagógico Rafael Oliveira de Souza Lara Meneses Saldanha Nepomuceno Rebeka Melo Peres Analista Educacional - Mídias Régis da Silva Pereira Emanoel Alves Cavalcante Produção de Áudio e Vídeo Projeto Instrucional José Moreira de Sousa Ana Lucia Do Nascimento Pedro Henrique de Moura Mendes Maria Mirislene Vasconcelos Programação / Implementação Revisão Gramatical Renan Alves Diniz Janaína de Mesquita Bezerra Thais Rozas Teixeira José Ferreira Silva Bastos 34