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?

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

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)

As Pessoas mais Influentes nos Testes Software

Por Gregory Mooney.

Ao longo da minha carreira em testes de software houve muitos obstáculos que tive de superar para chegar onde estou hoje. Antigamente esforçava-me para testar de forma eficaz; e através de tentativa e erro fui capaz de me tornar mais eficiente.

No meu primeiro trabalho de tester, foi um desafio conseguir o respeito dos programadores que tinham um perfil mais técnico do que eu. Eu era muito jovem e inexperiente, mas com persistência e com o apoio dos meus superiores, consegui lentamente ganhar o respeito deles e tornar-me mais técnico.

Nos últimos anos, comecei lentamente a ganhar a minha independência como tester e isso deveu-se principalmente à ajuda prestada por outros testers influentes. Tendo trabalhado principalmente em espaços fechados, nunca tinha investigado a forma como outros testers se assumem no mercado; expunha-me pouco perante a comunidade dos testers e os líderes de pensamento no mundo dos testes.

Com a sua orientação, participando em conferências de testes, lendo os seus livros e artigos, tornei-me mais confiante nas minhas competências e descobri novas maneiras de olhar para o software. Estes líderes da indústria de testes ajudaram-me a ver os testes de software sob uma nova luz e a considerar a sua prática extremamente gratificante.

Assim, elaborei uma lista das pessoas mais influentes na minha formação na minha formação como tester ao longo dos últimos anos. Também recebi opiniões de outras pessoas sobre quem os influenciou nas suas carreiras. Não se tratou de uma eleição, ou uma sondagem de popularidade. Acredito que é importante entender quem - e o quê - influencia as nossas carreiras, como uma reflexão para nos tornarmos pessoas mais fortes no futuro.

Acima de tudo espero que esta lista chegue às mãos daqueles que são novos no mundo dos testes de software, para que possam aprender com essas pessoas tal como eu aprendi ao longo dos últimos anos. Tenho a certeza que teria evoluído mais rapidamente se tivesse os seus recursos disponíveis para mim.

Aristóteles

Tinha que o colocar aqui em primeiro, porque algumas das informações mais importantes sobre como encarar os testes de software deriva dos grandes filósofos da história humana. Os testes de software não são apenas uma maneira de pensar; são uma arte e uma ciência.

Aristóteles é o vencedor, não apenas por ter sido, provavelmente, o maior filósofo de todos os tempos, mas também porque deixou a sua marca em todos os aspectos da ciência. A sua maneira de pensar há mais de dois mil anos atrás, moldou a forma como hoje pensamos as ciências e as artes, incluindo os testes de software.

James Bach

James deve ser a pessoa mais franca na comunidade de testes de software. Os seus pontos de vista e código de ética podem ser difíceis de digerir para algumas pessoas, mas a sua paixão é incomparável. Ele fala com o coração e defende aquilo em que acredita.

Os seus pontos de vista baseiam-se num código de ética em testes de software e são entendidos no contexto de cada cenário que os testers enfrentam. A comunidade de testes está dividida e defensores como ele podem ser a chave para unir os testers numa única comunidade.

Não importa se se concorda ou não com os seus pontos de vista. Ele sabe que através da conversa e debate, podemos aprender mais uns com os outros do que se ficarmos sentados e nos recusarmos envolver-nos. Isto é o que ele me ensinou; e é por isso que eu tenho muito respeito pelas suas opiniões, artigos e livros.

Algum material de James Bach que eu recomendo a todos os testers demora tempo a ler:

- Lessons Learned in Software Testing (Cem Kaner, James Bach, Bret Pettichord)

- Secrets of A Buccaneer-Scholar

- Blog de James Bach

Cem Kaner

Não se encontra outra pessoa com mais conhecimento no mundo dos testes do que Cem Kaner. Para lá dos testes, Kaner é doutorado em psicologia, é formado em direito e psicologia e tem sido um programador e gestor de testes. Ele é um dos fundadores Association of Software Testing. Para ser honesto, deve ser difícil descobrir algo que ele ainda não tenha feito.

Grande parte dos testes, como podem imaginar, são um exercício mental; assim podemos ver onde a licenciaturas de psicologia e filosofia são oportunas, mas, como é óbvio, eu não posso falar pelo Sr. Kaner. Tenho todo o seu material que li em alta consideração. Tenho dois dos seus livros na minha lista de coisas que quero ler... Os seus interesses variam desde as métricas até às leis da qualidade de software.

- Website de Cem Kaner

- Testing Computer Software

- Context-Driven-Testing

Lisa Crispin

Desde que comecei a entender as práticas Agile e a forma como o trabalho em sequências de iterações diminui a quantidade de tempo de testes, fiquei fascinado pelos testes Agile.

Trabalhei numa espécie de híbrido Waterfall/Agile, quando era tester, de modo que o Agile ainda é relativamente novo para mim. No meu anterior cargo de tester, tinha iterações bastante longas devido à falta de recursos de desenvolvimento - éramos um pequeno grupo interligado a trabalhar remotamente uns dos outros. Assim, quando comecei a aprender sobre testes em ambientes Agile, fui rapidamente a alguns dos trabalhos de Lisa (e, posteriormente, de Janet Gregory) sobre o assunto.

