Introduo a Teste de Software O interesse pela atividade de testes de software aumenta medida que a falta destes de testes influenciam

m diretamente no custo final de um software produzido. Com isso, as exigncias por softwares com maior qualidade tm motivado a definio de mtodos e tcnicas para o desenvolvimento de softwares que atinjam os padres de qualidade impostos. Vrios pesquisadores tm investigado os diferentes critrios de teste, buscando obter uma estratgia de teste com baixo custo de aplicao, mas ao mesmo tempo, com grande capacidade em revelar erros. Os testes podem ser automticos ou manuais, e eles podem ser classificados em diversos tipos: teste de caixa-preta (black-box testing), teste de caixa-branca (white-box testing), testes de unidade (Unit Testing), testes de aceitao (Aceptance Testing), testes de integridade, testes de desempenho, testes funcionais, testes de interface, testes estruturais etc. Para os testes manuais, existem muitas tcnicas e padres que devem ser seguidas para garantir uma melhor qualidade dos testes, e para os testes automticos, existem vrias ferramentas que auxiliam na automatizao dos testes. O objetivo deste grupo abordar e interagir com outros usurios sobre suas experincias em aspectos tericos e prticos relacionados atividade de teste de software a fim de melhorar o desenvolvimento dos testes em software. Principais tipos de Testes de Software Os testes de software so uma maneira de garantir a qualidade de um software. Com isso existem diversas maneiras de se testar um sistema, ou seja, existem testes mais baixo nvel e teste mais alto nvel, que podemos classificar em testes de caixa-branca (white-box testing) e os testes de caixa-preta (black-box testing) respectivamente. Os testes de caixa-branca so realizados diretamente no cdigo e geralmente so feitos pelo implementador do sistema, um exemplo deste tipo de teste so os testes de unidade (unit testing). Por outro lado, os testes de caixa-preta so feitos de maneira funcional, onde o testador no tem contado direto com o cdigo do sistema, entende-se o sistema como uma caixa onde ao inserir valores de entrada, retorna valores de sada, geralmente estes testes so realizados por uma equipe especfica de teste, que utiliza a especificao dada pelo cliente para fazer o roteiro de casos de teste. Os testes de caixa-preta mais comuns so o teste funcional e o teste de aceitao, que semelhante ao teste funcional, a diferena que esse teste executado diretamente pelo cliente. H tambm os testes mistos, que tanto so de caixa-branca quanto de caixa-preta, que so os testes de regresso, de integrao e de cobertura. Os testes de regresso devem ser realizados sempre que o sistema sofrer alteraes considerveis que podem gerar bugs, geralmente necessrio re-executar todo o roteiro de teste criado para o teste funcional, desde que o sistema no seja muito grande. H tambm um teste muito importante, que o teste de cobertura, este teste tem a finalidade de verificar se o roteiro de teste executado, tanto nos testes de unidade quanto nos testes funcionais, esto abrangendo 100% do cdigo implementado. H ferramentas que auxiliam na execuo destes testes, como por exemplo, um plugin para o Eclipse IDE, o Emma Coverage. A partir do entendimento mais aprofundado sobre cada tipo de teste, que pode-se obter uma

forma mais prtica e tcnica de testar cada parte do sistema, a fim de garantir uma maior qualidade do software. Os 10 princpios dos Testes de Software Geralmente muitos dos princpios de teste de software parecem ser bvios, mas na verdade conhec-los ajudam bastante no momento de testar, pois criam uma barreira de conscincia no testador, o qual se tornar mais crtico no momento de elaborar os casos de teste e de testar. 1 Princpio: Uma parte importante de um caso de teste uma definio de resultado esperado. Se o resultado esperado no tiver sido pr-definido, ento resultados errados podero ser considerados corretos. Devido ao fenmeno de que "os olhos vem o que eles querem ver". H um desejo no subconsciente de ver o resultado correto. Uma forma de tirar isso fazer uma anlise detalhada de todas sadas em busca de uma ortogrfica perfeita, antes de verificar a sada esperada pelo programa. 2 Princpio: Um programador deve evitar tentar testar seu prprio programa. Geralmente uma pessoa no gosta de encontrar erros no seu prprio trabalho ou programa. Se o programador se equivocou quando fez o cdigo, natural que ele se atrapalhe no momento de testar. Porm, no caso de realizar debugs mais eficiente quando feito pelo prprio programador. 3 Princpio: Os casos de teste no devem ser grandes e exaustivos. Um bom roteiro de testes possui casos de teste que so facilmente executados pelo testador, os quais no so executados de maneira ambgua. Para isso, os casos de teste tm que ser bem escritos e objetivos, como tambm devem possuir o menor nmero de passos. 4 Princpio: Analisar abundantemente os resultados de cada teste. normal pessoas no detectarem certos erros, mesmos quando estes erros podem ser claramente observaods num checklist ou roteiro de teste. 5 Princpio: Casos de teste devem ser escritos com entradas que so invlidas e no esperadas, como tambm com entradas vlidas e esperadas. 6 Princpio: Examinar um programa para ver se ele no faz que proposto, apenas metade da batalha; a outra metade verificar se o programa faz o que no proposto. Este um corolrio para o princpio anterior. Os programas devem ser testados devido a problemas secundrios indesejveis. Por exemplo, um programa de folha de pagamento que faz corretos pagamentos est errado quando produz folha de pagamento para funcionrios que no existem.

