TestExpert A sua comunidade de teste e qualidade de software

Pessoal,

criei um post no meu Blog falando sobre a Consultoria de Testes que fiz recentemente. Lá vocês podem acompanhar todo o processo e eventualmente colaborarem para que nosso trabalho, em conjunto, seja sempre positivo:
http://testavo.blogspot.com/2011/12/consultoria-de-testes-lugati-vitoria-es.html

A ideia é que vocês possam acompanhar o processo de mudança e autoconhecimento das empresas que desejam caminhar para o lado da qualidade. E é importante que nós possamos agregar com o trabalho de uns e outros pois tem espaço para todo mundo.

É possível que num futuro próximo nós possamos abrir uma Fábrica de Testes lá, daí vamos precisar conversar com mais calma.

abraços,
Luiz Gustavo Schroeder Vieira, CTAL
http://testavo.blogspot.com
http://www.lugati.com.br 

Existem ainda outros processos mencionados no TMap Next que servem como suporte e auxílio para as mais diversas atividade de teste de software descritas até aqui, bem como para outros os outros processos vistos anteriormente. Veremos à seguir alguns desses processos.

Como já foi falado, às vezes é mais eficiente para organizar certos aspectos/suporte de forma centralizada ao invés por projeto. Trata-se de apoiar os processos para os seguintes assuntos:

- Política de teste

- Organização de teste permanente

- Ambientes de teste

- Ferramentas de teste

- Profissionais de teste

Processos de Suporte - Política de Teste

A política de teste descreve como uma organização lida com as pessoas, recursos e métodos envolvidos no processo de teste em várias situações

Uma vez que o teste é um dos instrumentos para garantir a qualidade, a política de teste terá que estar em consonância com as medidas políticas e outras iniciativas em relação à gestão da qualidade.

Leia o artigo na integra em http://qualidadeeteste.blogspot.com/2011/10/qualidade-de-software-parte-ii.html 

Impulsionados pelas mudanças tecnológicas e pelo amadurecimento das atividades de desenvolvimento de software os produtos, as organizações de desenvolvimento (ODSs) e seus processos associados mudaram no decorrer das últimas décadas. Este capítulo faz uma retrospectiva desses elementos.

A seção 2.1 e 2.2 abordam, respectivamente, a evolução dos produtos de software e a evolução das organizações de desenvolvimento. A seção 2.3 apresenta os processos existentes em uma ODS, demonstrando modelos e elucidando conceitos.

Leia o artigo na integra em http://qualidadeeteste.blogspot.com/2011/10/qualidade-de-software-parte-ii.html 

Entende-se por Testes de Desenvolvimento(development tests) o uso do conhecimento da implementação técnica do sistema. Isso começa com testes nas primeiras/menores do sistema: rotinas, unidades, programas, módulos, objetos, etc.

Depois de ter sido estabelecido que as partes mais elementares do sistema sejam de qualidade aceitável, as partes maiores do sistema são submetidas a testes de integração. A ênfase aqui é na transferência de dados e as interfaces entre, por exemplo, as unidades até o nível do subsistema.

Teste unitário: Um teste realizado no ambiente de desenvolvimento pelo desenvolvedor, com o objetivo de demonstrar que uma unidade atende os requisitos definidos nas especificações técnicas

Teste Unitário Integrado: Um teste realizado pelo desenvolvedor no ambiente de desenvolvimento, com o objetivo de demonstrar que um grupo lógico de unidades atende aos requisitos definidos nas especificações técnicas

Os testes de desenvolvimento são parte integrante do trabalho de desenvolvimento executada pelo desenvolvedor. Eles não estão organizados como um processo autônomo para uma equipe independente.

Processo de Testes de Sistema e Aceite

Os processos de Teste de Sistema e Aceite são considerados como autônomos para serem organizados. Eles têm seus próprios planos de teste, orçamentos e freqüentemente seus próprios ambientes de teste.

Os processos de Teste de Sistema e Aceite "rodam" em paralelo ao processo de desenvolvimento de software, o qual deve ser iniciado enquanto as especificações funcionais são criadas.

O modelo de Ciclo de Vida do TMap Next é usado na criação do plano de teste e na execução  de outras atividades no processo de teste.

Um ciclo de vida de teste é necessário para estruturar várias atividades, suas ordens e dependências. O modelo de ciclo de vida é um modelo genérico e pode ser aplicado a todos os níveis e tipos de teste de teste e utilizado em paralelo com os modelos de ciclo de vida para o desenvolvimento do sistema.

Testes de Sistema e Aceite

No modelo de ciclo de vida TMap Next, as atividades de teste são divididos em sete fases: Planejamento, Configuração e Manutenção da Infra-Estrutura, Preparação, Especificação, Execução e Conclusão.

Introdução

O teste de software é geralmente organizado em níveis de teste, onde cada nível de teste possui metas específicas. O TMap Next distingue e estabelece os seguintes níveis de teste:

- Testes de Desenvolvimento;

- Testes de Sistemas;

- Testes de Aceite.

 

Os níveis de teste devem ser coordenados mutuamente e isso é feito quando criamos o Plano de Testes Mestre(ou MTP - Master Test Plan) e gerenciamos o processo total de testes.

Com relação ao MTP e os níveis de teste, é importante organizar um processo para planejamento, preparação, execução e gerenciamento das atividades.

Estes processos podem ser aplicados em um projeto de testes ou testes dentro de um departamento, por exemplo, em um teste de manutenção de uma nova release.

Veremos agora com mais profundidade as atividades de cada um dos seguintes processos mostrados abaixo:

- Plano de Testes Mestre(MTP - Master Test Plan), gerenciando o processo total de testes;

