Blog no twitter

Acompanhe o blog engenhariasoftware no twitter, acesse:
http://twitter.com/engsw

abraços

J. A.

Que PAÍS queremos construir?

Caros Colegas

Acabei de receber um convite, no mínimo, inusitado. A referida “universidade” está prestes a passar por uma reavaliação do MEC e procura por professores doutores para “engrossar o caldo” de seu pobre corpo docente.

Por questões éticas, não divulgarei o nome da universidade, da cidade e do coordenador do curso.

Acredito que a comunidade deve ficar atenta no momento de escolher ou indicar cursos destas “universidades de beira de estrada”.

Segue o e-mail convite (atente-se para a questão ortográfica).

“Bom dia José, meu nome é xxxx sou o coordenador da computação da xxxx do campus de xxxxx, estou contatando você por indicação do professor yyy e do professor yyyy, José estou contratando um Dr. para esse primeiro momento  formular duas questoes mês no estilo ENADE em uma disciplina de vossa escolha, sem necessitar estar presente no campus, ganhando 1hora aula semana para tal atividade, (algo entorno de R$140,00 reais mês)se voce se enteressar favor retorne o contato o quanto antes”.

Acho que o trecho extraído da música de Renato Russo resume a situação que chegamos (http://letras.terra.com.br/legiao-urbana/46973/). Os grifos são de minha autoria.

Nas favelas, no senado (inclusive na universidade)

Sujeira pra todo lado

Ninguém respeita a constituição (muito menos a ética)

Mas todos acreditam no futuro da nação (Será?)

Que país é esse?

…

Mas o Brasil vai ficar rico (Quem é o Brasil?)

Vamos faturar um milhão (Quem? Eu? Você? O dono a universidade em questão?)

Quando vendermos todas as almas (Olha que estamos quase lá. Tem muito gente vendida em todas as esferas)

Dos nossos índios num leilão

Que país é esse?

…

J. A.

fabri@femanet.com.br

A relação entre conhecimento e gerência: Uma visão peculiar

É uma boa pedida para analisarmos nossa postura no mercado de trabalho. É uma verdadeira aula sobre o valor do trabalho em sua vida.

 

Ensinamos corretamente a engenharia de software?

A questão acima foi delineada por um interlocutor deste blog que trabalha em uma empresa do setor produtivo de software. Dentro da referida empresa ele é responsável por recrutar programadores e testadores.

Bem, confesso que não respondi a questão no momento que ela foi elaborada. Aproveito a oportunidade para afirmar que tenho várias dúvidas sobre organização curricular das disciplinas da área de engenharia de software. A questão que intitula este post me levou a delinear algumas reflexões.

A ordem que as disciplinas são apresentadas está correta?

A grande maioria dos cursos de computação e informática apresenta, em um primeiro momento, aos seus alunos as disciplinas introdutórias da área de programação. Posteriormente são tratados os conteúdos referentes às estruturas de dados. Aspectos relacionados ao levantamento de requisitos, e modelagem sistêmica ocupam terceiro lugar nesta ordem. As informações inerentes ao projeto de software são configuradas como o quarto item. Saliento que alguns cursos possuem algumas disciplinas que apóiam o desenvolvimento do projeto, geralmente estas apresentam IDEs e linguagens de programação aos alunos, possibilitando-lhes a própria “materialização” do software. Os aspectos ligados a teste de software, em quase 100% dos cursos, são tocados (quando são) de forma superficial.

Será que não seria mais interessante organizar o currículo da área de engenharia de software a partir da seguinte equação?

Engenharia de Software = {analise de sistemas + [projeto de software + (programação + teste) + implantação+manutenção]} + processo e gestão de projetos de software

Na equação, primeiramente, resolvemos os parênteses, ou seja, as disciplinas de lógica, algoritmo e estrutura de dados seriam apresentadas nos semestres iniciais. Posteriormente proponho que os aspectos formais ligados a testes sejam discutidos na disciplina de Engenharia de Software I. Em Engenharia de Software II seriam apresentados os conceitos relacionados a projeto de software. O corpo de conhecimento ligado a implantação e manutenção do software seriam apresentados, concomitantemente, à disciplina de Engenharia de Software II. Por fim aspectos ligados a análise de sistemas, fator que requer um maior nível de abstração, seria visto no final, em Engenharia de Software III.

Ao ensinar algoritmo devemos apresentar uma linguagem de programação?

Trabalho com a disciplina de Algoritmos e Estrutura de Dados I, meu plano de ensino contempla o ensino da linguagem C (nota: nesta disciplina existem outros professores, não tenho pleno poder de decisão sobre o plano). É interessante ensinar C? Será que um compilador portugol não seria menos indigesto para os alunos? Como minimizar o número de reprovações nestas disciplinas? Fiz algumas experiências e materializei-as neste post.

Em que momento do curso devemos apresentar os conceitos ligados a orientação a objetos?

Alguns currículos apresentam a OO logo nas séries iniciais, outros inserem tais conceitos na metade. Qual é o melhor momento para apresentar estes conceitos? Sinceramente, não tenho uma posição definida sobre este assunto.

Qualidade de software é um tema importante?

Será que nosso aluno conhece os conceitos ligados a qualidade de software? Todos sabem o que é um processo produção de software? Aspectos ligados a qualidade do processo e do produto são delineados nos cursos de computação? Na maioria dos cursos, tenho a impressão que estes conteúdos são comentados superficialmente junto aos alunos.

A gestão de projetos é um conteúdo que deve ser ministrado por um professor da área de engenharia de software ou da área de administração?

Aspectos ligados a tempo e esforço para o desenvolvimento de um projeto deve ser apresentados aos alunos. Tenho certeza os conteúdos ligados a gestão de projetos são de extrema importância. Em alguns currículos, vejo que tais conteúdos estão ligados as disciplinas da à administração. Não seria interessante que um professor da área de engenharia internalizasse esse conteúdo junto aos alunos.

Acredito que a maior parte das reflexões delineadas é compartilhada por toda comunidade. A discussão está aberta, espero que todos a fomente.

J. A.

fabri@femanet.com.br

Gerente!!! Mate no ninho

A gestão em projetos é caracterizada pela aplicação de conhecimentos, habilidades e técnicas inerentes ao planejamento, execução e controle das atividades processuais que “materializam” um determinado produto ou serviço.

Faz parte da rotina de um gerente controlar qualidade, custo, prazo e o escopo de qualquer tipo projeto. O profissional que se propõe a gerenciar alguma coisa deve aglutinar as pessoas em torno de um único objetivo. Gerir expectativas  dos clientes, internos  e externos, garante a motivação necessária para a execução de qualquer projeto.

Lido com vários gerentes nos mais variados domínios de conhecimento. Alguns deles são do tipo “linha dura”, outros possibilitam aos seus comandados uma abertura maior e poucos possuem a coragem de “matar um problema no ninho”. Durante essa convivência compilei vários ensinamentos, compartilharei neste post 4 deles.

O gerente de projetos não irá agradá-lo sempre.

Em determinados momentos a pessoa responsável pelo planejamento e controle do projeto irá tomar uma atitude que não agradará a “gregos” e “troianos”. Para o gerente o mais importante é o sucesso na execução do processo, ou seja, produto ou serviço gerado deve satisfazer as expectativas ao cliente, possuir um custo baixo e alto índice de qualidade. Lembre-se, só existe equipe quando existe projeto. A partir desta afirmação questiono: Quem é mais importante, você ou projeto?

Não repasse TODOS os problemas a seus colaboradores

Cansei de ver gerentes praticarem a administração “au au”. Esse gerente repassa suas considerações e decisões para um indivíduo ou para uma comissão. Esse problema eu endereço à comissão X, esse outro problema eu endereço ao professor Y. Com base nas reflexões e direcionamentos de X e Y o gerente toma a sua decisão.  Geralmente a decisão tomada não difere dos apontamentos de X e Y. Decisões que dizem respeito, somente, ao gerente de projetos não devem ser encaminhadas a alguém.

Centralize energia no projeto

Seja focado, não desperdice tempo e recursos com algo que gere um baixo valor agregado para o projeto. Procure centralizar suas forças e atitudes em aspectos que promovam benefício para o cliente. Parece óbvio, mas essa característica não está presente em grande parte dos gerentes.

Não reinvente a roda, utilize um modelo simples, prático e funcional para resolver os problemas

A simplicidade e a praticidade favorecem a funcionalidade. Costumo dizer que existem modelos universais e que funcionam muito bem. Gerente não é sua função quebrar paradigmas teóricos, os cientistas e pesquisadores possuem essa responsabilidade. No contexto universitário presenciei o advento de várias “rodas quadradas”, principalmente no planejamento de projetos pedagógicos. Lembre-se que a qualidade e a criatividade não estão no modelo e sim nas pessoas que executam o processo.

Desobrigar-se de agradar a todos, assumir responsabilidades, centralizar energia, não reinventar a roda, levará VOCÊ gerente a matar qualquer problema no ninho.

José Augusto

fabri@femanet.com.br

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.

A situação das Fundações Educacionais não é das melhores…

José vende pão para financiar projetos assistenciais para crianças carentes. Até meados da década 1990, o pão de José tinha grande aceitação no mercado. De uns anos para cá a situação mudou um pouco, veja só:

1 – O custo de produção do pão aumentou drasticamente, pois os padeiros de José se especializaram (lembre-se que manter pessoal de qualidade exige maior remuneração).

2 – A qualidade do pão aumentou, padeiros especialistas produzem pão cada vez melhor.

3 – O nível do paladar da população diminuiu, ou seja, em matéria de pão a população está menos exigente.

4 – Surgiram várias padarias (que muitas vezes não se preocupam com a qualidade), a concorrência aumentou.

5 – Não existe uma fiscalização intensa da agência sanitária. As agências “afrouxaram” as regras.

Resultado: José vende, a cada dia, menos pão e com o passar do tempo o custo de produção só aumenta.

Plagiando Carlos Drummond de Andrade, questiono: “E agora José?”

Existem diversas fundações do terceiro setor, inseridas no contexto educacional, que se assemelham a padaria de José.  Vejam só a analogia:

1 – Algumas fundações possuem um corpo docente altamente qualificado, fato este que implica em um aumento constante no pagamento de pessoal.

2 – A qualidade do ensino, neste segmento, é indiscutível.

3 – A população brasileira a cada dia encontra-se menos exigente em matéria de ensino.

4 – Surgiram várias instituições particulares, discutíveis qualitativamente, neste segmento de mercado.

5 – Os órgão reguladores, cito MEC e CEE-SP, afrouxaram as regras promovendo a dita “expansão do ensino superior no Brasil”.

O que fazer para que o “povo não suma”?

Nos itens delineados a seguir, apresento, segundo meu ponto de vista, algumas ações que podem evitar que “José fique com a chave na mão e não abra a porta”.

1 – Com uma grande massa de mestres e doutores essas instituições podem obter ajuda das agências de fomento.

Errado. As agências dividem sua miséria com instituições solidificadas . A maioria das fundações educacionais não possui pesquisa de expressão e sequer plano de carreira.

2 – Demitir professores altamente especializados.

Errado. A maioria das fundações não está capitalizada para agir desta forma. Ao perder os professores especializados perderão a qualidade que possuem e conseqüentemente a parcela da população que procura o referido atributo debandará.

3 – Reduzir salário, cortar dissídio.

Errado. Medida paliativa lembre-se que os padeiros gostam de estudar e de se especializar, os cortes e as reduções só prorrogarão a explosão do forno da padaria. Ao aplicar cortes constantes você corre o risco de perder seus melhores padeiros.

4 – Aumentar o capital de giro se capitalizando via iniciativa privada.

Correto: As fundações educacionais devem apresentar ao mercado o lucro que elas podem dar. Se isto acontecer investimentos virão.

5 – Criar uma estrutura sólida para que o capital humano possa atuar, junto ao meio econômico, fora da sala de aula.

Correto. Ao criar uma carteira de consultorias para o setor econômico, você beneficiará a todos. As empresas absorverão conhecimento, os professores serão remunerados quando as consultorias forem realizadas e as fundações, também, serão remuneradas por manter tais professores consultores.

6 – Criar um plano de carreira.

Correto. Desde que o plano de carreira seja verdadeiro. Lembre-se, se o colaborador possuir “certa” estabilidade ele investirá tempo na resolução de problemas que gerem valor agregado para instituição. O plano de carreira alavanca a pesquisa e com isto podemos participar da divisão da miséria.

7 – Buscar estratégias diferenciadas de avaliação da qualidade.

Correto. As estratégias diferenciadas devem focar os aspectos qualitativos. Atualmente, a maioria das avaliações possui um caráter altamente quantitativo. Por que não criar um comitê de avaliação, por curso, que possua um representante docente, um representante discente e, principalmente, um representante do mercado? Acredito que uma visão externa será bem vinda.

8 – Ouvir o mercado de trabalho.

Correto. Que tipo de profissional o mercado procura? Esta questão é extremamente salutar dentro do contexto “educacional” do país. O referido contexto nunca esteve alinhado com o mercado. As iniciativas que contemplam  tal alinhamento são pífias.

9 – Que as visões estratégica e tática discutam os assuntos relevantes.

Correto. Os gestores devem canalizar suas forças no que realmente traz valor agregado. O contato direto com o setor econômico e político são as principais atribuições dos presidentes e diretores das fundações.

Em fim, a discussão está aberta.

Que José e seus padeiros mudem essa realidade. Com certeza todos têm elementos e ferramentas para isto.

E ai padeiro… quando sai à próxima “formada”?

Abraços

J.A.

fabri@femanet.com.br

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

Engenharia Software Conference

Nesta sexta-feira em São Paulo ocorre a Engenharia de Software Conference.

Aproveito a oportunidade para convidar você a participar da conferência.

A programação completa do evento pode ser acessada em: http://www.devmedia.com.br/es_conference/

J. A.

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.