Reuniões de Melhoria das Especificações II

Primeiros resultados:

Aplicando-se todas estas diretivas, colhemos alguns resultados da primeira reunião.

1. Avaliação do Template (o que agiliza? o que atrapalha?)

O pessoal avaliou o estado do template e dizem que não têm tido grandes problemas. Foi incluído como anexo (opcional) uma tabela para mapeamento de campo de tela (cujo nome estará também no protótipo) com a ‘tabela.coluna’ do banco de dados. Se esta tabela for usada no Caso-de-Uso, exclui-se a necessidade de incluir a validação dentro do texto do Fluxo.

Nome Campo	Tipo	Obrigatório?	Campo no BD
Tipo de Endereço	select box*	Sim	endereco.tipo
Endereço	text field**	Sim	endereco.descricao

*ou ‘campo seleção’ *ou ‘campo texto’
2. Retirada de Informação desnecessária do Caso-de-Uso (o que tem sido burocrático demais?)

Foi excluída a seção ‘Restrições’ dado que já existe no Caso-de-Uso um espaço para serem colocadas as pré e pós-condições.
3. Desmembramento dos passos de acordo com o Fluxo de Tela (clarificação dos passos)

Foi definido que cada verbo deriva um passo, e em cada quadro do ‘ping-pong’ podem existir um ou mais passos. Obs: cada verbo que signifique uma “ação”.
4. Regras de Validação do Campos (informações necessárias como tipo de campo: ‘text field’, ‘text area’, ‘select box’, ‘radio button’ e restrições de valores como numérico inteiro, decimal, etc..)

Ficou decido que não serão incluídas informações de telas nos textos dos passos de cada fluxo, ou seja, o nome de Campos e de Botões da tela. Mas o tipo de item de tela a ser utilizado pode ser indicado. Exemplo: ‘O sistema deve exibir uma tela com os campos: 1. Tipo de endereço: (campo de seleção); 2. Endereço (campo texto, obrigatório); [...] ‘
5. Inclusão de Requisitos Funcionais e Não-Funcionais no UC: Sim ou Não?

Ficou em aberto para ser decidido na próxima reunião porque isto vai exigir uma avaliação no tempo disponível para isto, no formato que irão ser registrados os requisitos, etc…
6. Geração de Protótipo (apresentação de uma solução prática pelo Adriano)

Foi apresentada rapidamente a ferramenta ‘Pencil’, sugerida pelo Alessandro, e a equipe entrou num consenso que a ferramenta se mostrou prática e fácil de ser manuseada. A confecção de protótipos foi votado por todos como item obrigatório.
7. Casos de Uso que possuem dependência entre si.

Foi definido que será colocado dentro do próprio caso-de-uso qualquer referência que ele tenha a outro Caso-de-Uso.

Pauta para a próximas reunião (ainda não fechada):

1. Feedback de todos em relação ao que foi definido e o que foi realmente aplicado, esforço necessário e benefícios
2. Quais as informações devem vir do cliente para melhorar a precisão das estimativas?
3. Diagrama de Classes: qual ferramenta utilizar até que a proposta da Mariana com o EA esteja pronta? Obs: Tínhamos discutido que ficariam nos anexos.
4. Nomenclatura padrão para as especificações de todos os projetos.
5. (…)

Reuniões de Melhoria das Especificações I

Fizemos duas reuniões para melhorias das Especificações, elas seguiram mais ou menos o modelo abaixo:

Objetivo

• Enxugar o Caso-de-Uso
• Adicionar informações válidas
• Diminuir dependência do Desenvolvedor ao Analista
• Diminuir dependência do Tester ao Analista

Papéis e Responsabilidades

Cada colaborador deve levantar os pontos que achar que podemos melhorar na Especificações prestando atenção também ao feedback dado pelos desenvolvedores e ao feedback dado pelo cliente na entrega do produto final.

O papel do Analista de Qualidade no grupo será de apenas dar sugestões defendendo os interesses da equipe de Qualidade. Além de motivá-los a discutir os assuntos levantados que são de profundo interesse da Área de Qualidade.

