Evento - TDC 2012 - Florianópolis


Nos dias 24, 25 e 26 de agosto acontece o evento The Developer's Conference em Florianópolis. O evento é dividido em 7 trilhas por dia, num total de 21 trilhas com assuntos diferentes, além das trilhas Stadium que são uma seleção de palestras das trilhas do dia e acontece num auditório. As inscrições pelo valor de R$ 40,00 encerram hoje.
Ano passado eu participei da trilha de testes, e foi muito interessante. Aprendi muita coisa nova, conheci muita gente disponível para trocar conhecimento, e foi o que me motivou a criar o blog.



Informações sobre o evento:

Como é uma trilha ?
Cada trilha na agenda do evento é realizada em uma sala e tem um dia inteiro de palestras. As trilhas Stadium são um mix de todas as trilhas do dia, são realizadas no auditório principal e abertas para que todos inscritos no evento possam aproveitar um pouquinho das outras trilhas.
O que são as trilhas University ?
As trilhas University são destinadas a estudantes e profissionais que estão iniciando na tecnologia discutido na trilha. As palestras têm nível mais introdutório, foco educacional e sempre que possível prático. Para que os participantes possam encerrar o dia com sentimento de aprendizado e ainda mais motivados.
Especial para estudantes
Estudante com carteira de estudante e aluno da Globalcode paga meia nas trilhas University!
Antes de fazer sua inscrição, é necessário solicitar seu código promocional enviando cópia de sua carteira de estudante para tdc@globalcode.com.br. Não faremos devolução após a inscrição feita.
E para quem quiser palestrar, basta clicar aqui e submeter as informações sobre a palestra.



Estudando para a Certificação CTFL - Quarto Capítulo Parte II

Continuação do resumo do quarto capítulo do syllabus CTFL.

Técnicas baseadas em estrutura ou caixa-branca


Nível de componente
- A estrutura é o próprio código.

Nível de integração
- A estrutura pode ser uma árvore de chamadas.co

Nível de sistema
- A estrutura pode ser a estrutura da página.

Teste e cobertura de sentença
- A cobertura de sentença é avaliada pela porcentagem de sentenças executáveis por um conjunto de casos de testes;

Teste e cobertura de decisão
- Porcentagem dos resultados da decisão;

Gerenciamento do Teste

Os principais benefícios da independência da equipe de testes são:

- Imparcialidade;
- Enxergar defeitos;

Tarefas do Líder de Testes

- Planejamento, monitoração e controle;
- Coordernar estratégias de testes;
- Escrever ou revisar uma estratégia de testes;
- Planejas os testes;
- Preparar o gerenciamento de configuração do testware;
- Métricas para avaliar o progresso dos testes;
- O que pode ser automatizado;
- Relatório com base nas informações obtidas;

Tarefas de um Testador

- Revisar e contribuir no planejamento;
- Analisar, revisar os requisitos do usuário;
- Especificação de testes;
- Configurar o ambiente de teste;
- Implementar os testes em todos os níveis;
- Utilizar ferramentas (quando necessário);
- Automatizar testes;
- Rever testes desenvolvidos por outras pessoas;


Só para reforçar, os resumos são apenas para relembrar o que deve ser estudado no Syllabus.
;D


Estudando para a Certificação CTFL - Quarto Capítulo - Parte I

Resumo sobre o quarto capítulo do syllabus, que trata a respeito de técnicas de modelagem de testes.

Durante a modelagem são criados os casos de testes e os dados de testes. Os casos de testes devem possuir as seguintes informações:

- Valores de entrada;
- Pré-condições;
- Resultados esperados (devem ser definidos antes da execução dos testes);
- Pós-condições;

O padrão IEEE 829-1998 define a documentação.

Categoria das técnicas de modelagem de testes

Testes de caixa-preta
Nos testes de caixa-preta, a estrutura interna do sistema é desconsiderada. Testa-se apenas o que é visível ao usuário. Engloba tanto os testes funcionais como os não funcionais.


Testes de caixa-branca
O teste de caixa branca é baseado na estrutura interna do software. Pode ser chamado de teste de estrutura.

Técnicas baseadas em caixa-preta

