Desenvolvimento

Ξ 5 comentários

Qualidade de vida de um software

publicado por Alessandra Lima

Figura - Qualidade de vida de um softwareHá um provérbio que diz: “The proof of the pudding is in the eating”, isso se aplica bem à área de software se pensarmos que utilizando de fato a solução desenvolvida é a única prova real de que o que se destina a ser utilizado e realizado está acontecendo conforme o esperado.

Muitos imaginam que a Qualidade de um software pode ser medida de acordo com a felicidade do cliente, o quão satisfeito ele está. Em partes, até que pode ser real. Mas também podemos pensar que a qualidade de uma solução está atrelada ao (1) número de defeitos encontrados após a instalação em um cliente, (2) qual a severidade de cada defeito, porque isso pode impactar na utilização, (3) e o tempo e o custo de correção para cada defeito.

Com problemas encontrados após a instalação, o custo dessas correções e o transtorno gerado acaba sendo um preço muito alto a se pagar. Tanto para quem solicita o serviço quanto para quem executa as correções. Fidelizar um cliente feliz é um bom caminho para conquistar novos. E já que tempo é dinheiro, sabendo utilizá-lo já é um sinal de lucro.

Nos dias atuais, devido à grande concorrência entre as empresas, o projeto tem um tempo curto para ser desenvolvido, porque somos a geração do “agora”. Então tanto para quem constrói a solução, quanto para quem usa, o tempo faz uma grande diferença. Acaba sendo um ciclo de interesses em comum.

Seguindo essa ideia, por mais que metodologias ágeis sejam utilizadas, se no ciclo de vida de desenvolvimento do projeto não houver um plano de testes, essa solução não será bem sucedida.

E então você pode questionar, mas o que colocar nas provas de testes? Seria um teste preencher todos os campos com valores inesperados e salvar? Não preencher nada e salvar? Clicar em todos os botões na página mais de uma vez? Utilizar browser diferente para cada teste? Utilizar banco de dados distinto? Tentar várias combinações? Comparar resultados? Sim! Pode ser tudo isso e muito mais. Será que um ser humano conseguiria fazer o mesmo teste minucioso mais de uma vez? Mesmo em fase final de entrega? Acredito que não existiram testes 100%. Dessa forma, podemos pensar que Testes Automatizados é a solução para vários cenários que precisam ser verificados inúmeras vezes, isso porque o código é modificado várias vezes durante o ciclo de desenvolvimento e, para cada alteração é necessário confirmar que nada que já tenha sido testado, parou de funcionar e você perder mais tempo fazendo a manutenção de um artefato de teste em si do que vendo valor na execução dos testes de regressão.

Seguindo essa idéia, podemos afirmar que Automatizar os testes é uma forma de ser eficiente e pró-ativo para validar um produto. É seguir a dica do provérbio do início do texto.

Teste Automatizado nada mais é do que ter ações pré-definidas para cada cenário a ser testado, quantas vezes necessário for.

Num primeiro momento, a automação pode ser recusada, já que o investimento para criar uma infraestrutura, dar treinamento e manter a automação é alto. Afinal profissionais que trabalham com testes, em grande parte, tem mais experiência em testes num modelo antigo, onde não havia investimentos para focar em automação e nas tecnologias que tornam a automação possível. Hoje em dia, precisariam ser treinados para desenvolver um Framework de Teste, onde seria possível codificar um Caso de Teste, em uma linguagem JAVA ou outra utilizada pela empresa – lembrando que nem todos os tipos de testes estão eleitos a serem automatizados.

Após isso, o custo desse ambiente será mais baixo do que manter uma pessoa testando manualmente e o risco de não ter testado todos os cenários cairá drasticamente. Além disso, se o Framework desse ambiente de Automação for criado com base em Programação Orientada a Objeto, esse mesmo design poderá ser reutilizado em outros projetos.

E, então você pode pensar: “por que ter uma pessoa de teste se posso automatizar?” Porque a pessoa de teste pode dedicar o tempo para executar testes que agreguem valores ao projeto como testes de usabilidade, acessibilidade, performance, segurança e testes exploratórios.

Teste Automatizado é a melhor maneira de aumentar a eficácia, eficiência e cobertura do seu teste de software. E, uma forma de converter esse tempo investido no desenvolvimento de um ambiente automatizado em cifras e reconhecimento com o passar do tempo.

  •  
  •  
  •  
  •  
  •  
  •  
  •  

Compare preços de Uber, 99 e Taxi

Minimum Way

Autor

Alessandra Lima é Bacharel em Sistemas de Informação pela UNISA e pós-graduada em Tecnologia da Informação pela Universidade Federal de São Paulo, atua há mais de 15 anos no mercado de tecnologia da informação, registrando passagem em empresas de consultoria, hospital, banco e multinacional. Trabalha como desenvolvedora JAVA na IBM e, ministra aulas na Faculdade SENAC, onde é docente para as disciplinas de Lógica de Programação e Projeto Integrador.

Alessandra Lima

Comentários

5 Comments

  • Concordo com a publicação. Fazer testes talvez seja mais difícil do que desenvolver, existem várias possibilidades e talvez não testamos todas elas. Perdemos muito tempo fazendo testes para no final ainda correr o risco de ter falhas.

    • Olá, William!
      Concordo com você em partes. Acredito que cada lado, tanto desenvolvimento quanto teste, tem os seus lados “complexos”. Quando você diz “perdemos muito tempo fazendo testes”, na verdade vejo como “investimos tempo”, para evitar falhas/erros maiores e, isso prejudique o dia/rotina de um cliente.
      Um software 100%, acredito que não existe, afinal é feito por humanos e, humanos falham. 🙂
      Obrigada por deixar seu comentário aqui 🙂

  • Acho interessante e acessível a questão de automatizar processos de testes de um software, porém quando tratamos de usabilidade, acessibilidade e performance é somente o usuário quem consegue definir esses pontos. Acredito que nessa do “somos a geração do ‘agora'” perdemos costumes que de certa forma, não deixam de ser importantes, até mesmo para área de TI.

    • Olá, Douglas!
      Esse é o ponto. A Automatização de Testes não consegue testar esse tipo de cenário: acessibilidade, usabilidade, performance. No meu entendimento, o foco da automatização é outro. O desafio da automação é repetir testes que podem ocorrer falhas humanas. E, não substituir uma pessoa da área de teste.

      Um outro ponto a ressaltar é que a automação envolve testes de caixa-preta ou caixa-branca, em que há pleno conhecimento da estrutura interna. Para os dois casos, a cobertura de teste é determinada respectivamente pela experiência do profissional envolvido. Além disso, a automação de teste também auxilia na fase de teste de regressão.

      Obrigada por deixar seu comentário aqui 🙂

  • Boa tarde, ótimo post, muito bem elaborado sob o ponto de vista de um projeto.
    Penso, que o teste de software tem que ser pensado e idealizado como ponto de estrategia no projeto, visto que a falta dele em um projeto acarreta em custos altos e retrabalho, mas também se não houver estrutura que atenda de forma estratégica o projeto deixará de importante no projeto.

You must be logged in to post a comment.

Busca

Patrocínio

Publicidade




Siga-nos!

Newsletter: Inscreva-se

Para se inscrever em nossa newsletter preencha o formulário.

Artigos Recentes