De Dftestes
Autora: Alice Tamashiro
Revisor: Rodrigo Souza
Tabela de conteúdo |
Introdução
Atualmente vivemos em um mundo onde os negócios possuem uma grande dependência pela TI (Tecnologia da Informação) e à medida que esse fator aumenta, também cresce a produção de software e complexidade dos sistemas. Um exemplo é quando um risco operacional da TI se propaga para os negócios, deixando de ser um risco da TI, passando a ser um risco do negócio, ou seja, se uma falha ocorrer nos sistemas, consequentemente ocorrerá uma falha nos negócios. Desta forma, torna-se fundamental o desenvolvimento de software com mais qualidade e confiabilidade. Neste capítulo será abordado o porquê se devem ter profissionais qualificados na elaboração e execução de testes.
Linha de Evolução entre TI e Testes
A tecnologia pode ser identificada em vários momentos da evolução humana, as descobertas de uma época que para a maioria da população eram novidades ou desconhecidas, eram consideradas como tecnologia.
A tecnologia relacionada a informações surgiu em meados dos anos 60 com a criação do Processamento de Dados. [1] O Processamento de Dados era responsável por realizar a execução de atividades burocráticas como geração de relatórios de folhas de pagamento.
Nos anos 70, iniciou-se a era dos Sistemas de Informações onde as informações coletadas e reportadas pelo Processamento de Dados passaram a ser organizadas e refinadas com o auxilio da evolução do meio de armazenamento e processamento destas informações.
Nos anos 80, inseriu-se no contexto tecnológico a era da Inovação e Vantagem Competitiva, nessa época as empresas descobriram que podiam utilizar as informações de forma organizada e refinada com o auxilio da execução das tarefas de escritório e não apenas para agilizar o processo de trabalho, mas também tomar decisões de forma mais rápida e entender melhor os seus clientes. Nessa época também teve uma grande evolução do hardware e das redes de computadores, porém, ainda não havia uma boa integração.
Nos anos 90, com a necessidade constante de obter informações cada vez mais rápidas, distribuídas e com maior integração entre hardware, software, redes, surge a era da Integração e Reestruturação do Negócio, onde passa a ter maior flexibilidade e troca de informações em que as empresas se vêem na necessidade de utilizar cada vez mais sugestões tecnológicas para a tomada de decisão.
Assim como a tecnologia, os testes tiveram evolução ao longo do tempo. Essa evolução se deu devido à necessidade de melhorar a qualidade do software desenvolvido. Iniciou-se nos anos 70 devido ao aumento de informações e complexidade de armazenamento dos dados. No início, os testes de software eram realizados dentro do processo de desenvolvimento pelo próprio desenvolvedor realizando os atualmente chamados Testes Unitários.
A complexidade dos programas de computador dificultava muito a execução dos testes e como consequência os programas eram liberados com inúmeros defeitos. No final de 1979 o Teste de Software foi conceituado por Myers como sendo um processo no qual se executava um programa com a intenção de encontrar erros. [2]
Nos anos 80 e 90, iniciou-se o movimento da melhoria dos Testes de Software, os resultados obtidos foram ótimos e empresas começaram a investir em ferramentas de automação, houve diminuição dos custos de correção dos defeitos, criação de área própria e aderente ao processo de desenvolvimento, as atividades de Testes de Software começaram a iniciar-se paralelamente e integradas com o desenvolvimento.
Hetzel conceituou o Teste de Software como sendo qualquer atividade que tem como objetivo mensurar a qualidade do software e avaliar um atributo de um programa ou sistema. [2]
Em 2002, Graig conceituou o Teste de Software como um processo de ciclo de vida concorrente ao projeto e mantém o testware a fim de medir e melhorar a qualidade de software que está sendo testado. [2]
Contudo, você deve estar se perguntando, porque diante de todo esse avanço da tecnologia e da qualidade de software, ainda ocorrem defeitos? Segundo Rios isso acontece devido: [3]
- As organizações não dão a devida importância à atividade, que é informal, sem metodologia, funções e responsabilidades.
- Em análise do contexto descrito, pode-se dizer que este fato ocorre devido à falta de conhecimento da empresa sobre seu próprio processo de desenvolvimento de software. Em caso de empresas em que a TI é um processo de apoio, não conseguem entender a importância das atividades de teste em conjunto com as atividades de desenvolvimento. Logo, não vêem a necessidade de se ter uma pessoa especialista responsável por esta atividade.
- Os testes são incompletos durante o desenvolvimento, implicando em problemas que ocorrem após sua implantação.
- São incompletos devidos à visão de testes que toda a equipe de desenvolvimento possui (Gerente, Analista, Desenvolvedor e Testador, se existir). Em geral, cada papel citado possui uma preocupação diferente da execução de bons testes (isso deveria ser exceção para Testador). O Gerente de Projetos não quer ter muito custo com testes, os Analistas não procuram especificar de forma mais detalhada o possível para entendimento de qualquer pessoa que leia sua documentação, o Desenvolvedor busca testar o cenário feliz, ou seja, se o que ele desenvolveu está correto e o Testador acaba não possuindo base incentivo e metodologia de trabalho. Cenário que regride aos anos 70. O resultado disso é o alto custo para identificar e corrigir os problemas.
- A abordagem dos testes não foi adequada para as novas tecnologias. Na realidade, pouco esforço foi feito nas organizações para adequar os procedimentos e reciclar o pessoal técnico de testes para tratar novas tecnologias.
- O principal motivador é o custo que terá. Teste é visto como algo que não é caro, que deve ser mais barato que o desenvolvimento.
- A estrutura organizacional para testes não tem se modificado. Quase todos os níveis de testes ainda são feitos pelos desenvolvedores que muitas vezes não gostam de testar o software. Além disso, não possui o perfil de Testador e/ou formalização especializada para executar tal atividade.
- Novamente custo.
- Pouca utilização de ferramentas de automação de testes que são essenciais para certos tipos de testes.
- O investimento em automação é muito maior que o simples investimento em evolução de metodologia e conhecimento. Logo, torna-se algo ainda mais longe de se alcançar.
Concluindo, a TI era considerada armazenadora de informações e atualmente é considerada como ferramenta de extrema importância para a tomada de decisões de negócios. A disciplina de Testes de Software era considerada um meio de encontrar defeitos, atualmente é vista como ferramenta de melhoria e qualidade do software. A disciplina de Testes de Software teve uma grande evolução devido à necessidade de entregar produtos com mais qualidade e de acordo com as necessidades dos usuários que começou a surgir nos anos 70. Porém, as culturas das empresas ainda não se adequaram com a visão Melhoria e Qualidade de Software, considerando muitas vezes a disciplina de Testes como sendo apenas um meio de encontrar defeitos.
Atualmente, as especificações dos sistemas e regras de negócios não são adequadamente descritas e a atividade de Testes de Software é a última etapa no processo de desenvolvimento. Estas duas atividades levam à disponibilização de produtos e soluções que não operam de acordo com o especificado, levando à insatisfação do cliente e/ou usuários finais.
Desta forma, podemos afirmar que a quantidade de problemas encontrados na entrega e implantações de software são ocasionadas muito mais por falta de cultura que existem ainda nas organizações do que falta de evolução da tecnologia e metodologia para dar qualidade.
Mito ou Realidade?
Mesmo com o surgimento de padrões, modelos e metodologias reconhecidas internacionalmente a área de garantia da qualidade vem enfrentando diversos tipos de obstáculos o quais chamamos aqui de mitos, vejam alguns deles:
- Enquanto não tivermos um programa em funcionamento, não será possível avaliarmos a sua qualidade. Isso é um mito! Atualmente temos mecanismos mais efetivos para garantir a qualidade do software, tal mecanismo permite que seja possível aplicar a garantia da qualidade desde o início do projeto. Esse mecanismo é conhecido como revisão técnica formal.
- “Testar é tão fácil, que até a minha mãe testaria!”, será isso verdade? Diante dos exemplos aqui apresentados podemos perceber que isso não é verdade. Além disso, os softwares atuais são muito complexos e possuem contextos diferentes, ou seja, não é possível testarmos um software de missão crítica da mesma forma que um software de comércio eletrônico. Este cenário mostra o quanto é importante ter profissionais qualificados que entendam essas diferenças e saibam aplicá-la de forma que atendam as expectativas do negócio.
- “Não é necessário gastar tempo com testes, pois o programa já foi testado!”, quem já não se deparou com uma frase dessas? Infelizmente, muitos programadores pensam dessa forma e aplicam testes sem critério algum. O intuito não é criticar os programadores e muito menos provar que 100% do que está descrito é verdadeiro, mas sim mostrar que a disciplina de testes de software existe e deve ser aplicada de forma profissional. Isso não significa que o desenvolvedor não deva testar, muito pelo contrário, existem testes específicos que seguem uma técnica que devem ser executados pelo desenvolvedor durante o desenvolvimento, os Testes Unitários.
- “Vamos pensar nos testes, após o desenvolvimento!” O planejamento dos testes é feito tardiamente, ou seja, após a fase de construção. Esta fase é super crítica, pois existe uma enorme pressão para entregar o projeto que muitas vezes pode estar atrasado e com custos elevados. Todos esses fatores comprometem a qualidade do produto a ser entregue ao cliente.
Qual é a realidade da disciplina de Testes de Software? Os mitos se tornaram realidade e a nossa missão é mudar a visão do próprio profissional da área de Testes de Software e das demais áreas.
A seguir será apresentada uma compilação da discussão da primeira mesa redonda (Testar é tão fácil que até minha mãe testaria!) realizada no DFTestes. A discussão contou com 19 participantes, que deram as suas opiniões e compartilharam as suas experiências na área, gerando assim um total de 26 respostas.
Para facilitar a visualização e compreensão foi utilizado o Diagrama de Causa e Efeito, conhecido também como Diagrama de Ishikawa ou Fishbone. Este diagrama tem como objetivo expor as relações de um determinado efeito (conforme figura: Defeito no Software e Qualidade no Software Entregue) e as suas causas potenciais, estas por sua vez possuem um até dois níveis.
Figura 1.02 - Ishikawa - Qualidade no Software Entregue
Cases
A seguir serão apresentados alguns casos reais de problemas que ocorreram recentemente, devido à má qualidade do software, problemas de desempenho e usabilidade. Embora algumas empresas aqui citadas não tenham divulgado a perda financeira que tiveram, podemos concluir que essas falhas causaram prejuízos diretos e indiretos à organização, além de comprometer a imagem da organização e gerar impactos para futuros negócios.
Caso 1 - Fonte IDG NOW, Symantec compensou 50 mil vítimas de atualização com falha na China. Publicada em 25 de junho de 2007 às 09h18
A Symantec distribuiu uma atualização problemática para 50 mil computadores chineses, essa atualização classificou equivocadamente arquivos do sistema como malwares' e os colocou em quarentena, afetando assim o funcionamento do computador, gerando uma onda de protestos na web.
Para compensar os danos a companhia ofereceu uma extensão de 12 meses de licenças do Norton e uma cópia da ferramenta Norton Save & Restore 2.0, para os usuários em geral. Para os clientes corporativos, a empresa ofereceu licenças da Symantec Ghost Solution Suite.
Caso 2 - Fonte IDG NOW, Bolsa de Tóquio fechou mais cedo por pane em TI. Publicada em 18 de janeiro de 2006 às 11h07.
Aumento no volume de transações, resultante de um forte movimento de queda nos valores, levou o sistema da bolsa de Tókio (a segunda maior no mundo em valor de capitalização, depois de Nova York) ao limite de processamento. O índice Nikkei fechou em queda de 3% (15.341 pontos), a maior baixa em um ano.
Caso 3 – Fonte IDG NOW, Site do Submarino apresentou problemas de acessibilidade. Publicada em 25 de novembro de 2008 às 15h39.
O site de comércio eletrônico Submarino apresentou instabilidades, tornando-se inacessível aos internautas.
Os usuários que tentavam acessar a home do site se deparam com uma página incompleta com a seguinte mensagem “Página não encontrada”. Nesta página tinha um link, que às vezes encaminhava para a página correta, outras não.
Concluindo, os problemas citados acima poderiam ser evitados, caso a empresa tivesse adotado um processo formal de garantia da qualidade.
A correta escolha da técnica de testes também é fundamental para o sucesso dos testes, por exemplo:
- 1º caso a aplicação de testes funcionais;
- 2º caso testes de desempenho, carga e volume.
- 3º caso testes de navegabilidade.
Além disso, podemos concluir a partir desses casos apresentados, que um teste mal sucedido pode significar um caminho aberto para outros tipos de problemas.
Conclusão
A disciplina de Testes de Software evoluiu muito durante esses anos, no entanto muitos profissionais da área sentem-se desvalorizados devido à falta de reconhecimento e visibilidade do papel deste profissional na indústria do software. A falta de conhecimento deste papel inicia-se:
- Nas faculdades de TI onde a ênfase é dada mais em linguagens de programação. Somente no último ano (quando tem) o aluno aprende algo sobre a disciplina de Testes de Software.
- Há mais de dez anos que tramitam no Congresso Nacional, diversos projetos que visam à regulamentação da área da TI. Contudo alguns desses projetos referem-se à regulamentação apenas da profissão de Analista de Sistemas, por exemplo [Mayer]. Em alguns desses projetos a disciplina de Testes de Software está inserida como uma atividade do desenvolvedor.
- As empresas preferem contratar desenvolvedores com várias habilidades, inclusive de garantia da qualidade. [4
A visão de um desenvolvedor é diferente de um Testador, geralmente desenvolvedores não gostam de testar e quando fazem não exercitam todas as condições. Já o Testador, tem uma visão mais crítica e detalhista.
Concluindo, a disciplina de Testes de Software é essencial para o desenvolvimento, pois fornece evidências da confiabilidade de produtos e soluções, e garantia do atendimento aos requisitos de negócios. Além disso, não pode ser considerada como qualquer atividade.
<- Voltar para introdução | Ir para o próximo capítulo ->
Referências Bibliográficas
[1] KENN, Peter G. W. Guia Gerencial para a tecnologia da informação: Conceitos essenciais e terminologia para empresas e gerentes. Rio de Janeiro: Campus, 1996.
[2] CRAIG, Rick D.; JASKIEL, Stefan P. Systematic Software Testing. Artech House © 2002
[3] RIOS, Emerson; MOREIRA, Filho. Testes de Software. Rio de Janeiro, Alta Books, 2003.
[4] COMPUTERWORLD/EUA. As seis profissões da área de tecnologia mais valorizadas em 2010. Disponível em
<http://idgnow.uol.com.br/carreira/2009/12/30/as-seis-profissoes-mais-valorizadas-em-2010/>. Acesso em 30/01/2010.
[5] CAMPOS, Fabrício F. Testar é tão fácil, que até minha mãe testaria! Disponível em: <http://qualidadebr.wordpress.com/2009/11/08/testar-e-tao-facil-que-ate-a-minha-mae-testaria/>. Acessado em 30/01/2010.
[6] HETZEL, Bill. The complete Guide to Software Testing. New York, John Wiley & Sons, 1998.
[7] MYERS, G.J. The Art of Software Testing. 2 ed. New Jersey, John Wiley & Sons, 2004.
[8] WIKIPEDIA. Malware. Disponível em <http://pt.wikipedia.org/wiki/Malware>. Acesso em 30/01/2010.
[9] LEMON, Summer. Symantec Compensa 50 mil vítimas de atualização com falhas na China. Disponível em:
<http://idgnow.uol.com.br/seguranca/2007/06/25/idgnoticia.2007-06-25.7174306115/>. Acesso em 30/01/2010
[10] IDG Now!. Bolsa de Tóquio fecha mais cedo por pane em TI. Disponível em: <http://idgnow.uol.com.br/mercado/2006/01/18/idgnoticia.2006-02-06.6752227625/>. Acesso em 30/01/2010.
[11] RODRIGUES, Nando. Site do Submarino apresenta problemas de acessibilidade. Disponível em:
<http://idgnow.uol.com.br/seguranca/2008/11/25/site-do-submarino-esta-com-problemas-de-acessibilidade/>. Acesso em 30/01/2010.
[12] Mayer, Roberto C. Regulamentação das profissões de TI: a quem interessa? Disponível em: <http://www.administradores.com.br/noticias/regulamentacao_das_profissoes_de_ti_a_quem_interessa/20340/>. Acesso em 30/01/2010.