O papel dos Analistas de Sistemas será em função de agilizar seu próprio trabalho e prover os dados necessários para o desenvolvimento sem que o desenvolvedor precise perder tempo em analisar o negócio (ele deve apenas entender de que forma o sistema deve se comportar em relação a eventos de tela, fluxo de dados, lógica envolvida, estrutura de dados no banco, regras de negócio a serem implementadas, etc. ). Isto para, no futuro, o desenvolvedor não precisar perder tempo com o entendimento do negócio, apenas implementar de acordo com o definido.

Então os próprios Analistas de Sistemas devem sugerir melhorias em função deste objetivo comum: prover melhorias que facilitem o trabalho sem burocratizar, ou seja, máxima eficácia com mínimo esforço.

Estratégias de Testes

Existem várias estratégias que podemos adotar para implantar testes de software em projetos. As estratégias de teste servem para nos guiar a um objetivo em comum: eliminar o máximo possível de bugs e desvios de implementação. Basicamente, entregar ao cliente exatamente o que ele requisitou e funcionando.

Para tal podemos adotar alguns tipos de abordagem:

• Preventiva ou Reativa (em relação ao tempo em que os testes iniciam) e;
• Analítica ou Heurística (em relação às fontes de informação disponíveis).

Preventiva VS. Reativa

Abordagem Preventiva
Equipe de Testes é envolvida desde o início: planejando as atividades de teste e especificando as atividades de teste são cedo quando possível. Isto pode ocasionar a otimização das atividades de teste e consequente redução de custo, já que os bugs de expecificação e projeto serão encontrados cedo, gerando menos retrabalho. Aplicação de revisão e análise estática antes do desenvolvimento pode contribuir para prevenir defeitos em tempo de execução de testes. Desta forma, pode-se reduzir os custos com execução de testes e retrabalho.

Abordagem Reativa
São atividades nas quais a equipe de testes é envolvida muito tardiamente e a abordagem preventiva não pôde ser escolhida. Nesta situação a análise e projeto do sistema já foi concluído, de tal forma que a equipe de testes precisará ‘explorar’ as funcionalidades a ser entregues. Testes exploratórios são baseados na experiência dos testadores e têm como objetivo executar diversas possibilidades de execução e de avaliação.

Analítica VS. Heurística

Abordagem Analítica

O planejamento dos testes é baseado em dados ou na análise destes dados. O critério de saída (critério que mapeia quando os testes devem parar) é quantificado e sua correlação será modelada. Ex: os testes serão finalizados quando atingirem 90% de cobertura.

A quantidade e a intensidade dos testes serão escolhidos de acordo com múltiplos parâmetros individuais (custo, tempo, cobertura, etc).

Abordagem Heurística

O planejamento de testes é baseado na experiência dos experts em testes (de dentro ou de fora do projeto) e/ou nas regras repassadas pelos papéis-chave do projeto. O motivo é porque os dados não estão disponíveis, a modelagem de dados para testes é muito complicada, ou porque é necessário conhecimento do negócio.

Abordagem Analítica e Heurística na prática

Na prática, a abordagem utilizada é um meio-termo entre os extremos e utiliza diferentes graus de elementos analíticos e estáticos:

Testes “model-based”

Utiliza modelos funcionais abstratos do software sob testes para o projeto de Test Cases para encontrar o “test exit criteria” (critério de encerramento dos testes), e para medir a cobertura dos testes (que ocorre contra o modelo).

Testes estatísticos ou “stochastic (model-based)”

Utiliza modelos estatísticos sobre a distribuição de falhas no objeto sujeito a testes, taxa de defeitos durante o uso do software ou distribuição estatística de casos de uso (bem como perfis operacionais); baseando-se nesta distribuição o esforço de testes é alocado.

Testes baseados em Risco

Utiliza informações do risco do projeto e do produto, e direciona o teste para áreas de maior risco.  Os riscos do projeto são tratados frente à capacidade de entrega do produto. Segundo os padrões I3E para Quality Assurance, gerenciamento de risco comprende:

• Avaliação do que pode dar errado (avaliação de riscos)
• Priorização dos riscos identificados
• Implementação de ações para mitigar ou eliminar estes riscos (Ex. partes críticas do software devem ser testadas mais criteriosamente)

Testes orientados a padrões ou processos

Utiliza regras, recomendações e padrões (como o modelo-V) como cookbock.

Testes orientados a Reuso

Testes em ambientes de reutilização de testes existentes e materiais. O objetivo é configurar os testes mais facilmente para o máximo reuso.

Testes baseados em checklists (ou metódicos)

