Formando equipes de alto desempenho, parte 1: Início e fases de evolução
Nesta primeira parte de uma série sobre equipes de alto desempenho e gerenciamento Agile, veja uma introdução geral e uma apresentação dos estágios de formação das equipes.
Notícias
O conteúdo foi adicionado aos favoritos!
Houve um erro ao adicionar aos favoritos! Por favor, tente novamente.
Categorizando Testes
Postado por Amr Elssamadisy , traduzido por Rodrigo Piovezan em 18 Ago 2009
Em uma discussão recente no Yahoo! Grupo de test driven development Carlos Ble compartilhou seu entendimento de categorias de testes decorrente de sua pesquisa:
Acabei tendo a seguinte imagem:
Testes do desenvolvedor:
Testes unitários : Isolados, atômicos, inócuos: exercitados com xUnit
Testes de integração:
Testes isolados que podem mudar o estado do sistema, por exemplo: salvar em banco, escrever em arquivo... Um teste de integração não representa por si um requisito funcional. Podem ser escritos para xUnit. Eles verificam a integração do nosso código com uma ferramenta de terceiros ou com diferentes camadas de nosso próprio código, por exemplo: a camada de lógica de negócio requer a camada de acesso a dados
Testes funcionais: (também conhecidos como Testes de Sistema)
Um teste que exercita uma parte completa do sistema, algum requisito funcional. Ele pode mudar o status do sistema.
Testes do Product Owner:
Testes de aceitação: Testes funcionais cuja entrada e saída podem ser validadas por uma pessoa não-técnica, o product owner.
John Donaldson forneceu um modelo multidimensional para testes que foca em papéis de teste e tipos de teste:
Eu gosto da visão de testes que você propõe. Mas acho que é uma instância de um modelo maior, onde você tem (pelo menos) papéis de atuação e tipos de teste.
Papéis de atuação: desenvolvedor, testador, QA, usuário, sponsor, etc.
Tipos de teste: unitários, de integração, funcionais, sistêmicos, de aceitação, de carga prolongados (soak), preliminares (smoke), etc.
Em qualquer situação dada você provavelmente sabe qual papel se encarrega de qual teste - mas no próximo projeto isso pode ser diferente.
Dale Emery sugeriu que não saber qual tipo de teste você está escrevendo é um sintoma de código ruim e indica falta de clareza. Um teste pode cair em diversas categorias ao mesmo tempo e o que importa é o seu ponto de vista atual:
O desafio, penso eu, é que qualquer teste pode ser classificado razoavelmente de várias formas diferentes, dependendo de quais dimensões você está focando. E existem diversas dimensões que as pessoas usam para classificar testes. Eu identifiquei algumas aqui: http://cwd.dhemery.com/2004/04/dimensions/
Por isso estou menos interessado em saber "qual tipo" de teste é, e mais interessado em saber onde um teste se encaixa nas dimensões que são mais importantes para mim, dependendo do meu objetivo em determinado momento. Aquelas em que penso com mais frequência são:
- Qual "unidade" esse teste define e valida? (Qual sistema, subsistema, objeto, colaboração...) - Qual funcionalidade o teste define e valida?
- Quem está primariamente envolvido com esse teste? Quem se preocupa mais com os resultados da execução desse teste?
- Quais decisões serão tomadas a partir dos resultados da execução desse teste?
Charlie Poole fornece uma análise detalhada da categorização de Carlos e sugere:
Na minha opinião, a distinção mais importante é entre os testes de objetivos do desenvolvedor e os testes de objetivos do cliente.
Essa discussão evidencia o fato de que classificar testes pode ser bastante confuso - especialmente para o iniciante. O consenso é que a forma mais indicada para classificar testes é uma abordagem dimensional e que o tipo de classificação que é relevante depende dos objetivos do usuário naquele momento e do contexto.
Utilizar os padrões existentes
por
Elias Nogueira
Enviado
Re: Utilizar os padrões existentes
por
Felipe Rodrigues
Enviado
Re: Utilizar os padrões existentes
por
Elias Nogueira
Enviado
Re: Utilizar os padrões existentes
por
Felipe Rodrigues
Enviado
Re: Utilizar os padrões existentes
por
Elias Nogueira
Enviado
Re: Utilizar os padrões existentes
por
Felipe Rodrigues
Enviado
-
Várias literaturas já possuem um padrão para os tipos de teste e dimensões de teste.
O que vejo são pessoas falando mais sobre qualidade mas não olhando o que já existe e que está em utilização por diversos profissionais. -
Por outro lado, diversas literaturas são incoerentes na nomemclatura dos testes. Frequentemente teste funcionais são interpretados como testes de interface de usuário. Isso é um erro, como constata a descrição do teste funcional. Em outros casos, o teste de integração é considerado o teste de interface.
Resumindo, pelo que eu tenho visto por aí, os conceitos estão bem bagunçados. -
Tu tens razão Rodrigo!
Mas isso acontece muito aqui no Brasil.
Com os autores de fora isso dificilmente acontece. -
Rodrigo? Quem é esse? =)
Bom, isso acontece muito com autores de fora também. Pegue por exemplo a comunidade de Rails e Grails. Cada uma tem um conceito diferente de teste funcional e teste de integração. Isso fica claro para aqueles que leram "Agile Web Development with Rails" e "Grails - The definitive Guide". Fora outros casos. Tanto acontece que os caras da lista citada na notícia estão discutindo isso. =)
Abração,
Felipe -
Desculpa Felipe... rsrsrssrsrs
Se tu ir nessa linha da Agile eu vou concordar sim!
O pessoal de Agile costuma confundir muito as questões de teste. Toda a vez que eu encontro um agialista que fala sobre estes conceitos eu mando ler alguns livros de teste escritos pelos profissionais da área.
O foco do teste pode ser difetente, mas as nomenclaturas e técnicas utlizadas não.
E o pessoal ainda costuma tirar conlusões proprias ao inves de consultar a literatura existente, tipo Mayers, Karner, Elfried, Bret, James Bach, etc..
Abraço! -
Agora chegamos num acordo! Os agilistas é que costumam confundir essas coisas mesmo.
Mas como eu disse acima, acho que essa confusão fica só por conta da nomemclatura.
6 comentários
Acompanhar Discussão Responder