Os testes estão atrapalhando a qualidade?

No primeiro post de 2013 relacionado a testes, compartilho com vocês uma palestra que encontrei do James Whittaker na conferência StarWest (Software Testing Analysis and Review) 2011. Largamente conhecido por suas contribuições a nossa área, ele questiona de maneira forte qual o verdadeiro papel dos testes.

James aborda diversas questões, que nos levam a refletir a importância de cada uma de nossas tarefas, por exemplo:

– Como ganhar respeito para os testes?

– Os testes são apenas uma disciplina que apoia o desenvolvimento?

– Os softwares estão ficando melhores… Porquê?

– Os bugs que você encontra poderiam ser encontrados pelos usuários?

– A única coisa que se mantém atualizada é o código.

O vídeo tem 55 minutos, mas tenho certeza que é um tempo bem investido. Assista e avalie como você se sente em relação ao seu trabalho com testes e principalmente como você pode torná-lo melhor?

 

“A única coisa que importa é o produto”

                                                                                     James Whittaker

Pessoalmente, concordo com muita coisa dita por ele no vídeo. Se prestarmos bastante atenção, o tom forte utilizado é apenas para chocar e chamar a nossa atenção a um problema visível e que muitos preferem empurrar com a barriga. Cada vez mais precisamos entregar valor, e ficar gastando tempo com atividades que pouco beneficiam o desenvolvimento do produto é um erro grave, do mesmo modo que o tempo perdido com trabalho que poderia ser melhor executado por ferramentas.

Você concorda com o cenário geral descrito por Whittaker? Ele, inclusive, aponta que estávamos enganados e que, sim, usuários e desenvolvedores podem testar melhor que uma equipe de testadores.

Link do post falando das ferramentas que o google tornou open-source para testes, mencionado no vídeo :

 – Google Testing Blog

No início do vídeo James faz um rápido questionário com a platéia, adicionei as perguntas abaixo em português, compartilhe conosco sua resposta:

Anúncios

Existe profissional de TI fazendo corpo mole na sua empresa?

Em qualquer profissão existem pessoas que fazem o conhecido “corpo mole”, alguns , inclusive,  se esforçam tanto na enrolação, que fica até difícil de percebermos, e acabam compensando sua pouca produtividade com grande esforço no “marketing pessoal” ou no “relacionamento” com os colegas.

As conseqüências das ações desse tipo de profissional nem sempre são imediatas ou graves, porém não há dúvida do custo e do prejuízo que essas atitudes podem ter no projeto e até mesmo na empresa.

Apesar desse tipo de profissional existir em todas as áreas e funções, no post de hoje, vamos focar em como reconhecer um testador desse tipo. Vamos apresentar algumas dicas para perceber quando um tester não está trabalhando como deveria, mas não se espante se você visualizar as mesmas características em outros profissionais.

Esse tipo de problema ainda ocorre, porque é fácil se safar sem realizar algum trabalho efetivo, e geralmente os líderes de equipe e gerentes de projeto não possuem as ferramentas e conhecimentos necessários para avaliar o progresso do trabalho de um testador. (Link – Artigo)

É extremamente fácil dizer que algo foi testado.

– Conhecimento superficial: Os profissionais que fazem corpo mole, em geral possuem conhecimento extremamente limitado sobre o sistema, afinal eles não teriam o trabalho de se aprofundar e conhecer os detalhes de cada requisito ou estória de usuário. Isso gera diversas consequências que facilitam a identificação desses profissionais:

1 – Encontram apenas Bugs superficiais e de pouco valor

2 – Não conseguem participar efetivamente das reuniões de planejamento

3 – Se limitam a fazer apenas o que lhes é pedido

Algumas mudanças na maneira de acompanhar o progresso do trabalho podem ajudar na tarefa de identificar esses profissionais:

– Evitar acompanhar a execução dos testes apenas através de relatórios gerados pelas ferramentas. Em seu lugar, questionar os envolvidos na execução, compreender o que foi testado, reportado e os próximos passos.

Outra ação, que talvez, apresente um resultado interessante é assegurar que diversas técnicas de execução são utilizadas: Automação, testes exploratórios, estáticos… Dessa forma, o profissional “corpo mole” precisará demonstrar seu conhecimento de uma maneira que permitirá uma melhor medição do seu trabalho.

Para finalizarmos o post, um vídeo divertido, onde George Constanza, da série Seinfeld, explica sua técnica para demonstrar que está cheio de atividades no trabalho.

E vocês? Que outras características observam nos Profissionais “George Constanza”?

Os 7 princípios do teste de software