Lisa Crispin é formadora e profissional de testes Agile. Publicou um par de livros sobre testes e o seu website é um óptimo recurso para aprender algo novo a partir das suas próprias experiências enquanto líder Agile.

- Agile Testing

- Blog de Lisa Crispin

Griffin Jones

Nunca trabalhei numa indústria regulamentada e depois de ouvir algumas histórias de horror, a ideia dá-me calafrios. Já ouvi aquelas histórias de testers e programadores serem processados ​​em milhões de dólares por causa de um defeito de software ter afectado o mercado de acções ou até mesmo ser causa de morte (por exemplo, um defeito num aparelho médico). Imagine que a sua aplicação bancária tinha um defeito onde as suas informações podiam ser roubadas e usadas contra si; você estaria à espera de uma indemnização do banco.

Testar em indústrias regulamentadas não é brincadeira, e Griffin Jones sabe disso melhor do que a maioria. Se você tiver dúvidas sobre a conformidade regulamentar, sejam o cumprimento das normas da FDA ou sobre a forma como se proteger a si e à sua empresa em encontrar e construir uma boa prova para se proteger em matérias de responsabilidade, ele é a pessoa a quem perguntar.

- Congruent Compliance

- Interview With Griffin Jones

- Regulated Industries andSoftware Testing

A lista continua

Para ser honesto, poderia mencionar algumas outras pessoas que influenciaram a forma como abordo os testes de software, mas não encaixariam aqui. Para aqueles que são novos nos testes de software, estes especialistas são um bom ponto de partida. Para os profissionais mais experientes nos testes, há sempre algo mais a aprender, por isso, continuem a procurar, e com sorte poderão continuar a aprender algo de novo com um especialista diferente em cada dia.

Estejam à vontade para dizer quem foi mais influente nas vossas carreiras de testers.

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

Texto original em inglês: Most Influential People in Software Testing

Erro de software provoca aviso de Tsunami no Alaska

Várias pessoas na cidade de Stika, no Alaska, acreditaram que um tsunami estava iminente quando receberam aviso que omitia a frase “Isto é um teste”. Os exercícios e simulações costumam ocorrer em muitas cidades costeiras do Alaska, mas desta vez, um erro de software terá levado a população a acreditar que se tratava de um evento real.

Segundo a rádio KWAC, um erro de software terá estado na origem da confusão. Joel Curtis, do Serviço Nacional de Meteorologia, esclareceu que a mensagem que foi transmitida usou o template de aviso real que substituiu a mensagem usada em exercícios e simulações.

Após esta simulação de tsunami, a polícia de Sitka apressou-se a esclarecer os residentes que a mensagem de alerta de tsunami foi apenas um teste.

-------------------
FONTES:
Software error leads to Tsunami warning scare in Alaska (FoxNews)
Tsunami warning test too real? (KWAC)

FAA ordena correcção imediata ao software do Boeing 747-8

A Federal Aviation Administration (FAA) (agência federal americana para a aviação) ordenou a correcção imediata da mais recente versão do software do Boeing 747-8, declarando que foi detectado um problema que pode provocar a perda de potência durante a manobra de aterragem e causar a queda do avião. Esta é a 4ª directiva da FAA sobre este tipo de aparelho.

Por seu lado, a Boeing já veio esclarecer que o problema agora detectado nunca afectou qualquer avião em pleno voo, acrescentando que a possibilidade de ocorrência de problemas é “extremamente remota”. Entretanto, as companhias que possuem este tipo de aparelho foram aconselhadas a actualizar o respectivo software.

O Boeing 747-8 é a mais recente versão do avião conhecido como “Jumbo“. Actualmente existem dezenas deste tipo de aparelho no activo em diversas companhias aéreas.

-------------------------
FONTE: FAA tells Boeing to fix 747-8 software to avoid crash (Reuters)

Testes de Regressão: Manuais ou Automáticos?

A questão que surge em cada fase do desenvolvimento é que os testes de regressão após cada iteração levam muito tempo, e muitas vezes a funcionalidade que está a ser validada não sofreu alterações. Consequentemente, a possibilidade de existirem defeitos é muito baixa. Como resultado natural, chegamos a uma ideia de automatizar todos os cenários de regressão e em detrimento dos testes manuais de regressão. As vantagens são evidentes:

• os testes automatizados são mais rápidos do que os manuais ;
• os testes automatizados podem ser realizados em qualquer momento;
• os testes automatizados são muito precisos;
• a automatização pode ser utilizada em quase todos os processos de teste;
• pode-se criar relatórios com base nos resultados da automatização.

Mas, infelizmente, a automatização dos testes de regressão tem muitas armadilhas que raramente são discutidas.

Antes de começar a automatizar testes de regressão é necessário resolver algumas questões: 

• Que funcionalidade deve ser coberta pelos testes;
• Definir a arquitectura dos testes automáticos;
• Escolher uma ferramenta para automatizar de testes de regressão.

