Gerenciamento de Riscos voltado para Teste de Software

A 33ª Mesa Redonda DFTestes foi sobre “Gerenciamento de Riscos voltado para Teste de Software”. A discussão teve 3 respostas e 3 participantes, sendo eles: eu, Ana Paula Gomes e Sarah Pimentel.

Embora tenha tido poucas respostas, a mesa redonda gerou um bom conteúdo. Confira ele nos próximos parágrafos.

Devemos gerenciar os riscos de teste separados do desenvolvimento?

A Ana Paula respondeu a pergunta, contando um pouco da sua experiência:

O gerenciamento de riscos deve ser feito em conjunto com o planejamento estratégico da empresa, e principalmente com o desenvolvimento. A depender da demanda dos setores relacionados ao setor de Qualidade, todo o planejamento interno pode mudar.

Um exemplo desta situação, onde trabalho, é a obrigatoriedade do PAF-ECF na Bahia. Nós, do setor de Qualidade, cuidamos da homologação. Porém o desenvolvimento precisa estar atento aos prazos e aos novos requisitos inseridos pela secretaria da fazenda. Sem um planejamento conjunto, os riscos serão maiores.

Na minha opinião, depende do contexto. Se a equipe de teste é separada da de desenvolvimento, é bem provável que sim. Mas mesmo assim, haverá riscos inerentes as duas áreas, e que portanto deverão ser tratados por ambas as áreas.

Agora riscos relacionados exclusivamente com a área de Teste, podem muito bem se tratados separadamente, pelo responsável/gerente pela equipe.

Quais são os riscos mais frequentes em teste de software?

A Ana Paula citou três riscos mais frequentes:

- Implementações que geram outros erros (muito frequente quando não tem-se uma documentação bem estruturada ou uma matriz de rastreabilidade de requisitos);

- Pouco investimento em testes e qualidade e, consequentemente, falta de profissionais qualificados (falo isso pela situação na Bahia! :) Aqui poucas empresas investem.)

- Prazos apertados.

A Ana Paula tocou em três riscos que acredito que são os mais comuns:

  1. Qualidade dos builds/versões;
  2. Falta de profissionais qualificados;
  3. Atrasos.

O primeiro é um risco bem enjoado pra se gerenciar, pois ele é externo a equipe de Teste de Software, principalmente, quando essa se encontra separada da equipe de Desenvolvimento. Portanto, o que devemos fazer é propor ações para mitigar esse risco, como por exemplo:

  • Realização de testes unitários e integrados pelos desenvolvedores;
  • Implementar integração contínua;
  • Estabelecer uma métrica para que a versão/build seja considerado testável pela equipe de Testes, por exemplo, passar em 90% dos testes unitários e integrados;
  • Promover treinamentos aos desenvolvedores, tanto em relação a linguagem e boas práticas, quanto sobre o domínio de negócio do software.

Já o segundo podemos ter as seguintes ações:

  • Desenvolver talentos internamente;
  • Ter uma certificação/treinamento interna para balizar os conhecimentos dos profissionais;
  • Terceirizar os testes.

E o último, que é um dos riscos que mais tira o sono do pessoal (literalmente rs). Podemos:

  • Entregar/apresentar o software em intervalos mais curtos;
  • Revisar as estimativas a cada ciclo de desenvolvimento;
  • Monitorar o tempo gasto com as atividades;
  • Identificar possíveis gargalos e impedimentos que possam ocorrer (por exemplo, a máquina de integração contínua está muito lenta – trocar para uma máquina melhor);
  • Priorizar as atividades e buscar entregar o que agrega mais valor ao cliente primeiro.

A Sarah levantou uma ideia bem interessante, e que faz todo sentido para ser armazenado numa “base de conhecimento”, além de explicar alguns riscos, baseada em duas últimas experiências:

Cada projeto é um projeto, mas não sei se vocês têm a mesma impressão que eu, mas parece que tem riscos que podiam vir junto com o template do documento que registra/acompanha os riscos :)

Algumas das ultimas experiências que eu tive:

- Projeto de consultoria: Quality Assessment

Equipe de testes 90% terceirizada no modelo fábrica.

Por que é um risco: Porque a empresa se envolvia muito pouco no ‘modus operandis’ do terceiro e problemas que encontrássemos que tivesse raiz na fábrica tinha pouca probabilidade de ser resolvido. Além disso, tínhamos acesso restrito às informações sobre esse ‘modus operandis’ e o terceiro tinha todo direito de não nos atender.
Impacto: Altíssimo
Probabilidade: Alta
Ações previstas: Reuniões entre os lideres da empresa e do terceiro para explicar a nossa forma de trabalho, explicando que não se trata de uma auditoria de contrato e que as respostas seriam confidenciais e a própria empresa contratante não teria acesso a essas respostas diretamente.