- Testes de Sistema e Aceite;

- Testes de Desenvolvimento;

Introdução

O resultado de uma Avaliação(Evaluation) depende fortemente da atitude do(s) avaliador(es), afinal avaliamos documentos que são criados por outros.

Dependendo de como os defeitos(ou erros) forem registrados ou comunicados, o autor do documento pode se sentir atacado pelo resto do time, resultando em uma aspecto negativo da real intenção do processo de Avaliação(Evaluation).

É importante saber que a meta final do processo de Avaliação(Evaluation) é entregar o melhor produto de trabalho possível.

Técnicas de Avaliação(Evaluation) são muito recomendadas para melhorar e aumentar a qualidade do produto

Pesquisas têm mostrado que o processo de Avaliação(Evaluation) não são sempre implementados ou executados corretamente. Tal pesquisa ainda revela que:

- 56%dos autorestiveram dificuldadede se distanciar doseu trabalho

- 48% dos avaliadores não receberam o treinamento correto

- 47% dos autores ficam com medo que os dados sejam usados contra eles

Introdução

Conforme a própria definição do TMap Next, o teste de software é um processo que fornece visão e conselhos sobre a qualidade e riscos relacionados. Se a qualidade for inadequada, medidas podem ser tiradas como, por exemplo, o re-trabalho por parte dos desenvolvedores.

Levando-se ainda em consideração que os recursos de teste e tempo são limitados, tonar-se importante relatar o esforço de teste para os riscos do produto esperados, ou seja: mais testes em áreas de grande risco no software; menos testes aonde os riscos são pequenos.

NO RISK, NO TEST!

Escolhas bem definidas devem ser feitas neste contexto. Análise de Risco do Produto(PRA - Product Risk Analysis) é uma ferramenta para ajudar a fazer estas escolhas.

"Uma Análise de Risco do Produto é uma analisar o produto que será testado com a intenção de atingir uma visão conjunta, para o gerente de testes e outros stakeholders, para as características do risco e partes do produto a ser testado, para que a profundidade do teste possa estar relacionada a esta visão."

Qual a sua atitude quando o ciclo de testes atinge 100% dos testes executados como passados? 

Como determinar a efetividade de um caso de teste manual ou automático? 

Questões complexas e que precisamos responder com frequencia para assegurar a qualidade dos produtos que entregamos. 

Visitem o BdB e participem relatando suas experiências. 

http://bytesdontbite.com/2011/07/18/os-bons-testes-falham/

Pessoal,

criei um post no meu blog falando a minha opinião sobre qual a verdadeira/principal função dos Testes de Software em equipe de Desenvolvimento de Software.

A ideia de criar este post, é para mostrar que existe um lado positivo além do "aumentar o nível de qualidade do software através da satisfação do cliente" pois essa abordagem custa caro! Pensa se você fosse um gestor... 

http://testavo.blogspot.com/2011/07/qual-funcao-de-testes-de-software.html

Obviamente essa é a minha opinião, tem pessoas que possuem opiniões divergentes da minha. Estou aberto a discussões!

abraços,
Luiz Gustavo Schroeder Vieira, FCE, CTAL-TA
Consultor de Testes
BSTQB TAG Member
+55 (48) 9994-3569
Skype: luizgsvieira
luizgustavo@lugati.com.br
http://testavo.blogspot.com
http://www.lugati.com.br

Novo post no BdB descreve como utilizar o powerpoint para facilitar a comunicação entre os membros da equipe. Permitindo diminuir a quantidade de defeitos por falhas de comunicação e até mesmo o planejamento e criação de casos de teste com comportamentos errados.

http://bytesdontbite.com/2011/06/21/aumentando-a-qualidade-do-software-com-apoio-do-powerpoint/ 

Muitas pessoas vêem como a descoberta de defeitos um dos propósitos do teste. No entanto, teste de software é muito mais do que isso como já vimos e podemos complementar esta definição com a provisão de informação e conselhos em relação aos riscos e qualidade.

Confusões são feitas com os vários termos como erro, defeito e falha:

- Erro(Error): Erro humano! Esta ação tem lugar antes de todas as faltas e / ou falhas.

- Falta(Fault): O resultado de um erro que residem no código ou documento. Falha é a visão de dentro do sistema. Falha é o estado onde qualquer erro existe. Desenvolvedores verão as faltas.

- Falha(Failure): O resultado ou manifestação de uma ou mais falhas. Quando o sistema está funcionando de maneira diferente do comportamento exigido, do ponto de vista fora do sistema. Os usuários verão a falha.

"O defeito(Fault, Bug) é o resultado de um erro que residem no código ou documento."

Para os propósitos de teste, o TMap Next emprega uma série de características da qualidade. Outro conjunto de características da qualidade pode ser encontrado na ISO 9126-1.

A utilização das características da qualidade(seja TMap Next ou ISO 9126-1) é recomendável, pois permite fazer decisões sobre o que testar ou não certas características da qualidade. 

O livro TMap Next, for result-driven testing mostra inúmeras razões, entretanto, para utilizar as características da qualidade do TMap Next e não da ISO 9126-1:

- Em muitas organizações, o TMap Next é o padrão de testes. Com isso, torna-se mais fácil a implementação das características da qualidade do TMap Next e não da ISO 9126-1.

- O teste de funcionalidade é uma das áreas mais importantes do TMap Next. A ISO 9126-1 vê a funcionalidade como um conceito macro, não havendo assim muitos detalhamentos.

- A características da qualidade da ISO 9126-1 não necessariamente é melhor ou pior que as características da qualidade do TMap Next. Elas são simplesmente diferentes.