7 Princpio: Evite casos de teste descartveis, a menos que o programa seja tambm descartvel. Muitas vezes o testador executa casos de teste aleatoriamente e quando precisa retestar aquele programa tem que gastar tempo novamente criando novos casos de teste. Um problema que geralmente o reteste no to rigoroso quanto o teste original. Assim, se uma nova funcionalidade causar falha, ela provavelmente no ser detectada. Ao armazenar os casos de teste em um documento e re-execut-los novamente a cada iterao conhecido como teste de regresso. 8 Princpio: Nunca faa um teste assumindo que nenhum erro vai ser encontrado. Este um erro que os projetistas de teste geralmente cometem e um sinal do uso incorreto da definio de teste. A definio correta que teste um processo de executar um programa com o intuito de encontrar erros. 9 Princpio: A probabilidade de encontrar mais erros numa seo de um programa proporcional ao nmero de erros j encontrados naquela seo. Apesar de fazer pouco sentido, isto acontece na maioria das vezes. Por exemplo, tem um programa com 2 mdulos, A e B, onde em 'A' foram encontrados 5 erros e em 'B' foi encontrado apenas 1 erro. A probabilidade de encontrar mais erros em 'A' num segundo ciclo de teste maior que a probabilidade de encontrar mais erros em 'B', porque como em 'A' havia mais erros que em 'B', ao corrigir os erros de 'A', h a possibilidade de surgir novos erros. Outra hiptese que os erros vm em aglomerados, ou seja, um erro desencadeia outro, e tambm algumas sees so mais propcias a erros que outras. 10 Princpio: Testar uma tarefa extremamente criativa e intelectualmente desafiante. Provavelmente verdade que a criatividade requerida para testar um programa grande seja maior que a criatividade requerida para criar aquele programa. Sabemos que impossvel tirar 100% dos erros. Existem muitas metodologias para criar casos de teste, mas estas metodologias ainda precisam de muita criatividade. Ento, ao analisar todos os princpio podemos extrair os 3 principais princpios, que so eles: 1. Testar um processo de executar um programa com o intuito de encontrar erros. 2. Um bom caso de teste aquele que tem alta probabilidade de encontrar um erro ainda no descoberto. 3. Um excelente caso de teste aquele que encontra um erro ainda no descoberto. Modelo de Roteiro de Testes
O Roteiro de Teste uma maneira de realizar testes manuais em softwares, como por exemplo, em Testes Funcionais. Este roteiro elaborado a partir dos documentos de especificao de um determinado caso de uso, como: especificao funcional, guia de interface e modelagem do banco de dados. O roteiro de teste tambm conhecido como Projeto de Teste, ele importante no momento da execuo dos testes, pois o testador

consegue realizar uma seqncia de passos de forma prtica, sem a necessidade de consultar todos os documentos de especificao no momento dos testes, podendo ficar focado apenas em executar os testes. Alm do que especificado pelo cliente, o roteiro de testes tambm possui procedimentos que testam a eficincia e a corretude do sistema. Em geral um roteiro de testes composto por um conjunto de Casos de Teste, mas alm dos casos de teste h tambm as sees de Localizao e de Objeto de Teste, descritas a seguir. As sees de Localizao do roteiro de teste servem para definir em qual tela do sistema ser executado um sub conjunto de casos de teste, os quais fazem parte daquela localizao. ALocalizao pode ser escrita da seguinte forma: Tela Consultar Funcionrios > Tela Manter Funcionrios.

Uma Localizao pode conter 1 (um) ou mais Objetos de Teste, onde este pode ser definido como a idia global de um conjunto de Casos de Teste. Por exemplo, na localizao descrita anteriormente, Tela Manter Funcionrios, um possvel Objeto de Teste seria Cadastro de funcionrios no sistema. Outro objeto de teste para esta mesma localizao poderia ser Alterao de funcionrios no sistema. O Objeto de Teste pode conter 1 (um) ou mais Casos de Teste, nos casos de teste onde esto inseridos os procedimentos necessrios para a execuo de um determinado teste no sistema. Um Caso de Teste composto por uma descrio, por uma pr-condio, pelo procedimento e pelo resultado esperado, que ser definido a seguir.

Na descrio est descrita a idia especfica do caso de teste; A pr-condio um requisito para o comportamento do sistema antes da execuo do caso de teste; No procedimento esto os passos para a execuo do caso de teste, este procedimento no deve fugir do foco descrito na descrio do caso de teste;

