GERENCIAMENTO E QUALIDADE DE SOFTWARE - LIVRO

Prévia do material em texto

Gerenciamento de software – unidade 1
O desenvolvimento de software nos remete ao código, ao teste e à entrega, mas há um fator fundamental que percorre o software desde o seu início até sua implantação: o gerenciamento de software.
O gerenciamento de software abrange uma série de atividades e processos que são essenciais para garantir o sucesso do produto, desde sua ideia inicial até a sua implantação. Logo a seguir, temos as principais etapas do gerenciamento.
O planejamento estratégico consiste nas estratégias claras para o desenvolvimento e a entrega do software. No início do planejamento estratégico, é necessário avaliar as necessidades da organização em relação ao software, entendendo os desafios, as oportunidades e os objetivos de negócio que o software deve atender alinhado às metas das organizações.
Após a definição dos objetivos, é importante realizar uma análise de viabilidade dos projetos de software, considerando fatores, como: recursos, custos envolvidos, prazos, riscos e retorno de investimento.
A análise de viabilidade auxilia na seleção dos projetos mais adequados para a inclusão de um plano estratégico. Com base nesta análise, os projetos de software são priorizados de acordo com sua relevância estratégica, considerando o alinhamento com os objetivos estratégicos, baseado na urgência e na capacidade de execução.
Também é nesta etapa que há a definição de planos e cronogramas, envolvendo a alocação de pessoas e recursos e estimativa de prazos, em que se faz necessário que os planos e cronogramas sejam revisados regularmente para garantir o processo adequado.
É importante tratar que, no planejamento estratégico, é fundamental garantir a comunicação eficaz entre as partes interessadas, que são: usuários finais, equipes de desenvolvimento e alta administração.
A análise de requisitos abrange análises, documentações e validações de requisitos, garantindo que os requisitos estejam claros, completos e testáveis, incluindo o entendimento das necessidades do usuário, a priorização de requisitos e a identificação das funcionalidades necessárias.
O design e arquitetura envolve a identificação dos componentes, a definição das interfaces e a organização lógica do software.
Desenvolvimento e codificação é o processo de supervisionar o desenvolvimento e a codificação do software. Isso envolve a programação, a implementação dos requisitos definidos, a revisão de código e a aplicação de boas práticas de programação, assegurando que o desenvolvimento seja conduzido de forma eficiente, dentro dos prazos e orçamentos estabelecidos em equilíbrio com a equipe.
Testes e qualidade é a execução de estratégias de teste para garantir a qualidade do software e o atendimento dos requisitos. Nesta fase, são incluídos testes unitários, testes de integração, testes de sistema, testes de aceitação e testes de usabilidade, promovendo a adoção de boas práticas de garantia da qualidade, como testes funcionais e não funcionais.
Implementação e manutenção é a fase de implantação do software em um ambiente de produção e a sua manutenção contínua, gerenciando a preparação do ambiente, que inclui a instalação do software, a migração de dados e a configuração de outros sistemas.
Aluno, diante de todas as fases listadas, podemos entender o quanto o gerenciamento de software é importante para termos um bom produto.
Desafios do gerenciamento de software
Já entendemos o que é o gerenciamento de software e suas etapas, agora vamos para os seus desafios. Segundo Prado (2000), o nível de sucesso das organizações na produção de um resultado ou na criação de um produto está diretamente ligado ao nível de maturidade em que estas empresas se encontram no que diz respeito às habilidades de condução de seus projetos, pois, quanto maior o amadurecimento em gerenciamento de software, mais previsíveis se tornam os resultados.
No entanto, em relação ao software, deve-se destacar que restrições de orçamento e cronograma são comuns. Sommerville (2011) diz que o sucesso do projeto não é garantido por um bom gerenciamento, mas o mau gerenciamento costuma resultar em falha do projeto. O autor ainda cita que a engenharia de software é diferente dos outros tipos de engenharia em muitas formas, devido tornar o gerenciamento de software desafiador.
Figura 1 - Desafios no gerenciamento de software
Pressman e Maxim (2021, v. 9, p. 968) exemplificam sobre um gerenciamento de software fraco com um comentário de Meilir Page-Jones (1985): “Testemunhei, horrorizado (…) gerentes dedicarem esforços em projetos que eram verdadeiros pesadelos, contorcendo-se em prazos impossíveis ou entregando sistemas que ultrajavam seus usuários e continuavam a devorar um bocado de tempo de manutenção”.
O gerenciamento de software fraco, geralmente, se dá pela existência de ineficiência ou problemas significativos no modo de condução e coordenação dos projetos. Alguns sinais de um gerenciamento de software fraco podem incluir:
· Atrasos frequentes: projetos que constantemente estão atrasados em relação aos prazos estabelecidos, indicando um equívoco no planejamento pela falta de definição de prioridades ou recursos insuficientes para finalizar dentro do cronograma.
· Acima do orçamento: quando não há um controle adequado dos custos devido a estimativas irreais ou à falta de monitoramento financeiro no projeto, pode-se estourar o orçamento estipulado.
· Falta de comunicação e colaboração: a falta de uma comunicação clara e aberta com as pessoas interessadas pelo produto pode gerar um mal entendimento do que é necessário para o sistema, prejudicando o objetivo do projeto.
· Baixa qualidade do produto: o resultado de um software com muitos defeitos, erros ou bugs indica a falta de qualidade perante uma análise falha do escopo do software, ocasionando erros no desenvolvimento do produto.
· Falta de definição dos requisitos: um fator influenciador pela falta de comunicação são os requisitos de software, que não se encontram claros e/ou possuem constantes mudanças, podendo resultar em um produto final que não atende às expectativas dos usuários.
· Alto índice de rotatividade da equipe: uma equipe de desenvolvimento que sofre pela alta rotatividade de seus membros pode ser resultado de problemas de liderança, falta de motivação ou até mesmo um ambiente de trabalho não saudável.
Para evitarmos um gerenciamento de software fraco, deve-se abordar esses problemas específicos de forma proativa, implementando práticas de gerenciamento de software mais eficientes, como veremos a seguir.
Gerenciamento de software mais eficiente
Um gerenciamento de software eficiente se constrói por meio de uma combinação de elementos-chave. Pressman e Maxim (2021) destacam que o gerenciamento eficiente do desenvolvimento de software se concentra nos 4 Ps: pessoas, produto, processo e projeto, não sendo de ordem arbitrária, em que um é tão importante quanto o outro.
Pessoas
A construção de um software é realizada por pessoas, e o sucesso de um projeto depende de pessoas bem treinadas e motivadas.
Pressman e Maxim (2021) ressaltam que o elemento humano, representado pelas pessoas envolvidas no desenvolvimento, é essencial para o sucesso. Quando o gerenciamento de software não reconhece a importância do esforço humano e não coloca as pessoas no centro do processo, pode enfrentar dificuldades significativas para o êxito do processo.
É crucial reconhecer e valorizar as habilidades, o conhecimento e as contribuições individuais de cada membro da equipe, além de fornecer um ambiente de trabalho colaborativo. Pessoas motivadas e engajadas são fundamentais para uma entrega bem-sucedida.
Outro fator é manter uma comunicação clara e aberta, em que os envolvidos possam se sentir encorajados a compartilhar informações, ideias e preocupações, alinhando suas expectativas, resolvendo problemas e mantendo os membros da equipe engajados e informados. Além de investir no desenvolvimento profissional da equipe, encorajando a colaboração entre todos.
Produto
No início do planejamento estratégico, vimos que sãoatingir o seu pico, em relação ao número de usuários simultâneos, por exemplo. Neste teste, os recursos do sistema são sobrecarregados e levam o sistema para um estado de falha.
· Teste de redundância: têm o objetivo de verificar se o sistema ou os seus componentes de backup estão funcionando corretamente. Estes sistemas devem ser capazes de assumir as funções do componente principal em caso de falha. Podem incluir cenários de failover, recuperação de desastres, integridade de dados e muitos outros.
Testar sistemas de tempo real é um desafio complexo. Mesmo diante de possíveis falhas, estes sistemas devem ser capazes de manter sua operação contínua e confiável. Manter os registros dos resultados dos testes é essencial para a tomada de ações corretivas e aprimoramento contínuo.
Testes estruturais (caixa branca) e funcionais (caixa preta)
Sabemos que os níveis de teste são executados um após o outro à medida que o desenvolvimento do sistema fica mais avançado, respondendo à pergunta: “Quando testar?”. Agora, devemos responder à seguinte pergunta: “Como testar?”. Nesse momento, falamos em técnicas de teste, as técnicas estruturais e funcionais, ou caixa branca e caixa preta.
O teste estrutural, conhecido também como teste caixa branca, é uma técnica que nos permite olhar "dentro" do software e examinar sua estrutura interna. Este tipo de abordagem é utilizado para identificar falhas de programação, entender o fluxo do código e garantir que as partes individuais do software foram escritas corretamente.
Testes estruturais podem ser executados em todos os níveis de testes, mas, geralmente, são mais usados no nível de teste de unidade. O uso destas técnicas é recomendando logo após o uso de técnicas baseadas em especificação, pois auxilia a medição da eficiência do teste através da análise de cobertura.
Cobertura é a extensão que uma estrutura foi exercitada por um conjunto de testes, expressa como uma porcentagem de itens cobertos (CTFL Syllabus, 2023). É medida como o número de instruções exercidas pelos casos de teste dividido pelo número total de instruções executáveis no código.
Essa forma de teste é desempenhada como um teste "estático", em que o software propriamente dito não é executado para desempenhar o teste. Com o auxílio de ferramentas de diagnóstico, é possível analisar o código fonte, procurando erros estruturais e os pontos fracos, fornecendo uma lista para ativar a ação corretiva a ser realizada. Esse tipo de teste é conduzido por desenvolvedores, em vez de testadores de sistema.
As técnicas de teste caixa branca comumente usadas são Teste de Instrução e Cobertura de Instrução e Teste de Ramificação e Cobertura de Ramificação.
Características comuns das técnicas baseadas em estrutura (CTFL Syllabus, 2023):
· Informações sobre como o software é construído são utilizadas para derivar os casos de testes. Por exemplo, código e modelagem.
· A extensão da cobertura do código pode ser medida pelos casos de testes. Além disso, os casos de testes podem ser derivados sistematicamente para aumentar a cobertura.
Por outro lado, o teste funcional, conhecido também como teste caixa preta, é uma técnica que nos permite verificar se um programa realiza suas funções conforme especificado nos requisitos. Esta técnica de teste é desempenhada de forma “dinâmica”, em que o software é executado para desempenhar o teste e avalia o comportamento de um software a partir de uma perspectiva externa, sem a necessidade de conhecer detalhes internos da sua estrutura.
Testes caixa preta pode ser executada em quase todos os níveis de teste, sendo eles integração, sistema, aceitação, alfa e beta. Este tipo de abordagem permite verificar se o software atende aos requisitos, se as funcionalidades e os recursos funcionam corretamente, além de identificar falhas.
As técnicas de teste caixa preta comumente usadas são:
· Particionamento de equivalência.
· Análise de valor de limite.
· Teste de tabela de decisão.
· Teste de transição de estado.
Características comuns das técnicas baseadas em especificação (CTFL Syllabus, 2023):
· Modelos, formais ou informais, são utilizados para especificação de um problema a ser resolvido, o software ou seu componente.
· Os casos de testes podem ser derivados sistematicamente destes modelos.
Compreendendo caixa branca e caixa preta
Agora que já sabemos o que são testes estruturais e funcionais (caixa branca e caixa preta, respectivamente), compreenderemos como funcionam as técnicas utilizadas em cada abordagem.
Em testes caixa branca, temos as seguintes técnicas:
Teste de Instrução e Cobertura de Instrução:
· Cada instrução do código é executada pelo menos uma vez durante a execução dos testes. O objetivo é garantir que todas as instruções sejam testadas para verificar se estão funcionando conforme o esperado.
· A cobertura de instrução é uma métrica usada para medir o quão bem o teste de instrução está cobrindo o código. Ela é expressa como uma porcentagem das instruções executadas em relação ao total de instruções no código.
· A fórmula típica para calcular a cobertura de instrução é: Cobertura de Instrução (%) = (Instruções Executadas / Total de Instruções) * 100
Teste de Ramificação e Cobertura de Ramificação:
· O foco está nas decisões de controle de fluxo no código. Cada possível caminho ou ramificação dentro de estruturas condicionais, como declarações "if" e "else", deve ser percorrido durante os testes.
· A Cobertura de Ramificação é uma métrica usada para medir o quão bem o teste de ramificação está cobrindo o código em termos de decisões de controle de fluxo. Ela é expressa como uma porcentagem das bifurcações de código que foram executadas em relação ao total de bifurcações possíveis.
· A fórmula típica para calcular a cobertura de ramificação é: Cobertura de Ramificação (%) = (Bifurcações Executadas / Total de Bifurcações Possíveis) * 100
Em testes caixa preta, temos as seguintes técnicas:
Particionamento de Equivalência:
· Visa reduzir a redundância e a complexidade nos casos de teste.
· A ideia é dividir o espaço de entrada de um sistema em grupos ou partições de equivalência, em que cada grupo deve se comportar de maneira semelhante em relação ao sistema.
· Em vez de criar casos de teste individuais para cada valor de entrada, você cria casos de teste que representam cada partição. Isso permite que você teste com eficiência diferentes cenários semelhantes, economizando tempo e recursos.
Análise de Valor de Limite:
· É uma técnica que se concentra em testar os limites dos valores de entrada de um sistema.
· Ela identifica os valores de entrada que estão próximos aos limites de uma faixa aceitável e cria casos de teste para esses valores.
Teste de Tabelas de Decisão:
· É usado para testar a implementação dos requisitos do sistema que especificam como diferentes combinações de condições resultam em diferentes resultados.
· Ele organiza as condições em uma tabela que lista todas as combinações possíveis de valores das condições.
· Cada combinação na tabela é testada para garantir que o sistema se comporte corretamente em todas as situações possíveis.
Teste de Transição de Estado:
· É uma técnica usada, principalmente, em sistemas que têm estados diferentes e transitam entre esses estados durante a execução.
· Ele se concentra em testar as transições entre os estados do sistema, verificando se as transições ocorrem de acordo com as especificações e se o sistema se comporta corretamente em cada estado.
Testes de caminho base na prática
Um ponto forte fundamental que todas as técnicas de caixa branca compartilham é que toda a implementação do software é levada em conta durante o teste, o que facilita a detecção de defeitos mesmo quando a especificação do software é vaga, desatualizada ou incompleta (CTFL Syllabus, 2023).
Agora que já sabemos o que são e como funcionam as técnicas caixa branca, exercitaremos um pouco essas técnicas. Observe a Figura 1 a seguir.
Figura 1 | Função login
Fonte: elaborada pelo autor.
O código mostrado na Figura 1 é um exemplo de sistema de loginsimples. Realizaremos alguns testes caixa branca nesse código.
Teste de Instrução e Cobertura de Instruções
A cobertura de instruções envolve a execução de testes para garantir que cada instrução no código seja executada pelo menos uma vez. Para isso, precisaremos criar casos de teste que acionem todas as partes do código. No código da Figura 1, temos três pontos de entrada principais:
1. Quando o nome de usuário está correto.
2. Quando o nome de usuário está correto, mas a senha está incorreta.
3. Quando o nome de usuário está incorreto.
Criaremos os casos de teste que garantem a cobertura de todas as instruções:
Caso de teste 1: Nome de usuário e senha corretos
· nome_usuario = "usuario1"
· senha = "senha123"
· Resultado esperado: "Login bem-sucedido!"
Caso de teste 2: Nome de usuário correto, senha incorreta
· nome_usuario = "usuario1"
· senha = "senha_incorreta"
· Resultado esperado: "Senha incorreta."
Caso de teste 3: Nome de usuário incorreto
· nome_usuario = "usuario_inexistente"
· senha = "qualquer_senha"
· Resultado esperado: "Nome de usuário incorreto."
Executando esses três casos de teste, garantimos a cobertura de todas as instruções do código.
Para auxiliar na identificação dos caminhos que devem ser testados, pode-se utilizar o critério de McCabe, chamado complexidade ciclomática.
A complexidade ciclomática é uma técnica utilizada para criação de grafos, com a seguinte fórmula: CC = Número de arestas – Número de nós + 2, determinando, assim, a quantidade de casos de teste mínimo para testar os caminhos independentes do programa (Vilela, 2005).
Veja a Figura 2.
Figura 2 | Grafo de fluxo
Fonte: elaborada pelo autor.
Agora, contamos o número de nós e o número de arestas no grafo:
N = 6 (nós) A = 7 (arestas)
Podemos calcular a complexidade ciclomática (CC):
CC = 7 - 5 + 2 = 3.
Portanto, a complexidade ciclomática do código é 3. Isso significa que há três caminhos independentes através do código.
Teste de Ramificações e Cobertura de Ramificações:
Além da cobertura de instruções, podemos verificar a cobertura de ramificações, que garante que todas as possíveis decisões no código sejam testadas. Em nosso exemplo, as principais decisões estão relacionadas ao nome de usuário correto ou incorreto e à senha correta ou incorreta.
Para cobertura de ramificações, devemos adicionar mais casos de teste para cobrir as diferentes combinações:
Caso de teste 4: Nome de usuário correto, senha correta
· nome_usuario = "usuario1"
· senha = "senha123"
· Resultado esperado: "Login bem-sucedido!"
Caso de teste 5: Nome de usuário correto, senha incorreta
· nome_usuario = "usuario1"
· senha = "senha_incorreta"
· Resultado esperado: "Senha incorreta."
Caso de teste 6: Nome de usuário incorreto, senha correta
· nome_usuario = "usuario_inexistente"
· senha = "senha123"
· Resultado esperado: "Nome de usuário incorreto."
Caso de teste 7: Nome de usuário incorreto, senha incorreta
· nome_usuario = "usuario_inexistente"
· senha = "senha_incorreta"
· Resultado esperado: "Nome de usuário incorreto."
Executando esses casos de teste, garantimos que todas as ramificações no código sejam testadas. Isso nos possibilita uma cobertura completa das instruções e das diferentes decisões do código.
Critérios para testes de software Unidade 3
Olá, estudante! Os critérios para utilização de teste de software referem-se a padrões ou diretrizes que determinam quando e como os testes de software devem ser aplicados durante o ciclo de desenvolvimento de software. De acordo com Pressman e Maxim (2021), para realizar testes de forma efetiva, uma equipe de software deve aplicar técnicas de revisões formais nos requisitos. Ao fazer isso, muitos erros serão eliminados antes do início dos testes. Esses critérios servem para auxiliar a tomada de decisões a respeito de quando é apropriado realizar testes, quais tipos de testes devem ser executados e qual é o melhor momento, durante o processo de desenvolvimento, para que eles sejam aplicados.
Esses critérios podem variar dependendo da metodologia de desenvolvimento, das necessidades de cada projeto e das características específicas do software. Sommerville (2011) define que a maneira como as empresas lidam com seus processos de desenvolvimento pode variar conforme o grau de formalidade, o porte da organização e o tipo de aplicação. Com isso, fica claro que não existe um formato padrão para a melhoria dos processos, cabendo ao gerente de projetos adaptar os procedimentos conforme as necessidades do projeto.
Existem vários tipos de critérios para utilização de testes, cada um com foco em diferentes aspectos do software. Alguns dos critérios tratam de:
Riscos: testes podem ser priorizados em áreas de maior risco, nas quais falhas podem ter impacto significativo no sistema.
Complexidade: áreas mais complexas do software podem ser submetidas a testes mais rigorosos.
Alterações: testar após alterações significativas no código, como novas funcionalidades ou correções de bugs.
Integração: testes de integração são realizados quando diferentes partes do sistema se comunicam.
Cronograma: definir quando os testes devem ocorrer para que estejam alinhados com o cronograma geral do projeto.
Requisitos críticos: áreas do software que envolvem requisitos críticos para o funcionamento correto do sistema podem ser testadas em maior profundidade.
Feedback contínuo: testes frequentes podem ser realizados ao longo do ciclo de desenvolvimento, com frequentes reportes ao time para garantir a qualidade em todas as fases.
Histórico de falhas: testar áreas que historicamente apresentaram problemas ou falhas.
Uma vez que os critérios foram estabelecidos, entramos na fase das práticas de testes de software. As práticas de teste são técnicas que empregamos para executar os testes de forma eficaz. Elas englobam várias abordagens, como testes manuais e automatizados, testes de unidade, integração e aceitação e testes exploratórios. Ao aplicar as técnicas corretas, podemos identificar falhas e problemas antes que o software seja entregue ao usuário final. Isso é especialmente importante em cenários nos quais a complexidade do software exige que todas as funcionalidades do sistema interajam sem problemas, sejam fortemente ou fracamente acoplados.
Por fim, ter um bom planejamento para a realização dos testes afeta diretamente a qualidade do produto, pois uma estrutura bem-organizada para os processos de teste não só facilita o trabalho da equipe como também tem um impacto significativo em cada etapa do projeto.
Explorando critérios, práticas e organização de testes 
Estudante, já entendemos que existem vários tipos de critérios para a utilização de testes, e que diferentes situações requerem abordagens diferentes. Ao escolher os critérios certos, podemos focar os aspectos mais críticos do software, economizando tempo e recursos. Vamos considerar um sistema de gerenciamento de recursos humanos, que têm funcionalidades como folha de pagamento, banco de horas, ponto eletrônico e décimo terceiro salário. Nesse contexto, o critério de risco assume uma grande importância. Afinal, estamos lidando com o salário de pessoas, em um ambiente complexo e altamente regulado por leis trabalhistas.
As práticas para testes de software abrangem um conjunto de métodos e técnicas que desempenham um papel fundamental na garantia da qualidade e confiabilidade do software. 
Essas práticas são desenvolvidas para testar diversos aspectos do software, desde a funcionalidade até o desempenho e a segurança. 
De acordo com Pressman e Maxim (2021), algumas das práticas essenciais para testes de software são:
Testes de unidade: focalizam o esforço de verificação na menor parte do software, ou seja, na menor parte do código. Nessa prática, cada unidade individual de código é testada separadamente para verificar se funciona conforme o esperado. Isso ajuda a identificar problemas em nível mais baixo, no código, e garante que cada componente contribua para um funcionamento correto do software.
Testes de integração: à medida que as unidades individuais decódigo são desenvolvidas, os testes de integração entram em cena. Essa prática visa testar a interação entre diferentes componentes do software. A integração é crucial para identificar conflitos e incompatibilidades que podem surgir quando essas partes diferentes do software são combinadas.
Testes funcionais: os testes funcionais são executados para avaliar se o software atende aos requisitos solicitados pelos clientes. Isso envolve a execução de cenários de testes e casos de teste que simulam um passo a passo de como o usuário utilizará a funcionalidade, garantindo que todas elas estejam operando conforme o planejado.
Automação de testes: a automação de testes faz uso de ferramentas e scripts de códigos envolvendo linguagens de programação para descrevê-los e executá-los de forma automatizada.
Testes de desempenho: os testes de desempenho avaliam como o software se comporta sob diferentes cargas de trabalho.
Testes de segurança: os testes de segurança identificam vulnerabilidades que podem ser exploradas por ataques maliciosos.
Ao aplicar as práticas mencionadas, estamos conduzindo avaliações de acordo com os critérios estabelecidos, como riscos, complexidade, requisitos críticos e alterações. Contudo, para fazer tudo isso funcionar bem, é preciso planejamento.
O planejamento é um elemento essencial para a execução eficaz das práticas de teste. Um planejamento sólido engloba a criação de cenários de testes bem documentados até a homologação desses testes em produção. Ao estruturar esses processos, definir responsabilidades e manter ambientes de teste consistentes, a organização garante que os testes sejam realizados de maneira eficiente, que erros sejam minimizados e que todos os aspectos cruciais sejam avaliados.
Aplicando estratégias de testes
Estudante, vamos partir para a aplicação. Segundo Pressman e Maxim (2021), o mais importante é que o software seja confiável, e com base nessa afirmativa escolhemos os critérios de testes mais apropriados para cada projeto – o nível de confiança é necessário para o software ser utilizado, e os testes dão esse nível de confiança devido ao fato de o projeto adotar a prevenção de erros e corrigi-los antes que o software chegue ao usuário final. Por exemplo, se testarmos uma funcionalidade de carrinho de compras de um comércio eletrônico, podemos escolher, como prática, o Teste Funcional, e o critério Alterações seria selecionado devido à funcionalidade ser sujeita à mudança, como adição e retirada de produto do carrinho.
Ao aplicar as práticas de teste, realizamos os testes de acordo com os critérios estabelecidos. Se optamos por testes exploratórios, navegamos pelo software como um usuário real, identificando problemas não previstos.
Vamos considerar, por exemplo, um sistema de gerenciamento de pedidos de restaurante para mostrar como cada tipo de teste pode ser aplicado em um único cenário. Se estamos usando testes de unidades, verificamos no código-fonte por meio da lógica implementada via código de adicionar pedidos em uma estrutura de dados, que pode ser uma lista. Se estamos usando testes de integração, verificamos se o código-fonte está adicionando o pedido em um banco de dados conforme o esperado, uma vez que o código-fonte tem que se comunicar com o banco de dados.
As práticas de testes funcionais podem ser feitas em testes que simulam um usuário fazendo um pedido pela própria aplicação. Já para realizar a automação de interface de usuário, podemos utilizar o Cypress como framework de teste que usa a linguagem JavaScript para automatizar os testes, com a finalidade de simular o usuário interagindo com a aplicação de forma bem rápida.
Para teste de segurança podemos utilizar OWASP ZAP, uma ferramenta que verifica vulnerabilidades de segurança no software. Para testes de performance podemos utilizar a ferramenta JMeter, na qual simulamos uma carga de usuários fazendo vários pedidos ao mesmo tempo na aplicação, e podemos observar como o software lida com esse tipo de estresse.
Dessa forma, o conjunto completo de testes cobriria todas as principais áreas do desenvolvimento de software, contribuindo para um sistema confiável.
Concluímos que o planejamento dos testes desempenha um papel crucial na eficácia dos testes de software, sem afetar a qualidade e confiabilidade do produto final. Quando falamos em organização de testes de software, não estamos falando em apenas manter documentos arrumados ou ambientes de trabalho organizados, mas também de uma abordagem estruturada e coordenada que permeia todo o processo de desenvolvimento.
Imagine construir uma casa sem um plano sólido: os resultados seriam desastrosos. Da mesma forma, a organização de testes de software é como o plano que guia todo o processo de construção de um produto de alta qualidade. O plano garante que todos os passos sejam seguidos de maneira ordenada, evitando erros e retrabalho.
Em resumo, os critérios de teste, as práticas de teste e a organização de testes são três pilares interdependentes que sustentam a garantia de qualidade do software. Compreender e aplicar esses elementos de maneira adequada nos permite construir um software confiável, eficaz e que atenda às expectativas dos usuários.
Planejamento, estimativa e execução de projetos de software
Caro estudante, o planejamento de teste é uma tarefa contínua e executada durante todo ciclo de vida do projeto; um planejamento de excelência favorece o projeto, garantindo a sua qualidade. Pressman e Maxim (2021) enfatizam a importância de manter o plano do projeto como um documento útil e atualizado para a equipe. Segundo os autores, elementos como cronograma, estimativa de custos e análise de riscos precisam ser revisados e atualizados ao longo do desenvolvimento do projeto, para assegurar sua eficácia e utilidade contínua.
As atividades de planejamento de testes podem ser documentadas em um plano de teste, e incluir:
Objetivos: o que se pretende alcançar.
Requisitos: as funcionalidades e restrições do sistema.
Escopo: as limites do projeto.
Cronograma: quando cada atividade será realizada.
Orçamento: quanto vai custar.
Recursos: quais pessoas, ferramentas e materiais são necessários.
Além dessas atividades, é necessário criar estratégia de teste fornecendo uma descrição geral do processo de teste. O CTFL Syllabus (BSTQB, 2023), em sua versão 3.1, destaca os seguintes tipos comuns de estratégias de teste:
Analítica: é baseada em análises de dois fatores como requisitos ou riscos, para guiar o processo em questão. Um exemplo ilustrativo dessa metodologia é o teste orientado por riscos. Nesse cenário, a concepção e a priorização dos testes são determinadas com base na avaliação do nível de risco associado a cada aspecto do projeto.
Baseada em modelo: o projeto dos testes é elaborado a partir de um modelo específico que representa alguma funcionalidade crucial do produto. Isso pode envolver uma função particular, um procedimento de negócios, uma estrutura interna ou mesmo um atributo não funcional, por exemplo, confiabilidade. Modelos frequentemente utilizados nesse contexto são os modelos de estado e os modelos de crescimento de confiabilidade.
Metódica: baseia-se na aplicação sistemática de um conjunto já estabelecido de testes ou critérios de teste. Esses podem incluir uma classificação de falhas frequentes ou prováveis, uma lista de atributos de qualidade relevantes, ou padrões estabelecidos para a aparência e o funcionamento de aplicativos móveis ou sites da organização.
Compatível com processo: concentra-se na análise, desenvolvimento e execução de testes guiados por normas e padrões externos. Estes podem ser estabelecidos por padrões industriais específicos, documentação processual, uma base de teste identificada, ou qualquer outra diretriz ou norma estabelecida pela organização.
Dirigida (ou consultivo): predominantemente guiada por conselhos, direcionamentos ou instruções provenientes de stakeholders, peritos no domínio empresarial ou especialistas em tecnologia. Esses consultores podem não fazer parte da equipe de testeou mesmo da organização como um todo.
Contra regressão: é impulsionada pela intenção de prevenir a degradação de funcionalidades já existentes. A estratégia envolve o reaproveitamento de recursos de teste já disponíveis, como casos de teste, além da automatização ampla de testes de regressão.
Reativa: é adaptativa, respondendo ao sistema sobre um conjunto de testes e aos acontecimentos que surgem durante a execução do teste. Os testes são concebidos e postos em prática, podendo ser executados imediatamente com base nas informações obtidas a partir dos resultados de testes anteriores de outros testes. O teste exploratório é uma técnica frequentemente utilizada em estratégias do tipo reativa.
O planejamento pode ser feito com ferramentas como Gantt Charts, JIRA ou Trello para acompanhar o progresso do projeto.
Estimativa de testes 
Caro estudante, uma vez que o planejamento do teste foi estabelecido, é necessário criar as estimativas de teste. Existem várias técnicas que podem ser usadas para determinar o esforço necessário e adequado para os testes. Nesta seção vamos considerar o tempo, os recursos e o custo associados ao projeto. Estimar de forma precisa ainda é um desafio, mas é crucial para definir expectativas realistas.
De acordo com Sommerville (2011), existem dois tipos de técnicas que podem ser usadas para estimar:
Técnicas baseadas em experiências: as estimativas de requisitos de futuros esforços se baseiam na experiência que os especialistas frequentemente têm em projetos anteriores para fazer uma avaliação dos esforços que serão necessários para cumprir requisitos futuros. Esse método depende do conhecimento e domínio dos especialistas a respeito da área de aplicação do projeto.
Modelagem algorítmica de custos: uma abordagem usada em muitas situações para estimar custos e o esforço necessário em um projeto. Esse método se baseia em diversos fatores, incluindo atributos do produto como tamanho, e características do processo, como a experiência da equipe envolvida no projeto.
Em ambas as situações, é preciso fazer uma estimativa do esforço envolvido e das características do projeto e do produto. Sommerville (2011) destaca que na fase de iniciação de um projeto, as estimativas tendem a ter uma grande margem de erro. Isso ocorre porque a estimativa é realizada bem no início do projeto, sendo menor a precisão. Por outro lado, estimativas feitas tardiamente, embora possam ser mais precisas, acabam sendo menos úteis para o planejamento e execução do projeto.
Caso a estimativa inicial do esforço requerido seja de x meses, o intervalo real pode variar de 0,25x a até 4x do esforço efetivamente medido na entrega do sistema. Conforme o projeto progride na fase de planejamento e desenvolvimento, essas estimativas tendem a se tornar cada vez mais acuradas. Essa variação na incerteza e precisão das estimativas é ilustrada na Figura 1, que aborda a relação entre incerteza e estimativa ao longo do projeto.
Figura 1 | Incerteza de estimativas
Fonte: Sommerville (2011, p. 442).
Estimar um projeto vai muito além de simples palpites de tempo e recursos necessários; trata-se de um cálculo fundamentado que muitas vezes se baseia em dados históricos e expertise no domínio. Más estimativas podem levar a atrasos significativos e estouro do orçamento previsto.
Por exemplo, um projeto de grande complexidade envolvendo diversos stakeholders necessita de relatórios mais detalhados e rigorosos em comparação a uma simples atualização de software. No contexto do desenvolvimento ágil, métricas como relatórios de progresso de testes, resumos de defeitos e gráficos de burndown são incorporados em quadros de tarefas e discutidos em reuniões stand-up diárias.
Gráficos de burndown, frequentemente usados em metodologias ágeis como Scrum e Kanban, são ferramentas valiosas para monitorar o avanço do projeto ao longo de períodos específicos, geralmente sprints ou ciclos de trabalho. O objetivo central desses gráficos é ilustrar o volume de trabalho pendente em relação ao tempo restante, ajudando a equipe a avaliar se está no caminho certo para cumprir os prazos estabelecidos.
Estimar não é adivinhar quanto tempo e recursos o projeto consumirá, mas destacar a importância de abordagens bem-fundamentadas e o uso de ferramentas adequadas para monitorar o progresso.
Execução e monitoramento de testes
Vamos discutir a execução e o monitoramento de testes, que não se trata apenas de seguir o planejamento, mas também de ter flexibilidade e adaptabilidade para enfrentar surpresas, que inevitavelmente acontecerão.
No desenvolvimento de software, raramente as coisas ocorrem exatamente conforme planejado, pois sempre no meio do desenvolvimento ocorre riscos emergem, bugs aparecem e atrasos podem ser causados por uma série de fatores. Isso exige que a equipe de qualidade seja adaptável.
O CTFL Syllabus (2023), em sua versão 3.1, destaca que o gerenciamento de testes emprega dados do monitoramento para oferecer, sob a forma de diretrizes gerenciais, conselhos e intervenções requeridas para tornar os testes mais produtivos e efetivos. Veja exemplos dessas diretrizes gerenciais:
· Se um risco for mapeado e se transforma em um contratempo real, deve-se reorganizar a ordem dos testes.
· Reexaminar se um elemento de teste cumpre os requisitos de entrada ou saída.
· Reajustar o calendário de testes para acomodar um atraso no fornecimento do ambiente de testes.
· Mobilizar mais recursos conforme necessário.
Além disso, o uso de painéis em tempo real e indicadores-chave de desempenho (KPIs) é inestimável nesta fase. Eles fornecem uma visão instantânea de como a suíte de testes está sendo desempenhada em relação aos critérios de saída, como cobertura de testes e conformidade com requisitos.
Para exemplificar, imaginemos um projeto de um aplicativo de delivery de comida. A equipe de qualidade utiliza painéis de controle em tempo real para monitorar KPIs. Se, na metade da sprint, for detectado que a cobertura de teste para o sistema de pagamento do aplicativo está abaixo do esperado, várias ações corretivas são imediatamente implementadas. Isso pode incluir uma nova priorização de testes e a alocação de mais recursos para essa área específica.
As métricas também dão uma visão quantificada do projeto, abordando desde a relação entre o que foi planejado e o orçado até métricas mais específicas, como a densidade de defeitos e taxa de falhas. Métricas de custo, incluindo o ROI (retorno sobre investimento), são fundamentais para justificar os esforços e recursos alocados na atividade de teste.
As métricas frequentemente usadas em testes compreendem:
· Métricas relacionadas ao avanço do projeto, como conclusão de atividades, alocação de recursos e intensidade do teste.
· Métricas associadas ao progresso do teste, como evolução na implementação do caso de teste, avanço na configuração do ambiente de teste, quantidade de casos de teste realizados/não realizados, aprovados/reprovados e duração dos testes.
· Métricas para avaliar a qualidade do produto, por exemplo, disponibilidade, latência, tempo médio de falha.
· Métricas ligadas a defeitos, como número e grau de prioridade de defeitos identificados/resolvidos, taxa de incidência de defeitos e percentual de detecção de falhas.
· Métricas focadas em risco, como grau de risco remanescente.
· Métricas de abrangência, como cobertura de exigências e cobertura do código-fonte.
· Métricas financeiras, como custo do processo de teste e gastos globais com qualidade.
Em resumo, a execução e o monitoramento de testes são elementos centrais para o sucesso de qualquer projeto de software. Um planejamento rigoroso, técnicas de estimativa apropriadas e um monitoramento contínuo são a base de qualquer projeto bem-sucedido.
Princípios que norteiam a prática
Estudante, a prática da engenharia de software envolve diversos princípios, conceitos, métodos e ferramentas que devem ser considerados durante o planejamento de um software. De acordo Pressman e Maxim (2021), alguns desses princípios são:
Princípios queorientam o processo: 1. Seja ágil em todas as abordagens, tanto no modelo prescritivo como no ágil. 2. Mantenha o foco na qualidade do produto em cada etapa do desenvolvimento. 3. Esteja aberto para adaptações conforme as restrições do projeto. 4. Priorize a formação de uma equipe eficiente e auto-organizada. 5. Estabeleça mecanismos claros para comunicação e coordenação. 6. Implemente práticas para o gerenciamento de mudanças. 7. Tenha planos de contingência para avaliar e mitigar riscos. 8. Produza artefatos que agreguem valor a outros processos ou tarefas. Esses princípios servem como um quadro de referência aplicável a qualquer metodologia de desenvolvimento de software.
Princípios que orientam a prática: 1. Divida e conquiste. 2. Compreenda o uso da abstração. 3. Esforce-se pela consistência. 4. Concentre-se na transferência de informações. 5. Construa software que apresente modularidade efetiva. 6. Verifique os padrões. 7. Quando possível, represente o problema e sua solução sob perspectivas diferentes. 8. Lembre-se de que alguém fará a manutenção do software. Esses princípios são essenciais independentemente das técnicas ou ferramentas usadas, pois não só guiam o desenvolvimento, mas também facilitam a manutenção futura do software.
Princípios da comunicação: 1. Ouça. 2. Prepare-se antes de se comunicar. 3. Saiba que alguém deve facilitar a atividade. 4. Saiba que comunicar-se pessoalmente é melhor. 5. Anote e documente as decisões. 6. Esforce-se para conseguir colaboração. 7. Mantenha o foco e crie módulos para a discussão. 8. Faltando clareza, desenhe. 9. (a) Uma vez de acordo, siga em frente; (b) se não chegar a um acordo, siga em frente; (c) se uma característica ou função não estiver clara e não puder ser elucidada no momento, siga em frente. 10. Negociação não é uma competição nem um jogo. Funciona melhor quando as duas partes saem ganhando.
Princípios do planejamento: 1. Entenda o escopo do projeto. 2. Inclua os envolvidos na atividade de planejamento. 3. Reconheça que o planejamento é iterativo. 4. Faça estimativas baseadas no que conhece. 5. Considere os riscos ao definir o plano. 6. Seja realista. 7. Ajuste particularidades ao definir o plano. 8. Defina como pretende garantir a qualidade. 9. Descreva como acomodar as alterações. 10. Verifique o plano com frequência e faça os ajustes necessários
Princípios da modelagem: 1. Saiba que o objetivo principal da equipe de software é construir software, não criar modelos. 2. Seja objetivo; não crie mais modelos do que precisa. 3. Esforce-se ao máximo para produzir o modelo mais simples possível. 4. Construa modelos que facilitem alterações. 5. Estabeleça um propósito claro para cada modelo. 6. Adapte os modelos que desenvolveu ao sistema à disposição. 7. Crie modelos úteis, mas esqueça a construção de modelos perfeitos. 8. Não se torne dogmático quanto à sintaxe do modelo. Se ela consegue transmitir o conteúdo, a representação é secundária. 9. Se os instintos dizem que um modelo não está correto, mesmo parecendo correto no papel, provavelmente há motivos para se preocupar. 10. Obtenha feedback o quanto antes.
Princípios da construção: 1. Todos os testes devem estar alinhados com os requisitos do cliente. 2. Os testes devem ser planejados muito antes de serem iniciados. 3. O princípio de Pareto se aplica a testes de software. 4. Os testes devem começar “no particular” e progredir para o teste “no geral”. 5. Testes exaustivos são impossíveis. 6. Aplique a cada módulo do sistema um teste equivalente à sua densidade de defeitos esperada. 7. Técnicas de testes estáticos podem gerar resultados importantes. 8. Rastreie defeitos e procure padrões em falhas descobertas pelos testes. 9. Inclua casos de teste que demonstrem que o software está se comportando corretamente.
Princípios da disponibilização: 1. As expectativas do cliente para o software devem ser gerenciadas. 2. Um pacote de entrega completo deve ser montado e testado. 3. É preciso estabelecer uma estrutura de suporte antes da entrega do software. 4. Material instrucional adequado deve ser fornecido aos usuários. 5. Software com bugs deve ser primeiramente corrigido e, depois, entregue.
Por fim, esses princípios auxiliam na aplicação de um processo de software significativo e na execução de métodos eficazes de engenharia de software.
Processos de testes 
Estudante, uma vez entendido os princípios e práticas da engenharia de software, é crucial aprofundar o conhecimento dos processos de desenvolvimento de software. Ao longo dos últimos anos, o desenvolvimento de software passou por transformações significativas, e diversas metodologias e práticas foram criadas para tornar o processo mais eficiente e eficaz. De acordo Pressman e Maxim (2021), alguns desses processos são:
DevOps: busca integrar as equipes de desenvolvimento (Dev) e operações (Ops) para otimizar tanto o processo de desenvolvimento quanto a qualidade do software. Essa prática utiliza ferramentas de automação para implementar integração contínua e entrega contínua (CI/CD), permitindo que alterações de código sejam testadas, aprovadas e implantadas de forma rápida e segura. O DevOps também estimula uma cultura de colaboração e comunicação aberta entre as equipes, tornando o processo de desenvolvimento mais transparente e eficaz.
TDD (desenvolvimento orientado a testes): nesse processo, a elaboração de testes é feita antes da escrita do código de produção. A Figura 1 ilustra a etapa em que, antes de criar o primeiro trecho de código, a equipe de qualidade elabora um teste para avaliá-lo, tentando intencionalmente fazer com que o código falhe. Quando o código escrito satisfizer ao teste é realizado um novo teste para o próximo trecho de código a ser desenvolvido. Esse processo se repete até que todos os testes executados não apresentem erros. Caso algum teste apresente erro, o código deve ser corrigido. Esse fluxo iterativo continua até que não haja mais teste a ser criado, significando que o componente satisfaz a todos os requisitos definidos para ele.
Figura 1 | O fluxo de desenvolvimento controlado por teste 
BDD (desenvolvimento orientado a comportamento): é uma extensão do TDD, ou seja, primeiro se cria o teste e, em seguida, o código utiliza descrições de comportamento em linguagem natural. Essa abordagem ajuda a garantir que todos os membros da equipe, incluindo não desenvolvedores, possam entender e participar no desenvolvimento.
DDD (design orientado a domínio): ​​é um conjunto de regras e práticas que ajudam a fazer com que a parte técnica de um projeto de software se alinhe com as necessidades do negócio. Isso significa que o software pode crescer e se adaptar à medida que todos compreendem melhor o negócio. Ele também sugere que os desenvolvedores não apenas participem de reuniões com especialistas, mas que realmente entendam o negócio e todos os seus detalhes, olhando para ele de diferentes perspectivas. Isso ajuda a criar um software mais eficaz e alinhado com as metas do negócio. Todas essas práticas têm um objetivo: fazer o software melhor e tornar o processo de desenvolvimento mais eficiente. Elas não são coisas que você precisa escolher uma ou outra; muitas equipes usam várias delas ao mesmo tempo. A decisão de qual usar depende do que o projeto precisa, dos objetivos do negócio e de quem está na equipe de desenvolvimento. O mais importante é que todas essas abordagens oferecem ferramentas e técnicas que podem ajudar as equipes a fazerem software de alta qualidade de maneira mais fácil.
Arquitetura e design de software
Estudante, vamos discutir a respeito de arquitetura e design de software. Antigamente, a arquitetura era implícita e informal, mas desde a primeira divisão de programas em módulos ela vem evoluindo. De acordo com Pressman e Maxim (2021), arquitetura de software é importante para o desenvolvimento de sistemas, porque proporciona a comunicação entre todos os envolvidos, desde decisões que impactam o projeto até o fornecimento de uma visão compreensível da estrutura do sistema e da interaçãoentre seus componentes.
De acordo com Sommerville (2011), existem exemplos de padrões que são muito usados e que capturam os bons princípios de projeto de arquitetura. Eles são:
Arquitetura em camadas: organiza o software hierarquicamente, da interface do usuário ao sistema operacional. Essa estrutura facilita o entendimento e a manutenção. A escolha desse estilo arquitetural depende dos requisitos e limitações do projeto. A Figura 2 mostra uma arquitetura de quatro camadas. A camada mais básica foca o suporte ao sistema, incluindo bancos de dados e sistemas operacionais. A camada de aplicação abrange funcionalidades e utilitários da aplicação. A terceira camada lida com a interface do usuário, autenticação e autorização. A camada superior oferece recursos de interface com o usuário.
Figura 2 | Arquitetura em camadas
Arquitetura de repositório: centraliza dados e funções em um único armazenamento, facilitando a manutenção e o controle de versões. Isso se torna vantajoso para aplicações baseadas em dados, mas pode causar gargalos e tornar a distribuição desafiadora. A Figura 3 ilustra um exemplo no qual um repositório é útil, destacando um IDE (ambiente de desenvolvimento integrado) com várias ferramentas baseadas em modelos. Nesse contexto, o repositório atua como um sistema de controle de versão, permitindo rastrear e reverter alterações de software.
Figura 3 | Arquitetura de repositório
Fonte: Sommerville (2011, p. 112).
Arquitetura cliente-servidor: distribui dados e processamento entre servidores e clientes conectados por rede. É escalável e eficiente na alocação de recursos, mas traz desafios de segurança e carga. É comum em sistemas web e bancos de dados. Vantagens incluem modularidade e facilidade para expansão. A Figura 4 ilustra um exemplo de sistema cliente-servidor multiusuário na internet para oferecer uma biblioteca de filmes e fotos. Vários servidores gerência desenvolveram diferentes tipos de mídia: o servidor de vídeo cuida da compressão e descompressão de vídeos em baixa resolução, enquanto outro servidor mantém as fotos em alta resolução.
Figura 4 | Arquitetura cliente-servidor
Fonte: Sommerville (2011, p. 114).
Arquitetura de duto e filtro: organiza para processar dados em tempo real, em que cada etapa transforma entradas em saídas. Os dados fluem sequencialmente ou paralelamente por meio dessas transformações, até serem convertidos em saídas. Cada transformação é uma etapa de processamento independente que pode operar em lotes ou de forma contínua. A Figura 5 ilustra um exemplo de uma arquitetura de sistema em lote, usada em uma organização que emite faturas para os seus clientes. Semanalmente os pagamentos efetuados são conciliados com as faturas. Recibos são emitidos para os pagamentos confirmados, e lembretes são enviados para faturas não pagas no prazo.
Figura 5 | Arquitetura duto e filtro
Fonte: Sommerville (2011, p. 115).
Após a fase de arquitetura vem a etapa design de software, que envolve a elaboração de especificações detalhadas para cada componente ou módulo identificado durante a arquitetura. Essa fase é dividida em design de alto e baixo nível, em que o primeiro estabelece a arquitetura do software e o segundo detalha o comportamento específico de cada módulo. O design é fundamental não só para orientar a construção do sistema, mas também para avaliá-lo em relação aos seus objetivos, como confiabilidade e eficiência. Portanto, um design bem elaborado é importante para que o software final atenda às necessidades do cliente e mantenha uma alta qualidade de código, abrangendo aspectos como legibilidade e manutenibilidade. 
Contudo, tanto na arquitetura como no design de software ambas são fundamentais para o sucesso de qualquer projeto de desenvolvimento de software, e frequentemente se sobrepõem ou são iterativos, dependendo da metodologia de desenvolvimento adotada.
Critérios para testes de software
Estudante, desde que o software se integrou em nossas vidas, surgiu a necessidade de maior qualidade. O CTFL Syllabus (BSTQB, 2023), em sua versão 3.1, traz que muitas vezes os termos "Garantia de Qualidade" (ou simplesmente QA) e "testes" são usados como se indicassem o mesmo, mas são diferentes, embora relacionados. Ambos fazem parte de um conceito maior: o gerenciamento de qualidade. Esse gerenciamento inclui todas as ações que ajudam e controlam uma organização para manter a qualidade. Dentro disso, tanto a garantia de qualidade quanto o controle de qualidade são partes importantes. 
De acordo com Pressman e Maxim (2021), o gerenciamento de qualidade abrange uma gestão de qualidade efetiva aplicada de modo a criar um produto útil que forneça valor significativo para aqueles que o produzem e para aqueles que o utilizam. A garantia da qualidade de software envolve diversas atividades que visam assegurar a excelência do produto final, como:
Revisão de código: ou code review, é essencial para a qualidade do software. Além da detecção de defeitos, também visa a melhorias e conformidade. Para melhores práticas, devem ser seguidas diretrizes claras e uma abordagem colaborativa. Estabelecer critérios de aprovação e manter revisões frequentes também são passos importantes. A documentação dos resultados serve como um histórico valioso para futuras análises e melhorias contínuas.
Inspeção de documentos: é uma prática rigorosa que foca principalmente a detecção de defeitos e a avaliação da qualidade do produto de trabalho. A documentação de cada inspeção deve ser feita por meio de checklists para guiar os revisores, que são pares ou especialistas usados para conduzir a inspeção. A inspeção é comandada por um facilitador treinado, não pelo autor. Documentos resultantes incluem registros de defeitos e ações necessárias. Métricas coletadas durante o processo auxiliam na melhoria contínua do desenvolvimento de software
Gestão de configuração e de mudanças: são práticas como controle de versões, no qual serve para garantir a integridade e qualidade de um software ou sistema ao longo de seu ciclo de vida. Este conjunto de práticas controla e documenta todas as alterações em código-fonte, documentação e outros artefatos. Em equipes ágeis, a mudança não é apenas inevitável, mas também bem-vinda. Seja uma alteração no software em desenvolvimento, na composição da equipe ou em tecnologias emergentes, a agilidade está em saber adaptar-se eficientemente. São usadas ferramentas como Git para rastrear essas modificações, permitindo a colaboração eficiente entre equipes e a reversão de mudanças quando necessário. Todas essas estratégias se integram para formar um sistema robusto de garantia da qualidade.
No gerenciamento da qualidade de software, a excelência é alcançada por meio de várias atividades importantes. Isso inclui desde a revisão de código e inspeção de documentos, que focam a detecção de defeitos e melhorias, até a gestão de configuração e mudanças, essenciais para manter a integridade do projeto ao longo do tempo. As equipes ágeis trazem uma camada extra de adaptabilidade, tornando o software mais resistente a diversas mudanças. Todas essas estratégias trabalham juntas para criar um sistema sólido de garantia de qualidade, assegurando que o software entregue seja não apenas útil, mas também valioso para todos que o utilizam.
Normas e padrões de qualidade de software
Estudante, como já entendemos a garantia de qualidade, vamos estudar as normas e padrões de qualidade de software que desempenham um papel crucial na garantia de eficácia, segurança e confiabilidade dos produtos de software. De acordo com Pressman e Maxim (2021), o padrão ISO foi desenvolvido com objetivo de identificar os atributos fundamentais de qualidade para software. Dentre as normas internacionalmente reconhecidas, podemos destacar a ISO/IEC 12207, ISO/IEC 15504 e ISO/IEC 9126, cada uma delas com o foco em aspectos específicos da qualidade do software.
ISO/IEC 12207: fornece um guia para todo o ciclo de vida de um software, do começo ao fim. Ela ajuda empresas a ficarem mais organizadas, focarem o clientee gerenciarem melhor seus recursos. A norma divide os processos em três tipos: Fundamentais, de Apoio e Organizacionais. Esses processos abrangem tudo, desde o desenvolvimento até a manutenção do software, tornando todo o trabalho mais eficiente e alinhado. É uma ferramenta útil para evitar falhas e garantir o sucesso de projetos de software.
ISO/IEC 15504: 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. Também conhecida como SPICE (Software Process Improvement and Capability Determination), essa norma foca a avaliação do processo de desenvolvimento de software. O objetivo é medir a maturidade dos processos de uma organização e identificar áreas para melhoria. Ao seguir esta norma, as organizações podem não apenas melhorar seus processos internos, mas também garantir que seus produtos finais atendam aos padrões de qualidade desejados.
ISO/IEC 9126: esta norma foi criada para definir o que faz um software ter qualidade. Ele se divide em seis atributos principais: funcionalidade, que avalia se o software faz o que promete, considerando aspectos como segurança e adequação; confiabilidade, focada no tempo que o software fica disponível sem falhas; usabilidade, que olha para o quão fácil é usar o software; eficiência, que se preocupa com o uso inteligente de recursos do sistema; facilidade de manutenção, que mede o quanto é simples fazer correções ou atualizações; e, por fim, portabilidade, que é a capacidade do software de funcionar em diferentes ambientes ou sistemas.
Em resumo, a adesão a essas normas é crucial para qualquer organização focada em alcançar a excelência em desenvolvimento de software. Elas oferecem um roteiro estruturado para melhorar a qualidade dos produtos e otimizar processos internos. Isso não apenas resulta em produtos mais confiáveis, mas também potencializa a eficiência operacional da empresa. Além disso, empresas que seguem essas diretrizes ganham uma vantagem competitiva, pois demonstram um compromisso sério com a qualidade e a satisfação do cliente, fatores cada vez mais valorizados no mercado atual.
Lei Geral de Proteção de Dados (LGPD)
Estudante, atualmente a sociedade está cada vez mais digital, o que obriga as empresas a se adaptarem às novas regulamentações. Com isso, a Lei Geral de Proteção de Dados (LGPD), que foi sancionada em agosto de 2018 e entrou em vigor em setembro de 2020 no Brasil, trouxe mudanças significativas no cenário de regulação de dados no país. A LGPD apresenta impactos significativos em várias áreas, inclusive na de desenvolvimento e gerenciamento de software, pois ela estabelece regras claras para coleta, armazenamento, tratamento e compartilhamento de dados pessoais, impondo penalidades severas para as organizações que não cumprirem a legislação (Brasil, 2018).
Para as empresas de desenvolvimento de software, essa lei muda bastante a forma como elas devem cuidar das informações das pessoas. Isso vale desde o momento em que o programa está sendo feito até quando ele já está funcionando. Além de se preocupar em fazer um programa bom e sem falhas, as empresas também têm que seguir as regras da LGPD.
Com a LGPD, a primeira coisa que muda ao fazer um programa, é que você tem que pensar em proteger os dados das pessoas desde o começo. Não dá para deixar para pensar nisso só no final. Em outras palavras, o programa tem que ser feito de modo que já venha com a segurança dos dados como algo básico, e isso tem que ser bem testado para ter certeza de que está funcionando. Por exemplo, medidas como criptografia forte para o armazenamento de dados e protocolos seguros para a transferência de informações entre sistemas tornam-se essenciais.
Além disso, é indispensável que as empresas estabeleçam um sistema robusto de governança de dados, integrando-o às práticas de gerenciamento de qualidade de software. Isso implica a criação de métricas, indicadores e auditorias específicas para monitorar a conformidade com a LGPD, bem como a implantação de ferramentas e processos para assegurar o tratamento adequado dos dados pessoais.
A qualidade do software também está relacionada à experiência do usuário, e a LGPD acrescenta uma nova camada a essa equação. Isso significa que o programa precisa ser claro a respeito de como usa os dados e permitir que as pessoas vejam, corrijam ou apaguem suas informações. Isso é uma parte importante para saber se o programa é bom ou não.
Em caso de incidentes de segurança que resultem em vazamento de dados, a empresa deve ter processos claros e eficazes para lidar com a situação, minimizando os danos aos titulares dos dados e também às suas operações. A qualidade do gerenciamento dessas situações de crise pode inclusive impactar significativamente a reputação da empresa e sua posição no mercado.
Portanto, a LGPD adiciona uma complexidade adicional ao gerenciamento e à qualidade de software. Ignorar essa legislação não é uma opção, dadas as pesadas multas e possíveis danos à reputação que o não cumprimento pode acarretar. Mais do que nunca, qualidade e conformidade legal devem andar de mãos dadas no cenário atual de desenvolvimento de software.
image4.png
image5.png
image6.png
image7.png
image8.png
image9.png
image10.png
image11.png
image12.png
image13.png
image14.png
image15.png
image16.png
image17.png
image18.png
image19.png
image20.png
image21.png
image22.png
image23.png
image24.png
image25.png
image1.png
image2.png
image3.pngcriados a estimativa quantitativa e o cronograma de atividades, mas, provavelmente, no início do planejamento, não temos todas as informações sólidas, até porque realizar uma análise detalhada dos requisitos para ter as informações fidedignas pode demorar semanas ou até mesmo meses. Mas, ainda assim, se faz necessário um escopo estabelecido e delimitado.
É neste escopo que serão identificadas as necessidades dos usuários e das partes interessadas, capturando os requisitos e documentando-os de forma adequada para garantir uma base sólida para o desenvolvimento. Com isso, a gerência e a equipe técnica conseguem mitigar os riscos, definir alguns prazos e orçamentos, escolhendo a melhor estratégia baseada na estimativa quantitativa.
Processo
O produto se inicia pela junção de vários processos que serão os responsáveis por guiar o trabalho da equipe de desenvolvimento. Pressman e Maxim (2021) destacam a importância de adotar processos eficientes, de acordo com o projeto de software a ser desenvolvido, tais como metodologias ágeis, processos em cascata, desenvolvimento interativo, entre outros. O objetivo é ter um processo bem definido e que permita uma entrega eficaz do software.
Projeto
Para evitar a falha de um projeto, primeiramente, devemos entender os fatores-chave do projeto.
Para o sucesso, Pressman e Maxim (2021) incluem: requisitos claros e fáceis de compreender; participação ativa do usuário em toda a construção do produto; gerente com habilidades de liderança; construção do plano do produto e cronograma com a participação dos envolvidos; equipe habilidosa e engajada com espírito colaborativo; orçamento e cronograma realistas e sempre monitorados; necessidade do cliente entendida e satisfeita e, por último, produto com qualidade e escopo atingido.
Aluno, para concluir o nosso entendimento a respeito de gerenciamento de software, este fornece etapas estruturadas, processos bem definidos e necessários para garantir uma entrega eficiente do sistema.
Qualidade de software
A qualidade de um produto de software se tornou fundamental para a competitividade entre empresas de tecnologia. Nesse cenário altamente disputado, as empresas que se destacam são aquelas que compreendem a relevância da qualidade e se empenham continuamente para empregar qualidade em seus produtos (softwares) e serviços.
Além do contexto competitivo, temos sistemas complexos, nos quais a qualidade pode ser um fator determinante para o sucesso de um software. Em alguns casos, os softwares lidam com situações em que milhões de reais podem estar em jogo e, até mesmo, vidas humanas.
Embora a palavra “qualidade” pareça intuitiva em seu significado, à medida que nos aprofundamos no assunto, descobrimos que a sua interpretação vai além do que inicialmente imaginávamos.
Em produtos de software, a avaliação da qualidade é uma tarefa abstrata e bem complexa. Ao analisarmos a qualidade de software, deparamo-nos com uma série de aspectos intangíveis que não podem ser facilmente medidos ou quantificados de maneira objetiva, tais como: a eficiência do sistema através de suas funcionalidades; a confiabilidade do software em realizar tarefas sem falhas; a segurança em proteger os sistemas de ataques maliciosos e ameaças; a usabilidade na interação do usuário ao software. Esses são alguns exemplos de qualidade que o software deve apresentar, mas é difícil medir.
Como mencionado, a avaliação do software é desafiadora, pois envolve opiniões, percepções e interpretações individuais, sendo que cada pessoa pode ter diferentes pontos de vista sobre a qualidade, baseando-se em sua experiência, seu conhecimento e seus valores pessoais.
A avaliação da qualidade de software é um processo subjetivo, em que a equipe de gerenciamento de qualidade precisa usar seu julgamento para decidir se foi alcançado um nível aceitável de qualidade. Ela precisa considerar se o software é adequado para sua finalidade ou não (Sommerville, 2011).
Pressman e Maxim (2021) englobam duas características à qualidade de software: qualidade do projeto e qualidade de conformidade.
A qualidade do projeto envolve o grau de atendimento às características especificadas de requisitos. Já a qualidade de conformidade foca na implementação do projeto e se o sistema resultante atende efetivamente às necessidades e metas estabelecidas.
A qualidade de software é uma combinação de múltiplos atributos, e não depende apenas dos requisitos do sistema, mas também da experiência do usuário e do atendimento às necessidades específicas de cada contexto, requerendo um processo contínuo de testes, validações dos usuários e aprimoramentos para assegurar que o produto atenda aos mais altos padrões de desempenho e satisfaça as demandas dos usuários de forma efetiva.
Métricas de gerenciamento e qualidade de software 
Agora que já temos uma compreensão a respeito do significado de qualidade no desenvolvimento de software, precisamos conhecer como medir a qualidade.
Primeiramente, as métricas desempenham um papel essencial na avaliação e no aprimoramento contínuo da qualidade no software, por serem medidas quantitativas utilizadas para avaliar diversos aspectos, visto que fornecem informações mensuráveis e objetivas da qualidade do sistema, possibilitando ter uma visão clara sobre o produto.
Por meio das métricas, é possível obter uma compreensão mais aprofundada dos pontos fortes dos sistemas e das áreas que necessitam de maior aprimoramento, identificando possíveis problemas e riscos, permitindo que a equipe de desenvolvimento tome medidas preventivas ou corretivas. Além disso, as métricas permitem monitorar o progresso do projeto ao longo do tempo, identificando o que é crucial para garantir o cumprimento de prazos e metas estabelecidas, evitando desvios significativos.
A medição possibilita uma comparação entre diferentes projetos e/ou versões do software, ajudando a identificar melhores práticas e contribuindo para o aprimoramento de futuros projetos.
Embora existam muitas medidas de qualidade de software, a correção, a manutenibilidade, a integridade e a usabilidade são as que mais fornecem indicadores úteis para a equipe de desenvolvimento (Pressman; Maxim, 2021).
· Correção: mede a quantidade de defeitos encontrados em uma aplicação. Como métrica, podemos analisar a taxa de novos defeitos, que indica quantos defeitos são encontrados em um determinado período; a classificação dos defeitos, que pode ser baixa, média, alta ou crítica; o tempo médio para corrigir os defeitos; a taxa de reincidência de defeitos, indicando a proporção de defeitos que reaparecem após as correções; o percentual de defeitos encontrados pelos usuários, comparados aos encontrados pela equipe de testes.
· Manutenibilidade: mede a facilidade que um sistema pode ser modificado, atualizado ou corrigido após sua implementação inicial. Essa métrica avalia a capacidade do software de ser sustentado e aprimorado ao longo do tempo. Uma métrica simples é o Tempo Médio para Alterar (MTTC), que mede o tempo necessário para analisar, projetar, implementar, testar e liberar a funcionalidade aos usuários.
· Integridade: mede a capacidade do sistema de resistir a ataques intencionais à segurança. A integridade é definida com base nas métricas de ameaça (probabilidade de ataque) e segurança (probabilidade de repelir o ataque).
· Usabilidade: mede a facilidade de uso do software e a experiência do usuário em interagir com a aplicação. Como métrica, podemos analisar a taxa de tarefas realizadas com sucesso pelos usuários na primeira tentativa; o tempo médio que os usuários levam para concluir as tarefas no sistema; a proporção de erros cometidos pelos usuários ao realizar tarefas específicas; a satisfação do usuário ao utilizar o produto.
Portanto, as métricas são essenciais para garantir a qualidade do software e podem ser utilizadas para direcionar ações de melhoria contínua.
Elementos da garantia da qualidade de software
Durante a nossa jornada sobre o gerenciamento da qualidade de software, percebemos a importância das métricas dequalidade. É fundamental compreender que a qualidade não deve ser uma preocupação secundária, em vez disso devemos incorporar a qualidade na concepção do software até em sua manutenção.
A qualidade abrange todo o ciclo de desenvolvimento do software e diversos outros fatores, como: a compreensão das necessidades do cliente, a definição clara dos requisitos, a análise do processo e a adoção de boas práticas no desenvolvimento.
A garantia da qualidade de software é uma atividade essencial para assegurar que o produto alcance os mais elevados padrões de qualidade. Integrá-la em todas as fases do desenvolvimento é um passo crucial para alcançar o objetivo proposto do software.
Ao garantir a qualidade desde o início, conseguimos evitar retrabalho e custos extras, além de reduzir problemas significativos no produto. Isso resulta em um impacto positivo na entrega, pois teremos um software que atende efetivamente às necessidades do cliente.
Figura 1 | Garantia da qualidade de software
De acordo com a Figura 1, os elementos da garantia de qualidade de software são:
· Definir processo: engloba o estabelecimento de um processo específico para a garantia da qualidade, com diretrizes, políticas e procedimentos que serão seguidos durante todo o ciclo de desenvolvimento.
· Controle de alterações: compreende o controle e gerenciamento de todos os artefatos produzidos durante o desenvolvimento do software, garantindo a integridade e rastreabilidade dos itens.
· Revisões e testes: inclui atividades específicas relacionadas à garantia e ao controle da qualidade, tais como: revisões técnicas, estratégias de testes para identificar e avaliar o impacto dos defeitos encontrados, melhorando a qualidade do software.
· Métodos e ferramentas: os métodos são as abordagens ou técnicas sistematizadas que guiam o processo de desenvolvimento. Já as ferramentas são os softwares que auxiliam nas atividades de desenvolvimento.
· Auditorias e conformidade: avalia a eficácia dos processos definida pela organização e garante que o software esteja em conformidade com os padrões estabelecidos.
· Medição e geração de relatórios: garante o uso das métricas e indicadores para medir a qualidade do processo de desenvolvimento, identificando áreas de melhoria e gerando relatórios para acompanhar o progresso e a conformidade com os objetivos estabelecidos.
Pressman e Maxim (2021) ainda citam que outros elementos também fazem parte da preocupação da garantia da qualidade, tais como: a capacitação dos profissionais da equipe e a garantia das atividades de suporte, entre eles: manutenção, suporte on-line, documentação e manuais de usuários.
Aluno, ao combinar estes elementos, as equipes de desenvolvimento podem estabelecer uma cultura de qualidade sólida e garantir que o software atenda a altos padrões de qualidade.  
Fatores da qualidade de software
Aluno, ao longo dos anos, a indústria de tecnologia tem reconhecido a importância de fornecer sistemas confiáveis, eficientes e que atendam às expectativas dos usuários. Para alcançar esses objetivos, é essencial entender e analisar os diversos fatores que influenciam a qualidade de um software.
Em 1977, McCall desenvolveu um dos primeiros modelos formais para avaliar a qualidade, conhecido como Modelo de Fatores de Qualidade de McCall. Esse modelo propôs uma estrutura organizada para refletir sobre os aspectos fundamentais que influenciam na qualidade do software.
Os fatores de qualidade desempenham um papel fundamental na avaliação e garantia de qualidade do software, sendo estes os atributos e as características que determinam o grau de excelência do produto: produtos usados para avaliar o quão bem o software atende aos requisitos do usuário e às expectativas de qualidade.
De acordo com a Figura 1, o modelo de fatores de qualidade de McCall focou em três categorias principais que abrangem diferentes fatores de produtos de software.
Figura 1 | Fatores da qualidade de software
Fonte: adaptada de McCall, Richards e Walters (1977).
A revisão do produto aborda a capacidade do software de ser modificado, atualizado e corrigido com facilidade, sem impactar negativamente sua estrutura e funcionalidade. Inclui fatores, como:
· Manutenibilidade: passar por mudanças ou evoluções de forma rápida e com baixo impacto em sua estrutura e funcionamento.
· Flexibilidade: ajustar ou adaptar facilmente a novas exigências, como: novos cenários, requisitos ou funcionalidades adicionais.
· Testabilidade: submeter a testes de forma abrangente, eficiente e confiável, a fim de verificar se ele atende aos requisitos e se funciona corretamente em diferentes cenários.
A transição do produto aborda a capacidade do software de ser adaptado e transferido para diferentes ambientes e plataformas sem a necessidade de grandes modificações. Inclui fatores, como:
· Portabilidade: ser transferido em diferentes sistemas operacionais, plataformas de hardware ou ambientes de execução. Um software portável pode ser executado em diversos dispositivos ou ambientes sem a necessidade de modificações significativas.
· Reusabilidade: ter componentes ou módulos reutilizados para outros softwares. Um código bem estruturado e modular facilita a reutilização de suas partes, economizando tempo e recursos no desenvolvimento de novos sistemas.
· Interoperabilidade: funciona de forma integrada com outros sistemas e aplicativos, independentemente das plataformas ou tecnologias usadas, garantindo que dados e serviços possam ser compartilhados e trocados de maneira eficiente.
A operação do produto aborda a forma que o software se comporta e executa suas funções em condições normais de uso, ou seja, quando está em pleno funcionamento pelos usuários. Inclui fatores, como:
· Correção: satisfazer as especificações e cumprir os objetivos visados pelo cliente.
· Confiabilidade: executar as funções de maneira estável, sendo livre de defeitos, evitando interrupções inesperadas durante o uso.
· Usabilidade: fácil entendimento de uso e intuitivo, permitindo que os usuários interajam com o sistema de forma simples e sem dificuldades.
· Integridade: manter e preservar a integridade dos dados e das informações manipuladas durante o seu funcionamento, evitando corrupção, perda ou acesso não autorizado.
· Eficiência: desempenho do software em relação à velocidade e utilização de recursos, garantindo que as tarefas sejam executadas de forma rápida e sem atrasos excessivos.
Aluno, vimos como cada fator contribui para a criação de um software mais confiável, eficiente e adaptável, resultando em um produto que proporciona uma experiência positiva e satisfatória.
Como garantir a qualidade de software?
Caro aluno, compreender a qualidade de software é um desafio, pois ela possui conceitos diferentes para diferentes pessoas. Também, a qualidade é impactada por diversos fatores que afetam seu resultado. Na Aula 2, tivemos a oportunidade de entender o significado da qualidade e explorar os seus elementos fundamentais da garantia da qualidade. Esses elementos são vitais para assegurar que padrões e critérios de qualidade sejam devidamente alcançados. Entretanto, o que deve ser feito para garantir a qualidade de um software?
A fim de garantir a qualidade do software, é importante compreender que a garantia da qualidade deve estar presente em todas as etapas do desenvolvimento de software, vide exemplo na Figura 2. Seu principal objetivo é detectar problemas antes que sejam migrados para a próxima fase.
Figura 2 | Garantia da qualidade em todas as etapas de desenvolvimento
Fonte: adaptada de Bartié (2002).
De acordo com cada fase, temos as seguintes atividades e atuações da garantia da qualidade:
· Definição do modelo de negócios: nesta fase, ocorre a modelagem e a identificação das necessidades do cliente, proporcionando uma compreensão do produto a ser desenvolvido, bem como a sua viabilidade, o seu cronograma e os custos. A garantia da qualidade assegura que as necessidades relatadas pelos clientes são claras e objetivas, além de verificar a existência de um planejamentoque abranja a avaliação de viabilidade de execução do projeto, o cumprimento do prazo e os custos envolvidos.
· Especificação dos requisitos: nesta fase, são identificadas as características funcionais e não funcionais para a concepção do produto. Durante esta fase, todas as necessidades que emergiram no modelo de negócio são minuciosamente detalhadas através dos requisitos. A garantia da qualidade deve avaliar se os requisitos coletados estão completos, claros e sem ambiguidade. Adicionalmente, é essencial verificar se eles foram validados pelos clientes e se existe a rastreabilidade entre os requisitos.
· Análise e modelagem: nesta fase, é definido um modelo de solução que abrange todos os requisitos definidos na fase anterior. A garantia de qualidade avalia se todos os requisitos foram incluídos nesta solução, bem como verifica a capacidade da arquitetura definida em lidar eficazmente com mudanças significativas, sejam elas relacionadas ao crescimento, à segurança, ao ambiente etc.
· Implementação: já na fase de implementação, os modelos e requisitos definidos nas fases anteriores são transformados em código fonte. A garantia da qualidade assegura a legibilidade do código fonte; avalia a conformidade com o padrão de desenvolvimento da organização; avalia as mensagens apresentadas ao usuário final e a existência de rotinas de tratamento de erros em processos críticos do sistema.
· Teste de software: o objetivo desta fase é identificar falhas para buscar confiabilidade, usabilidade e eficiência do produto, assegurando que funcione conforme o esperado em diferentes cenários e condições. A garantia da qualidade avalia se as estratégias, as categorias e os casos de testes definidos estão sendo seguidos e executados de acordo com o planejado para alcançar os objetivos propostos.
· Disponibilização: fase em que o produto é entregue ao cliente para os usuários realizarem a homologação das funcionalidades do sistema. A garantia de qualidade avalia a entrega do sistema e garante o aceite por parte do cliente e as manutenções necessárias.
Através da presença e do acompanhamento em todas as fases do desenvolvimento, podemos garantir a qualidade do software e do processo.
O dilema da qualidade de software
Ao longo desta jornada, exploramos os conceitos fundamentais sobre qualidade e os meios para garantir a qualidade de software. No entanto, quão intensamente devemos direcionar o esforço e o foco para a garantia da qualidade? O que seria um software “bom o suficiente”?
Essas são questões do dilema da qualidade. Se for desenvolvido um software de baixa qualidade, podemos ter uma falta de interesse do mercado; se buscarmos por um software perfeito, devemos ter em conta os custos altos e um período longo de desenvolvimento. O dilema da qualidade é encontrar um equilíbrio entre um produto aceitável, evitando excessos de esforço e gasto, de forma que não comprometam o projeto.
Este dilema surge porque, ao investir em testes rigorosos, revisões extensas e práticas de desenvolvimento de qualidade, pode-se obter um produto final mais estável e confiável, resultando em menos retrabalho, menos problemas após seu lançamento e uma reputação positiva para a empresa. Mas, essa abordagem pode aumentar o tempo de desenvolvimento, atrasar o lançamento do produto e aumentar os custos.
Por outro lado, optar por acelerar o processo de desenvolvimento pode permitir que o produto chegue ao mercado mais rapidamente, o que pode ser vantajoso em um ambiente de competição acirrada. Entretanto, pode resultar em problemas de qualidade, defeitos, vulnerabilidades à segurança e insatisfação do cliente.
Então, o que seria um software “bom o suficiente”?
O software “bom o suficiente” fornece funções e características de alta qualidade desejadas pelos usuários, mas, ao mesmo tempo, fornece outras funções e características mais obscuras ou especializadas que contêm erros conhecidos (Pressman; Maxim, 2021).
Para Pressman e Maxim (2021), é viável a entrega de um software que não seja perfeito, mas que atenda às necessidades do usuário e, ao mesmo tempo, ofereça alguns erros conhecidos. Com um bom time de marketing, pode-se vender este software em sua primeira versão e melhorá-la para a versão 2.0 com aprendizados.
Pressman e Maxim (2021) enfatizam o risco para pequenas empresas de entregar um produto com erros, visto que se pode arruinar permanentemente a reputação da empresa, nem tendo chances de entregar uma próxima versão. Também, temos softwares de grandes corporações, como os de sistemas embarcados em tempo real, que envolvem risco à vida, nos quais qualquer erro conhecido compromete drasticamente a confiabilidade.
Mas, quanto custa a qualidade? No contexto de assegurar a qualidade, certamente, haverá um investimento financeiro, contudo, a ausência da qualidade também acarretará custos.
Figura 3 | Custos para corrigir erros e defeitos ao longo do ciclo de vida do software
Fonte: adaptada de Boehm e Basili (2001).
Na Figura 3, ao exemplificar em valores, observa-se que o custo relacionado ao encontrar e corrigir um defeito aumenta drasticamente à medida que avançamos cada vez mais nas fases do desenvolvimento de software. Entre a fase de requisitos e codificação, vê-se um aumento de 1 a 10 vezes o valor do custo da correção. Na fase de testes, esse valor sobe de 15 a 70 vezes. Após o lançamento do produto, este custo pode chegar a 1000 vezes mais caro.
Mesmo que tenha um custo para garantir a qualidade, no final, torna-se mais barato do que não o ter, ou seja, o equilíbrio envolve uma análise sobre o objetivo do produto, as oportunidades do mercado (custo e prazo) e atender às necessidades do usuário.
Metodologia ágil para gerenciamento de projetos
Estudante, modelos de processos têm por objetivo organizar e estruturar o desenvolvimento do produto. Cada modelo, dentre os diversos disponíveis, é distinto em seu fluxo de procedimento, delineando a maneira pela qual as atividades metodológicas, as ações e as tarefas são estruturadas, de forma sequencial e cronológica. Esses padrões são cruciais para a resolução dos desafios que são identificados ao longo do processo de desenvolvimento de software.
Em 2001, dezessete pessoas se reuniram para discutir sobre o futuro do desenvolvimento de software, compartilhando suas frustrações pelo enfoque das empresas em planejamento e documentação do ciclo de desenvolvimento. Porém, as empresas esqueceram-se de fatores importantes, então eis que surge o manifesto ágil, como podemos ver na Figura 1.
Figura 1 | Manifesto para desenvolvimento ágil de software
Fonte: Agile Manisfesto.
Mas, o que é agilidade? A agilidade abrange a rápida resposta às mudanças. Todavia, não é somente isso. A agilidade integra as propostas do manifesto ágil, incentivando uma comunicação mais fácil entre os membros da equipe (tanto pessoas técnicas quanto não técnicas); enfatiza a entrega do software que realmente funcione e atenda às necessidades do cliente; destaca a importância de trabalhar perto dos clientes para compreender suas necessidades em evolução; reconhece que mudanças são inevitáveis e que a capacidade de se adaptar rapidamente a elas é crucial para o sucesso do projeto.
Na metodologia ágil, temos os seguintes métodos mais utilizados no mercado, que são: Scrum e Kanban.
· Scrum: é baseado em sprints, ou seja, ciclos de produção de um projeto, com foco na colaboração, flexibilidade e entrega contínua de valor aos clientes.
No processo do Scrum, vide Figura 2, temos o product owner, que prioriza os requisitos que serão implementados para a próxima sprint. No planejamento, o time realiza a estimativa das histórias priorizadas e define qual será o objetivo da sprint e como será atendida, criando o sprint backlog, que são as atividades que serão desenvolvidas até o final da sprint. Após isso, inicia-se a sprint.
Sobre a duração da sprint, ocorre de duas a quatro semanas, e o time realiza o desenvolvimento da funcionalidade. Também, temos o scrum master, que ajuda todos do time e implementa valores, princípiose práticas do Scrum, sendo responsável por conduzir a daily. Daily é uma única reunião diária feita para verificar o andamento da sprint e possíveis impedimentos; caso haja impeditivos, o scrum master é responsável por remover obstáculos.
Após a finalização da sprint, o scrum master conduz a retrospectiva, que é uma reunião em que o time analisa a sprint, pontuando pontos positivos e negativos e realizando questionamentos sobre como pode melhorar; no final da retrospectiva, levanta alguns planos de ações para melhoria contínua. Em paralelo com a retrospectiva, ocorre a revisão, na qual o time demonstra o que foi desenvolvido para o product owner.
Sprint finalizada, repete-se todo o processo a partir da reunião de planejamento.
Figura 2 | Processo do Scrum
Fonte: elaborada pela autora.
· Kanban: é um quadro visual que ajuda a visualizar as demandas do time. O quadro é dividido em colunas que representam as etapas do desenvolvimento. As etapas mais utilizadas pelas empresas são: A fazer, em desenvolvimento e finalizado. Claro que se pode acrescentar mais colunas, pois a metodologia é adaptável para cada projeto. Na Figura 3, é exibido um quadro Kanban dividido em quatro etapas, que são: A Fazer, em desenvolvimento, em testes e finalizado.
Figura 3 | Exemplo de quadro Kanban
Fonte: elaborada pela autora.
Uma das principais funções do Kanban é garantir um número máximo de itens nas colunas de trabalho Em Andamento, limitando-o, a fim de garantir que todos tenham trabalho a fazer, mas que ninguém esteja fazendo múltiplas tarefas. Isso quer dizer que, se foi definido que o limite para um do time será quatro itens “Em Desenvolvimento”, ao ultrapassar este limite, ficará evidente no quadro. Com isso, o foco se torna terminar os itens em andamento antes de puxar algo novo para desenvolver.
Aluno, você pode concluir que as metodologias ágeis priorizam a colaboração no projeto, a flexibilidade e a entrega incremental, sendo adaptáveis e eficientes, impulsionando resultados excepcionais no ambiente organizacional de constante mudança.
Planejamento e estimativa de projetos
As metodologias ágeis são abordagens iterativas que enfatizam a flexibilidade, a colaboração e a entrega incremental de software. Cada iteração é um ciclo curto de desenvolvimento, durante o qual uma parte funcional do software é planejada, desenvolvida, testada e entregue. Isso permite que o software seja entregue em partes funcionais ao longo do tempo, em vez de esperar até que o produto todo esteja concluído.
Entenderemos sobre o processo de planejamento e estimativa, bem como técnicas de estimativa e o quanto podemos planejar para as próximas iterações.
Sommerville (2011) cita que, nas metodologias ágeis, há uma abordagem de planejamento em dois estágios, sendo eles:
· Planejamento de release: o objetivo principal deste estágio é definir uma visão de longo prazo para o produto e determinar quais funcionalidades serão incluídas no release.
· Planejamento de iteração: processo mais curto e detalhado que ocorre no início de cada iteração, também conhecida como sprint. O planejamento de iteração é estabelecido no backlog pelo product owner, que seleciona as histórias de usuário para serem implementadas durante a sprint.
De acordo com a Figura 4, no início do projeto, a equipe e o cliente colaboram para identificar as histórias representadas por funcionalidades planejadas. O planejamento de release implica a seleção e o refinamento das histórias de forma contínua. O planejamento de iteração envolve a escolha das histórias para a sprint.
Na reunião de planejamento de iteração, o time realiza a quebra de histórias em tarefas, transformando-as em pequenas atividades que são necessárias para o desenvolvimento da funcionalidade. Por fim, cada tarefa é estimada pelo time. Essas estimativas são utilizadas para calcular o esforço e o tempo em desenvolver as demandas da iteração por completo.
Figura 4 | Planejamento ágil
Fonte: adaptada de Sommerville (2011, p. 440).
As estimativas são calculadas da seguinte forma: as histórias são avaliadas em termos de esforço e são atribuídos pontos de esforço, que podem variar conforme o grau de complexidade. Algumas formas para estimar são:
· Por hora: o time estima de acordo com o esforço previsto em horas de trabalho.
· Story Point (pontos de história): cada história é atribuída a um número de pontos. Esses pontos não têm um valor absoluto, mas são usados para comparar histórias entre si de acordo com a complexidade. Exemplo: por tamanho (PP, P, M, G).
Essas formas de estimativas podem utilizar algumas técnicas, que são:
· Estimativa baseada em histórico: o time usa referências históricas para estimar o esforço em novas tarefas, ajudando a criar estimativas mais precisas e realistas.
· Planning Poker: os membros da equipe discutem as histórias, fazem perguntas para esclarecimentos e, depois, selecionam uma estimativa relativa (story point) de forma simultânea, usando cartas com números.
Aluno, o planejamento de release ou iteração estabelece um roteiro claro para o projeto. Já as estimativas visam prever o esforço necessário para concluir as demandas.
Execução, monitoramento e controle de projetos
Durante esta aula, exploramos as metodologias ágeis e vimos sobre planejamento e estimativa. Agora, entenderemos o que é a fase de execução de um projeto e como podemos monitorar e controlar seu andamento. Essas atividades trabalham em conjunto para garantir que os objetivos do projeto sejam alcançados dentro do escopo definido, por cronograma e orçamento.
Depois da fase de levantamento de requisitos, análise e modelagem, vem a etapa da execução. Essa fase é o momento em que o planejamento cuidadosamente elaborado começa a se concretizar. As atividades e tarefas delineadas em reuniões de planejamento são postas em ação pela equipe de desenvolvimento. A comunicação clara e eficaz se torna uma ferramenta vital nesta fase, permitindo que todos os membros da equipe entendam suas responsabilidades, além de facilitar a resolução rápida de problemas que possam surgir.
Entretanto, o progresso do projeto não pode ser considerado garantido somente pela execução das atividades. A fase de monitoramento entra em cena para avaliar continuamente o progresso do projeto com relação ao plano original. Dados reais são coletados e comparados aos dados planejados, identificando desvios que possam surgir. Isso possibilita uma visão em tempo real do estado do projeto, permitindo que a equipe identifique atrasos, excessos de custos ou problemas de qualidade antes que se tornem incontroláveis.
Utilizando, por exemplo, o Scrum, é possível monitorar o andamento do projeto pelo gráfico de burndown, conforme a Figura 5. O gráfico representa visualmente o esforço em relação ao tempo necessário para concluir a sprint e permite decisões mais assertivas e realistas, desde que os dados estejam corretamente atualizados.
A precisão do gráfico facilita a comunicação com as partes interessadas para que todos saibam o que esperar.
Conforme a Figura 5, o gráfico de burndown é construído por dois eixos, que representam:
· Esforço: a quantidade de trabalho restante.
· Tempo: os dias do começo até o final da sprint (ou projeto).
Atravessando os eixos, temos duas linhas:
· Planejado: o trabalho ideal. Mostra o quanto precisa ser feito a cada dia para atingir a meta do cronograma.
· Real: o trabalho real. Mostra o ritmo de avanço que está sendo realizado pela equipe.
Figura 5 | Gráfico de burndown
Fonte: elaborada pela autora.
Com base nas informações coletadas durante o monitoramento, a equipe pode tomar decisões para realinhar o projeto aos seus objetivos. Isso pode envolver readequação do cronograma, realocação das pessoas, revisão das atividades ou até mesmo ajustes no escopo do projeto. O controle não apenas garante que os desvios sejam tratados, mas também oferece uma oportunidade de aprendizagem valiosa para as próximas sprints.
O monitoramento e o controle são processos iterativos, ocorrendo ao longo de toda a execução do projeto. Issoajuda a equipe a adaptar-se às mudanças que podem ocorrer durante o andamento do desenvolvimento. A agilidade e a capacidade em responder aos ajustes conforme necessário, sem comprometer o resultado.
Aluno, a execução, o monitoramento e o controle de projetos são vitais para ajudar o gerenciamento do projeto a ser bem-sucedido. Cada fase desempenha um papel crítico para garantir que o produto seja entregue dentro das expectativas, ajustando o percurso conforme necessário e mitigando os riscos que possam surgir, fornecendo resultados de alta qualidade.
Explorando a qualidade e as métricas de revisão de software – Unidade 2
Aluno, durante o trajeto em desenvolver softwares, perceberemos que erros são resultados inevitáveis de ações humanas. Quando um erro se manifesta como um comportamento incorreto do software, isso é chamado de falha. A falha é o sintoma visível, mas por trás dela está o defeito, uma imperfeição no código que causa a falha. Compreender essa relação é essencial, pois ajuda a identificar, corrigir e evitar defeitos, melhorando a qualidade do software.
· Erro de software: no contexto do desenvolvimento de software, um erro refere-se a uma ação humana que produz um resultado incorreto ou inesperado. Erros são inerentes à natureza humana e podem ocorrer em qualquer fase do desenvolvimento. São o resultado de decisões equivocadas, interpretações errôneas ou lapsos na implementação.
· Defeito de software: um defeito é a raiz das falhas e ocorre quando há uma imperfeição no código-fonte do software. É a relação entre os erros de desenvolvimento e as falhas vistas pelo usuário. Defeitos podem surgir devido a equívocos na codificação. Identificar e corrigir defeitos é essencial para aprimorar a qualidade do software.
· Falha de software: uma falha ocorre quando um componente de software não executa a função esperada. É a diferença entre o observado e o esperado. Ela é a consequência visível de um erro, ou seja, que não se manifesta claramente e pode ser percebida pelo usuário final como um comportamento incorreto do sistema. As falhas são resultadas tangíveis da presença de defeitos no software e podem variar em gravidade, de pequenos incômodos a problemas críticos.
A busca pela qualidade do software nos leva ao reino das métricas de revisão. Segundo Hetzel (1987), testes são fundamentais para o controle de um projeto, portanto, uma vez que considerado uma fase importantíssima do processo de desenvolvimento de software, surge a necessidade de identificar maneiras de controlá-los de forma eficiente.
Métricas de software são medidas quantitativas utilizadas para avaliar características do desenvolvimento de software, permitindo análises objetivas e tomadas de decisão informadas (Pressman; Maxim, 2014).
Algumas das métricas mais importantes incluem:
· Taxa de cobertura de testes: percentual dos testes conhecidos que foram concluídos.
· Taxa de detecção de defeitos: mede a eficácia da revisão ao calcular a proporção de defeitos encontrados em relação ao número total de defeitos presentes.
· Tempo médio para resolver defeitos: avalia a eficiência da equipe em resolver os defeitos encontrados durante as revisões.
· Taxa de falsos positivos e falsos negativos: avalia a precisão das revisões, identificando a proporção de defeitos erroneamente identificados como verdadeiros (falsos positivos) e defeitos reais que não foram detectados (falsos negativos).
· Densidade de defeitos encontrados: quantifica o número de defeitos encontrados em relação ao tamanho do artefato revisado.
· Tempo médio por revisão: mede o tempo médio gasto em cada revisão.
Essas são apenas algumas das mais variadas métricas que existem atualmente nos processos de revisão de software. No entanto, a eficácia das métricas de revisão depende em grande parte dos registros dessas revisões. Os registros de revisões referem-se à documentação detalhada e organizada das atividades relacionadas às revisões. Durante esses processos formais, o software é avaliado, buscando identificar defeitos, sugerir melhorias e verificar a conformidade com os requisitos definidos.
Caro aluno, perante todos os conceitos apresentados anteriormente, podemos compreender os quão importantes são as métricas e revisões para um bom desenvolvimento de software com qualidade, visto a propensão do ser humano em cometer erros.
Métricas e revisões eficientes
Já sabemos que o processo de desenvolvimento de software não segue uma linha de produção limpa e fácil. Quando estamos construindo software, em meio a todas as coisas que fazemos, é bem provável que algumas falhas aconteçam. Dessa forma, é preciso compreender como as métricas e revisões registradas são responsáveis por garantir o sucesso durante as fases de construção do software.
Ao fazer parte da equipe de testes em uma organização, o profissional, com certeza, se deparará com os seguintes questionamentos:
· “Qual o tempo necessário para finalizar o ciclo de testes?”.
· “Qual o grau de estabilidade da funcionalidade que está sendo testada?”.
· “Quantos testes serão necessários para o escopo que você está testando?”.
· “Quanto já foi testado?”.
A lista de questionamentos é extensa, mas faz parte da rotina da equipe de testes. É importante frisar que responder a esses questionamentos nem sempre é confortável para o testador. Existem alguns motivos:
· A equipe de testes não está preparada para apresentar os dados solicitados.
· A equipe de testes possui dados inadequados
· A equipe de testes não estava ciente da necessidade de levantar e registrar essas métricas.
Quando não há dados registrados, geralmente um profissional de testes é destacado para deixar sua atividade e realizar a coleta dos dados e tratá-los de uma forma apresentável. Este desafio poderá levar muito tempo para ser finalizado e custará o precioso tempo da equipe de testes; isso se deve, principalmente, à falta de planejamento.
Um programa de métricas é um conjunto de passos que incluem planejar, medir, analisar os dados, tomar decisões e implementar essas decisões.
É importante dizer que as métricas possuem algumas características que agreguem valor ao seu uso, tais como a facilidade de ser calculada e compreendida sem ambiguidade. A métrica possui uma capacidade de análise estatística que possibilita identificar tendências, distribuições e relações entre os dados.
As métricas podem ser divididas entre diretas, indiretas, orientadas a tamanho, orientadas por função, produtividade, qualidade e técnicas (Garcia, 2015).  
· Métricas diretas: chamadas também de fundamentais ou básicas, são medidas quantitativas obtidas por meio da avaliação de atributos observáveis, tipicamente determinada por processos de quantificação (exemplos: custo de projeto, tempo de desenvolvimento e quantidade de defeitos encontrados).
· Métricas indiretas: chamadas também de derivadas, são obtidas por meio da análise e combinação de outras métricas previamente coletadas (exemplos: complexidade, eficiência, confiabilidade, facilidade de manutenção).
· Métricas orientadas a tamanho: são indicadores diretos que mensuram as dimensões dos artefatos de software relacionados ao processo pelo qual o software foi desenvolvido (exemplos: esforço, custo).
· Métricas orientadas por função: representam um conjunto de técnicas para mensurar o software sob a perspectiva do usuário, estabelecendo uma visão sob a complexidade do sistema.
· Métricas de produtividade: constituem um conjunto de indicadores voltados para avaliar a produção resultante do processo de engenharia de software (exemplos: número de casos de uso por iteração, número de linhas de código por dia, número de histórias de usuário concluídas por sprint).
· Métricas de qualidade: são um conjunto de indicadores utilizados para avaliar a conformidade do software com os requisitos e padrões estabelecidos pelo cliente (exemplos: taxa de defeitos e tempo médio de correção de defeitos).
· Métricas técnicas: indicadores utilizados para avaliar as características intrínsecas do software, concentrando-se nos aspectos técnicose estruturais do código e das soluções implementadas (exemplos: complexidade ciclomática, índice de manutenibilidade).
Essas métricas não apenas avaliam a qualidade do processo de revisão, mas também auxiliam na identificação de áreas de melhoria, como veremos a seguir.
Métricas de software na prática
Agora que entendemos a importância das métricas de software e sua influência na qualidade do processo de desenvolvimento, é hora de nos aprofundarmos na aplicação dessas métricas. Nosso objetivo é entender como essas métricas são capazes de otimizar processos e resultados no âmbito do processo de desenvolvimento de software.
Sabemos que o levantamento de métricas é a melhor maneira de verificar quando um processo está sob controle e se seus objetivos são capazes de serem atingidos, principalmente se levarmos em consideração projetos grandes e complexos. Dessa forma, somos capazes de perceber que, para uma boa utilização das métricas de revisão de software, faz-se necessário um planejamento estratégico sólido.
Conforme Pressman e Maxim (2014), devemos selecionar cuidadosamente as métricas que se ajustam apropriadamente ao contexto do projeto. Cada software tem suas particularidades, portanto, é crucial que a escolha das métricas seja a mais assertiva possível (Hetzel, 1987), selecionando métricas relevantes para o sucesso do projeto.
Selecionadas as métricas, o passo seguinte é a definição dos objetivos tangíveis e quantitativos, os quais servirão como pontos de referência para avaliar o progresso e o desempenho ao longo do projeto.  Por exemplo, ao utilizar a taxa de cobertura de testes como métrica, é possível definir uma meta específica, como alcançar 90% de cobertura até o final de uma fase de desenvolvimento pré-determinada.
O desenvolvimento de um plano detalhado para coleta e análise de dados é de extrema importância. Essa etapa envolve determinar como, quando e por quem as métricas serão coletadas. Para garantir a confiabilidade dos dados, a criação de um processo claro e bem documentado é fundamental.
A seguir, realizamos a análise dos dados coletados. Essa análise deve ser realizada com bastante atenção. É aqui que comparamos os resultados obtidos com os objetivos estipulados e identificamos tendências ou padrões. Se uma métrica não atingir o objetivo estabelecido, devemos investigar as causas escondidas e implementar medidas corretivas apropriadas (Pressman; Maxim, 2014). Por exemplo, se a taxa de detecção de defeitos estiver abaixo do esperado, isso pode indicar que as revisões não estão sendo suficientemente rigorosas.
Ao analisar periodicamente os resultados das métricas, podemos identificar gargalos no processo de desenvolvimento, reconhecer problemas recorrentes e introduzir melhorias graduais. Caso observemos uma densidade de defeitos elevada em um módulo específico do software, por exemplo, podemos optar por alocar mais recursos para revisões e testes nessa área, ou seja, as métricas de revisão também podem desempenhar um papel fundamental na identificação de áreas de melhoria contínua.
A colaboração de toda a equipe de desenvolvimento é de extrema importância. Ao compartilhar metas, métricas selecionadas e resultados obtidos, criamos um senso de responsabilidade compartilhada pela qualidade do software. Essa abordagem colaborativa incentiva a contribuição de cada membro da equipe na identificação de problemas e na proposição de soluções (Pressman; Maxim, 2014), promovendo uma cultura de melhoria contínua.
Em síntese, a aplicação eficaz das métricas de revisão é um fator crucial para atingir um software de qualidade. Ao selecionar métricas pertinentes, estabelecer objetivos claros, coletar e analisar dados de maneira consistente e envolver toda a equipe, podemos aprimorar continuamente nossos métodos de desenvolvimento, identificar problemas precocemente e entregar um produto de software mais confiável e satisfatório aos usuários.
Introdução ao teste de software
Quando a humanidade se deu conta de que o software estava integrado na maior parte da vida cotidiana de pessoas, surgiu uma corrida pela maior qualidade de software. Qualidade não era uma preocupação no início da era digital. Hoje, todos os desenvolvedores de software concordam que software de alta qualidade é um objetivo importante.
Definir qualidade de software não é uma tarefa fácil. Para Pressman e Maxim (2021), no sentido mais geral, é uma gestão de qualidade para criar um produto útil que forneça valor mensurável para aqueles que o produzem e para aqueles que o utilizam. Já para Sommerville (2011), a qualidade do software é diretamente relacionada à qualidade do processo de desenvolvimento de software. Mas, e qualidade? Segundo o dicionário, qualidade é a propriedade positiva de um objeto ou um ser (Aulete, 2009).
A qualidade de software e os testes de software estão intrinsecamente relacionados, pois os testes desempenham um papel fundamental na busca por qualidade no desenvolvimento de software. Isso quer dizer que testar software é avaliar se ele está fazendo o que deveria fazer, de acordo com os seus requisitos, e não está fazendo o que não deveria fazer (Moreira Filho; Rios, 2003). Testar também pode ser um processo de executar um programa ou sistema com a intenção de encontrar defeitos (teste negativo) (Myers, 1979).
Para Hetzel (1988), teste é qualquer atividade que a partir da avaliação de um atributo ou capacidade de um programa ou sistema seja possível determinar se ele alcança os resultados desejados. E para Pressman e Maxim (2021), é um conjunto de atividades que podem ser planejadas com antecedência e executadas sistematicamente.
Todas essas definições realçam a seguinte ideia: teste de software é a verificação feita sobre um sistema ou parte dele para garantir que uma determinada entrada produza sempre uma saída esperada.
Dessa forma, compreendemos que, no âmbito do desenvolvimento de software, qualidade é compreendida como um conjunto de condições que devem ser satisfeitas ou refere-se à medida em que o software atende aos requisitos, sendo livre de defeitos, seguro, confiável e que atenda às necessidades do usuário.
Independentemente do projeto que se desenvolve, existem vários objetivos pelos quais devemos testar software. O CTFL Syllabus (2023), em sua versão 4.0, destaca os seguintes:
· Avaliar produtos de trabalho, como requisitos, histórias de usuários, projetos e código.
· Detectar falhas e defeitos.
· Garantir a cobertura necessária de um objeto de teste.
· Reduzir o nível de risco de qualidade de software inadequado.
· Verificar se os requisitos especificados foram atendidos.
· Verificar se um objeto de teste está em conformidade com os requisitos contratuais, legais e normativos.
· Fornecer informações aos stakeholders para que possam tomar decisões informadas.
· Criar confiança na qualidade do objeto de teste.
· Validar se o objeto de teste está completo e funciona conforme o esperado pelos stakeholders.
Os objetivos dos testes podem variar, dependendo do contexto, o que inclui o produto de trabalho que está sendo testado, o nível de teste, os riscos, o ciclo de vida de desenvolvimento de software que está sendo seguido e os fatores relacionados ao contexto do negócio (CTFL Syllabus, 2023).
Explorando os níveis de teste de software
Já sabemos os conceitos de qualidade e teste de software e compreendemos o quão importante é garantir que o software atenda aos requisitos estabelecidos, sendo livre de defeitos e que entregue valor aos seus desenvolvedores e usuários. Mas, quando falamos em teste de software, imediatamente deve surgir a seguinte dúvida: quando testar?
Nesse ponto, estamos falando em níveis de teste, os quais são grupos de atividades de teste que são organizadas e gerenciadas em conjunto. Cada nível de teste é uma instância do processo de teste, realizado em relação ao software em um determinado estágio de desenvolvimento, desde componentes individuais até sistemas completos (CTFL Syllabus, 2023).
Existem sete níveis de teste de software, que são realizados em momentosdiferentes do ciclo de vida do desenvolvimento de um software. Os níveis de teste são:
· Teste de Unidade: verifica o funcionamento do menor componente do software, como sub-rotinas, métodos e classes. É realizado pelo desenvolvedor e, geralmente, requer o uso de estruturas de teste ou frameworks de teste de unidade.
· Teste de Integração: verifica se a interação entre os componentes de um sistema é eficaz e não causa conflitos. É realizado pelo desenvolvedor e envolve a integração entre um ou mais componentes.
· Teste de Sistema: verifica o sistema como um todo, analisando o comportamento geral e seus recursos. É realizado por uma equipe de testes após a codificação completa do sistema. É realizado para verificar se o sistema atende aos requisitos definidos.
· Teste de Aceitação: verifica o sistema como um todo, sob o ponto de vista do usuário final, concentrando-se na validação dos requisitos. É realizado pelo usuário. O foco é verificar se o sistema está pronto para ser entregue e usado.
· Teste Alfa: verifica o sistema de uma forma que não tenha sido planejada, sob o ponto de vista de um seleto grupo de usuários internos. É realizado pelos usuários internos da organização, podendo incluir testadores, desenvolvedores e outros funcionários.
· Teste Beta: verifica o sistema de uma forma que não tenha sido planejada, sob o ponto de vista de um grande número de usuários. É realizado por um subconjunto de usuários finais do sistema, que satisfaçam determinados critérios definidos pelo fornecedor do sistema.
· Teste de Regressão: verifica o sistema após alterações, como correções de bugs ou implementação de novas funcionalidades. É realizado pela equipe de testes.
Os níveis de teste são diferenciados pelos atributos que lhes convêm, para evitar que as atividades de testes se repitam. O CTFL Syllabus (2023) destaca os seguintes:
· Objeto de teste.
· Objetivos do teste.
· Base de teste.
· Defeitos e falhas.
· Abordagem e responsabilidades.
Cada um desses atributos ajuda a caracterizar e diferenciar os diferentes níveis de teste, garantindo que cada fase de teste tenha um foco específico e contribua para a qualidade geral do software. Compreender esses atributos permite que os profissionais de teste planejem e executem testes de maneira mais eficaz, atingindo os objetivos definidos em cada etapa do processo de desenvolvimento de software.
Níveis de teste na prática
Agora que somos capazes de compreender a importância dos níveis de teste, no desenvolvimento de aplicações, nosso objetivo é entender como esses níveis de testes são executados em cada etapa do processo de desenvolvimento de software.
Os níveis de teste são agrupamentos de atividades de teste bem planejadas e executadas de maneira organizada. Cada nível de teste representa uma fase do processo de teste. Cada nível de teste contribui para a melhoria geral da qualidade do software, conforme definido pelo CTFL Syllabus (2023).
Em um ciclo de vida de desenvolvimento, existem sete níveis distintos de teste de software, cada um sendo executado em um momento específico. Segue-se a ordem:
· Teste de Unidade: é a menor parte testável do sistema. Nesse nível, o foco está nas partes mínimas do software, como funções e métodos, verificando se eles funcionam individualmente. Veja a Figura 1, ”Função soma”, escrita em python.
Figura 1 | Função soma
Fonte: elaborada pelo autor.
Nesse exemplo, o resultado da soma de 5 e 3 deve ser sempre 8. Este teste é muito importante para garantir que o “alicerce” do sistema funcione conforme o esperado.
· Teste de Integração: ocorre quando os componentes individuais do sistema são combinados. Isso garante que a interação entre esses componentes não resulte em conflitos. Este teste é uma atividade realizada pelos desenvolvedores, em que eles unem um ou mais componentes para verificar a integração. Veja os exemplos de integração a seguir:
Figura 2 | Módulo formatador
Fonte: elaborada pelo autor.Figura 3 | Módulo operações
Fonte: elaborada pelo autor.Figura 4 | Módulo de integração
Fonte: elaborada pelo autor.
Nesses exemplos, o módulo de integração verifica se a função de formatação cria a saída esperada com base no resultado da função de soma. Dessa forma, garantimos que as partes do software interajam sem problemas, como aconteceria em uso real.
· Teste de Sistema: por sua vez, avalia o sistema completo, analisando seu comportamento geral e recursos. Uma equipe de testes executa esse nível após a codificação completa do sistema. O objetivo é garantir que o sistema atenda aos requisitos definidos, funcionando como uma unidade coesa.
Sobre a perspectiva do usuário final, temos o Teste de Aceitação. Nesse nível, os requisitos são validados em relação à expectativa do usuário. O teste também é executado a nível de sistema e pelo próprio usuário final. Ele determina se o sistema está válido, ou seja, pronto para uso.
Os testes Alfa e Beta são voltados para avaliações não planejadas do sistema. O Teste Alfa é semelhante ao Teste de Aceitação, porém neste nível apenas um grupo seleto é incluído para testadores e desenvolvedores, verificando o sistema de maneira imprevista. O objetivo é garantir um maior nível de qualidade do produto antes de enviá-lo ao cliente, pois permite aos desenvolvedores resolver imediatamente problemas críticos ou correções identificadas. 
Enquanto isso, no Teste Beta, um número maior de usuários finais avalia o sistema em condições do mundo real, proporcionando feedback valioso. Este teste coleta a opinião dos usuários sobre o produto e garante que o produto esteja pronto para usuários em tempo real.
Por fim, o Teste de Regressão entra em ação após modificações no software, como correção de bugs ou adição de funcionalidades. É uma verificação para garantir que as mudanças não impactem negativamente o sistema. 
Portanto, compreender a dinâmica dos níveis de teste ajuda os profissionais de teste a planejar e executar testes de forma eficaz. Cada nível tem seu propósito único, mas todos são essenciais para entregar um software confiável, livre de defeitos e que atenda às necessidades dos usuários.
Padrões de teste de software
Padrões estão presentes em praticamente todos os aspectos de nossas vidas, e na área de testes de software não é diferente. Padrões são repetições reconhecíveis dentro de um conjunto de elementos ou processos. Tanto os mecanismos de desenvolvimento quanto os de teste de software estão cheios de padrões.
Equipes de testadores experientes realizam bons projetos de teste de software, ao passo que novos testadores acabam ficando sobrecarregados pelas opções de testes disponíveis, tendendo a utilizar métodos e técnicas de testes que não sejam eficazes e bem-sucedidas.
Uma coisa que boas equipes de testes não devem fazer é resolver testar cada etapa do processo de desenvolvimento de software do zero. Quando uma boa solução (método/modelo de teste) é encontrada, a equipe a reutiliza repetidamente. Dessa forma, você encontrará padrões, planos de testes, casos de teste e automações que se repetem frequentemente. Esses padrões resolvem situações específicas a depender do processo de desenvolvimento de software e permitem a equipe de testes desenvolver seu planejamento de testes com flexibilidade.
Os padrões de teste de software são instruções e práticas criadas para auxiliar equipes de testes a executar testes com qualidade. Alguns dos padrões mais comuns incluem:
· AAA (Arrange-Act-Assert): é um padrão para organizar e formatar códigos em métodos de testes unitários, separando-os em etapas de preparação, execução e verificação.
· Given-When-Then: é padrão de organização de casos de teste em cenários claros, dividindo-os em condições iniciais, ações executadas e resultados esperados.
· Page Object: é um padrão de design que ajuda a reutilizar objetos de testes para facilitar a manutenção de testes de UI automatizados.
· Data-Driven Testing: é um padrão que executa scripts de testes que acessa dados de entradas e saídas previstas a partir de arquivos de dados.
· Mocking e Stubbing:é um padrão de teste em que objetos que ainda não foram criados são simulados para isolar componentes do sistema que possuem dependências externas e/ou fornecer respostas pré-definidas para chamadas de métodos.
· BDD (Behavior Driven Development): é um padrão que enfatiza a colaboração entre desenvolvedores, testadores e stakeholders que ajuda a criar cenários de teste usando vocabulário específico e enxuto, minimizando dificuldades de comunicação.
· TDD (Test Driven Development): é uma metodologia para desenvolvimento e escrita de código, em que a codificação das funcionalidades começa a partir da escrita de testes unitários.
Além dos padrões mencionados, é importante nos aprofundarmos na diversidade de contextos em que o teste de software é aplicado. Ao falarmos de sistemas baseados em arquiteturas cliente-servidor, os testes, geralmente, se concentram na comunicação entre clientes e servidores, buscando garantir que os dados sejam entregues corretamente e que os componentes do servidor estejam suscetíveis a lidar com várias solicitações simultâneas.
Para garantir que essas arquiteturas funcionem corretamente, uma variedade de testes pode ser realizada, que incluem:
· Testes de Comunicação e Integração.
· Testes de Desempenho e Escalabilidade.
· Testes de Segurança.
· Testes de Integração com Bancos de Dados.
· Testes de Usabilidade.
· Testes de Recuperação de Falhas.
· Testes de Concorrência.
Em contraste, sistemas de tempo real impõem exigências rigorosas de latência e precisão temporal. Testar esses sistemas requer cenários específicos que avaliem a capacidade do software de responder dentro de prazos quase imediatos, garantindo que a execução das tarefas seja definitiva e previsível.
Padrões para arquitetura cliente-servidor
Agora que conhecemos os padrões de teste de software e sua utilidade no auxílio da execução de testes de software, exploraremos mais a fundo os testes para arquiteturas cliente-servidor.
O modelo de rede, ou arquitetura cliente-servidor, permite que um sistema complexo seja decomposto em componentes menores, em que cada componente é responsável por sua própria função. Em um sistema cliente-servidor, temos, do lado cliente, um ou mais componentes lidando com lógica de apresentação e uso de serviços fornecidos pelo lado do servidor; do lado do servidor, temos um ou vários componentes que agem coletando e armazenando dados, mantendo relação e fornecendo acesso aos dados processados por inúmeros clientes, ou até mesmo outros servidores na rede.
Testar sistemas cliente-servidor pode ser um desafio devido à sua natureza complexa, em que cada componente é dependente e permanece em relação com outros componentes. É essencial que haja boa colaboração entre todos os departamentos envolvidos no desenvolvimento deste tipo de sistema, alinhando processos de teste com o desenvolvimento desde estágios iniciais, tratando os testes como um esforço em equipe. Dessa forma, entenderemos melhor a respeito do que é necessário testar em sistemas cliente-servidor.
· Testes de Comunicação e Integração: a comunicação é um aspecto importantíssimo das arquiteturas cliente-servidor. Os testes devem garantir que os dados sejam transmitidos corretamente, que as solicitações dos clientes sejam tratadas de forma adequada e que as respostas dos servidores atendam às expectativas. Logo, isso envolve testar os protocolos de comunicação que estas arquiteturas utilizam, como HTTP, HTTPS e TCP/IP.
· Testes de Desempenho e Escalabilidade: em sistemas de arquitetura cliente-servidor, a escalabilidade é essencial para lidar com um grande número de clientes. Os testes de desempenho verificam como o sistema se comporta sob carga, analisando se os servidores são capazes de lidar com múltiplas requisições e se os tempos de resposta dessas requisições são aceitáveis. Para esse tipo de teste, ferramentas de teste de carga, como: Apache JMeter, são utilizadas para simular cenários de alta demanda.
· Testes de Segurança: segurança é um aspecto de extrema importância em sistemas de arquitetura cliente-servidor, pois muito comumente dados sensíveis são transmitidos. Para identificar e corrigir possíveis brechas na segurança, testes de penetração, ou pentest, são executados para identificar vulnerabilidades.
· Testes de Integração com Bancos de Dados: a maioria dos sistemas cliente-servidor interagem com bancos de dados. Testes devem ser feitos para verificar se a integração entre a camada do servidor e o banco de dados está sendo executada corretamente, incluindo a capacidade de recuperação e a gravação de dados, ou seja, leitura e escrita de informações no banco.
· Testes de Usabilidade: são essenciais quando o cliente em questão possuir uma interface para o usuário, como um aplicativo móvel ou uma página web. Esses testes têm por objetivo garantir que a interface é intuitiva, fácil de usar e atenda às necessidades do seu usuário.
· Testes de Recuperação de Falhas: envolvem a simulação de falhas de rede, falhas de servidor e outros cenários de erro, com o intuito de garantir que o sistema é capaz de se recuperar adequadamente e manter a integridade dos dados.
· Testes de Concorrência: envolve a simulação de um grande número de usuários acessando o sistema ao mesmo tempo. O objetivo é identificar problemas de concorrência, como condições de corrida, ou seja, conflitos no acesso de recursos compartilhados do sistema entre um ou mais usuários.
Aplicando padrões de teste de software
Tendo compreendido os conceitos de padrões de teste de software e teste de software para sistemas de arquitetura cliente-servidor, vamos nos aprofundar na aplicação de testes para um sistema de tempo real.
Sistemas de tempo real são quaisquer sistemas computacionais, de qualquer tipo, cujo tempo de resposta a um determinado evento seja pré-definido. Isso não significa, necessariamente, que são super-rápidos, mas, sim, capazes de fornecer serviços dentro de limites temporais estabelecidos em seu documento de requisitos.
É de nosso conhecimento os níveis de teste de software durante as etapas do processo de desenvolvimento de software. Dessa forma, sabemos que, independentemente do tipo de sistema que estamos testando, esses níveis devem ser respeitados para garantir que falhas no processo de desenvolvimento sejam encontradas e tratadas.
Sigamos para a aplicação desses padrões na testagem de nosso sistema de tempo real. Para isso, idealizaremos um sistema de monitoramento médico, projetado para permitir que médicos e enfermeiros monitorem constantemente os sinais vitais de pacientes em hospitais em tempo real. Este é um sistema crítico, pois fornece alertas imediatos a respeito de mudanças no estado de saúde de pacientes, como batimentos cardíacos ou quedas de pressão.
Alguns dos testes necessários para validar, com maior índice de qualidade possível, o sistema proposto são:
· Testes de Latência: têm o objetivo de avaliar o tempo que o sistema leva para processar uma entrada e produzir uma saída, ou seja, medem o tempo necessário para que os dados percorram entre o dispositivo cliente e o servidor. Estes testes devem ser executados medindo a latência da rede em diversas condições, como diferentes cargas e tráfego ou diferentes localizações geográficas dos dispositivos clientes. A latência deve estar dentro dos limites especificados no documento de requisitos.
· Teste de carga: têm o objetivo de avaliar como será o comportamento do sistema sob carga máxima, ou seja, determinam se o sistema mantém desempenho aceitável quando muitos usuários o acessam simultaneamente. Estes testes podem ser executados utilizando ferramentas de teste de carga, em que a carga, ou seja, o número de usuários acessando o sistema, é aumentado gradativamente até o limite especificado. O tempo de resposta do sistema deve estar dentro dos limites aceitáveis para todas as instâncias de usuários.
· Teste de estresse: têm o objetivo de avaliar o momento em que o desempenho do sistema cai, mesmo ao ponto de falhar completamente, ou seja, é um teste de carga realizado até