Black & White box

ISO 9126-1

2010-03-03T14:37:00.004-03:00

Um conjunto de normas [de padrão internacional] para avaliação da qualidade de um software.

Os componentes verificados por essa norma são:

- Processo

- Produto

- Qualidade em uso

Para a verificação de cada um dos componentes citados, a norma gera atributos de qualidade distribuídos em 6 características principais: [FCUEMP]

1. Funcionalidade

Verifica se o software satisfaz as necessidades especificadas pelo cliente/usuário.

2. Confiabilidade

Verifica se o software consegue manter o nível de desempenho.

3. Usabilidade

Verifica a capacidade do software ser entendido pelo cliente/usuário.

4. Eficiência

Verifica o tempo de resposta/processamento do software.

5. Manutenibilidade

Verifica a capacidade do software ser modificado.

6. Portabilidade

Verifica a capacidade de um software ser transferido de um ambiente para outro.

p.s: vamos avaliar seu software!?

Defeitos

2010-03-01T12:02:00.011-03:00

Respondendo a questão da @Kamilla[DFTestes] sobre classificação dos defeitos.

Defeito: estado do software causado por um erro

Erro: ação humana que produz um resultado incorreto

Abaixo classifico os defeitos seguindo 4 identificadores.

- Frequência: sinaliza a freqüência com que o defeito pode ser observado no artefato ou aplicação. Os tipos de freqüência são: Sempre e Aleatório.

- Gravidade: indica o grau de impacto com que a ocorrência afeta a continuidade do projeto de desenvolvimento ou de utilização da aplicação. A gravidade é classificada como: Grande, Média e Pequena.

- Prioridade: serve para informar a prioridade de correção do defeito. Muitas vezes, a própria gravidade já indica a prioridade, porém, a prioridade serve para ordenar ocorrências com mesma severidade. Sinaliza a urgência de resolução. Os tipos de prioridade são: Imediata, Alta, Média, Baixa e Sugestão.

- Categoria: classifica as ocorrências e permite levantamento de métricas identificando os tipos de defeitos. Os tipos de categorias são: Caso de Uso, Interface, Banco de Dados, Sistema, Caso de teste e Protótipo.

Financeiro X Emocional

2010-02-24T00:23:00.004-03:00

" Toda empresa deve ter uma cultura e uma filosofia. Sem cultura e filosofia planejadas e assumidas, a empresa move-se apenas em função de números. Ela se torna um péssimo ambiente para seus funcionários e uma péssima prestadora de serviço para seus clientes. Os clientes passam a ser não mais seres humanos especiais, mas apenas consumidores em potencial. Uma empresa que não é capaz de pensar 10 ou 20 anos a sua frente é autodestrutiva.

A empresa portadora de uma excelente filosofia tem consciência de que existe para a sociedade, e não a sociedade para ela. Sua meta é contribuir para tornar a sociedade melhor. Sua vocação é colaborar para o crescimento humano. Seu sonho é gerar qualidade de vida em todas as pessoas que ela atinge direta ou indiretamente. Para ela o lucro financeiro caminha paralelamente ao lucro emocional.

As empresas que não possuem uma filosofia sólida costumam perpetuar seus defeitos ao longo das gerações de funcionários. Entre esses defeitos estão a falta de comunicação, a carência de solidariedade, o falso trabalho em equipe, a competição e os mecanismos maquiavélicos."

Autom.ação.

2010-02-22T15:11:00.005-03:00

Vários amigos [analistas/desenvolvedores] sempre me fazem a mesma pergunta: "Por que não automatizar?".

Antes da resposta gostaria de fornecer algumas definições.

1) O que significa a palavra "automação"?

Aplicação de técnicas computadorizadas ou mecânicas para a diminuição do uso de mão-de-obra em qualquer processo.

2) Qual o objetivo da automação?

Diminuir os custos e aumentar a velocidade da produção.

3) Quando automatizar?

[A RESPOSTA!]

A automação de testes pode ser um sonho, mas se não for bem planejada será um pesadelo.