O resultado esperado descreve como o sistema deveria se comportar aps a execuo do procedimento do caso de teste.

Casos de Teste Fundamentais I

Existem diversos tipos de casos de teste fundamentais que no podem deixar de fazer parte do roteiro, so eles: i. Layout: no incio de cada roteiro de teste, necessrio que sejam feitos casos de teste especficos para o layout de cada tela do sistema. ii. Campos obrigatrios: casos de teste que verificam se os campos obrigatrios esto sendo corretamente tratados. Por exemplo: Verificar se ao deixar um campo obrigatrio em branco se est aparecendo a mensagem. iii. Mscara: Verificar se os campos esto sendo preenchidos com suas respectivas mscaras. Por exemplo: O campo CPF deve ser preenchido com a mscara NNN.NNN.NNN-NN

iv. Valores permitidos: Verificar se os campos esto sendo validados no caso de receberem valores no permitidos. Por exemplo: campos numricos no devem aceitar caracteres especiais e/ou letras. v. Valores nulos: Verificar se um campo que s pode aceitar valor maior que zero, se esto aceitando valor menor ou igual a zero. vi. Valores limite: Verificar qual o valor mximo e mnimo permitido para certo campo. Testar se ao inserir um valor fora do limite se est aparecendo a devida mensagem. vii. Verificao de caracteres especiais: Verificar se os campos de texto esto aceitando caracteres especiais. viii. Validao de campos (Data, CPF, CNPJ): Verificar se foi digitado uma data, CPF ou CNPJ vlido. ix. Eventos do mouse: Realizar testes que copiam textos com o mouse e colam e verificar se estes campos esto sendo validados corretamente. x. Espaos em branco: Num campo obrigatrio, preencher com espaos em branco e verificar se o sistema detectou que o campo estava vazio. xi. Ortografia: Verificar a ortografia de todo e qualquer texto do sistema, inclusive de mensagens de alerta.

Casos de Teste Fundamentais II Alm dos Casos de Teste Fundamentais observados no outro post, podemos identificar outros casos de teste que tambm so imprescindveis para um roteiro de teste de qualidade, so eles:

i. Navegador: os sistemas web geralmente possuem comportamentos diferentes quando so visualizados em diferente navegadores. Com isso importante criar um caso de teste para executar o sistema nos principais navegadores, por exemplo, IE7, IE8, Chrome, Firefox e Safari.

