quinta-feira, 29 de maio de 2014

A vida bipolar de um software tester

Isto é uma chatice. Estive todo o dia a fazer testes e ainda não encontrei um único problema.

Não, espera...

Isto é bom, certo? O objectivo é termos software limpo. Tudo bem, porreiro, vamos a isto! Parece que vamos conseguir pôr isto em produção amanhã de manhã... Só mais um teste ... Porra!!! Encontrei um bug! Odeio encontrar bugs na recta final! Isto é uma treta.

Não, espera...

Isto é bom, certo? É melhor apanhar os bugs hoje em QA do que amanhã em produção . É para isso que me pagam. Ui… aqui está outro bug! E mais outro! Cá vamos nós... Acabei de encontrar a mãe de todos os bugs. Isto é incrível!

Não, espera...

Isto é mau, certo? Ou fazemos um esforço e trabalhamos até mais tarde ou adiamos a entrada em produção de amanhã. Devia ter encontrado estes problemas mais cedo, teria sido muito mais fácil… Que porcaria!

Mas o que é isto? Estão a rejeitar os meus bugs??? A sério??? Que humilhação! Odeio quando os meus bugs são rejeitados!

Não, espera... Isto é bom, certo? É porreiro que os meus bugs sejam rejeitados. Menos confusão. Agora não tenho que testar tudo novamente.

Não, espera... Eu quero testar tudo outra vez.

Não, espera... talvez não queira.

Ahhhhhhh!

-----------------------------------------
Texto original em ingles: The Bipolar Life of a Software Tester


segunda-feira, 26 de maio de 2014

Bug no Software interrompe contagem de votos electrónicos na Bélgica

Um bug numa aplicação de votação electrónica levou à suspensão da divulgação de resultados eleitorais na Bélgica, anunciou hoje o Ministério do Interior Belga. No Domingo realizaram-se eleições europeias, federais e regionais e registaram-se problemas nas contagens de votos feitos em aparelhos antigos existentes em 20 dos 209 cantões belgas.

O bug no software provocou resultados incoerentes quando tentou somar os resultados os votos preferenciais dessas máquinas. A aplicação soma os resultados de diferentes formas mas deve obter sempre o mesmo resultado. Mas desta vez não foi isso que aconteceu. E, consequentemente, a contagem de votos foi imediatamente interrompida.

Este bug surgiu apesar do software ter sido especialmente desenvolvido para actos eleitorais e ter sido "testado milhares de vezes", tendo mesmo sido certificada pela PriceWaterhouseCoopers, declarou Peter Grouwels, o porta-voz do Ministério do Interior.

A meio da noite a empresa Stesud que criou o software apresentou uma solução para o problema e as contagens de votos foram retomadas.

As máquinas problemáticas (PC’s x86 da era DOS) são de dois tipos e têm sido usadas na Flandres (região flamenga). Desde 2012, alguns cantões passaram a usar um sistema de voto electrónico baseado em Linux, desenvolvido pela empresa venezuelana Smartmatic. Na Valónia (região francófona) 80% dos municípios usam o sistema tradicional com caneta e papel.

Kommer Kleijn, porta-voz da VoorEVA.be, uma organização belga que rejeita o sistema de voto electrónico porque "priva os eleitores de verificar eficazmente as eleições em que participam" descreveu os problemas como "uma catástrofe".

"Eles afirmam que a gravação dos votos foi feita na perfeição; mas quem pode confirmar isso? Nós não podemos", disse Kleijn. "Não há nenhuma maneira de provar que o bug só estava presente na aplicação usada para somar os votos e não em outras partes do sistema de votação", acrescentou.

Não é a primeira vez votando com este sistema dá problemas. "Sempre que este sistema foi utilizado, houve problemas comparáveis a este" lembrou Kleijn.

Segundo um estudo realizado por sete universidades belgas, em 2003, na cidade de Schaarbeek, por exemplo, as máquinas de voto contaram 4096 votos a mais do que eleitores registados. E, em Liège, em 2006, alguns candidatos obtiveram um resultado parcial superior ao seu resultado final, disse Kleijn.

A Bélgica é um dos poucos países europeus que ainda utilizam sistemas de voto eletrónico. Na Alemanha, o Tribunal Constitucional Federal proibiu o uso de urnas electrónicas em 2009, pois os resultados das máquinas não eram verificáveis. A Holanda proibiu a prática em 2008, após um grupo de activistas ter conseguido demonstrar que os resultados dos dois tipos de urnas electrónicas em uso podiam ser adulterados.

