Automação de testes: Aproximando contextos

A área de Teste evoluiu muito desde quando eu iniciei nela, em 2007. Hoje mesmo não atuando nela, eu vejo o quanto é diferente a forma de se testar, de quando eu comecei na área.

Naquela época automação de testes era um assunto ainda muito pouco difundido e as ferramentas usadas pagas, de grandes suítes de teste como a Rational.

Hoje em 2013 o cenário muito bastante, práticas ágeis estão mais difundidas, a comunidade brasileira está mais madura e ferramentas open sources dão todo o “ferramentário” necessário para a automação.

Para chegarmos no estado de hoje, várias mudanças e revoluções ocorreram. E como toda revolução, ela promete algo muito melhor ao status quo e para se prevalecer, muitas vezes ela se apoia em dizer que tudo está errado.

A automação de testes surgiu como um “lobo mau” para muitos Testers e outros se agarram a ela, como se ela fosse o único caminho de se testar. Com o tempo perceberam que ela nada mais é do que uma evolução. Ela não veio pra expurgar testes manuais, ela veio pra trazer maior eficiência aos testes e evitar o “caos” das manutenções de software.

Um dos efeitos colaterais da automação de teste, foi a aproximação da área de Teste com a área de Desenvolvimento. Ela ocorreu fisicamente com os Testadores sentando mais próximos dos Desenvolvedores, pra facilitar a comunicação quando é preciso tirar dúvidas sobre programação.

Mas ela ocorreu mais ainda na formação do Tester, no próprio DNA do Tester, uma vez que programar não é mais uma arte usada apenas para construir, ela também é usada para “quebrar ” (testes de carga usando JMeter), pra verificar (testes de aceitação usando Jasmine) e pra dá segurança para mudar (testes unitários com RSpec).

Com isso dois contextos que de forma errada muitas vezes eram separados, hoje estão mais próximos. Afinal, Desenvolvimento e testes sempre existiram pelo mesmo propósito, entregar software de qualidade.

Com a dinâmica atual do mercado de TI, não há mais espaço pra guerrinhas setorias, nem para Desenvolvedores que só cospem código, e nem pra Testadores que só navegam por telinhas. Não é mais questão de ser generalista, é questão que saber analisar um problema é tão básico para um Desenvolvedor, como programar é para o Testador.

Especializações interessantes para os profissionais da área de teste de software

A 32ª Mesa Redonda foi sobre “Especializações interessantes para os profissionais da área de teste de software” e teve apenas 2 respostas e 3 participantes, sendo eles: eu, Elias Nogueira e Lidiane Santos.

Como a discussão foi curta, abaixo segue praticamente a íntegra das contribuições feitas pelo Elias e pela Lidiane e também alguns comentários meus.

O Elias abordou vários pontos relevantes, entre eles o insight de que uma especialização na área de Teste de Software, não precisa ser necessariamente na área. Pode parecer estranho, mas é verdade:

Acredito que a especialização em si na Área de Teste não é apenas sobre a área (ex: uma pós em Gestão de Qualidade ou Teste de Software), e sim mais sobre o negócio onde trabalhamos (SOA, Sistemas Distribuidos, Mobile, etc…)

Claro que esse meu pensamento é um pouco puxado para o lado técnico. 😛

Sempre acreditei que o profissional em teste é um dos mais completos, por causa da variedade de conhecimentos que ele precisa ter para desempenhar sua função (óbvio que dependendo do papel/nível do mesmo). Logo, penso que a carreira de um profissional de teste é cheia de conhecimento “fora-teste” (análise de requisitos, programação, etc..)

Hoje, dentro da área acadêmica (Especialização, Pós, MBA) eu vejo quase que 100% formações de líderes, analistas de qualidade ou correlatos. É muito difícil encontrar algum curso acadêmico mais técnico em teste, ou que pelo menos ensine técnicas de teste, algumas ferramentas, etc…

Vejo que o profissional, se deseja algo mais técnico, tem que recorrer a uma destas áreas acadêmicas fora de teste ou recorrer a um mestrado para desenvolver algo diferente. É um ponto que as universidades estão amadurecendo, mas muito lentamente (se pensarmos o número de matérias de programação x número de matérias sobre qualidade e teste de software)

Eu fiz uma Pós em Teste de Software (onde vi toda a área de validação) na Unieuro, e recomendo. Apesar de eu já ter o conhecimento do que eu tive na pós, eu a procurei alguns motivos: ter outras visões do mesmo assunto e ter uma certa comprovação acadêmica. Hoje já recorro a cursos dentro da minha área de especialização que mais me interessam.

A minha dica é que na hora da escolha de uma especialização na área, em termos acadêmicos, que o profissional saiba qual linha ele quer/vai seguir, pois para a linha técnica não existe muita coisa.

Aproveito pra listar aqui algumas instituções acadêmicas ao redor do Brasil que possuem cursos voltados para a área de Teste e Qualidade de Software (sugestão de ficar como um thread separada depois)

– Unieuro (Brasília/DF) – MBA em Teste de Software (Pós Graduação) [não existe mais]

– Feevale (Novo Hamburgo/RS) – Teste e Garantia da Qualidade de Software (Pós Graduação)

– Unisinos (São Leopoldo/RS) – Qualidade de Processos de Software (Tecnológico)

– FIAP (São Paulo/SP) – MBA em Gestão da Qualidade em Software com ênfase em CMMi e MPS.BR (Pós Graduação) [não existe mais]

– SENAC (São Paulo/SP) – Gestão da Qualidade de Software (Pós Graduação)

 

 

 

– UNICAMP – Especialização em Engenharia de Software

A Lidiane contou um pouco da sua experiência e lembrou que participar de eventos é uma forma de buscar se especializar e também de compreender melhor a área e a sua amplitude:

Realmente esse tema é muito importante e legal. Vejo muitas pessoas que estão na área de teste que não sabem que os profissionais dessa área podem ter uma carreira.

Em relação a especializações, existem muitos cursos legais de ferramentas, automação de testes, implementador MPT.BR, TMM. Vejo que há bastante cursos online e/ou semi-presencias, mas não são muito divulgados

Pós-Graduação, eu vejo que é muito interessante na area de Engenharia de Software, Qualidade de Software, é muito importante analisar a grade, pois tem algumas pós que não abordam muito o tema Teste SW.

Na Poli tem alguns cursos bem legais de especialização e extensão vejam no site www.pecepoli.com.br , temos a Iterasys com os cursos preparatórios para certificações, mesmo que vc não faça a prova, o curso acaba sendo muito legal e você consegue praticar algumas coisas no dia-a-dia.

Eu atualmente tento frequentar os eventos de teste como o Brateste, Conferencias – inclusive fui no TDC 2010 realizado em Agosto, WorkShops, estou sempre antenada nas novidades e visitando blogs relacioandos a Qualidade e Teste SW.

Por fim, termino agora em novembro o MBA em Teste de Software pela Unieuro, o curso é bom tirando algumas falhas da instuição em relação ao atendimento ADM e Financeiro… *rs

Eu achei super válidas as contribuições do Elias e da Lidiane, e retratam bem as formas que podemos nos especializar na área de Teste de Software.

Na minha opinião, a especialização hoje é encarada pelos profissionais, basicamente de duas formas:

• O profissional gosta da área e quer se aprofundar melhor nela, ou está buscando cobrir lacunas da graduação e conhecer outras áreas (ex.: ao fazer uma pós em Engenharia de Software);
• A outra forma, são os profissionais que estão buscando status e aumento. Afinal, é bunitinho falar que é pós-graduado e para algumas empresas, o título mostra que o profissional é mais qualificado que outro que não possui uma pós. Essa abordagem é perigosa, porque você pode acabar fazendo um curso que não gosta ou que o seu perfil não encaixea Além do que, essa visão de que ser pós-graduado é igual ser melhor do que os que não são, é uma visão alienada.

