WhatsApp Image 2021-10-25 at 16.30.05

Princípios e comportamentos no teste

Escrito por Carlos Alexandre Figueiredo
 em 26 de outubro de 2021

Hoje entramos no nosso quinto episódio de série de artigos mensais sobre teste de software, e vamos falar sobre a psicologia no teste de software.

Quando atuamos com qualidade de software, precisamos desenvolver alguns comportamentos e pensamentos que nos ajudam a ter mais confiança e assertividade durante o ciclo de vida do produto. Hoje gostaria de conversar com vocês sobre alguns pontos.

O primeiro deles é o objetivo de teste. Muitos imaginam que o teste tem como principal objetivo mostrar que um produto não possui erros e isto é uma forma de pensar bem equivocada. O teste tem como principal característica provar a presença de defeitos, não a ausência deles. Até porque não existe um software que não possui algum erro. Quem desenvolveu foi uma pessoa e pessoas falham. Então é normal ter erros, e a função do teste é impedir o máximo de erros possíveis.

O segundo ponto que gostaria de falar é sobre uma dúvida que muitos têm: quanto de teste é preciso para garantir a qualidade. Para isto, podemos utilizar as técnicas de teste já explicadas nos artigos anteriores. Estas técnicas vão nos guiar para uma quantidade satisfatória para garantir a qualidade. E se você pensou: ah é fácil, testa tudo que está garantido… Seria muito bom se tivéssemos o tempo necessário para testar tudo, mas não temos. Devido aos prazos que temos para realizar a tarefa de teste, é impossível validar todos os possíveis testes que um produto possui; iria demorar anos. Acaba sendo inviável. Vamos supor que você é milionário e resolveu comprar um carro de luxo, daqueles que são fabricados por encomenda. Na sua opinião, seria interessante comprar este carro hoje, mas só receber ele daqui a 20 anos, pois serão executados todos os testes possíveis? Acredito que não faz muito sentido.

Aproveitando que entramos no assunto valores e custo, um outro ponto muito interessante a se falar é quando a atividade de teste deve começar. Bem fácil este, certo? O quanto antes. Quanto mais cedo iniciar o teste, mais barato será para corrigir. Utilizando o mesmo exemplo do carro de luxo, imagina se depois do carro montado e finalizado, descobre-se um defeito pequeno. O motor não está no carro. Neste caso, teria que desmontar o carro quase todo para incluir o motor e depois montar tudo. Isto atrasaria a entrega em mais dias, sem contar todo o custo necessário para arcar com este atraso. No software é da mesma forma – se demorar muito para entrar a tarefa de teste, mais caro será para corrigir este defeito.

Um princípio que utilizo bastante é o princípio de agrupamento de defeitos. Na maioria das vezes, quando encontramos algum erro, existe uma probabilidade muito grande de encontrarmos outro erro. Mas precisamos ter um cuidado com os testes executados. Sempre que executamos o mesmo teste por muito tempo, eu costumo dizer que o teste fica viciado. Mas o que significa isto? Significa que este teste vai fazer o mesmo teste sempre e que a correção atende apenas a este teste. Então existe um risco de não encontrarmos mais erros devido a este “vício”. Portanto é necessário sempre atualizar seus testes.

Outro princípio muito importante é a ausência de erros. Este é mais um indicativo de que precisamos mudar nossos testes. Sempre que executar o teste em alguma aplicação e não encontrar erros, mude os testes. O fato de não encontrar mais erros não significa que não existe o erro. Existe, só não foi localizado ainda.

E por último gostaria de escrever sobre a independência de teste. Qual seria o grau de independência mais indicado para o produto? Para isto, precisamos entender bem qual o contexto em que foi desenvolvido, afinal este também é outro fator determinante para definir quais serão os cenários de teste, quais técnicas devem-se utilizar e principalmente qual o grau de independência. De acordo com o Sylabbus, livro utilizado para uma das certificações de teste, “certo grau de independência muitas vezes representa uma forma eficiente de encontrar defeitos e falhas.” Isto nada mais é do que o grau de confiança que se tem em relação ao quão crítico um teste será dependendo de quem executar os cenários de teste. O nível mais baixo de independência é o teste elaborado pela mesma pessoa que escreveu o código. Não digo que o teste não será bem feito, mas existe a probabilidade de não ser tão rígida quando necessária. Um nível um pouco mais independente seria o teste realizado por uma ou mais pessoas diferentes da pessoa que escreveu o código, mas ainda participante da mesma organização. E o nível mais alto de independência seria o teste que é realizado por pessoa de organizações diferentes da pessoa que escreveu o código do produto. Este profissional será bem mais crítico com as atividades de teste, uma vez que ele não possui vínculo com o desenvolvedor.

Vou finalizando este nosso quinto episódio de artigo referente a teste de software. Grande abraço e nos vemos no próximo artigo.

por Carlos Alexandre Figueiredo Analista de Testes
Menu - DBC Company

Compartilhe

Compartilhar no facebook
Compartilhar no whatsapp
Compartilhar no twitter

Deixe um comentário!

E participe da conversa.

Veja Também

Industry
DBC was practically born in the footwear and iron and steel industries. We have the best solutions for every stage of the...
Financial
We offer solutions to decentralize financial information, expand the final customer`s options when transferring and accessing their information, effective spend control, integration...