Publicado em

Você sabe a diferença entre Erro, Defeito e Falha !?

Vamos dar uma passada em principios elementares de teste de software, vamos analisar qual é a diferença entre Erro, Defeito e Falha.

O Erro é um engano cometido por uma pessoa, pode ser um erro de lógica cometido durante a codificação por exemplo, entretanto um erro pode acontecer em qualquer fase do desenvolvimento, erros de sintaxe, tratamento de erros, erros de cálculo, erros de interface de usuário e etc.

Na tratativa de um bug sempre devemos buscar a causa raiz para eliminar o problema, precisamos descobrir o erro e eliminá-lo.

O Defeito demonstra desvios que revelam o não atendimento dos requisitos especificados impedindo que o software entregue o resultado planejado, consequência de um erro impetrado de alguma forma no software.

A Falha é a consequência de um defeito, um comportamento incorreto que se manifesta durante a utilização do software, ou seja nem todos os defeitos resultam em falha, se essa parte do código por algum motivo não for executado nunca saberemos dele.

  • Resumindo

Para me conhecer melhor acesse meu site e meu perfil no LinkedIn, fique a vontade para entrar em contato, vamos conversar !!! 

Publicado em

Processo de homologação, como é que é ? (Parte 2/3)

Antes de iniciarmos uma homologação precisamos nos certificar que uma série de coisas tenham sido feitas para que não haja impactos no planejamento previsto com a descoberta de problemas que deveriam ter sido resolvidos nos testes dos times.

Cada time envolvido precisa realizar os testes relacionados ao seu escopo, é recomendável que haja um ambiente aonde os incrementos possam ser integrados e façam conexão com sistemas que compõem a solução como um ERP ou um TMS por exemplo:

  1. Testes unitários;
  2. Testes de regressão;
  3. Testes automatizados;
  4. Testes integrados (quando possível);
  5. Testes de performance;
  6. Testes de segurança;
  7. Testes de carga;
  8. Testes de usabilidade;
Os times precisam garantir a integridade do seu incremento passando por todos os passos necessários conforme a natureza da sua demanda.

Quantos mais testes forem feitos no ambiente integrado (“pré-homolog”) pelos times melhor, deve haver um responsável para organizar as subidas para esse ambiente de forma a garantir sua integridade e disponibilidade, assim todos poderão executar as validações e fazer os ajustes oriundos dos apontamentos que surgirão, não se pode garantir que todos os problemas sejam eliminados porém essa prática garante maior robustez ao incremento do programa para a homologação.

Apesar de exigir grande esforço de organização é de extrema importância que aconteça, caso esses passos não sejam realizados, passamos a atribuição dos testes para os responsáveis pela homologação juntamente com a área de negócio, o que é extremamente contraproducente, vamos parar por aqui, continuamos no próximo post.

Para me conhecer melhor acesse meu site e meu perfil no LinkedIn, fique a vontade para entrar em contato, vamos conversar !!! 

Publicado em

Não faça sprint de QA !!!

Algumas vezes nos deparamos com situações aonde se opta rodar uma sprint separadamente para execução dos testes de QA, essa abordagem deve ser evitada pois gera diversas disfunções causando impactos negativos.

Nesse cenário a definição de pronto não estaria sendo completamente seguida ou seria nula, pois na prática não teria utilidade já que ao final de uma sprint, o trabalho executado não estaria validado.

Não crie dificuldades para o seu time, se organize e faça os testes dentro da Sprint.

Durante os testes, os ajustes e bugs encontrados serão tratados em um momento diferente do ideal o que impactará a produtividade do time seja qual for o procedimento adotado a partir deste ponto.

Haverá dificuldades para o planejamento de releases além da geração de débitos técnicos diminuindo certamente a transparência, faça os testes de QA dentro da sprint, vai ser bem mais legal.

Para me conhecer melhor acesse meu site e meu perfil no LinkedIn, fique a vontade para entrar em contato, vamos conversar !!!