Vamos testar e desenvolver?

Caros(as) leitores(as),

O que vocês acham de testar e desenvolver uma aplicação?

Isso mesmo, testar e desenvolver uma aplicação na prática, colocar a mão na massa! 🙂

Como seria isso? Bem o formato que estive pensando (podemos refinar depois), é que primeiro vocês escrevem um teste e me enviam (pelos comentários), daí eu implemento o código para passar naquele teste, e depois a gente troca. E assim vai indo, até a nossa aplicação ficar pronta.

Em qual linguagem?

Qualquer uma. 😀

A intenção não é aprender a sintaxe de determinada linguagem e sim exercitar as suas habilidades para testar e desenvolver.

Mas eu não sei programar Fabrício

Sem problemas também, pode enviar a implementação do código em pseudocódigo.

Só é preciso saber lógica de programação e ter vontade de aprender para participar. 🙂

OBS.: A “tradução” para alguma linguagem de programação eu faço depois, para podermos ir evoluindo a aplicação.

Como iremos testar?

A ideia é utilizando testes automatizados, usando alguma ferramenta Xunit ou até de testes de aceitação. E se você não conhecer nenhuma ferramenta, poderá enviar o teste no estilo do cenário do BDD.

Como iremos desenvolver?

Utilizando TDD, ou seja, primeiro vamos escrever o teste para depois escrever o código. Indo bem baby steps.

Ou seja, acaba sendo “parecido” com um dojo, só que online.

Qual aplicação iremos desenvolver?

Uma aplicação simples, a primeira seria uma para descobrir que tipo é um triângulo. Praticamente a mesma que o Camilo Ribeiro escreveu em Java.

Topam?

Se você estiver interessado em participar, basta fazer um comentário (não doí rs). O mínimo para essa ideia maluca ser colocada em prática é um participante hehe. Se tivermos mais, o que seria muito legal, melhor ainda, pois poderemos aprender mais e ter soluções implementadas de forma diferente e usando ferramentas e linguagens diferentes também. 🙂

Depois maiores detalhes de como será a dinâmica de trabalho eu explico depois (pensando em usar os próprios comentários do blog ou criar uma lista de e-mail).

Update 18/11/10

Pessoal, irei fechar as “inscrições” para essa dinâmica no dia 30 de novembro. Portanto, se você quiser participar, deixe um comentário que eu entrarei em contato.

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

Anúncios

O melhor da semana 24/10 a 30/10

Pessoal,

Após um tempo sem “o melhor da semana”, o dessa semana está bem “recheado”:

Conhecimento a um clique, esse é o QualidadeBR. 🙂

Abraços! E tenham uma ótima semana!

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

OFF – Mudanças

Quem acompanha o blog há um tempo, teve ter notado que algo está ocorrendo, afinal o QualidadeBR nunca tinha ficado sem atualizações semanais (ou no máximo duas semanas de lacuna).

E neste post explico as razões para isso e também conto algumas mudanças que ocorreram na minha carreira, que acabaram influenciando a ausência de posts e criação de conteúdo (afinal, “o melhor da semana”, não conta como criação de conteúdo rs).

“Lado negro da força”

Antes, é bom explicar que o “lado negro” do tópico é apenas uma brincadeira 😉 (não há o bem/mal entre Teste de Software e Desenvolvimento de Software)

Começando pelo começo, afinal é sempre bom começar por ele. Desde praticamente o começo de 2010 eu tenho me dedicado meus estudos, mais para a área de programação.

No início de 2010 houveram boas oportunidades na Voice Technology, para iniciar uma abordagem diferente na hora de se decidir sobre como serão feitos os testes. No começo tentei uma abordagem mais voltada ao testes unitários, pois eles seriam a base para a automação dos testes, e para isso era preciso ter alguns conhecimentos em Java e também o mindset de Teste de Software. E como eu era o que mais “enchia o saco” sobre isso, acabei aceitando esse desafio (meus conhecimentos sobre Java, eram BEM fracos rs). Mas no final, o projeto acabou não indo para frente e o desenvolvimento dos testes unitários também.

Depois desse projeto, houve outro no qual também participei com o foco mais em automação, só que dessa vez voltado para os testes de aceitação, usando o Selenium para os testes de uma interface Web e desenvolvendo um mini “framework” para automatizar os testes de controle de chamada (testes de URA). Foi sem dúvidas, um período bem legal, afinal aplicar os meus conhecimentos em Teste de Software e ao mesmo tempo aprender Java foi muito divertido.

Em paralelo a isso estava estudando Ruby on Rails, cujo interesse surgiu no 6º encontro do pessoal do Guru-SP. Primeiro lendo o livro Agile Web Development with Rails e depois fiz o excelente curso da e-genial, de Ruby on Rails do básico ao avançado.

O meu objetivo com os estudos de Ruby on Rails eram para desenvolver/contribuir com projetos open-source, principalmente projetos voltados para a área de Teste de Software.

Porém…

No final do projeto de automação na Voice Technology, surgiu um novo projeto que tinha um módulo de configuração via Web, e o meu Scrum Master estava pensando em desenvolver em Ruby on Rails e perguntou se eu estaria interessado. Como o projeto de automação já estava estável e o pessoal estava usando o “mini” framework que criei, e eu estava querendo colocar em prática os conhecimentos que estava aprendendo no curso da e-genial, aceitei o desafio e lá fui eu, encarar o meu primeiro projeto de desenvolvimento Web. 🙂

O começo foi bem difícil,  pois desenvolvimento Web exige vários conhecimentos, e além de estar começando a trabalhar com Ruby on Rails, precisava também aprender mais sobre HTML, CSS e Javascript (mal sabia as tags do HTML rs). Lembro que após algumas sprints, estava bem decepcionado com o meu próprio desempenho, pois a gente (eu e meu Scrum Master) estávamos a quase duas sprints emperrados numa parte do sistema, que estavamos usando Ajax e eu estava com sérias dificuldades em fazer tudo funcionar (mexia num lugar, quebrava o outro e assim ia rs). Mas no final deu tudo certo e a gente conseguiu finalizar a primeira versão do projeto.

E depois desse primeiro projeto surgiram outros e aí acabei trabalhando na Voice, 100% com Desenvolvimento de Software.

Por que a mudança?

Diferente de vários conhecidos meus, que largaram a área de Teste de Software para se dedicar a área de Desenvolvimento de Software, eu não tinha ambições em seguir a área de Desenvolvimento de Software, não após conhecer e me apaixonar pela área de Teste de Software.

Porém, aqui estou programando em Ruby, lidando com bugs de interface (maldito IE! rs), escrevendo testes automatizados (ainda não tantos quanto é preciso), tentando usar TDD (ainda sou muito bundão e orientado ao VFFP – “vamo fazer funcionar primeiro”), fazendo commits (o Git é sensacional!), tentando escrever código SOLID, passando madrugadas em frente ao computador a base de Red Bull para entregar um projeto em 48 horas,  buscando me especializar com cursos e livros, etc.

Não há um único motivo para a mudança de área, não é apenas porque Ruby on Rails é um framework revolucionário ou porque as oportunidades foram surgindo na empresa.

Mas para não esquivar/sabonetar a resposta da pergunta do tópico, vou dizir dois motivos principais:

  • Meu perfil
    • eu cai na área de Tecnologia, o curso de Análise e Desenvolvimento de Sistemas não estava nos meus planos no começo de 2005 e eu junto com meus amigos estávamos pensando em seguir pra área de Jornalismo (ninguém acabou seguindo rs), mas por sorte, acabei me inscrevendo no curso da Termomecanica e passando (e não passando nem na USP e na Mackenzie e Metodista pelo ProUni em Jornalismo). E a área de Tecnologia tem algo que sempre gostei de fazer, estudar. E gostar de estudar é fundamental para quem atua em áreas onde a informação é o mais importante, como é o caso da área de Tecnologia da Informação (e antes se eu era tachado de CDF, hoje sou tachado de NERD rs);
    • e assim como eu gostava de Matemática e Português, eu também gosto de estudar sobre Teste de Software e Desenvolvimento de Software, e assim o meu perfil acaba sendo muita mais generalista do que especialista, embora eu busque ser um especialista-generalista, ou seja, ser especialista em alguma(s) área(s), mas também ter uma boa base de outras áreas.
  • Criação
    • saber programar,  possibilita poder criar soluções e isso é MUITO divertido!
    • adoro ter ideias, mas ideias por si só são apenas ideias, o importante é colocar as ideias em prática, e o “ecossistema Ruby on Rails” é sensacional quanto a isso, por permiti você colocar as suas ideias de forma rápida e praticamente sem nenhum custo, a não ser o seu próprio tempo e dedicação.

A combustão

Tirei férias em setembro, e ao invés, de aproveitar como tudo faz, indo para praia, viajando, etc foi o mês do ano, em que mais trabalhei, principalmente na última semana das férias. E o motivo, o Vizir.

Acabou ocorrendo de casar o novo rumo que o André e o Antonio estavam tomando nas suas carreiras, com as minhas novas aspirações e pensamentos (um dia preciso fazer um post sobre isso rs, provavelmente é muito off-topic, e será no meu blog pessoal hehe) e surgiu a oportunidade de ajudar eles com o Vizir e ser sócio da start-up. 😀

Empreender é algo que eu acabei descobrindo que já fazia há um tempo (rs), afinal o QualidadeBR mesmo, é um empreendimento, embora seja um passivo (rs) no aspecto financeiro, mas no aspecto de ganhos de conhecimento está sendo um excelente ativo! 😀

E o Vizir é uma excelente oportunidade de aprender MUITO mais, sobre várias áreas e colocar as ideias e conhecimentos em combustão e produzir soluções que realmente solucionem os problemas dos clientes, e o Vizir (produto) é nossa primeira tentativa, voltado para as pessoas que precisam monitorar as suas marcas nas redes sociais.

A escolha por Rails acabou sendo natural, no começo do desenvolvimento do Vizir, e isso acabou definindo os novos rumos que estou e irei tomar quanto ao conhecimento, o foco mais do que nunca é ficar fera em Ruby on Rails, e por isso acabei dando uma parada nos estudos sobre Teste de Software.

QualidadeBR e a área de Teste de Software

Durante esses últimos meses está sendo bem difícil conciliar as atividades que exercia antes do Vizir, e por isso acabei tendo que sair da comunidade Testadores e participando menos dos grupos de discussão. Essas foram decisões difíceis, pois gosto muito da área, de ajudar as pessoas e da equipe dos Testadores, porém percebi que se fosse tentar fazer tudo que gostaria, não iria fazer nada muito bem.

E também pensei várias vezes sobre o que faria em relação a área de Teste de Software e o blog, afinal são quase 3 anos de QualidadeBR e de atuação na área.

Decidi por não abandonar nenhuma das duas, o blog irá continuar e a minha atuação na área também. Logicamente que não trabalhando mais na área de Teste de Software, os tópicos que serão abordados no blog, provavelmente seguiram uma outra linha (ainda irei definir). E acho que isso é bom, afinal sempre escrevi no blog sobre o que estava aprendendo/vivenciando.

A minha atuação na área, será agora exclusiva a participação de discussões, ajudando o pessoal e manter o blog.

Quanto a periodicidade dos posts, ainda não dá pra dizer que voltará a ser semanal, mas irei me esforçar pra produzir conteúdo, pelo menos uma vez no mês. 🙂

Bem é isso, obrigado a todos e desculpem pela ausência.

Fonte imagens:

http://bit.ly/dont_be_afraid_of_change

http://bit.ly/bruce_on_rails

Automação de testes funcionais

A 30ª Mesa Redonda DFTestes, que ocorreu na primeira quinzena de agosto, foi sobre “Automação de testes funcionais”. A mesa redonda gerou bastante discussão, totalizando 29 respostas e tendo 10 participantes, sendo eles: eu, Juraci Vieira, Felipe Silva, Shmuel Gershon, Elias Nogueira, Rodrigo Almeida, Ueslei Aquino, Luiz Gustavo, Fermiano de Queiroz e Roberto Passani.

Segue abaixo, o resumo desta mesa redonda, quem quiser conferir a discussão na íntegra, só acessar esse link.

Vocês acham a automação dos testes funcionais necessária? Se sim, você sempre tenta automatizar os testes funcionais, como?

Segundo o Juraci Vieira:

Certamente é necessária uma vez que os ciclos do desenvolvimento de software estão cada vez mais ágeis e os softwares cada vez mais complexos, para cobrir a complexidade crescente é necessário grande quantidade de casos de teste, e para se adequar ao curto prazo de tempo é necessário executar essa grande quantidade de testes de maneira mais eficiente porém, mantendo a acurácia. Isso é possível com a automação de testes funcionais.

Outra razão para se utilizar automação de testes funcionais seria para investir mais tempo no trabalho de análise do software e desenvolvimento dos casos de testes (para que os mesmos sejam mais eficazes em encontrar defeitos) do que na execução propriamente dita. Digo isso em casos de equipes pequenas de teste como é o meu caso em que sou o analista de testes e o executor dos testes. Isso me poupa tempo pra planejar melhor o que fazer.

O Juraci automatiza os testes funcionais da seguinte maneira:

Eu sempre tento automatizar aqueles casos de testes repetitivos e que exigem bastante atenção, nem sempre você está com a atenção 100% para executar o mesmo teste manual passo a passo, esquecer-se de um detalhe é normal para seres humanos. Prefiro investir um tempo até dez vezes maior para automatizar um caso de teste assim do que executa-lo sempre manualmente com o risco de errar algum passo e mascarar o resultado do teste.

Automatizo utilizando 2 softwares livres AutoIt e QAliber. Tenho um certo domínio sobre o AutoIt e o mesmo satisfaz minhas necessidades. O QAliber tenho estudado a cerca de um mês e logo utilizarei em um projeto “vivo”.

O Felipe Silva também acredita que a automação dos testes funcionais é necessária, e segundo ele é importante para manter a competitividade e consenguir atender as demandas:

Sim, é necessário principalmente para que se possa ser competitivo o suficiente para conseguir manter os atuais e clientes e ganhar novos, a automação também ajuda na qualidade dos testes, uma vez que pode-se concentrar o foco dos testes mais na análise de futuros novos erros do que em regressões, em certos casos é possível automatizar aquilo que ainda está apenas nos requisitos, ganhando agilidade também desde os primeiros ciclos de testes (deixando a “malhar grossa” na automação e a “malha fina” nos testes manuais).

O Felipe Silva compartilhou como ele faz a automação dos testes funcionais, dizendo:

Sim, sempre que possível e viável tentamos planejar a automação, não só de testes funcionais, mas todo tipo de automação que traga bons resultados, nem que só possamos começar a trabalhar nisso só daqui alguns meses, como ferramentas temos QTP (Quick Test Professional), Selenium, o próprio Java, tem coisas que acabam sendo automatizadas com Macros.

Segundo o Shmuel  a automação nem sempre é necessária:

A automação dos testes não é necessária. Ela pode ser vantajosa às vezes, ou prática, ou até mesmo agradável. Mas nem sempre ela é necessária.

Por outro lado, eu tento automatizar testes funcionais, claro. Existem testes que trazem beneficio quando automatizados.

Eu uso batch files, VBScript ou C# quando escrevo minhas automações. Já usei AutoHotKey (“irmão” do AutoIT mencionado pelo Juraci), VB, Ruby e Perl também, mas menos.