Partição de equivalência
- As entradas do sistema são divididas em grupos que tenham um comportamento familiar;
- Pode ser um conjunto de dados válidos, ou dados inválidos (rejeitados pelo sistema);
- Aplicável a todos os níveis de testes;

Análise do valor limite
- Nos limites de uma partição de equivalência é onde existe maior probabilidade para identificar defeitos;
- Valores máximos e mínimos;
- Valores válidos e inválidos;
- Pode ser aplicada em todos os níveis de testes;

Tabela de decisão
- Podem ser usados para regras de negócio;
- As condições de entradas são declaradas como verdadeiro ou falso;
- Cada coluna possui uma regra de negócio que define uma única combinação que resulta na execução de ações;
- A tabela cria combinações que geralmente não foram exercitadas durantes os testes;

Teste de transição de estados
- Permite ao testados visualizar o software em termos de estado;

Teste de caso de uso
- O caso de uso possui pré-condições que precisam ser garantidas que funcionem;
- Casos de testes baseados em casos de uso facilitam na descoberta de defeitos durante a utilização do sistema no mundo real;

Estudando para a Certificação CTFL - Terceiro Capítulo

Resumo do terceiro capítulo do syllabus, referente a técnicas de testes estáticos.

Os testes estáticos não pressupõem a execução do sistema. Podem ser manuais, revisões em documentações, ou automatizadas através da análise estática.
A revisão pode ser realizada bem antes da execução dos testes dinâmicos. Quanto antes, no ciclo de desenvolvimento, for identificado o defeito, mais barato será para corrigir.

Benefícios da revisão:
- Detecção e correção antecipada de defeitos;
- Redução do tempo no desenvolvimento;
- Redução do custo e tempo de teste;
- Menos defeitos;
- Melhoria na comunicação;

Processo de revisão

Planejamento
- Definir critérios de revisão;
- Selecionar equipe;
- Alocar funções;
- Definir critérios de entrada e de saída;
- Selecionar quais partes do documento serão revisadas;
- Checar critérios de entrada;

Kick-off
- Distribuir documentos;
- Explicar os objetivos;

Preparação individual
- Análisa da documentação;
- Anotar os defeitos em potenciais, questões e comentários;

Reunião de revisão
- Discussão ou registro, com resultados documentados;
- Anotar os defeitos e fazer recomendações para o tratamento de defeitos;
- Examinar, avaliar e registrar questões durante a reunião;

Retrabalho
- Resolver defeitos encontrados, tipicamente feitos pelo autor;
- Registrar os status atuais dos defeitos;

Acompanhamento
- Checar se os defeitos foram encaminhados;
- Obter métricas;
- Checar os critérios de saída;

Tipos de revisão

Revisão informal
- Pode haver programação em pares ou um líder técnico revisando a modelagem e o código;
- Documentação opcional;
- Dependendo do revisor, a importância pode variar;
- Principal propósito: Uma forma de obter algum benefício a baixo custo;

Acompanhamento
- A reunião é conduzida pelo autor;
- Cenários, grupos de discussão e exercícios práticos;
- Sem restrição de tempo;
- Opcionalmente há um redator;
- Pode variar de informal para formal;
- Principal propósito: aprendizagem, obtenção de entendimento e encontrar defeitos;

Revisões técnicas
- Documentado;
- Processo de detecção de defeitos;
- Idealmente deve ser conduzido por um moderador;
- Preparação dos revisores;
- Elaboração do relatório de revisão, contendo informações sobre a lista de defeitos encontrados, se o software corresponde aos requisitos;
- Pode variar de informal para formal;
- Principais propósitos: discussão, avaliar alternativas, encontrar defeitos, resolver problemas técnicos e checar a conformidade;

Inspeção
- Conduzida pelo moderador;
- Análise por pares;
- Utilização de métricas;
- Processo formal baseado em check-list;
- Entradas especificadas e critérios de saída para a aceitação do produto;
- Acompanhamento formal;
- Principal propósito: encontrar defeitos;

Análise estática

- Encontrar defeitos no código fonte do software e na modelagem;

Benefícios
- Detecção de defeitos antes da execução do teste;
- Identificação de defeitos dificilmente encontrados por testes dinâmicos;
- Prevenção de defeitos se as lições forem aprendidas pelo desenvolvimento;

Defeitos mais comuns descobertos por ferramentas de análise estática:
- Referências a uma variável com valor indefinido;
- Código morto;
- Inconsistências entre as interfaces dos módulos e componentes;
- Vulnerabilidade na segurança;

Ferramentas de análise estática são tipicamente usadas por desenvolvedores.


Estudando para a Certificação CTFL - Segundo Capítulo

Continuando os resumos do syllabus para a CTFL:

O segundo capítulo aborda informações sobre os níveis de testes, tipos de testes e teste de manutenção. Abaixo, segue uma breve descrição e resumo sobre cada item:

Níveis de Testes

Teste de Componentes
- Os testes de componentes ocorrem com acesso direto ao código;
- Verifica o funcionamento do software através de módulos, objetos, classes, e são testados separadamente;
- Envolve o desenvolvedor;
- A correção geralmente é realizada no momento da identificação do defeito, e não há documentação ou registros formais de incidentes;
- TDD (Test Driven Development);

Teste de Integração
- Testa-se a interface entre os componentes, interações de diferentes partes de um sistema;
- Testar a integração entre os diferentes componentes do software, e geralmente é realizado após os testes de componentes;
- Teste de integração para verificar as interações entre diferentes sistemas. Pode ser realizado após os testes de sistemas;
- Quanto maior o escopo de testes de integração, maior será a dificuldade para encontrar e isolar o defeito;

Teste de Sistema
- Refere-se ao comportamento de todo o sistema, definido pelo escopo do projeto;
- O ambiente de teste deve simular ao máximo o ambiente de produção;
- Podem ser baseados em: especificação de riscos, ou requisitos, processos de negócios e casos de uso;

Teste de Aceite
- Frequentemente é de responsabilidade do usuário;
- Estabelecer confiança no sistema;

Formas de teste de aceite:

- Teste de aceite do usário;
- Teste operacional de aceite;
- Teste de aceite de contrato e regulamento;
- Alfa e Beta Teste;

Tipos de Testes

Teste de função (teste funcional)
- Testes baseados nas funções descritas em documentos;
- Pode ser realizado em todos os níveis de teste;
- Considera o comportamento externo do software (caixa-preta);

Técnicas de teste funcional:

- teste de controle;
- teste de interconexão;
- teste paralelos;
- teste de requisitos;
- teste de regressão;
- teste de suporte manual;
- teste de tratamento de erros;

Teste de características do produto de software (testes não funcionais)
- É o teste de "como" o sistema trabalha;
- Pode ser realizado em todos os níveis de teste;
- Medir as características;
- Modelo de qualidade: ISO 9126

Técnicas de teste não funcional:

- teste de performance;
- teste de carga;
- teste de estresse;
- teste de usabilidade;
- teste de interoperabilidade;
- teste de manutenibilidade;
- teste de confiabilidade;
- teste de portabilidade;

Teste de estrutura (teste estrutural)
- Caixa-branca;
- Pode ser feito em todos os níveis de teste;
- Baseado na arquitetura do sistema;

Teste relacionado a mudanças (teste de confirmação e regressão)
- O teste de confirmação certifica que um defeito encontrado foi realmente resolvido e removido;
- Teste de regressão: teste repetido de um sistema, após sua modificação, para descobrir a existência de algum defeito que pode ser originado;
- Realizado quando o software ou ambiente é modificado;
- Forte candidato a automação;
- Podem ser realizados em todos os níveis de testes;

Teste de Manutenção

- Após o sistema ser desenvolvido e estar disponível em produção, o mesmo poderá sofrer manutenções periódicas, seja para acrescentar melhorias, ou para corrigir defeitos não detectados anteriormente;
- Além de ser testada a modificação realizada no software, o teste de manutenção inclui testes massivos de regressão;
- O escopo do teste está diretamente relacionado com os riscos que a versão de melhoria ou corretiva poderá causar;



Estudando para a Certificação CTFL - Primeiro Capítulo

Estou me preparando para a certificação CTFL - Certified Terster Foundation Level da ISTQB - International  Software Testing Qualifications Board, e pensei: por que não escrever no blog um resumo do capítulo que estou estudando? Pra mim, funciona muito bem a regra de aprender ensinando. Enfim, ao terminar de estudar cada capítulo, vou atualizar o blog, e com isso, espero poder ajudar quem está se preparando para a prova também. Como a minha memória é muito visual, eu vou usar esquemas para facilitar o entendimento.