Eu particularmente, prefiro uma pós-graduação fora da área de Teste de Software, para quem está na área de Teste de Software. Caso o seu perfil seja mais gerencial, busque uma pós de gestão ou um MBA, agora caso o seu perfil seja mais técnico, busque então uma pós em Engenharia de Software.

Escolha bem o curso e não vá na “hype”, afinal uma pós-graduação, geralmente exige um investimento financeiro grande. Faça a sua escolha com bastante parcimônia. 😉

E lembrem-se: nem sempre se especializar, significa se matrícular num curso de pós-graduação, hoje em dia há outras opções.

Fique por dentro das novidades, assine o feed do QualidadeBR.

Bug no Gmail

Estava desenvolvendo a funcionalidade de aplicação de tags para as menções no Vizir, e durante o desenvolvimento tomei como base do comportamento dessa funcionalidade,  a aplicação de labels do Gmail.

Durante o estudo do funcionamento da criação dos labels no Gmail, acabei encontrando um bug interessante, que mostra bem como nem sempre podemos cobrir todas as situações de erro, uma vez que elas são muitas.

Para quem não conhece essa funcionalidade do Gmail ou não usa o Gmail, segue uma breve explicação sobre ela:

Você quer aplicar um label (marcação) para um e-mail, por exemplo: todos os e-mails de promoções com o label “promoções”. O que essa funcionalidade faz, é exatamente prover uma maneira de aplicar labels aos seus e-mails.

Vamos direto em como reproduzir o bug:

1. Clique no checkbox ao lado do e-mail que você quer aplicar o label;
2. Clique no combo-box Labels;
3. Clique na opção Create new (um pop-up irá aparecer);
4. Digite o nome do seu label e clique no botão OK (“OK” para um botão de criação é estranho hein, poderíamos sugerir uma melhoria).

Pronto, viu o bug? Não?

Sem um screenshot fica difícil, neh. Segue abaixo uma imagem com cada passo feito, clique nela para visualizar numa resolução maior .

E agora viu o “danado”?

Se você nunca usou essa funcionalidade dessa maneira (tem como usar ela criando filtros pré-definidos), está descontado. Mas se você já usou deve/deveria ter reparado que faltou algo.

Quando você aplica um label na mensagem duas coisas acontecem:

• Uma mensagem aparece em cima da box dos e-mails, avisando que a “conversação” foi adicionada no label (The conversation has been added to “qualidadebr”.)
• O e-mail/conversação é marcado com o label.

O que faltou foi a segunda forma de notificação, o label não foi adicionado no e-mail (visualmente, se você atualizar a página irá visualizar o e-mail com o novo label). O interessante que esse bug só ocorre quando você aplica um novo label ao e-mail, se você for aplicar um label já existente, o bug não irá ocorrer.

Abaixo, o resultado esperado:

Pelas entranhas do bug

Com a explicação acima um bom desenvolvedor já iria descobrir o porquê do bug existir.

O que ocorre por de trás das câmeras quando você aplica um label ao e-mail, é que uma atualização via AJAX é feita em duas partes da página: no div da mensagem e no div dos labels.

O problema não é que a atualização não é feita no div dos labels, e sim que o elemento não é adicionado, provavelmente porque o novo label não foi adicionado na varíavel que contém os labels.

E como saber tudo isso?

Te contar que nem precisa entender muito de Javascript e HTML. Utilizando o formidável Firebug você já consegue observar esse comportamento. Difícil é entender o HTML gerado pelo javascript do Gmail (se estiver curioso em entender um pouco como o Gmail funciona esse artigo pode ser útil).

Como solucionar esse bug?

Eu passei pelo mesmo problema na implementação da funcionalidade de aplicação de tags nas menções no Vizir. A solução que encontrei foi dá um refresh na página, quando uma nova tag é inserida. Desta forma, o objeto que armazena os labels já é atualizado com o novo label.

Não deve ser a solução mais linda e elegante, talvez seja possível atualizar a lista de labels do combo-box, via Javascript. Mas como eu não sei fazer isso (preciso dá uma pesquisada se é possível e como fazer [canelada pra mim]),  e essa solução se comportou bem e foi eficiente para o problema que enfrentei. 🙂

Como esse bug escapou dos jardins do Google?

Sou usuário do Gmail desde 2007, e desde lá, só uso ele como cliente de e-mail, tanto para uso pessoal como profissional. E só no começo desse mês que encontrei esse bug.

Ou seja, acredito que este bug não se apresenta com tanta frequência, pois nem todos usuários utilizam esse recurso (diria até, que uma minoria utiliza). Além disso, o uso mais frequente dos labels, pelo menos o uso que mais faço e vejo as pessoas fazerem, é na criação dos filtros.

E a equipe de Teste de Software do Gmail, por que será que eles não encontraram esse bug?

Tenho duas especulações quanto a isso:

• Encontraram o bug, porém como a sua ocorrência não é tão frequente e sua presença não atrapalha muito o usuário, o bug ainda não foi corrigido (tá na fila no bugtracking deles, com prioridade baixa);
• Não encontraram, pois não tinham um caso de teste que cobria esse cenário.

A grande lição que podemos tirar com esse bug, é que um sistema pode muito bem ir para produção, ser super bem elogiado pelos usuários e mesmo assim conter dezenas de bugs (eu conheço uns 3 ou 4 só do Gmail rs). Se você for querer ser perfeccionista ao extremo, você nunca irá colocar um sistema em produção. Um sistema sem bugs não é algo comum, e esse fato é até justificável, é só olhar para as pessoas que desenvolvem e usam os sistemas, elas são perfeitas?

Fique por dentro das novidades, assine o feed do QualidadeBR.

Meus pensamentos sobre pós-graduação

A escrita deste post tem duas motivações:

1. Li semana passada o sample do livro The Personal MBA: Master the Art of Business do Josh Kaufman;
2. A notícia de que a Unieuro foi reprovada na avaliação do MEC.

Já adianto, que não tenho nada contra o curso de pós-graduação da Unieuro em Teste de Software. E pelo feedback que tive de alguns amigos, me parece ser um curso, onde é possível extrair conhecimentos e experiências para o seu crescimento profissional.

Colocada as motivações do post e um breve aviso, é hora de explicar o porquê deste post:

O objetivo é simples, compartilhar a minha visão e posição atual sobre a possibilidade de fazer uma pós-graduação e também minha visão geral sobre uma pós. Lembrando que essa é uma visão bem particular e que acredito ser adequada para o meu perfil e para os meus objetivos a curto e médio prazo, portanto ela pode ser bem diferente da sua visão.

Contextualizando

Estive sentado numa carteira desde os meus 3 anos de idade até os meus 20 anos (hoje tenho 22). Portanto foram 17 anos navegando pela direção convencional dos estudos e aperfeiçoamento pessoal e profissional. E após tanto tempo, tantas escolas, colegas, professores, amigos e notas, me sinto muito à vontade em falar sobre educação, afinal passei das 10.000 mil horas e portanto, me considero um expert, como aluno.

Porém o título de expert como aluno, não é algo que se deva ficar se orgulhando tanto, para mim ele é muito mais próximo do “título” expert em saber andar, do que de um título de expert na arte de ensinar, por exemplo.

Após 2 anos sem frequentar regularmente uma carteira (terminei a faculdade em dezembro de 2008), deveria estar me pressionando para fazer uma pós-graduação. Até já pensei sobre o assunto, principalmente no primeiro semestre de 2009 e estava até planejando começar algo no início de 2010. No entanto, já estamos em 2011 e nem sequer me inscrevi em alguma pós-graduação.

Os motivos para a minha escolha

Essa escolha não foi feita de um dia para o outro, ou após um longo período de reflexão, ela foi feita dia-a-dia.

Ano passado, foi quando tive certeza que não é o momento de fazer uma pós-graduação. Os principais motivos para essa decisão foram:

• Tempo: fazer uma pós-graduação consume muito tempo, e tenho que confessar que mesmo após ter terminada a faculdade não senti, um grande alívio na minha agenda, parece que naturalmente o tempo que era investido na faculdade, foi sendo consumido por outras coisas;
• Dinheiro: uma das minhas opções de pós é o MBA na FGV e minha condição financeira iria ficar seriamente comprometida;
• Maturidade: tanto para um MBA na FGV, como um mestrado na USP, não sinto que estou no momento de fazer, ou melhor, não sinto que irei contribuir o meu máximo para o curso, e que ele irá agregar tanto para a minha formação.

Acho que devo uma explicação para a minha última frase, afinal que louco falaria que um MBA na FGV ou um mestrado na USP não iria agregar tanto para a formação dele.

Então senhores(as), ambos iriam agregar muito, tanto para a minha formação, como para o meu networking (lembrando que o networking é um dos pontos mais importantes de qualquer instituição educacional, desde do primário). No entanto, para o meu contexto atual, há outras alternativas que se encaixam melhor, além do mais, o título e “status” que uma pós na FGV ou USP me daria, não é algo tão relevante para mim (mesmo sabendo que pode ser para uma empresa que for me contratar), eu me importo muito mais com a grade dos cursos e professores e a relevância dos assuntos para o meu contexto.

A minha escolha foi baseada na minha expertise como aluno e meu gosto por vários assuntos/áreas. Essa expertise me permite navegar sozinho pelos mares da informação, e com ela eu mesmo faço a minha grade, escolho os meus mestres e o mais importante, consigo corrigir a tempo a minha direção.

Para ilustrar um pouco disso, vamos considerar a área de Teste de Software. Por ela ainda ser recente no Brasil, não há nenhum curso que esteja maduro e atualizado o suficiente para o meu gosto. Além do mais, para quem está nessa área e está focando em obter conhecimento, acredito ser mais válido acompanhar blogs, listas de discussão, ler livros e participar de eventos (como até disse nesse outro post).

Agora sobre o meu interesse em vários assuntos/áreas, acredito ser um “mal” desde cedo, pois na escola mesmo eu gostava de várias matérias, ao nível de gostar tanto de Matemática como de Português (rs). Lógico que há o risco de se tornar um pato, mas eu não estudo todas as áreas de meu interesse ao mesmo tempo, muito pelo contrário, geralmente eu foco em uma por um bom tempo e em paralelo vou dando uma olhada em outras. Simplesmente, é impossível abraçar o mundo.

Minha escolha

Lendo o sample do livro The Personal MBA: Master the Art of Business (vou até comprar o livro em breve), percebi que a minha escolha não é tão incomum assim, o próprio autor também fez essa escolha e há anos atrás, e ele cita pessoas que fizeram essa escolha há décadas atrás!

Eu costumo até brincar, que esse tipo de livro/autor são má influências para mim, porém, vejo que eles foram pessoas iguais a mim, que tiveram as suas dúvidas sobre qual caminho escolher, e acabaram encontrando outras pessoas com visões parecidades e que ajudaram a trilhar o seu próprio caminho.

Ainda estou bem no início desse caminho, portanto não há nenhum resultado expressante para te conta e tentar te convencer que esse é O caminho. Aliás, acredito que o caminho do autodidata pode se encaixar para determinadas pessoas e para outras não, e não há nada de errado com isso. O importante é você escolher o seu caminho, e não deixar essa escolha para o seu chefe, pais, marido/esposa, etc.

O interessante de ser um autodidata é que a impressão que eu tinha, é que esse é um caminho solitário, afinal, muitas vezes você não tem com quem discutir sobre o assunto que você está aprendendo ou tirar uma dúvida. Porém, não é bem assim não, acabei conhecendo várias pessoas (boa parte conhecidos/amigos virtuais) e até o problema da falta de relacionamento com outras pessoas (networking), pode ser muito bem surprido, indo em eventos relacionados com as áreas de estudo.

Outro ponto bem interessante, é que como você está no comando do seu próprio barco, e desta maneira, o seu limite é até onde os seus olhos podem ver.

Além do mais, o acesso a informação está muito mais fácil e simplificado hoje em dia, eu por exemplo, consigo ter em um minuto o livro que achei interessante em minhas mãos, ou melhor, no Kindle. E sites como a Amazon, são verdadeiros oasis da informação e do bom consumismo.

Saindo um pouco do mundo dos livros, temos os blogs, que ainda são uma fonte muito rica e atualizada de informação. Na área de Teste de Software por exemplo, há excelentes profissionais escrevendo em seus blogs, tanto aqui no Brasil, como lá fora. Palestras também estão cada vez mais sendo compartilhadas em canais como o YouTube e Vimeo, e o investimento financeiro necessário é zero!

Por enquanto é isso, quando eu ler o livro, provavelmente terei mais opiniões e pensamentos para compartilhar, e este assunto voltará ao foco.

E você o que pensa sobre pós-graduações, você já fez alguma, está pensando em fazer ou está seguindo por outros caminhos?

Fique por dentro das novidades, assine o feed do QualidadeBR.

Qual o objetivo do Teste de Software?

Minha resposta para essa pergunta é bem simples e direta: obter informações.

Na lighting talk dada pelo Shmuel Gershon na EuroStar desse ano, ele fala sobre isso de uma maneira bem didática (vale a pena assistir!).

Não que as outras respostas estejam erradas, muito pelo contrário. Mas percebo que algumas são muito extensas e particularmente, gosto de simplificar as coisas.

Mas dentre as possíveis respostas para a pergunta do título desse post, há uma perigosa: encontrar bugs.

Seria como se eu perguntasse para um policial, qual o objetivo do trabalho dele e ele me respondesse que é prender os bandidos. Na verdade, esse é só um dos objetivos do policial, e encontrar bugs é só um dos objetivos do Teste de Software.

E o perigo para nós profissionais de Teste de Software, é quando os outros pensam que a nossa tarefa é só essa, ou pior ainda, quando nós mesmos nos limitamos a fazer apenas isso.

Durante a exploração do software, não podemos ficar esperando encontrar apenas bugs, precisamos focar em encontrar informações. Como o próprio Shmuel disse: ao obter uma informação, ao invés, de se perguntar se ela é algo ruim, podemos nos perguntar “o que podemos concluir a partir dessa informação?”. Parece ser a mesma pergunta, mas não é.

Além do mais, se você focar apenas em encontrar bugs, poderá perder facilmente a motivação, pois haverá dias em que você não encontrará nada, porém se você focar em obter informações, dificilmente passará um dia sem ter obtido uma informação interessante.

Notícias ruins é o que faz vender o jornal (rs) ou prender a atenção a TV, mas não se restrinja apenas as tragédias, há vários outros tipos de informações que podem ser até mais relevantes para a equipe, e que ajudarão eles a melhorar o sistema. E você não será mais visto, como o portador de notícias ruins (rs).

Fique por dentro das novidades, assine o feed do QualidadeBR.

Teste de Software: resultado da imperfeição

Ontem comecei a ler o livro “O Ócio Criativo” do Domenico de Masi. E logo no começo, em uma das perguntas feitas pela entrevistadora Maria Serena Palieri ao de Masi, ele traz um insight muito interessante, no qual valoriza as imperfeições do ser humano.

Para entender melhor, reproduzo abaixo o trecho do livro em questão:

Quais foram, então, os momentos da História nos quais nós, seres humanos, atravessamos encruzilhadas, vimos que o mundo virava de cabeça para baixo, se torna “um outro” mundo?

Um primeiro longo período da história humana vai de setenta milhões a setecentos mil anos atrás. Durante esse período, quem vivia não percebia nenhuma mudança, se sentia sempre igual. Trata-se da longuíssima fase na qual o homem criou a si mesmo: aprendeu a andar ereto, a falar, a educar a prole.