Equipe de testes interna com auto estima muito elevada

Por que é um risco: Estranho não? Mas é que é complicado tu dizeres pra uma pessoa que o que ela acha que ela faz melhor que a grande maioria não é bem assim.

Impacto: Altíssimo. Se não quiserem nos ouvir, o projeto não gera nenhum resultado.
Probabilidade: Média. Não era possível aferir mais que isso porque ainda não conhecíamos a maturidade da equipe.
Ações previstas: Reuniões intermediárias de apresentações de findings para “preparar o espírito” para o relatório final.

Bom, esses eram os tops em minha opinião. Mas claro, sempre existem vários outros como confiança e conseqüente cooperação das áreas correlatas no trabalho realizado (um trabalho de quality assessment não pode contar somente com a equipe de testes como entrevistado e colaborador, precisa ser um trabalho holístico); previsão de orçamento interno para implantar as melhorias sugeridas; entre outros.

Esses trabalhos de consultoria são bem legais (eu gosto pelo menos rs), tem que ter conhecimentos diversos na área de TI pra meter o bedelho na área de todo mundo, mas principalmente tem que desenvolver bem um trabalho psicológico para não ferir os brios de ninguém, inspirar confiança e influenciar pessoas de modo a convencê-las dos ganhos que as mudanças podem trazer.

Já num outro projeto de delivery, eu entro em todos os pontos que o Fabrício e a Ana falaram, e ainda acrescento alguns complicadores como:

- A equipe de desenvolvimento já havia comunicado que não iria fazer testes unitários
- A data do projeto é uma daquelas datas previstas por astrólogos e negociadas com os deuses do Olímpio e se tu não cumprires vai ter toda uma vida de má sorte :P
- Um dos momentos mais emocionantes foi descobrir que não tinha tempo de re-trabalho previsto no cronograma.

Enfim. A gente tá sempre fazendo malabarismos na nossa área. Impressionante. Um bom gerenciamento de riscos permite NO MÍNIMO manter os olhos de todos abertos para todos os “problemas inevitáveis que estão por vir”, e com um pouco de sorte, conseguir impedir que alguns deles cheguem a afetar o projeto.

A propósito, outra experiência interessante desse ano foi ouvir: “Estou cansado de ouvir as pessoas falando nas reuniões de projeto sobre risco de não entrega de infra-estrutura. Está marcada para o dia 30/10. Atrasou? Não. Então não é um risco!”. É muito importante que antes de entrar numa reunião sobre riscos, os participantes tenham idéia de O QUE É um risco. Ajuda a acalmar os ânimos rs.

Além dos já citados, eu acrescento:

  • Não ter um ambiente de teste próximo do de produção;
  • Falta de expertise em determinada ferramenta;
  • Ausência de ferramentas para determinado teste;
  • Dificuldades em manter os testes automatizados;
  • etc.

Esse foi o resumo da 33ª Mesa Redonda DFTestes, se você quiser saber como foram as outras mesas redondas, confira os outros resumos.

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

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

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. :P

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.

É possível realizar documentação de testes quando trabalhamos com metodologias ágeis? Digo, desde o plano de teste até o caso de teste, isso é possível?

Após um bom tempo sem fazer os resumos das excelentes mesas redondas virtuais, que ocorrem no grupo de discussão DFTestes. Nos próximo parágrafos, segue o resumo da 31ª Mesa Redonda DFTestes (sim, a minha intenção e fazer o resumo de todas que ocorreram no período em que parei de fazer os resumos).

Essa mesa redonda teve 7 respostas e 7 participantes, sendo eles: eu, Lidiane Santos, Shmuel Gershon, Felipe Silva, Fermiano de Queiroz, Sarah Pimentel e Ueslei Silva.

É possível realizar documentação de testes quando trabalhamos com metodologias ágeis? Digo, desde o plano de teste até o caso de teste, isso é possível?

A Lidiane deu a sua contribuição dizendo:

É possível sim, fazer documentação em um proceso ágil, mesmo porque você começa desenvolvendo em cima dos cenarios de testes que foram levantados.

E eu já trabalhei muito em empresas que não utilizam o processo agil, mas já testei muito software sem documentação, indo apenas pela intuição e conforme vou testando vou documentando os testes.