As informações foram retiradas da apostila de certificação, versão 2011br.

Testes no Internet Explorer: Brace Yourself

Quando chega o momento em que é necessário iniciar os testes no Internet Explorer, essa é a minha reação:


Talvez eu esteja sendo injusta, afinal de contas, o IE está melhorando aos poucos nas versões mais recentes. Mas para desenvolvedores e testadores, o lançamento de versões pode ser a causa de trabalho dobrado, pois o layout pode funcionar na versão mais recente, mas na anterior pode ficar totalmente desconfigurado. O número de usuários que navegam pelo IE é consideravelmente alto, 56% ainda o utilizam. Além desse fato, é necessário considerar que muitos dos usuários demoram para atualizar a versão, então, não nos resta opção, a não ser testar o site em mais de uma versão do IE. Simples, não é mesmo? Não. Uma vez instalada a versão mais recente do nosso querido navegador, as anteriores são totalmente substituidas, obviamente. Uma primeira alternativa para ter acesso a várias versões do navegador seria através da máquina virtual e a outra alternativa seria instalar o IETester. 
O IETester é uma ferramenta free para Windows, que contém desde a versão 5 do Internet Explorer até a versão 9. No sistema, é possível abrir abas com todas as versões, e acessar o site a ser testado.




  




Mas para testes automatizados, há apenas a opção de máquina virtual.
Além de simular as várias versões do Internet Explorer, há ferramentas para o desenvolvedor, como por exemplo, visualizar o código fonte.
Você poderá realizar o download clicando aqui.

Usabilidade - Técnica de Observação

Olá pessoal,
A observação do usuário interagindo com o sistema é uma técnica muito eficaz quando existe a necessidade de melhorar a usabilidade de interação entre o usuário e o software.
É importante selecionar usuários com níveis de conhecimentos diferenciados, e principalmente, focar nos perfis de usuários que mais farão uso do sistema. Por exemplo, se o sistema será disponibilizado para consultas de produtos em supermercados, os perfis de usuários são abrangentes, mas provavelmente o público maior serão donas de casas que tem pouca familiaridade com tecnologia. Depois de definir os perfis dos usuários para a técnica de observação, é necessário preparar o ambiente. Certifique-se de que o sistema esteja funcionando corretamente, e garanta as condições necessárias para que a cobaia, ou melhor, o colaborador, possa se sentir a vontade. Outra etapa que pode ser incluída na preparação do ambiente é a elaboração de scripts contendo tarefas. Com os scripts elaborados é mais fácil de identificar em que parte do sistema há mais dificuldade de interagir, e o usuário não fica sem rumo, clicando na primeira opção que aparece. A tarefa pode ser: "cadastre-se no site" e durante a técnica, o observador detecta se o usuário demorou para achar o botão para se cadastrar ou se a tarefa como um todo demorou muito tempo para ser concluída. 
Agora você já tem os usuários, o ambiente e os scripts, então o próximo passo é iniciar a técnica de observação. Durante a observação, o ideal é que o observador não interaja com o usuário, evitando influenciar ações que normalmente seriam tomadas sem a ajuda de alguém. Além do observador detectar as principais dificuldades, é necessário anotá-las, para posteriormente reportar ao setor de webdesigner e desenvolvimento, para que sejam realizadas as alterações necessárias.

Com a imagem do mapa mental abaixo, é mais fácil de visualizar o processo.




A técnica é simples, e o tempo de conclusão depende do tamanho do script e do tamanho do sistema. Mas o mais importante nessa técnica, é o fato de poder identificar o que pode ser feito para melhorar a qualidade do sistema, conforme as reais necessidades e conhecimentos dos usuários. Para quem está muito familiarizado com o sistema, não faz diferença se um botão está posicionado discretamente, enquanto deveria ter mais destaque.


Clicando aqui você poderá conferir uma entrevista feita com a antropóloga britânica Charline Poirier sobre um estudo de usabilidade no Ubuntu, conduzido aqui no Brasil.

 
Monster Bug