|
||
|
|
» Início » Desenvolvimento » Desenvolv de Software » Qualidade de Software - Tipos de testes em software, parte 1
|
|
Avaliação:
![]() ![]() ![]() ![]() | Publicado em: 28/03/2007Qualidade de Software - Tipos de testes em software, parte 1
Alex Estevam Alex Estevam, 25 anos, se graduou como tecnólogo em webdesign pela UNIP e é pós-graduado em TI na mesma instituição.
Geek declarado, sempre amou o mundo dos bits and bytes começando a carreira em Informática como estagiário da FEI em São Bernardo - SP onde reside, aos 14 anos.
Atualmente trabalha como Analista de Testes de Software em uma grande multinacional onde já está há mais de 2 anos adquirindo uma sólida experiência em qualidade de software.
Pretende seguir carreira nesta área e estudar disciplinas que permeiam este tipo de trabalho, contribuindo assim para a qualidade dos artigos publicados no Plugmasters.
Testar aplicações implica em subdividir os testes em algumas categorias para que se possa abordar os sistemas de maneiras diferentes. Assim, cercando-se todos os lados fica difícil deixar escapar algum 'bug'.
A diferença básica entre teste funcional e estrutural é justamente essa perspectiva e o objeto focado - o teste funcional foca no comportamento externo do sistema testado, agindo como o que engenheiros de software costumam chamar de teste black box, explico - semelhante à caixa preta de um avião, ninguém sabe o que rola ali dentro, até abrí-la. No nosso caso, não abrimos a caixa, ou seja, não vemos o código-fonte pra saber se um esperado erro é ou não um problema de programação ou uma lógica estruturada de dados incorreta. Já o teste estrutural nos permite focar no funcionamento interno, o que exige um bom conhecimento de lógica de programação e um aprendizado relativamente profundo da linguagem de programação utilizada no caso, já que é difícil programar, imagina você olhando um código tentando fazer a reengenharia dele pra saber o que deu erro? A partir daí, os engenheiros de software resolveram adotar este tipo de teste como white box ou caixa-branca. E como saber qual teste é necessário para o sistema em questão? Tudo depende do foco do software e do que os gerentes de projeto ou mesmo qualquer parceiro envolvido necessitam. Fatores como; se o sistema é visto em partes, com diferentes linguagens aplicadas ou se tudo é integrado e apenas uma linguagem foi adotada ajudam (ou atrapalham), a decidir qual tipo de teste integrar. Um fator fundamental também é se a equipe de Beta Testers têm o conhecimento suficiente pra realizar um tipo de teste estrutural. Na realidade brasileira, grande parte das empresas ainda utilizam os próprios desenvolvedores para testarem os próprios softwares. Então, podemos talvez afirmar que a maior parte dos testes realizados por aí afora são white box. Assim como em tudo, existem vantagens e desvantagens. A primeira é que dificilmente o programador acha o próprio erro; devido a fator tempo, preocupação em terminar a codificação e também porque principalmente o desenvolvedor, envolto em seu raciocínio no momento do desenvolvimento, simplesmente julgará certos comportamentos da aplicação como sendo corretos, sendo que às vezes podem não ser. É o famoso "Not A Bug" - frase predileta de muito desenvolvedor. Outra desvantagem que vejo nisso é que faltará uma abordagem, de preferência documentada, do teste funcional, em que um QA ou Beta Tester pode, de acordo com especificações, prever o comportamento funcional da aplicação e assim pegar erros onde um teste estrutural jamais poderia pegar. Enfim, parece mesmo que testar não é uma simples tarefa pra qualquer um. Desde o teste da simples aplicação até um complexo sistema integrado web-based. Há muito o que fazer! Artigos relacionados
Este artigo é a parte 2 de 3 da seguinte série:
Ilton <j.ilton@gmail.com>
Parabéns Alex, estou fazendo uma monografia para conclusão da pós em Engenharia de software a mesma sobre qualidade de software e lendo seu artigo esta enriquecendo muito os meus conhecimentos, gostaria de citar nessa 1 parte sobre outro artigo que li sobre os desenvolvedores serem um tipo de Test Infected, como eles lidam com esse "not bug". Cristiano citou em seu artigo que Kent Beck, criador e disseminador do Extreme Programming, quando o programador atinge o nível de adorar o processo de escrever testes, significa que o programador tornou-se Test Infected. Obrigado!
link do artigo:http://www.linhadecodigo.com.br/artigos.asp?id_ac=991 ![]() ![]() ![]() ![]() ![]() ![]() |
|
|