Algumas desculpas que os programadores emitem na presença dos testadores

Veja algumas desculpas que os programadores emitem durante a execução da atividade de teste.

1 – Putz: Se eu tivesse validado. (o se é primo de primeiro grau do talvez)

2 – Nem sei se eu validei isso. (eu tenho certeza que não)

3 – O programa não passou no teste porque eu esqueci de retirar um comentário do código. (que pena!)

4 -Essa é ótima: Tá pegando pesado, o usuário nunca irá fazer isso. (utilize sua certeza para programar)

5 – Pelo menos a saída emitida não é lixo de memória. (é… poderia ser pior)

6 – Ih. Por que letra não entra e os caracteres especiais sim? (se você não sabe, quem saberá?)

7 – (Essa é ótima) Poxa que maldade!!! Testar isto para ver se está funcionando!!!

8 – Porque, sei lá. (boa, não?)

9 – Era para passar no teste mas não passou (ainda bem que você pensa assim!)

10 – Tudo isso aconteceu porque modifiquei o programa (inteligente esta!!! né…)

J. A.

fabri@femanet.com.br

Pipa na UENP

Nesta terça (20 de outubro) tive a oporunidade de conversar com o pessoal da Universidade Estadual do Norte do Paraná – campus de Bandeirantes, sobre a qualidade no processo de produção de software. Os slides utilizados estão disponíveis neste link.

Agradeço a coordenação do curso de Sistemas de Informação pelo convite.

CMMI: Mais um semestre Chinês

Ao publicar o post será que o reinado indiano terá fim  defendi a tese que se os chineses crescessem 10% ao ano em número de certificações CMMI nível 5 - em 15 anos a China superará a Índia.

No final do mês de setembro o SEI  publicou mais um relatório sobre as avaliações do referido modelo, nele é possível encontrar números consolidados para o primeiro semestre de 2009. Mais uma vez, a China liderou a taxa de crescimento.

Vamos aos números.

Empresas avaliadas nos últimos 88 meses:

• Brasil:      117 (10% de crescimento)
• Índia:       460 (12% de crescimento)
• China:     946 (27% de crescimento)

Taxa crescimento no número de avaliações no primeiro semestre de 2009 -

• Nível 5:
  • Brasil:     00%
  • Índia:      03%
  • China:     10%
• Nível 4:
  • Brasil:     00%
  • Índia:      00%
  • China:     25%
• Nível 3:
  • Brasil:     09%
  • Índia:      23%
  • China:     34% (salto de 540 para 728 empresas certificadas)

Note que a  escalada chinesa é superior a indiana em todos os níveis.

Por fim, ressalto que os números publicados pelo SEI, mantêm a minha tese: Os chineses cresceram, NESTE SEMESTRE, 7% em números de certificações (CMMI nível 5) quando comparados aos indianos. Em 2008 essa taxa foi de 10,66%. Se ambos os países repetirem o desempenho do primeiro semestre de 2009, os chineses terão um crescimento de 20% contra 6% dos indianos. Se a taxa de crescimento permanecer em torno dos 15%, em 10 anos, a China será o país com maior número de certificações no nível 5.

Mais um número para os chineses comemorarem nos 60 anos de sua revolução.

A questão está aberta: A China irá ultrapassar a Índia em número de certificações CMMI?

José Augusto Fabri

fabri@femanet.com.br

Para que simplificar se podemos complicar

Toda vez que sou convidado a falar sobre a redação de um processo de produção de software utilizo, como exemplo, uma adaptação da entrevista de Gehringer apresentada pela rádio CBN.  

Segue a transcrição da entrevista:

Joãozinho, um funcionário exemplar de uma grande empresa, foi promovido a gerente. É isso ai Joãozinho, meus parabéns, agora você tem o direito de tecer opiniões sobre o planejamento estratégico da referida organização.

No primeiro dia em sua nova função, Joãozinho recebeu um documento – o planejamento estratégico - um calhamaço de 150 páginas. Depois de ler várias vezes, não entendeu nada. Ele não conseguia enxergar uma relação direta entre o planejamento estratégico e as coisas que aconteciam no dia-a-dia da empresa.