Se refletirmos bem, estas são mudanças extraodinárias, todas elas decorrentes da compensação dos nossos defeitos. Rita Levi Montalcini explicou isso muito bem no seu livro L’elogio dell’imperfezione (O elogio da imperfeição). Tínhamos um olfato fraco, portanto não podíamos perseguir a caça farejando a terra, como fazem os animais, mas tínhamos que avistá-la: para isto devíamos caminhar de pé, já que a caça frequentemente fugia, desaparecendo na vegetação. Isto fez com que se tenham salvado somente aqueles indivíduos da nossa espécie que se tornaram mais aptos para caminhar eretos.

Tal fato nos faz entender melhor o surgimento de várias áreas e tecnologias. E uma das áreas decorrentes da imperfeição humana, é a de Teste de Software.

Todos conhecem aquela frase que diz que “errar é humano”. E a probabilidade da ocorrência do erro ainda pode ser maior dependendo do ambiente em que estamos inserido. Sendo que quando falamos de um ambiente de desenvolvimento de software, logo lembramos de palavras como: prazo, complexidade, pressão, dentre outras.

Portanto, os profissionais de TI acabaram ao longo do tempo, percebendo a importância de se testar o software, sendo ela uma ação derivada da imperfeição humana. Afinal, seria um desperdício de tempo e esforço testar algo produzido pelo ser humano, se ele fosse perfeito.

É interessante notar, que graças as nossas imperfeições, fomos forçados a nos adaptar melhor ao ambiente em que vivemos e ao longo da história da humanidade, grandes inventos foram feitos, justamente para tentar contrapor tais imperfeições.

Voltando ao texto do livro, podemos interpretar que ao aprender a andar ereto, diminuímos os riscos de não conseguir comida. E pensando no mundo do desenvolvimento de software, o Teste de Software acaba também diminuindo riscos, no caso, os riscos associados a qualidade do produto/serviço que iremos entregar ao cliente.

E a lição que podemos tirar de tudo isso, é que é importante reconhecer as nossas limitações e erros, e mais importante ainda, é buscar agir para contrapô-los. Sendo assim, testar um software acaba sendo uma das ações que podemos executar, para contrapor o fato de que não produzimos software perfeito.

Fique por dentro das novidades, assine o feed do QualidadeBR.

Tire a gente da Área 51

O Felipe Knorr Kuhn teve a iniciativa de criar um repositório para perguntas sobre Teste de Software no StackExchange (mesma plataforma do StackOverflow e que foi criado pelo grande Joel Spolsky e o Jeff Atwood) .

Abaixo, falo mais sobre esse repositório, baseado no e-mail do Felipe, que foi enviado para algumas listas de discussões.

O que é o StackExchange?

Assim como o StackOverflow, ele é voltado para armazenar perguntas e respostas, tendo funcionalidades como por exemplo: “tagear” perguntas e avaliar respostas e perguntas,. O legal do StackExchange, é que ele te permite criar o seu próprio repositório de perguntas e respostas, onde uma comunidade fica responsável por ele.

Se quiser ver um exemplo prático de uso do StackExchange, você pode clicar no link abaixo, para o repositório de Teste de Software internacional, onde pessoas como o Matthew Heusser, Justin Hunter e o Shmuel Gershon participam:

http://testing.stackexchange.com/

Que área 51 é essa?

Para pode ter um repositório no StackExchange é preciso passar por três etapas:

• Definição: Precisamos de 60 pessoas “seguindo” a proposta e algumas perguntas que sirvam de bom ou mal exemplo para o assunto;
• Comprometimento: Uma vez que a etapa de definição tenha sido atingida, precisamos de pessoas que decidam dar suporte à comunidade, fazendo ou respondendo perguntas;
• Beta: É o site finalmente no ar, sendo utilizado pela comunidade.

Enquanto o nosso repositório não passar por essas três etapas ele fica numa área “secreta”, chamada área 51, uma boa analogia do pessoal do StackExchange com a Área 51 (rs).

Qual a diferença desse repositório para as listas de discussão?

O foco do StackExchange é armazenar perguntas e respostas, sendo assim a primeira diferença é que o repositório será voltado para responder perguntas relacionadas com Teste de Software. Já numa lista de discussão os assuntos podem ser mais variados, desde discussões até divulgação de eventos.

Particularmente, acho bem legal o StackOverflow (onde sempre caiu quando pesquiso por alguma exceção ou problema que estou buscando resolver), e por isso, acho que o nosso repositório no StackExchange pode ser bem legal, afinal ele é focado em perguntas e respostas, e isso pode facilitar tanto a vida de quem quer ajudar, quanto de quem está querendo ajuda.

Agora se vai dá certo ou não, só o tempo poderá dizer. 🙂

Se você achou interessante a ideia e quer participar, acesse o link abaixo para seguir o repositório e por favor, divulgue na sua empresa, grupo de amigos, etc. 😀

http://area51.stackexchange.com/proposals/10120/teste-de-software

Fique por dentro das novidades, assine o feed do QualidadeBR.

Quais ferramentas podem apoiar o Teste de Software?

A 24ª edição da Mesa Redonda DFTestes teve como tema “Quais ferramentas podem apoiar o Teste de Software?”. A discussão teve 14 respostas e 10 participantes, sendo eles: eu, Regiane Ribeiro, Rafael Silva, Rodrigo Almeida, Felipe Silva, Shmuel Gershon, Sarah Pimentel, Elias Nogueira, Ueslei Aquino e Humberto Barboza.

Abaixo faço um “resumo” da discussão, quem participa do grupo DFTestes pode acessar a discussão na íntegra, neste link.

Quais ferramentas podem apoiar o Teste de Software?

O Shmuel Gershon fez um comentário bem interessante:

A ferramenta mais útil em meu trabalho como testador é o quadro-branco (é, aquela lousa na parede mesmo, link).

Ferramentas são essenciais:

A menos que o testador tenha algum super poder de manipulação de bits e transistores com a forca da mente, ele vai precisar de um teclado, um mouse, um sistema operacional. Não dá pra testar sem ferramentas.

A pergunta é “quanto vamos deixar a ferramenta guiar o processo?”

E aí entram todas as ferramentas — as de geração de dados, as de controle de versão, as de gestão de testes — quanto nos deixamos a ferramenta decidir por nos?

Minha opinião é que se em algum momento você toma alguma ação por que é assim que a ferramenta faz, a ferramenta já está passando do seu limite. Ela trabalha pra você, não o inverso.

Segundo a Sarah Pimentel:

Qualquer uma que torne sua vida mais fácil, lembrando o que o Shmuel falou: A ferramenta trabalha pra você e não o inverso.

Eu concordo plenamente com o Luke Skywalker, que dizer Shmuel! 🙂

E acho que o ponto que ele  colocou, mostra bem um dos motivos pelos quais muitos profissionais ainda usam planilhas. Afinal, a planilha é totalmente customizada para a sua necessidade, você não tem que ficar preenchendo campos com blá-blá.

Quando optar pelo uso de uma ferramenta, ao invés, de um processo manual?

De acordo com a Sarah Pimentel:

– Quando o processo manual for difícil de manter/executar;
– Quando houver planejamento (tempo para aprender a ferramenta, tempo para verificar necessidades de adaptações na ferramenta e realizá-las…);
– Quando o processo de teste estiver maduro (mas ele pode amadurecer usando ferramentas também).

Para o Elias Nogueira precisamos ter o controle sobre o processo antes de buscar ferramentas:

Quando você já tem todo o controle sobre o processo e onde a aplicação dessa ferramenta não traga riscos ou grandes adaptações ao processo de teste

O Ueslei disse que:

Sabemos que em cada uma das fases do ciclo de vida, diversas são as atividades e técnicas a serem realizadas afim de gerar os produtos de cada uma das fases e, com toda certeza cada uma delas podem ser facilitadas com o uso de ferramentas. Mas, um fator que vejo de extrema importâncias é:

O profissional de teste precisa primeiro entender as técnicas de teste para então entender quais ferramentas devem ser usadas para cada técnica.

Como colocado pelo Elias Nogueira, eu reforço: O emprego de uma ferramenta errada na vez de ajudar se torna um grande risco para o projeto.

Então a melhor ferramenta é aquela que melhor atende ao processo de teste da organização e nem sempre, a ferramenta ideal para uma organização será ideal para outras. Com isso, um fator de importância é o estudo de viabilidades das ferramentas antes de sua aquisição e implantação de uma ferramenta na Organização. Esta prática pode eliminar o risco de, apenas no meio do projeto, descobrir que a ferramenta empregada não atende.

De acordo com o Humberto Barboza:

O uso de ferramentas sempre foi mesmo motivo de discussão na nossa área. Em relação a ferramentas de teste automatizado, alguns pontos devem ser questionados quando pensamos nisso. Por exemplo, uma ferramenta faz automaticamente tudo que fazemos manualmente, ou seja, ela não têm capacidade intelectual, então, o ganho de sua utilização está no tempo de execução. Porém, precisamos saber se fatores como: custo da ferramenta, prazo (Tempo de aprendizado), negócio do cliente, tipos de teste (Pra regressão é uma boa), serão adequados ao seu uso.

Em relação a outros tipos de ferramenta, considero algumas muito importantes no processo de teste. As de Gestão de Defeitos (Mantis, Trac), Gerência de Configuração (ClearCase, VSS) são bastante eficientes pois têm aprendizado e manutenção relativamente fáceis. E confesso que depois de algum tempo as utilizando ficamos dependentes das mesmas. Hoje mesmo, quero voltar a utilizar o Trac ou a HP Quality Center porque na empresa atual meu processo está todo manual com planilhas excel.

Adotamos o scrum e gostaria bastante de utilizar estas ferramentas, mas, hoje tenho um problema em que a equipe de desenvolvimento prefere o quadro afirmando que a visualização das tarefas e defeitos através dele são fundamentais para o sucesso da metodologia. Então, penso em como não ter retrabalho neste cenário, visto que neste caso teremos que incluir na ferramenta e também no quadro.

Quando o desenvolvimento de uma ferramenta internamente pode ser a melhor escolha?

A Sarah Pimentel respondeu dizendo:

Essa é uma análise que deve levar em conta:
.. atendimento às necessidades;
.. custo;
.. usabilidade;
.. tempo.

Segundo o Elias Nogueira:

Quase que jamais!!!!
Atualmente existem diversas, mas diversas ferramentas para a apoiar o processo de teste.
Já vi muitos casos que as empresas criam ferramentas de bug tracker, que é o mais comum, mas a alocação de um profissional e o tempo que a ferramenta leva para ser desenvolvida não justifica o custo de até comprar e customizar uma ferramenta…
Mas, quem sou eu pra dizer que a empresa X está errada em desenvolver uma ferramenta para o apoio aos testes.

Na verdade, creio que o único momento que podemos nos ‘dar ao luxo’ de desenvolver uma ferramenta internamente é referente a automação nos níveis unitários, de integração e de sistema. Já peguei projetos onde eu não conseguia nenhuma ferramenta e tive que criar uma arquitetura automatizada para testar um sistema de mensageira.

Só uma aviso aos novatos: muito se fala em utilizar e implantar o Mantis e Testlink para dar “velocidade” ao processo e ter um ponto centralizado. Mas iniciem conhecendo os conceitos dessas ferramentas (gestão de defeitos e gestão de testes), faça manualmente e depois implemente, se necessário, uma ferramenta.

A ferramenta que deve se adequar ao nosso processo, e não o contrário!

O Humberto respondeu a pergunta dizendo:

Penso que somente quando o negócio é muito específico e a adaptação à ferramenta inviável. Mas, quase sempre nesses casos vale mais a pena continuar com o processo manual.

Sobre o que o Elias disse, eu acho que é de se considerar a possibilidade. Principalmente, em se tratando de sistemas não web. (mas esse já é um tema de outra mesa redonda)

Bem pessoal é isso. Continuem de olho na lista do DFTestes, pois sempre há assuntos bem interessantes lá, e poderão haver novas respostas nessa mesa redonda.

Fique por dentro das novidades, assine o feed do QualidadeBR.

Padronização de caso de teste. Pluralizado ou integrado?

A 23ª Mesa Redonda DFTestes foi sobre “Padronização de caso de teste. Pluralizado ou integrado?”. A discussão até o presente momento, teve 23 respostas e 8 participantes sendo eles: eu, Felipe Silva, Elias Nogueira, Edwagney Luz, Renata Eliza, Shmuel Gershon, Sarah Pimentel e Lucas Nadalete.

A mesa redonda começou bem fria, estava dando pinta que nem iria dar muita discussão, mas de repente, ela estourou. E vários comentários relacionados ao assuntos foram feitos, boas analogias e explicações foram feitas, mas até o momento não conseguimos saber o que é um caso de teste pluralizado e integrado. :s

A seguir, faço um resumo dessa excelente mesa redonda, que é altamente recomendável a sua leitura na íntegra, pois vários assuntos foram discutidos durante a mesa redonda, e como sempre faço o resumo focado no tema da discussão, alguns bons comentários sobre outros assuntos ficam de fora.

Padronização de caso de teste. Pluralizado ou integrado?

Até o momento desse post, ninguém conseguiu explicar o que seria um caso de teste pluralizado ou integrado. Tal terminologia, provavelmente deve ser bem específica, já que ninguém, tinha ouvido ela antes.

E falando em termos, o Edwagney fez um comentário bem pertinente:

Sinceramente, não vejo nenhum motivo para acrescentarmos mais conceitos como “Pluralizado ou Integrado”. Acho totalmente desnecessário!

Na minha opinião, realmente é desnecessário criar novos termos, principalmente, quando eles não são “auto explicativos”.

O Elias Nogueira fez uma interpretação que se não é a correta em relação aos termos é correta em se tratando de casos de teste:

Se eu interpretei bem o enunciado dessa mesa redonda, e seria interessante o outro desse tópico explicar, é a diferença entre o pluralizado e o integrado.
Pelo entendimento que tenho disso, creio que seria:

• Pluralizado: Casos de teste distintos. Esses seriam como: Inserir Cliente com sucesso, Inserir Produto com sucesso, Emitir NF, Calcular impostos, etc… Logo um Caso de Teste no cenário: “cada um no seu quadrado”. Cada um executa uma ação específica para o que ele realmente é proposto
• Integrado: Casos de Teste que “agrupam” todos os testes a fim de chegar a um objetivo comum. Seria como eu criar apenas um Caso de Teste para Emitir uma NF, sedo que tenho passos do cadastro do cliente, cadastro de produtos, calculo de impostos, etc…

Se for nessa linha de pensamento, e na minha linha purista, os Casos de Teste Pluralizados são os corretos, e não existe qualquer outra nomenclatura ou “agrupamento” de Casos de Teste. O que criamos quando temos uma linha parecida com o Integrado são Cenários de Teste.

Padronização de caso de teste. Detalhado ou resumido?

O Felipe Silva acabou sugerindo a questão “Padronização de caso de teste. Detalhado ou resumido?”, no lugar da questão tema da mesa redonda, por essa terminologia ser mais conhecida. A respeito da questão, o Felipe mesmo deu a sua opinião dizendo, subentendo que pluralizado seria um caso de teste mais resumido e o integrado um caso de teste detalhado:

Se eu entendi corretamente, pluralizado seria um caso teste escrito de forma genérica, que não contém detalhes específicos, e integrado seria aquele caso de teste com o máximo possível de step detalhados com toda informação específica, o famoso caso de testes “que até minha mãe conseguiria ler, executar e avaliar o resultado”.