Acho que essa associação de Teste de Software = Documentação e Burocrácia é coisa do passado.

Para o Shmuel, você pode tanto documentar, como não documentar, quando está trabalhando com metodologias ágeis:

É possivel realizar documentacao de testes quando trabalhamos com metodologias ágeis.

E também, é possível não realizar documentação de testes quando trabalhamos sem metodologias ágeis. Surpresa!

O Fermiano contou um pouco da sua experiência atual:

Sei que existem testadores que usam deste argumento, mas também vejo testadores fazendo o contrário. Felizmente, aqui a maioria encara os desafios da função e assume os riscos, sedentos por um teste exploratório. Documentação também depende do processo utilizado, precisamos seguir os planos de testes para garantir o sucesso obtido em projetos anteriores. Em nosso processo temos uma variedade de testes, com base em planos de teste e, também, exploratórios, em várias etapas. Toda a documentação “necessária” para os testes é gerada durante essas etapas, de acordo com cada etapa do processo.

A Sarah tocou num ponto bem importante, o de que as metodologias ágeis muitas vezes não são utilizadas corretamente, e passam a ser apenas para mascarar que não está sendo utilizado nenhuma metodologia:

Pois é.. Uma questão é que muitas vezes quando alguém me diz “nesse projeto vamos usar metodologias ágeis” me dá um frio na espinha e eu já saio correndo pra mesa do SQA dizendo pra ele fazer alguma coisa, porque em muitos casos eu sei que ‘usar metodologia ágil’ é uma desculpa pra não usar metodologia alguma. A metodologia passa a ser: precisamos entregar para o cliente um monte de pedaços de sistemas e fazer várias entregas e rápidas.

Completamente deturpado. Não existe envolvimento próximo do cliente, não tem ninguém capacitado na equipe para conduzir o time nas práticas da metodologia escolhida, a equipe é formada por um grande numero de profissionais juniors, ou seja: tem tudo pra ser um desastre.

Não tô dizendo que NINGUÉM sabe fazer projeto ágil, por favor. Tô dizendo que HÁ CASOS, em que ‘metodologia ágil’ é desculpa para não usar metodologia alguma. Se não tiver um responsável fazendo às vezes de SQA (no sentido de orientar a equipe e até mesmo intervir na escolha da metodologia) o negócio desanda feio.

Então metodologia ágil pode ou não ter o teste documentado, dependendo da necessidade do projeto.

Se para testar é necessário ter uma vasta documentação, já discutimos isso antes. A minha opinião é: não.

O Ueslei compartilhou um pouco da sua experiência:

Depende!

Atualmente estou alocado em uma empresa que usa desenvolvimento ágil. Junto com o Desensolvimento, estão 3 pessoas encarregadas pelos testes.

As histórias de usuário criadas pelo desenvolvedor, são levantadas com base nas especificações que são realizadas por uma área específica.

A equipe de teste, utilizam tais especificações para realização da primeira bateria de testes.

Mas, isso não é tudo. Temos também uma outra equipe de testes, com perfil de homologação/aceitação, mas que explora os sistemas com maior granularidade do que os conhecidos testes de aceitação.

Esta equipe, é formada por 10 colaboradores. Esta equipe, também com base nas especificações, geram documentos de casos de teste e automação de teste.

Bom! no nosso ambiente, além de ágil, temos outros processos que suportam as necessidades e geram artefatos. Mas, mesmo que uma organização use ágil puro, ainda sim, seria interessante usar documentos, mesmo que simples. Por exemplo, mapas do que é interessante ser testado. Assim, o conhecimento não fica tácito nem corre-se o risco de algo importante cair no esquecimento.

Eu acredito que sim. Porém, pensando em uma equipe que é realmente ágil ou pelo menos busca respeitar os princípios ágeis, talvez não seja necessário realizar um plano de teste. Copiando e colando um exemplo que dei num comentário no blog As Especialistas, relacionado ao assunto:

De acordo com o contexto, podemos até não utilizar o Plano de Teste, mas isso não significa que estaremos pulando a fase de planejamento (que é essencial), mas sim que podemos utilizar outras formas de fazer o planejamento.

Para ilustrar o que quero dizer, vamos pensar numa equipe de Teste de Software com 3 pessoas, que testam um sistema que é desenvolvido em ciclos de 2 semanas. A cada ciclo de desenvolvimento novas funcionalidades são adicionadas e também bugs são resolvidos.

Para esta equipe, o planejamento do Teste de Software pode ser iniciado na própria reunião de planejamento do ciclo de desenvolvimento, da qual já podem sair, por exemplo, com as funcionalidades que serão testadas, o que não será testado, ambientes que serão usados e os prazos.

