Trilha Testes 2016

De MSTECH wiki
Revisão de 13h14min de 11 de julho de 2016 por Andre.iguera (Discussão | contribs)

Ir para: navegação, pesquisa

A trilha de Testes I do TDC 2016 foi dividida entre palestras técnicas e não técnicas. As palestras técnicas tratavam de assuntos relacionados a implementação de testes unitários, melhoria de performance nas suites de testes, ferramentas de auxílio nos testes. As palestras não técnicas eram básicas em sua maioria, onde palestrantes com pouco tempo na área de testes contaram suas experiências.

Eu não garanto a qualidade.

Palestrante: Diego Blond

Conteúdo simplificado para iniciantes. A qualidade é responsabilidade da equipe, não só do testador.

  • Abrir bugs não garante a qualidade. E se ninguém corrigir?
  • Não ter bugs não garante a qualidade.
  • Relatórios não garantem a qualidade.
  • Discussões não garantem a qualidade.
  • Planos de teste não garantem a qualidade. Gastam muito tempo e as pessoas acabam não seguindo os planos de teste. Tudo pode se perder caso o plano de testes seja construído com base num documento falho.
  • Hora extra não garante qualidade pois não quer dizer que o funcionário está efetivamente produzindo mais.
  • Desistir não garante qualidade.
  • Equipe maior não garante qualidade. Equipe menor também não.
  • Focar na qualidade não garante qualidade. De que adianta construir um sistema perfeito se ele não é entregue no prazo?
  • Entregas com pressão não garantem qualidade.
  • Entregas sem pressão também não garantem qualidade.
  • Testes automatizados não garantem qualidade. Levam tempo para serem construídos. Esse tipo de teste nunca vai entender o usuário da mesma forma que você.
  • Ser um bom QA não garante qualidade. A equipe garante! Equipe informada conhece o usuário e faz questionamentos. É importante saber se comunicar com o cliente e fazer sugestões. É importante sair da zona de conforto. Bom senso: Saber onde aplicar cada esforço. É importante ter bom senso em tudo.

Tudo isso junto garante a qualidade.

Dicas do palestrante:

  • Fazer workshops com os clientes. Ninguém entende melhor das regras do sistema do que o próprio cliente.
  • Seja o exemplo da equipe. Mostre que é possível aplicar melhores práticas.

Testes exploratórios não são sinônimos de bagunça!

Nos testes exploratórios o testador aprende, faz o design e executa o teste ao mesmo tempo, evoluindo à medida em que executa os testes. Ser ágil não é fazer de qualquer jeito. Cadastrar um bug não é apenas mandar um print para o desenvolvimento.

O palestrante apresentou o plug-in da Microsoft chamado Exploratory Testing para Google Chrome (disponível em http://aka.ms/xtinstall).

  • Integração com o TFS ou roda sem conexão;
  • Grava os cliques do usuário durante a execução dos testes;
  • Permite abrir os prints para edição;
  • No modo standalone, gera um relatório após a execução dos testes;
  • Integrado ao TFS, permite o cadastro de bugs diretamente no servidor.