Automação de testes: Aproximando contextos

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

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

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

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

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

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

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

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

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

Anúncios

IEEE 1028 – Padrão para Revisões de Software

Um amigo meu, o Edimilson Estevam, fez o último exame da CTFL, e comentou comigo que caiu algumas questões a respeito desse padrão do IEEE.

Eu particularmente nunca tinha ouvido falar a respeito dele, nem na época que me preparei para a CTFL.

O intuito desse post, é compartilhar esse padrão (enviado pelo Edimilson – obrigado!), e também fazer um resumo a respeito dele.

O que é o IEEE 1028?

Como todo padrão elaborado pelo IEEE (lê-se “I três E”), o 1028 é fruto do trabalho voluntário de alguns membros do IEEE. E sendo um padrão, eles nos traz algumas importantes e relevantes informações a respeito de revisão de software. Mas é sempre bom lembrar, que ele deve ser usado com bom senso, pois o contexto sempre prevalece sob o padrão (ou deveria prevalecer).

O IEEE 1028 nos traz cinco tipos de revisão de software, junto com os procedimento necessários para a execuçaõ de cada tipo. Está fora do escopo do padrão questões como: quando uma revisão se faz necessária? como escolher qual tipo de revisão deve ser usado?

Os 5 tipos de revisão abordados são:

  • Revisões gerenciais;
  • Revisões técnicas;
  • Inspeções;
  • Walk-throughs;
  • Auditórias.

Os cinco tipos de revisão

Segue abaixo, a tradução do anexo B do padrão, que contém uma tabela comparativa entre os tipos de revisão (o texto original está numa linguagem meio chata de entender, e não consegui melhorar muito na tradução – se notarem algum erro ou melhoria, por favor me avisem):

Característica Revisão gerencial Revisão técnica Inspeção Walk-through Auditória
Objetivo Garantir o progresso; recomendar ações corretivas; garantir alocação correta dos recursos Avaliar a conformidade do estado atual com as especificações e planos; garantir integridade da mudança Encontrar anomalias; verificar decisões; verificar a qualidade do produto Encontrar anomalias; examinar alternativas; melhorar o produto; fórum para aprendizado Avaliação independente de cumprimento com os objetivos de padrões e regulamentos
Tomada de decisão A equipe de gerenciamento traça o curso da ação; decisões são feitas na reunião ou como resultado das recomenda-ções A equipe de revisão solicita aos gerentes ou a liderança técnica que atuem nas recomendações A equipe de revisão escolhe as disposições pré-definidas do produto; os defeitos devem ser removidos A equipe concorda com as mudanças para serem feitas pelo autor Organização auditada, iniciador, comprador, cliente ou usuário
Verificação das mudanças O líder verifica que itens são fechados; a verificação das mudanças é deixada para outros controles do projeto O líder verifica que itens são fechados; a verificação das mudanças é deixada para outros controles do projeto O líder verifica que itens são fechados; a verificação das mudanças é deixada para outros controles do projeto O líder verifica que itens são fechados; a verificação das mudanças é deixada para outros controles do projeto Responsabili-dade da organização auditada
Tamanho recomendado do grupo Duas ou mais pessoas Três ou mais pessoas Três a seis pessoas Duas a sete pessoas Uma a sete pessoas
Quem participa Gerentes, liderença técnica e algumas pessoas de outras áreas Liderença técnica e algumas pessoas de outras áreas Pessoas da área com acompanhe-mento documen-tado Liderença técnica e algumas pessoas de outras áreas Auditores, organização auditada, pessoal de gerência e técnico
Grupo da liderança Normalmente o gerente responsável Normalmente o engenheiro líder Um facilitador treinado O facilitador ou o autor O auditor líder
Volume de materiais Moderado para muito, depende dos objetivos da reunião Moderado para muito, depende dos objetivos da reunião Relativa-mente baixo Relativa-mente baixo Moderado para muito, depende dos objetivos da reunião

Abaixo, segue o link para baixar o padrão IEEE 1028:

http://bit.ly/ieee_1028

3 anos!!!

Como o tempo passa, parece que foi ontem que estava escrevendo o primeiro post do QualidadeBR.

É… já fazem três anos que o QualidadeBR nasceu, e com certeza há muita história pra contar sobre esses três anos, além do 282 posts que já foram publicados nesse período.

Mas hoje vou deixar um pouco de lado a temática do blog, e falar a respeito de 3 coisas que o QualidadeBR me proporcionou nesses 3 anos.

Conhecer pessoas

Sem dúvidas um dos pontos mais legais de ter criado o QualidadeBR foi ter a oportunidade de conhecer tantas pessoas, desde outros blogueiros até leitores. Vários deles considero verdadeiros amigos, mesmo não conhecendo alguns pessoalmente.

Acredito que esse seja uma das coisas mais bacanas ao se criar um blog, independente do assunto.

Ajudar pessoas

Como sabem o QualidadeBR não possui nenhum tipo de apoio financeiro ou veiculação de propaganda. Nunca ganhei nenhum centavo com ele, e aliás, essa nunca foi a minha intenção (não que eu ache ruim apoiadores ou veicular propagandas, muito pelo contrário).

Mas algo que ganhei e isso não tem preço, é o prazer de poder ajudar as pessoas, seja por meio do próprio conteúdo do blog, ou via e-mail.

Então se você gosta de ajudar as pessoas, criar um blog pode ser uma boa forma de fazer isso.

Aprendizado

A minha intenção inicial com o QualidadeBR era me motivar a continuar os estudos na área de Teste de Software, pois tinha acabado de obter a CBTS, e não queria me acomodar, muito pelo contrário, queria estudar sobre novos assuntos e compartilhar experiências e o pouco que conhecia da área na época.

O QualidadeBR me fez e ainda faz aprender muito, seja durante as pesquisas para um post, firmando conhecimentos durante a escrita ou até mesmo por meio dos comentários dos leitores.

Se você gosta de estar sempre aprendendo, um blog pode ser uma boa forma de motivar os seus estudos e além disso, você estará compartilhando eles com outras pessoas.

Bem é isso. Obrigado a todos leitores por acompanhar o QualidadeBR. 🙂

Software Testing Weekly

Se você gosta de receber newsletters informativos (não spams) e se interessa por Teste de Software, o Software Testing Weekly lhe será útil.

Baseado no Ruby Weekly e derivados (ex.: NoSQL Weekly), o Software Testing Weekly irá trazer toda segunda-feira, um resumo do que ocorreu na comunidade de Teste de Software, tanto em blogs como em grupos de discussão.

Para receber, basta se inscrever no seguinte endereço: http://eepurl.com/3Yvc. E veja um piloto aqui: http://bit.ly/exemplo_stw.

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 😛
– 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. 😛

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.