Depois os três podem fazer uma reunião entre eles para detalhar melhor o planejamento de teste. Deste detalhamento podem sair com vários post-its para serem colocados num quadro ou com um checklist num Google Docs, por exemplo.

O que ocorre é que “o Método mais eficiente e eficaz de transmitir informações para, e por dentro de um time de desenvolvimento, é através de uma conversa cara a cara”, portanto toda documentação que você faria apenas com o objetivo de comunicar algo a alguém será provavelmente, descartada.

Por que raios, quando se fala em Teste de Software, as pessoas logo lembram de documentação, e não de testes em si? Por que os profissionais de Teste de Software ainda são tão dependentes de documentação?

Segundo o Shmuel:

Um dos motivos da ligação Teste de Software –> Documentação é esse mesmo, os testadores passarem o tempo tentando provar que da pra documentar, e tentando gerar documentação suficiente pra se proteger atrás dela. Quem nunca ouviu um testador falando: “Testei o que está nos requerimentos”, “esse bug eu perdi, porque não esta no plano de testes”, “Já terminamos os testes: 100% do plano de testes”… ? Acho que essa associação é culpa nossa, mais do que culpa deles.

O Felipe Silva comentou a resposta do Shmuel dizendo:

Que jogue a primeira pedra aquele que nunca se protegeu atrás de documentação.

Na minha opinião, a documentação acaba sendo uma forma da gente se defender. E além disso, muitos profissionais foram influenciados por processos que tem em sua saída a produção de artefatos. Então, acabamos utilizando a documentação até mesmo em ocasiões onde ela não é necessário (ex.: comunicação).

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

Livro DFTestes – disponível versão Wiki

Como alguns de vocês devem saber, estou participando da elaboração do livro sobre as Mesas Redondas (MR) da lista DFTestes.

Esse livro é baseado nas MRs, mas o seu conteúdo não se restringe apenas a elas. São 10 capítulos, baseados nas 10 primeiras MRs. Ou seja, são capítulos sobre temas bem diversos, cobrindo desde assuntos básicos como a importância de se testar, como temas mais avançados como automação de testes e Testes no contexto ágil.

Em breve sairá o e-book, mas já colocamos todos os capítulos numa Wiki. Acessem em: http://3.ly/LivroDFTestes/

O que achou do livro? Deixe nos comentários.

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

Automação de testes funcionais

A 30ª Mesa Redonda DFTestes, que ocorreu na primeira quinzena de agosto, foi sobre “Automação de testes funcionais”. A mesa redonda gerou bastante discussão, totalizando 29 respostas e tendo 10 participantes, sendo eles: eu, Juraci Vieira, Felipe Silva, Shmuel Gershon, Elias Nogueira, Rodrigo Almeida, Ueslei Aquino, Luiz Gustavo, Fermiano de Queiroz e Roberto Passani.

Segue abaixo, o resumo desta mesa redonda, quem quiser conferir a discussão na íntegra, só acessar esse link.

Vocês acham a automação dos testes funcionais necessária? Se sim, você sempre tenta automatizar os testes funcionais, como?

Segundo o Juraci Vieira:

Certamente é necessária uma vez que os ciclos do desenvolvimento de software estão cada vez mais ágeis e os softwares cada vez mais complexos, para cobrir a complexidade crescente é necessário grande quantidade de casos de teste, e para se adequar ao curto prazo de tempo é necessário executar essa grande quantidade de testes de maneira mais eficiente porém, mantendo a acurácia. Isso é possível com a automação de testes funcionais.

Outra razão para se utilizar automação de testes funcionais seria para investir mais tempo no trabalho de análise do software e desenvolvimento dos casos de testes (para que os mesmos sejam mais eficazes em encontrar defeitos) do que na execução propriamente dita. Digo isso em casos de equipes pequenas de teste como é o meu caso em que sou o analista de testes e o executor dos testes. Isso me poupa tempo pra planejar melhor o que fazer.

O Juraci automatiza os testes funcionais da seguinte maneira:

Eu sempre tento automatizar aqueles casos de testes repetitivos e que exigem bastante atenção, nem sempre você está com a atenção 100% para executar o mesmo teste manual passo a passo, esquecer-se de um detalhe é normal para seres humanos. Prefiro investir um tempo até dez vezes maior para automatizar um caso de teste assim do que executa-lo sempre manualmente com o risco de errar algum passo e mascarar o resultado do teste.