No post – Os bons testes falham – falamos sobre um dos princípios de teste definidos no livro “Fundamentos de testes de software”. Hoje, compartilho com vocês dois vídeos, bem curtos, que resumem os 7 princípios definidos no livro. Os mesmos servem como referência, principalmente para aqueles que estão iniciando na área de testes.

O primeiro vídeo, exibido acima, aborda os 4 primeiros princípios, são eles:

1 – Teste demonstra a presença de defeitos.

Os testes reduzem a probabilidade que erros desconhecidos permaneçam no sistema, mas mesmo que nenhum defeito seja encontrado isso não é prova de conformidade.

2 – Teste exaustivo é impossível.

Mesmo com auxílio da automação, o número de combinações possíveis de cenários de teste numa aplicação é gigantesco, inviabilizando a possibilidade de se afirmar que TUDO foi testado.

3 – Testes devem iniciar o quanto antes e erros encontrados tarde custam mais para corrigir.

Iniciando o mais cedo possível no ciclo de vida do desenvolvimento do software, diminuímos o custo das correções e possibilitamos que erros de design, requisitos e arquitetura sejam encontrados no momento ideal. (Link para vídeo que aborda o assunto)

4 – Agrupamento de defeitos 

80% dos defeitos são causados por 20% do código. Ao identificar essas áreas sensíveis, os testes podem prioriza-las, enquanto ainda procuram por erros nas demais regiões.

O segundo vídeo, exemplifica os princípios anteriores e apresenta os 3 últimos pontos:

5 -Paradoxo do Pesticida

Caso os mesmos testes sejam aplicados repetidamente, em determinado momento eles deixam de ser úteis, ou seja, não conseguem encontrar nenhum novo defeito. Por isso, os testes precisam ser revisitados com frequência.

6 – Teste é dependente do contexto

Diferentes tipos de aplicações exigem a aplicação de técnicas diferentes de teste.
7 – A ilusão da ausência de defeitos

De nada adianta o sistema estar correto funcionalmente, porém não atender a real  necessidade do usuário.

O Cliente

Entre todos os princípios listados, acredito que os números 3 e 7 representam os principais aspectos da nossa atividade. A busca constante por antecipar cada vez mais as possíveis falhas da aplicação e assegurar que o sistema entregue atenda as reais necessidades do cliente, agregando valor ao seu negócio.

E vocês que aspectos consideram mais importantes nos testes de software?

Agora você já pode acompanhar as novidades do BdB pelo Facebook, acesse e curta nossa página.

Entendendo os testes de performance

Todos já enfrentamos diferentes problemas de performance ao acessar nossos serviços favoritos na web. Lentidão e até mesmo indisponibilidade por longos períodos são problemas que ainda afetam a maioria das aplicações web.

Desse modo, podemos apontar que a Performance é um requisito não-funcional CHAVE para as aplicações web. E menosprezá-la pode causar grandes consequências.

Podemos definir os testes de performance, como:

Através dos testes de performance podemos simular o ambiente de produção, que a aplicação será submetida e avaliar como a mesma irá se comportar.

Lembrando que….

…de forma, que através da correta execução dos testes de performance, em conjunto com um monitoramento eficiente, podemos submeter diversos pontos da aplicação aos níveis de carga esperados e avaliar o seu comportamento.

No contexto das aplicações web: “Se um usuário tem de esperar muito (para acesso, processamento do lado do servidor, para formatação ou exibição do lado do cliente), ele ou ela pode decidir ir para outro lugar.” (Pressman, 2005)

Logo, desprezar esse requisito não-funcional pode gerar perdas irrecuperáveis para um negócio.

Do ponto de vista conceitual, fala-se sempre em três tipos de teste:

Performance: Avalia se a aplicação em teste atinge os requisitos em relação a questões como: tempo de resposta, throughput e utilização sob um nível de carga esperado.

Carga: Submete a aplicação a diferentes níveis de carga, com o objetivo de identificar a capacidade máxima de operação, além de gargalos, memory leaks, etc…

Stress: Avalia a robustez, disponibilidade e confiabilidade da aplicação em condições extremas (cargas muito elevadas, escassez de recursos)

Os três são comumente confundidos, porém como descrito cada um tem sem objetivo específico e a correta utilização dos mesmos durante o desenvolvimento poderá proporcionar um nível completo de informações sobre o comportamento da aplicação.

Por fim, é importante enfatizarmos que: “Caso não sejam executados da maneira correta, os resultados são, na melhor das hipóteses, inúteis e, na pior das hipóteses, enganosos, fazendo com que uma empresa menospreze ou superestime a capacidade de sua aplicação.” (Savoia, 2000)