Vamos ver situações reais na prática. Na fase de mudança de testes manuais para testes automatizados, tive um projecto onde eu tinha que testar o registo de dois tipos de contas para um site em 43 domínios, consoante país. Era um autêntico inferno. O cliente não se preocupava com a qualidade da informação apresentada. Os requisitos eram os seguintes:

• as contas são criadas sem erros fatais ;
• os dados introduzidos coincidem com os valores que são exibidos nas configurações após a criação.

Depois de duas execuções percebi que era demais. Na altura, só conseguia ver que o número de campos de registo é diferente em alguns países e também tinha alguma experiência em programação em C#. Havia a possibilidade de automatizar os testes regressão e não hesitei. Pedi a um amigo familiarizado com automatização para descrever e mostrar como se escrevem testes. Depois de muitas perguntas, tentativas e erros, nasceu um teste simples de navegação. Descobri locators e web drivers Selenium - e eis que, todos os domínios utilizavam os mesmos locators. Pouco mais tinha para fazer: executar última regressão manual da minha vida em todos os domínios e preencher a tabela com os correspondentes campos e domínios. Outra sessão de regressão manual - um longo processo para fechar o círculo - e tudo parecia terminado.

Gozei cada uma das regressões seguintes. Pude assistir a algumas séries de TV enquanto executava a regressão. E, por sinal, cada uma demorava apenas o tempo de um episódio. Enquanto eu costumava gastar cerca de 4 a 5 horas em testes de registos nos 43 domínios, os testes de regressão automatizados demoravam 40 a 45 minutos.

Considerando isto, podemos chegar à conclusão nº1: para ver as vantagens da automatização de testes, devemos começar com os testes mais frequentes, que geralmente são positivos, e que devem ser executados após cada release.

Isso continuou durante várias releases até que a empresa decidiu oficialmente automatizar a maioria das funcionalidades. E como o cliente não era muito conhecedor em testes de automatização decidimos automatizar toda e qualquer coisa que caísse no âmbito do meu conhecimento de automatização de testes.

Como resultado, cobrimos quase todo o sistema com testes automáticos. Tudo estaria bem, mas depois de qualquer correcção alguns testes começavam a falhar. Na maioria dos casos, isso acontecia porque tínhamos grandes scripts que tinham muitos passos:

·         Num primeiro passo do teste o sistema era colocado num determinado estado; quando o erro surgia no segundo passo, já não tinha sentido executar os restantes passos;

·         Cenários longos contêm muito código e acções como estas; como resultado, repetir os primeiros passos podia fazer com que muitos testes falhassem.

·         Devido à repetição do código, os testes automáticos validam o mesmo ponto muitas vezes, o que provoca um aumento desnecessário da duração dos testes.

Com base nisso, podemos chegar à conclusão nº 2: cenários demasiado longos devem ser executados manualmente, pois consome-se muito tempo a escrevê-los e estes podem falhar devido a pequenos bugs ou erros de menor importância.

Vamos considerar uma outra situação muito interessante. O cliente pediu testes automáticos, como é habitual, e solicitou que apresentássemos alguns exemplos. Ele aprovou a ideia, e alguns dias depois adicionamos automatização de testes ao planeamento. Mas os nossos programadores atrasaram-se e, os testers tiveram que escrever testes automáticos com base numa versão provisória. Dois dias depois os programadores concluíram o trabalho, mas mais da metade dos testes automáticos falhou.

Conclusão nº 3: nunca começar a escrever testes automatizados, sem que exista uma versão estável.

Há pouco tempo atrás, tivemos uma situação engraçada. Tínhamos recebido um pedido de testes automáticos a um site e tudo tinha de ser feito rapidamente. Tudo correu melhor do que nunca. Algumas semanas depois, o cliente enviou uma carta reclamando que os testes não funcionaram. Percebemos que ele tinha iniciado um redesenho do site e todos os testes tinham falhado. Isto ensinou-me a fazer testes estáveis.

Portanto, a conclusão n º 4 é: quando for possível, usar os locators de modo que os elementos possam ser encontrados após pequenas mudanças.

Assim, as vantagens de testes manuais vêem-se claramente: não dependem de nada e podem ser feitos em qualquer momento. Prescindir dos testes manuais não vai trazer nada de bom. Testes manuais e automáticos estão inter-relacionados e complementam-se; cada um tem vantagens e desvantagens. Antes de pensar em automatizar cenários de regressão devemos avaliar o tempo a escrever os dois tipos de testes e o apoio destes. E lembre-se que os especialistas em testes manuais geralmente ganham menos do que aqueles que têm competências em automatização de testes.

Como sempre, é tudo uma questão de dinheiro. Se a automatização de cenários de teste de regressão economiza dinheiro sem perder a qualidade do produto, então pode-se alargar o leque de cenários automatizados, elevando a qualidade do produto e reduzindo custos. O ponto de equilíbrio é uma decisão de cada um de nós e depende da experiência e das preferências pessoais.

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

Traduzido e adaptado de: Regression Testing: Manual Or Automated? (With Examples)