Automatizo utilizando 2 softwares livres AutoIt e QAliber. Tenho um certo domínio sobre o AutoIt e o mesmo satisfaz minhas necessidades. O QAliber tenho estudado a cerca de um mês e logo utilizarei em um projeto “vivo”.

O Felipe Silva também acredita que a automação dos testes funcionais é necessária, e segundo ele é importante para manter a competitividade e consenguir atender as demandas:

Sim, é necessário principalmente para que se possa ser competitivo o suficiente para conseguir manter os atuais e clientes e ganhar novos, a automação também ajuda na qualidade dos testes, uma vez que pode-se concentrar o foco dos testes mais na análise de futuros novos erros do que em regressões, em certos casos é possível automatizar aquilo que ainda está apenas nos requisitos, ganhando agilidade também desde os primeiros ciclos de testes (deixando a “malhar grossa” na automação e a “malha fina” nos testes manuais).

O Felipe Silva compartilhou como ele faz a automação dos testes funcionais, dizendo:

Sim, sempre que possível e viável tentamos planejar a automação, não só de testes funcionais, mas todo tipo de automação que traga bons resultados, nem que só possamos começar a trabalhar nisso só daqui alguns meses, como ferramentas temos QTP (Quick Test Professional), Selenium, o próprio Java, tem coisas que acabam sendo automatizadas com Macros.

Segundo o Shmuel  a automação nem sempre é necessária:

A automação dos testes não é necessária. Ela pode ser vantajosa às vezes, ou prática, ou até mesmo agradável. Mas nem sempre ela é necessária.

Por outro lado, eu tento automatizar testes funcionais, claro. Existem testes que trazem beneficio quando automatizados.

Eu uso batch files, VBScript ou C# quando escrevo minhas automações. Já usei AutoHotKey (“irmão” do AutoIT mencionado pelo Juraci), VB, Ruby e Perl também, mas menos.

O Elias Nogueira destacou a importância de uma análise de viabilidade:

A automação nem sempre é viável, eu mesmo já recebi diversas demandas de clientes internos querendo “firulas” para “melhorar o seu trabalho”, mas de nada traz ganho como um todo para a organização.

Sempre, mas sempre que pensarmos em automação é necessário uma análise de viabilidade. Ela não precisa ser um documento mega extenso e difícil de ler, mas um tempo em que necessitamos avaliar se realmente a automação faz sentido ou traz ganhos em potencial.

Hoje mesmo tive um caso em que a automação solicitada, depois de fazer uma PoC (Prova de Conceito), só iria trazer benefícios após o 42° ciclo de execução, para um sistema que executa 1 ciclo mensal. O Analista de Teste que solicitou isso vê um ganho pra ele, mas eu nao vejo ganho em alocar minha equipe num trabalho que não trará um retorno esperado.

E o Elias, ainda complementou dizendo:

A automação é uma das ferramentas para o Teste, e não deve sempre ser tomado como lei nas empresas. Mas isso, como sempre depende…

Como o próprio Shamuel relatou em suas experiências em automação, podemos utilizar qualquer artifício para automatizar: shell script, AWK, programação pura, ferramentas de automação, etc…

A automação de teste, às vezes, mas atrapalha do que ajuda. Isso se deve a diversos fatores, como o próprio entendimento da automação por parte dos stakeholders (lembrem do gerente sem noção, que acha que a automação é como um “testa aí”, basta dar record-and-play e tudo se resolve), senioridade/conhecimento técnico da equipe e conhecimento de negócio por parte dos Analistas de Teste (sim, se estes não souberem especificar bons testes, estaremos fazendo uma má automação).

O Rodrigo Almeida resumiu bem a sua opinião sobre o assunto, dizendo:

Eu tenho certeza que ela é necessária. Para ter produtividade alta é preciso ter automação. O segredo é saber quais casos de teste escrever e automatizar!

Saber quais são os testes que são necessários ser automatizados é importante segundo o Rodrigo:

Sempre. Desde que o seu ROI seja positivo, ou seja, precisamos automatizar os casos de teste corretos. Casos de teste para telas CRUD de sistemas não precisam ser automatizadas. E eu acho que precisa fazer teste uma vez só na vida para estas telas. O que precisa ter teste automatizado são as funcionalidades do núcleo do sistema, que contém as regras de negócio do sistema que o cliente usa. Se estas regras sofreram algum impacto em alguma mudança realizada no sistema/ERP, só saberemos na execução dos testes funcionais automatizados.

Sobre a necessidade de automatizar testes de CRUD (Create-Read-Update-Delete), o Elias Nogueira acredita que tudo depende da situação, em determinados casos a automação de tais testes pode sim ser fazer necessária:

Em alguns tipos de sistemas o CRUD é o que é mais utilizado (e mail alterado) pelo cliente.

O importante é ter foco no que o cliente realmente usa e também no que ele realmente quer… Se precisar automatizar uma parte ínfima de uma tela ou regra que nunca é utilizada para agradar o cliente, temos que automatizá-la.
Isso é meio “ruim” pra nos, não gostamos, mas é o valor que o cliente vê nisso que nos faz ser vistos com bons olhos e como uma equipe que agraga valor.

O Ueslei Aquino, concorda com o Elias, e expôs uma experiência, falando:

Em uma experiência que tive, o cliente afirmava que “garantindo que, em cada tela do sistema eu consiga Cadastrar, Consultar, Alterar e Deletar, já posso garantir que alguma coisa funciona”. Essa foi a primeira meta colocada pelo cliente para a automatização.
Buscando entender o motivo, fizemos uma busca pelo sistema de chamados da empresa. E um grande número de chamados de cliente eram de relamação de defeitos nestes pontos.
O Ambiente era um ERP com mais de 20 módulos integrados.
Sobre o assunto, o que acho estranho, é que sempre que falamos sobre automação, alguém vem defender os testes manuais. Automação não exclui os testes manuais, aliás, um dos objetivos de automatizar os testes funcionais, é justamente para poder ter tempo para fazer outros testes, afinal não testamos apenas para garantir a “funcionabilidade” dele, há outras cinco características que poderão ser bem importantes para o sistema.
O Luiz Gustavo acredita que a necessidade de automação dos testes funcionais depende de vários fatores: 

De maneira geral:

- Da rotina dos testadores

- Do conhecimento sobre automação da equipe de testes

- Da tecnologia do sistema

- Da ferramenta de automação a ser utilizada (por isso é aconselhável estudar os benefícios de cada ferramenta antes de aplicá-la, sendo assim, não existe ferramenta “ideal” ou “melhor”)

- Do orçamento do projeto

- Se os prazos estão apertados (se não, é melhor fazer os testes manualmente, por motivos óbvios)

- Se possui um ambiente de testes dedicado

Mais especificamente:

- Se as funcionalidades a ser testadas se repetem (Regression Testing)

- Do esforço necessário para preparação do ambiente de testes (a massa de dados pode ser toda amarrada via Regras de Negócio, e isso dá um trabalhão…)

- entre outros.

Para o Fermiano talvez ela não seja necessária, mas pode ser uma possibilidade a ser considerada:

Eu não diria que a automatização de testes funcionais é necessária, mas a atenção para essa possibilidade sim.

Estamos sempre atentos para essa possibilidade, mas os fatores já citados aqui indicam que os testes manuais são mais eficazes e eficientes para a maioria dos casos. Automatizamos sim, mas é uma pequena fração da totalidade dos testes.

Exemplo: Numa etapa da fase de validação usamos um roteiro de testes para os testes de regressão. Esse roteiro possui aproximadamente 200 situações complexas de testes a serem executados, necessitando aproximadamente de 5 dias para ser completado (execução e verificação dos resultados). Não é raro alguém perguntar quando teremos 100% desse roteiro automatizado. A realidade é que apenas 30%, no máximo, desse roteiro poderá ser automatizado.
O Felipe Silva deu a sua contribuição dizendo:
A necessidade automatizar ou não vai do jeito em que as coisas são conduzidas em cada projeto, por exemplo no meu projeto trabalhamos tão corrido que enquanto estamos testando a release atual já estamos estimando e criado cenários e casos de testes para a próxima release, se alguém fosse parar para automatizar regression a próxima release iria atrasar, e as regras mudando toda release, em outras palavras o que chamamos de regression “hoje” tá mais pra “coisas que restaram da release passada”, não conseguimos nem manter os TCs que são super pequenos e nada detalhados, quem dera manter atualizados scripts, aqui vale mais a pena automatizar alguns procedimentos genéricos do que automatizar validações.
Mas tem empresas também em que as pessoas ficam focadas em uma release só, e acompanham o projeto desde a fase de requisitos até a homologação, enquanto os devs nem escreveram os códigos eles tem tempo para fazer um monte de coisa, quando é assim é, se o FW é conhecido é possível até automatizar desde o ciclo 1 paralelamente a implementação (aqui sim vejo ganho na automatização), então assim que a primeira build é gerada deixa-se uma maquina dedicada rodando os scripts dia e noite (se possível em integração contínua), e os testers seguem suas vidas normalmente em suas 8hs diárias executando os testes “pente fino” manuais. Pensando nisso, na release 2 os scripts das funcionalidades da release 1 já estariam lá, então novamente paralelamente a criação do código da release 2 iriam criar os scripts da release 2, se alguma coisa da release 2 quebrar alguma coisa da release 1 espera-se que os scripts da release 1 achem isso enquanto os testers estão focados na release 2. 