Joãozinho, bem-vindo ao mundo real. Você entrou para o time das pessoas que complicam em vez de simplificar. Com certeza o documento foi redigido em outro idioma, o português corporativo. Uma língua extremamente complicada que não é falada e somente escrita. Vou apresentar 3 exemplos de coisas muito simples, que ao serem escritas no português corporativo “agregam um valor imenso”.

1 – Implementar a substituição estratégica de  um equipamento periférico que gere um alto grau de luminosidade ao ambiente criativo. Traduzindo, troque a lâmpada queimada.

2 – Avaliar a necessidade de um programa emergencial de governança financeira doméstica balançada. Ou seja, pare de estourar a cheque especial.

3 – Esquematizar uma agenda de atividades gerenciais de maneira a criar um gap vital para atender os clientes internos em sua organização. Traduzindo, converse sempre com seus colaboradores.

Joãozinho lembre-se, agora você ganhou o direito de complicar. Então… relaxe e complique. Se demonstrar competência para isto, você será promovido a diretor.

Engenheiros, SQAs, analistas de sistemas, fujam das complicações, simplifiquem… institucionalizar um processo de produção de software caracteriza-se como a implementação da ciência do óbvio.

Abraços

José Augusto Fabri

fabri@femanet.com.br

Como criar um processo ágil de desenvolvimento de software?

Pessoal, compartilho com vocês um  material super simples que trata da criação de um processo ágil de desenvolvimento de software. Basta acessar o link http://visaoagil.wordpress.com/2009/07/02/whitepaper-criando-um-processo-agil-para-desenvolvimento-de-software/ e confir.

Abraços

Guto.

Utilizando o framework de Zachman para definição de um processo de produção de software

O framework Zachman foi originalmente concebido, na IBM, por John Zachman, no início dos anos 80 e é caracterizado como um quadro de trabalho que provê mecanismos para definir as características (processos, tecnologia e conectividade) de uma corporação.  Ele utiliza um modelo matricial bidimensional com seis interrogações básicas (O que? Como? Onde? Quem?  Quando? Por que?) cruzadas com seis tipos de modelos (escopo, modelo de negócio, modelo sistêmico, modelo tecnológico e apresentação detalhada).

Atualmente, o referido framework é classificado como um padrão mundial para expressar elementos básicos para a arquitetura corporativa e de sistemas de informação. Neste post vou apresentar como apliquei o framework no estabelecimento de um processo de produção de software de uma empresa localizada no estado de SP. Para atingir este objetivo vou dividir o texto em três seções: 1 – Contexto empresarial, 2 – Apresentação do framework, 3 – Uma pequena visão da definição e institucionalização de algumas tarefas do processo.

1 – Contexto empresarial

A empresa X necessitava estruturar um processo de produção de software para atender as prerrogativas delineadas no framework de Zachman. O objetivo da empresa era concorrer em um processo licitatório. Importante: o edital pontuava as empresas que demonstrassem conhecimento no referido framework. É salutar dizer que a empresa em questão possuía um processo de produção de software semi-estruturado (ou seja, algumas atividades do processo eram bem definidas e estavam consistentes, porém outras deixavam a desejar). Esta semi-estruturação facilitou muito o trabalho. Primeiramente detectamos quais as atividades do processo seriam aproveitadas e quais seriam reestruturadas. Posteriormente envolvemos os colaboradores (cerca de 20 pessoas) para trabalhar na reestruturação. Apresentamos o framework de Zachman aos colaboradores e por meio de um brainstorm iniciamos nosso trabalho. Todas as informações colhidas eram materializadas em redes semânticas e, posteriormente, mapeadas junto ao framework.

2 – O framework

O framework é caracterizado por uma matriz de 6 X 7. Nas linhas visualizam-se os modelos e nas colunas as questões. A leitura do framework deve ser feita da seguinte forma:

Linha modelo de negócio X Como? = definição dos processos de negócio.

3 – Uma pequena visão da definição e institucionalização de algumas tarefas do processo

Nesta seção será apresentada a definição e institucionalização da atividade que materializa o modelo de negócio, as demais seguem a mesma abordagem.

De posse do framework e das redes semânticas geradas, concluímos que materialização do processo de negócio possui como entrada as informações advindas da atividade de mapeamento do escopo. Neste caso, para o referido processo, teríamos 6 artefatos de entrada (vide figura abaixo) e seis artefatos de saída. A quantidade de artefatos, tanto de entrada como de saída, não necessita respeitar estritamente as prerrogativas impostas no framework, é possível perfeitamente adaptá-las dentro do contexto organizacional previamente definido.