Em França há ainda alguns municípios que usam urnas electrónicas. E na Estónia é usado um sistema de voto electrónico via Internet que foi considerado vulnerável a vários ataques por diversos especialistas que desaconselharam o seu uso nas eleições europeias.

---------------------------------------------
A LER:
Software bug disrupts e-vote count in Belgian election (PC World)
Couac informatique, la diffusion de certains résultats en suspens (Le Soir)
Enormes bugs informatiques dans le dépouillement des elections (La Libre)

sexta-feira, 16 de maio de 2014

Cinco sinais de um Tester pouco profissional

Recentemente, tem havido muitos debates sobre o nível de profissionalismo dos testers.

Algumas pessoas argumentam que não existem testers profissionais porque a própria profissão não é formalmente especificada ou ensinada nas universidades; outros pensam que não há profissionais nesta indústria, pois esta ainda é relativamente nova. Mas por outro lado, todos consideramos natural procurar indicadores de profissionalismo na atitude das pessoas nas suas actividades e trabalho nos esforços que fazem para evoluir e aperfeiçoarem-se.

Aqui ficam alguns sinais de pouco profissionalismo nos testers:

1. Você acha que não precisa de ler o código. Porque lidamos com desenvolvimento de software, devemos saber algo sobre a sua engenharia. Podemos não ser saber escrever o código; no entanto, se não o lermos, vamos perder uma grande quantidade de informações que contribuem para o processo de testes. O código permite analisar o produto, perceber como é que as novas correcções podem afectá-lo e gerar novos bugs.

2. Você acha correcto iniciar os testes só após a conclusão da fase de desenvolvimento. A verdade é que conseguimos testar de forma eficiente, quando somos envolvidos o mais cedo possível no projecto, tal como os outros membros da equipa. Embora os testes sejam vistos como a última etapa do projecto, é fundamental participar e acompanhar o levantamento de requisitos, a análise e a fase de planeamento para entender melhor os objectivos dos testes.

3. Você normalmente não interage com o cliente. Uma vez que o seu trabalho é garantir que o produto está de acordo com todas as necessidades do utilizador, é fundamental que um tester faça validações regulares junto do cliente e tenha uma boa compreensão das expectativas dos utilizadores em relação ao produto. Só assim se conseguem fazer testes eficazes e abrangentes.

4. Você considera desnecessária a gestão de risco. Todos os testers sabem que existem algumas componentes do software que são mais propensas a bugs e que estas componentes costumam atrasar o trabalho da equipa. Por esse motivo, faz parte das funções de um tester conhecer estas situações e informar os outros. E porque nunca conseguimos testar tudo, temos que fazer a gestão de risco, atribuindo prioridades ao nosso trabalho e decidir a ordem dos testes a executar.

5. Você não tenta aumentar o seu valor como tester. Engana-se quem pensa que fazer testes não requer conhecimentos e competências especiais que permitem desenvolver a especialização em testes. Em vez de ver os testes como um trabalho pouco sério, devemos começar a construir uma estratégia profissional como testers. Devemos identificar as qualidades mais importantes que a nossa empresa exige a cada um de nós e delinear formas para as desenvolver.

O futuro dos testes de software precisa de todos nós; se deixar de ser exigente com a sua especialização profissional, então deixarão de existir testers profissionais.

---------------------------------------------------------
Texto original em inglês: Beware! 5 Signs of Being Unprofessional Tester


domingo, 11 de maio de 2014

Ford chama 750.000 veículos devido a problema de software



Em Detroit (EUA), a Ford Motor Co. Anunciou que está chamar para revisão mais de 750.000 veículos utilitários desportivos para correcção de um possível problema no software nas portas. Os veículos em causa foram vendidos nos Estados Unidos, Canadá e México.

A segunda construtora automóvel americana chamou 692.487 SUVs (incluindo cerca de 65.000 C-Max híbridos), construídos em 2013 e 2014, devido a um problema no software que pode atrasar o accionamento dos airbags laterais em alguns acidentes.

A Ford anunciou que até ao momento não foi reportado qualquer acidente ou problema relacionado com a falha agora detectada.

Além disso, a Ford também está chamar para revisão 692.744 SUVs construídos em 2013 e 2014 para corrigir possíveis defeitos nos puxadores das portas que poderiam impedir as portas de trancar correctamente. A empresa disse que as portas se poderiam abrir durante a condução, aumentando o risco de ferimentos.

-------------------------------------------------------
Fonte: Ford recalls over 750,000 vehicles for software, door-handle faults (Chicago Tribune)


domingo, 27 de abril de 2014

Testers e Programadores: podemos ser amigos?

