Creio que é extremamente importante saber o que meus colegas estão aprendendo também. Isso nos dá uma visão não só de aprendizado mas também de mercado.
- Aprendi que QAs devem ir fundo no paradigma funcional, logo estou estudando Erlang e pretendo estudar Elixir
- Aprendi utilizar AspectJ nos testes (Selenium+JUnit)... testadores também devem saber o básico da programação
- Estou aprendendo a usar a ferramenta TestLink
- Aprendi um pouco sobre teste de performance, usando o NeoLoad, o SilkPerform e na batalha com o JMeter
- Aprendendo Robotium
- Aprendi TestLink e execução de Query's
- Model cheking com LTSA graças a cadeira de VeV na minha faculdade
- Aprendendo sqlmap para usar nos testes de segurança
- Aprendi a usar Selenium WebDriver com Python (minha linguagem do coração :) )
- Aprendi e apliquei técnica de automação de escrita de caso de teste com data driven
- Aprendi Scrum, Kanban, Lean e Agile
- Aprendi e implantei Jira e Greenhopper para Agile
- Aprendi e implantei Continuous Integration e Continuous Deploy em PHP com GIT, AWS
Analisando as respostas podemos perceber algumas coisas bem interessantes:
- Muitos testers estão aprendendo ferramentas de automação. Isso indica que eles já estão preocupados em estar no mesmo fluxo que o mercado que quer uma entrega/repsosta mais rápida
- Alguns testers já estão aprendendo sobre itens não funcionais em teste de software, e isso prova que não é somente de teste funcional que se vive de teste de software
- Que alguns testers estão entrando num contexto ágil, aprendendo coisas além do assunto especifico sobre teste de software
E vocês leitores, o que aprenderam com teste de software?
Eu aprendi que os testadores não necessariamente precisam ser especialistas em determinados ramos de negócios, e que o mesmo deve sempre trabalhar em cima de Entrada, Processamento e Saída. E dessa forma este será capaz de testar qualquer coisa.
ResponderExcluirE hoje eu acredito que os testadores saíram dessa caixinha “O teste” hoje somo uns verdadeiros profissionais de requisitos, porque em muitos casos pegamos 3 linhas de informação e a parti disso temos que levantar toda uma gama de requisitos de testes para montar um plano.
E concordo plenamente quando você (Elias Nogueira) diz: Nem só de teste funcional vive o teste de software!
Eu aprendi que os testadores não necessariamente precisam ser especialistas em determinados ramos de negócios, e que o mesmo deve sempre trabalhar em cima de Entrada, Processamento e Saída. E dessa forma este será capaz de testar qualquer coisa.
ResponderExcluirE hoje eu acredito que os testadores saíram dessa caixinha “O teste” hoje somo uns verdadeiros profissionais de requisitos, porque em muitos casos pegamos 3 linhas de informação e a parti disso temos que levantar toda uma gama de requisitos de testes para montar um plano.
E concordo plenamente quando você (Elias Nogueira) diz: Nem só de teste funcional vive o teste de software!
Excelente.
ResponderExcluirAcho que a ideia principal é que sempre precisamos estar aprendendo coisas novas para atender novos desafios.
No momento estou no desafio de quebrar o paradigma do processo tradicional para o ágil e com certeza os livros que estou lendo estão me ajudando muito com essa nova realidade.
Essa primeira resposta é a cara do Camilo Ribeiro (http://www.bugbang.com.br/)
Além do que foi citado, tenho aprendido como é importante ter processos de qualidade definidos, não só no teste de software em si, mas na qualidade de código e deployment, por exemplo.
ResponderExcluirAlém disso, que outro grande papel do analista de QA ou de Teste é conscientizar e mostrar aos desenvolvedores o quanto é importante que eles desenvolvam plenamente conscientes do que estão fazendo e que não é só porque alguém vai testar depois que eles podem fazer qualquer coisa.
Além do que foi citado, tenho aprendido como é importante ter processos de qualidade definidos, não só no teste de software em si, mas na qualidade de código e deployment, por exemplo.
ResponderExcluirAlém disso, que outro grande papel do analista de QA ou de Teste é conscientizar e mostrar aos desenvolvedores o quanto é importante que eles desenvolvam plenamente conscientes do que estão fazendo e que não é só porque alguém vai testar depois que eles podem fazer qualquer coisa.