Embora o bug façam parte do desenvolvimento de software desde que os computadores foram programados, nem todos os bugs são criados iguais.

 A maioria das pessoas pensa que os bugs de software são apenas erros de programação – uma falha ou falha em um programa que produz resultados indesejados ou incorretos – mas isso não é rigorosamente verdade. Há muitas razões para erros de software e eles têm diferentes maneiras de aparecer:

Maneira 1

Primeiro, você tem o caso em que a pessoa que especifica o programa conversa com o cliente, mas o cliente pode não ter pensado exatamente no que deseja. Se simplificarmos a analogia para cores, o cliente diz que quer em azul, mas na verdade ele precisava em verde. O desenvolvedor apresenta o programa em azul, mas o cliente informa que ele o queria em verde!

Maneira 2

Em um segundo cenário, a pessoa que está escrevendo a especificação pode se comunicar incorretamente com o cliente ou pode não ter conversado com o cliente adequadamente para entender o requisito. Em outras palavras, o cliente pode ter dito ‘verde’, mas o que foi ouvido foi ‘azul’, que foi então anotado como parte das especificações. Como resultado, o cliente pensará que o programa finalizado possui um erro, mas na verdade é um erro nas especificações.

Maneira 3

No próximo nível, a pessoa que escreveu a especificação pode se comunicar incorretamente com o programador – o programador implementa exatamente o que ele achava necessário, mas não acertou porque interpretou mal as instruções.

Maneira 4

E finalmente temos um bug real – quando o programador pretendia torná-lo “azul”, mas na verdade digitou “verde” ou de alguma forma colocou “verde” no código.

Portanto, temos quatro estágios diferentes no processo através dos quais ‘bugs’ podem ocorrer. E a dificuldade que temos é que os usuários tendem a pensar que todos os erros são como o último caso!

De fato, os três primeiros exemplos são geralmente chamados de defeitos – ou seja, um desvio dos requisitos. Um defeito não significa necessariamente que há um erro no código (ou seja, devido a erro humano); pode ser uma função que não foi implementada ou não definida nos requisitos do software.

Portanto, quando testamos software sob medida – fornecendo versões iniciais do software para os clientes testarem – o que realmente estamos fazendo é pedir ao cliente que verifique defeitos; para ver se entendemos corretamente seus requisitos e o processo de teste de requisitos.

Nesse estágio inicial, o programa pode parecer complicado e com erros, e muitas vezes não é fácil explicar aos clientes que não estamos procurando um relatório de erro – apenas um aceno para confirmar que o projeto está indo na direção certa.

Aqui na RockApps seguimos procedimento rígidos de controle de qualidade e testes de nossos softwares e a contribuição do cliente é fundamental no projeto.

A RockApps pode auxiliar a sua empresa no desenvolvimento de um sistema ou aplicativo livre de bug e pronto para atender as necessidades de sua empresa.

Entre em contato conosco através dos nossos canais e peça um orçamento conosco! 🙂

Author

Guilherme

Leave a comment

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *