Plano de Automação de Testes

Oi pessoal, bom dia!

Dei uma pesquisada na web por documentos/planos de automação de testes, mas não encontrei nenhum de exemplo. Estava querendo apresentar um para meu gestor da empresa, para a equipe de desenvolvimento levar o projeto de automação adiante.

Estou querendo elaborar um. Quais os tópicos que precisam ser abordados? Por exemplo, escolha da ferramenta na qual será utilizada, o tempo de treinamento das equipes, bibliografias que serão utilizadas, o que será automatizado, prazos, entre outros. Quais as sugestões de vocês?

Desejo um ótimo dia para todos e para os que puderem contribuir desde já agradeço.

Esse plano é para “qualquer tecnologia que cair no colo” ou para algo mais específico?

@Ramses-Saccol-de-Almeida é para uma tecnologia mais específica. Por exemplo, aqui na empresa desenvolvemos com Ruby. Tenho experiência com BDD através do JBehave. Penso muito em sugerir no plano a automação envolvendo Cucumber + alguma outra ferramenta de testes unitários. Para interface, iria sugerir Capybara (Cucumber + Selenium Webdriver), mas para um momento futuro.

As validações seriam mais a nível comparativo de valores: No dia-a-dia, geramos relatórios com cálculos pesados, que automatizando ganharemos um bom tempo para nos concentrarmos em outras atividades.

Na verdade eu pensaria no processo em onde tu pode ganhar tempo. Se , entendi certo, mexe com relatórios, talvez pegar mais pedaços do sistema e testar eles unitariamente, pode tirar algum peso dos testes de interface. Sobre a tecnologia, vale uma POC com outras ferramentas. Na verdade tu pode colocar no processo um tempo de pesquisa para isso.
O que eu faria é: separar onde posso ganhar com automação (e onde sei que vai ser um processo custoso), nessa parte onde ganho, como posso testar e gerar mais valor…E depois uma parte para pesquisa/avanço/manuntenção…
E implementaria isso não tudo de uma vez, mas em pequenas entregas para começar a ver algum valor…(ou seja, um pensamento ágil maroto disfarçado uaheuahuaehu)

Thiago sem querer intrometer na forma que você trabalha, e sendo o advogado do diabo, é realmente necessário ter um plano para automatizar testes?

@Rafael-Chiavegatto hauauauauaua, tranquilo. Sem problemas. :grinning:

O plano é mais para termos argumentos com a diretoria para termos um tempo pra nos organizarmos e implantarmos o processo de automação. Hoje nosso tempo pra desenvolvimento e testes é bastante limitado. Com isso, precisaremos de tempo e investimento em material para treinarmos as equipes.

Fica meio que inviável metermos a mão na massa sem que haja um consenso das partes envolvidas. Por isso o desenvolvimento de um plano.

@Ramses-Saccol-de-Almeida De início estava pensando em repassar esses pontos com meu gestor (tirei esses pontos de um Webinar sobre automação de testes da Matera Systems):

  1. Definição das ferramentas de automação;
  2. Tempo de treinamento das ferramentas;
  3. Definição do ambiente de testes;
  4. Priorização do backlog de automação;
  5. Padronização da automação;
  6. Planejamento da automação;
  7. Acompanhamento da automação;
  8. Manutenção da automação.

Com isso, poderíamos ir pensando aos poucos (e até mesmo pegando alguns pontos) na parte de integração contínua (que infelizmente hoje não temos :( ).

Iniciaríamos por pequenas conquistas, para logo em seguida irmos galgando espaços maiores.

Então, eu sou muito contra ao item 5… Até por que no ramo tecnologico, quando tu chega em uma padronização, algo sempre muda e gera um custo rever esse processo.
item 3 faz mais sentido quando se sabe o que vai rolar em automação. Por ex: digamos que testes unitários serão a prioridade nesse primeiro passo. Logo se pode pensar em um ambiente ou se pode usar esse tempo para ver talvez um processo de CI que encaixe um ambiente para rodar…
Item 7 e 8 foi o que falei sobre guardar um tempo sobre pesquisa/avanço/manutenção. Eu prefiro não separar isso por que tu pode e não o que fazer manutenção, mas pode pesquisar sobre algo né?
Acho que a grande jogada, é mostrar o valor de se ter um processo. Se tu não conseguir mostrar o valor do que vai fazer, do que adiantar fazer?

Gerente adora ver o tempo de execução dos testes diminuindo, se você quer agradar alguem veja quais são as expectativas de ganho com automação dessa pessoa.
Eu particularmente gosto de automatizar o processo de teste, geração de relatórios, geração de massa eu gosto de falar 8 equipes levavam 1,5 horas por dia para fazer o relatório de execução para o cliente X agora eles apertão um botão e o relatório leva 3 minutos.
totalizando uma economia de 8 horas por dia 24 horas por mes e bla bla bla.

@bruwesley É justamente esse ponto que estou levantando em conjunto com a equipe. Levamos um bom tempo pra validar os relatórios, e de quebra, a cada nova validação, surgem novos erros. A automação viria a diminuir mais o “retrabalho” que estamos tendo, além das perdas $$$.

@Ramses-Saccol-de-Almeida: Em relação ao item 1, a questão de uma padronização de código seria mais no sentido de ter um padrão de projeto (como Page Objects, por exemplo).

Em relação ao item 3, já temos um ambiente de testes que será utilizado. A questão agora é a escolha de uma ferramenta para definirmos dentro do projeto qual será a estrutura das pastas.

O itens 7 e 8 permanece pro futuro, pois, isso dependerá bastante do comportamento da ferramenta escolhida.

Olha até hoje eu não vi a automação dar lucro ela não substitui o trabalho manual porem ela cria uma nova gama de areas e você ganha tempo, trabalhei com um lider que ele queria que cada wait fosse sincronizado com a aplicação por que ele alegava que se a gente rodasse mil vezes e perdesse mil segundos isso seria uma perda de performance hoje eu vejo a automação como um complemento de abrangência e não diminuição de custo em contrapartida um profissional automatizador é muito mais caro que um testador manual.

@bruwesley Vejo a automatização com ótimos olhos, sejam testes unitários, integração e aceitação(cada qual com seu objetivo), pois proporciona banefícios não só pra você QA, mas para o time de desenvolvimento, cliente e demais envolvidos.
O feedback é muito mais rápido para o time de desenvolvimento se a aplicação está tendo o comportamento que deveria ter ou não.
Reduz o risco de subir para produção com inconformidades (o que em algumas funcionalidades trás prejuízos financeiros, o que impediria a empresa de perder)
Aumenta a confiabilidade da entrega, tanto internamente, quanto para o cliente
O desenvolvimento e a entrega começa a ganhar mais velocidade, e a entrega das funcionalidades em produção é mais rápida e você entrega valor para o seu cliente final.

Respondendo o amigo @Thiago-Ferreira, esses itens elencados da Matera acho que te da uma boa diretriz, aos poucos, com o passar do tempo e somando com seu aprendizado tudo isso vai ficando automático na sua cabeça e você mesmo pode até ignorar alguns itens ou até incrementar outros de acordo com a sua experiência, processo de trabalho e cultura da empresa na qual trabalha.

@bruwesley said in Plano de Automação de Testes:

Olha até hoje eu não vi a automação dar lucro ela não substitui o trabalho manual porem ela cria uma nova gama de areas e você ganha tempo, trabalhei com um lider que ele queria que cada wait fosse sincronizado com a aplicação por que ele alegava que se a gente rodasse mil vezes e perdesse mil segundos isso seria uma perda de performance hoje eu vejo a automação como um complemento de abrangência e não diminuição de custo em contrapartida um profissional automatizador é muito mais caro que um testador manual.

Automação não gera lucro. Nunca gerou (a não ser que tu venda isso como serviço, dai talvez tu tenha um lucro…heheheh)
Mas ela ajuda a um time de desenvolvimento ter um retorno rápido a modificações ou implementações no processo de desenvolvimento (ou manutenção). Quanto menos tempo tu perde com um problema, mas tempo sobra para desenvolver/entregar algo. Isso se tu for ver é um tipo de ganho em termos financeiros.

Sobre profissional automatizador , na minha humilde e agressiva opinião, é a maior besteira que já ouvi/li/conheci na minha vida. Saber desenvolver um teste automatizado é uma skill, não cargo.
O “core” da profissão é auxilio a qualidade, e isso pode vir de várias maneiras.

@Thiago-Ferreira said in Plano de Automação de Testes:

@Ramses-Saccol-de-Almeida: Em relação ao item 1, a questão de uma padronização de código seria mais no sentido de ter um padrão de projeto (como Page Objects, por exemplo).

Em relação ao item 3, já temos um ambiente de testes que será utilizado. A questão agora é a escolha de uma ferramenta para definirmos dentro do projeto qual será a estrutura das pastas.

O itens 7 e 8 permanece pro futuro, pois, isso dependerá bastante do comportamento da ferramenta escolhida.

Item 1 até é bacana, mas é algo que se tu enfrentar algo novo, talvez não se ajuste ao projeto. O exemplo que tu deu é legal para ser encaixado como “boa prática”, mas eu não perderia muito tempo.
Item 3 já está definido. O que falou se refere mais ao item 5. (o qual eu ainda discordo muito fortemente…heheh)

@Ramses-Saccol-de-Almeida Em relação ao primeiro item, em um primeiro momento não é bom nos preocuparmos fortemente com um padrão de projeto. Mas daqui pra um tempo é bom.

@Ramses-Saccol-de-Almeida eu trabalhei como consultor por uns 5 anos e em empresas muito grandes, Santander, Oi, Vivo, Cielo, Vale e outras que eu ja passei a consultoria vende a automação como um meio de economia de $$$ mas eu nunca vi nenhum cliente economizar dinheiro com isso.
Eu vejo a automação como um complemento tipo eu ja fui em cliente onde um teste levava 3 dias para ser feito.

  • Preparar a Massa de dados.
  • Executar o teste
  • Analise dos dados
    Eu fiz uma automação que todo o processo era feito em 3 ~ 4 horas.
    Esse cliente contratava 3 pessoas para fazer os testes ele manteve os 3 analistas de testes porem o tempo deles foram usados para fazer outras atividades que não podiam ser feitas por causa do tempo que era empregado nessa atividade.

@Thiago-Ferreira Faça acontecer, depois faça acontecer da melhor maneira

@samuel.pereira Realmente é uma confiança maior mas como eu disse no outro post eu não vejo um ganho de $$$ diretamente entende.

@Thiago-Ferreira “O feito é melhor que o perfeito” faça uma poc mostre um MVP depois você enfeita a carroça.

@bruwesley said in Plano de Automação de Testes:

@Ramses-Saccol-de-Almeida eu trabalhei como consultor por uns 5 anos e em empresas muito grandes, Santander, Oi, Vivo, Cielo, Vale e outras que eu ja passei a consultoria vende a automação como um meio de economia de $$$ mas eu nunca vi nenhum cliente economizar dinheiro com isso.
Eu vejo a automação como um complemento tipo eu ja fui em cliente onde um teste levava 3 dias para ser feito.

  • Preparar a Massa de dados.
  • Executar o teste
  • Analise dos dados
    Eu fiz uma automação que todo o processo era feito em 3 ~ 4 horas.
    Esse cliente contratava 3 pessoas para fazer os testes ele manteve os 3 analistas de testes porem o tempo deles foram usados para fazer outras atividades que não podiam ser feitas por causa do tempo que era empregado nessa atividade.

OK, eu já trabalhei com os mesmos clientes, e dificilmente eles vão ter algum lucro. Isso é devido ao modo de como elas trabalham. Isso é uma outra discussão. Tem mais política de interesse nesse clientes do que em outras empresas.
O exemplo que tu deu tem muito indício de ser isso. Mas, como falei, papo para outro tópico, pq é mais cultural do que funcional.
Eu prego automação por saber que ele tem valor quando se é empregado. Note que eu não prego exclusivamente para testadores. Eu prego para equipe/time use o que ajudar a reduzir tempo. Se a tecnologia atacada não tem tanto suporte para algo assim, claro que “inventar a roda” gera um custo enorme.

Eu participei de projetos que deram lucro com automação. Cada um com a sua experiencia e a comunidade para a gente compartilhar…
¯_(ツ)_/¯

Log in to reply

Looks like your connection to Agile Testers was lost, please wait while we try to reconnect.