Palestra Teste de Software: princípios, ferramentas e carreira
Denunciar
Compartir
•5 recomendaciones•2,158 vistas
Palestra Teste de Software: princípios, ferramentas e carreira
•5 recomendaciones•2,158 vistas
Denunciar
Compartir
Descargar para leer sin conexión
A palestra inicialmente abordará os princípios do Teste de Software como o que é teste de software, níveis de teste, tipos de teste, como testar um software, gestão de testes, gestão de defeitos, certificações entre outros. Durante a palestra serão mostradas as principais ferramentas que auxiliam os testadores e qual a funcionalidade de cada uma. E por fim será discutido sobre a carreira e os papéis em relação ao mercado atual.
Más contenido relacionado
La actualidad más candente
La actualidad más candente(20)
Destacado
Destacado(20)
Similar a Palestra Teste de Software: princípios, ferramentas e carreira
Similar a Palestra Teste de Software: princípios, ferramentas e carreira(20)
![[GUTS-RS] GUTS Universitário - Carreira de Testes](https://cdn.slidesharecdn.com/ss_thumbnails/guts-rsuniversitrio2016carreiratestes-161101203011-thumbnail.jpg?width=768&fit=bounds)
Palestra Teste de Software: princípios, ferramentas e carreira
- 1. Teste de Software: princípios, ferramentas e carreira
- 2. • Formação acadêmica - Graduada em Engenharia da Computação - Pós-graduanda em Gerenciamento de Projetos • Experiência Profissional - Analista de Teste no Grupo Assessor Taís Dall’Oca
- 3. Agenda • Por que testar? • O que é Teste de Software • Processo de Teste • Níveis de Teste • Tipos de Teste • Ferramentas • Carreira
- 4. Os testes estão no nosso dia a dia
- 5. O que testar em um celular?
- 6. Mas por que testar? Somente o processo de desenvolvimento não garantirá que o produto esteja livre de defeitos; Os testes indicam a presença de defeitos no produto; Gastos com retrabalho; Maior tempo gasto devido à manutenção do produto; Insatisfação dos clientes; Imagem negativa da organização para presentes ou futuros clientes;
- 7. Os usuários querem USAR o produto e não ENTENDÊ-LO!
- 8. Motivação Bug faz usuários descobrirem se são populares no Facebook. Fonte: Olhar Digital
- 9. Motivação Falha no site da American Airlines permite passagens de graça para o Brasil. Fonte: Fábrica de Testes
- 10. Motivação Galaxy S6 Edge tem falhas de segurança, inclusive no E-mail; Google alerta. Fonte: Techtudo
- 11. Erro, defeito ou falha? • O ser humano está sujeito a cometer um erro (engano) Erro • Que produz um defeito (bug) no código ou documento Defeito • Se um defeito no código for executado, o sistema irá falhar Falha
- 12. A importância...
- 13. Ou seja,
- 14. FUNCIONALIDADE –> SATISFAÇÃO DAS NECESSIDADES EFICIÊNCIA –> RÁPIDO E ‘ENXUTO’ MANUTENIBILIDADE –> FACILIDADE DE MANUTENÇÃO CONFIABILIDADE –> IMUNIDADE A FALHAS USABILIDADE –> FACILIDADE DE USO PORTABILIDADE –> USO EM OUTROS AMBIENTES Dimensões da Qualidade
- 15. Teste de Software Testar é o processo de executar um programa ou sistema com a intenção de encontrar defeitos (teste negativo) (Myers, 1979) Testar é qualquer atividade que, a partir da avaliação de um atributo ou capacidade, permita determinar se o programa ou sistema obtém resultados desejados (Hetzel, 1988)
- 16. Teste de Software Testes podem possuir objetivos diferentes: • Encontrar defeitos. • Ganhar confiança sobre o nível de qualidade. • Prover informações para tomada de decisão. • Prevenir defeitos. (Syllabus, 2011) Testar é verificar se o software está fazendo o que deveria fazer, de acordo com seus requisitos, e se não está fazendo o que não deveria fazer. (Rios, Cristalli, Moreira e Souza, 2003)
- 17. #1: Equipe de Testes X Desenvolvimento e Analistas A equipe de testes não é inimiga da equipe de desenvolvimento e nem dos analistas de requisitos. Alguns "pré-conceitos" e algumas dicas sobre testes de software #2: Pessoas menos qualificadas A equipe de testes não pode ser composta por pessoas menos qualificadas ou servir como um trabalho temporário. Teste de Software
- 18. Alguns "pré-conceitos" e algumas dicas sobre testes de software Teste de Software #3: No final do desenvolvimento Os testes não devem ser iniciados no final do desenvolvimento. #4: Não há mais nenhum defeito Não é o objetivo da equipe de testes garantir que o sistema não tenha mais nenhum defeito.
- 19. #5: Não somos programadores Os membros da equipe de testes não são programadores, portanto a equipe de desenvolvimento deve tentar nos explicar da melhor forma o que está acontecendo no sistema. Nos ajudem. :) #6: Comunicação entre as equipes é TUDO! Surgiu uma dúvida? Pergunte, esclareça, não deixe para depois. Isso serve para todas as equipes! Alguns "pré-conceitos" e algumas dicas sobre testes de software Teste de Software
- 20. Teste de Software As características de bons testadores: • Aprendizado contínuo; • Capacidade analítica (ler nas entrelinhas, ter opinião crítica e analítica sobre o assunto); • Boa comunicação (verbal e escrita); • Criativo; • Perfeccionista; • Observador; • Detalhista;
- 21. Processo de Teste Requisitos Implementação Design Verificação e Validação Operação e Manutenção Modelo em cascata (modelo antigo) Teste era custo!
- 22. Processo de Teste Teste é investimento! Desenvolvimento Testes
- 23. Verificação Validação Estamos desenvolvendo o produto corretamente? Estamos desenvolvendo o produto correto?
- 24. Estratégias Tipos de Teste (o que testar) Técnicas de Teste (como testar) Níveis de Teste (quando testar)
- 25. Níveis de Teste UNIDADE INTEGRAÇÃO SISTEMA ACEITAÇÃO Testes unitários. Explorar a menor unidade do projeto. Falhas associadas às interfaces entre os módulos. Verificar se o produto satisfaz seus requisitos. Realizado por grupo de usuários. Verificar se o produto está de acordo com o solicitado.
- 26. Técnicas de Teste ESTRUTURAL FUNCIONAL Garantir que os softwares sejam estruturalmente sólidos e funcionem no contexto técnico onde serão instalados. Garantir o atendimento aos requisitos, ou seja, que os requisitos foram corretamente codificados.
- 27. Tipos de Teste CARGA (STRESS) RECUPERAÇÃO SEGURANÇA CONFORMIDADE OPERAÇÃO EXECUÇÃO REGRESSÃOREQUISITOS SUPORTE MANUAL TRATAMENTO DE ERROS INTEGRAÇÃO CONTROLE PARALELOS EXPLORATÓRIO
- 28. O “Quadrante Mágico” do Teste Ágil Criado por Brian Marick que sugeriu uma série de técnicas de testes para diferentes categorias.
- 29. Artefatos Planos de teste Casos de teste Projetos de teste Roteiros de teste Checklists Relatórios Cenários de teste Incidentes Scripts automatizados
- 30. Categorização das ferramentas: 1. Ferramentas de automação de testes de regressão; 2. Ferramentas para gestão de defeitos; 3. Ferramentas para testes de Performance/Stress; 4. Ferramentas manuais; 5. Ferramentas de rastreabilidade; 6. Ferramentas de cobertura de código; 7. Ferramentas para gestão de testes; 8. Ferramentas de apoio à execução dos testes; Ferramentas
- 31. Ferramentas no ciclo de vida dos testes DEFINIÇÃO DOS REQUISITOS TESTEIMPLEMENTAÇÃOPROJETO IMPLANTAÇÃO Ferramentas de apoio Automação de testes Gestão de defeitos Gestão de testes Gestão de projetos Controle de versões
- 32. Ferramentas Atualmente, existem muitas ferramentas open source e gratuitas. Testes de performance •JMeter •OpenSTA Gestão de defeitos •Mantis •Bugzilla Testes funcionais •Selenium (WEB) •Watir (WEB) •SoapUI Gestão de testes •TestLink •TestMaster •Testitool Gestão de projetos •phpCollab •ProjectKoach Gestão de requisitos •OSRMT •Plandora
- 33. Ferramentas O TestComplete é uma solução completa para a automação de testes funcionais de aplicações desktop, mobile e aplicações Web para a plataforma Windows. Algumas vantagens: Os testes não consomem muito tempo. Os testes repetitivos podem ser executados com maior facilidade. Testes em vários ambientes, navegadores, entre outros. Testes funcionais, de desempenho, estresse, segurança e muitos outros podem ser realizados. Algumas desvantagens: Custo alto. Exige conhecimento em programação. Testes de usabilidade não serão possíveis.
- 34. Carreira Gerente de Teste Analista de Teste Líder de Teste Analista de Automação de Teste Arquiteto de Teste Tester
- 35. Certificações ALATS (Associação Latino Americana de Teste de Software) CBTS: Certificação Brasileira em Teste de Software ISTQB (International Software Testing Qualification Board) CTFL : Certified Tester, Foundation Level CTAL-TA: Advanced Level Test Analyst CTAL-TM: Advanced Level Test Manager CTAL-TTA: Advanced Level Technical Test Analyst QAI (Quality Assurance Institute) CAST : Certified Associate in Software Testing CSTE : Certified Software Tester CSQA : Certified Software Quality Analyst CSPM : Certified Software Project Manager
- 36. Certificações Quais são as vantagens? • Melhoria do prestígio e da imagem; • Aumento da competitividade e entrada em novos mercados; • Aumento da confiança dos trabalhadores, clientes e administração; • Redução de custos; • Melhoria das técnicas, conhecimentos e produtividade; • Mercados internacionais ou específicos;
- 37. Existem outros caminhos... Livros Lisa Crispin e Janet Gregory Emerson Rios Anderson Bastos Ricardo Cristalli Trayahú Moreira Alexandre Bartié
- 39. Existem outros caminhos... Blogs Crowdtest -> crowdtest.me/blog Qualister -> www.qualister.com.br/blog Elias Nogueira -> eliasnogueira.com/blog Qualidade de Software -> qualidade-de- software.blogspot.com.br
- 41. Pra descontrair!
- 42. OBRIGADA!
Notas del editor
- Os testes estão no nosso dia a dia. Seja no momento de preparar nossa comida, experimentando sabores, temperaturas.. Nas montadoras de automóveis, onde eles testam os carros antes das vendas. Exames em laboratórios. Uma mãe cuidando de seu filho, onde ela testa a temperatura da água para não machucar seu bebe. Nós estamos rodeados de testes. Quando nós compramos um celular, um tablete, o que fazemos? Testamos suas funcionalidades e tudo mais que ele nos oferece.
- Rápido. Camera boa; Faz ligações? Recebe ligações? A internet funciona? O sistema é fácil de mexer? O carregador está funcionando? Gosto de música, os fones estão funcionando?
- Eles não querem saber como tal funcionalidade funciona.. Como aquilo foi feito.. Por que tal aplicativo tem essa cor? Eles querem usar o produto, aproveitar o máximo possível o que ele oferece. Descobrir todas suas funcionalidades e satisfazer suas necessidades.
- Dia 14 de Outubro, um bug permitiu que usuários do Facebook descobrissem quão populares (ou impopulares) eles são na rede social. O erro mostrava a contagem de visualizações de posts, algo que geralmente só administradores de páginas conseguem ver. O bug afetava apenas o site móvel do Facebook; a página para desktops e os aplicativos permaneceram normais. Ele mostrava quantas pessoas viram links e, em alguns casos, imagens compartilhadas pela rede. O Facebook confirmou o problema ao Verge e disse que estava trabalhando para consertá-lo. Embora pareça inofensivo, o bug toca num ponto delicado na rede social, já que uma das coisas que mantém usuários motivados a fazer publicações por lá é essa aura de mistério em torno da quantidade de pessoas que serão impactadas.
- Empresa ainda não informou se bilhetes adquiridos através de seu site no Chile serão respeitados; não é primeira vez que companhia enfrenta este problema. Um erro na página na internet da companhia American Airlines no Chile permitiu a compra de passagens com destinos a Brasil, Estados Unidos e Europa de graça, segundo clientes. Durante o fim de semana, ao entrar na página da empresa, visitantes encontraram passagens geralmente caras vendidas a US$ 0. A situação teria sido causada por uma falha técnica, e não por uma campanha de marketing, e o site da companhia seguia fora do ar na manhã de segunda-feira. A situação foi compartilhada por clientes nas redes sociais. A jornalista chilena Macarena Carrasco comprou seu bilhete na noite do domingo - mas as passagens estavam disponíveis a preços mais baratos desde a tarde. Ela comprou bilhetes para Londres, mas disse que muitos outros usuários adquiriram passagens para a Grécia pelo mesmo preço. Ela disse estar "cruzando os dedos para que a American Airlines respeite às passagens" compradas a esse preço. E, apesar de não haver confirmação de que as compras serão honradas, Carrasco disse poder ver o número de reserva e todo o itinerário de sua viagem. Não é a primeira vez que a empresa sofre um episódio como este. Em 20 de agosto, vários usuários disseram nas redes sociais que haviam comprado passagens do Chile a Nova York ou Miami por US$ 70. A companhia admitiu o erro.
- O Galaxy S6 Edge possui 11 falhas de segurança do tipo zero day, de acordo com especialistas do Project Zero, do Google. Esse tipo de falha é considerada grave porque dá margem para invasores explorarem brechas que podem comprometer a segurança dos dados do usuário, bem como a sua privacidade. A Samsung foi notificada e já promoveu a correção de parte dos problemas. Um dos exemplos de problemas é uma brecha que pode ser explorada no aplicativo Samsung Email. Invasores podem usar um malware que toma controle do app e o utiliza para encaminhar mensagens de e-mail recebidas pelo usuário. Dessa forma, um criminoso teria acesso a todo o tráfego de e-mails da vítima. Outro erro grave permite que o recurso do Android para descompactar arquivos, modificado pela Samsung, descompacte dados de aplicativos perigosos em pastas ocultas, ou que não poderiam ser acessadas pelo usuário e apps. Dessa forma, as pragas podem se esconder de forma mais eficiente dentro do sistema operacional. Outras falhas encontradas mostram que é possível criar aplicativos que sobrecarreguem a memória RAM do smartphone, causando corrupção de dados. Esse tipo de procedimento pode criar vírus que travem o sistema operacional, ou ser usado para criar aplicativos maliciosos que se aproveitam do episódio para assumir privilégios de administrador. O Project Zero é uma iniciativa do Google para encontrar falhas de segurança em produtos e serviços. A ideia é que os especialistas usem as informações coletadas para alertar fabricantes e desenvolvedores sobre os problemas. No caso da Samsung, a maior parte das 11 falhas já foram corrigidas e espera-se que atualizações para as três brechas restantes sejam liberadas em breve. Em resposta ao TechTudo, a Samsung informou que o programa mensal Samsung Security Update apresentou, em outubro, soluções para oito questões trazidas pelo Google. “As demais questões serão inclusas como parte da atualização de segurança do mês de novembro, que estará disponível nas próximas semanas. A Samsung recomenda que os usuários sempre mantenham seus softwares e aplicativos atualizados”, disse a empresa em nota.
- Mas afinal, isso tudo que vimos são erros, defeitos ou falhas?
- O custo de correção de defeitos tende a aumentar quanto mais tarde o defeito é detectado. Defeitos encontrados durante a produção tendem a custar muito mais que defeitos encontrados em modelos de dados e em outros documentos do projeto do software. * testes unitários podem remover entre 30% e 50% dos defeitos dos programas; * testes de sistemas podem remover entre 30% e 50% dos defeitos remanescentes; * os sistemas podem ir para produção com aproximadamente 49% de defeitos; * as revisões de código podem reduzir entre 20% e 30% desses defeitos Fonte: Theartofsoftware testing–1979 –GlenfordMyers
- Funcionalidade O conjunto de funções satisfaz as necessidades explícitas e implícitas para a finalidade a que se destina o produto? Eficiência Os recursos e os tempos utilizados são compatíveis com o nível de desempenho requerido para o produto? Confiabilidade O desempenho se mantém ao longo do tempo e em condições estabelecidas? Usabilidade É fácil usar o software? Portabilidade É possível utilizar o produto em diversas plataformas com pequeno esforço de adaptação? Manutenibilidade Há facilidade para correções, atualizações e alterações?
- Verificação: O propósito da verificação é demonstrar que o produto ou seus produtos de trabalho atendem aos seus requisitos específicos. Validação: O objetivo da validação é demonstrar que um componente do produto cumpre o seu uso pretendido quando colocado em seu ambiente pretendido.
- Tipos: baseado nos inúmeros tipos de teste existentes, definir os que serão aplicados; Técnicas: estruturais e/ou funcionais Estágios: Unidade >> Integração >> Sistema >> Aceitação
- Teste de Unidade: também conhecido como testes unitários. Tem por objetivo explorar a menor unidade do projeto, procurando provocar falhas ocasionadas por defeitos de lógica e de implementação em cada módulo, separadamente. O universo alvo desse tipo de teste são os métodos dos objetos ou mesmo pequenos trechos de código. Teste de Integração: visa provocar falhas associadas às interfaces entre os módulos quando esses são integrados para construir a estrutura do software que foi estabelecida na fase de projeto. Teste de Sistema: avalia o software em busca de falhas por meio da utilização do mesmo, como se fosse um usuário final. Dessa maneira, os testes são executados nos mesmos ambientes, com as mesmas condições e com os mesmos dados de entrada que um usuário utilizaria no seu dia-a-dia de manipulação do software. Verifica se o produto satisfaz seus requisitos. Teste de Aceitação: são realizados geralmente por um restrito grupo de usuários finais do sistema. Esses simulam operações de rotina do sistema de modo a verificar se seu comportamento está de acordo com o solicitado.
- ESTRESSE: determinar o desempenho do sistema com volumes esperados (Ex.: espaço suficiente alocado em disco; comunicação de rede adequada) EXECUÇÃO: determinar se o sistema funciona com proficiência (Ex.: transações rodando em tempos adequados; hardware e software otimizados) CONTINGÊNCIA / RECUPERAÇÃO: determinar se o sistema retorna a um status operacional depois de uma falha (Ex.: indução de um erro; avaliação da adequação de um backup de dados) OPERAÇÃO: determinar se o sistema pode ser executado em status operacional normal (Ex.: manual e treinamento dos usuários; procedimentos de gerenciamento de configuração) CONFORMIDADE: determinar se o sistema foi desenvolvido em concordância com os padrões e procedimentos (Ex.: padrões seguidos; documentação completa) SEGURANÇA: determinar se o sistema está protegido segundo os padrões de segurança da empresa (Ex.: acesso negado; procedimentos locais) REQUISITOS: determinar se o sistema é executado conforme o especificado (Ex.: especificado x implementado; regulamentos e políticas) REGRESSÃO: verificar se alguma coisa mudou em relação ao que já estava funcionando corretamente (Ex.: mudança de seguimentos funcionais do sistema; mudança manual de procedimentos corretos) TRATAMENTO DE ERROS: prevenir ou detectar erros para depois consertá-los (Ex.: falha introduzida; erro reincidente) SUPORTE MANUAL: preparar os dados para processamento e usar os dados fornecidos pelo sistema (Ex.: informação de input; tomada de decisões baseadas nas informações dos relatórios) INTEGRAÇÃO: assegurar que a interconexão entre as aplicações funciona corretamente (Ex.: cenário de teste de integração) CONTROLE: analisar o aplicativo com um olhar negativo e assegurar que aquilo que poderia sair errado foi adequadamente protegido (Ex.: seleção das transações e verificação da possibilidade de reconstrução) PARALELO: comparar resultados do aplicativo atual com a versão anterior (Ex.: comparação dos resultados obtidos com as versões nova e antiga para garantir a equivalência)
- É importante salientar que o quadrante é um guia, e não um processo! TESTES QUE SUPORTAM O TIME São os testes que suportam o time e ajudam os desenvolvedores, não somente os testadores, enquanto o produto é desenvolvido. Estes testes são mais voltados a qualidade e entendimento dos requisitos e arquitetura do que em testes como conhecemos de forma funcional. Quadrante 1 Representa, basicamente, a principal prática de desenvolvimento ágil: TDD – Test Driven Development. Dentro deste quadrante temos duas práticas: teste de unidade, que valida uma pequena parte da aplicação como objetos e/ou métodos, e testes de componente que valida partes maiores da aplicação como um grupo de classes que provê o mesmo serviço. Validam a qualidade interna do código fonte. Ao utilizar a técnica de TDD o programador pode desenvolver uma funcionalidade sem se preocupar em posteriormente alterar qualquer parte da aplicação, ajudando assim a tomar melhor decisões de arquitetura e design. Não são destinados ao cliente, pois o cliente não irá entender os aspectos internos do desenvolvimento e não devem ser negociáveis com o cliente, pois a qualidade do código deve sempre existir e não ser negligenciada. Os testes desenvolvidos usualmente executados dentro de uma abordagem de Integração Contínua para prover um rápido feedback da qualidade do código. Quadrante 2 Este quadrante também suporta o time de desenvolvimento, continua guiando o desenvolvimento, mas de uma maneira mais alto-nível focando mais em testes que o cliente entenda, onde este define a qualidade externa de que ele precisa/deseja. Aqui o cliente define exemplos que serão usados para um entendimento maior do funcionamento da aplicação, e são escritos de forma com que o cliente ou papéis ligados a negócio entendam. Todo o teste executado aqui tem um foco no funcionamento do produto e alguns deles podem até mesmo ter uma pequena duplicação com alguns testes criados no Quadrante 1. Testes focados no negócio também podem ser automatizados e, usualmente, a técnica de BDD – Behavior Driven Development é utilizada na escrita e execução automatizada destes exemplos de cenários. Neste quadrante também podemos utilizar de pessoas com conhecimentos em UX (User Experience) para que, através de mockups e wireframes, o cliente possa validar a interface gráfica antes que o time comece a desenvolver esta camada. TESTES QUE CRITICAM O PRODUTO O termo “criticam” aqui não é apenas de forma destrutiva, mas também relacionados a melhoria. O foco é saber como iremos aprender a melhorar o produto, escrevendo, se necessário, mais critérios de aceite e exemplos. Quadrante 3 As vezes mesmo criando diversos mecanismos para assegurar que estamos atendendo a necessidade do cliente através de critérios e/ou exemplos, pode acontecer de não atendermos realmente aquele desejo, ou mesmo o teste unitário e o teste através do BDD podem não ter um valor real. Neste quadrante iremos realmente criticar o produto e executa-lo como um usuário real usando nosso conhecimento e intuição na utilização da aplicação. O cliente pode executar este tipo de tarefa, usualmente chamada de UAT – User Acceptance Testing, dando um feedback mais preciso, aceitando a funcionalidade, analisando possíveis novas funcionalidades. Esta ação pode ser também um dos critérios de DoD – Definition of Done de uma funcionalidade. O ponto central deste quadrante, além do UAT, são os testes exploratórios. Utilizando esta técnica qualquer membro do time é capaz de, simultaneamente, explorar a aplicação e executar mais testes, usando o feedback do último teste para a execução dos próximos e também é capaz de extrair novos critérios, sempre observando o comportamento da aplicação. Quadrante 4 Os testes neste quadrante são os mais técnicos e criticam o produto em termos de performance, carga e segurança. Nos dias de hoje negligenciar aspectos como performance podem tirar a vantagem competitiva de um cliente/negócio. Geralmente já conhecemos aspectos relacionados a performance e segurança quando refinamos algumas User Stories. As técnicas aplicadas a performance, carga e segurança vão desde os níveis mais baixos (como uma inspeção de código) como a utilização de ferramentas que simulam diversos usuários simultaneamente ou transações por segundos. O quadrante visa apoiar os times de testes ágeis como um guia. É fundamental o entendimento do time e principalmente a capacidade técnica de “perceber” quais técnicas e práticas serão adotadas durante o desenvolvimento/testes da aplicação, sempre buscando agregar valor a aplicação/entrega, e principalmente atender a expectativa do cliente.
- Testador: executa os casos de testes manuais do sistema. Sabe seguir a direção desses casos de testes. Tem uma visão crítica do sistema como um todo. Reporta os bugs de forma clara com evidências. Entra em contato com o time de desenvolvimento para esclarecer dúvidas deles se necessário. Analista de Teste: cria os casos de testes a partir de requisitos. Cria documentos com cenários, condições e passos de testes. Lê documentos funcionais do sistema e traduz esses requisitos para testes dentro do sistema. Participa de reuniões com o cliente para entender a necessidade de negócio do sistema. Se envolvido no ciclo de desenvolvimento do software pode apontar possíveis "bugs" antes mesmo do desenvolvimento. Analista de Automação (Automatizador): lê, entende e interpreta os casos de testes manuais que são repetitivos (ou não) e transforma os passos de testes em scripts automatizados. O automatizador é quem cria, atualiza e mantém esses scripts. Engenheiro/Arquiteto de Teste: planeja e mantém o ambiente de testes. Define a arquitetura do ambiente de testes e quão parecido ele será com o ambiente de produção. Prepara e mantém a massa de dados que será utilizada nos testes. Líder e Coordenador de Testes: planeja o número de ciclos de testes necessário para cobrir as partes críticas do sistema. Decide quais as prioridades dos testes que serão executados. Faz o meio de campo entre o time de desenvolvimento e de testes caso aja algum problema de comunicação entre eles. Cria relatórios e faz análise de bugs em aberto e a prioridade para re-testar esses bugs. Gerente de Testes: entende em um nível macro qual é o andamento dos testes. Elabora propostas para novos projetos de teste de software. Seleciona os colaboradores que farão parte da equipe de testes. Prove treinamento sempre que necessário para a equipe. Consultor de Teste: especialista na área, que partilha experiências e conhecimentos em consultorias à empresas que desejam implantar e/ou aprimorar a área.