Será verdade que os testers são aquele grupo de gente problemática como os programadores sugerem? É verdade que ninguém gosta de ser criticado, especialmente quando se trata do seu trabalho. Mas o que os testers realmente fazem é garantir a entrega ao cliente de um produto com qualidade. E é por isso que, em alguns momentos, os programadores se sentem ofendidos. Querem saber porquê? A resposta está na natureza e nas responsabilidades desses dois papéis.

Às vezes, surgem bugs graves; e por vezes, ocorre uma invasão de bugs que leva os programadores a sentirem-se irritados com o seu número e por vezes até com a pessoa. Nestes dois papéis falta a compreensão mútua em diversas áreas.

Criar um bom entendimento e relacionamento entre testers e programadores

Amizade e trabalho em equipa são as principais chaves para resolver este problema. Ser amigo de um programador - significa que se pode falar com ele e ele vai compreender o assunto e, portanto, os dois combinam esforços - pode melhorar o trabalho. Ambos devem compreender que quanto melhor e mais coordenado for o seu trabalho, melhor será o resultado alcançado. Os programadores, por seu lado, deve assegurar que o seu trabalho está livre de bugs. No entanto, os testers devem garantir que se existirem erros, estes são comunicados atempadamente e de forma adequada antes da data prevista de conclusão do projecto.

Sendo tester e passando tempo com a equipa faz com que a relação entre todos os membros, incluindo você e programadores, seja mais amigável. Ao trabalhar juntos, podemos encontrar bugs antecipadamente. E é sempre melhor para corrigi-los imediatamente, do que receber reclamações dos clientes. Com a cooperação, ou seja, com a discussão do desenho e das soluções, todos podem beneficiar; por exemplo, os programadores podem ficar a conhecer as várias questões e áreas, de modo a melhorar a qualidade do seu trabalho, e portanto, assimilando na sua mente novas ideias sobre a qualidade do produto a criar.

Os testers acabam sempre por encontrar bugs, mas também podem partilhar algumas tácticas com os programadores sobre como testar o seu trabalho. Podem ajudar os programadores a testar melhor o seu trabalho, antes de o entregar. Note-se que este processo apenas produz frutos quando todos trabalham juntos e partilham o mesmo objectivo final, ou seja, "entregar um produto de elevada qualidade" que esteja de acordo com as necessidades do cliente.

Então, qual é a melhor maneira de tornar as relações entre programadores e testers mais amigáveis?

Aqui estão alguns pensamentos sobre esta questão:
  • Partilhar. Partilhar ideias e estratégias com os programadores. Não deixar isso para os momentos em que surgem os problemas.
  • Ser amigo e ter a mente aberta com programadores para que eles não se sintam magoados. Permitir que eles partilhem qualquer coisa connosco.
  • Manter um estilo positivo de informação/reporte. Tentar ser mais diplomático.
Se tiverem outras ideias, por favor partilhem.

---------------------------------------------------
Traduzido e adaptado de: Testers Vs Developers: How To Make Them Being Friends?



segunda-feira, 21 de abril de 2014

Desafios enfrentados em testes manuais

A maioria dos desafios enfrentados em testes manuais surge devido a falhas de julgamento na análise de competências. Os desafios enfrentados são:

1. Pessoas
Sábia seleção dos membros da equipa
O maior desafio ao selecionar uma equipa para um determinado trabalho é selecionar as pessoas certas para o mesmo, pois é um fator muito importante para averiguar se será efetivamente atingido o sucesso ou não. 

Solução: Todos os testers selecionados devem ser qualificados para executarem o seu trabalho. Testers não qualificados podem tornar complexa uma tarefa simples o que pode atrasar o processo. Poderão também utilizar métodos que provocam falhas graves em testes tornando-os inapropriados. Testes manuais exigem pessoas qualificadas na área, sendo os principais requisitos a resolução de problemas, excelente capacidade de análise e comunicação.

Conhecimento do negócio
Outro grande desafio que enfrentamos é o de saber tudo sobre o processo que estamos a realizar. Esta é a única razão pela qual o conhecimento de negócio tem vindo a ganhar poder sobre competências e conhecimentos técnicos.

Solução: Um dos principais fatores que enfrentamos em testes é desenhar as condições de teste corretas. Isto requer muita análise de requisitos e também um excelente nível de conhecimento de negócio. É um conceito importante para ter uma ideia real do produto, como ele funciona, o que aumenta as capacidades de teste. Temos que, pelo menos, ganhar o conhecimento básico de negócio antes de testar um produto. Isso ajudará a investigar as principais falhas lógicas, se realmente existirem. Conhecimento de negócio é importante para compreender o máximo de conceitos possíveis.