Não tenho como ser genérico em tirar uma conclusão geral que automação de testes funcionais em ciclos de regressão sempre são viáveis.

Testes sustentáveis, o que raios é isso?

No início da discussão coloquei que a automação dos testes funcionais é muito importante para se testar de forma sustentável, pois é muito difícil garantir a qualidade de um sistema apenas com testes manuais.

O Shmuel fez considerações pertinentes sobre essa minha colocação, que me fizeram explicar melhor o que seria testar de forma sustentável.

Primeiramente, testes sustentáveis são importantes para podermos garantir a qualidade do sistema a longo prazo. Pois pode ocorrer de precisarmos de esforço X para testar o sistema, no início do desenvolvimento, e 2X para testar o sistema nas etapas finais de desenvolvimento, cenário esse que revela que algo pode estar errado.

Testar de forma sustentável serial algo como testar de forma eficiente, ou seja, com o mínimo de esforço e o máximo de eficiência.

Ou melhor, testar de uma forma que fosse possível garantir um bom nível de qualidade, ao longo de todo o projeto, buscando investir um esforço sempre parecido. Ou seja, garantir a qualidade tanto quando o sistema tem apenas 2 funcionalidades, como quando ele tem 50.

Para tentar explicar o “conceito”: imagine que estamos no ano de 2006 e você trabalha no Google, mais precisamente na célula de desenvolvimento do Google Docs. Como todos sabem, o Google Docs é uma ferramenta que teve o seu desenvolvimento de forma incremental, e você como incubido de testar ele. Você precisará fazer vários testes a cada nova versão, sendo que boa parte destes testes, já foram feitos antes.

Se você fosse testar sempre de forma manual, acabaria entrando numa rotina, que sempre teria mais e mais testes para executar e isto com certeza iria impactar no projeto, uma vez que ou você necessitará de mais pessoas para te ajudar ou o prazo para a entrega será sempre maior, afinal a cada lançamento você terá mais testes para fazer.

Mas você é o Shmuel, uma pessoa consciente e que sabe da importância da sustentabilidade para o Teste de Software, por isso já em 2006 percebe que boa parte dos testes podem ser automatizados, e isso iria aliviar bastante o seu trabalho e você teria tempo para fazer outros testes mais complexos, que poderiam obter novas informações e que necessitariam de análises que um computador não consegue fazer (por exemplo, testes de usabilidade).

A ideia de sustentável seria essa. Meio viajante eu sei, e muito bonita na teória.

Você estuda a viabilidade de automação e planeja, ou simplemente ‘põe a mão na massa’?

O Juraci respondeu dizendo:

Eu estudo sim a viabilidade para cada caso de teste, em um projeto eu tenho casos de teste candidatos a automação. São aqueles repetitivos que serão utilizados em uma futura regressão, testes massantes tais como o mencionado anteriormente, testes que revelaram falhas no software também são candidatos pois mostram o seu valor durante o teste de regressão. Vale destacar que o caso de teste é a base para a automação, é o requisito do “sotftware/aplicativo/script” que será o produto da automação, não adianta ‘colocar a mão na massa’ sem ter os casos de teste bem definidos, pois isto equivale a ter um requisito fraco e que irá acarretar em muito mais transtorno como foi comentado.

O Ferminiano também fazer um estudo antes:

Sim, fazemos um estudo de viabilidade de automatização. Sempre aparece alguém querendo automatizar alguma coisa, pensando que basta apertar um uma tecla e pronto, como já disseram aqui na lista. Um breve estudo de viabilidade mostra que apenas algumas poucas vezes isso é possível.

Bem pessoal é isso, espero que tenham gostado do resumo, que mesmo atrasado não poderia faltar, pois essa discussão foi excelente, aliás, se você quiser saber mais, acesse o link para a página do DFTestes com a discussão na íntegra. ;)

Quais as diferenças entre Analista de Qualidade e Analista de Teste?

O tema da 28ª Mesa Redonda DFTestes foi “Quais as diferenças entre Analista de Qualidade e Analista de Teste?”. A discussão teve 7 respostas e 7 participantes, sendo eles: eu, Ricardo Henrique, Felipe Silva, Adriano Martins, Bruno Rojo, Janaina Trilles e Luis Barros.

