Day in the life of a Software Development Engineer in Test at Microsoft Ireland

Tipos de Testers

Traduzido e adaptado por João Fialho.

Comportamento: Mede qualidade, fala de qualidade, impõe qualidade, pune aqueles que não têm qualidade
"Inimigos" favoritos: Gestores de Projecto, Programadores e por vezes outros Testers
Frase preferida: Qualidade, Qualidade e Qualidade
Notas: Apenas focados em qualidade. Perfeccionista. Designados por polícias da qualidade. Exigem qualidade em todas as fases dos projectos. Este perfil vive, respire e dorme a pensar em qualidade.

Comportamento: Quando encontra um erro entra em pânico, esbraceja, grita e deita lágrimas de horror
"Inimigos" favoritos: Developers
Frase preferida: “Não dá, não dá, não dá! Não funciona!”
Notas: Atitude exagerada quando encontra algum bug, seja um bug com pouca ou muita criticidade.

Comportamento: Ri-se, brinca, atira piadas e diverte-se com o seu trabalho
"Inimigos" favoritos: Test Team Leaders
Frase preferida: “Sabes o que era capaz de ser giro?”
Notas: Trabalha para fazer um bom trabalho mas também para se divertir com aquilo que está a fazer. Após horas de trabalho, este perfil consegue manter a boa disposição e mandar uma boa piada.
Cria dados de teste engraçados.
A sua maneira de ser, pode transparecer para outras áreas alguma falta de rigor ou de qualidade.

Comportamento: Encontra bugs de forma instantânea, está no lugar certo à hora certa
"Inimigos" favoritos: Gestores de Projecto, Developers e outros Testers
Frase preferida: “Eu não vou à procura de bugs, eles é que me encontram”
Notas: Assim que começam a testar uma aplicação que já foi testada, encontram bugs imediatamente.
Assim que eles mexem em alguma coisa encontram logo problemas.
Todos os testers, em algum momento ou em algum projecto, usufruem desta magia.
Poucos testers conseguem ter esta capacidade permanentemente.

Comportamento: Ao encontrar bugs dá murros na mesa, pontapés na cadeira, grita e revolta-se.
"Inimigos" favoritos: Developers e Gestores de Projeto
Frase preferida: “I'm gonna put my fist through it”
Notas: Má atitude quando encontra bugs. Pior ainda quando é obrigado a registá-lo ou a verificar que a correcção não resolveu o problema.
Detesta programadores gestores de projecto e utilizadores finais.
Dá um murro na mesa quando ouve os programadores a perguntar “Isto é realmente um bug?”.

Comportamento: Para encontrar bugs explora todos os caminhos possíveis, normalmente usa phones, toma montes de notas e efectua testes pouco usuais.
"Inimigos" favoritos: Tester com o perfil “The Checklister”
Frase preferida: “Este teste parece-me interessante”
Notas: Exploram a aplicação à procura de cenários interessantes e reagem à medida que vão sendo devolvidas informações pelo sistema, alterando os seus casos de teste originais.
A capacidade inventiva que colocam na identificação dos bugs encontrados, originam bugs dificeis de identificar e de corrigir.
Este perfil testa qualquer coisa em qualquer estado, não estando limitado a nenhuma checklist.
Atribuem pouca importância aos casos de testes pré-definidos.

Comportamento: Verifica e valida constantemente, sejam bugs, correções ou regressão.
"Inimigos" favoritos: Tester com o perfil “The Explorer”
Frase preferida: “Mas no caso de teste não diz para validarmos isso”
Notas: Perfil com dois extremos.
Por um lado temos o tester inexperiente que apenas executa tarefas pré-definidas de forma robotizada, não colocando em causa nem os testes nem a aplicação. (esta é a visão que leva as pessoas a acreditar que todos os testes podem e devem ser automatizados).
Por outro lado temos o tester que utiliza checklist’s para efectuarem validações específicas e essenciais numa determinada fase do projeto.
Utiliza checklists para armazenar informações e recolher métricas.
A sua “Praia” são os testes de regressão.

Comportamento: Ri-se bastante, conversa muito, aprecia o seu trabalho e diverte-se com ele.
"Inimigos" favoritos: Praticamente não tem “inimigos”
Frase preferida: “Vamos fumar um cigarro e falar sobre isso”
Notas: Todas as equipas devem ter um.
Não gosta de monotonia nem de rotinas.
Organizam eventos e são bons a quebrar o gelo entre as equipas.
É sem dúvida o Manager dos coffee breaks e dos jantares de equipa.
Por vezes, precisa de um abanão para não se deixar entusiamar em demasia com as actividades extra laborais.

Comportamento: Tudo é automatização e automatizável
"Inimigos" favoritos: Manual Testers
Frase preferida: “Eu não posso efectuar essa tarefa utilizando esta ferramenta?”
Notas: Vivem para automatizar e automatizam tudo.
Falam com um programador e agem como um tester.
Este perfil normalmente sabe um pouco de tudo, usando um leque alargado de ferramentas, tem habilidade natural para construir código aliada a uma compreensão orientada aos testes.
Quando está restringido a apenas uma ferramenta, perdem a chama que poderiam ter, uma vez que estão limitados à resolução de um conjunto restrito de problemas.

Comportamento: Incialmente está um pouco confuso sobre o que deve realmente fazer um Tester
"Inimigos" favoritos: Testers séniores
Frase preferida: “Não percebo nada de testes, estou apenas a dar uma ajuda”
Notas: Um Drafter é normalmente alguém de outra equipa que integra a equipa de testes.
Por vezes, as equipas de gestão inserem estes elementos em equipas de testes porque pensam que todos podem efectuar testes de software. Outras vezes são inseridos apenas para ajudar.
Alguns deles têm a tendência a continuar a desempenhar funções de tester ao longo da sua carreira e percebem que tem essa aptidão.
Normalmente a aquisição de novos testers é feita através desta experiência.
A partir do momento em que o Drafter começa a defender como requisito fundamental do seu trabalho a qualidade de um sistema, e começa a levantar questões difíceis de resolver, passa a ser assumidamente um Tester.

------------------------------------
Texto original: Tester Types ( Rob Lambert)

Aumentar a eficiência dos Testes de Regressão

Os testes de regressão são essenciais, pois visam encontrar falhas no software após alterações de código, mudanças de ambiente ou apoio à finalização (release) de um produto.

Com os testes de regressão também se pretende garantir a confiança do utilizador de que a nova versão do produto é melhor do que a anterior. Embora muitas empresas ainda ignorem a sua necessidade e deixem de executar testes após a finalização do produto, esta fase de testes não deve ser menosprezada.

Seguem-se cinco formas possíveis para executar testes de regressão sobre um produto de software.

1. Executar todos os testes existentes

Isto significa que todos os Casos de Teste desenhados e executados anteriormente devem ser executados após a finalização do produto. No entanto, se todos estes são manuais, os testers vão ter um enorme volume de trabalho. Provavelmente, não existem tempo nem recursos disponíveis para isso. Na maioria dos casos, é impossível realizar 100% dos testes planeados.

2. Executar testes de alto risco

Neste método, devemos ter em consideração os testes que apresentam o maior valor para os utilizadores e para o negócio. A maioria destes testes foca-se nas funcionalidades e as actividades mais frequentes dos utilizadores e do negócio. Não é exagero afirmar que com mudanças no produto, os processos-chave do negócio também podem mudar. Sugerimos que se atribua 30-40% do tempo total de regressão para os testes de risco elevado (dependendo de outras coisas que devem ser testadas).

3. Testar funcionalidades mais propensas a bugs

As funcionalidades mais complexas são aquelas onde é mais provável que se encontre maior quantidade de bugs.

Geralmente a complexidade inclui cálculos complicados e integração de diversas aplicações. As funcionalidades que têm um registo histórico de muitos defeitos também devem ser classificadas neste grupo.

4. Testes Exploratórios

Neste tipo de testes vamos desenhando o Caso de Teste à medida que o vamos executando. No decorrer da construção e execução de testes exploratórios podemos identificar problemas que nos levam a executar outros testes.

5. Automatização de Testes

Podemos reduzir a quantidade de testes a executar manualmente se recorrermos à automatização. Para a execução rápida, devemos usar ferramentas que reduzam significativamente o tempo de execução dos testes. No entanto, é importante prever algum tempo para o desenvolvimento de scripts de automatização. Também devemos ter presente que se houver mudanças no ambiente é muito provável que esses scripts precisem de ser actualizados.

Estes 5 métodos podem ser usados na execução de testes de regressão de forma a garantir a qualidade do software a entregar.

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

Traduzido e adaptado de: EnsuringEffective Regression Testing In 5 Ways

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

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:

After Boeing 787 Is Diverted, Air India Looks Into Software Problem

Air India diverts Boeing 787 after software problem

Avião da Boeing tem novafalha e voo transatlântico é cancelado

Boeing admits Dreamliner 98% reliable – must improve

James Bach on Software Testing

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:

• Software Testing without Requirements: Survival Guide
• How To Test With Little To No Requirements
• Testing Without Requirements
• Testing Without Requirements or Specifications 
• Testing Without Requirements