Utiliza listas de falhas e defeitos desde cedo nos ciclos de teste, listas de defeitos em potencial ou riscos, ou prioriza o critério de qualidade e outros métodos menos formais.

Testes baseados em experiência

Utiliza a experiência do profissional e o feeling dos especialistas envolvidos (para a tecnologia utilizada e o domínio da aplicação)

Participação no FISL

Este post eu havia escrito em 15 de julho de 2009, logo depois de ter participado do FISL10 (Fórum Internacional de Software Livre) que é realizado em Porto Alegre, RS. Segue….

Qual a importância do Teste de Software?

Este tema já está “batido”, no entanto ainda ouvimos por diversas vezes esta mesma pergunta.
No FISL 10 (10º Fórum Internacional de Software Livre) eu e o Luiz Gustavo (http://testavo.blogspot.com) nos vimos à frente deste mesma pergunta quando um dos expositores nos comentou o seguinte: “Na comunidade de Software Livre não precisamos de testadores, a própria comunidade testa o software”. E isto nos gerou uma “pulguinha” atrás da orelha. Como explicar para ele a importância do teste de software mesmo em projetos que possuem várias pesssoas testando aleatóriamente? Talvez a resposta esteja implícita na própria pergunta: mas, afinal, quem testa o quê? Existe uma organização? Todo mundo testa tudo?

Obviamente nem todo mundo testa tudo e nem tudo é testado por todo mundo.
Sacou?

Bom… o fato é que é provado por diversos estudos (citar um exemplo) que um software testado muitas vezes não está livre de bugs. Aliás, nenhum software no mundo é perfeito ou, atende a todos os requisitos funcionais e não-funcionais do cliente . Isto porque se o foco do teste não for definido nem os objetivos e os critérios de entrada e saída, as várias pessoas podem estar testando a mesma coisa e não capturando bugs relevantes para o sistema. É possível também que boa parte das condições não estejam sendo ‘cobertas’ pelos testes por se tratar de itens ‘irrelevantes’, ou de menos importância para o bom funcionamento do sistema.

O papel de um profissional na área de testes é encontrar tantos bugs quanto possível para garantir um alto nível de qualidade no produto. Além disso, ele está apto a verificar se todos os requisitos definidos pelo cliente foram cumpridos, além de obter métricas em cima de todo o seu trabalho. É importante que seja feita uma análise também da cobertura dos testes e das técnicas e práticasa a serem aplicadas.

Além disso, com os testes, é possível determinar também os possíveis riscos do projeto de não atingir o objetivo ou o risco do produto não ser entregue de acordo com o desejo do cliente. Existem indicadores que demonstram quão distante um sistema pode estar do seu objetivo final: atender os desejos e necessidades do cliente de acordo com o que foi contratado.

Estes indicadores serão estudados e contemplados em posts posteriores.

Metodologia de desenvolvimento de software: importância, conceitos e princípios

Estava procurando uma ‘luz no fim do túnel” para um problema que tenho tido na empresa que atualmente trabalho: a falta de entendimento de que a implantação de testes de software exige pelo menos uma metodologia de software definida, e o mínimo de organização que um projeto deveria exigir. Encontrei, então, o seguinte artigo:

http://blog.prasabermais.com/2010/02/28/metodologia-de-desenvolvimento-de-software-importncia-conceitos-e-princpios/

O que mais me chamou a atenção foi a finalização do artigo, que são fatos básicos que toda empresa deveria ter em mente ao se implantar melhorias no processo e/ou uma metodologia de desenvolvimento:

“Uma metodologia de desenvolvimento de software é importante pois pode ser um marco para iniciar as melhorias, traz benefícios para todo o grupo, compartilhando as experiências; estabelece uma linguagem comum ; é um caminho para definir metas de melhoria contínua; traz facilidade na manutenção de sistemas ; reduz dependência de pessoas chaves e facilita o processo de testes

Ao se adotar uma nova metodologia, deve-se considerar que durante o processo de implantação da mesma haverá aumento do trabalho e da burocracia e a tendência de tornar o trabalho mais lento; dificuldade do aprendizado e que o treinamento custa tempo e dinheiro; a carga de trabalho aumenta no início do uso da metodologia, e os benefícios só são vistos mais tarde; a manutenção da documentação pode ser tediosa; a metodologia deve ser adaptada para cada tipo de situação.”