2. Processos
Cada tester tem os seus próprios métodos e casos de teste que podem ser ligeiramente diferentes dos processos definidos pela empresa. Por isso, é importante ter informações completas sobre os processos estabelecidos pela empresa e segui-los de forma a não dar origem a testes incompletos.

Problema da atualização de requisitos
Um dos maiores desafios em testes manuais é que os requisitos do software sofrem várias atualizações devido a várias razões. O verdadeiro obstáculo reside em abordar estas razões com sucesso.

Solução: A principal razão pela qual os requisitos do software continuam a mudar ao longo do tempo é devido ao surgimento de muitos erros e bugs que tornam difícil continuar o processo de teste. Então, nesses casos, são utilizados testes de regressão para testar qualquer nova falha ou surgimento de eventuais falhas previamente resolvidas.

Selecionar os casos de teste relevantes e priorizá-los
Depois de passar pela fase de escrita dos casos de teste tendemos a relaxar por pensar que estamos no caminho certo. No entanto precisamos recordar que, mesmo depois de escrever os casos de teste corretamente, erros podem ser cometidos ao selecionar ou priorizar os mesmos. Portanto, este processo também é igualmente crítico para o sucesso de testes de software.

----------------------
Traduzido e adaptado de "Challenges of Manual Testing" por Tiago Almeida

domingo, 13 de abril de 2014

Tem calma! És um tester...

Por Eric Jacobson.

Muitos testers optaram por tornar o seu trabalho stressante, assumindo mais responsabilidades do que deviam, ocultando as suas competências com as competências de outros membros das suas equipas. Optar por tornar o seu trabalho menos stressante não só irá ajudá-lo a apreciar os testes, mas também irá permitir que você se concentre em testes, e melhorar a sua posição como líder de testes. Aqui estão algumas coisas que eu aprendi ao longo dos anos...
  • Quando as pessoas me perguntam "Será que conseguimos uma Certificação de QA para colocar isto em produção? " lembro-lhes que a escolha do momento do lançamento do produto é uma decisão de negócios; mas posso dizer-lhes muito do que eles precisam saber (por exemplo, como é que funciona actualmente sob certas condições, o que erros existem) para os ajudar a tomar essa decisão.
  • Quando ouço os utilizadores queixarem-se que o produto não trabalha para eles devido à forma como foi concebido, sinto empatia com eles... depois lembro-me que eu nunca digo aos analistas/programadores como devem construir o produto ou o que deve fazer.
  • Quando sou confrontado com coisas tecnicamente assustadoras para testar, volto-me para a minha equipa. Só tenho que fazer um olhar estúpido para a primeira pessoa com que falo, porque quando eu começar a falar com a segunda pessoa, pelo menos já aprendi com a primeira. À medida que vou partilhando as minhas ideias sobre testes, eles gradualmente mudam de básico para sofisticado. Rapidamente percebo que toda a gente na minha equipa está tão baralhada como eu.
  • Momento da Verdade. Estou à espera disso. Ando descontraído no início de uma iteração e trabalho mais e mais para o final. Mantenho o equilíbrio entre trabalho e vida privada, mantendo a minha agenda pessoal livre antes e depois de uma entrada em produção. Trabalhando até tarde com outros membros da equipa é muitas vezes tão divertido como passar uma noite calma em casa com a minha esposa (não se preocupem; ela não lê o meu blog).
  • Demasiadas coisas para testar! Muito pouco tempo! Isto por vezes ainda me stressa. Mas quando penso racionalmente, coloca a questão aos meus chefes: "tenho apenas dois dias; preferem que eu teste as novas funcionalidades ou que me concentrar em testes de regressão?". Isto habitua-os a respeitar o meu planeamento e a entender que este tem limitações. Também mostra que respeito o seu sentido de negócio e valorizo as suas opiniões.
  • O produto foi lançado mas a qualidade é uma porcaria. Ok, você pode sentir-se um pouco culpado... juntamente com os programadores e os analistas. Mas lembre-se, você não fez o código, nem o projectou. A qualidade só pode ser incluída pelos programadores (por exemplo, se não há código, não há qualidade). Se agora é uma porcaria, imagine-se o que seria antes daqueles 471 erros que você detectou!
E você? Que coisas faz para tornar os testes menos stressantes e manter sua sanidade?

-------------------------------------------------------
Texto original em inglês: You’re a Tester, Relax (Test This Blog - Eric Jacobson's Software Testing Blog)