Testes de Acessibilidade & Deficientes Físicos - 02

Pessoal,

abaixo estou postanto uma menssagem importante (que foi colocada no grupo QAI no yahoo groups em 27-06-2007) sobre o meu texto anterior "Testes de Acessibilidade & Deficientes Físicos" , juntamente com meu respectivo comentário. Certas coisas são fundamentais chamarmos atenção e esta é uma delas. É uma questão de consciência e bom senso.

Abraços,

Leonardo Molinari

====================================

MENSSAGEM:

--- Em qai-brasil@yahoogrupos.com.br, Juliano César Ribeiro escreveu>> vi la seus artigos sobre acessibilidade.trabalho com testes de acessibilidade especificamente com jaws e vv.> utilizo ferramentas de validação aotumática de acessibilidade aqui na empresa;> e, para ser sincero... As empresas precisam contratar testadores de acessibilidade que, sejam exclusivamente portadores de alguma deficiência, pois, infelizmente, os programas desenvolvidos, às vezes passam um pouco longe neste quesito.>

RESPOSTA:

Caro Juliano,
fico feliz por você ter lido meu artigo e estar passando em meu blog. Esta sua opnião você poderia ter deixado lá na parte de comentários, pois seria util a quem passar por lá, pois a considero deveras importante. Seu comentário estarei postando em BLOG junto minha resposta. Se nao chamarmos atenção, ninguem vê. Existem duas frases que se complementam:

"Eu penso, logo existo!"
"Eu falo, logo existo!"

Não fique pessimista, pois certas não acontecem da noite para o dia e temos de continuar mostrando a importancia e chamar para a discussão. Estarei postando outros artigos de acessibilidade e vamos discutir mais.

Por mais que o teste de acessibilidade não seja de exclusividade dos portadores de alguma deficiência, mas está cada mais claro que os mesmos são estratégicos e fundamentais neste tipo de teste. Existem dois aspectos, ou dois lados da mesma moeda:
-dependendo do nível, do tipo de aplicações, da estrutura da aplicação em si e do público-alvo, uma determinada caracteristica de teste de acessibilidade, ou foco será dado mais enfâse, e necessitanto de testadores específicos, que neste caso portadores de determinados de tipo de deficiência seriam mais requeridos que outros de outro tipo de deficiência;
-o ideial e correto era se ter pelo menos vários testadores com deficiência onde cada um deles tivesse uma deficiência diferente da outra, de modo que diversas caracteristicas e aspectos pudessem ser testados em termos de acessibilidade.
-para cada testador e portador é recomendável ter um outro testador ou analista acompanhando o teste.

Conclusão: tanto os testadores com deficiência como os que não tem deficiência sairiam ganhando, em termos de mercado de trabalho. Todos tem direitos iguais e se complementariam na realização dos serviços de teste. Sem contar que a qualidade e a profundidade do teste de acessibilidade seriam cada vez maiores. Todos teriam a ganhar.

Abraços,
Leonardo Molinari

CONTOS TECNOLÓGICOS DE QUALIDADE - 02

TÍTULO: Lords of the Bugs ou o Senhor das Falhas - A Sociedade do Teste

...Uma homenagem a J.R.R.Tolkien.

Em uma terra-empresa-média não muito distante, a muito tempo atrás havia departamento-planície dominado por grande mal denominado de Sau-Bug-Ron, o Sr. das Falhas. Este Sr. havia implantado em vários sistemas da empresa, por raiva e vingaça e pelo fato de não receber aumento, 7 Bugs adormecidos que eram acionados por um Bug principal que comandava e acionava os outros.

"... Eram Sete Bugs para atormentar,
Sete Bugs para dar prejuizo,
Sete Bugs para se vingar,
Sete Bugs insoluveis e,
Um Bug principal para governar e aos outros acionar."