Todos os artefatos de entrada e de saída respeitavam os padrões de projeto e de produto estabelecidos pela organização. Dentro do processo de consultoria também foi configurada uma base de conhecimento, com o objetivo de materializar os aspectos sintáticos e semânticos para o preenchimento de tais artefatos. Uma ferramenta de gestão, também foi configurada, seu objetivo era estabelecer as linhas base de: tempo, custo, escopo (configuração) e qualidade.

Por fim, gostaria de salientar que estou aberto a possíveis discussões e, se necessário for, posso “contar”, pessoalmente, tudo o que foi feito nesta experiência.

Abraços

J.A.

Desenvolvendo a atividade de teste de software – parte 2: A guerra dos testes

No post Desenvolvendo a Atividade de Teste de Software parte 1 apresentei alguma técnicas que podem (de imediato) ser implementadas pelos desenvolvedores de software. Neste texto mostrarei os passos para institucionalizar a atividade de teste unitário em uma empresa de produção de software.

1 – Apresente a importância da atividade de teste para os envolvidos com o processo.

Neste passo solicito a cada um dos colaboradores o desenvolvimento de uma interface para receber, via teclado, os dados de uma pessoa, por exemplo: código, nome, rua, número, bairro, idade e CPF. Além de receber as informações o programa deveria armazená-las em um banco de dados. Enfatizo, TESTEM O PRODUTO ANTES DE ENTREGAR PARA O CLIENTE. Terminado a atividade de programação e do “suposto teste” veja só o que ocorre.

2 – Treinamento em teste de software.

Realizada a experiência, os colaboradores têm a noção exata sobre importância da referida atividade. Todos estão ávidos para participar do treinamento em teste de software. Aproveito a deixa a apresento as concepções delineadas no post Desenvolvendo a Atividade de Teste de Software parte 1.

3 – Crie a guerra de teste

Realizado o treinamento, convido os colaboradores para um desafio, a guerra dos testes. Divido a equipe de produção em grupos. Solicito que os grupos desenvolvam um único programa. Todos os grupos devem criar os seus escudos, ou seja, validar as entradas para que os tiros (dados de testes gerados pelo outro grupo) não os atinjam.

Estabeleço um tempo para o desenvolvimento.

Sorteio quem vai disparar em quem, por exemplo: o grupo 1 dispara contra o 2; o 2 contra 3; o 3 contra o 4; e o 4 contra o 1.

Contabilizo os tiros efetuados. Vence quem acertou mais e recebeu menos tiros.

Dados gerados com a guerra

Executei a guerra dos testes algumas vezes, veja só o último resultado:

Contexto: empresarial.

3 grupos de 5 pessoas.

Um formado somente por mulheres (grupo 1).

Um formado somente por homens (grupo 2).

E outro misto (grupo 3).

O Grupo 1 acertou 5 tiros no grupo 2 e não levou tiro algum do grupo 3.

O Grupo 2 acertou 2 tiros no grupo 3 e levou 5 do grupo 1.

O Grupo 3 não acertou tiro algum no grupo 1 e levou 2 tiros do grupo 2.

O grupo 1 foi o vencedor. Como prêmio, as garotas levaram um abadá para o carnaval 2010 (em Salvador). O prêmio foi disponibilizado pela empresa.

A institucionalização

A gerência de produção da empresa adotou guerra como prática, toda semana seria configurada uma. Além disso, as garotas que venceram foram “convidadas” a compor a célula de teste da empresa. Todas as funcionalidades geradas passarão pelo crivo delas.

Abraços

José Augusto Fabri

fabri@femanet.com.br

Desenvolvendo a atividade de teste de software – parte 1

Conforme definido por Sommerville, um processo de produção de software estabelece procedimentos sistemáticos que possibilitam a construção de um produto caracterizado como software. O processo pode ser dividido em atividades (ou subprocessos). Essas atividades também podem ser subdivididas, gerando assim, as tarefas. A partir desta definição podemos concluir que a tarefa é a menor unidade de execução dentro de um processo. Geralmente, todo processo de software possui as seguintes atividades: Levantamento de requisitos, modelagem de negócio (análise de sistemas), projeto de software, programação, teste, implantação e manutenção.