ii. Resoluo do monitor: os sistemas web tambm podem ter exibies diferentes dependendo da resoluo do monitor do usurio. Neste caso, importante que seja criado um caso de teste para verificar o comportamento do sistema nas principais resolues. Ex: 800x600, 1027x768. Existe um site que simula o sistema a ser testado nas diferentes resolues (http://www.webconfs.com/web-page-screen-resolution.php).

iii. Perfil do usurio: H sistemas que possuem diferentes perfis de usurios com diferentes privilgios. Neste caso, importante criar diferentes casos de teste considerando na pr-condio o perfil do usurio. Inclusive deve haver casos de teste considerando que um usurio comum no pode acessar as funcionalidades de um administrador do sistema.

iv. Autenticao: Quando o sistema possui autenticao do usurio, importante criar casos de testes para no permitir que um usurio no autenticado acesse o sistema.

v. Caracteres especiais: importante criar casos de teste que verifiquem o comportamento do sistema quando so inseridos em campos de texto um link ou uma imagem. Pois, se o sistema processar o cdigo HTML inserido, o link pode ser direcionado para um vrus ou para imagem indevida.

vi. Integridade dos dados: Verificar no banco de dados se os valores foram atualizados ou excludos corretamente.

vii. Clique duplo: Ao criar um roteiro de teste para uma tela de cadastro, incluir um caso de teste que verifique o comportamento do sistema quando o usurio clica duas vezes no boto Salvar. Neste caso, o sistema no deve incluir 2 registros.

viii. Tempo de processamento: Verificar o tempo de processamento para carregar uma pgina ou um combo box no ultrapassa o tempo mximo esperado. No caso de listas, pode ser necessrio incluir paginao para melhorar o tempo de processamento.

ix. Dados em uma tabela: Verificar se o texto contido em uma tabela possui alguma ordenao, se o alinhamento dos campos esto de acordo com o padro especificado.

x. Alerta de Confirmao: importante que hajam alertas de confirmao em botes cuja ao de excluir ou cancelar uma operao. Criar casos de teste que verifiquem se ao clicar em 'No', o sistema realmente No Exclui ou No Cancela a operao.

CheckList de Controle de Qualidade

Geral

Verificar ortografia das mensagens e dos campos.

Verificar se campos de radio button excludentes no podem ser marcados ao mesmo tempo. Verificar layout do sistema, tentar manter a aparncia mais parecida possvel com o prottipo. Alm disso deve-se verificar se os campos e tabelas esto alinhados com relao aos outros campos.

Filtro e Pesquisa

Verificar lgica das mensagens. Ex.: Campo de filtro para perodo entre anos ____ a ____ colocar ano _2000_ a _1500_ dever aparecer a mensagem "O ano final deve ser maior que o inicial" e no caso de colocar ano _1500_ a _2000_ a mensagem no deve aparecer.

Fazer combinaes de filtros e verificar se esto sendo listados resultados relativos aos filtros selecionados. Verificar a ordenao das listagem (ver especificao). Verificar a ordenao de campos combo box (ver especificao). Verificar se os campos esto habilitados ou desabilitados conforme a especificao. Ficar atento aos erros de java script. Preencher os campos de texto com caracteres especiais e/ou caracteres invlidos. Se no conseguir preencher com caracteres invlidos via teclado, tentar ctrl+v e cola com o mouse. Verificar se o boto limpar est limpando todos os campos corretamente. Campos de texto deve ser possvel pesquisar com uma substring. Ex.: Para pesquisar um funcionrio com nome Ana Paula Muniz, se eu digitar na consulta a string "Ana" deve aparecer todos os funcionrios que possuam a palavra Ana, como Ana Maria, Luciana, etc.

Verificar na especificao quais campos j devem vir preenchidos.

Cadastro

Preencher os campos de texto com caracteres especiais e/ou caracteres invlidos. Se no conseguir preencher com caracteres invlidos via teclado, tentar ctrl+v e cola com o mouse. Verificar se os campos esto habilitados ou desabilitados conforme a especificao. Ao confirmar a operao de cadastro, verificar se apareceu uma mensagem informando que o item foi cadastrado.

Exibir

No exibir, deve-se ficar muito atento consistncia dos dados, tipo se um dado foi inserido no cadastro ele deve obrigatoriamente aparecer no Exibir com sua respecitiva mscara. Deve-se estar ciente qual o valor que deve ser exibido no caso de um campo no ter sido preenchido. s vezes deve aparecer o campo vazio outras vezes deve aparecer algum caracter. Verificar na tela de exibio se todos os dados alterados foram exibidos corretamente na tela, inclusive ficar atento s mscaras.

Atualizar

Este deve ser o caso de teste mais rigoroso e deve ser feito com mais ateno. Verificar se os campos atualizados foram realmente atualizados. Esta verificao deve ser feita tanto no exibir quanto na tela de alterao. Verificar se na tela de alterao se todos os campos foram carregados corretamente.

Executar o fluxo de alterao mais de uma vez, para garantir que nenhum dado esteja sendo mantido na sesso. Verificar a atualizao de campos que fazem parte de pop-up. Pois muitas vezes as alteraes que so feitas dentro do pop-up se perdem ao fechar a janela. Verificar se os dados cadastrados/atualizados nos pop-up esto corretos. Quando houver uma tabela em que seja possvel inserir e remover dados dela antes de cadastrar, realizar testes de carga para ver se os dados esto sendo mantidos/removidos corretamente. Ao confirmar a operao de atualizao, verificar se apareceu uma mensagem informando que o item foi atualizado. Verificar se ao chamar algum pop-up se ao fechar a janela, o fluxo continua no modo de alterao.

Excluir

Tentar excluir um registro, no alert de confirmao clicar em Cancelar e depois verificar se o registro no foi excludo. Tentar excluir um registro, no alert de confirmao clicar em OK e depois verificar se o registro foi excludo. Realizar uma pesquisar e verificar se a excluso foi realizada realmente. Verificar se apareceu uma mensagem informando que o item foi excludo.

Relatrios

Ficar muito atento aos dados que contm no relatrio, ou seja, ao fazer uma filtragem de dados, devese verificar se apenas aqueles dados selecionados que fazem parte do relatrio. Verificar se o layout do relatrio est idntico ao do prottipo. Verificar a ortografia dos relatrios. Verificar questes de agrupamento das colunas quando h dados repetidos numa mesma coluna, geralmente esta informao est presente no projeto de teste ou especificao.

Boas prticas para elaborar um Roteiro de Testes

estes de software uma rea que vem crescendo bastante na Engenharia de Software, pois diminui custos com a manuteno do sistema e evita aconteam problemas futuros com o sistema, aumentando assim a qualidade do sistema produzido [1].

Os testes de caixa-preta, quando realizados de forma manual, necessitam da elaborao de um roteiro de teste, como pde ser visto no artigo anterior. No entanto, a qualidade destes roteiros de teste a nica garantia de que os testes realizados sero realmente eficientes e que iro detectar o mximo de falhas possveis em um sistema. Com isso tem sido feito um estudo para melhorar a qualidade dos casos de teste. A seguir podemos observar alguns pontos importantes que devem ser levados em considerao no momento da elaborao do roteiro de teste.

Um bom roteiro de testes possui casos de teste que so facilmente executados pelo testador, os quais no so executados de maneira ambgua. Para isso, os casos de teste tm que ser bem escritos e objetivos.

Outro requisito importante para um bom roteiro de teste que os casos de teste sejam eficientes, ou seja, que atinjam a maior cobertura possvel e que encontrem o maior nmero de falhas.

Para se adquirir mais qualidade nos casos de teste necessrio que sejam realizadas reunies entre os projetistas de teste, a fim de identificarem e classificarem os casos de teste mais importantes que devem sempre fazer parte dos roteiros.

Outra prtica importante realizar revises nos roteiros de teste produzidos, com a finalidade de detectar falha de compreenso ou irrelevncia nos casos de teste.

Um bom caso de teste aquele que objetivo, ou seja, aquele que possui em seu procedimento passos referentes a uma nica funcionalidade. Quando o caso de teste objetivo, os testadores conseguem focar melhor na idia principal do teste.

Um caso de teste deve ser tambm auto-suficiente, nele deve estar contida toda a informao necessria para execut-lo, ou seja, deve haver uma descrio bem detalhada sobre a pr-condio do sistema para que o teste seja realizado.

importante evitar casos de teste exaustivos, com um nmero muito grande de passos. Testes grandes e que tomam muito tempo tendem a causar disperso no testador, e assim ele acaba perdendo o foco principal do teste.

Casos de teste que descrevem situaes mais prximas das aes do usurio final so mais eficientes, pois tm mais chances de se encontrar falhas mais graves.

Outra questo importante manter a equipe de teste sempre informada sobre o andamento dos projetos, principalmente a respeito da mudana de requisitos. Pois, toda vez que h uma nova verso do documento de especificao do sistema, tem que haver mudanas no roteiro de teste daquele determinado caso de uso.

Assim, podemos concluir que aplicando boas prticas no momento de elaborar um roteiro de teste possvel obter uma melhoria significativa na execuo do testes, pois os casos de teste se tornam mais coerentes e possuem informaes completas para auxiliar na execuo pelos testadores.

Referncia:

[1] Pressman, R. S. Engenharia de Software. 5 ed., McGraw-Hill, 2002.

[2] Olegpario, P. L, Bandeira, L. R. P. Boas prticas adotadas em um Projeto de Design de Testes Um relato de experincia. Artigo publicado no II EBTS, Recife, 2007.

A importncia dos testes de regresso Os testes de regresso geralmente so executados aps a correo de algum defeito ou aps a adio de uma nova funcionalidade. Seu objetivo garantir que nenhum defeito foi acrescentado ao sistema aps sua modificao. De nada adianta testar um sistema, verificar que ele no possui defeitos para aquele conjunto de casos de teste e aps modificaes no sistema, aqueles casos de teste no serem novamente executados, pois as novas mudanas podem trazer defeitos para o sistema.

Chamamos de teste de regresso, porque temos que testar novamente funcionalidades que j foram testadas antes. Normalmente, este tipo de teste realizado atravs de ferramentas de automao de teste, porque um problema encontrado durante estes testes a falta de tempo para executar novamente casos de teste j executados, logo o teste de regresso deixado para segundo plano. No entanto, esta uma falha grave que as equipes de teste fazem, pois nos testes de regresso geralmente encontramos mais defeitos do que na primeira execuo, isso porque o testador j ter mais familiaridade com o sistema e ao executar novamente aqueles casos de teste possvel perceber outros tipos de defeitos que na primeira execuo passaram-se despercebidos.

Para que os testes de regresso sejam executados em tempo hbil, necessrio que o gerente de testes tenha em mente a necessidade deste tipo de teste, assim ele poder planejar a execuo dos testes de regresso e aumentar o tempo para a atividade de testes. O roteiro de casos de testes de regresso pode ser de trs tipos: Casos de teste que abrangem todas as funcionalidades do sistema. Casos de teste apenas para as funcionalidades que foram modificadas. Novos casos de teste para as funcionalidades que provavelmente foram afetadas pela mudana.

Os testes de regresso uma maneira eficiente de reduzir a quantidade de defeitos que podem ser encontrados em um sistema.

Testes de Regresso Automticos com Selenium Como os testes de regresso geralmente so executados aps a correo de algum defeito ou aps a adio de uma nova funcionalidade. Ento, comum que no sobre muito tempo para realizar os testes de regresso. Neste caso, utilizar alguma ferramenta para re-executar os testes seria ideal para minimizar o tempo para identificar se os defeitos foram corrigidos e tambm se novos defeitos no foram inseridos durante a correo.

Assim, existe algumas ferramentas que viabilizam a automao de testes funcionais para aplicaes Web, por exemplo, Selenium, Watir, BadBoy etc. Estas ferramentas se comportam como um rob que medida que o testador executa os testes pela primeira vez, a ferramenta vai guardando todos os eventos acionados na ferramenta, por exemplo, clicar em um boto, inserir informaes em um campo, etc.

No entanto, apenas ir guardando os eventos no suficiente, pois como um caso de teste possui o campo "Resultado Esperado", ento necessrio indicar para a ferramenta o que esperado aps a execuo de um conjunto de eventos ou aes. As ferramentas que automatizam os testes, a exemplo de Selenium, permitem adicionar assertivas que garantem que o sistema est se comportando conforme esperado em cada execuo.

Exemplo de verificaes presentes na ferramenta Selenium so: 1. verifyTextPresent | login (quando voc quer identificar a presena de algum texto da pgina.) 2. verifyElementPresent | \\div[@id="main"] (quando voc quer identificar a presena de um elemento "html" dentro daquela pgina.)

O verify do tipo "1" nem sempre recomendada, pois em uma futura atualizao da pgina pode acontecer daquele nome "login" ser alterado para "usurio". Neste caso, o teste iria falhar indevidamente. O verify do tipo "2" mais indicado, pois com ele possvel identificar um elemento "html" independente da alterao da ordem ou nome dos campos, pois o teste ser sempre baseado no "id" daquele elemento. A notao utilizada para identificar os elementos pode ser atravs da linguagem XPath(http://www.w3schools.com/xpath/default.asp) ou Expresses Regulares(http://www.regular-expressions.info - bastante utilizada para verificar a mscara de um campo).

Como sugesto de uma ferramenta para automatizar os testes de regresso eu aconselho a ferramenta Selenium IDE, pois ela possui um plugin para o firefox, que auxilia na criao dos casos de teste.

Na tabela abaixo h um exemplo de um caso de teste criado usando a ferramenta Selenium, que contm a validao de um campo e-mail.
EmailInvalido open select select select clickAndWait

/page pessoa_datanascimento_3i pessoa_datanascimento_2i pessoa_datanascimento_1i pessoa_submit //div[@class="span-11 verifyElementPresent colborder"]/h1[contains(text(), "Inscries j Realizadas")] clickAndWait link=Alterar Dados Pessoais clickAndWait link=Editar meus dados pessoais type pessoa_nome type pessoa_identidade click pessoa_sexo_m clickAndWait pessoa_submit clickAndWait link=Editar meu endereo type endereco_logradouro type endereco_cep

label=1 label=Junho label=1998

Roberto Soares 1224564

Rua Campos Bis 12345-678

EmailInvalido type type type clickAndWait verifyTextPresent verifyNotValue type clickAndWait verifyTextPresent

endereco_cidade endereco_bairro endereco_email endereco_submit Email no vlido //*[@id="endereco_email"] endereco_email endereco_submit Email no vlido.

Paulina Almeida Lima oi

regexp:^([a-zA-Z0-9_\-\+\.]+)@(([a-z0-9-]+(\.[az0-9-]+)*(\.[a-z]{2,3}))|(([01]?\d\d?|2[0-4]\d|25[05])\.){3}([01]?\d\d?|25[0-5]|2[0-4]\d))$ email@

Alguns motivos para implantar testes na sua empresa Existem muitos motivos para implantar uma equipe de teste em uma empresa de construo de software. Vrias empresas ainda no esto cientes da importncia dos testes de software. No entanto, a maioria dos processos de desenvolvimento prev atividades de verificao e validao, at mesmo em processos geis. Quando um software entregue para o cliente sem testes, ele pode causar vrios problemas para a empresa que o desenvolveu, alm dos prejuzos para o prprio cliente. Como existem vrios tipos de teste de software, h empresas que preferem adotar os testes de unidade, realizados pelo prprio programador e outras empresas investem em testes funcionais, elaborados e executados por uma equipe de teste especializada. Abaixo esto alguns motivos para implantar testes na sua empresa: 1. Quando um produto no testado, h uma grande chance deste produto possuir erros ou defeitos, assim este produto no vai satisfazer as necessidades o cliente. 2. O cliente quando no est satisfeito com o produto dificilmente ir contratar novamente a empresa. 3. Quando no h qualidade no produto, a empresa fica com imagem negativa, logo necessrio mais investimento em marketing. 4. Se os erros so encontrados pelo cliente, o custo para corrigir estes erros muito maior do que quando o sistema ainda est em desenvolvimento. 5. Quando no h uma equipe para testar o sistema, o gerente exige dos programadores um sistema com qualidade, mas isso difcil, pois nem sempre conseguimos ver os prprios erros cometidos. 6. Com os testes, possvel ter uma maior garantia de que o sistema no possui erros crticos, os quais, quando existem, podem causar grandes prejuzos para o cliente. 7. Com os testes, novos clientes ficaro interessados em seus sistemas devido recomendaes. 8. Com os testes, os programadores, apesar de parecer que no, ficam bem satisfeitos e motivados com os elogios ao sistema feitos pelo cliente, j que ele no encontra muitos bugs. 9. Com os testes, minimiza-se a necessidade de atender telefones para ajudar os usurios a utilizarem o sistema, logo, menor custo com mo-de-obra para helpdesk.

10. Quando h uma equipe de teste para testar o sistema, todos saem ganhando: o dono da empresa (menos gasto com marketing e mais prestgio para a empresa), o cliente (satisfao e confiana no sistema), os usurios (conseguem usar o sistema de forma til e correta), os programadores (motivao por criar sistemas com qualidade) e os testadores (mais empregos). O item 4 um dos pontos mais importantes a ser levado em considerao, pois quando um sistema entregue para o cliente sem ser verificado pela equipe de testes, ele passar para a etapa de 'manuteno' e nesta etapa, geralmente, a equipe que desenvolveu o sistema j alocada para um novo projeto. Como no possvel prever a demanda de correes para o sistema, provvel que haja uma sobrecarga de novas tarefas para os desenvolvedores. Assim, o novo projeto comea a atrasar, pois parte da equipe ter que ser alocada novamente ao projeto antigo. Alm disso, se a equipe que desenvolveu o sistema no trabalhar mais na empresa, ento o custo para corrigir ser ainda maior, pois um programador que nunca viu o sistema ter uma certa dificuldade para corrigir os erros do sistema, logo isso demanda mais tempo e consequentemente mais custo para a empresa. Assim, importante pensar duas vezes antes de decidir no colocar uma equipe de testes na sua empresa para testar todos os sistemas desenvolvidos. Motivos no faltam para criar agora mesmo uma equipe de teste. Se sua empresa j tem uma equipe de teste, esta dever ser bem valorizada, pois talvez o futuro da empresa dependa desta equipe.

Como decidir se os testes devem ser automatizados? Antes de sair utilizando qualquer ferramenta para automatizar seus testes, necessrio analisar vrios fatores que iro definir o sucesso ou no dos seus testes. Algumas ferramentas podem no ser suficientes para representar todos os seus testes, neste caso no faz sentido utiliz-las.

Alm disso, o software a ser testado pode estar em constante atualizao, onde seus componentes so modificados, logo os casos de teste automticos tambm tero que ser alterados, caso contrrio no podero ser re-executados.

A seguir sero apresentados alguns fatores [1] que podem ajudar a decidir se os testes devem ser automatizados ou no.

1. Frequncia da execuo: importante levar em considerao a quantidade de vezes que se pretende executar os testes, se for apenas uma vez, ento a execuo manual pode ser suficiente. 2. Gerao de cdigo reusvel: se o cdigo de teste criado para um caso de teste poder ser facilmente reutilizado em outro caso de teste, ento este pode ser um bom motivo para usar alguma ferramenta de automao.

3. Relevncia do teste: se uma funcionalidade ser utilizada mais vezes do que outras, s

vezes pode valer a pena criar casos de teste automticos para ela, por exemplo, casos de teste para login na aplicao.

4. Esforo para automatizar: deve-se ter em mente se valer a pena o esforo para automatizar um roteiro de teste considerando a quantidade de vezes que aquele roteiro poder ser executado e se h casos de teste reusveis.

5. Ferramentas de automao: para cada tipo de sistema a ser testado poder ser utilizado diferentes ferramentas de automao dos testes. Isto deve ser cuidadosamente analisado antes de decidir qual ferramenta ser utilizada.

6. Dificuldade de executar o teste manualmente: s vezes alguns casos de teste devem ser executados de forma exaustiva para um conjunto de diferentes usurios, neste caso invivel realizar o mesmo teste para vrios usurios. Logo, a automao ser necessria. Assim, estes e outros fatores podem ser considerados no momento de decidir se os testes sero automticos ou manuais. Mas bom sempre lembrar que o principal objetivo de um caso de teste (automtico ou no) encontrar bugs no sistema.

[1] J. C., Oliveira, C. C., Gouveia, R. Q., Filho. A way of Improving Test Automation Cost-Effectiveness. Artigo publicado no CAST'06, Indianpolis, EUA, 2006.

DICA.: A revista Testing Experience deste ms disponvel neste blog na seo de "Revistas Digitais Gratuitas" sobre Ferramentas de Teste de Software, vale a pena dar uma olhada. :) Ferramentas para Testes de Software Todas as ferramentas listadas abaixo so Open Source. Esta lista foi criada a partir de uma pesquisa realizada em grupos de discusso de testes, onde os participantes listaram estas ferramentas como as mais utilizadas nas empresas em que trabalham.

Testes Funcionais em Aplicaes WEB Selenium - http://seleniumhq.org Watir - http://wtr.rubyforge.org BadBoy - http://www.badboy.com.au actiWATE - http://www.actiwate.com Canoo WEBTest - http://WEBtest.canoo.com Apodora - http://www.apodora.org

Testes de Desempenho JMeter - http://jakarta.apache.org/jmeter

Gesto de Casos de Teste TestLink - http://www.teamst.org TestMaster - http://testmaster.sourceforge.net

Gesto de Defeitos Bugzilla - http://www.bugzilla.org Mantis - http://www.mantisbt.org Redmine - http://www.redmine.org Jira - http://www.atlassian.com/software/jira

Verificao, Validao e Teste de Software A qualidade de software adquirida com a aplicao de tcnicas de verificao e validao durante todo o processo de desenvolvimento de um software. So necessrias diversas tcnicas para definir e medir a qualidade do software, como tambm importante verificar a qualidade do processo de teste adotado. Quanto antes for aplicado um processo de teste no ciclo de desenvolvimento de um sistema, menor ser o custo para corrigir os defeitos encontrados. Para isso o ideal que haja um processo de teste independente, porm que seja altamente integrado ao processo de desenvolvimento.

Os casos de teste devem ser criados tomando o cuidado de verificar se todos os requisitos levantados foram abordados, pois sua finalidade garantir que o software est fazendo o que ele deve fazer. As tcnicas de teste de unidade e de cobertura geralmente so utilizadas na fase de codificao. H tambm as tcnicas walk-through, inspees, revises, prova de corretude e simulao. As tcnicas de walk-through e inspees verificam tambm as especificaes a fim de detectar problemas at mesmo na fase de design. Os tipos de teste so divididos em testes de caixa-branca e caixa-preta. Para minimizar o nmero de entradas para os casos de teste, necessrio extrair algumas caractersticas do domnio, as quais iro representar o domnio como um todo, isso pode ser feito com a tcnica de anlise do valor limite.

Para

verificar

qualidade

dos casos

de

teste

criados existem

tcnicas

de anlise

estatstica, anlise de mutao, anlise esttica, anlise de fluxo e anlise dinmica. A tcnica de anlise estatstica utiliza testes de cobertura, que determinam o percentual de abrangncia dos casos de teste ao executar o programa no momento do teste. Na tcnica de mutao so gerados programas mutantes, onde neles so introduzidos diferentes defeitos, com a inteno de verificar se os casos de teste executados conseguem detectar tais falhas previamente conhecidas.

A aplicao de teste de software importante durante todo o desenvolvimento do sistema. No entanto, a prtica de testes nas indstrias de software ainda imatura. Alm disso, as ferramentas que poderiam auxiliar com testes automticos, ainda no esto prontas para determinados tipos de sistemas. Outra problemtica que o custo para garantir que o sistema est de acordo com a especificao muito alto e fica mais alto ainda quanto mais tarde os testes forem realizados. O que impossibilita para uma melhor qualidade do sistema a falta de formalizao das especificaes. Segundo Dijkstra, o teste pode ser usado para mostrar a presena de defeitos, mas nunca para mostrar que eles no existem. Uma coisa importante, quanto mais riscos aquele sistema apresentar para a sociedade, mais tem que se investir na sua qualidade.

Referncias:

[1] ADRION, W. R; BRANSTAD, M. A and CHERNIAVSKY, J. C. Validation, Verification and Testing of Computer Software, published at ACM, p. 159-192, New York, 1982. [2] HAILPERN, B. and SANTHANAM, P. Software debugging, testing, and verification at http://www.research.ibm.com/journal/sj/411/hailpern.html, wrote at 2002, accessed at Mar/08. [3] WIKIPEDIA Software Testing at http://en.wikipedia.org/wiki/Software_testing, accessed at Mar/08. O papel do Testador de Software O testador de software responsvel por atividades dentro do processo de desenvolvimento que garantem a qualidade do sistema que est sendo desenvolvido. A atividade de teste geralmente comea a partir do momento que h um documento de especificao do sistema. Com o documento de especificao possvel realizar tarefas de inspeo da especificao, atravs de um checklist, garantindo que o documento esteja em conformidade.

Em seguida, o processo de elaborao de Roteiros de Teste iniciado, seguido da reviso do roteiro, que realizada por outro membro da equipe. Aps o sistema estar rodando, os testes so executados, manualmente ou automaticamente, onde os resultados so registrados em um Relatrio de Erros indicando se os testes passaram ou no. Este Relatrio de Erros passado para o desenvolvedor do sistema, para que sejam corrigidos os defeitos do sistema. Aps a correo dos defeitos, o Roteiro de Teste novamente executado a fim de verificar se os defeitos foram corrigidos ou se novos defeitos foram adicionados ao sistema.

Quando o sistema passa em todos os testes, ele pode ser enviado para a produo. Nem sempre o Roteiro de Teste cobre 100% das funcionalidades do sistema, por isso existem tcnicas, roteiros e ferramentas que auxiliam na elaborao dos roteiros de teste, quanto maior

a qualidade dos roteiros de teste, maior ser a qualidade do sistema testado.

O testador geralmente tem atividades relacionadas aos testes de caixa-preta, ou seja, testes funcionais, onde o testador no tem acesso ao cdigo do sistema, sendo o desenvolvedor responsvel pelos testes de caixa-branca, que so testes realizados utilizando o cdigo do sistema. Voc um bom testador?