Se for mesmo isso, prefiro o modelo básico (pluralizado), este é mais fácil de ser escrito e mantido, porém os detalhes que não estão escrito precisam estar na cabeça de quem executa, portanto exige que sejam executados por experts no projeto.

Já houve uma discussão sobre o tema no DFTestes.

Para mim, seguindo o entendimento do Felipe, a resposta para a pergunta depende do contexto em que se está testando. Como o Felipe disse, o genérico/pluralizado exige que o testador tenha domínio sobre as regras de negócio e a aplicação. Já o detalhado/integrado não exige um domínio sobre as regras de negócio e a aplicação por parte do testador.

Outros pontos interessantes, é em questão da manutenibilidade, estabilidade e velocidade. O caso de teste genérico/pluralizado tem maior manutenibilidade e estabilidade, pois como ele é mais a nível do que fazer e não como fazer, acaba sendo mais curto, portanto mais fácil de manter, e é menos “quebrável”, já que não entrar em detalhes de implementação (ex.: nome do campos). Já em questão de velocidade, mais uma vez o teste genérico/pluralizado leva vantagem, pelo mesmo motivo de que ele é mais fácil de manter.

Resumindo, se você é quem especifica os casos de testes e testa, ou você é um testador já experiente, então o mais indicado pode ser o caso de teste genérico/pluralizado. Agora se quem irá executar os testes não tem pleno conhecimentos das regras de negócio e da aplicação, ou ainda, os testes podem ser reutilizados num futuro (exemplo manutenções no software), o mais indicado pode ser o caso de teste detalhado/integrado.

O Elias Nogueira acredita que um bom caso de teste precisa ser detalhado, segundo ele:

Quanto a isso, ainda sou meio “purista” e creio que um bom Caso de Teste precisa ser detalhado. Precisa sim conter os passos como condições de uso e ser muito bem estruturado.

Existem sim várias formas de criar os Casos de Teste no Test Design, sendo o mais usual a de Heumman para criar os Casos de Teste a partir dos Casos de Uso.

O que define o grau de detalhamento são os tipos de teste para qual o(s) Caso(s) de Teste estão sendo escritos.
Quando vou escrever um Caso de Teste em nível Unitário, obviamente ele será diferente do de Sistema que estamos acostumados a criar. Escrever um Caso de Teste para algum cenário de Performance também é diferente de um Caso de Teste Aceitação.
Os Casos de Teste podem ter a entrada do seu processo os seguintes fatores:

• Requisitos de Negócio
• Interface com o Usuário
• Domínio de entradas

Com o detalhamento, a equipe vai saber de regras que nem o Analista de Requisitos/Sistema saberá mais depois de 1 semana… e pra onde vai o conhecimento dessas regras?
Outro ponto também é que com um Caso de Teste detalhado, qualquer um na tua equipe, ou qualquer um que entrar na equipe, poderá ter um conhecimento maior da aplicação na execução destes Casos de Teste.

Claro que, em nossa realidade isso muda constantemente. Eu trabalho hoje num “Fábrica”, e sou obrigado a escrever Casos de Teste detalhados para os Testadores, que as vezes nem conheço. Se eu não fizer isso, posso deixar aspectos importantes passar não pelo pouco detalhamento do Caso de Teste, e sim da interpretação do Testador.

Já na realidade de quem não trabalha em uma Fábrica, creio que o nível de detalhe não é alto pelo alto conhecimento da aplicação que estes profissionais já tem.

A respeito da opinião do Elias, eu não acho que seja uma questão de qual é o melhor detalhado ou genérico/resumido. Ambos tem os seus pontos positivos e negativos. O importante é que o profissional de teste saiba da existência dos dois, pois é ele quem irá decidir por optar um ou outro.

A Renata Eliza deu a sua explicação sobre o caso de teste Step by Step (o famoso passo a passo), que seria o detalhado e o cenário de teste, que seria o mais resumido:

Acredito que as distinções dos Casos de Teste teriam mais sentido se fossem do tipo:
– Casos de Teste Step by Step: quando o objetivo é cercar, através de casos de teste detalhados todas as possibilidades de um determinado documento da especificação. Como por exemplo, o Caso de Uso.
– Cenários de Teste: que dá uma ideia mais generalizada do que deve ser testado naquele determinado cenário. Mais voltado para profissionais experientes, que têm a visão do que realmente precisam fazer.

O Edwagney falou sobre caso de teste detalhado, fazendo importantes considerações que nos podem levar a escolher ele:

Também não acho interessante que sejam elaborados apenas casos de teste detalhados. Isso depende muito da empresa que está usando o processo e como ela deseja documentar isso. Para uma empresa que existe grande rotatividade de profissionais, talvez seja interessante um maior nível de detalhe, entretanto, outra que tem uma política de manter seu grupo e treinar novos profissionais, o detalhamento fará um efeito contrário. Ao invés de ajudar, vai atrapalhar, pois o grupo é coeso e experiente, e não necessita de um alto nível de detalhamento para que o caso seja executado com qualidade e dê o resultado que se espera. Digo isso porque já trabalhei com esses dois tipos de empresas.

Nas consultorias que faço e nas empresas que eu trabalhei com isso, quando elegemos um caso de teste passivo de automatização, onde chegamos a um nível de detalhamento que seja possível sua automatização. Para os que não é possível a automatização, o nível de detalhamento segue sempre o bom senso e a forma de trabalhar da empresa

Coloco também uma outra variável para incrementar a questão, depende também do ramo de atuação da empresa. Se ela for especialista demais e seus profissionais idem, ao detalharmos os casos demais, ninguém usa e o processo cai todo por água abaixo. Um exemplo muito bom é a área de Telecom. É uma área tão específica e tão especialista, que para uma pessoa conseguir executar um tipo de teste, tem que ter uma série de requisitos básicos, que se formos colocar todas essas informações em um caso de teste, seria gasto tanto tempo que se tornaria inviável. E quando a pessoa já está devidamente treinada, ela não usa os casos detalhados, pois eles, ao invés de ajudar, travam a produtividade. Isso em caso de teste manual.

O Edwagney ainda deu uma excelente e bem didática explicação sobre a “cadeia”  dos casos de testes:

Faço a comparação com uma peça teatral, onde o nome da peça, seria a suíte de testes; os cenários, naturalmente os cenários do teste; as cenas, os casos de teste; e os atos dos atores a sequencia de execução cada cena ou caso de teste.

A Sarah Pimentel deu a sua opinião sobre a questão dizendo:

Entre um caso com mais detalhes e outros com menos, pra mim a resposta é como a da maioria das mesas redondas que temos: depende 😛

Se temos um caso de teste detalhado demais, e temos a política de capturar telas que comprovam a execução de cada passo, começa a ser um trabalho enfadonho, especialmente os testes de regressão que executamos inúmeras vezes.

Se temos um caso de teste genérico demais, corremos o risco de o testador não entender bem o step ou não verificar todos os pontos que o autor imaginou que ele verificaria.

Pra mim, assim como um documento de requisitos, o caso de testes está bom quando especifica tudo e não deixa brechas para interpretações. Se algo precisa ser verificado, deve estar explicitamente detalhado em algum passo. Se algo não precisa de tanta atenção (pode ser o caso de alinhamento de labels, nomes de campos que mudaram para outros similares, cores, posicionamento de objetos)… Não precisa estar descrito. Não que esses itens não devam ser testados, mas tem aplicações nas quais isso é um fator importante e outras em que não. Então depende do teu objetivo.

Para casos de teste que exigem uma busca um pouco mais complexa de dados, por exemplo, bastaria eu dizer que eu preciso de “um contrato de manutenção de hardware válido para atendimento físico com SLA de 48h” ou eu colocaria na pré-condição uma query que trouxesse esses tipos de contrato para o testador? Pouparia bastante tempo se ela já estivesse lá. E essa é uma decisão, pra mim, similar a de cima. Se vamos ganhar tempo e acuracidade, opto por detalhar. Se vamos burocratizar e onerar a manutenção e a execução, opto por generalizar.

