Conceitos de teste de software
Teste de software acima de tudo é o que agrega segurança ao deploy. Não é atoa a popularidade de TDD, onde a idéia é construir pequenos protótipos que se completam como um todo em scripts isolados, função por função, com verificações assertivas, resultando na identificação de casos de falha VERMELHOS e transferência do código funcional VERDE produzido, sem erros, para o código fonte em produção da aplicação.
Testes de software examinam o comportamento do produto por meio de sua execução, e são formas de se garantir a qualidade. Verificação (no contexto de testes) é o conjunto de atividades que garante que o software implementa corretamente uma função específica, enquanto validação garante que o mesmo corresponde aos requisitos. Erros são cometidos pelos programadores, ocasionando inconsistências, deficiências e comportamentos inesperados (fora da especificação). Falhas são eventos notáveis originados por defeitos. O processo de testes é ineficiente. Por quê?
- Pelo custo alto por defeito encontrado e corrigido limitado;
- Por jamais garantir que um programa está correto necessário;
- Por não haver técnica que reduza defeitos a ponto de eliminar a necessidade de se testar;
- Por que um software deve ser testado?
- Os 7 princípios de testes
- Quem deve executar os testes de software?
- 5 atividades fundamentais de um processo de teste
- Estratégias de testes dos modelos de ciclo de vida
- Verificação estática e dinâmica.
- Vantagens de se realizar os 3 (três) tipos de testes estáticos
- Testes de caixa-preta e testes de caixa-branca (white-box tests)
- Estratégias de modelagem de testes de caixa-preta (black-box tests)
- Como o Desenvolvimento Ágil trata dos testes
- Testes unitários
- Homologação como ferramenta de teste
- Seja certificado em testes
Por que um software deve ser testado?
As entradas (inputs) e saídas (outputs) de todo software devem ser confiáveis. Para isso são necessários os diversos tipos de testes para simular determinados comportamentos da aplicação, geralmente antes de sua liberação do ambiente de produção. Se justificam pela necessidade de se verificar a correta execução de determinada atividade e correticidade frente aos requisitos, também identificando anomalias devido a erros.
Os 7 princípios de testes
- Testes mostram a presença de defeitos, mas não provam o contrário;
- Testes exaustivos são impossíveis, devido à infinidade de possibilidades, tornam-se inviáveis em termos de custo-benefício;
- Testar antes (TDD) devido à vantagem da identificação prévia;
- Agrupamento de defeitos onde poucos módulos contém os erros;
- Paradoxo do pesticida, que reforça a importância do teste constante, revisto e atualizado;
- Teste dependente do contexto com criticidade e impacto diferentes;
- Falácia da ausência de defeitos: Existem defeitos que não são encontrados, o que acaba levando a conclusões errôneas;
Quem deve executar os testes de software?
Nas grandes equipes das organizações que produzem software existem especialistas específicos para tal finalidade. No entanto, naqueles contextos de negócios em que existe uma pequena equipe sem o profissional dedicado para testes, é uma boa estratégia envolver não apenas o desenvolvedor, mas também acrescentar visões diferentes sobre o resultado esperado, assim como de outro indivíduo da equipe, da empresa ou mesmo um consultor em outsourcing.
5 atividades fundamentais de um processo de teste
- Planejamento e controle : Fase de elaboração da estratégia de testes, definindo objetivos e as atividades para alcançá-los, asim como também a definição da política de testes.
- Análise e modelagem : Análise de informações como os requisitos, códigos, processos e seus diagramas para produção dos testes. Itens em condição de teste (com fonte rastreável) devem ser organizados por prioridade.
- Implementação e execução : etapa onde dados são disponibilizados aos testadores, e ocorre a especificação dos procedimentos e scripts de teste (itens como a sequência e priorização, se automatizado ou manual, dependências).
- Avaliação dos critérios de saída e relatórios : Avaliação de cobertura especifica casos a serem incluídos, enquanto Aceitação diz respeito ao resultado e Processo diz respeito a execução de todas as atividades. Comparação Requisitos x Log de Teste, produzindo documentos:
- Casos de testes (planejados, executados com sucesso e com fracasso);
- Defeitos identificados (severidade, prioridade, status);
- Solicitações de mudança (aceitas ou não, testadas ou não);
- Custo x Esforço x Tempo (planejado versus realizado);
- Riscos (mitigados e residuais);
- Tempo perdido (com eventos blocantes);
- Resultados nas regressões;
- Atividades de encerramento de teste : Envolve a verificação dos entregáveis, dos relatórios, arquivamento para reutilização dos artefatos e estrutura pela organização, e documentação das lições aprendidas.
Estratégias de testes dos modelos de ciclo de vida
- Ciclo de vida sequencial em cascata (V) : Estratégia de prevenção, baseada na análise dos requisitos. Equipe de testes independente, seguindo a sequência
Definir » Implementar » Testar ao final. - Ciclo de vida iterativo por protótipo : requisitos são enregues no início de cada iteração e a prioridade são riscos de qualidade. Cada incremento significativo da iteração é testado.
- Ciclo de vida incremental em espiral : protótipos são testados, redesenhados e retestados.
Verificação estática e dinâmica.
- Verificações estáticas ocorrem na inspeção de software e podem ser suportadas por ferramentas de análise de código (ex. Travis CI)
- Verificações dinâmicas ocorrem em testes de software. O sistema é executado com dados de teste e seu comportamento operacional é observado.
Vantagens de se realizar os 3 (três) tipos de testes estáticos
- Testes estáticos oferecem uma maneira de melhorar a produtividade e qualidade do desenvolvimento de software, através das ferramentas de análise, revisando e inspecionando suas variações. Podem iniciar muito cedo no ciclo de vida, produzem mais qualidade e reduzem custos com retrabalhos (nas fases finais).
- Inspeção simples : detecção de defeitos na lógica e no código de maneira informal;
- Revisão de apresentação (walkthrough) : Podem ocorrer a qualquer momento mediante planejamento. Líder, relator, autor e membros consideram implementações alternativas, além de avaliar a conformidade com padrões e especificações. Envolve treinamento da equipe e troca de idéias;
Revisão técnica : uma equipe qualificada avalia formalmente o produto quanto a padrões e especificações. Líder, relator, leitor, autor e inspetores mantendo foco na simplicidade, são definidos itens relevantes, aplicados treinamentos e documentados os resultados.
Testes de caixa-preta e testes de caixa-branca (white-box tests)
Testes de caixa preta (black-box) : são baseados em especificação e consideram apenas entradas aceitas pelo componente(função) e saídas esperadas. Visa identificar anomalias de código, interfaces, fontes de dados e performance.
Testes de caixa branca (white-box) testes baseados na estrutura do código que visam garantir que os caminhos independentes sejam executados pelo menos uma vez. Testa as possibilidades de afirmação e negação, as operações em loop e a validade das estruturas de dados.
Testes de unidade garantem que pequenos blocos do sistema cumprem suas funções corretamente, a partir de entradas fornecidas e retornos esperados via asserções, que são métodos específicos nos scripts de estes. O código-fonte em produção é chamado e testado com entrada de dados de teste e asserções.
Testes de integração garantem que o novo código se adequa ao existente. São parte de um processo automatizado no controle de versões onde a cada pull-request as rotas da aplicação são executada s para verificar a presença de erros.
Testes de regressão verificam se as funcionalidades que até então estão funcionando, continuam funcionando corretamente após a implementação das alterações.
Estratégias de modelagem de testes de caixa-preta (black-box tests)
- Testes exaustivos : Exploram n possibilidades de entrada e saída, e demandam muito tempo.
- Testes aleatórios : Entradas dos casos são aleatórias dentro de uma margem. Eficácia considerada baixa. Conhecidos como testes de stress.
- Partição em classes de equivalência : Eleição de um número finito, representante da classe. Intervalo de valores válidos (criação das classes abaixo,na margem e acima dela), conjunto de valores válidos (uma classe com valores aceitos, outra com valores inválidos), valor e característica mandatórios (como validação do primeiro caractére), e elemento distinto (subdivisão da classe).
- Análise dos valores de borda : Consideração de valores dentro da classe, abaixo da fronteira e acima da fronteira.
Existe uma infinidade de frameworks free de testes de todas as tribos e linguagens, que podem agregar integridade, confiabilidade e resiliência ao código, garantindo a satisfação do chefe, dos clientes e nosso tapinha nas costas.
Produzir testes não é perda de tempo. Na verdade, o código que funciona produzido nos testes é transferido para produção, com exceção das asserções e mockups.
Como o Desenvolvimento Ágil trata dos testes
O cliente fornce feedback contínuo, e suas estórias geram funcionalidades. Ocorre a programação em par com testes prévios a implementações (ex: XP, SCRUM). Testes de integração são executados utilizando ferramentas de versionamento e integração contínua e as estórias são entregues como ramificações (branches) no repositório do projeto.
Testes unitários
Ainda há muitas controvérsias sobre Testes unitários, e na prática, a adoção é mínima. Isso porque é muito fácil realizar testes de entrada e saída de funções com dados de teste diretamente no código dos arquivos oficiais do projeto. A parte vantajosa de programar orientado a testes unitários é a diminuição do número de cliques e diminuição do preenchimento manual de entradas.
Ter uma suíte de testes unitários confiável, passa a agregar confiança para criação de novas funcionalidades. Isso porque toda vez que se cria uma nova funcionalidade, cria-se primeiro o seu caso de teste unitário. Na hora da execução, um único comando será capaz de re-testar todos os testes criados anteriormente, para só então começar a processar a nova funcionalidade a ser testada.
A garantia do funcionamento de Features e correção de Bugs está diretamente relacionada à existência de testes de comprovação. Aí entra a função dos TestCases: são registrados casos de falha e teste para o código em produção. O caso de teste “chama” a função em uso atualmente. Através de simples comandos, é possível testar todo o sistema ou casos isolados.
Homologação como ferramenta de teste
O ambiente de homologação é a interface de validação com o cliente. O código do estágio de desenvolvimento é publicado no servidor de produção em um subdomínio (ex: teste.sitedocliente.com.br) após testes técnicos e o acesso é liberado aos clientes, que confirmam a satisfação de seus requisitos. O ambiente de homologação nunca sai de moda, por que possibilita aos próprios stakeholders (partes interessadas do negócio) fornecer feedback sobre retornos inesperados ou mesmo atualizações de seus requisitos – tudo considerando recursos e limitações do ambiente de produção.
Seja certificado em testes
O ISTQB emite certificados válidos internacionalmente, e já credenciou mais de 450 mil profissionais em 100 países. O valor do certificado Foundation Level começa em R$350,00. Verifique as unidades de aplicação mais próximas no site.
Quer saber mais sobre como funciona? Fale com um desenvolvedor agora mesmo!
WhatsAppO conteudo foi útil? Isso é fantástico. Quer incentivar mais posts como esse? Mostre seu apoio com qualquer valor.
Chave PIX: d0311e58-cb6e-4d47-b3d8-3d4254763ce7