Porém o que não ele contava era com o Testador-Cavaleiro que descobriu um Bug horrivel estava no programa novo que havia sido compilado. O problema é que não se sabia qual das ultimas alterações não-documentadas tinha introduzido o Bug.

O fato é que o Testador-Cavaleiro, pagou um preço terrivel para descobrir o Bug: testou tanto que teve problemas motores e teve de ser hospitalizado. Mas ele descobriu e avisou a quem era de direito sobre o programa .exe que não entrou em produção. Como o Sau-Bug-Ron era o único que mexia nos programa foi demitido. Porém o nome correto do programa-fonte que continha o Bug nunca foi descoberto, e o pilantra não disse qual era o nome.

Se tivessem sido feito uma auditoria poderiam ter descoberto onde estava o Bug, mas devido a gula e a fraqueza do Gerente envolvido o fonte nunca foi descoberto... ficou perdido num mar de fontes antigos e não utilizados ... até que foi achado pelo Desenvolvedor Vovô de nome Bug-Lun que quando achou o código antigo, ou secular, resolveu guarda-lo escondido, mas o Bug do mal nunca entrava em produção...

Bug-Lun sempre que podia olhava meu código-fonte e dizia: "Meu precioso...Meu precioso..."

Muito tempo se passou até que o Bug-Lun perdeu - sim isso mesmo !!! - o seu "precioso" no meio de tantos fontes antigos. Fizeram uma mudança radical na base de Gerência de Configuração e tudo mudou de lugar...

Mas não demorou muito e o Bug foi achado por uma outra "raça" a muito esqueçida na empresa: os "estagiários-loucos-por-TI´s" ou simplesmente "loucottis" comm eram chamados. Os loucottis são uma raça resistente de funcionários pequenos, em termos de escalão, onde se encontram. Um deles achou o fonte do program-Bug perdido, era o Bilbu Brega, como era conhecido. Com o tempo Bilbu também passou a chamar o progama de "meu precioso"...

O tempo passou e vários meses depois o pior estava acontecendo: O gerente atual de desenvolvimento (que anteriormente era analista) recebeu um e-mail do Sau-Bug-Ron avisando que ele tinha deixado um Bug-bomba em um aplicativo principal que acionaria os bugs, e isto pararia a empresa dentro de algum tempo. O fato que se ele conseguisse colocar o bug-mestre em produção este acionaria os outros. Não tinha jeito, teve de convocar o mago-mestre da empresa, que é especialista em programação, para tentar salvá-los, o Sr. GreenDalfo.

Bilbu e GreenDalfo eram amigos e a muito tempo porém o mago desconfiava do progama-Bug .
Mas o Bilbu estava velho e se aposentando como estagiário e resolveu passar o programa para o seu afilhado (explicando tudo que sabia a ele), de nome Frodus Brega. Porém Frodus passou a seguir as orientações de seu novo amigo GreenDalfo.

Para uma questão de desconfiança, resolveram fazer um teste sem muito formalismo e descobriram que um programa-Bug "acordou e começava a acionar os Bugs em Produção"... Agora a situação piorara, pois era como "acionar e acelerar" o relógio de uma bomba-relógio...

Não tinha solução, um equipe emergencial de Analistas de Sistemas, Testadores, Especialistas em Requisitos, Analistas de Produção, e Usuários Amigos foi reunida para tentar descobrir e eliminar os Bugs-filhos e o Bug-principal, que estava no programa agora em execução. Formaram a "Sociedade do Teste", como eles se denominavam. E ainda tinham de impedir que Sau-Bug-Ron invadisse o sistema através de hackers e acionasse de vez todos os Bugs. Era uma guerra imediata, pois até um antigo gerente de empresa, segundo informações secretas, e amigo de GreenDalfo estava do lado Sau-Bug-Ron: era o outro mago da programação denominado Sr. Saulomen.

Porém eles perceberam uma coisa certa: resolver o Bug do programa principal era tarefa (e "fardo") do jovem Frodus Brega...

