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

Instruções para relatar defeitos do CrowdTest

Relatar defeitos é uma atividade rotineira para testadores. Nem sempre quem está começando consegue relatar com precisão uma falha.

Existe algumas documentações que ajudam nesse sentido. Gosto de sempre reler os guias do CrowdTest para me atualizar sobre as técnicas usadas nesse sentido.

Vale a pena conferir:

http://crowdtest.me/issues_guide?utm_source=mailmarketing&utm_medium=email&utm_campaign=projeto-buscapenahora

Nesse projeto foi orientado com o texto:

2. Instruções para o preenchimento do Formulário de Nova Ocorrência

2.1. Preenchimento do Título

O título deve ser capaz de dar uma ideia concisa e clara da ocorrência encontrada. O título da ocorrência deve permitir que outros testadores identifiquem se a ocorrência encontrada já foi registrada (evitando, assim, ocorrências duplicadas).

2.2. Preenchimento da Descrição

A descrição deve conter uma explicação detalhada da ocorrência encontrada.

2.3. Preenchimento dos Passos para reprodução

Os passos para reprodução devem ser bem detalhados e sem ambiguidades e redundância. Não assuma que determinados passos são óbvios e serão entendidos pelo revisor. Caso existam pré-condições para a reprodução da ocorrência, as mesmas devem ser detalhadas. Este campo deve ser utilizado para convencer de que a ocorrência existe e é reproduzível.
Coloque cada passo separado por marcadores. É mais simples de entender os passos quando estão com marcadores do que apenas texto.

• Acessar a “Tela de Cadastro de Usuários”;
• Não informar os campos obrigatórios;
• Clicar em [Salvar];

É melhor que...
“Acesse a tela de cadastro de usuário sem informar os campos obrigatórios e clique em salvar.”
Vale ressaltar que o vídeo com a evidência do problema não substitui a descrição do passo-a-passo do problema.

2.4. Preenchimento dos Resultados Esperados

Descrição do que é esperado após a execução dos passos e uma comparação com o que é atualmente exibido pelo sistema que difere do resultado esperado.

2.5. Preenchimento das Informações Adicionais

Detalhar qualquer outra informação que achar relevante para o entendimento da ocorrência relatada.

2.6. Preenchimento da Funcionalidade

Associar a funcionalidade correspondente à ocorrência encontrada.
Caso o testador veja a necessidade de inclusão de uma nova Funcionalidade em um projeto, deverá enviar um e-mail para crowd@crowdtest.com.br com o nome do projeto e o caminho onde a funcionalidade se encontra.

2.7. Preenchimento do Tipo

Associar o tipo da ocorrência encontrada de forma correta e que caracterize realmente o tipo da ocorrência. A seguir são descritos cada tipo de ocorrência:

Tipo	Descrição
Impeditivo	Ocorrência que impede o uso do sistema. Não existe forma de contorná-la. Exemplo: Ao clicar em um botão, o sistema trava e para seu funcionamento.
Funcional	Ocorrência não impeditiva relativa ao funcionamento do sistema. Uma ocorrência que pode ser contornada pelo usuário do sistema. Exemplo: Ao clicar no botão “Limpar”, o campo não é limpo.
Segurança	Ocorrência que compromete a segurança do uso do sistema. Exemplo: acesso a senhas de segurança, dados pessoais de usuários, etc.
Interface	Ocorrências relativas à interface, como problemas de renderização, cores, etc. Exemplo: O Label de um botão aparece deslocado, fora da área do botão.
Texto	Qualquer ocorrência relacionada ao uso incorreto de algum idioma.
Melhoria	Sugestões de melhorias para o sistema.

Vale ressaltar que nem todos os tipos de ocorrências estarão presentes em todos os projetos. Por exemplo, pode ocorrer de em um projeto só poderem ser registradas ocorrências funcionais.

2.8. Preenchimento do Navegador

Selecionar o navegador no qual a ocorrência aconteceu. Fiquem atentos aos tipos de navegadores autorizados para testes em cada projeto.

2.9. Preenchimento do Sistema Operacional

Selecionar o S.O. no qual a ocorrência aconteceu. Fiquem atentos aos sistemas operacionais autorizados para testes em cada projeto.

2.10. Preenchimento dos Anexos

Os anexos podem receber qualquer tipo de arquivo, mas o principal uso deles é para evidenciar a ocorrência. As evidências das ocorrências são obrigatórias para todos os tipos, exceto as melhorias.
Para evidenciar podem ser anexados print screens ou vídeos. Utilize arquivos com formatos comuns (e.g. MP4, AVI, WMV, PNG, JPG, GIF) e que não exijam a instalação de um software particular para serem visualizados.
Podem ser utilizados serviços de hospedagem de vídeos na Internet, caso o limite de upload não seja suficiente.
Vale ressaltar que a inclusão de anexos não elimina a necessidade de preencher os demais campos com o detalhamento esperado.

CrowdSim software de teste de evacuação de emergência

Alunos da PUC-RS desenvolveram um software que faz teste em situações de evacuação de áreas públicas em caso de emergência. Chama-se CrowdSim, essa ferramenta de modelagem e animação 3D testa como seria uma situação de tumulto ou momentos de pânico.

Como resultados pode simular situações com baixo custo e nenhum risco. Os resultados dos testes existe uma informação para influenciar na tomada de decisão da instalação de saídas de emergência ou câmeras.

Esse teste achei interessante e importante para aprimorar a segurança de estruturas públicas.

Fonte: http://tecnologia.terra.com.br/noticias/0,,OI6314449-EI15607,00-Software+simula+evacuacao+de+locais+com+multidao.html

Automação de tarefas de interface de usuário com Autoit

Quando comecei na área de teste, precisava de algumas tarefas automatizadas de interface de usuário, como não tinha-mos dinheiro para comprar ferramentas optei por ferramenta freeware. Conheci o Autoit3 que desempenha um papel interessante na automação de UI (user interface).

Endereço: http://www.autoitscript.com/site/autoit/

AutoIt3 é uma ferramenta freeware de linguagem script de formato BASIC desenhado para automatizar tarefas de interface com usuário Windows e de uso geral. Esta ferramenta usa uma combinação de simulações em teclas, movimentos do mouse, manipulação e controle de janelas a fim de automatizar tarefas em uma forma não possível ou fiável com outras linguagens (exemplo VBScript e SendKeys). AutoIt é também muito pequena, auto-suficiente e roda nas versões regulares do windows até hoje, sem exigir problemas em tempo de execução.
O conceito da ferramenta é usar coordenadas na tela para cliques do mouse, sendo as coordenadas relativas a janela ativa ou não, enviar comandos do teclado e ativar janelas de acordo com o nome.

Na minha opinião é uma forma de iniciar em automação de testes com baixo custo e razoavel produtividade.

Um case que vi foi a automação completa do roteiro do PAF-ECF. Onde não era exclusivamente automatizada mas, serviu como guia nas operações e validações do roteiro. Esse roteiro tinha aproximadamente 120 testes e deveria ser feito na sequência.

Para quem não tem nenhum processo automatizado, eu sugiro que conheça o Autoit e veja se consegue aproveitar algum recurso dessa ferramenta nos seus testes. A primeira coisa que eu automatizei com autoit foi entrar na aplicação (informar usuário e senha), já uma economia de tempo sendo que todos os dias eu tinha que digitar sempre o mesmo usuário/senha.

Automação de teste é assim, se já te ajuda nas tarefas diárias a automação pode valer a pena.

Google torna a Octane um projeto open source

Google torna a Octane um projeto open source

Testes feitos em navegadores agora podem ser aprimorados pela comunidade com essa abertura.

Projeto hospedado em: http://code.google.com/p/octane-benchmark/

Estou seguindo o projeto. Achei interessante a comparação do rendimento dos navegadores.