Abaixo segue o resumo (antes tarde do que mais tarde rs) dessa mesa redonda que teve como tema uma pergunta aparentemente simples, mas que costuma gerar confusões.

Quais as diferenças entre Analista de Qualidade e Analista de Teste?

Para o Ricardo Henrique a diferença é:

Analista de teste seria aquele envolvido especificamente na área de testes de software elaborando casos de testes e executando. Já o analista de qualidade seria aquela pessoa envolvida no trabalho que define um processo de desenvolvimento de software e depois certifica esse processo.

O Felipe Silva concordou com a diferença apresentada pelo Ricardo e levantou uma questão pertinente:

Eu concordo com você.

- Mas é realmente esse profissional que as empresas procuram quando abrem uma vaga para Analista de Qualidade?

Pergunto isso já vi várias vagas por ai com nome de Analista de Qualidade pedindo requisitos de Analista de Testes.

Alguém ai é Analista de Qualidade ou  participou de um processo seletivo destes? Caso sim, por favor compartilhe um pouco do que é esperado do profissional e quais seriam suas atividades do dia a dia.

Na minha opinião, a confusão já começa na distinção do que é Teste de Software e o que é Garantia de Qualidade do Software (SQA). O artigo do Fábio Martinho nos ajuda a perceber as diferenças e vai mais afundo nas diferenças entre Qualidade, Qualidade do Software e SQA.

Um agravante ainda, é que em empresas pequenas/médias, geralmente o profissional acaba exercendo algumas funções tanto de Analista de Qualidade, quanto de Teste.

Ao me ver, o Analista de Qualidade é um profissional da área de SQA, já o Analista de Teste é um profissional da área de Teste de Software.

O QAI faz essa diferenciação, tanto que há a Certified Software Quality Analyst (CSQA), para profissionais de SQA e a Certified Software Tester (CSTE), para profissionais de Teste de Software.

Resumindo, as atividades de uma Analista de Qualidade são diferentes da do Analista de Teste, portanto são cargos diferentes, embora seja comum a sobreposição de funções em muitas empresas.

O Adriano resumiu muito bem a diferença entre Analista de Teste e Analista de Qualidade dizendo:

Analista de Teste: Valida o produto
Analista de Qualidade: Valida o processo

O Luis Barros compartilhou uma experiência que ilustra a diferença entre o Analista de Teste e o de Qualidade:

Já fui Analista de Testes dentro de umas área de Qualidade.

Como “funcionava”:

Meu superior direto era o mesmo superior do Analista de Qualidade.

Mas eu trabalhava mesmo era envolvido no projeto de desenvolvimento, inclusive era auditado pelo meu colega ao lado.

De certa forma isso me ajudou bastante a amadurecer a disciplina dos processos que a empresa seguia, pois era assunto constante nas reuniões com nosso gerente. Mas os detalhes dos testes dos projetos acabavam sendo discutidos com outros gerentes.

Era estranho mas sempre se aproveita algo.

Bem pessoal é isso. Continuem de olho na lista do DFTestes, pois sempre há assuntos bem interessantes lá.

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

Livro “Conversando sobre Teste de Software” está disponível

Pessoal,

Quem participa de listas de discussões sabe que algumas discussões produzem um conteúdo muito bom. Porém, o mesmo fica restrito aos participantes da lista e acaba sendo esquecido com o passar do tempo.

Pensando nisso e aproveitando as periódicas mesas redondas que ocorrem na lista do DFTestes. Aproveitamos o conteúdo delas para fazer um livro no formato ebook.

O livro em si ainda não está pronto (faltam apenas dois capítulos, que já estão em processo de revisão), mas os capítulos finalizados foram disponibilizados na web, em formato wiki. O link para acessar os capítulos é o seguinte:

http://3.ly/LivroDFTestes/

Esse primeiro livro está cobrindo as 10 primeiras Mesas Redondas DFTestes, sendo que os seguintes temas são abordados:

Esses capítulos não são simples resumos das mesas redondas (como os que faço aqui no blog), e sim textos cuja fonte principal são as mesas redondas, mas que também são baseados em grandes obras da literatura de Teste de Software e “temperados” com a experiência de profissionais que atuam na área de Teste de Software.

Então, se você atua na área de Teste de Software ou se interessa pelo assunto, esse livro poderá te ajudar nos estudos e a ter uma melhor compreensão dessa área tão fascinante.

Abraços!

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