Eles conseguiram depois se aventurar, e Testar (e se ajudarem como nunca), eliminar s bugs e o exercito de hackers, e ainda impedir que Saulomen invadisse também outros programas. Ao fim destruiram o programa-Bug-Mestre, e consequentemente destruiram a imagem de Sau-Bug-Ron. Os detalhes são um outro conto...

A paz foi restaurada e todos eguiram o seu caminho, mas aprenderam uma dura lição: a somente através da sinergia e de todos acreditarem na potencialidade de cada um é que o "mal" foi extinto...

Importante: Pessoal, devido ao alto custo da história, tive de cortar gastos pois senão o estudio-imaginação iria embarcar este conto... ups...

Escrito por: Leonardo Molinari

Testes de Acessibilidade & Deficientes Físicos

Pessoal,

este post para mim é por demais importante, pois estarei tocando em um dos pontos mais estratégicos de nossa área de Testes:

tanto o usuário como o testador podem ser deficientes físicos, incuindo aí deficiências motoras, visuais e neurológicas.

É uma questão de consciência falar deste tema, pois de que adianta escrevemos milhares de artigos e escrevermos palavras importantes se nos esqueçemos de que o defiênte físico é um ser humano como outro qualquer, pois ninguém é perfeito e está na constuição o respeito aos mesmos, sem preconceito e sem estrelismos. Porque toco neste tema? Todos nós passamos por limitações e temos defeitos, digo por mim, que aqui revelo neste blog, que quando criança sofri um trauma (susto praticado por uma babá infeliz) que custou anos de gageira (isto mesmo, g-a-g-o). Hoje (já a anos) estou perfeitamente normal, e por mais absurdeo pareça, dou palestras com uma tranquilidade enorme e sem medo de ser feliz e em geral com grande sucesso. Superei-me. Fui meu próprio deficiente e vitima de preconceito e hoje aqui falando pra vocês que todos temos uma função de transformar o teste em algo positivo.

Devido a importancia cada vez maior do tema resolve mostrar o papel do Teste de Acessibilidade, com foco em deficêntes físicos. Vamos a alguns fatos verdadeiros:

-Teste de acessibilidade não é de exclusividade para deficientes físicos, mas pelo fato destes serem consumidores e de ser cada vez importante o seu papel na sociedade, bem como fato de eles serem melhores "testadores" no que se diz acessibilidade (em termos de "usuário testador"), toma-se como verdade de que cada vez mais os deficientes fisicos fazem mais testes deste tipo, com destaque para : os deficientes visuais, deficientes motores devido ao capacidade de realizar movimentos finos, e aos deficientes que tem problemas neurológicos como epilepsia(ex: reação a cores).

-Testes de acessibildidade devem passar por um planejamento, execução, análsie como qualquer outro teste.

-A W3C possui orientações para acessibilidade e testes de acessibilidade, o que mostra uma preocupação mundial.

Vejamos abaixo um quadro por tipo do pessoas com deficiência nos EUA, onde tem cerca de 55 milhoões de defiêntes. Destaco 3 no gráfico acima: uso limitado de mão co cerca de 13,6 milhões, defiência cognitiva co cerca de 9 milhões, e deficiência visual com cerca de 2 milhões. Com isto podemos ter uma idéia melhor. Esta informação é de 1997, porém o enfoque aqui é termos uma idéia.











Mais abaixo podemos um visão de como está a legislação em alguns paises/continentes o conjunto de leis que estão sendo elaboradas para atender aos deficientes físicos, incluindo aí, tópicos e itens de acessibilade, se de forma direta ou indiretamente. Destaco o fato de que a Europa, Japão e Austrália já estarem com legislação pró´ria em andamento desde de 2006 (pendentes) e os EUA desde de 2001 a resolução 508.











Coisas que precisamos testar em acessibilidade, com uso de pessoas de defiência física:

- Utilizar vários leitores de tela.
- Testar recursos de ampliação de letra que são muito usados.
- Usar mais de um gerador de testes de acessibilidade, de modo aumentar a amplitude do teste
- Fazer de uso texto explicativos quando temos figuras

Porém quando lidamos com mouse devemos testar as seguintes combinações:

-Sem mouse apenas: com mouse desligado navegue pelo site utilizando teclado e monitor.
-Sem mouse e com software Leitor de Telas: navegar pelo site com o teclado, um software leitor de telas e com monitor.
-Sem mouse e sem monitor: navegar pelo seu site utilizando apenas o teclado com orientação do leitor de telas.


A intenção deste artigo é levar a discussão este tema. Veja o site:

==> http://www.uiaccess.com/accessucd/ut.html

Abraços e todos,

Leonardo Molinari

Agradecimento - Sucesso do livro de Gerência de Configuração

Pessoal,

agradeço a todos pelo sucesso que tem sido meu livro, pois muitos tem comprado meu novo livro para implantar ou revisar a Gerência de Configuração em suas empresas, independente dos querem e precisam entender do assunto que é um dos pilares da Qualidade.
Pelo fato de ser extremamente completo, ele serve de base para um real entendimento da Gerência de Configuração e de seus elementos, passo-a-passo.

O mesmo é fruto do trabalho inédito de 01(um) ano de trabalho de montagem do mesmo, pelo fato de ter muito material e ter trabalhado na área (e ainda estar trabalhando também) quis selecionar e colocar algo com muito carinho.

Para que não teve a oportunidade de ir ao lançamento vejam as fotos:

==> http://br.geocities.com/lm7k/fotos_lancamento.html

Para que desejar comprar e vê-lo em detalhe, passem no link abaixo:

==> http://www.visualbooks.com.br/?show=MostraProduto&chave=36576

Não esqueçam de passar também no meu site pessoal:

==> http://geocities.yahoo.com.br/lm7k/testes.html

Abaixo a todos,

Leonardo Molinari

Ferramentas Exclusivas para Testes de JSF OpenSource

Pessoal,

devido a uma valiosa pergunta do nobre colega José Augusto Agnello, resolvi postar uma grande dica para todos de meu blog. Antes, já viram meu vídeo de Boas Vindas abaixo???

Problema: com qual ferramenta testar o tão controverso JSF (Java Server Faces)??? Bem, existem alguma soluções Opensoure, porém a maioria dos grandes fabricantes (Mercury, Segue, etc) não tem features especificas para JSF (pelo menos não divulgada p/ a grande massa da internet). Então somente nos restou o velho (e bom) opensource. Aqui vão algumas dicas realistas:

JWebUnit
http://jwebunit.sourceforge.net/

Selenium:
http://www.openqa.org/selenium/

HttpUnit:
http://httpunit.sourceforge.net/

JMeter
http://jakarta.apache.org/jmeter/
veja artigo em http://forum.java.sun.com/thread.jspa?threadID=664673

Bem, pode não ser uma "Brastemp" (parafraseando um velho comercial de TV), ou o melhor dos mundos, ou uma "McLaren de F1" (antigamente era Ferrari da F1), mas mesma assim você consegue com um pouco de boa vontade testar. Com as dicas acima, procurado nos respectivos manuais/docs das ferramentas você poderá realizar seus testes. Eu sempre indico a "trilha e não o trilho". Não tenham medo de pesquisar, pois querer "tudo de graça é impossível"...

Gente,

valeu pela força e um grande abraço ao Agnello,

[]s

Leonardo Molinari

Frase da semana de 25 a 29 de junho 2007

Amigos,

para todos nós refletirmos aqui vai uma frase ou um pensamento da semana:


"Dificuldades reais podem resolvidas; apenas as imaginárias são insuperáveis!"
Theodore N. Vail...


Abraços

Leonardo Molinari

Análise da venda da Telelogic para IBM

Amigos,

uma notícia passou na semana passada desapercebida, porém com pouco alarde: a venda da Telelogic, empresa da área de soluções para área de software. Ela tem em seu portifólio soluções como o DOORS (para gerência de requisitos), Synergy (para gerência de requisitos) e o TAU/UML (para modelagem UML), dentre outras. São vários pontos:

-Os produtos dela concorrem diretamente com a linha Rational da IBM (requisitos, ger. configuração, testes, modelagem UML, etc). isto indica que foi uma compra para obsorver o que ela tiver de melhor e detonar o resto. Foi uma compra para "eliminar a concorrência".

-Penetração na Europa. Telelogic tem penetração forte na europa por ser uma empresa européia. Empresa sueca.

-Fortalecimento de suas soluções Rational em segmento de governo, pois a Telogic tem muitos clientes governamentais e industriais. Por exemplo, a Embraer (do Brasil!!!) controla todos os requisitos de projetos de seus aviões através do DOORS.

-Se fortalecer frente aos concorrentes que compraram nos ultimos anos outras empresas: a Borland comprou a Segue, a HP comprou a Mercury, a Serena comprou a Merant. Porém esta ultima tem forte penetração no segmento de Ger. de Configuração pois o PVCS era da Merant e foi absorvido na linha de produtos da Serena. A Mercury é uma potência em testes e qualidade, que possui produtos de testes de 1a linha e um produto de Ger. de Configuração, so faltando para Gerencia de Requisitos. A Borland ja tinha Ger. de Requisitos e Ger. de Configuração e so faltava testes... Resumindo: ou se fortalecia ou iria e médio/longo prazo perder espaço em novos mercados...

-A venda ainda nao foi concretizada AINDA, pois as fases são as seguintes:
a) o conselho diretor aceitou a oferta da IBM porém não tem poder de decisão,
b) oferta foi recomendada para os acionistas pelo conselho, que aprovam ou não (ESTÁ EM ANDAMENTO)
c) se os acionistas aprovarem a venda, a confirmação é encaminhada a um orgão sueco que dá o aval 100% ou não (analisa problemas legais/concorrência/trust/etc no mercado sueco).

-As etapas acima devem levar cerca de 4 a 6 meses, pelo menos. Resumindo: no fim do ano sai a confirmação.

-Alguns produtos tem filosofia dificil de compatibilizar: o ClearCase tem ger. configuração baseada em objetos, o Synergy possui baseada em tarefas... (leiam meu livro de Gerência de Configuração para entender).

Existem empresas no Brasil que serão afetadas pela venda, porém estas já estão se preparando para mudança. Espero que dê tudo certo, pois a venda de uma empresa deste porte afeta muitos em muitos países.

Veja link da notícia no IDGNOW:
http://idgnow.uol.com.br/mercado/2007/06/11/idgnoticia.2007-06-11.7168407425

Abraços

Leonardo Molinari

Frase da semana de 18 a 22 de junho 2007

Amigos,

para todos nós refletirmos aqui vai uma frase ou um pensamento da semana:


"Precisamos de homens que sabem sonhar coisas inéditas."
John Fitzgerald Kennedy (1917-1963), ex-presidente dos EUA...


Abraços

Leonardo Molinari

Montando um ambiente com soluções 100% Opensource

Artigo: Ferramentas para montar um Desenvolvimento 100% Opensource

Autor: Leonardo Molinari

Texto:

1 - Apresentação

“Como escolher um conjunto adequado de ferramentas opensource” é algo que tem se tornado um ponto emergencial em diversos projetos devido aos custos cada vez mais elevados dos mesmos. A escolha de uma ferramenta, por mais barata que seja, tem sempre um custo associado. Apresentar as principais ferramentas opensource existentes, considerando um suíte completo, que suportem a qualidade de um projeto é o objetivo deste artigo.

