WorkFlows com diferentes abordagens do processo de teste de software com a utilização do SCRUM

O tema da 25ª Mesa Redonda DFTestes foi “WorkFlows com diferentes abordagens do processo de teste de software com a utilização do SCRUM”. A discussão teve 5 respostas e 4 participantes, sendo eles: eu, Sarah Pimentel, Ricardo Henrique e Humberto Barboza.

A discussão acabou não sendo tão movimentada como de costume, acredito que por já ter tido uma mesa redonda relacionada ao Scrum antes. Mas mesmo assim, acredito que o conteúdo da mesma pode ser útil, principalmente para aqueles que estão usando o Scrum.

Abaixo, segue o resumo da discussão, quem quiser conferí-la na íntegra é só acessar esse link (necessário ser inscrito no DFTestes).

Quais mudanças ocorrem no workflow quando utilizamos o Scrum?

Na minha opinião, o Scrum sendo um processo iterativo e incremental, acaba forçando o seu workflow a ser baseado em iterações e trabalhando de forma incremental também.

Se você já usa alguma metodologia incremental (ex.: XP), não haverá grandes mudanças.

O Humberto Barboza complementou dizendo:

Concordo quando o Fabrício diz que a mudança maior é na iteratividade. Ressalto ainda:  Como são “tiros curtos” precisamos planejar com eficiência, avaliar os riscos sob o olhar criterioso, priorizar as tarefas / estórias. Sem o devido planejamento, participação nas reuniões é impossível cumprir os prazos estabelecidos porque manter a documentação (Casos de Teste, Roteiros, Rastreabilidade) é extremamente custoso e um dia perdido têm impactos bem grandes.

Quais abordagens casam melhor com o Scrum?

Falando em Teste de Software, acredito que uma das que casa melhor é o Teste Baseado em Riscos (Risk-Based Testing), pois a cada sprint é necessário avaliar os riscos relacionados a mesma e fazer os testes associados aos riscos da sprint.

Como o tempo é bem curto, geralmente cada sprint tem 2 semanas, temos que ter foco nos testes. Por exemplo: num cenário de manutenção de software, é difícil realizar uma regressão de testes manuais completa.

Outra abordagem que destaco é a automação de testes, pois é muito difícil manter o teste de software sustentável sem buscar a automação, uma vez que trabalhamos com ciclos curtos e precisamos entregar valor constante para o cliente e software de qualidade.

Segundo o Humberto Barboza:

Acho que isso depende muito do projeto que trabalhamos. Precisamos sim avaliar os riscos claro que olhando para prazos e custos e perceber a melhor forma de trabalho com o que dispomos.

A metodologia de desenvolvimento de software da equipe de desenvolvimento é o que mais tem impacto no workflow do processo de Teste de Software. Sendo assim, é possível usar Scrum quando a equipe de desenvolvimento não usa?

É possível, mas dificilmente você vai conseguir usar todas as práticas do Scrum e conseguir cumprir as metas da sprint. O Teste de Software está fortemente ligado ao desenvolvimento (como irmãos siameses), por isso o melhor acaba sendo ambos usarem as mesmas metodologias/frameworks.

Mas algumas práticas do Scrum podem ser adotadas, como por exemplo: reunião diária, retrospectiva, quadro kanban e definição de metas de curto prazo.

O Humberto Barboza acredita que é possível, contanto que seja adaptado a nossa realidade:

Penso que sempre é possível, adaptando a metodologia à nossa realidade.

Bem pessoal é isso. Até a próxima! 😉

Fique por dentro das novidades, assine o feed do QualidadeBR.

Anúncios

O melhor da semana 23/05 a 29/05

Pessoal,

Segue abaixo, a lista com o melhor da semana, espero que gostem:

Você leu algo interessante, relacionado a área de Teste e Qualidade de Software, e quer compartilhar? Sinta-se à vontade em colocar nos comentários. 🙂

Abraços! E tenham uma ótima semana!

Fique por dentro das novidades, assine o feed do QualidadeBR.

O melhor da semana 16/05 a 22/05

Pessoal,

Segue abaixo, a lista com o melhor da semana, espero que gostem:

Você leu algo interessante, relacionado a área de Teste e Qualidade de Software, e quer compartilhar? Sinta-se à vontade em colocar nos comentários. 🙂

Abraços! E tenham uma ótima semana!

Fique por dentro das novidades, assine o feed do QualidadeBR.

Escola de Teste Direcionada pelo Contexto

Publiquei no TestExpert um artigo sobre a Escola de Teste Direcionada por Contexto, segue abaixo o link:

http://www.testexpert.com.br/?q=node/1751

O artigo apresenta os sete princípios básicos da Escola de Teste Direcionada por Contexto e foca bastante na importância de levar em consideração o contexto, quando realizamos as nossas atividades.

Boa leitura! 😉

Fique por dentro das novidades, assine o feed do QualidadeBR.

Quais ferramentas podem apoiar o Teste de Software?

A 24ª edição da Mesa Redonda DFTestes teve como tema “Quais ferramentas podem apoiar o Teste de Software?”. A discussão teve 14 respostas e 10 participantes, sendo eles: eu, Regiane Ribeiro, Rafael Silva, Rodrigo Almeida, Felipe Silva, Shmuel Gershon, Sarah Pimentel, Elias Nogueira, Ueslei Aquino e Humberto Barboza.

Abaixo faço um “resumo” da discussão, quem participa do grupo DFTestes pode acessar a discussão na íntegra, neste link.

Quais ferramentas podem apoiar o Teste de Software?

O Shmuel Gershon fez um comentário bem interessante:

A ferramenta mais útil em meu trabalho como testador é o quadro-branco (é, aquela lousa na parede mesmo, link).
Ferramentas são essenciais:
A menos que o testador tenha algum super poder de manipulação de bits e transistores com a forca da mente, ele vai precisar de um teclado, um mouse, um sistema operacional. Não dá pra testar sem ferramentas.
A pergunta é “quanto vamos deixar a ferramenta guiar o processo?”
E aí entram todas as ferramentas — as de geração de dados, as de controle de versão, as de gestão de testes — quanto nos deixamos a ferramenta decidir por nos?
Minha opinião é que se em algum momento você toma alguma ação por que é assim que a ferramenta faz, a ferramenta já está passando do seu limite. Ela trabalha pra você, não o inverso.

Segundo a Sarah Pimentel:

Qualquer uma que torne sua vida mais fácil, lembrando o que o Shmuel falou: A ferramenta trabalha pra você e não o inverso.

Eu concordo plenamente com o Luke Skywalker, que dizer Shmuel! 🙂

E acho que o ponto que ele  colocou, mostra bem um dos motivos pelos quais muitos profissionais ainda usam planilhas. Afinal, a planilha é totalmente customizada para a sua necessidade, você não tem que ficar preenchendo campos com blá-blá.

Quando optar pelo uso de uma ferramenta, ao invés, de um processo manual?

De acordo com a Sarah Pimentel:

– Quando o processo manual for difícil de manter/executar;
– Quando houver planejamento (tempo para aprender a ferramenta, tempo para verificar necessidades de adaptações na ferramenta e realizá-las…);
– Quando o processo de teste estiver maduro (mas ele pode amadurecer usando ferramentas também).

Para o Elias Nogueira precisamos ter o controle sobre o processo antes de buscar ferramentas:

Quando você já tem todo o controle sobre o processo e onde a aplicação dessa ferramenta não traga riscos ou grandes adaptações ao processo de teste

O Ueslei disse que:

Sabemos que em cada uma das fases do ciclo de vida, diversas são as atividades e técnicas a serem realizadas afim de gerar os produtos de cada uma das fases e, com toda certeza cada uma delas podem ser facilitadas com o uso de ferramentas. Mas, um fator que vejo de extrema importâncias é:

O profissional de teste precisa primeiro entender as técnicas de teste para então entender quais ferramentas devem ser usadas para cada técnica.

Como colocado pelo Elias Nogueira, eu reforço: O emprego de uma ferramenta errada na vez de ajudar se torna um grande risco para o projeto.

Então a melhor ferramenta é aquela que melhor atende ao processo de teste da organização e nem sempre, a ferramenta ideal para uma organização será ideal para outras. Com isso, um fator de importância é o estudo de viabilidades das ferramentas antes de sua aquisição e implantação de uma ferramenta na Organização. Esta prática pode eliminar o risco de, apenas no meio do projeto, descobrir que a ferramenta empregada não atende.

De acordo com o Humberto Barboza:

O uso de ferramentas sempre foi mesmo motivo de discussão na nossa área. Em relação a ferramentas de teste automatizado, alguns pontos devem ser questionados quando pensamos nisso. Por exemplo, uma ferramenta faz automaticamente tudo que fazemos manualmente, ou seja, ela não têm capacidade intelectual, então, o ganho de sua utilização está no tempo de execução. Porém, precisamos saber se fatores como: custo da ferramenta, prazo (Tempo de aprendizado), negócio do cliente, tipos de teste (Pra regressão é uma boa), serão adequados ao seu uso.

Em relação a outros tipos de ferramenta, considero algumas muito importantes no processo de teste. As de Gestão de Defeitos (Mantis, Trac), Gerência de Configuração (ClearCase, VSS) são bastante eficientes pois têm aprendizado e manutenção relativamente fáceis. E confesso que depois de algum tempo as utilizando ficamos dependentes das mesmas. Hoje mesmo, quero voltar a utilizar o Trac ou a HP Quality Center porque na empresa atual meu processo está todo manual com planilhas excel.

Adotamos o scrum e gostaria bastante de utilizar estas ferramentas, mas, hoje tenho um problema em que a equipe de desenvolvimento prefere o quadro afirmando que a visualização das tarefas e defeitos através dele são fundamentais para o sucesso da metodologia. Então, penso em como não ter retrabalho neste cenário, visto que neste caso teremos que incluir na ferramenta e também no quadro.

Quando o desenvolvimento de uma ferramenta internamente pode ser a melhor escolha?

A Sarah Pimentel respondeu dizendo:

Essa é uma análise que deve levar em conta:
.. atendimento às necessidades;
.. custo;
.. usabilidade;
.. tempo.

Segundo o Elias Nogueira:

Quase que jamais!!!!
Atualmente existem diversas, mas diversas ferramentas para a apoiar o processo de teste.
Já vi muitos casos que as empresas criam ferramentas de bug tracker, que é o mais comum, mas a alocação de um profissional e o tempo que a ferramenta leva para ser desenvolvida não justifica o custo de até comprar e customizar uma ferramenta…
Mas, quem sou eu pra dizer que a empresa X está errada em desenvolver uma ferramenta para o apoio aos testes.

Na verdade, creio que o único momento que podemos nos ‘dar ao luxo’ de desenvolver uma ferramenta internamente é referente a automação nos níveis unitários, de integração e de sistema. Já peguei projetos onde eu não conseguia nenhuma ferramenta e tive que criar uma arquitetura automatizada para testar um sistema de mensageira.

Só uma aviso aos novatos: muito se fala em utilizar e implantar o Mantis e Testlink para dar “velocidade” ao processo e ter um ponto centralizado. Mas iniciem conhecendo os conceitos dessas ferramentas (gestão de defeitos e gestão de testes), faça manualmente e depois implemente, se necessário, uma ferramenta.

A ferramenta que deve se adequar ao nosso processo, e não o contrário!

O Humberto respondeu a pergunta dizendo:

Penso que somente quando o negócio é muito específico e a adaptação à ferramenta inviável. Mas, quase sempre nesses casos vale mais a pena continuar com o processo manual.

Sobre o que o Elias disse, eu acho que é de se considerar a possibilidade. Principalmente, em se tratando de sistemas não web. (mas esse já é um tema de outra mesa redonda)

Bem pessoal é isso. Continuem de olho na lista do DFTestes, pois sempre há assuntos bem interessantes lá, e poderão haver novas respostas nessa mesa redonda.

Fique por dentro das novidades, assine o feed do QualidadeBR.

O melhor da semana 09/05 a 15/05

Pessoal,

Segue abaixo, a lista com o melhor da semana, espero que gostem:

Você leu algo interessante, relacionado a área de Teste e Qualidade de Software, e quer compartilhar? Sinta-se à vontade em colocar nos comentários. 🙂

Abraços! E tenham uma ótima semana!

Fique por dentro das novidades, assine o feed do QualidadeBR.

Padronização de caso de teste. Pluralizado ou integrado?

A 23ª Mesa Redonda DFTestes foi sobre “Padronização de caso de teste. Pluralizado ou integrado?”. A discussão até o presente momento, teve 23 respostas e 8 participantes sendo eles: eu, Felipe Silva, Elias Nogueira, Edwagney Luz, Renata Eliza, Shmuel Gershon, Sarah Pimentel e Lucas Nadalete.

A mesa redonda começou bem fria, estava dando pinta que nem iria dar muita discussão, mas de repente, ela estourou. E vários comentários relacionados ao assuntos foram feitos, boas analogias e explicações foram feitas, mas até o momento não conseguimos saber o que é um caso de teste pluralizado e integrado. :s

A seguir, faço um resumo dessa excelente mesa redonda, que é altamente recomendável a sua leitura na íntegra, pois vários assuntos foram discutidos durante a mesa redonda, e como sempre faço o resumo focado no tema da discussão, alguns bons comentários sobre outros assuntos ficam de fora.

Padronização de caso de teste. Pluralizado ou integrado?

Até o momento desse post, ninguém conseguiu explicar o que seria um caso de teste pluralizado ou integrado. Tal terminologia, provavelmente deve ser bem específica, já que ninguém, tinha ouvido ela antes.

E falando em termos, o Edwagney fez um comentário bem pertinente:

Sinceramente, não vejo nenhum motivo para acrescentarmos mais conceitos como “Pluralizado ou Integrado”. Acho totalmente desnecessário!

Na minha opinião, realmente é desnecessário criar novos termos, principalmente, quando eles não são “auto explicativos”.

O Elias Nogueira fez uma interpretação que se não é a correta em relação aos termos é correta em se tratando de casos de teste:

Se eu interpretei bem o enunciado dessa mesa redonda, e seria interessante o outro desse tópico explicar, é a diferença entre o pluralizado e o integrado.
Pelo entendimento que tenho disso, creio que seria:

  • Pluralizado: Casos de teste distintos. Esses seriam como: Inserir Cliente com sucesso, Inserir Produto com sucesso, Emitir NF, Calcular impostos, etc… Logo um Caso de Teste no cenário: “cada um no seu quadrado”. Cada um executa uma ação específica para o que ele realmente é proposto
  • Integrado: Casos de Teste que “agrupam” todos os testes a fim de chegar a um objetivo comum. Seria como eu criar apenas um Caso de Teste para Emitir uma NF, sedo que tenho passos do cadastro do cliente, cadastro de produtos, calculo de impostos, etc…

Se for nessa linha de pensamento, e na minha linha purista, os Casos de Teste Pluralizados são os corretos, e não existe qualquer outra nomenclatura ou “agrupamento” de Casos de Teste. O que criamos quando temos uma linha parecida com o Integrado são Cenários de Teste.

Padronização de caso de teste. Detalhado ou resumido?

O Felipe Silva acabou sugerindo a questão “Padronização de caso de teste. Detalhado ou resumido?”, no lugar da questão tema da mesa redonda, por essa terminologia ser mais conhecida. A respeito da questão, o Felipe mesmo deu a sua opinião dizendo, subentendo que pluralizado seria um caso de teste mais resumido e o integrado um caso de teste detalhado:

Se eu entendi corretamente, pluralizado seria um caso teste escrito de forma genérica, que não contém detalhes específicos, e integrado seria aquele caso de teste com o máximo possível de step detalhados com toda informação específica, o famoso caso de testes “que até minha mãe conseguiria ler, executar e avaliar o resultado”.

Se for mesmo isso, prefiro o modelo básico (pluralizado), este é mais fácil de ser escrito e mantido, porém os detalhes que não estão escrito precisam estar na cabeça de quem executa, portanto exige que sejam executados por experts no projeto.

Já houve uma discussão sobre o tema no DFTestes.

Para mim, seguindo o entendimento do Felipe, a resposta para a pergunta depende do contexto em que se está testando. Como o Felipe disse, o genérico/pluralizado exige que o testador tenha domínio sobre as regras de negócio e a aplicação. Já o detalhado/integrado não exige um domínio sobre as regras de negócio e a aplicação por parte do testador.

Outros pontos interessantes, é em questão da manutenibilidade, estabilidade e velocidade. O caso de teste genérico/pluralizado tem maior manutenibilidade e estabilidade, pois como ele é mais a nível do que fazer e não como fazer, acaba sendo mais curto, portanto mais fácil de manter, e é menos “quebrável”, já que não entrar em detalhes de implementação (ex.: nome do campos). Já em questão de velocidade, mais uma vez o teste genérico/pluralizado leva vantagem, pelo mesmo motivo de que ele é mais fácil de manter.

Resumindo, se você é quem especifica os casos de testes e testa, ou você é um testador já experiente, então o mais indicado pode ser o caso de teste genérico/pluralizado. Agora se quem irá executar os testes não tem pleno conhecimentos das regras de negócio e da aplicação, ou ainda, os testes podem ser reutilizados num futuro (exemplo manutenções no software), o mais indicado pode ser o caso de teste detalhado/integrado.

O Elias Nogueira acredita que um bom caso de teste precisa ser detalhado, segundo ele:

Quanto a isso, ainda sou meio “purista” e creio que um bom Caso de Teste precisa ser detalhado. Precisa sim conter os passos como condições de uso e ser muito bem estruturado.

Existem sim várias formas de criar os Casos de Teste no Test Design, sendo o mais usual a de Heumman para criar os Casos de Teste a partir dos Casos de Uso.

O que define o grau de detalhamento são os tipos de teste para qual o(s) Caso(s) de Teste estão sendo escritos.
Quando vou escrever um Caso de Teste em nível Unitário, obviamente ele será diferente do de Sistema que estamos acostumados a criar. Escrever um Caso de Teste para algum cenário de Performance também é diferente de um Caso de Teste Aceitação.
Os Casos de Teste podem ter a entrada do seu processo os seguintes fatores:

  • Requisitos de Negócio
  • Interface com o Usuário
  • Domínio de entradas

Com o detalhamento, a equipe vai saber de regras que nem o Analista de Requisitos/Sistema saberá mais depois de 1 semana… e pra onde vai o conhecimento dessas regras?
Outro ponto também é que com um Caso de Teste detalhado, qualquer um na tua equipe, ou qualquer um que entrar na equipe, poderá ter um conhecimento maior da aplicação na execução destes Casos de Teste.

Claro que, em nossa realidade isso muda constantemente. Eu trabalho hoje num “Fábrica”, e sou obrigado a escrever Casos de Teste detalhados para os Testadores, que as vezes nem conheço. Se eu não fizer isso, posso deixar aspectos importantes passar não pelo pouco detalhamento do Caso de Teste, e sim da interpretação do Testador.

Já na realidade de quem não trabalha em uma Fábrica, creio que o nível de detalhe não é alto pelo alto conhecimento da aplicação que estes profissionais já tem.

A respeito da opinião do Elias, eu não acho que seja uma questão de qual é o melhor detalhado ou genérico/resumido. Ambos tem os seus pontos positivos e negativos. O importante é que o profissional de teste saiba da existência dos dois, pois é ele quem irá decidir por optar um ou outro.

A Renata Eliza deu a sua explicação sobre o caso de teste Step by Step (o famoso passo a passo), que seria o detalhado e o cenário de teste, que seria o mais resumido:

Acredito que as distinções dos Casos de Teste teriam mais sentido se fossem do tipo:
Casos de Teste Step by Step: quando o objetivo é cercar, através de casos de teste detalhados todas as possibilidades de um determinado documento da especificação. Como por exemplo, o Caso de Uso.
Cenários de Teste: que dá uma ideia mais generalizada do que deve ser testado naquele determinado cenário. Mais voltado para profissionais experientes, que têm a visão do que realmente precisam fazer.

O Edwagney falou sobre caso de teste detalhado, fazendo importantes considerações que nos podem levar a escolher ele:

Também não acho interessante que sejam elaborados apenas casos de teste detalhados. Isso depende muito da empresa que está usando o processo e como ela deseja documentar isso. Para uma empresa que existe grande rotatividade de profissionais, talvez seja interessante um maior nível de detalhe, entretanto, outra que tem uma política de manter seu grupo e treinar novos profissionais, o detalhamento fará um efeito contrário. Ao invés de ajudar, vai atrapalhar, pois o grupo é coeso e experiente, e não necessita de um alto nível de detalhamento para que o caso seja executado com qualidade e dê o resultado que se espera. Digo isso porque já trabalhei com esses dois tipos de empresas.

Nas consultorias que faço e nas empresas que eu trabalhei com isso, quando elegemos um caso de teste passivo de automatização, onde chegamos a um nível de detalhamento que seja possível sua automatização. Para os que não é possível a automatização, o nível de detalhamento segue sempre o bom senso e a forma de trabalhar da empresa

Coloco também uma outra variável para incrementar a questão, depende também do ramo de atuação da empresa. Se ela for especialista demais e seus profissionais idem, ao detalharmos os casos demais, ninguém usa e o processo cai todo por água abaixo. Um exemplo muito bom é a área de Telecom. É uma área tão específica e tão especialista, que para uma pessoa conseguir executar um tipo de teste, tem que ter uma série de requisitos básicos, que se formos colocar todas essas informações em um caso de teste, seria gasto tanto tempo que se tornaria inviável. E quando a pessoa já está devidamente treinada, ela não usa os casos detalhados, pois eles, ao invés de ajudar, travam a produtividade. Isso em caso de teste manual.

O Edwagney ainda deu uma excelente e bem didática explicação sobre a “cadeia”  dos casos de testes:

Faço a comparação com uma peça teatral, onde o nome da peça, seria a suíte de testes; os cenários, naturalmente os cenários do teste; as cenas, os casos de teste; e os atos dos atores a sequencia de execução cada cena ou caso de teste.

A Sarah Pimentel deu a sua opinião sobre a questão dizendo:

Entre um caso com mais detalhes e outros com menos, pra mim a resposta é como a da maioria das mesas redondas que temos: depende 😛
Se temos um caso de teste detalhado demais, e temos a política de capturar telas que comprovam a execução de cada passo, começa a ser um trabalho enfadonho, especialmente os testes de regressão que executamos inúmeras vezes.
Se temos um caso de teste genérico demais, corremos o risco de o testador não entender bem o step ou não verificar todos os pontos que o autor imaginou que ele verificaria.
Pra mim, assim como um documento de requisitos, o caso de testes está bom quando especifica tudo e não deixa brechas para interpretações. Se algo precisa ser verificado, deve estar explicitamente detalhado em algum passo. Se algo não precisa de tanta atenção (pode ser o caso de alinhamento de labels, nomes de campos que mudaram para outros similares, cores, posicionamento de objetos)… Não precisa estar descrito. Não que esses itens não devam ser testados, mas tem aplicações nas quais isso é um fator importante e outras em que não. Então depende do teu objetivo.
Para casos de teste que exigem uma busca um pouco mais complexa de dados, por exemplo, bastaria eu dizer que eu preciso de “um contrato de manutenção de hardware válido para atendimento físico com SLA de 48h” ou eu colocaria na pré-condição uma query que trouxesse esses tipos de contrato para o testador? Pouparia bastante tempo se ela já estivesse lá. E essa é uma decisão, pra mim, similar a de cima. Se vamos ganhar tempo e acuracidade, opto por detalhar. Se vamos burocratizar e onerar a manutenção e a execução, opto por generalizar.
O Lucas deu a sua opinião contando um pouco da sua experiência:
Na empresa onde trabalho temos situações onde as especificações dos Casos de Teste tendem a ser mais detalhadas quando dispomos de um prazo aceitável, escopo e especificação de Caso de Uso bem definidos e o profissional responsável por automatizar ou executar manualmente os testes não possui muita experiência a respeito do ambiente e negócio; já por outro lado, também nos deparamos com situações onde os Casos de Teste tendem a ser definidos de uma forma bem mais genérica, sem muitos detalhes (step-by-step), com uma descrição mínima do Caso de Teste, das entradas e das saídas esperadas. Este segundo ocorre principalmente quando há um cronograma bem mais enxuto que o esperado e o testador é alguém que conhece muito bem as regras de negócio do produto/projeto alvo.Em outras palavras, a forma como os Casos de Teste são especificados, varia e bastante. Sou extremamente a favor de se trabalhar com Casos de Teste Padronizados, mas se analisarmos com calma nem sempre as variáveis envolvidas são favoráveis, tais como: cronograma, artefatos (especificação de caso de uso, requisitos, …), ambiente, experiência do testador (técnica e negócio), automatizado/manual, enfim; e por serem elementos variáveis, os mesmos tendem a impactar na forma como os Casos de Teste são definidos, quando realmente são definidos.

Como exemplo, quando o testador tem pleno conhecimento do contexto de negócio, e o script de teste tende a ser automatizado, os Casos de Teste aqui na empresa são especificados genericamente, e o detalhamento (step-by-step) do teste fica por conta do script. Apesar de não ser a melhor prática, principalmente do ponto de vista de manutenibilidade, isso nos possibilita trabalhar a especificação dos Casos de Teste, automatização dos scripts, execução dos testes e gestão de defeitos, dentro do prazo esperado para as entregas/implantações.

Cuidado com o que você chama de caso de teste

O Elias fez um comentário bem pertinente sobre o que chamamos de caso de teste:

Uma outra coisa que não posso deixar de comentar: os que até hoje tratam em alguns lugares o Caso de Teste como sendo um passo. Aquelas planilhas em Excel gigantes, onde um profissional fala que tem 5.000 Casos de Teste, que na verdade são passos.
Isso pra mim é a pior coisa que um profissional pode fazer, além das empresas que vendem a atividade de criação de Casos de Teste por quantidade.

Sobre o assunto, o Lucas fez o seguinte comentário:

A respeito das famosas planilhas Excel, é extremamente importante não confundir um “caso de teste” por mais genérico que seja, com uma linha em uma planilha eletrônica que na realidade representa um simples “passo”. Já me deparei com situações onde a própria equipe de desenvolvimento gera uma planilha dessas com os testes executados por eles mesmos, e ao realizarem a entrega repassam o artefato como quem diz: “aqui estão as entregas e estes são os testes executados, só refazer”, ou seja, totalmente sem fundamento. Diante de uma simples “verificação” é possível evidenciar vários fluxos (alternativos ou de exceção) que não foram contemplados, bem como validações efetuadas incorretamente.

Bem pessoal é isso. Continuem de olho na lista do DFTestes, pois sempre há assuntos bem interessantes lá, e poderão haver novas respostas nessa mesa redonda.

Fique por dentro das novidades, assine o feed do QualidadeBR.