quinta-feira, 12 de setembro de 2013

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/

segunda-feira, 19 de agosto de 2013

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.

quinta-feira, 1 de agosto de 2013

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!



terça-feira, 16 de abril de 2013

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/

quarta-feira, 6 de março de 2013

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.

terça-feira, 5 de março de 2013

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.