Gostaria de uma ajuda, pois sou novo na área de TI e atualmente trabalho em uma empresa do ramo. Solicito uma ajuda em relação a questão prática do Teste de Software, pois estou estudando para a prova do BSTQB…na questão teórica está legal, porém vou ser sincero, funciono muito na prática.
Se alguém puder ajudar com algum material, eu agradeceria muito.
Como começar? Pelos testes. Aliás Java já deveria ser ensinado começando com testes como faz o livro de 2005 Agile Java, Crafting Code with TDD
Como testar? Dois bons livros sobre isto: TDD by example e Growing Object Oriented Software Guided by Tests. Outro livro ótimo: JUnit in Action 2nd Edition
O que utilizar nos testes? JUnit, Hamcrest, Mockito, Selenium, DBUnit, Hudson ou Go (cruise control) e outras coisas como easyb (ou JDave), Concordion (ou Cucumber)… aqui o campo é vasto.
O mais importante é (vou até grifar): esquecer tudo que aprendeu ou que alguma “autoridade certificadora” pretende ensinar sobre testar software depois de pronto
Nenhum QA deve esperar uma funcionalidade ficar pronta para iniciar os testes. O cara de QA deve ser da equipe de desenvolvimento ou trabalhar junto a ela sem que em hipótese nenhuma exista algum tipo de antagonismo.
É uma certificação de nível fundamental destinado a qualquer pessoa envolvida em testes de software. Isto inclui as pessoas em papéis como Testadores, Analistas de Testes, Engenheiros de Testes, Consultores de Teste, Gerentes de Teste, Aceitação e Desenvolvedores de Software.
Esta certificação também é adequada para quem quer um entendimento básico de teste de software, tais como Gerentes de Projeto, Gerentes de Qualidade, Gerentes de Desenvolvimento de Software, Analistas de Negócios, Diretores de TI e Gestores.
Os possuidores da certificação CTFL serão capazes de ascender para níveis mais elevados de qualificação de testes de software pelo ISTQB.
É preciso fazer este exame mediante a curso preparatório para exercer as funções mencionadas acima
Como começar? Pelos testes. Aliás Java já deveria ser ensinado começando com testes como faz o livro de 2005 Agile Java, Crafting Code with TDD
Como testar? Dois bons livros sobre isto: TDD by example e Growing Object Oriented Software Guided by Tests. Outro livro ótimo: JUnit in Action 2nd Edition
O que utilizar nos testes? JUnit, Hamcrest, Mockito, Selenium, DBUnit, Hudson ou Go (cruise control) e outras coisas como easyb (ou JDave), Concordion (ou Cucumber)… aqui o campo é vasto.
O mais importante é (vou até grifar): esquecer tudo que aprendeu ou que alguma “autoridade certificadora” pretende ensinar sobre testar software depois de pronto
Nenhum QA deve esperar uma funcionalidade ficar pronta para iniciar os testes. O cara de QA deve ser da equipe de desenvolvimento ou trabalhar junto a ela sem que em hipótese nenhuma exista algum tipo de antagonismo.
[]s
Luca[/quote]
Hummm, vou dar uma pesquisada nos livros e softwares citados então o “melhor” (aconselhado) é fazer os testes ao mesmo tempo que o desenvolvimento?
Sem sombra de dúvida. Talvez esta seja a maior certeza de como desenvolver software e a prática de desenvolvimento que seja recomendada pelo maior número de especialistas.
Não tenho idéia do que seja a tal certificação BXPTIOQPSEILÄOQUÊ, mas se não recomenda este prática então é coisa para se passar longe.
Acho que mais importante do que o momento do teste é tê-los automatizados.
Testes automatizados ajudam muito mais, principalmente se considerarmos TODO o ciclo de vida do software.
Automatize e teste continuamente seu software. [/quote]
Discorda de quem? De mim que sou adepto de tudo automatizado desde o primeiro teste de aceitação que segundo o GOOS é a primeira coisa a ser escrita no software desde a estória do usuário até o deploy em produção tal como recomenda o livro Continuous Delivery? Ou discorda da necessidade de alguém certificar-se em testes?
Eu discordo da necessidade de existir “Testadores, Analistas de Testes, Engenheiros de Testes, Consultores de Teste, Gerentes de Teste” como personagens separados. Ou será que precisa ter um cargo de nome pomposo como “engenheiro de testes” para interpretar os resultados da integração contínua?
Uma coisa muito importante em um ambiente de desenvolvimento que tem a ver com o modo como será feita o tal deployment em produção com apenas um clique é como se usa o sistema gerenciador de controle de versões. Tudo deve ficar nele, inclusive os scripts dos bancos de dados e scripts de deployment nos diversos ambientes (desenvolvimento, “homologação” e produção).
Hoje em são tantas as coisas necessárias para se aprender a desenvolver software confiável de qualidade (que realmente atenda às necessidades do cliente) dentro do prazo que não imagino como ainda sobra tempo para alguém tentar se certificar em uma coisa que deve ser o modo natural de fazer as coisas. Para mim seria igual a me certificar de que como arroz com feijão. E sem precisar de um engenheiro para determinar como segurar o talher e muito menos um gerente para conferir.
Não fui claro no que escrevi - Discordo da discussão. Mais importante do que discutir quando é melhor testar é saber que os testes são automatizados e DE BOA QUALIDADE (e como saber se o teste tem qualidade?).
Outro ponto importante é não assumir TDD (ou testes antes) como a solução de todos os males. Eu gosto muito do assunto e acredito nas vantagens que ela pode trazer, mas isso deve ser avaliado caso a caso e, mais importante, devemos estar preparados para situações onde isso não é uma realidade como por exemplo um projeto “Brown field”/suporte/etc.
Resumindo, concordo sim que esse é o melhor caminho mas temos que ter cuidado ao assumir como A solução.
Ps: Qual ambiente vc usa? Estive fazendo experimentos com Hudson, Junit, Emma e SeleniumHq e achei que os resultados foram bem legais.
Na última semana de agosto deve sair o livro Continuous Delivery lotado de idéias sobre como construir um ambiente em que se pode fazer deploy na produção com um simples click. Sábado passado li o que tem a mostra dele em SafariBooks (tem muitas páginas faltando).
Acho que será um livro muito bom para todos os times. O livro aborda o que você escreveu e mais algumas outras coisas que provelmente você também usa e outras que eu não sei se dá certo em todos os casos como usar virtualização para reproduzir ambiente de produção.
Ainda acho melhor gastar dinheiro com um livro deste (40 dólares + frete) do que pagar uma certificação
Na última semana de agosto deve sair o livro Continuous Delivery lotado de idéias sobre como construir um ambiente em que se pode fazer deploy na produção com um simples click. Sábado passado li o que tem a mostra dele em SafariBooks (tem muitas páginas faltando).
Acho que será um livro muito bom para todos os times. O livro aborda o que você escreveu e mais algumas outras coisas que provelmente você também usa e outras que eu não sei se dá certo em todos os casos como usar virtualização para reproduzir ambiente de produção.
Ainda acho melhor gastar dinheiro com um livro deste (40 dólares + frete) do que pagar uma certificação
[]s
Luca[/quote]
Bem interessante o livro, com certeza foi pra minha lista. Não compro agora porque acabei de pedir o JUnit in action, segunda edição, que ainda está em pré-venda, caso alguem queira aproveitar.
Concordo com o Luca, teste bom é feito no dia-a-dia e é automatizado.
Esse certificado CTFL é indicado para as pessoas que desejam escrever scripts de teste em arquivos .doc, simples assim. É um certificado meia boca e que não serve para nada.
Cheira a merda, simples assim.
E mais: enquanto as pessoas derem mais valor para essas letras CTBTAL, CTBL, etc e menos valor para o "Olha, eu leio código de terceiros e entendo, costumo ler para aprender, tenho ciência de que programar é como artesanato, a gente aprende praticando e observando. ", a produção de software vai ser uma cáca.
Nota: conheço duas pessoas que possuem essa certificação, nenhuma delas sabe o mínimo necessário para fazer qq software.