static testing dynamic testing difference between these two important testing techniques
o gateway padrão não está disponível o Windows 10 continua acontecendo
Teste é Verificação e validação . Todos nós sabemos que leva 2 Vs para completar o teste.
No artigo de hoje, vamos lançar alguma luz sobre Teste estático . Também é chamado de Verificação. Vamos aprender tudo sobre isso e dar ênfase especial a isso porque Teste dinâmico freqüentemente recebe a máxima atenção e tem inúmeros artigos detalhando isso.
No entanto, nenhuma discussão sobre o teste estático estaria completa sem uma explicação do que significa seu equivalente, o teste dinâmico. O teste dinâmico é a validação, o outro “V”.
O teste dinâmico é quando você está trabalhando com o sistema real (não algum artefato ou modelo que representa sistema), fornecendo uma entrada, recebendo saída e comparando a saída com o comportamento esperado. É um trabalho prático com o sistema com a intenção de encontrar erros.
Durante esse processo, entenderemos como os dois equívocos comuns a seguir sobre o teste não são verdadeiros:
- O teste é uma atividade que vem no final
- É realizado apenas por testadores e o resto deles não tem nada para fazer
Vamos começar com uma referência rápida ao modelo v :
- No lado esquerdo do modelo V, temos atividades que não são realizadas pela equipe de QA.
- No lado direito , temos alguns deles que são tratados pela equipe de desenvolvimento, alguns pelos testadores e alguns pelos usuários.
Vamos começar com - Levantamento de requisitos . É executado pelo analista de negócios e outro gerenciamento de nível superior - o documento de saída para esta fase é o documento de requisitos de negócios, BRD.
O próximo estágio é o Projeto de sistema . O projeto do sistema é uma fase em que os requisitos de negócios são traduzidos em requisitos funcionais, no FRD (documento de requisitos funcionais).
Quando a tradução estiver acontecendo, a equipe de desenvolvimento (que é o ator principal nesta etapa) irá revisar o documento BRD passo a passo, página por página e linha por linha. Mesmo que o objetivo principal seja consumir os requisitos de negócios por causa da tradução, o documento BRD está sendo revisado por sua vez.
Um exemplo: Digamos que este seja o BRD de um site de banco que é grande em segurança. Há uma seção no BRD que fala sobre as regras de senha para os diversos usuários que criam uma conta no site do banco online. Uma das regras é: Um usuário não pode usar uma senha que ele / ela usa para outras contas.
Isso não é possível. Porque, um site pode apenas sugerir como o usuário deve definir as credenciais de login, mas não há como essa restrição pode ser imposta. Portanto, esse requisito não é viável - ou seja, não pode ser realizado por meio do software.
Vamos agora considerar os seguintes pontos com base neste exemplo:
- Como é determinado que esse requisito não é edificável e, portanto, não pode ser testado (em outras palavras, inviável)? Temos o site do banco e depois definimos o login e a senha - e então percebemos que isso não está sendo possível? Não, estamos simplesmente baseando isso em nossa revisão do BRD e, claro, em algum bom senso comercial.
- Estamos testando esse requisito? Claro, mas com base puramente no sentido teórico e conceitual, mas não no AUT (aplicativo em teste) real.
- Qual é a forma física deste teste? -Uma leitura simples ou uma revisão formal do BRD ou uma análise de viabilidade ainda mais formal dos requisitos do negócio.
Voltando aos nossos equívocos:
- Quem está realizando essa revisão do BRD? - Principalmente a equipe de desenvolvimento e outras equipes técnicas responsáveis pela criação do produto. Não testadores.
- Esta revisão ocorre no final da criação do produto? Não, na fase inicial de desenvolvimento do projeto. Portanto, não apenas o fim.
Técnicas de teste estático:
Para resumir, o teste estático é a parte de verificação do teste de software que segue os métodos de:
- Revisões de documentos
- Passo a passo
- Inspeção
- Análise de viabilidade ou qualquer outra forma de análise para determinar se o software é o que deveria ser ou não
- Revisão de código
Para citar o CSTE CBOK, “A verificação responde à pergunta:“ Construímos o sistema certo? ” enquanto as validações abordam, “Construímos o sistema certo?”
A seguir estão todas as atividades de teste estático que acontecem no lado esquerdo do modelo V.
| Estágio SDLC | Resultado | Verifica | Atores |
|---|---|---|---|
| Coleta de requisitos de negócios | BRD (documento de requisitos de negócios) | Documento de escopo (se houver) | |
| Projeto de requisitos do sistema | FRD (documento de requisitos funcionais) | Revisa / verifica o BRD | Dev, equipes técnicas |
| Projeto de requisitos técnicos | TDD (Documento de Projeto Técnico) | Revisa / verifica o FRD | Dev, equipes técnicas |
| Design (código) | Código | Revisa / verifica o TDD. Revisão do código pela equipe de desenvolvimento quanto à integridade, formato etc. | Dev, equipes técnicas |
Nota: Essas informações podem ser extrapoladas para projetos seguindo quaisquer metodologias de desenvolvimento, pois as etapas serão mais ou menos semelhantes.
No lado direito do modelo V está a validação.
Técnicas de teste dinâmico:
- Teste de Unidade
- Teste de integração
- Teste de Sistema
As fases de Unidade, integração, sistema e UAT tratam da criação de testes a serem executados no AUT durante os vários estágios de seu desenvolvimento. Embora os testes tenham como objetivo validar diferentes tipos de requisitos, são todos testes iguais.
Portanto, qualquer forma de teste em que temos um teste que precisa ser executado em um AUT e sua saída é necessária para determinar o resultado do teste (bem-sucedido ou não) - é a validação.
download de firewall grátis para windows 10
Agora, seria correto generalizar que no lado direito (RHS) do modelo V não há verificação alguma? A resposta é não.
Todos os testes criados em cada estágio no RHS são revisados várias vezes durante o estágio de criação / finalização do teste. O processo detalhado de revisão da documentação de teste está em https://www.softwaretestinghelp.com/test-documentation-reviews/
No RHS:
- Os testes e o código são revisados nos estágios de teste de Unidade / Integração pelos desenvolvedores.
- Os testes de sistema passam por uma revisão por pares durante sua documentação e, após a conclusão, passam por uma revisão pela equipe de desenvolvimento e analista de negócios.
- Os testes do UAT passam por uma revisão pela equipe de QA e também pelos usuários antes do início do UAT.
Conclusão
Concluindo, o teste estático é uma técnica de teste importante que assume a forma de revisão de requisitos de negócios, revisão de requisitos funcionais, revisões de design, revisões de código e revisão de documentação de teste. É uma atividade contínua e não feita apenas por testadores.
A validação, a parte do teste dinâmico, é mais prática e acontece no próprio produto e não em um artefato ou representação do produto. Um processo muito formal de identificação de caso / condição de teste, considerações de cobertura, execução e relatório de defeitos marcam os métodos de teste dinâmicos.
Sobre o autor: Este artigo foi escrito pelo membro da equipe STH Swati S.
Compartilhe seus comentários, perguntas e experiências sobre o tópico de teste estático e dinâmico.
Leitura recomendada
- Diferença entre Desktop, Teste de Servidor Cliente e Teste da Web
- Técnicas de estimativa ágil: uma estimativa verdadeira em um projeto ágil
- Teste da caixa preta: um tutorial aprofundado com exemplos e técnicas
- O que é teste de conformidade (teste de conformidade)?
- Qual é a diferença entre o teste SIT vs. UAT?
- Teste Alfa e Teste Beta (um guia completo)
- Principais diferenças entre o teste de caixa preta e o teste de caixa branca
- As diferenças entre teste de unidade, teste de integração e teste funcional