Aprender sobre automação e contribuir com projeto

Buscando projetos para serem testados achei uma comunidade vibrante da mozilla. Eles distribuem alguns projetos e códigos python para quem quiser ajudar.

Tem conhecimento em Selenium e/ou Python? Contribua você também, todos tem a ganhar.

Fonte:
https://quality.mozilla.org/docs/webqa/projects/automation/

Por que precisamos de teste de unidade?

Fonte: http://tshooter.com.br/2013/08/02/porque-voc-definitivamente-precisa-de-testes-de-unidade/

O texto do Igor demonstra 5 pontos em que a equipe tem a ganhar ao utilizar testes de unidade em seus códigos, são eles:

1. Codificar com testes de unidade em mente obriga-o a pensar sobre o design e a arquitetura de seu código – o que faz com que ele se torne um código melhor
2. Testes de unidade fornecem feedback imediato – todas as alterações no código são testadas (pelo menos em parte) à medida que você codifica.
3. Um pequeno investimento agora leva a uma enorme economia mais tarde – bugs em produção custam muito mais do que bugs em desenvolvimento
4. Testes de unidade fornecem métricas para a qualidade do seu código
5. Testes de unidade trazem qualidade inerente às suas implantações (releases)

Esses argumentos são muito importantes ao iniciar testes de unidade na equipe, é preciso tentar obter esses resultados se desejar obter melhorias. Com certeza o andamento das releases vai melhorar, ter esse foco faz com que as dificuldades sejam enfrentadas e chegue ao objetivo. Como aprender uma coisa nova é desgastante não ter resultado de imediato, mas haverá ganhos se houver persistência. Claro que é necessário conhecer muito bem a equipe que está trabalhando e seu contexto.

No artigo existe experiências ricas em dificuldades e soluções encontradas. Boas equipes despertam essas experiências, a evolução em minha opinião é mais válida para manter a estabilidade do que uma revolução. Você pode tentar impor testes de unidade em sua equipe, mas se houver um aprendizado paulatino e constante acredito que a dor seja menor.

Manhas de SQL injection

Nessa Semana Troy Hunt publicou coisas sobre SQL injection e estou reblogando no teste importa.
Endereço:
http://www.troyhunt.com/2013/07/everything-you-wanted-to-know-about-sql.html

Nesse post o autor explica algumas manhas de capturar dados do servidor através das requisições.

Para expandir as alternativas de teste é relevante extrair os conceitos por ele colocado. Claro que nem todos utilizam SQL Server e ASP.net, mas os conceitos com certeza pode ser validos em outros ambientes.

Boa leitura!

Testing Dojo Brasil

Já esta no ar o site Testing Dojo Brasil http://testingdojo.com.br.

Programadores utilizam Coding Dojos para exercitar suas habilidades de programação em grupo. Eles se reúnem para programar em pares e receber feedback de seus colegas. Mas a idéia do Testing Dojo é fornecem uma configuração similar aos Dojos de programação, mas ajudam os testadores a praticar suas habilidades individuais em um grupo. Mais detalhes no Site.

O testingdojo está organizando um grupo, com pessoas interessadas a organizar os dojos, em todas os estados do brasil, caso tiver interesse é só entrar no site divulgar e se inscrever. Vamos lá criar essa comunidade.

Fonte: http://testingdojo.com.br

Reblogado de: http://testersoftware.blogspot.com/

Internacionalização colaborativa

A ideia de colaboração realmente deve invadir o desenvolvimento de software. Para sistemas que são mundiais é interessante ter um processo eficaz de internacionalizar a linguagem do software.

Descobri hoje que o sistema de compressão de arquivos B1 é desenvolvido sobre o framework Crowdin, uma excelente ferramenta para que deseja internacionalizar colaborativamente.

Teste de Usabilidade deve ser o foco?

Segundo o autor do texto http://blog.utest.com/which-comes-first-functional-or-usability-testing/2013/02/ a usabilidade deve vir primeiro.

Na minha opinião podemos fazer o sistema com qualdiade, do núcleo para a interface ou o contrário, desde que a equipe esteja comprometida com o resultado.

Se a arquitetura do cerne do sistema estiver em boas condições as mudanças na interface pode ocorrer até para plataformas distintas.

Os testes determinar como o sistema se comporta

Onde eu trabalhava, a equipe de teste gerava os casos de teste e ninguém mais utilizava esse artefato, em eventos de teste aprendi sobre uma abordagem em que os casos de teste poderia ser reutilizado, por exemplo por uma equipe de suporte ou consultores técnicos. Isso seria bom para  os testes, mais validação dos artefatos resulta em melhor qualidade.

Então comecei um estudo sobre BDD e processo de aceitação. Mas no contexto que estava não podia implantar mudanças tão radicais assim, não tinhamos nada de aceitação de software.

Abordagem em que os testes determinam como o sistema se comporta, nem sempre precisa usar BDD ou ATDD ou qualquer outro conceito por completo. A maneira que pude usar foi adaptando os conceitos de criação dos casos de teste e as validações feitas sobre o artefato gerado.

Ainda tenho bastante coisa para estudar e aprender a adaptar, conceitos de BDD estou já familiarizado, o próximo passo será estudar Specification by example. Colocarei em breve os estudos que conseguir.

No momento posso passar o trabalho que fiz para a faculdade onde tem uma bibliografia para conseguir uma base de conhecimento.

Trabalho está em: https://github.com/ptcmariano/Acceptanceit

Pergunta no grupo:
http://br.groups.yahoo.com/group/testadores/message/836


Keyworkds:
caso de teste determinar o comportamento
estudos sobre BDD e automação de teste