A atividade de teste é dividida em teste de caixa preta e teste de caixa branca. No primeiro a equipe de teste não tem a acesso ao código fonte do programa. Para executar o teste de caixa preta é necessário definir os casos de testes, definir os dados de teste, executar os testes e verificar os resultados (temos aqui 4 tarefas).

A definição dos casos de teste tem como objetivo delimitar o que deve ser testado, os recursos necessários para execução do teste (hardware e software) e as técnicas a serem utilizadas na definição dos dados de teste.

Delamaro et. al. enumera uma série de técnicas, neste post vou apresentar 4 delas: teste exaustivo, particionamento em classe de equivalência, análise do valor limite e o teste funcional.

No teste exaustivo, todas as possibilidades são testadas, ou seja, eu testo todos os possíveis dados de entrada. Para exemplificar esta técnica parta do princípio que você tem que testar um programa com duas entradas numéricas inteiras. A linguagem de programação que você utiliza delimita que o número inteiro possui 32 bits. Neste caso teríamos que executar o teste de 2³² * 2³², ou seja, 2⁶⁴ entradas. Vamos supor também que a máquina utilizada no teste  processa o referido programa em 1 milissegundo. Transformando 2⁶⁴ milissegundos em séculos, chegaríamos à casa de 5.849.424.

Ao analisar o exemplo acima podemos concluir que o teste exaustivo é inviável na definição dos dados de teste. Com base nesta afirmação, Delamaro et. al. apresenta a utilização da técnica de particionamento em classe de equivalência.

Para exemplificar esta técnica, vamos supor que o testador tem como tarefa definir os dados para executar o teste de um programa que deve verificar se um número inteiro encontra-se no intervalo fechado de 0 a 10. Ao aplicar o particionamento em classes de equivalência a quantidade de entradas e, conseqüentemente, de execução para este programa é 3 (3 classes – entrada negativa, entrada dentro do intervalo, entrada positiva superior ao limite do intervalo). A tabela abaixo apresenta os dados de entrada e a saída que deve ser emitida pelo programa em questão.

Dados                   Saída

-3                           número fora o intervalo

4                             número dentro do intervalo

15                           número fora do intervalo

A técnica de análise do valor limite possibilita que dados próximos a fronteira das entradas sejam inseridos na folha de teste. Neste caso a tabela para execução das entradas e a saída a ser emitida pelo programa anterior deve possuir a seguinte configuração:

Dados                   Saída

-3                           número fora o intervalo

4                             número dentro do intervalo

15                           número fora do intervalo

-1                           número fora do intervalo

0                             número dentro do intervalo

1                             número dentro do intervalo

9                             número dentro do intervalo

10                           número dentro do intervalo

11                           número fora do intervalo

Ao analisar a definição e a tabela apresentada para a técnica em questão é possível concluir que:

1 – A técnica de analise do valor limite está baseada na técnica de particionamento em classes de equivalência, pois o referido teste levou em consideração os números dentro e fora (duas classes) do intervalo.

2 – Números próximos e imediatamente superiores ao limite das variáveis também devem ser testados. Supondo que a linguagem de programação utilizada para construção do referido programa estabelece que o número inteiro possua 16 bits. Teríamos que incluir na folha de teste os seguintes dados: -32769, -32768, -32767, 32766, 32767, 32768. O primeiro e o último número da seqüência estão fora do limite da variável. Esta informação deve ser validada e informada ao usuário quando um dado como este for digitado.

Já o teste funcional provê subsídios para que o testador possa inserir dados de tipos diferentes daqueles definidos no documento de especificação. Neste caso além de testar os dados apresentados na tabela 2 é necessário:

1 – testar o comportamento do programa quando a entrada for uma letra.

2 – testar o comportamento do programa quando a entrada for um caractere especial ex: {!   ;   – }.

3 – Testar o programa quando a entrada for nula.

4 – Testar o programa quando a entrada for um espaço em branco.

Em todos os testes acima, a saída emitida pelo programa é: “entrada inválida”.

Por fim, o teste de caixa branca está ligado à idéia de inspeção de código. Seu objetivo é verificar anomalias no referido artefato. Este texto apresenta alguns itens a ser inspecionado em qualquer código fonte:

1 – O código fonte segue as prerrogativas estabelecidas pelo padrão de código. Se o processo norteia a utilização do Java Code Convention o código deve seguir a referida convenção.

2 – Verificar se todas as variáveis declaradas estão sendo utilizadas durante o processamento das informações.

É importante salientar que atividade de teste possui uma grande gama de conceitos, este texto apresentou alguns que podem (de imediato) ser implementados pelo setor produtivo de software. No próximo post apresentarei como institucionalizo tais conceitos em uma empresa produtora de software.

Abraços

José Augusto Fabri

fabri@femanet.com.br

Referências:

Delamaro, et. al. Introdução ao teste de software. Campus. 2007.

Sommerville. I. Engenharia de Software.

A pipa da Escola Regional Bahia, Alagoas e Sergipe

Na última semana (de 06 a 08 de maio) estive na Universidade Estadual de Santa Cruz, Ilhéus, ministrando um curso sobre processo fabril de produção de software.

Gostaria de parabenizar a organização do evento, especialmente, aos professores Paulo Ambrósio e Jose Craveiro pela acolhida durante minha estada em no sul da Bahia.

Agradeço também aos alunos de Alagoas, Sergipe e da Bahia que não mediram esforços para participar do curso.

Compartilho com vocês: Análise do mercado produtivo de software sobre a ótica do BRIC. Slides do Curso. Estrutura de dados utilizada na organização do processo produtivo (figura ao lado).

 

Abraços

José Augusto Fabri

fabri@femanet.com.br

A rastreabilidade dos requisitos como importante fator da garantia de qualidade

Todos nós sabemos que um dos principais itens em um plano de qualidade de software é atender de forma eficiente e eficaz as especificações do produto delineadas pelo usuário. Neste caso a qualidade passa pela concepção de um fio condutor que uni requisito e produto. É justamente neste aspecto que as empresas possuem grandes dificuldades. Elas não implementam um dos conceitos primários da engenharia de software, a rastreabilidade.

O que é rastreabilidade de requisitos?

Para responder essa questão, vamos supor que tenhamos um requisito de software modelado em um documento de caso de uso. Esse requisito irá gerar uma parte do projeto de software. Essa parte será implementada, testada e, posteriormente, implantada. A capacidade de recuperar, rapidamente, todos os artefatos (digramas, código, folha de teste, etc.) gerados a partir do referido requisito defini o termo rastreabilidade.

A rastreabilidade está, intimamente, ligada ao modelo de processo e ao próprio processo de software. A partir de um  processo definido e institucionalizado  podemos recuperar tudo aquilo que foi gerado para atender a especificação de um determinado requisito. É importante salientar que para efetuar tal recuperação, de maneira eficaz, é necessário utilizar uma ferramenta de gestão de processo de software. Já escolha do modelo se alinha com a volatilidade dos requisitos, fato este que leva a maioria das empresas a utilizar o modelo incremental ou evolucionário.

Subsidiar o mapeamento de impacto também se constitui uma das diretrizes da rastreabilidade. Vale lembrar que o referido mapeamento é uma tarefa ligada à gestão de configuração.  Parta do seguinte exemplo: Você, enquanto analista de sistema, levantou um requisito. Esse requisito sofreu vários desdobramentos (foi projetado, implementado e testado), gerando assim vários artefatos. Imagine que o cliente fez uma mudança neste requisito. Neste caso, com a rastreabilidade modelada, é possível identificar quais artefatos serão impactados diretamente.

Ao rastrear e validar os requisitos estamos nitidamente delineando questões relacionadas à qualidade do processo. Em nenhum momento podemos esquecer que o fio condutor que une os requisitos aos produtos gerados passa por questões ligadas a:

gestão de configuração;

planejamento, acompanhamento e supervisão de projetos;

gestão de requisitos.

Enfim, ao tratar estas questões delinearemos a maioria das PAs do CMMI nível 2.

Também não podemos nos esquecer da qualidade dos requisitos não funcionais, fatores como segurança, proteção, confiabilidade de recuperação, facilidade de compreensão, estabilidade, facilidade de implantação, modularidade, portabilidade e facilidade de uso devem compor todo e qualquer planejamento de qualidade.

J. A.

fabri@femanet.com.br