Logo, é fundamental que, desde o início do ciclo de vida da aplicação, o RNF relacionado a performance seja priorizado, para que todo um ambiente de testes seja preparado de maneira adequada para simular o ambiente de produção e desse modo auxiliar o desenvolvimento a atingir o nível de qualidade desejado.

Gostou do assunto testes de performance? Participe, deixando seu comentário no post.

Em breve, voltaremos ao assunto falando do Apache JMeter.

E não esqueça de nos seguir no Twitter e juntar-se a nós no Facebook para ser informado das novas atualizações do blog!

Teste está morto parte 2

Como havia prometido, volto hoje ao tema abordado na semana passada. Tentarei destacar os principais pontos abordados no vídeo recomendado na parte 1. E antes de tudo, obrigado a todos pela participação no blog, na DFTestes e no Linkedin. A colaboração de vocês é fundamental para o enriquecimento da discussão.

A primeira grande contribuição do vídeo trata-se da abordagem inicial a evolução das metodologias de desenvolvimento e consequentemente as diferentes formas de atuação dos testadores. O palestrante, Alberto Savoia, a divide em dois grandes momentos: Old Testmentality e New Testmentality. Partindo da dependência completa dos documentos de requisitos, aos ciclos mais curtos das metodologias ágeis associados a uma maior integração entre desenvolvedores e testadores.

Durante a chamada Old Testmentality, as aplicações só eram entregues quando estivessem completamente “prontas”. Enquanto, que na New Testmentality, as entregas passaram a ser frequentes, exigindo uma participação constante do cliente na construção do “produto correto”.

Em seguida, Savoia começa a destacar os pontos que o levam a pensar que o teste tradicional está morto. Começando pelo o que ele chama de Post-Agile, a qual tem como diferencial o fato de apresentar uma postura mais casual e descuidada em relação aos testes ágeis tradicionais.

Segundo Savoia, a questão central cada vez mais é a construção do “produto correto” e não o simples desenvolvimento correto do produto ou das funcionalidades, ou seja, o objetivo é entregar um produto, que em primeiro lugar, atenda às necessidades dos usuários. Não basta ser apenas perfeito funcionalmente.

O palestrante nos lembra que de fato existem diversas aplicações fabulosas construídas utilizando os conceitos tradicionais, mas que a estrutura existente nos dias atuais, como a computação nas nuvens, permitem diminuir o foco da qualidade de software e transferi-lo para garantir que estamos construindo o produto CORRETO.

Um grande exemplo citado é o twitter, que tornou famosa sua baleia com a enormidade de vezes que deixava os usuários na mão, mas mesmo assim eles continuavam voltando, pois o produto era o desejado.

Nesse novo cenário, que se desenha, segundo Savoia, precisamos nos voltar para outro tipo de bug, o chamado idea bug, que podemos traduzir como bugs de conceito ou de idéia do produto.

Um produto errado é muito pior do que um produto com o comportamento errado.

A chave é testar a idéia, ou seja, garantir que estamos desenvolvendo o produto certo.

E como podemos testar a idéia?

A sugestão de Savoia é começarmos utilizando protótipos iniciais (pretotype), os quais ele diferencia dos protótipos tradicionais, por serem desenvolvidos e aplicados em curtos espaços de tempo. É fundamental testar cedo e falhar rápido, segundo o mesmo Bons testes falham rápido, diminuindo o tempo e o capital investido. (BdB – Os bons testes falham)

Alberto cita ainda alguns dos sinais observados, que o levam a crer no fim dos testes tradicionais.

Sinais do Testpocalypse:

– Diminuição no numero de contratações
– Comoditização dos testadores
– Saída dos antigos líderes e ausência de novos
– Mais e mais empresas partindo para o Post-Agile

Acompanhado essa corrente de mudanças existem enormes oportunidades. Savoia enfatiza a crescente necessidade do surgimento de novos líderes na área de testes, com uma mentalidade diferente, e que possam conduzir essa etapa de transição. Onde, como o mesmo aponta, ainda conviveremos por um longo tempo com as diversas formas de teste. (BdB – Imagine um mundo sem Bugs no Software)

Por fim, um dos slides afirma “Test is dead. Don’t take it literally, but take it seriously.”, traduzindo, “Teste está morto. Não leve isso literalmente, mas leve a sério.”. Logo, a palestra é uma alerta e não uma simples afirmação arrogante, que se julga acima de todos nós. Uma apresentação, que vale a pena ser vista com atenção, e que nos deve levar a refletir sobre os caminhos, que estamos seguindo, as oportunidades de aprendizado e de mudança que podemos levar a nossa área. Sejamos o agente dessas mudanças.

P.S. Todas as imagens utilizadas estão nos slides da apresentação, disponível aqui.

Teste está morto parte 1

