quarta-feira, 19 de fevereiro de 2014

Testes de Regressão: cinco ideias chave



Os testes de regressão são realizados para garantir a correcção de bugs não têm impacto sobre o funcionamento do produto; para isso procuramos novos bugs no software já testado. Por outro lado, é importante executar testes de regressão sempre que se introduzem alterações na Base de Dados ou nos programas, quando se corrigem bugs e quando se muda para uma rede ou sistema operativo diferente.

Seguidamente apresentam-se 5 passos para ajudar à realização sistemática de testes de regressão.

Passo 1

Prever algum tempo para execução de testes. Como o tempo é o primeiro constrangimento de todos os testers, estes devem ser suficientemente experientes para conseguir avaliar todas as áreas do software num curto espaço de tempo.

Passo 2

Corrigir todos os factores envolvidos. Há casos em que, mesmo com os defeitos corrigidos, o produto não funciona como pretendido. Isso geralmente deve-se a uma incapacidade do programador para corrigir os problemas que estão na raiz dos defeitos, corrigindo apenas os problemas secundários. Portanto, é fundamental para identificar todos os factores que provocam o problema e corrigi-los antes dos outros.

Passo 3

Ter cuidado com os bugs corrigidos. Por vezes, quando os programadores corrigem certos bugs, pode acontecer que novos bugs passem despercebidos. Por isso, quando se executam testes de regressão, os testers devem estar cuidadosamente atentos.

Passo 4

Concentre-se em aspectos funcionais. Durante os testes de regressão apenas devem ser considerados os aspectos que afectam a funcionalidade da aplicação. Aspectos estéticos são igualmente importantes; no entanto, na maioria dos casos, não devemos gastar tempo com eles.

Passo 5

Construa o seu conjunto de testes de regressão. Criar esse conjunto é útil para identificar os bugs quando o software é novamente testado.

Siga estas cinco ideias chave para assegurar que não perde nada durante a execução de testes de regressão.

------------------------------

Traduzido e adaptado de: A QuickGuide To Regression Testing



quinta-feira, 13 de fevereiro de 2014

Boeing 787 com problemas de software





Na passada semana um Boeing 787 (Dreamliner) da Air India que voava de Nova Deli (Índia) para Melbourne (Austrália) teve de ser desviado para Kuala Lumpur (Malásia) após ter sido detectado um problema de software.

Um porta-voz da companhia aérea indiana afirmou que uma equipa de especialistas da Boeing se tinha deslocado a Kuala Lumpur, suspeitando-se que a origem do problema estivesse numa actualização de software. Alguns dias antes, um outro Boeing 787, da companhia polaca LOT, cancelou um voo transatlântico após ter sido detectado um problema num dos computadores de bordo.

Estes problemas de software juntam-se a outros problemas técnicos anteriores com as baterias de litium. Recentemente um responsável pela Boeing admitiu que a fiabilidade do Dreamliner tinha subido de 97 % para 98%, mas este indicador ainda não era satisfatório. O mesmo responsável acrescentou que o objectivo da Boeing é que o Dreamliner possa voar com a mesma fiabilidade do Boeing 777: 99,4%.

--------------------------------
Sobre esta notícia:
Boeing admits Dreamliner 98% reliable – must improve

sábado, 7 de dezembro de 2013

Testar com poucos (ou nenhuns) Requisitos

Muitos testers são surpreendidos quando lhes pedem para testar aplicações informáticas sem que existam requisitos claros. Será possível não cair em pânico e sair desta situação de forma segura quando não se tem muita experiência? Muito dificilmente um tester recebe um documento completo e preciso de especificações funcionais. Em muitos casos estão definidos prazos de entregas iniciais, surgem mudanças repentinas de requisitos ou tarefas urgentes, faltam recursos humanos, e existem outros obstáculos que podem complicar o processo de testes. E mais frequentemente também surgem desentendimentos entre especialistas de diferentes áreas que podem ser resolvidos graças à intervenção do tester. Para ultrapassar estas situações, existem algumas dicas que podem ajudar os testers com menor experiência.

Primeiramente é necessário encontrar respostas claras para algumas questões genéricas:
  • Vamos fazer testes unitários e/ou de sistema?
  • Vamos fazer testes funcionais, de performance ou de regressão?
  • Trata-se de um produto novo ou é um projecto de manutenção?
  • Como é que os programadores entendem o sistema?
  • Que outra documentação existe além de especificação funcional?
  • Existe algum analista/especialista de negócio, ou um utilizador final disponível?
  • Há componentes funcionais previamente definidas?
  • Quais são as áreas de risco?
  • Qual o nível de experiência da equipa de testes?
  • Vão ser feitos testes manuais e/ou automáticos?