O Lucas deu a sua opinião contando um pouco da sua experiência:

Na empresa onde trabalho temos situações onde as especificações dos Casos de Teste tendem a ser mais detalhadas quando dispomos de um prazo aceitável, escopo e especificação de Caso de Uso bem definidos e o profissional responsável por automatizar ou executar manualmente os testes não possui muita experiência a respeito do ambiente e negócio; já por outro lado, também nos deparamos com situações onde os Casos de Teste tendem a ser definidos de uma forma bem mais genérica, sem muitos detalhes (step-by-step), com uma descrição mínima do Caso de Teste, das entradas e das saídas esperadas. Este segundo ocorre principalmente quando há um cronograma bem mais enxuto que o esperado e o testador é alguém que conhece muito bem as regras de negócio do produto/projeto alvo.Em outras palavras, a forma como os Casos de Teste são especificados, varia e bastante. Sou extremamente a favor de se trabalhar com Casos de Teste Padronizados, mas se analisarmos com calma nem sempre as variáveis envolvidas são favoráveis, tais como: cronograma, artefatos (especificação de caso de uso, requisitos, …), ambiente, experiência do testador (técnica e negócio), automatizado/manual, enfim; e por serem elementos variáveis, os mesmos tendem a impactar na forma como os Casos de Teste são definidos, quando realmente são definidos.

Como exemplo, quando o testador tem pleno conhecimento do contexto de negócio, e o script de teste tende a ser automatizado, os Casos de Teste aqui na empresa são especificados genericamente, e o detalhamento (step-by-step) do teste fica por conta do script. Apesar de não ser a melhor prática, principalmente do ponto de vista de manutenibilidade, isso nos possibilita trabalhar a especificação dos Casos de Teste, automatização dos scripts, execução dos testes e gestão de defeitos, dentro do prazo esperado para as entregas/implantações.

Cuidado com o que você chama de caso de teste

O Elias fez um comentário bem pertinente sobre o que chamamos de caso de teste:

Uma outra coisa que não posso deixar de comentar: os que até hoje tratam em alguns lugares o Caso de Teste como sendo um passo. Aquelas planilhas em Excel gigantes, onde um profissional fala que tem 5.000 Casos de Teste, que na verdade são passos.
Isso pra mim é a pior coisa que um profissional pode fazer, além das empresas que vendem a atividade de criação de Casos de Teste por quantidade.

Sobre o assunto, o Lucas fez o seguinte comentário:

A respeito das famosas planilhas Excel, é extremamente importante não confundir um “caso de teste” por mais genérico que seja, com uma linha em uma planilha eletrônica que na realidade representa um simples “passo”. Já me deparei com situações onde a própria equipe de desenvolvimento gera uma planilha dessas com os testes executados por eles mesmos, e ao realizarem a entrega repassam o artefato como quem diz: “aqui estão as entregas e estes são os testes executados, só refazer”, ou seja, totalmente sem fundamento. Diante de uma simples “verificação” é possível evidenciar vários fluxos (alternativos ou de exceção) que não foram contemplados, bem como validações efetuadas incorretamente.

Bem pessoal é isso. Continuem de olho na lista do DFTestes, pois sempre há assuntos bem interessantes lá, e poderão haver novas respostas nessa mesa redonda.

Fique por dentro das novidades, assine o feed do QualidadeBR.

Quem é o grande vilão do Teste de Software, o bug ou o tempo?

A 20ª Mesa Redonda DFTestes teve como tema “Quem é o grande vilão do Teste de Software, o bug ou o tempo?”. A discussão teve 9 respostas e participantes, sendo eles: eu, Sarah Pimentel, Luís Barros, Shmuel Gershon, Rodrigo Almeida, Felipe Silva, Elias Nogueira, Humberto Barboza e Talita de Oliveira.

Abaixo, faço um “resumo” de como foi a discussão, sempre lembrando que quem quiser ela na íntegra é só acessar esse link (é necessário se inscrever no DFTestes).

Quem é o grande vilão do Teste de Software, o bug ou o tempo?

Segundo a Sarah Pimentel:

Tanto o tempo quanto os bugs são vilões, quem está sendo pior depende do projeto, eu acho. Existe tanto aqueles sistemas onde nenhuma pratica de prevenção de defeitos foi aplicada e chegam com bugs críticos que bloqueiam e atrasam testes, quando os projetos nos quais a definição de requisitos atrasou, a arquitetura atrasou, o desenvolvimento atrasou mais ainda e o tempo do teste ficou reduzido a 25% do que era antes e claro que sempre esperam que a equipe de testes faça milagres porque só ela não pode atrasar.
Quanto aos bugs podemos atacá-los através de processos de prevenção de defeitos e quanto ao tempo, revisando o planejamento, implementando um processo de gerenciamento de mudanças e procurando alinhar a equipe de vendas (normalmente o tempo começa a ser um problema já na venda do projeto) o que realmente é possível entregar no tempo acordado.
Apesar do desejo intimo de ter a aplicação 100% testada, sabemos que isso é dito como impossível. Para isso, há algumas técnicas que nos ajudam a selecionar/priorizar testes para que possamos aproveitar nosso tempo da melhor maneira possível.

O Luís Barros deu a sua opinião dizendo:

Na minha opinião o TEMPO hoje é o grande vilão do teste de software.

O TEMPO compromete as verificações de documentação que, antes mesmo de ter uma aprovação formal já estão na mão dos desenvolvedores, pois o prazo já está apertado;
O TEMPO faz o desenvolvedor passar por cima dos testes unitários e de integração;
O TEMPO faz o prazo do time de teste ser reduzido. Aliás, a gente sofre muito com isso, pois o que é cortado primeiro de um projeto é sempre o teste;
O TEMPO faz um projeto ser “baseado em funcionalidade” (Funcionou tá bom!), onde só o “Caminho Feliz” importa.

E finalmente…
O TEMPO causa mais bugs pois, se tudo o que foi mencionado não acontecesse, certamente teríamos um software com muito menos bugs

Uma frase que já ouvi muito de caciques: “Não entregar tem um impacto muito maior do que entregar com erros!”

O Shmuel Gershon tem uma opinião diferente do pessoal:

Vilões? Ahn?

Primeiro, por que o bug seria um vilão? Se fosse um vilão, não ficaríamos tão feliz de achar um.
Acho que os bugs, longe de ser os vilões, são nossas bat-ferramentas, essenciais para sermos bons heróis. São eles que nos permitem aprender, e que nos permitem ensinar e transmitir informação adiante.

Segundo, por que o tempo? Tempo é o melhor amigo da qualidade de software. Se não tivessémos tempo suficiente, não ia dar pra fazer nada direito!
E a falta de tempo? Outro melhor amigo da qualidade, especialmente porque este fica do lado do cliente, defendendo seu valor — já pensou se ainda não tivéssemos recebido o Windows 97? não teria como avançar a tecnologia até chegar no Win7.

Bugs e Tempo, para ser vilões, só neste link e neste link. 🙂

O verdadeiro vilão dos testes, sou eu.
(não, não por que eu fico aqui contrariando todo mundo na DFTestes!)
Mas por que eu concordo com mas decisões, em vez de trabalhar com meus gerentes para tomar a decisão certa.
E porque eu não sou capaz de explicar toda a extensão do impacto de uma mudança no cronograma.
E porque as vezes uso métricas que em vez de ajudar, estão atrapalhando a operação.

É dura, esta vida de herói e vilão ao mesmo tempo…

Minha linha de pensamento sobre o assunto é bem parecida com a do Shmuel.

Todos são culpados! Até que se prove o contrário.

Em algumas organizações é muito fácil botar a culpa em fulano ou ciclano, principalmente, quando temos caciques (como lembrou o Luís), ou pessoas que gostam do poder, de tomar decisões sozinhas, etc.

Eu particularmente, vejo que o desenvolvimento de software é algo muito complexo, para um único ser humano levar a culpa. E por isso, sou a favor de quando algo de ruim acontece (“shit happens”), todos sentarem para buscar os fatores e a causa raiz para aquele problema ter ocorrido, deste modo todos evoluem e tem a oportunidade de discutir.

Nenhum dos dois são vilões, são apenas efeitos causados por seres humanos.

Porém, “o primeiro” bug, era sim um vilão, aquela traça maldita! rsrs

Hoje acredito que nenhuma falha acontece por causa de uma trasa, elas acontecem porque pessoas desenvolveram aquele sistema. E pessoas cometem erros, lembre-se errar é humano.

E como o Shmuel disse: “É dura, esta vida de herói e vilão ao mesmo tempo…”

O Rodrigo Almeida enfatizou a importância de termos um processo alinhado com a equipe de desenvolvimento, para podermos tornar o tempo o nosso amigo:

É preciso ter estratégia.

Estratégia para achar o bug nos testes críticos.

Tem que ter processo definido e alinhado com a equipe de desenvolvimento.

Desta forma o tempo vira aliado e não inimigo!

Segundo o Felipe Silva:

–  O tempo é um fator neutro, quem faz ele parecer mau ou bom é a “áurea espiritual da entidade responsável pela estimativa e cronograma”, se está estiver acima do “limite mortal humano” então o tempo leva a culpa mesmo sendo algo constante, caso contrário o tempo leva a culpa pelo desperdício de orçamento? Esta segunda resposta é única e exclusiva da “índole da(s) entidade(s) superior(es)”. Falando claramente tempo vilão = planejamento não reflete a realidade, isso também não quer dizer que o planejador é o culpado, a não ser que ele seja capaz de prever o futuro, mas ele é no mínimo cúmplice (rs).

– O bug pode ser um vilão, principalmente para nós responsáveis pela qualidade, mas é este também “paga meu salário todo mês”, estão se eu colocasse em uma balança ele é mais meu amigo do que meu inimigo, sobre o bug só posso dizer ele é mais previsível do que o tempo, embora não seja possível testar 100% do software é possível testar a parte mais usada e deixar o bug hibernando por tempo indeterminado, contanto que este não acorde ninguém vai reclamar.

Se for para pesar Tempo x Bug eu diria que o tempo tem maior peso, pois a falta deste primeiro ajuda o segundo ser um risco maior.

O Elias lembrou bem, que muitas vezes o grande vilão é a cultura da empresa:

O principal vilão do Teste de Software é a cultura!!!
Em um software de missão crítica ou relacionados (aviões, máquinas médicas, etc…) nem o tempo nem o bug serão um “vilão”, pois a cultura cultivada dentro de uma organização que desenvolve e testa um software dessa linha está preocupado com a qualidade.

O que nós enfrentamos no nosso dia-a-dia é prazos curtos e uma quantidade grande de bugs dado também a pressão colocada sobre a área de desenvolvimento para entregar ‘qualquer coisa’ de uma forma mais rápida.

Uma empresa que preza por uma cultura de qualidade dificilmente terá como o vilão o bug ou o tempo!

O Humberto Barboza deu a sua opinião dizendo:

Respondendo a pergunta e concordando com alguns, dentro do nosso paradigma de teste de software o tempo é o grande vilão.

Infelizmente para a nossa atividade nunca dispomos dele para realizar o trabalho ótimo. E na grande maioria das vezes somos obrigados a fazer o melhor trabalho que pode ser feito, priorizando as atividades, dentro do tempo que dispomos.

Claro que essa discussão como já pudemos perceber nessa mesa redonda envolve muitas variáveis: a cultura da organização passada hierarquicamente abaixo de que o teste pode ser cortado se não houver tempo, a pressão sobre a equipe de desenvolvimento que entrega o produto sem a qualidade esperada porque não realizou devidamente os testes unitários e de integração, a pouca importância dada a fase de planejamento dos testes e a adoção da estratégia “Sair fazendo” sem o devido planejamento, padrões engessados (inclusive estou sofrendo pra caramba com isso no momento, porque adotamos o Scrum, mas, com os padrões de documentos existentes hoje é inviável trabalhar e estou tendo que pensar no meio do sprint, por que não houve tempo antes rsrs, em como adaptar e gerar métricas no cenário atual visto que sequer utilizamos uma ferramenta de controle de defeitos).

Liderança desinteressada que deixa exclusivamente a cargo do QA todas decisões, por hora acho que é isso.

A Talita de Oliveira respondeu a pergunta dizendo:

Bom, pelos projetos que atuei, a maioria dos problemas em fase de teste foi o tempo, mas no meu ponto de vista uma coisa leva a outra, como disse o Humberto tem a ver com a cultura da empresa. Digo que uma coisa leva a outra pelo fato da pressa, como já diz o ditado que pressa é inimiga da perfeição, dificilmente um time de testes por mais competente que seja não conseguirá entregar um projeto com a % mínima de bugs se não houver tempo. E essa falta de tempo acontece porque a fase de testes na maioria dos projetos está no final, pelo menos é assim que tenho trabalhado…em fases finais.
E quanto a equipe de testes aceitar desafio, é normal, pois ao longo da minha experiência a pressão sempre foi alta porque ouvi sempre: “Vocês são a parte final do projeto” ou “Vocês que dirão se a aplicação está ok ou não”. Então..acho que não só a equipe de testes é culpada, mas todos os envolvidos tem sim sua parcela de culpa.

Por que gostamos tanto de terceirizar a culpa?

A Sarah Pimentel lembrou que é sempre mais fácil terceirizar a culpa:

Se eu assumo que a culpa é minha ou que eu tenho qualquer responsabilidade sobre o que está acontecendo, eu sou forçada fazer algo a respeito. Se eu jogo a culpa no outro, o problema é dele e ele que se vire pra resolver, não impacta no meu dia a dia. Fiz uma vez um treinamento de relações humanas e meu professor me disse algo óbvio: não podemos mudar os outros, a não ser que eles mesmos estejam procurando uma mudança. Então se há uma situação que você quer resolver, ao invés de esperar pelo outro, procure em você o que você pode fazer para mudar a situação e naturalmente (na maioria das vezes) o outro vai ser influenciado pela sua mudança de comportamento.

Na minha opinião é da natureza do ser humano culpar o próximo. A Dorothy Graham falou um pouco sobre isso no CInTeQ 2010, contando que irmãos mais velhos, gostam de colocar a culpa nos mais novos (eu mesmo fiz isso muitas vezes rsrs).

Quando crescemos aprendemos que podemos botar a culpa não são nas pessoas, mas também no processo, metodologia, ferramenta, bug, tempo, etc. E assim fazemos, quantas vezes você já ouviu falar que vários projetos falharam por causa que usavam o modelo Cascata. Mas quem escolheu usar o modelo Cascata? As pessoas não foi!?

Segundo o Humberto Barboza:

Infelizmente quase nunca fazemos um “Mea Culpa”. Concordando com o que foi dito já na lista, boa parte da culpa é nossa que por gostar de desafios ou situações desafiadoras, aceitamos irresponsavelmente trabalhar com tempo reduzido, padrões engessados, ausência de ferramentas adequadas e até liderança inoperante, infelizmente. Tecnicamente erramos por exemplo estimando mal nosso trabalho, priorizando atividades menos relevantes e cedendo às pressões do nosso meio. Precisamos defender o nosso trabalho e demonstrar a importância de ser bem planejado, projetado e executado e qual o impacto na qualidade do produto e as consequências que pode ter.

Bem pessoal é isso. Continuem de olho na lista do DFTestes, pois sempre há assuntos bem interessantes lá, e poderão haver novas respostas nessa mesa redonda.

Fique por dentro das novidades, assine o feed do QualidadeBR.