O Elias Nogueira destacou a importância de uma análise de viabilidade:

A automação nem sempre é viável, eu mesmo já recebi diversas demandas de clientes internos querendo “firulas” para “melhorar o seu trabalho”, mas de nada traz ganho como um todo para a organização.

Sempre, mas sempre que pensarmos em automação é necessário uma análise de viabilidade. Ela não precisa ser um documento mega extenso e difícil de ler, mas um tempo em que necessitamos avaliar se realmente a automação faz sentido ou traz ganhos em potencial.

Hoje mesmo tive um caso em que a automação solicitada, depois de fazer uma PoC (Prova de Conceito), só iria trazer benefícios após o 42° ciclo de execução, para um sistema que executa 1 ciclo mensal. O Analista de Teste que solicitou isso vê um ganho pra ele, mas eu nao vejo ganho em alocar minha equipe num trabalho que não trará um retorno esperado.

E o Elias, ainda complementou dizendo:

A automação é uma das ferramentas para o Teste, e não deve sempre ser tomado como lei nas empresas. Mas isso, como sempre depende…

Como o próprio Shamuel relatou em suas experiências em automação, podemos utilizar qualquer artifício para automatizar: shell script, AWK, programação pura, ferramentas de automação, etc…

A automação de teste, às vezes, mas atrapalha do que ajuda. Isso se deve a diversos fatores, como o próprio entendimento da automação por parte dos stakeholders (lembrem do gerente sem noção, que acha que a automação é como um “testa aí”, basta dar record-and-play e tudo se resolve), senioridade/conhecimento técnico da equipe e conhecimento de negócio por parte dos Analistas de Teste (sim, se estes não souberem especificar bons testes, estaremos fazendo uma má automação).

O Rodrigo Almeida resumiu bem a sua opinião sobre o assunto, dizendo:

Eu tenho certeza que ela é necessária. Para ter produtividade alta é preciso ter automação. O segredo é saber quais casos de teste escrever e automatizar!

Saber quais são os testes que são necessários ser automatizados é importante segundo o Rodrigo:

Sempre. Desde que o seu ROI seja positivo, ou seja, precisamos automatizar os casos de teste corretos. Casos de teste para telas CRUD de sistemas não precisam ser automatizadas. E eu acho que precisa fazer teste uma vez só na vida para estas telas. O que precisa ter teste automatizado são as funcionalidades do núcleo do sistema, que contém as regras de negócio do sistema que o cliente usa. Se estas regras sofreram algum impacto em alguma mudança realizada no sistema/ERP, só saberemos na execução dos testes funcionais automatizados.

Sobre a necessidade de automatizar testes de CRUD (Create-Read-Update-Delete), o Elias Nogueira acredita que tudo depende da situação, em determinados casos a automação de tais testes pode sim ser fazer necessária:

Em alguns tipos de sistemas o CRUD é o que é mais utilizado (e mail alterado) pelo cliente.

O importante é ter foco no que o cliente realmente usa e também no que ele realmente quer… Se precisar automatizar uma parte ínfima de uma tela ou regra que nunca é utilizada para agradar o cliente, temos que automatizá-la.
Isso é meio “ruim” pra nos, não gostamos, mas é o valor que o cliente vê nisso que nos faz ser vistos com bons olhos e como uma equipe que agraga valor.

O Ueslei Aquino, concorda com o Elias, e expôs uma experiência, falando:

Em uma experiência que tive, o cliente afirmava que “garantindo que, em cada tela do sistema eu consiga Cadastrar, Consultar, Alterar e Deletar, já posso garantir que alguma coisa funciona”. Essa foi a primeira meta colocada pelo cliente para a automatização.
Buscando entender o motivo, fizemos uma busca pelo sistema de chamados da empresa. E um grande número de chamados de cliente eram de relamação de defeitos nestes pontos.
O Ambiente era um ERP com mais de 20 módulos integrados.
Sobre o assunto, o que acho estranho, é que sempre que falamos sobre automação, alguém vem defender os testes manuais. Automação não exclui os testes manuais, aliás, um dos objetivos de automatizar os testes funcionais, é justamente para poder ter tempo para fazer outros testes, afinal não testamos apenas para garantir a “funcionabilidade” dele, há outras cinco características que poderão ser bem importantes para o sistema.
O Luiz Gustavo acredita que a necessidade de automação dos testes funcionais depende de vários fatores: 

De maneira geral:

– Da rotina dos testadores

– Do conhecimento sobre automação da equipe de testes

– Da tecnologia do sistema

– Da ferramenta de automação a ser utilizada (por isso é aconselhável estudar os benefícios de cada ferramenta antes de aplicá-la, sendo assim, não existe ferramenta “ideal” ou “melhor”)

– Do orçamento do projeto

– Se os prazos estão apertados (se não, é melhor fazer os testes manualmente, por motivos óbvios)

– Se possui um ambiente de testes dedicado

Mais especificamente:

– Se as funcionalidades a ser testadas se repetem (Regression Testing)

– Do esforço necessário para preparação do ambiente de testes (a massa de dados pode ser toda amarrada via Regras de Negócio, e isso dá um trabalhão…)

– entre outros.

Para o Fermiano talvez ela não seja necessária, mas pode ser uma possibilidade a ser considerada:

Eu não diria que a automatização de testes funcionais é necessária, mas a atenção para essa possibilidade sim.

Estamos sempre atentos para essa possibilidade, mas os fatores já citados aqui indicam que os testes manuais são mais eficazes e eficientes para a maioria dos casos. Automatizamos sim, mas é uma pequena fração da totalidade dos testes.

Exemplo: Numa etapa da fase de validação usamos um roteiro de testes para os testes de regressão. Esse roteiro possui aproximadamente 200 situações complexas de testes a serem executados, necessitando aproximadamente de 5 dias para ser completado (execução e verificação dos resultados). Não é raro alguém perguntar quando teremos 100% desse roteiro automatizado. A realidade é que apenas 30%, no máximo, desse roteiro poderá ser automatizado.
O Felipe Silva deu a sua contribuição dizendo:
A necessidade automatizar ou não vai do jeito em que as coisas são conduzidas em cada projeto, por exemplo no meu projeto trabalhamos tão corrido que enquanto estamos testando a release atual já estamos estimando e criado cenários e casos de testes para a próxima release, se alguém fosse parar para automatizar regression a próxima release iria atrasar, e as regras mudando toda release, em outras palavras o que chamamos de regression “hoje” tá mais pra “coisas que restaram da release passada”, não conseguimos nem manter os TCs que são super pequenos e nada detalhados, quem dera manter atualizados scripts, aqui vale mais a pena automatizar alguns procedimentos genéricos do que automatizar validações.
Mas tem empresas também em que as pessoas ficam focadas em uma release só, e acompanham o projeto desde a fase de requisitos até a homologação, enquanto os devs nem escreveram os códigos eles tem tempo para fazer um monte de coisa, quando é assim é, se o FW é conhecido é possível até automatizar desde o ciclo 1 paralelamente a implementação (aqui sim vejo ganho na automatização), então assim que a primeira build é gerada deixa-se uma maquina dedicada rodando os scripts dia e noite (se possível em integração contínua), e os testers seguem suas vidas normalmente em suas 8hs diárias executando os testes “pente fino” manuais. Pensando nisso, na release 2 os scripts das funcionalidades da release 1 já estariam lá, então novamente paralelamente a criação do código da release 2 iriam criar os scripts da release 2, se alguma coisa da release 2 quebrar alguma coisa da release 1 espera-se que os scripts da release 1 achem isso enquanto os testers estão focados na release 2. 

Não tenho como ser genérico em tirar uma conclusão geral que automação de testes funcionais em ciclos de regressão sempre são viáveis.

Testes sustentáveis, o que raios é isso?

No início da discussão coloquei que a automação dos testes funcionais é muito importante para se testar de forma sustentável, pois é muito difícil garantir a qualidade de um sistema apenas com testes manuais.

O Shmuel fez considerações pertinentes sobre essa minha colocação, que me fizeram explicar melhor o que seria testar de forma sustentável.

Primeiramente, testes sustentáveis são importantes para podermos garantir a qualidade do sistema a longo prazo. Pois pode ocorrer de precisarmos de esforço X para testar o sistema, no início do desenvolvimento, e 2X para testar o sistema nas etapas finais de desenvolvimento, cenário esse que revela que algo pode estar errado.

Testar de forma sustentável serial algo como testar de forma eficiente, ou seja, com o mínimo de esforço e o máximo de eficiência.

Ou melhor, testar de uma forma que fosse possível garantir um bom nível de qualidade, ao longo de todo o projeto, buscando investir um esforço sempre parecido. Ou seja, garantir a qualidade tanto quando o sistema tem apenas 2 funcionalidades, como quando ele tem 50.

Para tentar explicar o “conceito”: imagine que estamos no ano de 2006 e você trabalha no Google, mais precisamente na célula de desenvolvimento do Google Docs. Como todos sabem, o Google Docs é uma ferramenta que teve o seu desenvolvimento de forma incremental, e você como incubido de testar ele. Você precisará fazer vários testes a cada nova versão, sendo que boa parte destes testes, já foram feitos antes.

Se você fosse testar sempre de forma manual, acabaria entrando numa rotina, que sempre teria mais e mais testes para executar e isto com certeza iria impactar no projeto, uma vez que ou você necessitará de mais pessoas para te ajudar ou o prazo para a entrega será sempre maior, afinal a cada lançamento você terá mais testes para fazer.

Mas você é o Shmuel, uma pessoa consciente e que sabe da importância da sustentabilidade para o Teste de Software, por isso já em 2006 percebe que boa parte dos testes podem ser automatizados, e isso iria aliviar bastante o seu trabalho e você teria tempo para fazer outros testes mais complexos, que poderiam obter novas informações e que necessitariam de análises que um computador não consegue fazer (por exemplo, testes de usabilidade).

A ideia de sustentável seria essa. Meio viajante eu sei, e muito bonita na teória.

Você estuda a viabilidade de automação e planeja, ou simplemente ‘põe a mão na massa’?

O Juraci respondeu dizendo:

Eu estudo sim a viabilidade para cada caso de teste, em um projeto eu tenho casos de teste candidatos a automação. São aqueles repetitivos que serão utilizados em uma futura regressão, testes massantes tais como o mencionado anteriormente, testes que revelaram falhas no software também são candidatos pois mostram o seu valor durante o teste de regressão. Vale destacar que o caso de teste é a base para a automação, é o requisito do “sotftware/aplicativo/script” que será o produto da automação, não adianta ‘colocar a mão na massa’ sem ter os casos de teste bem definidos, pois isto equivale a ter um requisito fraco e que irá acarretar em muito mais transtorno como foi comentado.

O Ferminiano também fazer um estudo antes:

Sim, fazemos um estudo de viabilidade de automatização. Sempre aparece alguém querendo automatizar alguma coisa, pensando que basta apertar um uma tecla e pronto, como já disseram aqui na lista. Um breve estudo de viabilidade mostra que apenas algumas poucas vezes isso é possível.

Bem pessoal é isso, espero que tenham gostado do resumo, que mesmo atrasado não poderia faltar, pois essa discussão foi excelente, aliás, se você quiser saber mais, acesse o link para a página do DFTestes com a discussão na íntegra. 😉

O melhor da semana 26/09 a 02/10

Pessoal,

Segue abaixo, a lista com o melhor da semana. Destaque para o post do Cássio Marques, onde ele mostra bem as razões para um desenvolvedor testar.

Conhecimento a um clique, esse é o QualidadeBR. 🙂

Abraços! E tenham uma ótima semana!

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