Para suportar a qualidade de um projeto se necessita ter principalmente os seguintes tipos de ferramentas:

• Ferramentas de Apoio a Gerência de Projetos: apoio e controle ao gerenciamento do projeto;
• Ferramentas de Gerência de Requisitos: tratam da gestão e controle dos requisitos do sistema-alvo;
• Ferramentas de Gerência de Configuração:
• Controle de Versões: gerenciamento e controle das versões dos itens de configuração (qualquer parte do software do sistema-alvo);
• Gerência de Defeitos ou Issues: gerenciamento dos itens de problemas, assuntos, ou defeitos no sistema-alvo;
• Ferramentas de Planejamento e Gerência de Testes: gerenciamento, registro e controle dos testes no sistema-alvo;
• Ferramentas de Execução de Testes Automatizados: quaisquer ferramentas que permitam a execução de testes de forma automatizada. Foco nas linguagens de desenvolvimento e nas técnicas de testes: “testes de performance em aplicações java”, “testes funcional em aplicações web/html”, etc.

2- O que não será analisado por este artigo

As ferramentas de execução de testes automatizados não serão analisadas aqui, pois para se analisar as ferramentas se deve primeiro saber qual técnica de teste que se deseja utilizar (teste de performance, funcional, unitário, etc) e depois se devee saber qual linguagem de programação-alvo de teste (java, C, C++, etc.). A partir destas variáveis temos um grande número de ferramentas cuja utilização dependerá ainda do processo metodológico que foi definido, para se poder orientar algo.

3- Lista de ferramentas opensource por tipo de ferramentas

·Tipo de Ferramenta: Apoio a Gerência de Projetos

oOpensource: dotProject.net

§http://www.dotproject.net/

§Foco no controle de atividades de tarefas em nível gerencial;

§Permite entrada de atividades em detalhe.

§Recomendado(s) (SIM ou vazio) por tipo de ferramenta: ___

oOpensource: Open Workbench

§http://www.openworkbench.org/

§Sucessor direto do MS Project. Um clone com foco na estimativa em “tarefas de trabalho”, enquanto MS Project se baseia em estimativa dos recursos para tarefas.

§Foco em múltiplos projetos e permite entrada diária das atividades em detalhe.

§Comparação entre ele e o MS Project:

§http://www.openworkbench.org/index.php?option=com_content&task=view&id=7&Itemid=6

§Recomendado(s) (SIM ou vazio) por tipo de ferramenta: SIM

oOpensource: XPMT - eXtreme Project Management Tool

§http://www.tegonal.com/en/products/xpmt/

§Misto de gerência de projeto com metodologia XP.

§Permite controlar de fato um projeto XP com tranqüilidade.

§Recomendado(s) (SIM ou vazio) por tipo de ferramenta: ___

·

·Tipo de Ferramenta: Gerência de Requisitos

oOpensource: OSRMT

§http://sourceforge.net/projects/osrmt/

§Foco 100% na gerência de requisitos.

§Boa comunidade e bem aceito no mercado.

§Semelhante ao Requisite Pro da IBM/Rational.

§Recomendado(s) (SIM ou vazio) por tipo de ferramenta: SIM

oOpensource: Jeremia

§http://jeremia.sourceforge.net/

§Foco em gerencia de requisitos, derivados de Casos de Uso da UML.

§Fraca comunidade.

§Recomendado(s) (SIM ou vazio) por tipo de ferramenta: ___

·Tipo de Ferramenta: Gerência de Configuração - Controle de Versões

oOpensource: Subversion

§http://subversion.tigris.org/

§Veio como uma evolução do CVS.

§Está se tornando padrão em substituição ao CVS, que é antigo e limitado.

§Forte comunidade e bem aceito no mercado.

§Ferramenta que deve ser levada a sério.

§Recomendado(s) (SIM ou vazio) por tipo de ferramenta: SIM