As respostas às questões anteriores revelarão possíveis formas de pôr em prática o processo de testes.

Quanto ao aspecto organizacional dos testes podemos considerar os seguintes aspectos:
  • Identificar os pontos fortes da equipa de testes.
  • Obter informações sobre as componentes técnicas desenvolvidas.
  • Combinar ou separar módulos consoante o tipo de testes.
  • Distribuir os módulos a testar de acordo com as competências e conhecimentos dos testers.
  • Encorajar a comunicação constante entre a equipa de testes e programadores e analistas.
  • Escolher uma abordagem de testes clara e objectiva, que não seja passível de diferentes leituras, para evitar erros de interpretação.
  • Documentar os passos básicos nos detalhes do processo de teste, se houver pouco tempo disponível.

Com estes princípios em mente, podemos ainda tentar algumas abordagens alternativas para os testes. Podemos realizar testes exploratórios, em que testamos a aplicação de acordo com o nosso próprio método. E podemos fazer testes de aceitação (ou com utilizadores) envolvendo um utilizador desconhecido para perceber como são entendidos os requisitos e as funcionalidades básicas, e compreender a forma como os utilizadores interagem com a nova aplicação. Também se pode pedir aos utilizadores que escrevam pequenas histórias (descrições do negócio) que podem servir de base para o desenho de mais testes.

Em resumo, podemos dizer que, quaisquer que sejam as condições para testar software, devemos sempre pensar cuidadosamente e definir objectivos claros antes de começar.

----------------------
Traduzido e adaptado de: Testing In The Dark: How To Come Out Into The Light (Blog Hunteress)

Outros links sobre este assunto:

terça-feira, 12 de novembro de 2013

Serão os testers "programadores falhados"?

O desenvolvimento de software é um processo de certa forma sinuoso, que envolve a intervenção de diferentes pessoas. A interacção entre diferentes pessoas não promove apenas a aprendizagem colectiva como também ajuda a desenvolver as competências técnicas dos colaboradores. No entanto, uma maior interacção entre colaboradores também aumenta as hipóteses de conflito, algo comum em ambientes de trabalho. Developers e testers são duas classes de colaboradores cuja interacção pode levar a conflitos infindáveis devido a várias razões, tais como a diferenciação das funções profissionais, a experiência profissional e os atributos intelectuais.

A razão mais evidente é a parcialidade histórica em relação aos testers apelidados de cidadãos de segunda e programadores falhados. “Os testers são os licenciados em ciências computacionais que não sabem programar”, este hábito de considerar os testers como colaboradores inferiores é a causa de todo o problema. No entanto, estas considerações pertencem a uma corrente de pensamento ortodoxa e são como estereótipos, sem evidências práticas e suporte factual. Com tanto desenvolvimento e progresso no mundo do QA, a realidade é que os testers têm agora um papel mais exigente e desafiador no processo de desenvolvimento.

Após discutir com developers e testers, descobri que os “developers” foram postos num pedestal e glorificados por si mesmos e pelas chefias. Eles acreditam que o código que desenham está isento de bugs e daí se depreende um problema de ego.

Tomemo-lo desta forma: os developers são os médicos que trazem o bébé (software) à vida, e que os testers são as pessoas que dizem “que bebé tão feio”. Mas não é exactamente isso que os testers tentam fazer. Os testers estão lá para ajudar no parto do bébé e a ajudar para que ele cresça forte. No fim de contas, Desenvolvimento e Testes são dois lados da mesma moeda. Ambos se complementam e é nesse aspecto que ambos os lados necessitam de pôr o ego de lado e colaborar.

Testar é como o retrovisor para o desenvolvimento para que este não se distraia. Visto que os testers são responsáveis pela qualidade do software, estes certificam-se que o software é entregue em boa forma tanto para o utilizador final como para a empresa.

Ao longo dos anos, o papel do profissional dos testes/QA evoluiu para um patamar separado mas igual; os testers têm apenas um conjunto de competências diferentes embora valiosas. É necessária a evolução na cultura de muitas organizações para trabalhar com e tirar partido desta nova ordem demográfica. Para além disso, os testers também deveriam trabalhar não só na identificação de bugs, mas também na correcção de bugs menores. Apenas enviar de voltar os relatórios de bugs para o developer após correr os ciclos de testes e pedir-lhe para corrigir os bugs e repetir o mesmo processo só vai intensificar e agravar a situação.

Assim sendo, é imperativo para ambos trabalharem colectivamente num projecto com união, e não limitarem-se a atirar trabalho para cima do outro.

------------------------------------
Traduzido e adaptado por Pedro Sesinando de: Are Testers failed programmers?