Onde é que os Testers podem ir buscar informação?

Com frequência, os testers sentem necessidade de recolher diversas informações que possam completar (ou substituir) as especificações de um projecto. Existem diferentes fontes de informação nas diversas fases de um projecto. Vejamos a que fontes podemos recorrer.

Então, quais as fontes podem ser usadas antes que sejam feitas alterações no código?

1. Especificação. Os testes podem-se basear numa especificação, um ficheiro de texto com uma descrição do que precisa ser testado e os resultados que o sistema deve produzir.
2. Gestor de Projecto. Regra geral, um gestor de projecto define as tarefas dos analistas/programadores. É altamente desejável que essas tarefas sejam replicadas para os testers. Isto permite poupar tempo.
3. Aplicações semelhantes. Podemos usar os produtos dos principais fabricantes de software como padrões. Por exemplo, podemos assumir algumas funcionalidades do interface do MS Office como padrão para as aplicações que correm em ambiente Windows.
4. Conhecer e compreender os use-cases.Compreender e seleccionar as funcionalidades principais e secundárias: Perceber quais as funcionalidades mais importantes para o cliente, ajuda-nos a definir correctamente as prioridades dos teste.Comportamento esperado da aplicação: Saber para que tipo de utilizadores foi criada a aplicação, permite-nos desenhar um interface mais adequado, ou, pelo contrário, identificar as desvantagens da utilização da aplicação.

Quais as fontes que podemos usar após o desenvolvimento da aplicação?

1. Os programadores. Por vezes, os programadores têm dificuldades com a implementação de uma função. Se partilham essa informação com um tester, este será capaz de se concentrar na função “problema” e testá-la mais eficientemente
2. A própria aplicação. Quando falta alguma documentação e ninguém partilha informação, não temos outra escolha que não seja investigar a aplicação.
3. Release notes. As release notes são os comentários sobre cada versão que está a ser testada. As release notes ajudar a determinar a ordem de um teste. É lógico testar primeiramente as partes do programa que foram alteradas na versão mais recente.As release notes também nos ajudam a actualizar a documentação dos testes. Sabendo quais as partes da aplicação que foram alteradas, podemos actualizar os casos de teste de acordo com as alterações, logo após a sua conclusão.

Traduzido e adaptado de Where Can Testers Get Information?

GTAC 2011: The Latest in Google Test Tools

Software Testing as a Career

Lisboa, IBM Oriente - IBM Rational: WorkShop Técnico - IBM Rational Functional Tester & Rational Perfomance Tester

Dia 28 de Maio está agendado um workshop técnico em IBM Rational nas componentes de testes funcionais e de testes de rendimento. 

• http://www.linkedin.com/groups/28-Maio-Lisboa-IBM-Oriente-4106471.S.240227700?qid=aefeb5cc-22a0-4780-b887-37fc320ee195&trk=group_most_recent_rich-0-b-ttl&goback=%2Egmr_4106471

A capacidade está limitada a 16 pessoas com recurso a 8 computadores pessoais.

A agenda será composta por:

Rational Functional Tester:

• Introduce the participants to Rational Functional Tester
• Demonstrate how automated testing can decrease test times and increase coverage
• Use the Functional tester recorder to create new scripts and enhance existing scripts
• Use data-driven wizard to cover multiple scenarios with a single script

Rational Performance Tester:

• Record and enhance automated tests
• Manage data for dynamic tests
• Create schedules to model workloads
• Execute and monitor tests
• Analyze and report on test results

Audiencia:

• Quality&Test Managers
• Application Development Managers

Contacto para inscrição e pre-registo: Rui.Garcia.Santos@pt.ibm.com

Enviar:

• Nome
• Mail 
• Telefone directo

Software error could affect some civilian paychecks

Payroll officials at the Department of Defense say a software glitch is to blame for miscalculated retirement and Social Security deductions in some upcoming civilian paychecks.

The Defense Finance and Accounting Service reported that paychecks for the pay period ending May 4 might be off for some employees due to an error in newly installed software for its Defense Civilian Pay System, according to an email from the Civilian Human Resources Agency.

The error inserted 2012 year-to-date contribution totals for retirement programs like the Thrift Savings Plan and the Roth TSP, as well as Social Security, in place of 2013 numbers, meaning some accounts were shown to have hit their contribution limits early.

Those affected will see lower retirement contributions in paychecks arriving this week or no contributions at all. Their Social Security deduction, or OASDI, could be higher.

-----------------------------
Fonte: Stars and Stripes. Notícia completa aqui.

Cinco Dicas para apanhar bugs!

Cada tester tenta detectar o maior número possível de erros. Dessa forma contribui para proteger a empresa/instituição de prejuízos financeiros adicionais e riscos. Seguidamente descrevem-se cinco dicas que podem ajudar um tester nas suas tarefas.

1. Por vezes é útil para quebrar as regras!

Executar apenas casos de teste pré-definidos pode levar um tester a não detectar erros, deixando-o mais longe de fornecer um produto que seja 100% livre de bugs. Se um tester segue apenas os casos de teste pré-definidos, corre o risco de fechar os olhos para outros erros. O primeiro segredo é verificar a funcionalidade que estamos a testar. Será uma maneira eficaz de descobrir mais bugs porque nem todos os aspectos da funcionalidade estão geralmente cobertos por casos de teste.

2. Examinar os padrões!

A maioria dos testers já percebeu que os bugs podem ser muitas vezes surgir em grupos; são os chamados bugs gregários. Ao testar uma nova – mas semelhante - funcionalidade, devemos analisar as ideias e as decisões anteriores sobre testes anteriores. É também um bom conselho para anotar as suas ideias que já lhe ajudaram na detecção e correcção dos erros.

3. Cercar o Bug!

Não tenha pressa para registar o bug encontrado num qualquer relatório. Isso pode ser apenas o princípio! Um erro pode indicar que o software tem uma “ponta solta”. Enquanto o sistema estiver instável, a sua tarefa testá-lo até ao limite. Alimentando-o com um grande número de dados disparatados, despejando dados em catadupa nos seus inputs, e reduzindo os recursos do sistema, poderá rapidamente permitir detectar antecipadamente a presença de outros bugs.

4. Preste atenção ao seu pressentimento sobre erros!

Antes de se manifestarem os bugs podem anunciar a sua presença! São como insectos cujo som de fundo indica a sua proximidade crescente. Por esse motivo, devemos ter os sentidos alerta para podermos apanhá-los a qualquer momento. Dessa forma, um tester deve ler as mensagens de aviso, logs de erros, etc, que não são exibidos num ecrã por qualquer motivo, mas podem indiciar a presença de bugs.

5. Duas cabeças pensam melhor do que uma!

Apesar de um tester poder ter muitas ideias, no entanto, pode haver situações em que não conseguimos detectar o bug. Este é o momento em que devemos pedir ajuda aos nossos colegas. Testar juntos ao mesmo tempo permite gerar novas ideias sobre os testes. Outra vantagem do teste em grupo é que você trabalha mais intensamente com o sentimento de "estar a ser observado". Mas a colaboração que dura por muito tempo pode levar a visão de túnel.

Existem, portanto, alguns segredos nos ajudam enquanto caçamos bugs. Experimentem-nos e depois, vejam se conseguem detectar ainda mais bugs do que anteriormente.

--------------
Traduzido e adaptado de : 5 Tips On How To Hunt For Bugs Successfully

Testes de Regressão