·Tipo de Ferramenta: Gerência de Configuração - Gerência de Defeitos ou Issues

oOpensource: Mantis

§http://www.mantisbugtracker.com/

§Ferramenta popular de gerência de defeitos e issues.

§Possui um pouco mais de recursos que o Bugzilla, seu concorrente direto.

§Forte comunidade e bem aceito no mercado.

§Recomendado(s) (SIM ou vazio) por tipo de ferramenta: SIM

oOpensource: Bugzilla

§http://www.bugzilla.org/

§Ferramenta popular de gerência de defeitos (foco exclusivo em gerência de defeitos).

§Forte comunidade e bem aceito no mercado.

§Recomendado(s) (SIM ou vazio) por tipo de ferramenta: ___

oOpensource: Trac

§http://trac.edgewall.org/

§Ferramenta não tão popular de gerência de defeitos e issues quanto o Mantis e o Bugzilla.

§Fraca comunidade porém é bem aceito no mercado.

§Possui ótima integração com Subversion, o que reforça sua boa aceitação no mercado.

§Recomendado(s) (SIM ou vazio) por tipo de ferramenta: ___

·

·Tipo de Ferramenta: Planejamento e Gerência de Testes

oOpensource: Testlink

§http://testlink.sourceforge.net/docs/testLink.php

§Boa ferramenta que possui comunidade forte.

§Não possui gerência de defeitos, porém possui gerência de requisitos de testes e gerência de casos de testes.

§Possui integração com diversos outros Opensource, principalmente com o Mantis e o Bugzilla.

§Fácil de instalação.

§Sua estrutura está em PHP com MySql, permitindo boa manutenção/programação e customização.

§Recomendado(s) (SIM ou vazio) por tipo de ferramenta: SIM

oOpensource: RTH

§http://www.rth-is-quality.com/home.php

§Boa ferramenta porém nova, possuindo comunidade fraca.

§Ferramenta completa: possui gerência de defeitos, gerência de requisitos de testes e gerência de casos de testes.

§Não possui integração com outras ferramentas.

§Fácil de instalação.

§Sua estrutura está em PHP com MySql, permitindo boa manutenção/programação e customização.

§Um ponto fraco claro é a parte de relatórios, porém com uma customização esta limitação se resolve.

§Recomendado(s) (SIM ou vazio) por tipo de ferramenta: SIM

4- Avaliação Geral Final

As ferramentas acima citadas não são as únicas existentes, mas são as que até o momento mais se destacam no mercado opensource.

Na lista acima existem mais de uma ferramenta por tipo de ferramenta. Neste caso a ferramenta mais indicada está destacada da pergunta “O(s) mais Recomendado(s) (SIM ou vazio) Por tipo de ferramenta” ("vazio" indica que não é a que mais recomendo, ou que menos se destaca, mas não quer dizer que não seja uma boa ferramenta pois dependerá do foco desejado e do ambiente envolvido). A única exceção são as ferramentas de Planejamento e Gerência de Testes, onde a escolha de qualquer uma delas pouco interfere no processo como uma todo. O que indicaria uma ou outra, seria o processo de testes que for utilizado.

Quando as ferramentas recomendadas são colocadas num mesmo ambiente basicamente temos uma boa integração entre a maioria delas. Não existe pacote perfeito. Mas as mesmas possuem características que quando colocadas em um mesmo ambiente é possível, com um mínimo de customização, integrá-las.

Pode ser que em um ambiente específico não se use uma ferramenta recomendada cima, porém é importante que se tenha em mente quais as vantagens e desvantagens da sua escolha.

5- Fontes