Não restam dúvidas de que automação de testes é uma atividade fundamental no desenvolvimento de sistemas. Desde os testes unitários até os de aceitação precisamos cada vez mais de uma estrutura que permita a entrega de aplicações de maior qualidade num menor espaço de tempo.

Na internet existem diversos materiais e vídeos, que podem nos ajudar a progredir nesse caminho. A indicação de hoje são os vídeos do Google Testing Automation Conference, conferência do google, que reúne os mais respeitados profissionais. Na página da conferência você encontra os vídeos e os slides das palestras realizadas. Buscando um pouco mais você pode encontrar também os vídeos das edições anteriores.

GTAC 2011 - Logo

A palestra de abertura da edição de 2011, apresentada por Alberto Savoia, têm como título Test is Dead (Teste está morto), ficou curioso? De forma brilhante, o mesmo passeia pelas metodologias de desenvolvimento de software, finalizando com os motivos que o levam a crer que o teste está morto.

São 35 minutos de palestra, somados a 15 minutos de perguntas. Logo, caso não possa parar agora, guarde o link e assista numa melhor oportunidade, vale bastante a pena.

Quer saber mais sobre como o pessoal testa as aplicações no google? Acesse o blog mantido por eles.

Outros vídeos interessantes do pessoal do google podem ser encontrados na página do youtube – Google Tech Talks.

Na próxima semana, publico a parte dois do post, onde comentarei sobre alguns dos pontos discutidos na palestra acima.

Os bugs também têm sentimentos

Muitas vezes uma imagem diz mais do que mil palavras. No blog Cartoon tester, Andy Glover faz uso de imagens extremamente simples, mas que transmitem de maneira objetiva conceitos e práticas interessantes relacionadas com as atividades do engenheiro de testes.

A imagem abaixo é do post do blog, que fala de maneira correta sobre algumas atitudes que devemos ter no nosso dia a dia quando encontramos bugs. Abaixo, uma breve explicação dos pontos mencionados.

Se você encontrar um bug:

1 – Reporte-o, bugs não gostam de ser esquecidos.

Diversos motivos podem levar um testador a esquecer de reportar algum defeito encontrado, prazos apertados, tarefas acumuladas, desorganização ou simplesmente o fato de que algumas vezes os defeitos são encontrados antes mesmo dos testes, em conversas informais, treinamentos, etc.. e nem sempre os envolvidos tomam as devidas ações nessas situações.

2 – Conheça-o melhor, bugs gostam de ser compreendidos.

Antes de reportar um defeito, devemos entender por completo seu comportamento, sua abrangência e quais são seus impactos.

3 – Tire uma foto, bugs gostam de guardar recordações das ocasiões.

Screenshots, fotos e inclusive vídeos ajudam a evidenciar melhor a reportagem de um defeito, facilitando o entendimento do desenvolvedor e evitando CRs reabertas.

4 – Conheça seus companheiros, bugs são socialites.

Ao encontrar um defeito é comum que outros bugs estejam localizados nas suas redondezas, por isso é importante a varredura nas funcionalidades relacionadas para rapidamente detectar novas falhas.

5 – Reporte rapidamente, do contrário os bugs se estabelecem e fazem moradia.

Agilidade na reportagem permite que sua correção também seja antecipada, evitando que outros bugs causados pela falha já existente sejam revelados.

6 – Seja honesto, bugs não gostam de fofocas.

Classificação de severidade e prioridade supervalorizadas, melhorias registradas como defeitos, entre outros problemas frequentes, causam problemas na comunicação da equipe e atrapalham o andamento das atividades.

7 – Guarde como o conheceu, bugs são românticos.

Ao encontrar um defeito, a primeira tarefa é sempre de verificar quais foram os passos prévios para detecção do problema, reportar como podemos reproduzir o issue é essencial para os desenvolvedores durante a correção e também para os testadores no momento da verificação das correções.

8 – Não o ignore, bugs podem morder quando não apreciados.

Em meio a tantos bugs, normalmente encontrados durante os testes, é comum que em alguns momentos desprezemos alguns defeitos encontrados, por acreditarmos que os mesmos são irrelevantes ou nunca serão corrigidos. Porém, já cansei de ver defeitos ignorados sendo reportados posteriormente por clientes ou quando vistos por outros ângulos gerando consequências graves para o sistema.

Adicionaria a lista de atitudes a verificação dos defeitos já existentes, prática bastante simples, mas que muitas vezes é relegada, e que pode evitar trabalho desnecessário de diversas pessoas.

E vocês concordam com os tópicos? Sentiram falta de mais alguma atitude?

…………………………………………………………………………………………………………………………………………..

Agora você já pode acompanhar as novidades do BdB pelo Facebook, acesse e curta nossa página.