Analisando uma Equipe de Teste, a automação é bem-vinda quando:

- o processo de teste é bem definido

- os profissionais são qualificados e treinados para o uso da ferramenta escolhida

- o teste manual foi anteriormente executado e validado

- os testes possuem mais de 4 ciclos

Sua equipe e o sistema possuem todos esses pré-requisitos?

Sim!

Então estamos aptos a automatizar, mas caso contrário -> Não!

Podemos automatizar qualquer fase do processo de teste que seja repetitiva e que gaste muito tempo.

O Testlink, por exemplo, pode automatizar a criação dos casos de testes e a geração de métricas.

Já o Selenium, pode ser útil nos testes de regressão, nos testes com cálculos matemáticos, teste de performance, teste de integração e nos testes unitários [realizados pelos desenvolvedores].

...

Obs: pensando na equipe de desenvolvimento, os testes automatizados são de extrema importância. Se os programadores não escreveram testes para os seus respectivos códigos, eles já produziram um código legado.

...

Automação é sim redução de custos, mas o objetivo do teste é mitigar os riscos provenientes do desenvolvimento em relação a qualidade. A equipe de teste precisa de alternativas que garantam que o seu trabalho será realizado com eficiência. Precisa, pelo menos, garantir a mesma qualidade obtida na execução dos testes manuais, afinal de nada adianta um número elevado de suítes de testes automatizadas se elas não testam nada. Se os programadores não conseguem escrever um código sem erros, como os testadores podem confiar um sua própria codificação para um script?

Portanto, ressalto, nenhum teste automatizado substituirá um teste manual.

Reflitam!

Time de Teste

2010-02-18T16:41:00.006-02:00

Um time de teste de software também possui uma hierarquia pré-estabelecida.

Um modelo básico e muito utilizado pela comunidade brasileira de teste de software é:

Gerente de Teste -> Líder de Teste -> Arquiteto de Teste -> Analista de Teste -> Testador

Definindo:

[As funções descritas abaixo podem variar conforme a necessidade da empresa]

Gerente de Teste: tem como função primordial a documentação do processo de teste frente ao processo de desenvolvimento de software e a iniciação/finalização do projeto de teste a ser realizado no produto a ser testado. Suas qualificações e competências se assemelham a um gerente de projeto: elaborar o plano do projeto de teste, aquisição de novos recursos, orçamento, riscos, prazos, elaboração de relatórios, limitações do escopo do projeto de teste e outras atividades gerenciais.

Líder de Teste: profissional responsável pela condução dos testes e pela tutoria da equipe de testes. Geralmente é um profissional com alto grau de conhecimento em ciclos de vida e ambientes de testes. O Líder de Testes "ajuda" o gerente de Testes a elaborar os relatórios básicos para o acompanhamento do projeto.

Arquiteto de Teste: responsável por montar e garantir o funcionamento da infra-estrutura e ambientes de teste. É também a pessoa que cuida da instalação/configuração/documentação das ferramentas e que garante o correto funcionamento das mesmas.

Analista de Teste: responsável por traduzir os requisitos do sistema em casos de teste. Identifica e define os testes necessários para cada cenário. Monitora e avalia a qualidade obtida ao testar.

Testador: técnico responsável pela execução dos casos de teste e scripts de teste.

Todos saem ganhando na formação de um Time de Teste de Software com profissionais qualificados: a empresa, o cliente e a própria equipe.

Testar - uma questão social.

2010-02-17T13:46:00.011-02:00

Até um testador obstinado precisa admitir que já se viu frente a frente com o tédio.

A execução diária de testes e o preenchimento exaustivo dos bugs transforma a disciplica de teste, por muitas vezes, em algo monótono e repetitivo.

Pessoalmente, acredito que essa seja a principal razão pela qual muitos profissionais de teste trocam de área ou continuam testando, mas sem criatividade e ânimo.

Como alterar o fluxo?

Responsabilidade social.

Por várias vezes em reuniões com a minha antiga equipe de teste, perguntei aos testadores/analistas se eles tinham idéia de como aquele trabalho era importante para a empresa que eles trabalhavam, para os clientes da empresa [muitas vezes órgãos públicos] e principalmente para a sociedade.

Um exemplo:

"Imaginem um erro no sistema de cálculos da aposentadoria do INSS. Esse erro não reportado por um teste tedioso afetaria seu avô, seu pai e mais tarde até você."

Será que todos nós pensamos sobre isso quando estamos elaborando, testando e projetando um software?

Todo trabalho tem uma questão social embutida!

O mais importante é aprender a importância da qualidade no desenvolvimento de um produto e como isso reflete no social. Nem todos os "testers" seguirão o caminho da detecção de erros, mas creio que serão melhores em qualquer outra profissão, pois serão responsáveis pelo que produzem e buscarão o seu melhor sempre, e não só por eles, mas pelo meio.

Myers e TDD

2010-02-10T12:13:00.002-02:00

Para complementar o post sobre a Regra 10 do JOGO.

http://ow.ly/15OxX

Discutindo Qualidade e Teste de Software

2010-02-09T09:30:00.005-02:00

Segue o link do grupo DFTestes:

http://br.groups.yahoo.com/group/DFTestes/

Regra 10 - O JOGO!

2010-02-08T15:19:00.000-02:00

Toda empresa de desenvolvimento de software deveria ter a Regra 10 de Myers escrita por todos os cantos.

Um cartaz pregado na porta ou perto da catraca seria uma boa solução.

Você [programador, analista de requisitos, gerente de projeto, etc] sabe o que diz a "Regra 10 de Myers"?

Não!?

Defino...

"A Regra 10 de Myers, estabelece que o custo de correção de defeitos tende a aumentar quanto mais tarde o defeito é detectado.A regra projeta um crescimento exponencial do custo de correção de defeitos, numa proporção de 10x. Ou seja, defeitos encontrados em revisões custam X, defeitos encontrados nos testes custam 10X e defeitos encontrados em produção custam 100X para serem corrigidos."

Entenderam?

Para ser mais clara...

Um defeito encontrado durante o levantamento de dados, escrita do caso de uso é mais barato que um erro encontrado no desenvolvimento e muito mais barato que um erro reportado pela equipe de teste.

E como poderíamos solucionar tal problema?

Começar do zero?

Processos agéis? TDD?

Hum...talvez.

Nessas técnicas a participação das equipes de teste e desenvolvimento são essenciais desde o início do projeto.

Sua empresa possui uma cultura "engessada" no processo de desenvolvimento de software?

Hum...entendi, mas tenho algumas soluções básicas!

1) Crie um checklist de testes unitários para sua equipe de desenvolvimento.

2) Pratique a política de diminuição de erros - se num determinado projeto vc obteve X erros, no próximo tente X/2. Aprenda com os erros e converse sobre os mesmos.

3) Faça reuniões de repasse - antes de homologar um UC, repasse o mesmo para a equipe de teste e desenvolvimento. Aceite as alterações!

4) Mantenha sempre uma excelente equipe de Análise de Requisitos.

As pessoas ocasionalmente resistem à mudança e evitam aventurar-se em áreas pouco familiares.

Arrisque!!!

Crie o conceito de TIME e entre no JOGO!

http://www.agileway.com.br/2008/09/09/scrum-no-metodo-conta-gotas/

http://dojofloripa.wordpress.com/2007/09/10/tudo-sobre-tdd/

http://blog.seatecnologia.com.br/2010/01/11/dojo-sea-2010

Agradecimento

2010-02-08T12:35:00.000-02:00

Farei um agradecimento público aos meus novos e ilustres leitores:

.Paulo Foina [coordenador do curso de Ciência da Computação do UNICEUB] - Manager at Instituto de Pesquisas Eldorado

.Vinicius Oliveira [companheiro de vida acadêmica] - ICT Assistant at Unicef

THANKS and LETS GO!