• MOLINARI, Leonardo. Gerência de Configuração - Técnicas e Práticas no Desenvolvimento do Software, Editora Visual Books, 2007, Florianópolis, 85-7502-210-5.
• ___________. Gerência de Projetos - Técnicas e Práticas com Ênfase em Web, Editora Érica, 2004, São Paulo, 85-7194-0050.
• ___________. Testes de Software - Produzindo Sistemas Melhores e Mais Confiáveis, Editora Érica, 2006, 3a Edição, São Paulo, 85-7194-959X.
• http://www.opensourcetesing.org/
• http://www.deitel.com/ResourceCenters/Software/OpenSource/OpenSourceProjectManagementApplications/tabid/856/Default.aspx

CONTOS TECNOLÓGICOS DE QUALIDADE - 01

Pessoal, segue abaixo o inicio de uma série de Contos que escrevo que são voltados para aproximar o leitor da Qualidade diária:

TÍTULO: A Guerra-dos-Requisitos, ou A Ameaça Vinda do Cubículo Distante

Ano: 2000-e-la-vai-fumaça, Hora: Naquela hora do cafezinho.

Local: o seu cubículo, ou o seu cantinho de trabalho.

Como tudo começou:

O Usuário-Robot-Maquiavélico entra no meu cubículo, e coloca claramente:

-Temos uma nova necessidade. È um requisito Funcional de Performance, baseado nos Diagramas Seqüência 33 e 57, e no Caso de Uso Buraco Negro.

Não dá nem tempo de acabar de tomar o cafezinho e contra-ataco:

-Tudo bem e tudo mal. Onde está o e-mail formalizando a necessidade? É possível ser mais especifico no que você precisa? O bom é que você está aqui e pode me ajudar.

A bomba estava apenas explodindo. Porém o usuário deu um sorrisinho sarcástico e deu uma piscadela:

-Tenho 3 reuniões hoje e preciso disto resolvido e implementado para 22 horas de hoje. Trouxe aqui o ArTudoLindo como testemunha, e qualquer dúvida fale com ele, mas tem de ser logo.

Não tinha nem visto o “capacho” que estava encostado de lado na estrada no cubículo:

-Quem não tem cão caça com gato. Um bom dia pra você!

O problema é que o “capacho” sentou-se e resolveu contar a sua vida... para ai sim esclarecer uma ou outra dúvida, mas sempre muito evasivo. Em pouco mais de uma hora ele se foi de volta para o seu cubículo e deixou a bomba em meu colo.

O fato é que precisava entender tecnicamente o requisito. Aí a Guerra se iniciou. Não tinha jeito, precisava falar com o “outro”... Os requisitos contradiziam o que já estava escrito e teriam impacto gravíssimo. Chamei o Usuário-Robot e tive que confrontá-lo com o “outro”.... Papo de cafezinho virou paulada de panela... Dentro em pouco já havia mais 10 pessoas na discussão e o pânico tomou conta:

-Se este requisito passar será o caos.... não!!!!...

-Meu Deus!!! Todos seriam impactados por estas mudanças...

Chegava a ter torcida. Uns contra e outros a favor. No final deu empate. Ao fim os dois colocavam:

-Eu implemento X e Y e mudo apenas o meu processo.

-E Eu apenas mudo meu processo.

Saí de fininho e a “bomba” já estava com outro.

Moral da História (sem isto não haveria graça!): Requisito precisa vir por escrito e documentado. De boca não dá certo. Em uma briga de conceitos, deixe os donos dos conceitos se entenderem. E acima de tudo requisito não é bomba, requisito é necessidade.

Escrito por: Leonardo Molinari

Olá pessoal,

este é o meu blog "Diário da Qualidade", o qual contarei minhas experiências e troca de ideias contantes em Qualidade de Software: Testes, Requisitos, Gerência de Configuração, etc ! Participe você também !

Vamos transformar a Qualidade para Além do Software...

Abraços ....

Leonardo Molinari
=============================
lm7k@yahoo.com.br
=============================
Blog: http://diariodaqualidade.blogspot.com/
Pág. Pessoal: http://geocities.yahoo.com.br/lm7k/testes.html

Veja meu vídeo de boas vindas ao meu blog: