O melhor da semana 24/01 a 30/01

Pessoal,

Segue abaixo, a lista com o melhor da semana, espero que gostem:

Você leu algo interessante, relacionado a área de Teste e Qualidade de Software, e quer compartilhar? Sinta-se à vontade em colocar nos comentários. 🙂

Abraços! E tenham uma ótima semana!

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

Quando automatizar?

A décima Mesa Redonda DFTestes teve como tema “Quando automatizar?”, e foi uma mesa redonda bem agitada, com 32 respostas (até o momento desse post) e a participação de 12 pessoas, sendo elas: eu, Elias Nogueira, Jonathan Rodrigo, Felipe Silva, Ueslei Aquino, Rodrigo Almeida, Milton Vopato, Marcelo Andrade, Shmuel Gershon, Rafael Porfirio, Sarah Pimentel e Jorge Diz.

Segue abaixo, o “resumo” da décima Mesa Redonda DFTestes, mais uma vez lembrando, que se você se interessa pelo assunto, é altamente recomendável a leitura da discussão na íntegra. 😉

Quando automatizar?

Segundo o Elias Nogueira:

Quando automatizar no sentido que não seja testes funcionais:

=> Qualquer tarefa repetitiva que gaste muito tempo no processo de teste
– Quando gastamos muito tempo criando/formatando Casos de Teste
– Quando gastamos muito tempo colhendo e gerando métricas dos testes

Quando automatizar no sentido de testes funcionais:

=> Testes de regressão
=> Smoke Tests
=> Tarefas repetitivas
=> Funcionalidades críticas do software
=> Testes com cálculos matemáticos

O interessante é que existe pelo menos um tipo de teste que somente pode ser feito automatizado (excluindo-se Portugal): o teste de performance. A base do teste de performance não é somente executar um teste e capturar o tempo de resposta, mas medir diversas outras variáveis que vão compor uma série de informações que juntas poderão dar uma visão de performance da aplicação. (Para maiores informações, consultar o Fabio Martinho) 🙂

Se falarmos em linhas ágeis (Jorge, por favor complemente), basicamente 90% dos testes são automatizados, em virtude da agilidade na entrega, conhecimento de negócio da equipe e conhecimento da equipe em ferramentas.

A respeito do comentário do Elias  sobre automação em linhas ágeis, eu penso que ela ocorre não em virtude da agilidade na entrega, e sim para garantir a qualidade na entrega, e principalmente, para garantir um desenvolvimento sustentável.

Na minha opinião os testes em nível unitário e integração também, que devem ser feitos pelos desenvolvedores, também são testes que devem ser executados de forma automática.

É bom lembrar que automação dos testes é um sonho de muitos profissionais da nossa área, porém ele pode passar a ser um pesadelo, se não for tratado de forma séria e madura (uma boa literatura sobre isso é o paper do Bret Pettichord – Seven Steps to Test Automation Success).

Pensando em uma equipe de Teste de Software, que realiza testes de sistemas, a automação é muito bem-vinda, quando há um grande volume de re-trabalho/testes de regressão.

Já pensando em uma equipe de Desenvolvimento de Software, os testes automatizados são de extrema necessidade, pois como costumam dizer, se você não escreveu testes para o seu código, você já está produzindo código legado.

Agora falando na linha ágil, a automação dos testes é essencial, olhando para o quadrante, percebemos que apenas os testes do terceiro quadrante são feitos de forma manual.

Dentre as razões citadas no livro Agile Testing, da Lisa Crispin e da Janet Gregory, estão:

  • Teste manual é demorado;
  • Reduzir a probabilidade de erros das tarefas de teste; (a tradução tá bem ruim, o original é assim: Reduce Error-Prone Testing Tasks)
  • Liberar tempo para fazer o trabalho o seu trabalho da melhor forma;
  • Prover uma rede de segurança, se eu fizer uma mudança no código eu terei os testes, que irão me avisar se eu quebrei algo;
  • Prover feedback cedo e frequente; (para mim está é a melhor razão) 😀
  • Os testes que direcionaram a codificação (ex.: TDD e BDD) podem fazer mais do que isso (ex.: se tornam testes de regressão);
  • Os testes provem documentação, aliás, são uma excelente documentação;
  • ROI, com o passar do tempo o esforço gasto na automação dos testes se paga.

A respeito do quadrante de Marick o Jorge Diz tem uma opinião diferente:

Não é bem isso, os quadrantes de Marick têm a ver com a ênfase na automação. Mesmo para os testes do quadrante superior direito (crítica do produto / voltados ao negócio) é possível ser auxiliado por ferramentas de automação. Em outros quadrantes, não se descarta o teste manual. Na prática, apenas os testes de unidade (quadrante inferior esquerdo) são inviáveis sem automação.
É bom lembrar que no modelo de teste ágil, testes são pensados não apenas como mecanismo de detecção de defeitos, mas que também é analisado seu papel de especificação do comportamento do sistema e suporte à equipe de desenvolvimento. Requisitos, testes e exemplos são aspectos diferentes das mesmas especificações. De fato, esta semana bloguei sobre isso.
A respeito sobre a automação no contexto ágil , o Jorge Diz falou que:
Você não consegue ciclos curtos de entrega se tiver que orçar um ciclo de teste manual. Você não consegue qualidade se não tiver testes que podem ser rodados à vontade. Você precisa escrever e executar os testes junto com o sistema sendo desenvolvido para encurtar o ciclo de comunicação
com o cliente e não perder tempo e esforço com mal-entendidos.
No entanto, a ênfase em automação chegou a ser exagerada. Hoje, a comunidade ágil começa a valorizar os conceitos da escola context-driven,
que dá mais importância a testes manuais e exploratórios

Para o Jonathan Rodrigo precisamos ter maturidade e precisamos levar em consideração a quantidade de ciclos de testes que teremos, para que a automação possa ocorrer:

E em uma fábrica de teste se automatizarmos um caso de teste ou uma funcionalidade de forma incorreta (com dúvidas referente aos requisitos) iremos produzir evidências erradas com muito mais velocidade gerando assim um grande prejuízos, como por exemplo a desconfiança do trabalho da fábrica pelo cliente causando assim a perca do mesmo.

Porém se for bem planejada a automação e for executada conforme o planejamento o projeto será um sucesso, pois realmente automatizar diminui os custos e aumenta a velocidade da produção, claro se tudo estiver bem definido e sem sobras de dúvidas, pois se não estiver bem definido os custos podem aumentar e trazer grandes prejuízos.

Termino respondendo a pergunta:

Automatizar quando? Quando tiver maturidade, processo para suportar a automação e quando for identificado que iremos executar o teste mais de 4 ciclos, pois em meu ponto de vista não vale o investimento da automação  em caso de teste que será executado menos de 4 ciclos.

O Felipe Silva acredita que devemos automatizar os testes quando:

1. Quando autorizado pelo cliente
2. Quando viável (ganhar tempo ou redução de custos/recursos)
3. Quando tiver ferramenta e gente capaz de usá-la (“um tolo com uma ferramenta continua sendo um tolo”)

Creio que essas 3 respostas são a base de todas as outras.

1. Pode parecer estranho, mas no meu caso estamos proibidos pelo cliente de automatizar testes funcionais.

2. O fato ganhar tempo OU reduzir custos é a alma de qualquer automação, pois ganhar tempo significa ganhar dinheiro (“tempo é dinheiro”), reduzir custos e recursos é bom também, nem sempre andam juntos, as vezes vale a pena gastar um pouco mais para ter uma entrega mais rápida. Poder alocar recursos em outras atividades que envolvam qualidade (quando se pensa em automação industrial não tiveram tantas vagas na área de qualidade para o número de operários trabalhando o que gerou desemprego), é aqui que cabe a maturidade.

Automação não substitui teste manual e não encontra um percentual de defeitos maior do que o manual, pelo contrário, gráficos mostram que testes manuais encontram mais defeitos que automatizados, pois quando se está lidando e interagindo diretamente com o sistema você consegue pensar (ver) uma situação que até então não tinha pensado apenas lendo um requisito.

Sabendo disso, diria que automatizar com sabedoria é fazê-lo pensando em um teste que tenha como alvo testar parte do sistema, pois pensar que você irá automatizar 100% dos testes é ilusão (assim como é ilusão dizer que você tem certeza que 100% dos defeitos foram encontrados em qualquer tipo de testes), fazendo assim, após ter o script fazendo uma rotina de testes “óbvios” pode-se então focar em testes melhor elaborados no qual tenha que pensar com malícia para imaginar um caminho que consiga quebrar o sistema, pensar em uma situação ainda não prevista por ninguém. Salvo alguns casos como já citado pelo Elias em que manual não é viável (testes de performance, que envolvam cálculos, etc)

3. Ter ferramenta não significa comprar a mais cara no mercado, significa ter uma ferramenta que te gere resultados. A ferramenta “abc” usada pela maior empresa do mundo “fgh” não faz dela a melhor para você, e a melhor para você neste projeto pode não ser a melhor no outro projeto, não ser a melhor também não significa que não serve, se o resultado final gerado é pósito então vale a pena, o único fato é que se outra ferramenta daria um resultado positivo maior pode-se rever/calcular/viabilizar ou não uma mudança de ferramenta.

Tendo a ferramenta vem o mais o importante – antes de comprar a ferramenta é lógico – que é saber utilizá-la, e sabendo usar! Também não adianta nada ter um time expert no assunto e uma ferramenta excelente para ficar na “prateleira”, infeliz é o “chefe” que pensa que vai comprar uma ferramenta e você vai se virar para colocar ela para funcionar, treinamentos e capacitação são necessários.

Saber fazer um script bom não significa que a pessoa está fazendo da melhor maneira possível, quanta gente já não disse “era só isso? quer dizer que você só colocou essa linha de código e já faz tudo isso? nossa antes eu fazia…..”

Automação é um projeto, não parte de um projeto e deve ser tratada como tal, com líder de projeto, desenvolvedor, pessoas responsáveis pela qualidade do que está sendo criado/mantido, cronograma e orçamento.

Na minha opinião além de analisar se será viável (ganhar tempo ou redução de custos/recursos) automatizar o teste X eu também preciso analisar se o teste X será mais eficaz se automatizado ou não, pois executar ele de forma automatizada precisa, pelo menos, garantir a mesma qualidade da execução manual.

Ou seja automação deve pelo menos, garantir a mesma qualidade que os testes manuais, afinal de nada adianta ter um monte de suítes de testes automatizadas se elas não testam nada. 😉

A respeito da viabilidade da automação dos testes (citada pelo Felipe), é preciso também levar em consideração o sistema sob teste, pois se eu automatizar hoje, o teste X, que testa a funcionalidade Y, e amanhã a funcionalidade Y mudar, essa mudança poderá quebrar o meu teste X.

O Ueslei Aquino compartilhou um pouco da sua experiência, relacionado ao assunto da mesa redonda:

Imaginem o que é assumir um departamento de “testes” com missão de torná-lo um departamento de “Qualidade” (Garantia e Controle de qualidade) com 9 profissionais que nunca tiveram um treinamento em testes. A visão do cliente em relação ao setor era… “este setor não me gera resultados financeiros positivos e eu tenho aqui a ferramenta X que 2 pessoas que passaram por aqui não conseguiram implantar, fique com ela 2 meses estudando e depois me apresente o cadastro Y sendo testado por ela.”

Diante do conhecimento, procurei mostrar que sem ter pessoas treinadas, processo e metodologia de teste definidos, documentação de teste… iniciar automação poderia não ser a solução, mas um tiro no pé. Mas, sem sucesso para minhas colocações… a intenção era automatizar os testes e assim poder vender serviço de teste, ou seja, vender para os clientes do próprio sistema poderem utilizar e testar as aplicações e assim gerar resultados financeiros positivos ao setor.

Parece loucura né… mas é a mais pura verdade. Ou seja, eu estava construindo um legado de teste, com uma aplicação que tive que me virar para colocar para funcionar. O Cliente ficou ciente dos riscos, mas quis arriscar…

Diante disso, o que posso dizer do resultado foi… recebi uma proposta irrecusável…saí da empresa e eles continuaram com o processo e inclusive iam começar a aplicar em um cliente que estava implantando o sistema.

O Rodrigo Almeida também compartilhou uma experiência com automação:

Temos uma ferramenta de automação de testes desde 2000. E só em 2008 é que aprendemos como usá-la corretamente.

Tivemos que trocar toda a equipe, contratar pessoas com perfil técnico e conhecimento de lógica de programação.

Mudamos o nosso processo de testes, para podermos automatizar aquilo que era necessário, crítico e kernel dos nossos produtos. Antes a gente automatizava somente as partes periféricas dos produtos, sem impacto efetivo na detecção de defeitos. E os scripts eram criados por pessoas que não conheciam de programação/lógica. Os resultados eram terríveis.

Então, a decisão de quando automatizar foi baseada nas seguintes premissas: É parte do núcleo do sistema? É usado por vários clientes? Faz parte do processo funcional do cliente? Se sim para  uma ou mais de uma pergunta, então automatiza.

Com a mudança radical feita em 2008, saímos de uma média de erros mensal na ordem de 140 erros para uma média de 50 erros/mês em 2009. Não alteramos nada no processo de desenvolvimento. Somente criamos um processo novo de automação de testes funcionais. Não fazemos testes de performance, somente automatizamos testes funcionais e executamos os testes já gravados (teste de regressão).

Com uma equipe correta, ou seja, com conhecimento em programação, conseguimos diminuir nosso ciclo de testes que eram de dois meses, isto mesmo, dois meses, para 12 horas! Somente otimizando os scripts já gravados.

Para o Milton Vopato devemos automatizar quando:

Na minha opinião, a automatização é positiva e é uma tendência para ganho de eficiência. Quando automatizar? acredito que quando você processos mapeáveis, tipo execução em batch, performance, lista de informações padrões, etc. Este tipo de validação economiza tempo para regressões, mas quero chamar atenção a outro ponto de quando automatizar. quando pensamos em quando automatizar, pensamos para que e no processo como um todo, mas acho válido, com uma análise de benefício, criar automatizações parcial do processo de teste funcional também, ex: Hoje validados requisitos funcionais em um XML, então automatizamos a criação do request e agora estamos trabalhando na automatização da leitura de algumas tags na saídas, com isso ganhamos performance e qualidade na execução

O Shmuel lembrou de uma automação que é muito bem-vinda em uma área de Teste de Software:

Me parece que nenhuma resposta comentou em um tipo de automação muito útil: A automação do ambiente.

Em sistemas aonde é necessário configurar a rede o produto e os periféricos de forma específica antes de começar a testar, automatizar o processo de configuração é muito útil.

E além do mais, essa automatização acaba sendo muito apreciada e utilizada por toda a organização, incluindo programadores, pessoal de suporte etc.
Essa automação é legal também porque ela não atrapalha ou influência os testes funcionais.
Já a automação de testes funcionais me da certo medo… 🙂
É muito fácil exagerar na quantidade te testes automatizados, e é mais fácil ainda exagerar na confiança dada a automação.
Com isso, devo colocar que aonde trabalho temos um sistema de automação bem extenso, e tentamos automatizar todos os testes importantes para serem rodados como regressão.

Para o Rafael Porfirio:

A automação também (ao meu ver) é uma opção quando temos uma certa estabilidade na aplicação em que estamos testando assim como o ambiente em que testamos, por isso em muitos casos a primeira coisa a se automatizar são os ciclos de regressão, visto que já foram testados manualmente e de certa forma atingiu uma certa estabilidade por já ter passado por outros ciclos de teste manual.
Outra coisa que devemos levar em consideração, também é o tempo que se leva para criar (scripts de alto, média ou baixa complexidade) e também para se dar manutenção….se você tem uma aplicação onde a cada release seu script deve ser recriado….talvez não seja viável a automação…

Ainda assim, muito é importante ressaltar que um teste automatizado jamais substitui teste manual. Pois assim como desenvolvedores não conseguem fazer todo o codigo 100% correto, como testers podem confiar em sua própria programação para um script?

A Sarah Pimentel fez considerações bem interessantes sobre o tema:

Eu sou bem adepta a processos, não como forma de burocratizar, mas como forma de organizar.

Então pra mim a primeira coisa é ter um processo para decidir isso. E essa decisão se dá em cima de viabilidade de automação.

Trabalhei em uma empresa que tinha uma equipe de automação separada da dos testes funcionais (eles também fazem testes funcionais, mas são especialistas em automação). Quando uma equipe solicitava a automação dos seus testes tinha que responder um questionário inicial para que a equipe de automação avaliasse a viabilidade desse projeto. Por que isso? Porque ao contrário do que muitos pensam nas empresas automatizar ao invés de ser a solução dos seus problemas pode ser mais um gerador de problemas.

Algumas considerações:

Você está automatizando porque você acha que vai encontrar mais erros?

Não vai. O processo automatizado tende a encontrar cada vez menos erros e até mesmo em determinado ponto, não encontrá-los. De tanto rodar os mesmos testes a aplicação fica estável naquele ponto e dificilmente aparecem erros ali.

Você acha que pode automatizar a sua aplicação a qualquer momento e que essa investida é suficiente?

Há dependências de interface gráfica. Se o desenvolvedor mudar “só um negocinho”, pode ser que o teste tenha que sofrer manutenção.
Também vale ressaltar a excelente comunicação do negócio com os desenvolvedores e os testers porque se mudanças no negócio forem discutidas no café e implementadas sem que os testers saibam, o teste também não vai funcionar.

Testes automatizados precisam ser testados?

Obviamente que sim. São programas. Se foram escritos por testers ou desenvolvedores não quer dizer que não possam ter erros. Automatizar precisa passar (rapidamente, claro) pelos mesmos estágios que o desenvolvimento de qualquer outro software. Com base na especificação ele será construído e alguém precisa validá-lo.

Amanhã tá pronto?

😀 Não! 😛

Automatizar requer tempo. Você está disposto a esperar? Quando estiver pronto, você vai ter tempo de utilizar? Por quanto tempo? Compensa?

Dá pra automatizar qualquer coisa?

Bom, não sou expert em automação para dizer que não. Tem um monte de gente na lista que sabe mais que eu pra falar isso, mas sei que tem coisa que é tão complexa que não vale a pena “perder” esse tempo (da forma como foi colocado na observação acima)

O desenvolvedor participa da automação?

Pode ser que seja necessário envolver o time de desenvolvimento para fazer algum ajuste (testability). A equipe de dev dispõe dessa alocação para ajudar?

Enfim. Depois de tudo isso, eu queria dizer que automatizar é legal sim! 😀 Só que é uma coisa que tem que ser planejada com tanto carinho quanto qualquer outro software.

Para o Jorge Diz:

A implantação de testes automatizados cria uma dinâmica diferente, para bem ou para mal. Se dependermos exclusivamente de testes manuais, a cada mudança necessária do sistema há o dilema de incorrer em um custos e prazos significativos para cada ciclo de teste: é extremamente difícil para um gestor avaliar o risco de não testar. A gestão tende a ser mais conservadora em melhorias do sistema (por conta do custo das mudanças), e a manter ciclos longos de entrega de funcionalidades.

Com testes automatizados, o gestor consegue ter informações mais confiáveis. para decidir, e diminuir muito o investimento a cada ciclo. Testes automatizados são uma forma de seguro contra diversos riscos, e ajuda a que as mudanças necessárias ao negócio possam ser implementadas. Oportunidades de negócio deixam de ser perdidas.

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.

Saiba mais

Segue abaixo, algumas publicações que foram referenciadas sobre o assunto, durante a mesa redonda:

Apresentação: 4° Encontro Mensal ALATS: Automação de Testes, Mitos e Verdades

Livro: Implementing Automated Software Testing: How to Save Time and Lower Costs While Raising Quality

Livro: Automated Software Testing: Introduction, Management, and Performance

Livro: Agile Testing

Fórum: SQA Forums – Automated Testing

Artigo: Seven Steps to Test Automation Success – Bret Pettichord

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

Peneirando Bugs

O Sr. Rex Black me surpreendeu ao apresentar o conceito de test granularity. Quando comecei a ler, pensei “mais que diacho de granulidade é essa?”, mas depois de ler, percebi que o conceito faz muito sentido. 😀

Testes de caixa-branca são focados nos detalhes da implementação, o código, a estrutura de dados, classes e os elementos de baixo nível do sistema. Portanto, eles são peneiras de grãos finos.

Já os testes de caixa-preta são focados nos riscos de qualidade, requisitos e na modelagem de alto nível. Assim sendo, eles são peneiras de grãos grossos.

Ou seja, tudo é uma questão de saber como peneirar os bugs. 🙂

E é importante lembrar, que os testes utilizando técnicas de caixa-branca (unitários e de integração), não excluem os testes utilizando técnicas de caixa-preta (sistema e aceitação), e vice-versa. Afinal, a combinação deles é sempre altamente recomendável e desejável.

E viajando um pouco além do conceito do Rex Black… como você escolhe feijões (será que alguém ainda faz isso hoje? rs), com uma peneira? Provavelmente NÃO, você precisa escolher com os olhos, colocando de lado aqueles grãos que estão ruins. E como você faz teste de interface? (não se parece um pouco com a maneira com que você escolhe feijões?)

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

Fonte:

R. Black, Pragmatic Software Testing: Becoming an Effective and Efficient Test Professional, Wiley, 2007.

Imagens:

http://bit.ly/7tQL7U

http://bit.ly/7rEwux

O melhor da semana 17/01 a 23/01

Pessoal,

Segue abaixo, a lista com o melhor da semana, espero que gostem:

Você leu algo interessante, relacionado a área de Teste e Qualidade de Software, e quer compartilhar? Sinta-se à vontade em colocar nos comentários. 🙂

Abraços! E tenham uma ótima semana!

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

Testar sem documentação é possível?

A nona Mesa Redonda DFTestes teve como tema “Testar sem documentação é possível?”, contando com 24 respostas e 16 participantes, sendo eles: eu, Shmuel Gershon, Juliana Kryszczun, Ueslei Aquino, Ana Rosa, Sarah Pimentel, Fernanda Coelho, Ismael Munchen, Daniel Goettenauer, Felipe Silva, Cristiana Yukie, Rodrigo Almeida, Rodrigo Souza, Andrea Cruz, Marcelo Andrade e Jorge Diz.

Abaixo segue o “resumo” de mais uma excelente Mesa Redonda DFTestes, e como sempre, não deixem de acompanhar a mesma, e se você se interessa pelo assunto, é altamente recomendável a leitura da discussão na íntegra. 🙂

Testar sem documentação é possível?

Segundo o Shmuel Gershon:

A documentação é uma das ferramentas usadas durante os testes, dentre outras. Como tal, ela nos ajuda a aprender sobre o comportamento e contexto do aplicativo.

Mas essa ajuda não é um pré-requisito para os testes. É possível testar sem documentação, pois durante os testes um Tester pode (deve?) abstrair e inferir sobre o aplicativo e ir aprendendo quais são as perguntas necessárias.

Muitos Testers, inclusive os que acreditam precisar da documentação, passam por esse processo consciente ou inconscientemente.

Afinal, nem sempre a documentação é correta, e se é possível testar desconfiando da documentação, é possível testar sem ela.

Finalizando, uma “prova matemática”: É possível testar a documentação, e a documentação por si não tem documentação (às vezes sim). Logo, é possível testar sem documentação :).

A utilização da documentação como base para a elaboração dos testes, costuma fazer parte de qualquer processo de Teste de Software, porém dependendo da documentação existente, outros caminhos podem ser seguidos para a elaboração dos testes, como foi comentado pela Juliana Kryszczun:

Muitas vezes a documentação que chega para a equipe de teste está toda distorcida. O sistema seguiu outro rumo, a documentação não foi atualizada e uma boa conversa com o analista de requisito (ou responsável) resolve bem mais do que ficar horas lendo a documentação desatualizada.

Esse não é o caminho feliz dentro do processo, mas às vezes, não dando a devida importância para a documentação pode salvar os prazos de entrega.

O Ueslei Aquino lembrou que em empresas onde não há um processo bem definido de Desenvolvimento e Teste de Software, ou onde o mesmo costuma sofrer resistência por parte das pessoas, a melhor fonte de informação acaba sendo as próprias pessoas:

Em empresas que não se tem a prática de documentação, o conhecimento tácito (o que está na cabeça de alguém) é o que predomina. Há momentos em que vale muito mais a pena descobrir quem é a “cabeça” do conhecimento, conversar sobre o sistema e extrair todas as informações necessárias que ficar preso a uma documentação desatualizada.

O Ueslei Aquino ainda complementa dizendo que:

A documentação é importante sim, desde que seja um facilitador para o teste, caso contrário mão a obra e vamos ao sistema sem documentação.

O Felipe Silva acredita que é possível sim testar sem documentação e complementa dizendo:

Pensando nos testes beta, por exemplo, muitos usuários que instalam aplicativos beta em seus PCs acabam testando. Porém, nem tudo é tão simples quanto um teste beta. Existem testes e testes, fato. Você testaria um sistema de controle de pouso de uma aeronave sem documentação? Eu não… se sim, você faria o primeiro vôo estando você nesta aeronave? Percebam que eu não disse que não é possível nem neste exemplo, eu não testaria sem documentação porque não tenho a mínima idéia de como um sistema desses deve funcionar para ter um resultado satisfatório, mas e se no contexto ao invéz de uma pessoa sem conhecimento fosse alguém que tem uma vasta experiência no assunto o suficiente para produzir a dita documentação, garanto que esta pessoa poderia testar sem documentação porque ela é a própria documentação.

Testar sem documentação é possível, depende de QUEM irá fazê-lo.

A Cristiana Yukie compartilhou uma experiência vivida com a documentação do Teste de Software:

Aqui tínhamos muitos problemas quando havia problemas em produção, porque não documentávamos o que foi testado, quais testes foram feitos na versão atualizada, quais regras foram cobertas… entre outros.  Quando começamos a ter documentos dos testes que deveriam ser feitos antes e após a atualização começamos a ter mais garantia da versão atualizada em produção.

Então, eu diria: é possível testar sem documentação Sim, porém se tivermos uma documentação (claro, sempre atualizada) ganhamos mais em qualidade! Esta documentação atualizada é bem vinda principalmente a longo prazo.

O Rodrigo Almeida lembrou que precisamos buscar produzir uma documentação eficiente:

Testar algum software sem documentação é possível sim, mas não acho que seja eficaz/eficiente.

O custo de não ter documentação alguma pode ser muito alto.

Criar e manter uma extensa documentação também não é viável, dado o custo.

Precisa ter um mínimo de documentação. Um caso de teste, o registro das alterações feitas no sistema para que seja feito o teste e um relatório sobre o teste. Acho que este seria o mínimo necessário.

A Andrea Cruz lembrou bem, que testar sem documentação irá trazer certos riscos e você precisará assumir-los:

Testar sem documentação é possível porém podem existir em determinados sistemas requisitos implícitos importantes que podem não serem cobertos pelo teste.

Eu trabalho com projetos que um testador leigo pode deixar de testar determinados requisitos.

Um bom testador é capaz de levantar os dados de um sistema a partir das conexões com Banco de Dados, Testes Funcionais e Testes de Performance apenas informando o tempo que foi levado para retornar determinadas consultas sem ter o critério e o limite esperado do tempo pelo cliente e escrever isso no Relatório de Testes.
Cabe ao Analista ter o critério para dizer o que passou e o que não é aceitável.

Exemplo simples: Um shortcut pode “matar” um software se não for acionado. Sem documentação como saber? Teste Monkey??? rsrsrsrsrs

Para o Daniel Goettenauer a documentação precisa ser gerada de acordo com o tamanho do projeto:

A empresa que trabalho até algum tempo não tinha a Fábrica de Testes e quando foi implantada para apagar incêndio a documentação de testes era ignorada, e o nível de produtividade era muito auto. A medida que o processo foi amadurecendo e se chegou a conclusão que a documentação era necessária para se ter robustez as coisas passaram a ficar lentas e engessadas.

O benfício da documentação só é percebido atualmente em grandes projetos, onde os testes de regressão são constantes e existe muitas mudanças.

Meu pensamento é que dependendo do tamanho do projeto de teste a documentação poderia ser tratada de forma mais simples(documentos básicos) ou complexa(todos os documentos). Dessa forma não teríamos projetos desenvolvidos em 16 horas e testados em 72 horas por conta do volume de documentação.

A Sarah Pimentel lembrou que a resposta para essa pergunta, poderá variar dependendo da escola de Teste, que você “segue”:

A favor de que é possível testar sem especificação:
Context-Driven School
-Faça o possível para ser útil (Acho que até agora a maioria aqui concordou que da pra gente seguir em frente)

-Faça perguntas se necessário (Comentei do oráculo, uma pessoa especialista a quem podemos recorrer)

Vasculhe documentações “escondidas” (Schmuel: “Uma documentação desatualizada serve para muitas coisas! :)”)

Agile School

– Conversas são mais importantes que documentações

Ps.: Note que nenhuma das duas disse que a melhor prática é testar sem documentação, apenas disseram que é possível se não tiver uma disponível.
Contra a possibilidade de testar sem especificação:
Analytical School
-Impossível (mas também imagina testar um sistema puramente matemático daqueles que tem não sei quantos computadores pra conseguir fazer um cálculo?)
Standard School
– Alguma documentação é necessária (planejando e seguindo um processo, deve ter alguma coisa que possa ser útil para o teste. e supondo que o planejamento ocorra de acordo com o ideal, que é o planejamento de testes iniciando no começo do projeto, já teriam sinalizado que tá faltando alguma coisa)
Quality School
– Force developers to follow the process (realmente, se tivessem seguindo um processo estruturado desde o começo, haveria alguma documentação, mas também chegar na fase de teste e fazer todo mundo documentar o que não foi documentado até o momento é suicídio do projeto)

O Marcelo Andrade lembrou que a informação é mais importante que a documentação, e disse:

Primeiro, só para deixar bem claro meu ponto de vista, a informação é mais importante que a documentação.

Isto é, se a documentação não é mantida, não é compreendida, não é atualizada, e é gerada apenas para cumprir-se com formalismo do processo, ela não é necessária.  Relembrando que documentação necessária é aquela que 1) o cliente solicita ou 2) é usada para apoiar o desenvolvimento.

Claro que não dá pra se testar tirando conclusões sobre regras de negócio da própria cabeça do testador.  Neste caso, se a informação está disponível (com o cliente ou com quem quer que seja) é ela que deve ser buscada.

Por fim, se sua equipe tem dificuldades com relação a documentação (encontrar, mantê-la atualizada, etc), tem-se que pode ser mais fácil incluir um artefato do qual se sinta real necessidade do que retirá-lo do que o processo prescreve.  O processo deve se adaptar às equipes e nunca o contrário.

Uma reflexão que me ocorreu dia desses: muitos de nós acabamos por usar documentos e mais documentos como “muletas”, como uma espécie de escora no que podemos nos apoiar (ou culpar) para saber o que devemos fazer.  Entretanto, se você tem uma equipe minimamente capacitada, as pessoas sabem o que fazer, o que é necessário para fazer, o que testar e como testar.  Talvez elas não tenham experiência em fazer ou temam errar.  Mas não há nada de errado em errar 🙂 e aprender.  Mas aí já são divagações…

O Jorge Diz também acredita que não deve-se colocar todas as fichas na documentação:

Não coloquemos todas as nossas fichas na documentação do sistema. Com certeza, é possível  testar sem documentação formal: pode ser mais ou menos eficaz, dependendo do contexto. E sempre devemos lembrar que o documento mais atualizado é sempre o próprio sistema sendo testado.

Durante a discussão a Sarah Pimentel levantou duas questões bem relevantes ao tema da mesma.

Pra quem acha que dá pra testar sem documentação, então por que a gente documenta? E porque tantas vezes brigamos por documentação?

Para Shmuel:

A documentação é uma ferramenta útil nos testes, por isso documentamos, ou brigamos por documentação correta. Às vezes o esforço da certo, às vezes não. É igual testabilidade. Uma ótima ferramenta, e brigamos por isso. Nem sempre dá certo, ou nem sempre acaba da melhor maneira.

O Felipe Silva disse que:

Para que pessoas sem conhecimento anterior do sistema consigam trabalhar, e em alguns casos serve para que o cliente assine dizendo que é isso que ele quer que seja feito.

Na maioria dos casos além de brigarmos para querer ter um sistema testável por qualquer um, em determinados processos de engenharia de software também brigamos porque queremos ter um documento como “defesa” contra a insatisfação do cliente. É aquele problema que se você não documenta, o cliente não assina, se ele não assina logo não existe um registro de que ele havia dito que era aquilo que ele queria, correndo o risco do cliente reclamar e ter melhorias no sistema sem pagar por elas nem ajustar cronograma e etc.

Se a documentação não é confiável, por que é gasto tempo produzindo-a?

O Shmuel acredita que:

Bom ela foi confiável no momento da produção.

Mas nem por isso ela é completamente inútil: Uma documentação desatualizada serve para muitas coisas! 🙂

Ela nos ajuda a entender a história do projeto, as expectativas iniciais, as primeiras idéias. A comparação entre o que foi documentado e o que saiu no fim nos ajuda a entender as suposições do cliente e dos arquitetos, os limites e obstáculos encontrados. Não jogue a documentação desatualizada fora! 🙂

O Felipe Silva pensa que:

Documentação é confiável quando atualizada e se possível assinada. Se não está atualizada e nem assinada siga o conselho do Shmuel: “Uma documentação desatualizada serve para muitas coisas! 🙂 Ela nos ajuda a entender a história do projeto, as expectativas iniciais, as primeiras idéias. A comparação entre o que foi documentado e o que saiu no fim nos ajuda a entender as suposições do cliente e dos arquitetos, os limites e obstáculos encontrados. Não jogue a documentação desatualizada fora! :)”

Conclusão

Algumas conclusões extraídas da discussão:

  • A documentação NÃO É um pré-requisito para a área de Teste de Software;
  • No entanto, a existência de uma documentação completa e atualizada poderá ajudar MUITO a elaboração dos testes, e assim aumentar a eficácia dos mesmos;
  • Não jogue a documentação desatualizada fora, ela poderá ser útil para quem for pegar o bonde andando, para poder ter uma noção melhor do projeto, afinal das contas, se ela está desatualizada, que dizer que as informações contidas nela, um dia foram as atuais;
  • “Falta de documentação é um risco. A documentação que está faltando e o contexto do teu projeto é que vão determinar se é um risco aceitável ou não.” (Sarah Pimentel)

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.

Você é eficiente?

Estou começando a ler o livro do Rex Black, Pragmatic Software Testing: Becoming an Effective and Efficient Test Professional e logo no início, encontrei uma pergunta bem interessante:

What Do Effective and Efficient Mean?

Traduzindo o sentido da frase:

O que pessoas eficazes fazem e o que eficiente significa?

Segue abaixo, o trecho do livro com a explicação do Rex e na sequência uma tradução:

Webster’s dictionary defines the word effective as “producing a decided, decisive, or desired result; impressive.” So, to be an effective software tester, you must decide what results you desire from your testing efforts.

Likewise, Webster’s defines efficient as “productive of the desired effect; especially to be productive without waste.” So, to be an efficient tester, you must allocate resources (time and money) appropriately.

O dicionário Webster define a palavra efetivo como “produzindo um determinado, decisivo, ou desejado resultado; impressivo.” Então, para ser um Testador de software efetivo, você deve decidir quais os resultados que você deseja dos seus esforços de teste.

Já a palavra eficiente é definida pelo Webster como “gerador do efeito desejado, especialmente, ser produtivo sem desperdício.” Então, para ser um Testador eficiente, você deve alocar recursos (tempo e dinheiro) de forma apropriada.

A definição das duas palavras me fez pensar em dois grandes desafios que todos nós enfrentamos (embora muitos não tenham plena consciência), são eles:

  • Alinhamento das suas expectativas com a realidade;
  • Manter o foco, buscar o melhor custo benefício.

O primeiro é muito difícil, e falo isso pensando de forma introspectiva, ou seja, se alinhar as expectativas consigo mesmo já é difícil, imagina só alinhar as expectativas com várias pessoas, de diferentes áreas, culturas, etc. Eu já vi projetos sofrerem fortes abalos, justamente devido a expectativas não estarem alinhadas.

E quem trabalha na área de Teste de Software deve saber bem como é difícil alinhas as expectativas, afinal muitos, principalmente no início da área, pensam que a área de Teste de Software irá solucionar todos os seus problemas, e pensamentos imaturos como os abaixo surgem:

  • Agora nossos softwares terão zero defeito;
  • Não teremos mais problemas em produção;
  • Iremos começar a produzir software de qualidade, do dia para noite.

Agora o segundo é menos difícil, e o nível de dificuldade dependerá de fatores internos e externos:

  • O ambiente de trabalho: pois o mesmo deverá possibilitar e incentivar que a equipe busque ser eficiente;
  • A maturidade da equipe: dependerá bastante da experiência da equipe (experiência é diferente de tempo de casa);
  • O fluxo de trabalho: ser for sem um processo bem definido ou com demandas não previsíveis, será difícil alcançar um bom grau de eficiência.

Pessoalmente falando, eu me sinto mal, quando percebo que não estou sendo efetivo em algo, e quando isso ocorre eu busco primeiro compreender os motivos que estão causando isso e depois procurar solucionar, às vezes é uma questão de expectativas acima da realidade, outras vezes por motivos externos, e daí é necessário conversar com alguém, etc.

Ser eficiente é algo que faz bem em qualquer profissão, e é uma premissa para você alcançar o topo da pirâmide de Maslow. E ser eficiente não é um esforço solo, e sim conjunto, por isso é sempre bom o time estar em constante questionamento e aprendizado, buscando a melhoria contínua (kaizen).

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

Saiba mais:

Segue abaixo, o link para um interessante artigo sobre o assunto:

Artigo Você é eficiente ou eficaz? por Eduardo Santos

http://www.acessa.com/negocios/arquivo/carreira/2003/11/25-Eduardo/

O melhor da semana 10/01 a 16/01

Pessoal,

Segue abaixo, a lista com o melhor da semana, espero que gostem:

Você leu algo interessante, relacionado a área de Teste e Qualidade de Software, e quer compartilhar? Sinta-se à vontade em colocar nos comentários. 🙂

Abraços! E tenham uma ótima semana!

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

O Testador também necessita saber programar?

A oitava Mesa Redonda DFTestes de 2010 teve como tema “O Testador também necessita saber programar?”, 29 respostas e  20 participantes, sendo eles: eu, Ismael Munchen, Milton Vopato, Felipe Silva, Ronaldo Cruz, Rodrigo Souza, Rodrigo Almeida de Oliveira, Anna Carolina Rocha, Edwagney Luz, Andrea Cruz, Shmuel Gershon, Jorge Diz, Eduardo Gomes,  André Dias, Camilo Ribeiro, Renata Eliza, Robson Agapito, Ueslei Aquino, Elias Nogueira e a Sarah Pimentel.

Abaixo, segue o “resumo” dessa excelente discussão (para conferir-la na íntegra, basta acessa esse link).

O Testador também necessita saber programar?

O Milton Vopato acredita que programação é um conhecimento que pode ser uma vantagem competitiva ao profissional da área de Teste de Software:

A rigor, não é necessário saber programar para realizar certos tipos de teste, em específico, testes funcionais, pois são validações em alto nível das regras de negócio, mas eu particularmente, acredito que qualquer profissional de TI, deve conhecer não só programação, mas o ciclo de vida de um software por completo (Requisitos, Desenvolvimento, Teste, Implantação resumidamente). Mesmo não sendo obrigatório conhecimentos de programação no teste, eu vejo como uma vantagem competitiva muito importante, para entender melhor o problema, desenvolver automações e participar de reuniões com dev. para discutir o defeito encontrado.

O Felipe Silva lembrou que para automação é fundamental você saber programar, e que um dia quem poderá ter tal papel é você, portanto é importante se aperfeiçoar:

Um dia pode ser você o escolhido para automatizar, estar preparado para pelo menos aceitar o novo desafio proposto com certeza te fará bem visto pela empresa. Ainda que não use no momento o seu conhecimento em automação no projeto, você pode criar uma automação de suporte ao seu dia dia, automação não é apenas criar o script de teste funcional de uma funcionalidade do projeto, mas sim é simplificar as suas tarefas, seja criando um pequeno aplicativo que te ajude a manter algum tipo de informação para gerar futuros relatórios, criando um macro no “office” e/ou qualquer coisa que aumente a tua produtividade. Pense à frente, seja criativo, MUDE para melhor!

Para o Ronaldo Cruz o testador não precisa conhecer programação ao nível de conseguir criar um sistema, mas o básico poderá ser muito útil, já que irá ajudar a realizar melhor as suas tarefas de Teste de Software:

Penso que quando se fala que o testador precisa saber programar, a maioria imagina que o testador necessita de conhecimentos a nível de criação de sistemas. Na verdade, o profissional não precisa chegar a tanto (só se quiser é claro), mas precisa conhecer o básico da linguagem. Isso ajuda em planejar melhor os testes, saber o que é efetivamente erro ou não e melhor explicar os bugs a equipe de desenvolvimento.

E o Ronaldo Cruz ainda finaliza o seu comentário dizendo:

Então do meu ponto de vista, o testador precisa saber programar? Sim, bem como também precisa saber analisar requisitos, mexer em banco de dados, ter conhecimentos em infra ou suporte.

Um ponto interessante levantado pelo Rodrigo Souza, foi em relação ao seu contexto:

O quanto é necessário destes conhecimentos, cada projeto, cada empresa e cada teste vai variar, e com certeza só acresce ao testador. Ter esses conhecimentos ajuda muito, claro que o profissional não vai ser o melhor programador e trabalhar com testes, mas dependendo do projeto sim teria que ser um ótimo programador, afinal quem são os tester do Eclipse e outros? se não tester com muito conhecimento em programação.

O Rodrigo Almeida compartilhou uma experiência que teve na sua empresa:

Em se tratando de automação de testes de software, aqui na empresa só obtivemos resultados satisfatórios depois que trocamos todas as pessoas que não eram programadores por programadores. As ferramentas de automaçao exigem que você saiba programar. Não tem jeito mais de voltar atrás neste cenário.

A Anna Carolina compartilhou a visão de pessoas que tem outras preferência na área de TI, até porque a área de TI não é feita só de programadores, nela há espaço para os mais variados tipos de perfis, e na área de Teste de Software há espaço tanto para quem gosta de programar quanto para quem não gosta:

Embora eu adore a área de informática, eu me considero uma pessoa muito comunicativa e não consigo passar o dia inteiro simplesmente olhando pra tela do computador programando. Logo, eu considero não possuir o perfil de programadora.
Fui em busca de outras áreas dentro da informática que me permitissem maior interação com outras pessoas, sejam elas usuários ou colegas da informática. Como a primeira opção que minha primeira chefe me passou com este perfil foi a área de testes, comecei a estudá-la e me apaixonei por ela. E cada vez menos dei importância para a programação.
Não trabalho com testes automatizados, então talvez a programação não me faça tanta falta. Mas é claro que também não estou na situação de quem não sabe nada: se você me pedir para escrever um código para resolver tal problema, eu talvez não consiga ou leve muito tempo para fazê-lo, pois gastarei muito procurando a sintaxe correta e as funções a serem usadas. Mas se eu preciso analisar um código que está dando problema, eu consigo assimilar o que foi feito pelo programador e raciocinar em cima disso para localizar a origem do erro.

A visão do Edwagney sobre o tema:

Minha visão desse tema vai um pouco mais além do conceito de saber programar para encontrar problemas mais rápido, ou abrir o código e entender. Saber programar e sobre banco de dados e etc,  significa conhecer a mente de quem está por trás de um trabalho. Conhecer a mente de um programador, conhecer a mente de quem modela banco de dados, etc. Partimos do pressuposto de que conseguimos entender que TODOS são seres humanos e erram, mas com a vantagem de conhecer quais os principais pontos em que uma falha pode ocorrer durante um trabalho de codificação, por exemplo. Nossa função é fazer um forte elo entre o que pensa o cliente e quem desenvolve o projeto e fazer com que o produto acordado entre os dois saia o mais próximo possível do estimado.

A Andrea acredita que é necessário ter conhecimentos básicos, mas que ainda não é imprescindível saber programação, para poder trabalhar na área de Teste de Software:

Ao meu ver saber programar, ou ter pelos menos conhecimentos básicos de Lógica de Programação, if..then, case, for (i=0..10) é importantíssimo para alguém que trabalhe na Área de Teste de Software porém hoje ainda não é imprescindível. Quem tem algumas noções pode se encaixar em qualquer projeto, ler qualquer Diagrama de Estado, Diagrama de Sequência, Fluxograma e ter uma noção plena de como funciona o fluxo do sistema como um todo.

O Shmuel citou as vantagens que o testador irá ter, caso conheça programação:
– O tester é capaz de entender os tipos de problemas que o aplicativo pode apresentar, pois o tester pode montar seu modelo mental de como o software funciona por dentro e testar os limites desse modelo.
– O tester é capaz de fazer testes automáticos quando necessário. Talvez até mais importante, a criação de pequenas ferramentas que facilitam a configuração rápida do sistema, ou que recolhem dados para relatórios podem fazer do tester um jogador importante com influência na equipe toda.
– Facilita a comunicação com os programadores. Bom ponto levantado pelo Milto e Felipe. Gostaria de dizer: “Programadores são seres que, bem, só entendem a linguagem de programadores, fazer o que :)”  mas como gosto muito dos programadores vou dizer diferente: É mais fácil conversar com eles quando nos colocamos no mesmo contexto que eles.

O Shmuel ainda falou sobre o que eu acredito ser o conhecimento mais importante para o testador, conhecer o domínio em que atua, utilizando um ótimo exemplo:

Cem Kaner uma vez comentou que “Eu não aceitaria um estudante de informática ou doutorado em meu laboratório se eles tem habilidades de comunicação fracas. Pela minha experiência essa característica é mais importante para o sucesso do que habilidades de programação”
A visao de Kaner, nos artigos que ele escreve sobre recrutamento de testers, é que os times devem ser heterogêneos, e nem todos devem saber programação. O conhecimento da area sobre a qual o software atua (domain knowledge) é essencial para se ter testes efetivos.

Por exemplo:
Se você estiver montando uma equipe para testar um software que faz transações na bolsa de valores, qual tipo de pessoas você recrutaria? Que soubessem programar ou que entendessem do mercado de ações? A melhor resposta, diz Cem, é “pessoas de ambos os lados”.

Pessoalmente, se eu tivesse que escolher um dos extremos, eu iria recrutar alguém com experiência no mercado de ações.  Ei, mas ele não sabe programar! Bom, o usuário final também não! 🙂

O Ismael Munchem acredita que:

Um testador com conhecimentos em programação seria mais completo. O conhecimento da linguagem não precisa ser um requisito para contratação, mas deveria ser algo a aprender em seguida.

O Jorge Diz começou o seu comentário fazendo uma analogia com o futebol:

A analogia que imaginei foi o futebol: “O Goleiro também necessita saber chutar ?”. Ai começou a cair a ficha: no futebol, o papel do goleiro está bem definido, com regras
claras sobre o que se espera dele em campo. Não acontece o mesmo com o profissional de testes: em particular, o “testador” poderia ser identificado como aquele que segue roteiros repetitivos, criados por outro profissional mais graduado (“analista de teste”). Seguindo com a analogia futebolística, a pergunta ficaria: “O Gandula também necessita saber chutar ?”

Em seguida, o Jorge expressou a sua opinião, frisando bem que a repetição de trabalho no Teste de Software é algo que deve ser evitado, e uma das soluções para isso é justamente a automação, mas a mesma não resolve tudo:

O papel de testador como subalterno seguidor de roteiros escritos está condenado. Não acredito, no médio prazo, haver espaço para que uma pessoa faça tarefas
repetitivas e alienantes de maneira produtiva, e mantendo um mínimo de motivação. Talvez uma exceção sejam as pessoas com um certo grau de autismo, como exemplificado pelo trabalho de empresas e organizações como Specialisterne na Dinamarca e Aspiritech nos EUA. Vejam, por exemplo, este artigo de Harvard: http://hbswk.hbs.edu/item/5869.html

Não descarto teste manual. Acredito, sim, em sessões exploratórias guiadas pela experiência, feitas por profissionais com perfil investigativo, utilizando recursos e conceitos de tecnologia para identificar e localizar defeitos no software de maneira similar aos policiais e peritos forenses do seriado CSI. Não imagino este perfil profissional sem um mínimo de vivência em diversas áreas de TI, incluindo desenvolvimento: infelizmente, não é o perfil procurado hoje pelas empresas quando é anunciada uma vaga de testador.

Note-se que nem falei ainda de automação: parece ser consenso do grupo que nesse caso o conhecimento de programação é indispensável. Reforço, no entanto, que automação não é tudo.

Outro papel do profissional de testes deveria ser o de promover a testabilidade dos sistemas. Para isto, é necessário conhecer bem padrões de arquitetura de software, orientação a objetos, técnicas de dublês de testes, injeção de dependência, polimorfismo, concorrência… Em minha opinião, isto vai muito além de if, for, while …

O Eduardo Gomes lembrou muito bem que a maneira como o testador faz os testes (caixa-branca e caixa-preta) irá exigir conhecimentos específicos e diferentes:

Entendo que a questão do testador ter ou não que saber programar merece uma análise conforme o contexto.

Se estamos falando de testes nos níveis mais baixos (unitário e integração), é interessante que o testador conheça bem lógica de programação, a sintaxe e a estrutura da linguagem utilizada na construção da aplicação, aspectos sobre o banco de dados utilizado e a arquitetura da solução. Além disso, pode ser necessária a construção de drivers ou stubs e o conhecimento de programação será muito útil.  Lembremos que esses testes são predominantemente caixa-branca.

Mas se falamos dos testes no nível de sistema ou mesmo dos testes de aceitação realizados pelo usuário, esse conhecimento para os testadores passa a ser menos relevante, pois o foco será a validação dos requisitos e das necessidades do usuário.  Trabalhamos muito mais com testes caixa-preta.

O Camilo Ribeiro levantou um ponto interessante, sobre os profissionais de Teste de Software, precisarem ser generalistas:

O Analista de Teste, Engenheiro de Teste, Líder de Teste, ao meu ver, são um generalistas. Não devem encontrar defeitos somente no software desenvolvido, mas em todo o sistema e em todo o processo para o desenvolvimento do sistema (sistema != software).

O que acontece quando um analista de teste resolve se tornar “o sênior” dos testers, sem ter adquirido conhecimento em OO, programação, requisitos, negócios e etc., é que ele se torna um especialista em achar “bugs”. Ele tem cinco certificações, oito cursos “mais ou menos” de teste, MBA em teste de software e etc. Ótimo currículo, para um testador.

Para a Renata Eliza todo conhecimento adquirido poderá ser útil:

Eu acredito que o Tester não necessita ser um desenvolvedor nato, mas precisa conhecer de programação sim. Acho que vale inclusive aquele conhecimento acadêmico, dos tempos da faculdade… Todo e qualquer conhecimento a mais só vai agregar qualidade ao teste.

O Robson Agapito relatou a sua experiência em desenvolver sistemas, justamente para apoiar o processo de Teste de Software, e essa é uma aplicação muito legal do conhecimento de programação, pois é difícil encontrar uma ferramenta que se adeque ao seu processo sem ter que realizar alguma customização:

Como ele foi desenvolvedor , a cada conhecimento adquirido ele foi desenvolvendo uma ferramenta especifica para a sua equipe… e desenvolvendo consultas para que pudesse colher os resultados de testes, além de gerenciar os mesmos. Claro se não fosse desenvolvedor também conseguiria isso, mas como já estava acostumado foi muito mais fácil e muito mais rápido este salto, hoje a equipe dele possui várias ferramentas de apoio que são fundamentais para o andamento e a agilidade da célula (mesmo o tempo ainda sendo um grande vilão dos testes), ganhando sempre em produtividade, deixando as coisas mais automáticas. E a gestão dos testes é bem menos trabalhosa do que na gestão anterior.

Para o Ueslei o conhecimento em programação ajudou no desenvolvimento de sua carreira:

Eu particularmente já passei pela cadeira de desenvolvedor, e isso me ajudou muito quando assumi a posição de gestor de testes em uma empresa e tive que fazer prova de conceito em ferramentas de automação e até mesmo em executar automação.

A empresa tinha resistências em investir em profissionais especializados e de acordo com a demanda de trabalho, eu trocava o boné e ora testava, ora gerenciava, ora automatizava e ainda treinava outros testers na ferramenta.

O Elias apresentou os cargos existentes na nossa área, é comentou que pessoas que conhecem e gostam de programação, costumam ser Automatizadores de Teste:

Se puxarmos para os cargos dentro da área de Teste de software, teremos os abaixo:
– Testador
– Automatizador de Teste
– Analista de Teste
– Engenheiro/Arquiteto de Teste
– Líder/Coordenador de Teste
– Gerente de Teste

Bom, como todos já sabem, já temos um cargo específico para o Testador que sabe programar; o Automatizador de Teste.

A Sarah fez o seu comentário relacionando o cargo com o conhecimento de programação necessário:

Testador
Não precisa saber programar.
Mas ter boas noções de programação ajuda a encontrar bugs e reporta-los adequadamente.
Automatizador de Teste
Nem precisa comentar 🙂
Precisa saber programar e BEM.
Analista de Teste
Não precisa saber programar.
Mas saber programar ajuda muito a avaliar a aplicação e inferir sobre os testes que serão realizados, escolha das técnicas aplicadas e análise de riscos.
Engenheiro/Arquiteto de Teste
Precisa saber programar, conhecer design patterns também. Deveria participar de reuniões de revisão de arquitetura e de código para ajudar a encontrar bugs mais cedo no projeto.
Líder/Coordenador de Teste
Eu vejo esse papel como se uma pessoa que sabe se virar muito bem tecnicamente. Isso inclui programação também. Não quer dizer que a pessoa precise saber tudo de tudo, mas deve ser capaz de auxiliar sua equipe a encontrar respostas. Fica mais fácil quando se tem o conhecimento.
Obviamente fora o técnico também precisa ter bons skills pessoais.
Gerente de Teste
Houve uma época que se dizia que um gerente não precisava conhecer o que estava gerenciando, apenas “gerenciamento”. Eu sempre discordei. Não imagino como alguém consegue gerenciar o que não conhece.
O gerente realmente não precisa saber programar.

Conclusão

Essa mesa redonda foi uma das mais produtivas, e para mim os seguintes pontos ficaram claros:

  • Na área de Teste de Software há espaço tanto para pessoas que sabem e gostam de programar, como para pessoas que não sabem ou não gostam de programar;
  • É de extrema importância você saber o que você quer, pois dependendo da função que você deseja exercer, conhecimentos específicos serão exigidos, ou seja, não adianta por exemplo, ter vontade em ser um Automatizador de Teste se os seus conhecimentos sobre programação são limitados;
  • Os profissionais de Teste de Software devem ser especialistas-generalistas! Como assim Fabrício? Devem ser especialistas em Teste de Software e no domínio que atua, e ainda precisam ter bons conhecimentos sobre as tecnologias utilizadas na sua empresa; (tava achando que a vida de um profissional de Teste de Software é moleza!?)
  • Programação é um conhecimento importante na nossa área, mas dependendo da sua realidade, é capaz que você nunca venha a precisar utilizá-lo, mas não é por isso que você precisa ignorá-lo;
  • Ao se especializar em programação e automação, não podemos perder o nosso mindset de profissionais da área de Teste de Software, pois somos “representantes” dos usuários finais, portanto precisamos saber falar e pensar na “língua” do usuário final, na nossa e ainda na dos programadores.

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.

Impressões do 8º Encontro Mensal da ALATS-SP

Ontem ocorreu a oitava edição do já tradicional Encontro Mensal da ALATS-SP, na Av. Paulista em São Paulo.

Tive o prazer de estar presente nesse encontro que teve como tema Modelos da Qualidade e o MPT.BR, onde foram apresentadas duas palestras: a primeira feita pelo José Correia, diretor regional da ALATS São Paulo, com o título de Introdução a Verificação e Validação no CMMI e MPS.BR, e a segunda apresentada pelo Emerson Rios, presidente da ALATS, com o título Introdução ao MPT.BR.

A seguir segue minhas impressões sobre o evento, espero que gostem. 🙂

Organização

A organização do evento foi bem realizada, só ocorreu um problema: a mudança do local do evento na última hora, mas a mesma foi avisada de forma eficiente aos participantes, e o novo local é bem perto (cerca de nem 100 metros) do local que estava previsto a realização do encontro.

A divulgação foi feita com uma boa antecedência, por meio das listas de discussões de Teste e Qualidade de Software, twitter da ALATS-SP, em blogs e além claro na própria página da ALATS-SP.

Local

O evento ocorreu em uma sala da DoMore, que possui uma boa infraestrutura (tem até um XBox 360 na sala de espera rs), boa climatização e espaço adequado para o número de participantes, aliás, a sala literalmente lotou! 🙂

Pré-palestras

Agora vamos parar de lenga-lenga, pois como puderam notar, não sou um bom relator de ambientes (uma pessoa que comenta sobre a presença de um XBox não pode ser levada a séria), e ir para o que realmente interessa, o encontro.

Antes do início das palestras, cada participante fez uma breve apresentação, contando sobre trabalha com Teste de Software, a quanto tempo e em qual empresa.

Após a apresentação ocorreu a posse dos Diretores Regionais Adjuntos (DRA) no mandato 2010, que assumiram o compromisso de trabalhar de formar voluntária em pró do crescimento e aperfeiçoamento da área de Teste de Software e Garantia da Qualidade. O time da ALATS-SP passou de 7 para 12 pessoas, e esse número ainda deverá aumentar no próximo mês, no qual haverá uma nova seleção de voluntários.

Em seguida o José Correia apresentou o balanço da ALATS e da diretoria de São Paulo, e também as metas para o ano de 2010:

  • Em 2009 189 pessoas participaram do encontro mensal;
  • Para 2010 a meta é de 400 pessoas!
  • Os DRAs realizaram 24 palestras em 2009, totalizando um público de cerca de 1.500 pessoas;
  • Para 2010 a meta é de 200 palestras, atingindo um público total de 10.000 pessoas!

Um verso que achei bem interessante, colocado pelo José no início da sua apresentação, foi:

Um sonho que se sonha só,

é só um sonho que se sonha só,

mas sonho que se sonha junto é realidade.

(Raul Seixas)

E isso é a pura verdade, por isso que foi e é tão importante o aumento de voluntários na ALATS-SP, que estão cultivando e espalhando a cultura de Teste de Software aqui no estado de São Paulo. E em outros estados isso também é possível, só é preciso união, seja ela por meio de uma associação, grupo de amigos, companheiros de trabalho, etc, e também vontade. 😉

Palestra do José Correia

O José Correia deu uma verdadeira aula sobre modelos de maturidade, e com a já conhecida, excelente didática (cheia de analogias).

O primeiro ponto esclarecedor apresentado sobre modelos de maturidade, foi a desmistificação que as pessoas tem sobre eles:

  • Não é algo mágico! Você não irá ter um salto de melhoria grande de “um dia para noite” é preciso tempo e compromisso, até porque não é a toa, que há níveis de maturidade;
  • Um modelo de maturidade não tem verdades absolutas;
  • Ele é focado no que você faz, NÃO como  você faz. Até por isso ele não te diz como fazer, apenas o que deve ser feito;
  • São modelos para você se inspirar, mas como somos preguiçosos, adoramos seguir a risca #fail!
  • Busca tornar o desenvolvimento de software mais previsível;
  • São uma base, não são completos e abrangentes.

Depois o José falou sobre CMMI (Capability Maturity Model Integration), explicando o seu surgimento, seus níveis e focando em apresentar onde está a área de Garantia da Qualidade de Processo e Produto e as de Verificação e Validação, nível 2 e nível 3 respectivamente.

Abaixo, uma figura apresentando os 5 níveis do CMMI:

O José explicou algo que geralmente não é muito bem interpretado por nós brasileiros, a palavra Capability (o C do CMMI), cuja tradução em português, capabilidade, não traz o mesmo sentido da palavra em inglês. Capability é a capacidade de fazer algo constante, fazendo uma analogia, o McDonald’s tem uma excelente capability, pois o Big Mac tem um Mc de São Paulo é igual ao de um em Campinas, por exemplo.

Após a introdução sobre o CMMI, o assunto em pauta foi o MPS.BR, uma versão brasileira do CMMI, e assim sendo, adaptado a realidade brasileira.

O José começou a sua explicação sobre o MPS.BR, falando do seu surgimento, que ocorreu em 2003, e depois já abordou os 7 níveis de maturidade.

Uma experiência interessante relatada pelo José, foi que algumas empresas utilizam o MPS.BR (Melhoria de Processos do Software Brasileiro), como forma de início para depois poderem estarem melhor preparados para alcançar um nível de CMMI, já que há uma relação entre os níveis do CMMI e o MPS.BR, como pode ser visto na figura abaixo, além disso o custo de um processo de implantação do MPS.BR é mais em conta do que o do CMMI, e esse é um dos principais motivadores de algumas empresas fazerem isso.

Ou seja, a pessoa pode alcançar o nível A do MPS.BR e depois já tentar o nível 5 do CMMI.

E por fim foi comentando um pouco sobre o Modelo V, mais para ilustrar como que pode ser o processo de Verificação e Validação em uma empresa.

Coffee Break

Pra quem já leu sobre os coffee breaks dos encontros passados, fica até sem graça falar que mais uma vez foi excelente, pena que eu já tinha tomado café em casa (rs). Foram 30 minutos para aproveitar pra conhecer o pessoal melhor, enquanto come uns pãezinhos de queijo (e vice-versa rs).

Palestra do Emerson Rios

O Emerson Rios iniciou a sua palestra falando sobre o porquê da criação do MPT.BR (Melhoria de Processo de Teste Brasileiro):

  • Necessidade de ter um modelo de melhoria focado na área de Teste de Software;
  • Adaptar um modelo de Teste de Software para a realidade brasileira;
  • Ausência de implementadores estrangeiros, de outros modelos, aqui no Brasil;
  • Criar um modelo leve para Teste de Software.

O MPT.BR é um modelo que ainda está em desenvolvimento, mas já estão sendo feitos 3 projetos pilotos, em três empresas no Rio de Janeiro. Os três estarão se encerrando no mês de março desse ano, portanto a fase de piloto do MPT.BR estará terminada.

O modelo é compatível tanto com a MPS.BR quanto com o CMMI, principalmente pelo fato de ser baseado justamente no MPS.BR, que por sua vez é baseado no CMMI. O MPT.BR propõe-se ser um modelo leve, para que não sejam onerados os processos e para que também seja possível aplicá-lo em áreas de Teste de Software pequenas, que é muito comum existirem no Brasil.

Na sequência o Emerson falou sobre os 5 níveis do MPT.BR, apresentando de forma mais detalhada os dois primeiros:

Nível 1 Gerência de Projetos de Teste – GPT
Nivel 2 Gerência de Requisitos de Teste – GRT
Nivel 3 Aquisição – AQU (opcional)
Gerência de Configuração – GCO
Garantia da Qualidade – GQA
Medição – MED
Nivel 4 Gerência de Recursos Humanos – GRH
Gerência de Reutilização – GRU (opcional)
Gerência de Riscos – GRI
Nivel 5 Verificação – VER
Validação – VAL

A primeira coisa que você precisa fazer para saber se você está credenciado ou não para implementar o MPT.BR nível 1, é tratar o Teste de Software como projeto, e se você trata o Teste de Software na sua empresa como um projeto, o próximo passo é responder as questões da Análise de GAP – Nível 1 (disponível na página do MPT.BR).

Na página do MPT há vários documentos que poderão te ajudar a entender melhor o MPT, dentre os quais estão os documentos do Nível 1, Nível 2 e Nível 3 (beta). E o interessante é que como é um modelo que está em desenvolvimento, você pode entrar em contato com o Emerson Rios, para sugerir melhorias, reportas erros, etc.

No final o Emerson Rios passou informações sobre o credenciamento de implementadores, para o qual é necessário que o profissional tenha feito o curso oficial para implementadores da  Riosoft/ALATS e ter o diploma de certificação CBTS.

Conclusão

Confesso, que senti aquela preguiça ao levantar às 6:00 em pleno sabadão, ainda tudo escuro (esse horário de verão é fogo…), mas aí lembrei que é o encontro mensal, ou seja, não é só mais um evento, e sim uma oportunidade de encontrar os amigos e fazer novos, as palestras em si são só uma desculpa pra gente ir (afinal é muito mais fácil você falar pra sua(seu) esposa(o)/namorada(o) que vai em uma palestra de Teste de Software, em pleno sábado, do que falar que vai sair com os amigos…rs).

As duas palestras foram muito boas, ambas cumpriram o que se esperava, e acredito que todos puderam entender melhor porque existem modelos de maturidade, e qual importância que eles podem ter para a sua empresa.

Na minha opinião, eles são no mínimo uma ótima fonte de consulta, e o bom é que tanto o MPS.BR quanto o MPT.BR possuem material para download, em seus sites. Se você deve ou não deve ser certificado em um deles, é uma questão de interesse interno (ação pró-ativa) ou de “pressão” externa (ação reativa).

Tem gente que marca uma cerveja pra conversar com os amigos, outros um futebol, alguns um cinema, e a gente marca uma palestra. 😀 Portanto, se você está aí na sua ilha sozinho, não tem com quem falar sobre Teste de Software, ou simplesmente, gosta de conhecer novas pessoas, participe do encontro mensal que a ALATS-SP promove todo mês, pois você ainda irá poder aprender ou conhecer mais sobre um assunto da nossa área. 😉

Dia 20 de fevereiro é o próximo!

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

Fonte imagens:

Cachorro fugindo do gato – http://bit.ly/752y8Z

Remédio Genérico – http://bit.ly/4omlvN

CMMI – http://bit.ly/4HwOx3

MPS.BR X CMMI – http://bit.ly/6uAbeO

Pesquisa Cargos e Salários 2010

Pessoal,

O Cristiano Caetano está realizando pela segunda vez, uma pesquisa a respeito de cargos e salários na área de Teste e Qualidade de Software. PARTICIPEM!!! 😀

Link para a pesquisa:

http://www.testexpert.com.br/?q=node/231

Segue abaixo, maiores detalhes retirados do e-mail enviado pelo Cristiano Caetano, na lista de discussão do grupo Validação e Verificação de Software (VV-SW-Brasil).

Com o objetivo de atualizar os dados da pesquisa realizada em 2007, disponível em http://www.testexpert.com.br/?q=node/231, criei uma nova versão para 2010.

Esta pesquisa se propõe a desenhar o mapa dos profissionais de teste e qualidade de software do Brasil. Considerando que a área de teste e qualidade de software é uma das áreas em franca expansão da atualidade, o resultado dessa pesquisa será de grande interesse para todos vocês.

A pesquisa não levará mais que dois minutos para ser preenchida. Sinta-se à vontade para repassar esse email para todos os seus colegas de trabalho e amigos que trabalham nesta área, afinal, quanto mais respostas melhor.

A pesquisa ficará aberta para preenchimento até março. Não perca tempo, preencha os dados agora. Os resultados da pesquisa serão divulgados portal TestExpert.

Para preencher a pesquisa, acesse o seguinte endereço:

(A pesquisa é 100% anônima)

http://www.testexpert.com.br/pesquisa/index.php?sid=35766&lang=pt

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