Qualidade de Software

Os bugs também têm sentimentos

2011-10-05T10:46:00.000-03:00

Muitas vezes uma imagem diz mais do que mil palavras. No blog Cartoon tester, Andy Glover faz uso de imagens extremamente simples, mas que transmitem de maneira objetiva conceitos e práticas interessantes relacionadas com as atividades do engenheiro de testes.
A imagem abaixo é do post do blog, que fala de maneira correta sobre algumas atitudes que devemos ter no nosso dia a dia quando encontramos bugs. Abaixo, uma breve explicação dos pontos mencionados.

Se você encontrar um bug:

1 – Reporte-o, bugs não gostam de ser esquecidos.
Diversos motivos podem levar um testador a esquecer de reportar algum defeito encontrado, prazos apertados, tarefas acumuladas, desorganização ou simplesmente o fato de que algumas vezes os defeitos são encontrados antes mesmo dos testes, em conversas informais, treinamentos, etc.. e nem sempre os envolvidos tomam as devidas ações nessas situações.

2 – Conheça-o melhor, bugs gostam de ser compreendidos.
Antes de reportar um defeito, devemos entender por completo seu comportamento, sua abrangência e quais são seus impactos.

3 – Tire uma foto, bugs gostam de guardar recordações das ocasiões.
Screenshots, fotos e inclusive vídeos ajudam a evidenciar melhor a reportagem de um defeito, facilitando o entendimento do desenvolvedor e evitando CRs reabertas.

4 – Conheça seus companheiros, bugs são socialites.
Ao encontrar um defeito é comum que outros bugs estejam localizados nas suas redondezas, por isso é importante a varredura nas funcionalidades relacionadas para rapidamente detectar novas falhas.
5 – Reporte rapidamente, do contrário os bugs se estabelecem e fazem moradia.
Agilidade na reportagem permite que sua correção também seja antecipada, evitando que outros bugs causados pela falha já existente sejam revelados.

6 – Seja honesto, bugs não gostam de fofocas.
Classificação de severidade e prioridade supervalorizadas, melhorias registradas como defeitos, entre outros problemas frequentes, causam problemas na comunicação da equipe e atrapalham o andamento das atividades.

7 – Guarde como o conheceu, bugs são românticos.
Ao encontrar um defeito, a primeira tarefa é sempre de verificar quais foram os passos prévios para detecção do problema, reportar como podemos reproduzir o issue é essencial para os desenvolvedores durante a correção e também para os testadores no momento da verificação das correções.

8 – Não o ignore, bugs podem morder quando não apreciados.
Em meio a tantos bugs, normalmente encontrados durante os testes, é comum que em alguns momentos desprezemos alguns defeitos encontrados, por acreditarmos que os mesmos são irrelevantes ou nunca serão corrigidos. Porém, já cansei de ver defeitos ignorados sendo reportados posteriormente por clientes ou quando vistos por outros ângulos gerando consequências graves para o sistema.
Adicionaria a lista de atitudes a verificação dos defeitos já existentes, prática bastante simples, mas que muitas vezes é relegada, e que pode evitar trabalho desnecessário de diversas pessoas.

E vocês concordam com os tópicos? Sentiram falta de mais alguma atitude?

Preparatório intensivo CBTS

2011-09-27T19:24:00.000-03:00

Fundamentos em teste de software: preparatório intensivo CBTS

DATA E HORÁRIO: 04 e 05 de novembro (sexta das 18h30 às 22h30 e sábado das 9h00 às 18h00).
CARGA HORÁRIA: 12 horas
MODALIDADE: A distância (aula ao vivo via webconferência, com interação com o instrutor).
INVESTIMENTO: R$ 290,00 até 18/outubro e R$ 350,00 após esta data. Desconto de 10% para pagamentos à vista.
INCLUI:

Certificado impresso
Acesso ao material oficial certificado pela ALATS em formato virtual
Dicas e simulados para a prova

INSTRUTORA: Érika Hmeljevski: Instrutora oficial da ALATS, tendo atuado como instrutora do treinamento CBTS desde 2007. É certificada CBTS e CTFL.
Implementadora oficial do MPT.BR, Modelo Brasileiro de Processo de Teste de Software. Representa a Associação Latino Americana de Teste de Software (ALATS) como Diretora do estado de Santa Catarina. Atua na área de testes e qualidade de software há 8 anos. Hoje coordena a equipe de Qualidade e Teste de Software do Instituto Stela, além de atuar como consultora e instrutora em teste de software pela Supreme Quality.
INFORMAÇÕES E INSCRIÇÕES:
treinamento@supremequality.com.br
48 4052-9897
47 8848-7076
EMENTA:

Introdução ao Processo de Teste
Processo de Teste
Ambiente de Teste
Análise de Risco
Planejamento de Teste
Elaboração do Teste
Executando o Plano de Teste
Gestão de Defeitos
Teste de Aceitação
Relatórios de teste
Estimativa de teste

INSCRIÇÕES CBTS: www.alats.org.br
Veja Também: SIMULADO CBTS

BRATESTE 2011

2011-09-26T18:42:00.001-03:00

IV Seminário Brasileiro de Teste de Software

O BRATESTE 2011 é o maior e mais importante evento sobre Teste de Software da América Latina, um local onde profissionais, a indústria e a academia se reunem para apresentar pesquisas, estudos de caso, produtos, serviços, trocar experiência durante os 4 (quatro) dias do evento, divididos entre tutoriais e seminário.
Não perca a oportunidade de aprender com renomados especialistas em Teste de Software, nas mais variadas áreas de conhecimento, tais como: Testes Ágeis, Gerência de Teste, Melhoria de Processo, Técnicas de Teste, Automação, Métricas e muito mais.

O evento, em sua quarta edição, será realizado de 11 a 14 de outubro de 2011 e terá 2 (dois) dias de tutoriais (pré-seminário) e 2 (dois) dias de seminário, com mais de 20 palestras no total.

Por que participar do BRATESTE 2011?

Networking
Oportunidade para trocar experiência com outros profissionais e renomados especialistas
Serão apresentados e discutidos os assuntos mais relevantes e atuais
Oportunidade única para aprender com especialistas renomados e reconhecidos internacionalmente
Participação da indústria, da academia e de profissionais e especialistas
Conhecer as novidades em produtos e serviços durante a visita aos estandes

Quem deve participar?

Diretores
Gerentes de Teste e Gerentes de Projeto
Profissionais da área de Teste e Qualidade de Software
Desenvolvedores
Pesquisadores
Estudantes

Onde será o evento?

Grand Hyatt Hotel

Avenida das Nações Unidas, 13.301
São Paulo, São Paulo, Brasil 04578-000
Tel.: +55 11 2838-1234
Fax: +55 11 2838-1235

Mais informações: www.alats.org.br/

Palestrantes: www.alats.org.br/portal/palestrantes-brateste-2011.html
Programação: www.alats.org.br/portal/programacao-do-evento.html
Tutoriais: www.alats.org.br/portal/tutoriais-brateste-2011.html
Palestras: www.alats.org.br/portal/palestras.html

Qualidade de Software

2011-06-22T14:05:00.001-03:00

Autor: André Koscianski, Michel dos Santos Soares

Editora: Novatec

I.S.B.N.: 8575221124
Edição: 2 / 2007
Idioma: Português
País de Origem: Brasil

Este livro aborda as principais tecnologias, metodologias e processos utilizados atualmente em desenvolvimento de software. Os fatores que influenciam a qualidade são discutidos em amplitude, com ênfase nos aspectos práticos, mas sem deixar de mencionar a fundamentação teórica essencial.

Os tópicos são tratados de forma inter-relacionada e abrangem:

modelos de processos organizacionais, como CMM e CMMI;
modelos de processos individuais e de equipe, como PSP e TSP;
o modelo brasileiro MPS.BR, lançado em 2005;
metodologias ágeis, como XP e SCRUM;
algumas das principais normas internacionais, como SQuaRE, ISO/IEC 25000:2005, ISO/IEC 12207 e ISO/IEC TR 15504;
programação e sua relação com a qualidade;
teste de software.

São apresentados diversos softwares de apoio, além de ampla bibliografia e referências a sites relevantes.

Trata-se de um verdadeiro guia para profissionais da área, podendo ser usado em cursos de graduação e pós-graduação como referência principal na disciplina de Qualidade de Software e complementar para Engenharia de Software e Programação.

Retificação Simulado CBTS

2010-05-04T13:25:00.004-03:00

Pessoal,

Recebi um e-mail de um amigo (Ueslei Silva - mptbr.blogspot.com) referente uma questão do Simulado CBTS com respostas que podem gerar dúvidas.

Segue trecho do e-mail:

Subject: Simulado CBTS

Date: Mon, 3 May 2010 16:55:13-0300

Marcelo,
Analisando a questão acima:
Como testaria o limite máximo de digitação de um campo numérico e que não apresenta essa informação?
Como testaria os limites inferior e superior para um campo numérico que não tenha informado os valores limítrofes?
Considerando as questões acima, minhas opções, seriam milhares de testes... neste caso acho que a opção indicada como correta, não seria a melhor.

E eu concordo com ele.
Realmente. Sem especificação, realizar teste que garanta limites do campo, resultaria em uma infinidade de testes.

Portanto, na próxima versão do simulado (estou corrigindo erros de digitação e coisas do gênero, mas está quase pronta) vou alterar esta questão.

Conto com a compreensão dos que já realizaram o simulado. E obrigado Ueslei pela colaboração.

Dicas Exame CBTS 2010

2010-04-26T14:53:00.005-03:00

Caros candidatos à Certificação Brasileira de Teste de Software, o "resumão" abaixo foi elaborado pelo Jonathan Rodrigo, ele o utilizou como referência complementar na prova do ano passado.

Aproveite para ver também: Simulado - Certificacao CBTS

Erro: Falha humana, normalmente é classificada como erro uma linha de código.
FURPS: É um modelo metodológico (do RUP)
Estágios, fases ou níveis de testes: Unitário / Integração/Sistema / Aceite.
Principal objetivo do teste: Encontrar o maior número de defeitos.
Custo do Software: O custo do software é o valor do desenvolvimento+o valor da manutenção.
Automação: Na certificação quando se falar de automação, estarão se referenciando á todo o processo de teste, deste seu planejamento, elaboração dos casos de testes e sua entrega.
Risco: Não existe risco 0% e nem 100%, para ser realmente um risco ele estará entre 10% á 90%.
Risco: Possibilidade de falha x prejuízo causado pela falha.

"Uma das maneiras de reduzir os riscos do software é testá-lo adequadamente"

Fluxo de gerenciamento de riscos

Modelo V: É o modelo que mostra a integração das atividades de desenvolvimento e teste de software, seu principal objetivo é mostrar o paralelismo entre as atividades.
Regra 10 de Myers: Prega que quando mais cedo o defeito/erro ou falha for encontrado mais barato será o seu ajuste.
Rex Black
Bohem
Estratégia de teste: Para elaborar uma estratégia é necessário saber O Que iremos testar, Como estes teste irão ser realizados e Quando, em qual momento será executado os testes.
Definições:

O Que: Neste momento levantamos as características da qualidade que iremos dar atenção nos testes.
COMO: Quais técnicas de teste iremos utilizar para atender os testes referentes às características levantas.
QUANDO: Em qual Estagio/Fase ou Nível iremos realizar os teste.

Ambiente de teste: O livro define ambiente de teste todas as pessoas envolvidas, os hardwares e softwares que farão parte do projeto.
Plano de Teste: É onde todas as definições do projeto de teste devem constar, por exemplo: A definição do ambiente de teste.
Os apontamentos dos riscos mais críticos, pois cada projeto tem suas particularidades e é no plano de teste onde definimos as regras (escopo) do projeto.
Preparação dos Volumes: Esta atividade é realizada na elaboração dos casos de teste.
Definição de Risco: Risco é a probabilidade de algo acontecer ou não trazendo benéficos ou malefícios ao projeto. (Chance de falhar x prejuízo causado).
Analise de risco: Na analise de risco é levado em conta a Probabilidade e a Criticidade, EX:

Se Probabilidade baixa e Criticidade alta = Risco Médio.
Se Probabilidade média e Criticidade baixa = Risco Baixo.

Testware: São todos os documentos que são gerados no projeto, obs.* todos estes documentos devem ser armazenados na ferramenta de GC
Mitigação: É a forma de controlamos um risco que ainda NÃO aconteceu, para que ele não venha se tornar uma realidade.
Contingência: Quando o Risco ACONTECEU, então Iniciamos o plano de contingência "Outra estratégia" resumindo o plano B.

Formas de Estabelecer um risco (QAI).

Intuição ou discernimento: Onde um técnico experiente usa sua intuição aliada com sua experiência e aponta um risco que se ocorrer ira custar muito caro seu concerto.
Consenso: A equipe entra em consenso referente á probabilidade de um risco acontecer.
Formula de Risco: O risco é calculado através de uma formula onde existem dados financeiros que permitem medir o custo da perda pela ocorrência do risco.
Estimativas de perdas anuais: É a combinação do consenso com a fórmula de risco.

Artefato de saída do Planejamento: O artefato de saída do planejamento é o PLANO de TESTE.

Quando é necessário criar mais de um plano de teste para um mesmo projeto?
Segue abaixo a exemplificação:

Só para lembrar "tudo que acontecer na definição estará dentro do PLANO DE TESTE".

Teste de Aceite

Responsável: Usuário
Objetivo: garantir que o que foi solicitado foi criado e se este funcionado corretamente.

Estar APTO ou FIT: Este termo é o mais utilizado para dizer que o software está pronto ou dentro das conformidades de aceite.

Para a fase do Aceite é necessário criar um plano de Aceite.

Gerenciamento de defeitos: Esta atividade é realizada no momento da execução dos testes, onde observamos quantos Bug´s estão sendo abertos/ Fechados.
Gestão de defeitos: É a melhoria continua, realizando prevenção dos defeitos, ele se inicia desde o inicio do projeto.

Baseline: Fotografia do momento atual do projeto.
Diferença de Baseline e GC:

Baseline é o projeto geral e GC é de doc á doc.

Releases: São oriundos das baselines, são utilizadas para entregas para o teste ou produção.

Alguns detalhes importantes na hora de reportar os Defeitos:

-Resumir: Reportar claramente, mas de forma resumida.
- Precisão: É um defeito ou poderia ser um erro do usuário EX: Erro de entendimento. Portanto, descrever realmente o que foi executado para que a falha fosse detectada.
-Neutralizar: Reportar apenas os fatos, sem humor, sem emoções.
-Isolar:
- Generalizar: Procurar entender o problema de forma genérica.
- Reproduzir: Reproduzir um defeito ao menos duas vezes antes de reportá-lo
-impacto: Qual o impacto deste defeito para o cliente?
-Evidencie: Evidencie a existência do defeito encontrado

Relatórios IEEE

Log de teste
Relatório de incidentes
Relatório sumário

APT: para se ter o APT (Analise de ponto de teste) é necessário ter o APF(Analise de ponto de função). O APF mede somente o teste Unitário e de Integração.
O APT observa TAMANHO e ESFORÇO.
Se tiver muitas funcionalidades é pior para controlar.
Se tiver poucas ferramentas de gerenciamento é pior para controlar.
O que o APT analisa para seu calculo?
O APT analisa o Tamanho do sistema, avalia a estratégia e o nível de produtividade da equipe.

PTDF – Ponto de teste Dinâmico de uma funcionalidade
PF-Tamanho da função em ponto de função

Se a equipe é MAIS qualificada, MENOR será o QET
QET – Qualificação da equipe de teste
AT – Ambiente de Teste
HTP – Horas de teste primárias.

O QET varia de 0,7 á 2.0

Formula:
QET + AT = HTP

Referência: Base de conhecimento em teste de Software
Veja também: Simulado - Certificacao CBTS

Formação em Teste de Software - Alphaville‏

2010-04-26T14:34:00.000-03:00

Iterasys, confirma o início da 18ª Turma do Curso de Formação em Teste de Software.
Local: Alphaville
Data: 03 de Maio à 15 de Junho
Horário: 17:30 ás 21:30

Sobre a Iterasys:
Principal centro de treinamento brasileiro em Teste de Software e Garantia da Qualidade, único credenciado ALATS, BSTQB/ISTQB e QAI.

Sobre o Curso de Formação em Teste de Software:
Treinamento com 120 horas, sendo 64 horas sobre processos e técnicas de Verificação e Validação acrescidas de 56 horas práticas em automação de testes com as ferramentas VirtualBox, Mantis, Testlink, NUnit, Code Analysis, JMeter, Badboy e Selenium.

Próximas Turmas:

São Paulo - Segunda à Sexta - 18:45 às 22:45 - 10 de Maio à 22 de Junho
São Paulo - Sábados - 09:00 às 18:00 - 29 de Maio à 25 de Setembro
Campinas - Sábados - 09:00 às 18:00 - 29 de Maio à 25 de Setembro
Brasilia - Sábados - 09:00 às 18:00 - 29 de Maio à 25 de Setembro

Inscrições através do site: http://www.iterasys.com.br/
contato @ iterasys . com . br
(11) 3254-7625

Certificação CBTS - Simulado

2010-04-20T19:00:00.012-03:00

Para quem está se preparando para o exame de Certificação CBTS, ou quem deseja testar seus conhecimentos em Qualidade de Software, vale a pena dar uma olhada na página Simulado CBTS.
Ele foi elaborado conforme o exame CBTS:

Número de questões: 100
Duração da avaliação: 3 Horas
Critérios de aprovação: 75% de acertos

Disponível também em versões menores (tempo proporcional à quantidade de questões):

50 questões em 1h30
25 questões em 45 minutos
10 questões em 18 minutos

Os simulados CBTS disponiveis devem ser utilizados apenas como matéria de apoio.

A referência bibliográfica básica recomendada pela ALATS é o Livro:
Base de Conhecimento em Teste de Software - 2a. edição
Rios, Emerson; Cristalli, Ricardo; Moreira, Trayahú & Bastos, Aderson. - S.Paulo, Martins Fontes, 2007.

Em breve disponibilizarei outros simulados com os mesmos propósitos.
Sugestões são bem vindas.

Apresentando XP. Encante seus clientes com Extreme Programming

2010-04-05T19:12:00.002-03:00

Resumo: Este artigo tem por objetivo apresentar a metodologia de desenvolvimento ágil de software denominada Extreme Programming. Serão abordadas, de forma resumida, as práticas, valores, e os papéis disponíveis a cada integrante de uma equipe de XP. Alguns comparativos com outras metodologias são feitas ao decorrer do trabalho enaltecendo as propriedades que definem a Extreme Programming.

2.1. Valores da XP

2.1.1 Feedback
2.1.2 Comunicação
2.1.3. Simplicidade
2.1.4. Coragem

2.2. Práticas

2.2.1. Cliente Disponível ou Presente
2.2.2. Jogo do Planejamento
2.2.3. Stand up meeting
2.2.4. Programação em par
2.2.5. Refactoring
2.2.6. Desenvolvimento guiado por testes
2.2.7. Código coletivo
2.2.8. Padrões de desenvolvimento
2.2.9. Design Simples
2.2.10. Metáfora
2.2.11. Ritmo Sustentável
2.2.12. Integração contínua
2.2.13. Releases curtos

2.3. Equipe XP

2.3.1. Gerente de projeto
2.3.2. Coach
2.3.3. Analista de teste
2.3.4. Redator técnico
2.3.5. Desenvolvedor

3. Conclusões
4. Referências

1. Introdução

A muito tempo a indústria de software vem passando por grandes transformações e novos desafios, entre eles desenvolver softwares com qualidade, no menor tempo possível e que atendam as necessidades dos clientes.
Com estes novos desafios a indústria de software passou a dar valor a algumas áreas da informática, como a engenharia de software e qualidade de software, com intuito de atender as exigências do mercado.
A indústria começou a utilizar metodologias de desenvolvimento de software, adotou métricas e padrões para alcançar níveis aceitáveis de qualidade, prever custos e prazos em seus projetos. Porém ainda são poucos os projetos que conseguem obter pleno sucesso em seu desenvolvimento, onde prazo e orçamento estabelecidos e as necessidades do cliente sejam realmente atendidas.
Pesquisa feitas pelo Standish Group International em 1994, um pouco antes da adoção de metodologia de desenvolvimento pelas indústrias, apontam que apenas 16, 2 % dos projetos de software atingiam sucesso (prazo, orçamento e funcionalidades atendidas). Em 2002 esta taxa havia subido para 34 %, ou seja, um aumento de 100 % em 8 anos. Mas estas taxas ainda se encontram muito aquém do esperado pelo mercado.
As metodologias utilizadas nos projetos pesquisados eram as mais variadas, podemos citar modelo em cascata, modelo iterativo e alguns com modelo em prototipação. Neste trabalho será utilizado o termo desenvolvimento tradicional para os projetos que se utilizem do modelo em cascata e todos os outros que se baseiam nele.
Analisando os motivos para a baixa taxa de sucesso dos projetos desenvolvidos com modelos tradicionais, cita-se os principais motivos e bastante comuns entre eles:

Tempo elevado entre cada fase do projeto, não acompanhando as mudanças de requisitos do projeto;
Falta de conhecimento por parte do cliente da sua real necessidade, dando margem às especulações dos desenvolvedores;
Forte linearidade no desenvolvimento do projeto;

Focando nas fragilidades do modelo tradicional, surgiram metodologias para desenvolvimento ágil de software. Cita-se algumas características destas metodologias:

Foco nas pessoas, não no processo, evitando especulações dos desenvolvedores;
Atender as reais necessidades do cliente, na velocidade e praticidade por ele desejada;
Ausência de linearidade no desenvolvimento do projeto;
O cliente aprender a suas reais necessidades durante o projeto e repassar esta novas necessidades a equipe de desenvolvimento;

Uma destas metodologias de desenvolvimento ágil é o Extreme Programming , metodologia que prima a qualidade do software desenvolvido, que atenda as reais necessidades do cliente e seja entregue dentro do prazo definido. Esta metodologia será detalhada a seguir.

2. Extreme Programming (XP)

XP é uma metodologia para desenvolvimento de software ágil, com qualidade e que atenda as necessidades do cliente. Alguns praticantes definem a XP como a prática e a perseguição da mais clara simplicidade, aplicado ao desenvolvimento de software.
Uma metodologia voltada para projetos cujos requisitos mudem com freqüência, utilizem desenvolvimento orientado a objetos, equipes de até 12 desenvolvedores e desenvolvimento incremental.
A XP Busca o máximo de valor a cada dia de trabalho da equipe para o seu cliente. Em um curto espaço de tempo o cliente terá um produto que possa ser utilizado, podendo aprender com o mesmo e reavaliar se o que foi desenvolvido é realmente o desejado.
Por ser uma metodologia recente, a XP sofre mudanças em suas concepções e, portanto, é comum encontrar variações. A adaptação ao ambiente de desenvolvimento deve ser levada em conta, se um valor trouxer mais prejuízos do que benefícios é necessário relavaliar a utilização desta metodologia.
A XP é organizada em torno de um conjunto de práticas e valores que atuam perfeitamente para assegurar um alto retorno do investimento efetuado pelo cliente. A seguir serão apresentados os valores e em seguida as práticas.

2.1 Valores da XP

Os valores são as diretrizes da XP. Eles definirão as atitudes das equipes e as principais prioridades da metodologia.
Para uma empresa estar realmente utilizando o XP, ela deve respeitar e utilizar todos os valores e práticas listadas nos próximos capítulos e caso um destes valores ou práticas não seja utilizado pela empresa, esta empresa não está trabalhando com a metodologia XP.

2.1.1 Feedback

O cliente aprende com o sistema que utiliza e com este aprendizado consegue reavaliar o produto recebido, com isso pode realimentar a equipe de desenvolvimento com as suas reais necessidades. Com o feedback , o cliente conduz o desenvolvimento do seu produto, estabelece prioridades e informa aquilo que é realmente importante.
Analogamente, há o feedback dado pelo desenvolvedor ao cliente, onde o mesmo aponta riscos, estimativas e alternativas de design . Este retorno é o aprendizado do desenvolvedor sobre o que o cliente deseja.
Com este valor, o tempo de defasagem entre as fases do projeto são extremamente pequenos, o cliente está o tempo todo em contato com a equipe de desenvolvimento, muito diferente dos modelos tradicionais, onde o cliente entrava em contato com a equipe um bom tempo depois do último feedback dado.
Um ponto que muitas empresas de software falham é não dar valor ao que o cliente realmente deseja, utilizam cegamente metodologias e acabam esquecendo o real propósito de um software: facilitar o trabalho de pessoas.
Com isto muitos sistemas acabam dificultando e burocratizando as tarefas das pessoas e como defesa as empresas alegam ter um produto genérico e que atenda as normais legais.

2.1.2 Comunicação

Para que o feedback entre cliente e desenvolvedor possa ser efetuado com sucesso é necessário ter uma boa comunicação entre eles. A XP prega que esta comunicação ocorra da forma mais direta e eficaz possível, oferecendo agilidade aos assuntos tratados. Recomenda-se o contato direto (face-a-face) entre cliente e desenvolvedor, para evitar qualquer tipo de especulação ou mal entendido entre as partes e para que possíveis dúvidas possam ser resolvidas de imediato.
Além de sanar as dúvidas no desenvolvimento, o cliente deverá estar disponível para a equipe, ou mesmo presente no ambiente de trabalho da empresa. Isto fará com que o cliente entenda o sistema e enriquecerá os relacionamentos pessoais, criando um elo de parceria e confiança mútua.
Algumas equipes não se adaptam bem a este valor. Este problema deve ser trabalhado em conjunto com a equipe. Enquanto não se acostumarem a falar e a trocar idéias com seus companheiros o sucesso da metodologia estará comprometido. Membros introvertidos são deseconselháveis para equipes de XP.

2.1.3 Simplicidade

Para que o cliente possa aprender durante o projeto e consiga dar o feedback necessário à equipe, não basta apenas uma boa comunicação, é necessário que os desenvolvedores implementem da forma mais simples possível o que o cliente deseja.
A lei é: faça a coisa mais simples que pode funcionar. Com esta filosofia, o cliente terá a funcionalidade rapidamente e da forma desejada, dando um feedback instantaneamente evitando especulações. O desenvolvedor deve implementar apenas o necessário para que o cliente tenha seu pedido atendido.
Ser simples não é um ato de desespero, é um ato de consciência e absoluta precisão. Muitas pessoas confundem simplicidade e facilidade. O mais simples nem sempre é o mais fácil e também não é escrever menos código. Simplicidade significa codificar o necessário para que um requisito seja atendido e entregue ao cliente.
Evita-se suposições, o futuro é incerto e por causa disso não necessita atenção. Os requisitos evoluem gradativamente em conjunto com o sistema e a arquitetura do projeto. Algumas vezes, o que é necessário hoje será descartado amanhã, e outras vezes o que seria necessário num futuro próximo nunca será utilizado.

2.1.4 Coragem

Por ser um processo de desenvolvimento novo e baseado em diversas premissas que contrariam o modelo tradicional, o XP exige que os desenvolvedores tenham coragem para:

Desenvolver software de forma incremental;
Manter o sistema simples;
Permitir que o cliente defina prioridades;
Fazer desenvolvedores trabalharem em pares:
Investir tempo em refactoring ;
Investir tempo em testes automatizados;
Estimar estórias na presença do cliente;
Expor código a todos os membros da equipe;
Integrar o sistema diversas vezes ao dia;
Adotar ritmo sustentável de desenvolvimento;
Abrir mão de documentos que servem como defesa;
Propor contratos de escopo variável;
Propor a adoção de um processo novo.
Assumir em relação ao cliente possíveis atrasos e problemas de implementação;
Colocar desenvolvedores e clientes frente a frente;
Implantar uma nova versão do sistema no cliente semanalmente;
Apostar em seus colaboradores aumentando suas responsabilidades;
Modelar e documentar apenas quando for de extrema necessidade.

2.2 Praticas da XP

Como o nome já diz, as práticas são um conjunto de atividades que deverão ser seguidas pelas equipes que desejam utilizar a XP.
Os valores já apresentados somados a estas práticas são um conjunto ? entrelaçado ? de boas atitudes. A fraquesa de umas é compensado por outra e assim fecha-se um ciclo fortemente dependente.

2.2.1 Cliente disponível ou presente

O XP trabalha com uma visão diferente do modelo tradicional em relação ao cliente. O XP sugere que o cliente esteja no dia-a-dia do projeto, acompanhando os passos dos desenvolvedores, onde a sua ausência representa sérios riscos ao projeto.
As funcionalidades do sistema são descritas brevemente em estórias em conjunto com os testes conceituais e serão estes os indicadores para uma boa implementação. No momento que os desenvolvedores irão implementar as estórias nada mais eficaz do que dialogar com o cliente para entender a estória, fazendo-se necessária a presença do cliente no ambiente de desenvolvimento.
Ao terminar uma estória, com a presença do cliente, a mesma poderá ser validada rapidamente e a equipe receber o feedback necessário sobre a funcionalidade, criando ciclos rápidos e precisos.

2.2.2 Jogo de planejamento

A XP utiliza o planejamento para assegurar que a equipe de desenvolvimento esteja trabalhando naquilo que gere o máximo de valor para o cliente. Este planejamento é feito várias vezes durante o projeto. é o momento onde o cliente solicita as funcionalidades desejadas através de estórias, onde a equipe estima o custo de cada estória e planeja as releases e as iterações.
Todas as funcionalidades do sistema são descritas em estórias, pequenos cartões em que o cliente deve descrever o que deseja com suas palavras e da forma mais simples possível. Lembrando que a simplicidade também deve ser respeitada pelo cliente.
Após a definição das estórias é necessário estimar o tempo das mesmas para que o cliente priorize o que deve ser implementado. A XP utiliza uma unidade chamada ponto , que refere-se a um dia de trabalho ideal do desenvolvedor, onde o mesmo não precisaria atender telefonemas, participar de reuniões, ou seja, estaria preocupado apenas com a estória em questão.
Muitas vezes algumas estórias consomem semanas de trabalho, oferecendo uma certa dificuldade de serem estimadas. A XP recomenda que estas estórias sejam quebradas em tarefas menores e que as mesmas não utilizem mais que alguns pontos de um desenvolvedor, recomenda-se 4 pontos ao máximo.
Em cada estória é escrita a quantidade de pontos estimadas pelo desenvolvedor, o XP recomenda que as estimativas sejam efetuadas em equipe e se possível com a presença do cliente para que durante a estimativa eventuais dúvidas sejam sanadas.
O XP tem por objetivo gerar valor para o cliente ao longo do projeto, para isto o software é desenvolvido de forma incremental, onde a cada entrega o cliente possa utilizar o sistema e obter benefícios do mesmo. Estas entregas o XP denomina como sendo releases , pequenos intervalos de tempo, máximo 2 meses, onde funcionalidades que gerem valor ao cliente sejam entregues.
A divisão dos releases é efetuada no início do projeto, geralmente com tamanhos fixos e pequenos. Após esta divisão o cliente define as estórias que farão parte dos releases e tenta-se evitar um planejamento muito longo, pois na entrega de cada release o cliente aprenderá com o sistema e possivelmente irá alterar as estórias para o próximo release .
Mesmo os releases sendo efetuados em curto espaço de tempo, continua representando um tempo muito longo para o feedback do cliente. Por esta razão os releases são divididos em espaços menores, chamados de iterações .
Uma iteração contêm um conjunto de estórias a serem implementadas, com duração entre uma a três semanas, onde ao final da mesma o cliente possa validar as implementações efetuadas e fornecer o feedback necessário à equipe.

2.2.3 Stand up meeting

O dia de trabalho de uma equipe XP sempre começa com um stand up meeting . é uma reunião rápida pela manhã, com aproximadamente 20 minutos de duração e onde seus integrantes permaneçam preferencialmente em pé.
Segundo estudos uma reunião em pé é mais rápida, evita bate-papos paralelos e faz os integrantes irem diretamente ao assunto. Mais uma vez, ágil e simples.
A reunião tem por objetivo atualizar a equipe sobre o que foi implementado no dia anterior e trocar experiências das dificuldades enfrentadas. Neste momento também são decididas as estórias que serão implementadas no dia e em conjunto definir os responsáveis por cada uma delas.

2.2.4 Programação em par

O XP exige que todo e qualquer código implementado no projeto seja efetuado em dupla, chamada de programação em par. é uma técnica onde dois desenvolvedores trabalham no mesmo problema, ao mesmo tempo e no mesmo computador. Um deles é responsável pela digitação (condutor) e outro acompanhando o trabalho do parceiro (navegador).
Esta prática agrega diversas técnicas de programação, enquanto o condutor codifica o problema o navegador permanentemente revisa o código digitado, onde pequenos erros de programação que demoraria algumas horas para serem depurados, facilmente são percebidos pelo navegador da dupla.
Um dos grandes benefícios da programação em par é a troca de experiências e idéias entre os desenvolvedores. A solução para um problema geralmente é a soma das idéias da dupla, tornando uma solução e codificação muito mais simples e eficaz.
é com esta prática que o XP uniformiza o nível dos desenvolvedores da equipe, através da troca de experiências. Após alguns meses trabalhando em duplas todos os desenvolvedores conhecerão todas rotinas do sistema, prontos para qualquer modificação ou para auxiliar algum iniciante.
Um grande questionamento sobre esta prática é com questão a produtividade dos desenvolvedores. Porém, é um erro pensar que somente uma pessoa estará codificando enquanto o outro apenas observa. O membro que não está codificando não apenas observa, mas também troca idéias, gera soluções e evita praticamente todos erros de codificação além de cobrar padrões de desenvolvimento da equipe.
Estudos indicam que a produtividade de uma equipe que utiliza pair programming e de equipes que tenham desenvolvedores sozinhos é praticamente a mesma, porém a qualidade do código gera facilidade de manutenção e outros ganhos a médio e longo prazo.

2.2.5 Refactoring

Um desenvolvedor ao deparar com um código mal escrito ou pouco legível mas que esteja funcionando, nos modelos tradicionais de desenvolvimento, dificilmente efetuaria alterações neste código, mesmo que tivesse que implementar novas funcionalidades.
O XP prega que todo desenvolvedor ao encontrar um código duplicado, pouco legível, mal codificado, sem padronização, lento, com código legado ou uso incorreto de outras implementações, tem por obrigação alterar este código deixando-o mais legível e simples, porém esta alteração não pode mudar o comportamento do código em questão.
Esta prática anda de mãos dadas com o código coletivo, já que todo desenvolvedor tem a possibilidade de melhorar qualquer código do sistema.
A padronização oferece facilidades aos desenvolvedores no momento de implementar novas funcionalidades ou efetuar qualquer tipo de manutenção, uma vez que o código se encontra simples e claro.
Uma questão importante é que a prática de refactoring esta apoiada pelos testes automatizados, pois facilmente o desenvolvedor terá um feedback se a alteração por ele efetuada irá gerar qualquer tipo de comportamento anormal no sistema, sofrendo o aprendizado sobre a alteração por ele efetuada.

2.2.6 Desenvolvimento guiado por testes

Esta atividade é considerada extremamente chata e dispendiosa por muitos desenvolvedores na modelagem tradicional, porém para os desenvolvedores de uma equipe XP esta atividade deve ser encarada com extrema naturalidade. Todo código implementando deve coexistir com um teste automatizado, assim garantindo o pleno funcionamento da nova funcionalidade.
é com base nestes testes automatizados que qualquer desenvolvedor terá coragem para alterar uma parte do código que não tenha sido implementada por ele, já que executando os testes automatizados poderá verificar instantaneamente se a modificação efetuada alterou o comportamento do sistema.
Com a implementação de testes o desenvolvedor poderá amadurecer o entendimento sobre o problema que irá solucionar, já que os testes são codificados antes da nova implementação.
No XP existem dois tipos de testes, os testes de unidade e de aceitação. O teste de unidade tem por objetivo verificar se os resultados gerados por cada classe estão corretos, já o teste de aceitação tem por objetivo verificar se a interação entre as classes que implementam uma funcionalidade (estória) atendem a necessidade de forma correta. Os testes de aceitação são descritos pelo cliente e implementados pelos desenvolvedores, facilitando ainda mais a interação entre as partes.

2.2.7 Código coletivo

No modelo tradicional de desenvolvimento, é comum dividir o projeto em partes e colocar responsáveis por cada uma destas partes. Porém apenas uma pessoa torna-se conhecedora daquela parte.
Este tipo de divisão traz sérios problemas ao projeto, uma vez que se aquela parte necessitar inúmeras alterações, apenas uma pessoa estará capacitada para alterá-la. Com estas inúmeras alterações, esta pessoa pode se tornar um gargalo no projeto.
O XP trava uma batalha contra este tipo de divisão, já que não existe uma pessoa responsável por uma parte do código. Cada desenvolvedor tem acesso a qualquer parte do sistema e tem liberdade para alterá-la a qualquer momento e sem qualquer tipo de aviso.
Esta prática tem como conseqüência um código revisado por diversas pessoas e caso algo não esteja claro, com certeza será alterado por alguma pessoa ( refactoring ) para que o mesmo torne-se legível.

2.2.8 Padrões de desenvolvimento

Um dos valores do XP é a comunicação, e o código também é uma forma da equipe se comunicar. Uma forma clara de se comunicar através do código, é manter um padrão no projeto para que qualquer um possa rapidamente entender o código lido.
O XP recomenda a adoção de um padrão desde o início do projeto, preferencialmente padrões utilizados pela comunidade da linguagem de desenvolvimento. Havendo a necessidade de modificações e adaptações durante o projeto, que visam agilizar o desenvolvimento, as mesmas devem ser efetuadas.

2.2.9 Design simples

Nota-se que todas as práticas do XP focam que o maior valor possível seja gerado para o cliente, para tal premissa ser verdadeira o XP prega um design do sistema da forma mais simples possível para que atenda a necessidade do cliente.
Umas das premissas do desenvolvimento tradicional é que o custo de uma alteração no sistema cresce exponencialmente ao longo do projeto, com isto tenta-se criar soluções genéricas preparando o sistema para futuras alterações.
Este tipo de pensamento dá margens para especulações e implementações que na maioria dos casos não terá utilidade para o cliente. O XP parte do princípio que o custo de uma alteração tende a crescer lentamente e se estabilizar ao longo do projeto, esta premissa é dita em função dos avanços nas linguagens e práticas de programação, novos ambientes e ferramentas de desenvolvimento, utilização de orientação a objetos no desenvolvimento e em conjunto com estes novos avanços existe o fruto das outras práticas XP, deixando o código simples, legível e passível de alteração a qualquer momento.

2.2.10 Metáfora

Muitas vezes pessoas tentam explicar um assunto ou problema a outras pessoas por um período sem obter o êxito necessário na explicação dada, simplesmente as outras pessoas não conseguem entender a mensagem que está se tentando repassar.
Ao criar comparações e analogias com o assunto que está em questão as pessoas passarão a entender deste assunto de uma forma muito mais rápida e possivelmente não a esquecerão mais. Este tipo de artifício é chamado de metáfora no XP, e deve ser utilizado com intensidade durante o projeto, uma vez que facilita a comunicação e fixação dos assuntos entre as partes.
Esta prática anda em conjunto com o ritmo sustentável, já que para o desenvolvedor criar boas metáforas exige criatividade e desenvolvimento de idéias, o que torna necessário uma boa condição física e bem estar por parte do desenvolvedor.

2.2.11 Ritmo sustentável

Uma grande problema nos projetos de software é a falta de tempo para encerrar o mesmo, e uma das técnicas mais adotadas para compensar a falta de tempo é submeter os desenvolvedores (humanos) a trabalharem até mais tarde e muitas vezes sacrificarem seus finais de semana.
Nos primeiros momentos este tipo de atitude tem efeitos positivos, porém passado alguns dias o rendimento da equipe cai drasticamente, dando margens a erros pela falta de concentração no desenvolvimento, justamente pelo cansaço físico do desenvolvedor.
O XP proíbe que os desenvolvedores trabalhem até mais tarde. O XP sugere um ritmo sustentável de 40 horas semanais, respeitando assim a individualidade e o físico de cada desenvolvedor. Desta forma a equipe estará sempre concentrada e muito menos propensa a pequenas falhas na implementação.

2.2.12 Integração contínua

No desenvolvimento tradicional geralmente as equipes são organizadas de modo que uma parte (módulo) fiquei sob responsabilidade de um desenvolvedor, cabe a esta pessoa efetuar testes e codificação que dizem respeito a sua parte. Esta estratégia reduz a complexidade e as preocupações de um desenvolvedor.
Interfaces de integração são convencionadas para que futuramente estas partes possam se comunicar, este tipo de desenvolvimento esta propenso a sérios erros de integração, uma vez que os períodos em que as partes são integradas e testadas são extremamente longos.
O XP propõe uma integração contínua, se possível deve ser efetuada diversas vezes ao dia para que toda a equipe tenha conhecimento do código recém desenvolvido. Com esta prática o feedback sobre a alteração efetuada será retornado em um menor espaço de tempo.

2.2.13 Releases curtos

No modelo tradicional o projeto é dividido em fases, de um modo que o cliente começará a ter benefício com o sistema muito próximo de o mesmo estar finalizado. A maior parte do investimento do projeto é feita antes mesmo de estar concluído, sem ter gerado qualquer tipo de valor econômico ao cliente.
O XP recomenda que pequenos investimento sejam efetuados de forma gradual e que busque grandes recompensas o mais rapidamente possível. Com a prática de releases curtos, o XP pretende dar o máximo de valor econômico ao cliente em um curto espaço de tempo.
Release é um conjunto de funcionalidade bem definidas e que representam algum valor para o cliente. Um projeto XP pode ter um ou mais releases no seu ciclo de desenvolvimento.

2.3 Equipe XP

Em uma equipe de XP existem papéis a serem desempenhados por um ou mais desenvolvedores. Estes papéis serão listados a seguir.

2.3.1 Gerente de projeto

Pessoa responsável pelos assuntos administrativos do projeto, mantendo um forte relacionamento com o cliente para que o mesmo participe das atividades do desenvolvimento.
O gerente de projeto é responsável por filtrar assuntos não relevantes aos desenvolvedores e aspectos que só devam ser implementados em iterações futuras.
Para um bom exercício de gerente de projeto é necessário que a pessoa conheça e acredite nos valores e práticas do XP para que possa cobrar isto da sua equipe.

2.3.2 Coach

Pessoa responsável pelas questões técnicas do projeto, recomenda-se que esta pessoa seja a com maior conhecimento do processo de desenvolvimento, dos valores e práticas do XP. é de responsabilidade do coach verificar o comportamento da equipe frente o processo XP, sinalizando os eventuais erros cometidos pela equipe.

2.3.3 Analista de teste

Pessoa responsável em garantir a qualidade do sistema através dos testes escritos. Ele deve ajudar o cliente a escrever os casos de testes e no final de cada iteração verificar se o software atende todos os casos de testes.
Recomenda-se que esta pessoa não seja um desenvolvedor, para evitar uma visão tendenciosa já que não conhece o código desenvolvido. O analista de teste deve ter uma visão muito parecida com a do cliente e em muitos projetos esta pessoa acaba exercendo o papel de redator técnico.

2.3.4 Redator técnico

Pessoa responsável em documentar o sistema, evitando um forte trabalho dos desenvolvedores neste tipo de atividade, permitindo uma maior dedicação ao trabalho de codificação.
Esta pessoa deve estar em plena sintonia com os desenvolvedores e cliente para que a documentação reflita o código escrito e as regras de negócio atendidas pelo sistema.

2.3.5 Desenvolvedor

Pessoa responsável em analisar, projetar e codificar o sistema. No XP não existe diferença entre analista, projetista e programador uma vez que em vários momentos do projeto o desenvolvedor estará exercendo alguma destas atividades.
Naturalmente existe níveis distintos de desenvolvedores dentro de uma equipe, mas com as práticas do XP, como pair programming , a tendência é a equipe se tornar uniforme em suas habilidades.

3 Conclusões

A metodologia de desenvolvimento Extreme Programming pode ser considerada extremamente nova, porém vem acompanhando as necessidades humanas dos desenvolvedores pelo mundo.
Gurus da tecnologia da informação vem aprimorando as concepções desta metodologia para atender as necessidades do mercado e principalmente das pessoas.
Um empresa ao utilizar este processo por completo, só estará agregando valor aos seus negócios e melhorando o ambiente de seus colaboradores e clientes, tratando-os como pessoas e parceiros. Está é chave no mundo dos negócios, o bem estar de seus colaboradores e a parceria entre o fornecedor e seus clientes, criando um laço de confiança ou até mesmo um sentimento de amizade.
Entender as necessidades do cliente não é ciência, é arte. Dar incentivo a ela é o mínimo que podemos fazer.

4 Referências

AMBROSI, Cleison Vander; GRAHL, Everaldo Artur. Extreme Programming: Um modelo de processo para o desenvolvimento de software. Blumenau ? SC: Instituto Catarinense de Pós-Graduação.
ASTELS, David; MILLER, Granville; NOVAK, Miroslav. Extreme Programming: Guia prático. Rio de Janeiro ? RJ: Campus, 2002.
BECK, Kent. Programação extrema (XP) explicada: acolha as mudanças. Porto Alegre ? RS: Bookman, 2004.
POHREN, Daniel. XP Manager: Uma Ferramenta de Gerência de Projetos Baseados em Extreme Programming. Novo Hamburgo ? RS: Centro Universitário Feevale, 2004.
TELES, Vinícius Manhães. Extreme Programming: Aprenda como encantar seus usuários desenvolvendo software com agilidade e alta qualidade. São Paulo - SP: Novatec Editora Ltda, 2004.
WUESTEFELD, Klaus. Xispê: Extreme Programming. Disponível em http://www.xispe.com.br/index.html . Acesso em: 23 / 07 / 2004.

Palavras-chave: Extreme Programming , Engenharia de Software, Qualidade de Software, Metodologia de Desenvolvimento, Processos Ágeis de Desenvolvimento, XP.

Por: Giovane Roslindo Kuhn e Vitor Fernando Pamplona

Garantia de Qualidade de Software

2010-04-05T12:25:00.000-03:00

Autor: Alexandre Bartié

Editora: Campus

I.S.B.N.: 8535211241
Edição: 2002
Idioma: Português
País de Origem: Brasil

O livro tem como objetivo proporcionar ao leitor uma visão geral dos conceitos de teste, dos diferentes tipos de teste, incluindo as estratégias e as métricas adequadas. Esta obra tem como público-alvo organizações interessadas em melhorar a qualidade de seus softwares, através do planejamento, implementação e automação de testes, líderes de projeto, analistas de sistemas, desenvolvedores de software; testadores; e os profissionais interessados e envolvidos em implementar ou gerenciar a implementação dos testes de software.

2º Encontro Mensal do Interior da ALATS-SP Regionais Itu/Sorocaba

2010-04-05T12:10:00.001-03:00

Data:08 de abril de 2010 (quinta-feira)
Horário: 19h30min – 22h00min
Local: FATEC - Sorocaba - Av. Engenheiro Carlos Reinaldo Mendes, 2015, Alto da Boa Vista.
Objetivo: Aumentar o contato entre profissionais da área de Teste de Software e Garantia da Qualidade, bem como estimular a troca de conhecimentos, experiências e práticas de sucesso.
Tema do encontro: Processo de Teste de Software apoiado por ferramentas Open-Source.

Conteúdo:

Processo de Teste de Software
Planejamento e Especificação de Testes
Ferramentas de Planejamento e Especificação de Testes
Ferramentas de Execução de Teste de Software
Gestão de Defeitos
Ferramentas de Gestão de Defeitos
Geração de Métricas e Relatórios

Agenda:
19h30min - Credenciamento e networking entre os participantes
20h00min - Palestra sobre Teste de Software
21h15min - Encerramento e Confraternização

Palestrante: André de Oliveira, graduado em Processamento de Dados pela Fatec Sorocaba, com especialização em Engenharia de Software pela UNICAMP. Atua á 5 anos na área de informática, sendo destes 2 anos e meio como Analista de Sistemas Responsável pela Qualidade de Software da Agiw Sistemas na cidade de Sorocaba, empresa desenvolvedora de ERP. É Diretor Regional Adjunto da ALATS-SP e certificado CBTS (Certificação Brasileira de Teste de Software).

Inscrições:
- Palestra Gratuita
- Até o dia 07/04/2010
- Vagas limitadas (30 participantes)
A participação na palestra Vale 2 PDTS para a renovação da CBTS.
Reserve pelo e-mail dra_sor_itu@hotmail.com com o assunto: ALATS SOROCABA (necessário enviar o nome, empresa, cargo e data de nascimento para cadastro)

Sites Recomendados

2010-04-01T12:27:00.006-03:00

Sites Brasileiros

Softex
http://www.softex.br/
TestExpert
http://www.testexpert.com.br/
Associação Brasileira de Melhoria em Tecnologia da Informação
http://www.abramti.org.br/
Qualidade de Software
http://qualidadesoftware.org.br/
Qualidade de Software
http://qualidade-de-software.blogspot.com/

Certificações

Certificação Brasileira de Teste de Software (CBTS)
http://www.alats.org.br/Default.aspx?tabid=198
Brazilian Software Testing Qualification Board
http://www.bstqb.org.br/
Instituto Brasileiro de Qualidade em Testes de Software
http://www.ibqts.com.br/
Certified Software Quality Analyst (CSQA)
http://www.softwarecertifications.org/
Software Quality Engineer Certification CSQE
http://www.asq.org/certification/software-quality-engineer/index.html
ISEB Foundation Certificate in Software Testing
http://www.bcs.org/server.php?show=nav.7179
ISEB Practitioner Certificate in Software Testing
http://www.bcs.org/server.php?show=nav.6956
The Certified Software Tester (CSTE)
http://www.softwarecertifications.org/
Certified Test Manager (CTM)
http://www.testinginstitute.com/ctm.php
Certified Software Test Professional (CSTP)
http://www.testinginstitute.com/cstp.php
American Software Testing Qualifications Board
http://www.astqb.org/

Revistas

StickyMinds Software Quality & Test
http://www.stickyminds.com/
Software Test & Performance Magazine
http://www.stpmag.com/
SDTimes Magazine
http://www.sdtimes.com/index.html
The Rational Edge
http://www-128.ibm.com/developerworks/rational/rationaledge/
Professional Tester Magazine
http://www.professionaltester.com/
Free Software Magazine for the Free Software World
http://www.freesoftwaremagazine.com/

Fóruns de discussões

VV-SW-Brasil - Validação e Verificação de Software
http://br.groups.yahoo.com/group/VV-SW-Brasil/
ALATS - Associação Latino Americana de Teste de Software
http://br.groups.yahoo.com/group/alats-br/
DFTestes: Grupo de amigos profissionais em Teste de Software do Distrito Federal
http://br.groups.yahoo.com/group/DFTestes/
QAI - Quality Assurance Institute Brasil
http://br.groups.yahoo.com/group/qai-brasil/
International Software Testing Qualifications Board
http://groups.google.com.br/group/bstqb
Grupo de estudo criado para quem deseja certificação CSTE da QAI
http://br.groups.yahoo.com/group/cste-brasil/
Grupo de discussão sobre Qualidade de Software
http://br.groups.yahoo.com/group/qa_rs/
QA Forums - The most popular Software Testing and QA discussions
http://qaforums.com/
Google Software Testing Group
http://groups.google.com/group/SoftwareTesting
Yahoo Software Testing and Quality Assurance Group
http://groups.yahoo.com/group/Software_QA/
Yahoo SQA Career Group
http://groups.yahoo.com/group/SQACareer/
Yahoo SQA Tester Group
http://groups.yahoo.com/group/SQAtester/
MSDN Software Testing Discussion
http://forums.microsoft.com/msdn/showforum.aspx?forumid=1600&siteid=1

Ferramentas de Automação e Gestão de Testes

Software QA Testing and Test Tool Resources
http://www.aptest.com/resources.html
Web Site Test Tools and Site Management Tools
http://www.softwareqatest.com/qatweb1.html
Open Source Software Testing Tools, News and Discussion
http://opensourcetesting.org/
Open Source Testing Tools in Java
http://java-source.net/open-source/testing-tools
Software QA and Testing Resource Center
http://www.softwareqatest.com/qattls1.html

Outros

Testing Spot
http://testingspot.net/
Search Software Quality
http://searchsoftwarequality.techtarget.com/
International Institute for Software Testing
http://www.testinginstitute.com/
Community portal for CSQA and CSTE professionals
http://csqa.info/
Food for Thought
http://www.swqual.com/newsletter/Subscribe.htm
Artima Weblogs
http://www.artima.com/weblogs/index.jsp
DevBistro Test Jobs
http://www.devbistro.com/jobs/keywords/Test
QA Jobs
http://www.qajobs.net/
Software Testing Hotlist
http://www.io.com/~wazmo/qa/
QAInsight
http://qainsight.net/
iSix Sigma Software/IT
http://software.isixsigma.com/
Quality Tree
http://www.qualitytree.com/
DevelopSense
http://www.developsense.com/
Satisfice
http://www.satisfice.com/
Developer Testing
http://www.developertesting.com/
Methods & Tools - Providing practical and free knowledge for the software developer, tester and project manager
http://www.methodsandtools.com/
Center for Software Testing Education
http://www.testingeducation.org/BBST/
TestFocus
http://www.testfocus.co.za/
Cem Kaner's website
http://www.kaner.com/articles.html

Fonte: TestExpert

Teste e Análise de Software - Processos, Princípios e Técnicas

2010-03-31T16:01:00.001-03:00

Autor: Mauro Pezzè, Michal Young

Editora: Artmed

I.S.B.N.: 9788577802623
Edição: 1 / 2008
Idioma: Português
País de Origem: Brasil

Um software de qualidade não pode ser construindo sem a utilização de técnicas de teste e análise de software. Este livro apresenta um conjunto de técnicas de teste e análise em uma prática moderna. Escrito em linguagem acessível, abrange tópicos bem aprofundados e oferece uma visão geral sobre o assunto.

Introdução ao Teste de Software

2010-03-31T15:51:00.003-03:00

Autor: Mario Jino, José Carlos Maldonado, Márcio Eduardo Delamaro

Editora: Elsevier - Campus

I.S.B.N.: 9788535226348
Edição: 2007
Idioma: Português
País de Origem: Brasil

Em 2006, a Sociedade Brasileira de Computação (SBC) organizou o seminário Grandes Desafios da Computação, onde foram identificados os mais importantes temas relacionados à área para a próxima década. Dentre eles, está o desenvolvimento tecnológico de qualidade e, conseqüentemente, a disponibilização de sistemas corretos, confiáveis e seguros. Nota-se também que, nos últimos anos, a indústria de software, no Brasil e no resto do mundo, tem empregado cada vez mais recursos na busca pela qualidade de seus produtos e na redução de seus custos de desenvolvimento e manutenção. Além da demanda criada pelas principais companhias de desenvolvimento de software, nota-se uma acentuada carência de profissionais aptos a atuar na área de qualidade e, mais especificamente, de teste de software.
Essas são apenas algumas razões que devem incentivar a leitura deste livro. Nele, procura-se apresentar as principais técnicas de teste de software, mostrando suas origens, evolução e tendências. Mostra, também, como essas técnicas vêm sendo aplicadas em domínios específicos como o desenvolvimento de software para a Web ou baseado em aspectos. Trata, ainda, de dois tópicos importantes e fortemente relacionados ao teste e qualidade de software que são: depuração e confiabilidade.

Base de Conhecimento em Teste de Software

2010-03-31T15:40:00.003-03:00

Autor: Aderson Bastos, Ricardo Cristalli, Trayahú Moreira, Emerson Rios

Editora: Martins Editora

I.S.B.N.: 8599102893
Edição: 2 / 2007
Idioma: Português
País de Origem: Brasil

Obra de referência para os profissionais da área, indicada para o leitor que começa a se preparar para os exames de certificação. A fim de auxiliá-lo ainda mais nessa tarefa, foram selecionados os temas mais abordados nos principais exames. De maneira complementar, esta obra, desde sua primeira edição, é também fonte de consulta para a execução das atividades relacionadas ao teste de software.

Obtendo Qualidade de Software com o RUP

2010-03-30T15:33:00.002-03:00

Abstract. This article describes what should be considered in the software development to achieve acceptable quality patterns. The article shows that quality software is something that should be considered in all time in the application life cycle. One of the features that can maximize the software’s quality level is the iterative and incremental development. Moreover, the failures of the waterfall development process and the show and description of the Rational Unified Process (RUP)’s features will be approached.

Resumo. Este artigo descreve o que deve ser levado em consideração no desenvolvimento de software para atingir padrões de qualidade aceitáveis. O artigo mostra que a qualidade de software é algo que deve ser levado em consideração em todo momento do ciclo de vida do aplicativo. Uma das características que podem elevar o nível de qualidade do software é o desenvolvimento iterativo e incremental. Além disso, são abordadas as falhas do processo de desenvolvimento em cascata e a apresentação e descrição das características do Rational Unified Process (RUP).

1. Introdução

A cada dia que passa, as organizações se tornam mais dependentes dos sistemas de informação. Atualmente, não apenas sistemas que podem colocar a vida de pessoas em risco são considerados sistemas de missão crítica. Hoje, os sistemas de informação de muitas empresas são qualificados como de missão crítica, pois podem gerar enormes prejuízos financeiros caso haja eventuais problemas com os mesmos.

A atividade de desenvolvimento de software possui um alto grau de risco. Essa atividade já gerou grandes prejuízos no passado e continua gerando. Atualmente, muitos projetos de desenvolvimento de software são iniciados e não são terminados, e outros são terminados consumindo prazos e orçamentos bem acima do que foi estipulado no início do projeto. Além disso, muitos produtos desenvolvidos possuem um nível muito baixo de qualidade.

Conforme [Kruchten 2003], um produto de qualidade deve ter ausência de defeitos e, principalmente, deve atender aos propósitos desejados. Alguma coisa com qualidade deve fazer o que as pessoas querem que ela faça. Se alguma coisa é livre de defeitos, mas não faz o que as pessoas querem que ela faça, essa coisa é um produto desnecessário.

A qualidade de software não pode ser avaliada de maneira isolada. Softwares são desenvolvidos pelas organizações através de procedimentos. Um método pobre ou a ausência de uma metodologia pode ser a causa da baixa qualidade. Sendo assim, a avaliação da qualidade está diretamente relacionada com a qualidade de processos e metodologias utilizadas.

2. Metodologias de Desenvolvimento

Metodologias de desenvolvimento e estruturas de avaliação de processos podem ser comparadas sob duas dimensões: de um lado, temos o vértice pouca formalidade / muita formalidade e de outro, o método cascata / método iterativo, exemplificado através da Figura 1.

Figura 1: Mapa de processos

Os processos com pouca formalidade produzem o mínimo de documentação possível e procedimentos de trabalho bastante informais. Os formais possuem maior documentação, mantém o histórico dos artefatos gerados e possuem gerenciamento de mudanças.
O método cascata é um procedimento linear, onde a integração e os testes são feitos no fim do ciclo de desenvolvimento. O método iterativo é guiado pelo risco, ou seja, é voltado para a eliminação e minimização de riscos. A implementação da arquitetura, a integração e os testes são realizados desde o início do ciclo de vida do aplicativo.

2.1 Método Cascata

Esse método, também conhecido como seqüencial, ou linear, foi utilizado por muitos anos e ainda é utilizado. Segundo [Kroll e Kruchten 2003], esse processo se baseia nos seguintes passos:

Entender completamente o problema a ser resolvido, seus requisitos e suas restrições;
Projetar uma solução que atenda todos os requisitos e restrições. Examinar o projeto cuidadosamente e ter certeza que todas as parte interessadas concordam que essa é a solução certa;
Fazer a implementação do projeto, usando as melhores técnicas de engenharia;
Verificar se a solução atende aos requisitos estabelecidos;
Distribuir o produto.

Esse processo é similar à forma a qual pontes e edifícios são construídos. Algumas coisas devem ser feitas dessa maneira. Em um projeto com dois meses de duração, essa metodologia poderia ser usada. Mas normalmente, softwares não devem ser desenvolvidos dessa forma.

2.2 Método Iterativo e Incremental

O método iterativo foi criado para superar as dificuldades impostas pelo modelo cascata. Já que o modelo cascata pode ser usado com sucesso em projetos pequenos, onde o domínio do problema é bem conhecido, a solução encontrada foi dividir grandes projetos em projetos menores.
Dessa maneira, alguns requisitos e alguns riscos podem ser identificados, um projeto pode ser realizado, uma implementação pode ser construída para esse projeto, validada e testada. Esse processo se repete com outras partes do sistema até que o sistema inteiro seja terminado. Isso é chamado de modo iterativo.

Em cada pequena parte do sistema é feita uma iteração. A iteração segue o modelo seqüencial tradicional, com identificação de necessidades, análise, projeto, implementação e testes.
A cada iteração o sistema é incrementado até que o ciclo de desenvolvimento do aplicativo termine. Nesse ponto, um novo ciclo de desenvolvimento pode ser iniciado.

A maneira de desenvolver projetos através de várias iterações que vão incrementando o projeto até que se chegue a um objetivo é chamada de modo iterativo e incremental. Atualmente esse paradigma de desenvolvimento é bem aceito e vem sendo utilizado por várias metodologias de desenvolvimento de software.

3. O Rational Unified Process

Conforme [Kroll e Kruchten 2003], podemos ter três definições para o Rational Unified Process (RUP):

O RUP é uma maneira de desenvolvimento de software que é iterativa, centrada à arquitetura e guiada por casos de uso. É descrita em vários livros e artigos. Uma das maiores fontes de informações é o próprio produto IBM RUP [1], que contém guias detalhados, exemplos e modelos cobrindo todo o ciclo de vida do software;
O RUP é um processo de engenharia de software bem definido e bem estruturado. O RUP define claramente quem é responsável pelo que, como as coisas devem ser feitas e quando fazê-las. O RUP também provê uma estrutura bem definida para o ciclo de vida de um projeto RUP, articulando claramente os marcos essenciais e pontos de decisão;
O RUP é também um produto de processo que oferece uma estrutura de processo customizável para a engenharia de software. O produto IBM RUP suporta a customização e autoria de processos, e uma vasta variedade de processos, ou configuração de processos, podem ser montadas nele. Essas configurações do RUP podem ser criadas para suportar equipes grandes e pequenas, e técnicas de desenvolvimento disciplinadas ou menos formais. O produto IBM RUP contém várias configurações e visões de processos prontas que guiam analistas, desenvolvedores, testadores, gerentes de projeto, gerentes de configuração, analistas de dados, e outros membros da equipe de desenvolvimento em como desenvolver o software. Ele tem sido utilizado por muitas companhias em diferentes setores da indústria.

O RUP utiliza a Linguagem Unificada de Modelagem (UML [2]) para especificar, modelar e documentar artefatos. A UML é um padrão definido pelo OMG [3] e ter se tornado o padrão empresarial para a modelagem orientada a objetos [4] .

Por ser flexível e configurável, o RUP pode ser utilizado em projetos de pequeno, médio e grande porte. [Kroll e Kruchten 2003] mostra como o RUP pode ser utilizado em um projeto de uma semana com uma equipe de uma pessoa.

3.1 Os Princípios do RUP

Não existe uma maneira exata de aplicar o RUP, pois ele pode ser aplicado de várias formas e será diferente em cada projeto e organização. Porém, existem alguns princípios que podem caracterizar e diferenciar o RUP de outros métodos iterativos:

Atacar os riscos cedo e continuamente;
Certificar-se de entregar algo de valor ao cliente;
Focar no software executável;
Acomodar mudanças cedo;
Liberar um executável da arquitetura cedo;
Construir o sistema com componentes;
Trabalhar junto como um time;
Fazer da qualidade um estilo de vida, não algo para depois.

3.2 Elementos do RUP

O RUP possui cinco elementos principais: papéis, atividades, artefatos, fluxos de trabalho e disciplinas.
Um papel (ou perfil) define o comportamento e as responsabilidades de um determinado indivíduo ou grupo de indivíduos trabalhando como uma equipe. Papéis não são indivíduos e nem títulos de trabalho. Um indivíduo pode assumir vários papéis. São exemplos de papéis:

Analista de sistema – O indivíduo que assume este papel coordena a obtenção dos requisitos e a modelagem dos casos de uso identificando funcionalidades do sistema e estabelecendo limites do sistema;
Projetista – Esse indivíduo define responsabilidades, operações, atributos, relacionamentos de uma ou mais classes e determina como elas devem ser ajustadas para serem implementadas no ambiente;
Projetista de testes – Responsável pelo planejamento, projeto, implantação e avaliação de testes, incluindo a geração de plano e modelo de teste, implementando procedimentos de testes e avaliando a abrangência dos testes, resultados e a efetividade.

Uma atividade é uma unidade de trabalho que um indivíduo executa quando está exercendo um determinado papel e produz um resultado importante para o contexto do projeto. Cada atividade pode ser dividida em passos. São exemplos de atividades:

Planejar uma iteração: realizada pelo papel gerente de projeto;
Encontrar casos de uso e atores: realizada pelo papel analista de sistemas;
Rever o projeto: realizada pelo papel revisor de projeto;
Executar um teste de performance: realizado pelo papel testador de performance.

Um artefato é um pedaço de informação que é produzido, modificado ou utilizado em um processo. Os artefatos são os produtos de um projeto. São as coisas produzidas durante o desenvolvimento do projeto. Artefatos são utilizados como entradas de atividades e são produzidos como saída.
Os artefatos podem ter várias formas:

Um modelo, como um modelo de caso de uso, um modelo de projeto;
Um elemento de um modelo, como uma classe, um caso de uso, um sub-sistema;
Um documento, como um caso de negócio, glossário, visão;
Código fonte;
Executáveis.

A enumeração de atividades, papéis e artefatos não constituem um processo. É necessário saber a seqüência do desenvolvimento das atividades para que possam ser produzidos artefatos de valor para o projeto. Um fluxo de trabalho [5] é uma seqüência de atividades que são executadas para a produção de um resultado valioso para o projeto. Fluxos de trabalho podem ser representados por diagramas de seqüência, diagramas de colaboração e diagramas de atividades da linguagem UML. O RUP utiliza três tipos de fluxos de trabalho:

Fluxos de trabalho principais, associados com cada disciplina (figura 2);
Fluxos de trabalho de detalhe, para detalhar cada fluxo de trabalho principal (figura 3);
Planos de iteração, que mostram como a iteração deverá ser executada.

Figura 2: Fluxo de trabalho: requisitos

Figura 3: Detalhamento de fluxo de trabalho: analisar o problema

Uma disciplina é uma coleção de atividades relacionadas que fazem parte de um contexto comum em um projeto. As disciplinas proporcionam um melhor entendimento do projeto sob o ponto de vista tradicional de um processo cascata. A separação das atividades em disciplinas torna a compreensão das atividades mais fácil, porém dificulta mais o planejamento das atividades. O RUP possui nove disciplinas, divididas em disciplinas do processo e de suporte. As disciplinas de processo são: modelagem de negócios, requisitos, análise e projeto, implementação, teste e distribuição. As de suporte são: configuração e gerenciamento de mudanças, gerenciamento de projeto, e ambiente.

Figura 4: Arquitetura geral do RUP

Conforme mostra a figura 4, o RUP possui duas dimensões:

O eixo horizontal representa o tempo e mostra os aspectos do ciclo de vida do processo à medida que se desenvolve. Representa o aspecto dinâmico do processo. É expresso em termos de fases, disciplinas e marcos.
O eixo vertical representa as disciplinas, que agrupam as atividades de maneira lógica, por natureza. Representa o aspecto estático do processo. É descrito em termos de componentes, disciplinas, atividades, fluxos de trabalho, artefatos e papéis do processo.

3.3 O Ciclo de Vida de um Projeto RUP

O ciclo de desenvolvimento no RUP possui quatro fases: iniciação [6] , elaboração, construção e transição. Cada uma é concluída por um marco principal, ou seja, cada fase é basicamente um intervalo de tempo entre dois marcos principais, como é mostrado na figura 5.

Figura 5: As fases e os marcos de um projeto

O ciclo de desenvolvimento termina com uma versão completa do produto de software. As fases definem estados do projeto, que são definidos por riscos que estão sendo mitigados ou questões que precisam ser respondidas.

A fase de iniciação, foca no tratamento de riscos relacionados com o caso de negócio. Deve ser verificado se o projeto é viável e se é financeiramente possível.

Na fase elaboração, o foco deve ser nos riscos técnicos e arquiteturais. O escopo deve ser revisado e os requisitos devem estar mais compreendidos.

Durante a construção, a atenção será voltada para os riscos “ lógicos ”, e a maior parte do trabalho será realizada.

Na fase de transição, serão tratados os riscos associados com a logística de distribuição do produto para a base de usuários.

Embora varie muito em empresas e projetos diferentes, um ciclo de desenvolvimento para um projeto de tamanho médio, possui uma distribuição de esforço e programação como é apresentado na tabela 1 e na figura 6.

Tabela 1. Distribuição de esforço e programação em projetos de médio porte.

Figura 6: Distribuição de esforço e programação em projetos de médio porte.

Conforme descrito na documentação do RUP, cada passagem pelas quatro fases gera uma geração do software. A menos que o produto "desapareça", ele irá se desenvolver na próxima geração, repetindo a mesma seqüência de fases de iniciação, elaboração, construção e transição. Esses ciclos subseqüentes são chamados de ciclos de evolução. A cada ciclo, são produzidas novas gerações.

Os ciclos de evolução podem ser disparados por melhorias sugeridas pelos usuários, mudanças no contexto do usuário, mudanças na tecnologia subjacente, reação à concorrência e assim por diante. Normalmente, a menos que ocorram mudanças significativas do produto ou da arquitetura, os ciclos de evolução têm fases de Iniciação e Elaboração bem menores, pois a definição e a arquitetura básicas do produto foram determinadas por ciclos de desenvolvimento anteriores.

4. Conclusão

Com a utilização de uma metodologia de desenvolvimento de software como o RUP, é possível obter:

Qualidade de software;
Produtividade no desenvolvimento, operação e manutenção de software;
Controle sobre desenvolvimento dentro de custos, prazos e níveis de qualidade desejados;
Estimativa de prazos e custos com maior precisão.

Apesar dos benefícios, deve-se ter a consciência que os benefícios não virão de maneira imediata. É necessário adquirir treinamento adequado, adaptação da metodologia no contexto ao qual ela será utilizada, apoio especializado para as equipes de desenvolvimento e tempo para a absorção da metodologia.

Mais informações a respeito do RUP podem ser obtidas no site do IBM RUP e também no site da comunidade IBM Rational. (IBM 2004).

Referências

Comunidade IBM RUP (2004) http://www-130.ibm.com/developerworks / rational / community, Novembro.
Fowler, Martin (2003) “ UML Distilled: A Brief Guide to the Standard Object Modeling Language ”, Addison Wesley, 3 ª Edição.
IBM Rational Unified Process Versão 2003.06.12.01. (2004) http://www-306.ibm.com/software/rational, Novembro.
IBM RUP (2004) http://www-130.ibm.com/developerworks/rational/products/rup,Novembro.
Kroll, P. e Kruchten P. (2003) “ The Rational Unified Process Made Easy: A Practitioner ' s Guide to the RUP ”, Addison Wesley.
Kruchten, P. (2003) “ The Rational Unified Process: An Introduction ”, Addison Wesley, 3 ª Edição.
Larman, Craig (2001) “ Applying UML and Patterns – An Introduction to Object-Oriented Analysis and Design and the Unified Process ”, Prentice Hall, 2 ª Edição.
Object Management Group (2004) http://www.omg.org, Novembro.
Perrelli, Hermano (2004) “ Visão Geral do RUP ”. Centro de Informática, Universidade Federal de Pernambuco. http://www.cin.ufpe.br/~if717/slides/3-visao-geral-do-rup.pdf, Novembro.
[1] Após a compra da Rational pela IBM, o produto Rational Unified Process passou a se chamar IBM Rational Unified Process (IBM RUP).
[2] UML: Abreviatura do inglês Unified Modeling Language. [Fowler 2003] é uma ótima referência para esse assunto.
[3] OMG: Object Management Group.
[4] Consulte [Larman 2001] para informações sobre aplicação da UML para análise e projeto orientados a objeto
[5] O termo fluxo de trabalho vem do termo inglês workflow. Pode ser traduzido também como fluxo de atividade.
[6] Iniciação é a tradução do termo inglês “ inception ”. Esse termo é também traduzido como “ concepção ”.

Por: Ronaldo Rezende Vilela Luiz

Qualidade de Software: Um Compromisso da Empresa Inteira

2010-03-30T11:16:00.001-03:00

Qualidade de software é um assunto que muito se discute e pouco se pratica. Temos a impressão, às vezes, que o discurso da qualidade não passa disso mesmo: discurso. Desde o início dos tempos do desenvolvimento de software temos problemas de qualidade que não só ainda não foram resolvidos como ainda parece que se agravam a cada nova geração tecnológica. Prazos estourados, baixa produtividade, custos altos e qualidade deficiente parecem ser um fantasma que novas tecnologias não são nunca capazes de exorcizar.

Para abordarmos o problema da qualidade, é necessário, evidentemente, que tenhamos claro em primeiro lugar o que entendemos por qualidade de software. Utilizando uma simplificação, poderíamos dizer que todos os problemas de qualidade de software caem em uma das seguintes duas categorias: falhas na Qualidade de Conformidade e falhas na Qualidade de Desempenho.

Qualidade de Conformidade diz respeito à aderência do produto à finalidade para a qual foi construído. No nosso caso, estamos falando de software que dá ao seu usuário a funcionalidade de que ele precisa. Como é amplamente sabido, este tipo de qualidade é mosca branca na nossa área. Por sua vez, Qualidade de Desempenho refere-se à capacidade do produto em apresentar consistentemente a funcionalidade desejada. Em termos de software, isto quer dizer boa performance, ausência de bugs, tolerância a falhas de infra-estrutura (hardware), tolerância a erros do usuário etc.

Por quê deveríamos nos preocupar com a qualidade de software? Existem algumas razões óbvias. Ninguém gosta de software com bugs. Bugs podem causar prejuízos que variam desde a mera necessidade de reiniciar o sistema operacional até à perda de satélites de milhões de dólares (como o Clementine, um satélite construído para designar alvos, no projeto Guerra nas Estrelas, o qual, quando recebeu um comando para mirar um ponto na superfície lunar, ativou os foguetes direcionais e ficou girando até acabar o combustível...). Bugs podem fazer um banco perder milhões e perder a confiança dos clientes ou parar por horas uma companhia telefônica, impedindo a realização de telefonemas interurbanos (como já ocorreu com a AT&T). Os problemas de qualidade tendem a aumentar com o uso maciço das tecnologias de processamento distribuído, onde é muito mais difícil prever o que pode dar errado...

Mas não é só isso. Os esforços pela qualidade na indústria automobilística provaram a tempos que a qualidade não tem custo. Ao contrário do que muita gente pensa, os investimentos em qualidade pagam-se em pouco tempo. O aumento de qualidade sempre é acompanhado por aumento de produtividade e redução de custos na forma de menos retrabalho e menor índice de refugo. Isto sem falar na maior satisfação do cliente, que pode ser refletida muitas vezes em maior participação no mercado. Assim, o axioma que diz que investimentos em qualidade dão lucro é plenamente aceito pela indústria de manufatura. Infelizmente, não é fácil encontrar quem acredite nisto na área de software.

No entanto, as empresas que entenderam que não existem razões para acreditar que este axioma não funciona com software, puderam experimentar os benefícios da aplicação das técnicas de qualidade -presentes na Engenharia de Produção- na Engenharia de Software (leia a entrevista com Watts Humphrey nesta edição). Em um artigo na edição de março, apresentei e discuti o modelo CMM de qualidade de software, desenvolvido pela SEI (Software Engineering Institute). Comentei, naquela ocasião, que os esforços em melhoria da qualidade não podem ter seu foco no produto apenas (fazer software melhor), mas principalmente no processo (fazer melhor o software).

A SEI apresentou, em um estudo recente, alguns números impressionantes relativos a melhorias de desempenho em empresas que investiram em qualidade seguindo os passos do CMM. O aumento médio de produtividade foi em média 35% por ano, enquanto o número de bugs encontrados em software após a entrega foi reduzido em 39% ao ano, chegando em algumas empresas a 95%! A relação custo/benefício, comparando os investimentos em qualidade com o retorno financeiro em termos de redução de custos via aumento de produtividade e redução de retrabalho e manutenção, ficou em média em 5 para 1, chagando a 9 para 1 em alguns casos. Isto é, para cada dólar investido em qualidade, estas empresas economizaram 5 dólares em média. Qualquer pessoa que conheça o Retorno sobre o Investimento (ROI) típico no mercado poderá confirmar que um ROI de 5:1 não se encontra todo dia...

Por quê, então, existe tão pouco investimento em qualidade nas organizações típicas de desenvolvimento de software? Existe aí um problema cultural de grandes dimensões e difícil de superar. Infelizmente, a cultura atual de desenvolvimento de software baseia-se em crenças absurdas que se espalham por todos os níveis da organização. Nos níveis mais altos, isto é, na administração de informática, acredita-se que os investimentos típicos em qualidade de software (uso de processos padronizados de gerência de projetos, uso de metodologias de desenvolvimento, treinamento contínuo dos desenvolvedores, uso de métricas, estabelecimento de procedimentos eficazes de controle de qualidade de software etc.) são caros demais, são mera burocracia e, principalmente, causam o alongamento dos prazos de desenvolvimento. Esta crença errônea é agravada pela limitada cultura de informática dos usuários e clientes, que tendem a pressionar por prazos completamente fora da realidade. Não passa pela cabeça de um alto executivo da GM ou da Volkswagen exigir de seus engenheiros a construção de uma nova fábrica de caminhões em três meses. Em nossa área, porém, é mais ou menos a isto que estamos submetidos dia após dia. No dizer de DeMarco e Lister (Peopleware, 1987), "regularmente pondo o processo de desenvolvimento sob extrema pressão de tempo e depois aceitando produtos de baixa qualidade, a comunidade dos usuários de software mostrou seu verdadeiro padrão de qualidade".

O desenvolvedor, por outro lado, além de acreditar nestas mesmas coisas, não aceita que ninguém lhe diga como deve fazer seu trabalho, afirmando que padronização de procedimentos e uso de best practices seriam uma violência à sua "criatividade". Se levarmos em conta que a maioria dos desenvolvedores não foi formada em Engenharia de Software e aprendeu tudo o que sabe "na marra", fica difícil acreditar nesta afirmação. Afinal, quem de nós confiaria sua saúde a um "médico" que aprendeu sozinho a profissão (fora da faculdade) e que têm solene desprezo pelos manuais de medicina? O caso é que a maioria de nós desenvolvedores não sabe desenvolver software, e deveríamos ter a humildade de aprender com quem já aprendeu.

Existem erros graves de percepção subjacentes a estas crenças. O primeiro deles é em relação aos prazos. O executivo de informática costuma falhar em perceber que o tal "aumento nos prazos" é geralmente relativo aos prazos prometidos, e não aos efetivamente cumpridos. Como raramente são registrados os prazos reais, ao final dos projetos, o que fica no inconsciente do gerente como regra de referência são os prazos que ele costuma prometer, não os que ele cumpre! E não é preciso ter décadas de experiência na área para se saber que o cumprimento de cronogramas é a exceção, e não a regra.

É claro que a introdução de procedimentos visando o aumento da qualidade pode causar, num primeiro momento, uma pequena redução de produtividade, devido à curva de aprendizado. Isto acontece com a introdução de qualquer nova tecnologia em um ambiente de produção. De forma geral, a introdução de novas tecnologias segue o gráfico da figura 1. O grande problema é que estes projetos acabam sendo abandonados no ponto mínimo da curva, fazendo com que os recursos investidos se percam e baixando o moral dos envolvidos. Mesmo assim, na prática, tenho observado (e conversado com colegas também) que em ambientes de desenvolvimento caóticos (a grande maioria), qualquer esforço de melhoria, por simples que seja, causa rapidamente melhorias de produtividade. A "barriga" da curva é mínima ou mesmo inexistente. O simples esforço por melhorar a documentação do projeto e as verificações de qualidade desde o início reduzem significativamente o tempo gasto em testes e retrabalho, fazendo com freqüência com que mesmo o primeiro projeto em que se aplicam estas técnicas acabe sendo completado antes do que teria terminado sem estas mesmas técnicas, além manter alto o moral dos envolvidos.

A médio prazo, então, não há o que se discutir. Software com mais qualidade sofre menos manutenção, e as manutenções necessárias são feitas muito mais rapidamente. Isto libera recursos para o desenvolvimento de software novo, reduzindo o backlog e acelerando o desenvolvimento; mais software pode ser reutilizado; e o processo de desenvolvimento pode ser continuamente melhorado para aumentar sua eficiência (leia-se prazos menores).

Para um esforço de melhoria de qualidade de software em uma organização funcionar, toda a organização deve estar comprometida. Especificamente, são fundamentais o compromisso da alta administração (de informática e usuária) e dos desenvolvedores, incluindo aí seus gerentes imediatos.

Compromisso da alta administração não é apenas uma expressão bonita. Este compromisso tem que se materializar em ações concretas. São necessários recursos para processos de melhoria (dinheiro e pessoas). É necessário "bancar" o esforço quando surgem crises. É necessário colocar em prática processos que garantam que pressões irrealistas dos usuários não esfumacem a iniciativa. É necessário treinamento e ampla comunicação. Enfim, são necessárias ações que somente executivos em nível de diretoria ou acima podem realizar.

Em um esforço de melhoria da qualidade, o primeiro ponto é colocar em ordem o processo de planejamento e estimativas realistas de prazos. Assim, se o gerente de equipe não souber ou não quiser fazer este planejamento, nada vai acontecer. Para garantir uma negociação realista com os usuários, a alta administração tem que garantir que os prazos estimados pelo gerente sejam aceitos pelos usuários. Os desenvolvedores, por usa vez, tem que comprometer-se a cumprir estes prazos, para que a credibilidade das estimativas junto aos usuários cresça.

Dado que a alta administração garante prazos realistas e dá condições para que os desenvolvedores melhorem suas práticas, é responsabilidade destes últimos aplicarem no seu trabalho diário os conhecimentos adquiridos em treinamentos. Também precisam comprometer-se em buscar continuamente mais conhecimentos, através de leitura de revistas técnicas, livros, pesquisa na Internet etc. Afinal de contas, trata-se de melhorar o processo de engenharia e, se os próprios engenheiros não melhorarem suas práticas de trabalho, nada acontecerá. Em suma, os desenvolvedores devem melhorar seu trabalho, e a administração deve dar as condições para que isto aconteça.

Para ilustrar o que entendo por comprometimento gerencial, apresento um caso real onde estes conceitos foram aplicados.

Em uma empresa em que trabalhei, do setor financeiro, a questão de qualidade era crítica. Existia uma carga noturna de processamento batch em mainframe que era volumosa e sensível a problemas. Um programa que parasse, durante a noite, no caminho crítico da produção levava a atrasos enormes no final do processamento batch, entrava pelo dia adentro e não permitia a entrada dos sistemas on-line, impedindo ou dificultando muito a operação normal e o atendimento aos clientes. A maioria dos abends durante a noite era causa por falhas de planejamento, testes mal feitos ou falta de coordenação entre a equipe de desenvolvimento/manutenção e outra áreas chave tais como a produção ou a administração de bancos de dados. Para resolver o problema, foi instituído um processo de controle de manutenções, que exigia da equipe um planejamento detalhado, teste e coordenação com as áreas envolvidas. Nenhum programa poderia entrar em produção sem que todos os passos estabelecidos fossem cumpridos. Havia uma área especialmente encarregada de verificar o cumprimento do planejamento, cujo gerente respondia diretamente para o diretor de informática, evitando que pressões do gerente de desenvolvimento pudessem fazer com que se "passasse por cima" do processo estabelecido. Os desenvolvedores foram treinados no processo e foram-lhes mostrados os benefícios esperados. A solicitação de manutenção de prioridade normal tinha de ser apresentada com quase duas semanas de antecedência à entrada em produção dos programas alterados. Existia também a possibilidade de implantações de maior prioridade acontecerem em um período inferior a estas duas semanas.

Apesar de todas estas providências, este processo não funcionou num primeiro momento. Os usuários continuaram pressionando os analistas por prazo e estes também não tinham o hábito de planejar as manutenções. Quando o usuário pedia algo, a equipe simplesmente sentava e fazia. As exceções eram a regra e o processo praticamente não era cumprido. Solicitações de manutenção para o mesmo dia ou o dia seguinte eram aceitas sem maiores problemas e, freqüentemente programas eram alterados no ambiente de produção sem mesmo passarem pela formalidade do processo. Não será surpresa para o leitor saber que os problemas de abends em produção continuaram ocorrendo com a mesma freqüência.

Percebendo este problema, o diretor de informática, com suporte explícito do vice-presidente administrativo e tácito do presidente da empresa, estabeleceu que absolutamente todas as manutenções deveriam passar pelo processo. Além disso, os desenvolvedores e seus gerentes imediatos foram informados de que teriam de explicar muito bem cada abend em produção. Por outro lado, também foram encorajados a resistir às pressões dos usuários. Estes últimos foram educados a respeito do novo processo, e se deixou claro que eles, usuários, teriam que explicar muito bem por quê suas solicitações exigiam os prazos curtos pedidos. A área de administração de mudanças recebeu poder para barrar qualquer solicitação de manutenção que entendesse estar fora dos padrões de qualidade, adiando as implantações em uma semana. Qualquer confronto de prazo entre esta gerência e a de desenvolvimento/manutenção seria levado para a decisão do próprio diretor de informática, que ouviria as razões do usuário. Todo abend em produção passaria a ser documentado por escrito, tendo a equipe de desenvolvimento que explicar suas causas e o que seria feito para evitar a recorrência. Estatísticas começaram a ser coletadas provando uma correlação positiva entre abends e manutenções "urgentes", isto é, ficou comprovado que a maioria dos problemas em produção eram causados por programas alterados em manutenções "de um dia para o outro". Níveis de erros em produção e de manutenções de prioridade "urgente" versus prioridade normal (duas semanas) eram coletados e divulgados, separados por equipe. Gerentes de equipes com altas taxas de erros e manutenções "urgentes" tinham que explicar as razões. Usuários de nível médio (um gerente na área de contabilidade, por exemplo) tinha de explicar ao seu diretor por que a sua manutenção era urgente, para que este pudesse por sua vez explicar ao diretor de informática, que liberaria a manutenção se esta fosse realmente necessária.

É claro que, no início, houve uma chiadeira geral. Ouviam-se gritos de "terrorismo" e "burocracia" por todos os corredores. Usuários queixavam-se da "urgência" de suas manutenções (na maioria não tão urgentes assim, ou tornadas urgentes por não se ter feito planejamento no momento certo, com a devida antecedência). Desenvolvedores e seus gerentes imediatos não gostaram de ter a qualidade de seu trabalho medida e divulgada publicamente. Mas a alta administração foi em frente e não se deixou intimidar pela gritaria.

Qual foi o resultado? Com o tempo, usuários e desenvolvedores aprenderam a separar o "urgente" do urgente. Tanto os usuários quanto os desenvolvedores aprenderam a planejar melhor as manutenções. Prazos realistas passaram a ser estabelecidos. Alterações em programas passaram a ser melhor testadas. Todas as áreas técnicas e funcionais passaram a ser sistematicamente envolvidas em cada manutenção, evitando problemas de coordenação. Em pouco tempo, as manutenções planejadas passaram a apresentar taxas baixíssimas de erros em produção. Os atrasos de processamento, que aconteciam em mais da metade dos dias do mês, passaram a ocorrer apenas em dois ou três dias por mês. A médio prazo, a relação entre manutenções urgentes e planejadas foi ficando cada vez menor.

Afinal, diante das evidências, todo mundo teve de concordar que a coisa tinha melhorado muito. A empresa como um todo beneficiou-se com a maior disponibilidade dos sistemas e melhor serviço ao cliente. A cultura nascente de planejamento levou ao aumento de produtividade e a um gerenciamento de prioridades muito mais eficaz. Os usuários descobriram que o "day after" de cada manutenção não precisava ser a roleta-russa a que estavam acostumados. E os desenvolvedores aprenderam que trabalhar de forma planejada lhes rendia mais noites de sono não-interrompido (havia programadores que eram acordados à noite três vezes por semana, na maioria das vezes exigindo sua presença imediata para consertar programas "abendados") e a possibilidade de ir para casa no final do expediente, ao invés de às 11 horas da noite, como era a regra.

Observe-se que a empresa em questão é uma multinacional da área financeira, isto é, está imersa em um ambiente onde as mudanças acontecem muito depressa e a toda hora. Mudanças de mercado, mudanças de legislação, mudanças em diretrizes da matriz surgem o tempo todo. Mesmo assim, o processo descrito foi um sucesso total, e chegou-se a um nível de serviço invejável, sendo que verificou-se que apenas algo em torno de 10% das manutenções realmente necessitavam ser implementadas com urgência (prazo inferior duas semanas). Desta forma, se um processo como este pôde funcionar em uma organização com estas características, pode funcionar em qualquer ambiente empresarial.

Este exemplo deveria fazer com que gerentes de informática e usuários percebessem que o aumento da qualidade do software depende muito menos do uso de novas tecnologias do que do uso de práticas gerenciais adequadas. Treinar desenvolvedores e dar-lhes tempo para absorver o que aprenderam é fundamental. Impedir os usuários de colocar prazos absurdos para seus pedidos é fundamental. Alocar recursos (tempo, dinheiro e pessoas em dedicação integral) para trabalhar na melhoria dos processos de software é fundamental. É obvio que os desenvolvedores que estão construindo software não terão tempo para definir processos, metodologias, medir qualidade, definir, coletar e analisar métricas etc. Atribuir esta responsabilidade a quem está desenvolvendo software é a melhor garantia de que nada vai acontecer. Se queremos qualidade, temos que investir nela. Mas tendo a certeza de que este é um investimento que se paga muitas vezes. E em pouco tempo.

Publicado em Junho de 1997 na Developers Magazine.

Este artigo está apresentado aqui tal como foi enviado ao editor, podendo, devido ao processo de revisão da revista, estar ligeiramente diferente de sua versão publicada.

Ó Copyright por Átila Belloquim. Este documento pode ser reproduzido no todo ou em parte, desde que citada a fonte.

IV Encontro Brasileiro de Testes de Software

2010-02-22T15:52:00.002-03:00

O IV Encontro Brasileiro de Testes de Software, que acontecerá nos dias 23 e 24 de abril de 2010, tem como objetivo promover o intercâmbio de informações e experiências na área de testes de software entre a academia e as empresas envolvidas no processo de desenvolvimento, a fim de gerar debates e fomentar o desenvolvimento da área.

Inscrições e mais detalhes: www.gotest.biz/ebts2010/

9º Encontro Mensal: X-Zone - Framework de Teste Open Source

2010-02-22T10:54:00.001-03:00

Data: 6 de março (sábado)
Horário: 08:30 - 12:00
Local: Iterasys - Av. Paulista, 726 – Auditório – próximo a estação de metro Brigadeiro

Objetivo:
Aumentar o contato entre profissionais da área de Teste de Software e Garantia da Qualidade, bem como estimular a troca de conhecimentos, experiências e práticas de sucesso.

Tema do Encontro:
X-Zone

Conteúdo:
Apresentação do X-Zone e de suas funcionalidades. Trata-se de um framework de teste criado no Brasil por iniciativa do notório Alexandre Bartiê e distribuido como software de código aberto, em que profissionais e empresas podem baixar a ferramenta e utilizá-la gratuitamente, além de poder adaptá-la as suas necessidades.

Agenda:

08:30 Credenciamento e networking entre os participantes
09:00 Posse dos novos Diretores Regionais Adjuntos no mandato 2010
09:15 Claudio Schoeps - X-Zone
10:30 Coffee break e networking
11:00 Continuação da palestra
12:00 Encerramento

Palestrantes:
Cláudio de Vilhena Schoeps, graduado em Engenharia Eletrônica pela FAAP e especialização em Gestão Empresarial pela Business School São Paulo, com mais de 20 anos de atuação em desenvolvimento de sistemas, trabalhos realizados no Brasil e contratados pela Dinamarca, França e Alemanha para empresas dos setores Financeiro, Telecomunicações, entre outros. Atualmente, é responsável pela unidade de consultoria da Auditeste. Atuou como diretor das empresas Dataware, Flexsys e Simplify..

Inscrições:

Não Associados: R$ 30,00
Associados ALATS 15% de desconto

A participação na palestra Vale 3 PDTS para a renovação da CBTS
Reserve pelo e-mail sp@alats.org.br

Fonte: http://alats.org.br/Default.aspx?tabid=144

Oficina de TestComplete a distância (webconferência)

2010-02-22T10:40:00.000-03:00

Objetivos
Apresentar os principais conceitos associados à automação de testes de software, abordando os principais tipos de automação de testes funcionais, suas vantagens e limitações, os custos associados, o retorno de investimento e os principais requisitos para a implantação de uma iniciativa de automação de testes de sucesso. Serão apresentados exemplos práticos para reforçar os conceitos aprendidos por meio de exercícios utilizando uma ferramenta comercial de automação de testes (TestComplete).

Público alvo
Testadores, Analistas de testes, Analistas de Sistemas e profissionais na área de desenvolvimento de software.

Data e horário
15 a 18 de março das 19h00 às 21h00 (carga horária de 8 horas)

Metodologia
Oficina prática ao vivo com webconferência.

Ministrante
Cristiano Caetano: É certificado CBTS pela ALATS. Consultor de teste de software sênior com mais de 10 anos de experiência, já trabalhou na área de qualidade e teste de software para grandes empresas como Zero G, DELL e HP Invent. É colunista na área de Teste e Qualidade de software do site linhadecodigo.com.br e da revista Engenharia de Software Magazine. Autor dos livros "CVS: Controle de Versões e Desenvolvimento Colaborativo de Software" e "Automação e Gerenciamento de Testes: Aumentando a Produtividade com as Principais Soluções Open Source e Gratuitas". É criador e mantenedor do portal TestExpert, maior comunidade brasileira sobre teste e qualidade de software.

Investimento
250,00

Formas de pagamento
Cartão de crédito em até 12x, débito online ou boleto.

Conteúdo programático

Criando um novo projeto
Conhecendo o Project Workspace
Gravando um script de teste
Stores e Checkpoints
Checkpoints (Property checkpoint)
Checkpoints (Region checkpoint)
Gravando o script em tempo real
Visualizer
Definindo a ordem de execução dos scripts
Data-driven
Acesso ao banco de dados
Object Browser
Timer
Chamando uma função ou procedimento localizado em outra unit
Auto-complete
Code Template
Debugging scripts
Project Items
Tested Applications
Name mapping
Low Level Procedures
User Forms
Events
Manual Test
Tests Log
Testes distribuídos
Tratamento de janelas inesperadas
Procura de imagens
Localização de objetos por propriedades
Optical Character Recognition (OCR)

Infra-estrutura necessária

Hardware

Banda larga (Cable modem, DSL, etc)
Internet Explorer® 6.0 ou superior, Mozilla® Firefox® 3.0 or superior (JavaScriptT e JavaT habilitado)
Microfone (opcional)
Caixas de som (obrigatório)
Windows® 7, Vista, XP, 2003 Server or 2000
Pentium® 1GHz com 512 MB de RAM ou superior

Software

Para entrar na Webconferência será necessário instalar um plug-in no navegador (as instruções serão enviadas no início do curso)
TestComplete e demais softwares necessários para o curso (as instruções serão enviadas no início do curso)

Maiores informações e inscrições:

treinamento@testanywhere.com.br
/ 4052-9536

Plano de Teste - Padrão IEEE 829-1998

2010-02-03T17:18:00.001-02:00

O ideal seria que sempre houvesse uma equipe destinada a realizar testes de software, produzindo os relatórios necessários para que os problemas possam ser estudados e resolvidos. Mas nem todas as empresas possuem estrutura que suporte ter uma equipe que siga todas as instruções para a realização de testes.

Nestes casos, uma boa saída é nomear alguém da empresa que não esteja envolvido na produção do sistema para realizar os testes. Claro que nestes casos as empresas devem definir quais os principais testes devem ser realizados de forma a atingir as partes mais críticas do sistema.

Os erros encontrados devem ser documentados com informações suficientes que ajudem na reprodução do erro, facilitando assim a solução do problema. A documentação do erro deve ser definida pela empresa. É importante manter um histórico de falhas encontradas, pois assim, ao final do projeto, pode ser feito um estudo e obter um aprendizado em cima dos erros que foram encontrados.

Uma atividade de testes bem organizada pressupõe planejamento. O plano de testes facilita a comunicação entre os envolvidos no desenvolvimento do software ao propor um padrão de referência a ser seguido.

O padrão apresentado a seguir é uma adaptação do padrão de plano de testes do IEEE[1998], abrangendo o planejamento, especificação e documentação dos testes. Caso sejam necessárias mais seções, estas devem ser incluídas após a última.

PADRÃO IEEE 829-1998:

Plano de Teste - Padrão IEEE 829-1998

Propósito - descreve o escopo, os recursos, a abordagem e o tempo alocado para as atividades de teste. Identifica os itens e funcionalidades a serem testados, os responsáveis e os riscos.
Identificador – associa um identificador único ao plano de testes específico.
Introdução – resume os itens e funcionalidades a serem testados. Pode haver referências a outros documentos do processo de desenvolvimento.
Itens – Identifica os itens a serem testados, incluindo versão.
Funcionalidades – Identifica as funcionalidades que serão testadas ou não, assim como os motivos.
Abordagem – especifica as principais atividades, técnicas e ferramentas usadas para o teste das funcionalidades. O detalhamento deve ser suficiente para permitir identificação das principais tarefas de teste e a estimativa de tempo para cada uma. As restrições significativas como recursos e prazos, devem ser identificadas.
Critérios de aceite – especifica os critérios de aceite para cada item.
Suspensão – especifica os critérios para suspender parte ou toda a atividade de teste.
Especifica as atividades que devem ser repetidas quando o teste for retomado.
Produtos – identifica os documentos produzidos, como planos, procedimentos, logs e relatórios.
Tarefas de teste – identifica as atividades necessárias para preparar e executar os testes, bem como todas as dependências entre as tarefas.
Ambiente – identifica as atividades necessárias para preparar e executar os testes, bem como todas as dependências entre as tarefas.
Responsabilidades – identifica os grupos responsáveis por gerenciar, projetar, executar, verificar e resolver os testes. Identifica os grupos responsáveis pelo ambiente e pelos itens de teste.
Treinamento – especifica as necessidades de treinamento e identifica as opções.
Cronograma – identifica as atividades e os prazos de conclusão. Para cada recurso, como pessoas e ferramentas, especifica os períodos de alocação.
Riscos – identifica os maiores riscos e os planos de contingência.
Aprovações – especifica os nomes e cargos dos responsáveis por aprovar o plano.
Devem ser inclusos espaços para assinaturas e data.

Veja também:
Fases de Testes:
Fases de Testes

Tipos de Testes:
Teste de Caixa-Preta
Teste de Caixa-Branca
Testes de Estresse
Teste de Integração
Teste de Orientado a Objetos
Teste de Aceitação

Fases de Testes

2010-02-03T16:42:00.001-02:00

Teste de Unidade
Também conhecida como Teste Unitário. É a fase do processo de teste em que se testam as menores unidades de software desenvolvidas (pequenas partes ou unidades do sistema). Os alvos desse tipo de teste são os métodos dos objetos ou mesmo pequenos trechos de código. Assim, o objetivo é encontrar falhas de funcionamento dentro de uma pequena parte do sistema funcionando independentemente do todo. Cada parte do programa é isolada e testada afim de mostrar que funciona individualmente.
O teste de unidade não detecta todos os erros de um programa, como por exemplo, erros de integração e problemas de performance. Além disso, pode não ser fácil antecipar todos os casos especiais de input que a “unidade” do programa pode vir a receber. Esse tipo de teste é eficaz apenas se for usado conjuntamente com outras atividades de teste do software.

Teste de Integração
Na fase de teste de integração, o objetivo é encontrar falhas provenientes da integração interna das unidades de um sistema. Geralmente os tipos de falhas encontradas são de envio e recebimento de dados. Por exemplo, um objeto A pode estar aguardando o retorno de um valor X ao executar um método do objeto B, porém este objeto B pode retornar um valor Y, gerando uma falha. Não faz parte do escopo dessa fase de teste o tratamento de interfaces com outros sistemas (integração entre sistemas). Essas interfaces são testadas na fase de teste de sistema, apesar de, a critério do gerente de projeto, estas interfaces poderem ser testadas mesmo antes de o sistema estar plenamente construído.

Teste de Sistema
Na fase de Teste de Sistema o objetivo é executar o sistema sob o ponto de vista do seu usuário final, varrendo as funcionalidades em busca de falhas. Os testes são executados em condições similares - de ambiente, interfaces sistêmicas e massas de dados - àquelas que um usuário utilizará no seu dia-a-dia de manipulação do sistema. De acordo com a política de uma organização, podem ser utilizadas condições reais de ambiente, interfaces sistemáticas e massas de dados.

Teste de Aceitação
Fase de Teste em que o teste é conduzido por usuários finais do sistema. Os testes são realizados, geralmente, por um grupo restrito de usuários finais do sistema. Estes simulam operações de rotina do sistema de modo a verificar se seu comportamento está de acordo com o solicitado.
É um teste formal, conduzido para determinar se um sistema satisfaz ou não seus critérios de aceitação e para permitir ao cliente determinar se aceita ou não o sistema. É utilizado para a validação de um software pelo comprador, pelo usuário ou por terceira parte, com o uso de dados ou cenários específicos ou reais. Pode incluir testes funcionais, de configuração, de recuperação de falhas, de segurança e de desempenho.

Teste de Regressão
Fase de Teste aplicável a uma nova versão de software ou à necessidade de se executar um novo ciclo de teste durante o processo de desenvolvimento. Consiste em se aplicar, a cada nova versão do software ou a cada ciclo, todos os testes que já foram aplicados nas versões ou ciclos de teste anteriores do sistema. Inclui-se nesse contexto a observação de fases e técnicas de teste de acordo com o impacto de alterações provocado pela nova versão ou ciclo de teste. Para efeito de aumento de produtividade e de viabilidade dos testes, é recomendada a utilização de ferramentas de automação de testes, de forma que, sobre a nova versão ou ciclo de teste, todos os testes anteriores possam ser re-executados com maior agilidade.

Veja também:
Tipos de Testes:
Teste de Caixa-Preta
Teste de Caixa-Branca
Testes de Estresse
Teste de Integração
Teste de Orientado a Objetos
Teste de Aceitação

Excelência em TI - Uma Visão Prática e Integrada

2010-02-02T12:22:00.025-02:00

RESUMO

Este artigo tem como objetivo principal proporcionar uma visão geral e logicamente estruturada sobre as melhores práticas mundiais no segmento de Tecnologia da Informação (TI). Não é intenção do mesmo desenvolver uma idéia completamente nova ou debater modismos, mas sim discutir os jargões e temas muito falados, e na maioria das vezes pouco praticados em TI, de forma simples, integrada e prática.

No meio desta guerra de temas populares estão os modelos, normas e melhores práticas (CMMI, ITIL, Six Sigma, ISO9001, etc) que se disseminaram com o objetivo de ajudar os CIOs e gestores de TI em suas missões de promover a geração de valor e gerenciamento de riscos por meio da tecnologia da informação e comunicações. Esta proliferação de padrões e conseqüente necessidade de integração vêm na verdade causando mais “dor de cabeça” aos gestores de TI do que de fato trazendo os benefícios que se esperava.

Este artigo finaliza apresentando uma proposta de um framework que integra as melhores práticas mundiais visando ajudar as organizações na concepção, construção e execução de suas estratégias nas áreas de TI.

Alguns temas abordados pelo artigo são:

Indicadores financeiros e empresarias e sua ligação com TI
Planejamento e alinhamento de TI aos objetivos de negócios
Governança e gestão de TI
Gestão por processos
Melhores práticas mundiais
ISF for Excellence: uma solução integrada

1. PROPÓSITO DE UMA EMPRESA E GOVERNANÇA CORPORATIVA

Apesar de ser evidente que uma empresa hoje não sobrevive sem levar em consideração seu relacionamento com a sociedade, meio ambiente, seus profissionais e demais stakeholders, ainda é verdade, entretanto, que o maior e mais importante objetivo de uma empresa é “maximizar a riqueza de seus acionistas ou sócios” [BRIGHAM, 1999]. É prudente enfatizar então que o principal objetivo dos gestores de uma empresa é serem os agentes que trabalharão para os acionistas com a meta clara de maximizar os resultados da mesma.

Quando se buscam resultados o que de fato se está perseguindo são os lucros, ou melhor, o volume financeiro que fica na empresa após pagamento de todas as despesas. Este lucro precisa ainda ultrapassar uma margem de retorno esperada pelos acionistas que compense o investimento de capital na empresa (ex: ROIC – Retorno sobre o Capital Investido, EVA – Valor Econômico Agregado, etc). De outra forma, seria mais razoável aos sócios e acionistas simplesmente aplicar o dinheiro em algum investimento de menor risco, uma vez que gerenciar uma empresa é uma atividade que envolve grandes riscos e esta palavra não os agrada em nada. Outro ponto que precisa ser compreendido é que o lucro gerado por uma empresa pode ser revertido aos sócios ou mesmo reinvestido na própria empresa com objetivo de, claro, gerar mais lucro!

Diante deste cenário, existe em uma empresa dois públicos importantes – gestores e acionistas - que necessitam estar alinhados ao objetivo comum da organização que é maximizar riqueza. O fato é que em muitas situações isto não ocorre, gerando a necessidade da criação de controles e incentivos que permitam que os gestores tenham os comportamentos adequados e alinhados com as necessidades dos acionistas e sócios (definição de Governança Corporativa). Isto significa transparência, ética e credibilidade no relacionamento entre gestores e demais stakeholders.

Conclui-se então, com base nesta primeira visão, que a primeira e mais importante regra de alinhamento entre negócios e TI é que os gestores de tecnologia devem exercer seus papéis de gerenciar os ativos e processos de TI no sentido de maximizar a riqueza dos acionistas e sócios da empresa.

2. IMPORTÂNCIA DA TI PARA OS NEGÓCIOS E GOVERNANÇA DE TI

Torna-se cada vez mais evidente que a TI é crítica e necessária para a realização das estratégias de negócio das maiores empresas do mundo, mas ainda não é tão evidente que a TI possa criar problemas e gerar riscos às organizações. Algumas razões que fazem com que a TI possa gerar riscos às operações das empresas são:

Aumento da escala e custos dos investimentos em TI
Aumento da complexidade e riscos de TI
Crescente vulnerabilidade das informações estratégicas, com risco de perdas financeiras e fraudes

É válido relembrar que sócios e acionistas não gostam que riscos imponham possibilidade de perdas aos seus investimentos!

Em resumo, para que as atividades de TI se alinhem aos objetivos estratégicos da corporação, dois papéis fundamentais precisam ser exercitados (Fig. 1):

Gerar valor para as empresas, de maneira a aumentar o valor aos sócios e acionistas
Gerenciar riscos inerentes à própria TI - de maneira a minimizar quaisquer possibilidades de perda de valor aos sócios e acionistas

Fig 1 – Visão ISD Brasil de Governança de TI

Da mesma forma que a Governança Corporativa existe para regulamentar a relação dos gestores executivos com acionistas, sócios e demais stakeholders, a Governança de TI existe para deliberar sobre o relacionamento dos gestores e estrutura de TI com os gestores executivos da empresa, garantindo visibilidade, transparência e ética que permitam que a TI colabore com o objetivo número 1 da empresa que é gerar valor (vejam parte 1 deste artigo e Fig. 2).

Tipicamente a definição do que significa gerar valor fica a cargo do planejamento estratégico das empresas. Conseqüentemente, o que a área de tecnologia deve fazer para colaborar com tais objetivos vai derivar do seu alinhamento com os objetivos estabelecidos. Várias decisões e ações podem ser empreendidas com o objetivo de colaborar com a estratégia da empresa e dentre elas podemos destacar algumas:

Quais projetos de tecnologia devem ser executados?
Quais atividades de TI devem ser gerenciadas com mais ênfase, avaliando os riscos para os negócios?
Quais competências devem ser desenvolvidas em TI?
Quais indicadores estratégicos devem ser mensurados e acompanhados?
Quais atributos mais influenciam os clientes: preço, prazo, funcionalidade, qualidade?

Fig 2 – Fluxo de Governança e Gestão de TI

3. ESTRATÉGIA E BALANCED SCORECARD (BSC)

Segundo definição de Michael Porter [PORTER,1985], famoso guru de planejamento estratégico, estratégia é a forma pela qual uma empresa pretende se posicionar futuramente para obter vantagem competitiva em seu mercado. Ainda segundo Porter, este diferencial competitivo pode ser obtido de duas formas:

Liderança no custo (praticando menor custo ou preço) ou
Liderança por diferenciação (melhor produto, serviço, relacionamento, etc.).

Porter ainda afirma que a vantagem competitiva de uma empresa só pode ser diagnosticada e melhorada continuamente através da análise e melhoria de sua “cadeia de valor” (Fig. 3) que é o conjunto de atividades (processos) que são executados para projetar, produzir, comercializar, entregar e sustentar produtos e serviços.

Fig 3 – Cadeia de Valor de Porter

Com isso, conclui-se que Porter, de maneira bastante enfática, aponta para os processos como fonte para obtenção de vantagem competitiva frente à competição de mercado. A questão então passa a ser como fazer a estratégia da organização se alinhar com a estratégia de TI, e ainda como a estratégia vai se conectar aos processos de negócios (cadeia de valor) e de tecnologia da informação.

Atualmente, a mais conhecida e talvez mais utilizada metodologia para identificar a relação de causa-efeito entre processos e resultados e para desdobrar a estratégia em ações exeqüíveis, é o Balanced Scorecard (BSC).

O BSC, método concebido inicialmente por Robert Kaplan e David Norton em artigo para a Harvard Business School no ano de 1992 [KAPLAN, 1992], ajuda as organizações a planejar e entender sua estratégia de forma “balanceada”, não se limitando somente à definição de objetivos e metas estratégicas única e exclusivamente financeiras. Outro ponto importante é que ele possibilita um raciocínio estratégico que leva em consideração questões de curto, médio e longo prazo. Isto é possível por meio de sua concepção, fundamentada em quatro perspectivas: financeira; clientes; interna (ou processos); aprendizado e crescimento (inovação) (Fig. 4), que leva as empresas a pensar em como uma estratégia pode ser implementada por meio de uma visão encadeada de causa-efeito entre diferentes objetivos estratégicos em diferentes visões e perspectivas (stakeholders).

Fig. 4 – As perspectivas estratégicas do Balanced Scorecard

O BSC, em adição a outro instrumento derivado do trabalho de Kaplan e Norton chamado “Mapa Estratégico” (Fig. 5) [KAPLAN, 2004], ficou então famoso pela capacidade de mensurar a cadeia de criação de valor [PORTER, 1985] ou valor gerado pelos processos, em empresas e áreas de capital intelectual intensivo, tal como a área de TI. Esta abordagem vem ao encontro da necessidade de substituição ou complementação dos atuais controles contábeis e financeiros que atendem primariamente a área industrial e manufatura, nas quais o investimento é medido em grande parte pela compra de ativos tangíveis, isto é, uma máquina a mais representa mais produção e conseqüentemente mais geração de riqueza. Hoje já se sabe que os mais importantes fatores de produção (geração de valor para a empresa) nos países desenvolvidos são “invisíveis” e que o investimento em capital intangível (competências, processos, sistemas de gestão e qualidade, software, etc) está cada vez mais próximo do investimento feito em capital tangível (Fig. 6).

Fig. 5 – Mapa Estratégico de Kaplan e Norton

Em síntese, fica evidente que a TI deve ajudar as empresas na missão de gerar riqueza aos sócios e acionistas e ainda não ser a origem de prejuízos e riscos para o negócio. Isto é possível, conforme explicita o mapa estratégico de Kaplan e Norton (Fig. 5), por meio da constante inovação e melhoria contínua dos processos da organização, produzindo repetíveis sucessos e conseqüente satisfação aos clientes internos e externos da empresa.

Fig. 6 – Crescimento de Investimentos em Intangíveis nos EUA

4. A MÁQUINA DE CRIAÇÃO DE VALOR – “PROCESSOS”

Podemos definir um processo como um grupo organizado de atividades que cria valor para os clientes [HAMMER, 2002]. Já a gestão por processos pode ser caracterizada quando uma empresa possui sua estratégia e seu sistema de gestão (papéis, responsabilidades, metas, estrutura, etc) orientados por processos. O lado oposto da gestão por processos se dá quando uma empresa vive em função de seus departamentos, que geralmente atuam de forma independente, não colaborativa, sem foco no cliente final e chegando em muitos casos a atuar como se fossem efetivos feudos. Isto fica evidente quando entendemos que processos podem ser multifuncionais e cruzar múltiplas entidades (departamentos, empresas, etc.) e a estruturação departamental muitas vezes se limita a ser um simples mecanismo para distribuição de funções e agrupamento de pessoas. Desta forma, a gestão por processos representa uma nova perspectiva de trabalho para as organizações.

A disciplina e a repetibilidade criada pela execução continuada dos processos leva as empresas à previsibilidade de resultados, tirando a dependência de esforços extraordinários ou mesmo “da sorte” para obtenção do sucesso pretendido. Algumas pessoas tendem a ver os processos como um bloqueio para a criatividade ou como seu oposto, o que não é verdade. Pode-se afirmar com segurança que o oposto de processos significa imprevisibilidade. Quando as pessoas executam processos, elas direcionam sua criatividade para a atividade fim e não para a estruturação da atividade em si (o como fazer). Na prática, os processos acabam sendo catalisadores e canalizadores da inovação, da melhoria contínua e também da efetiva gestão do conhecimento.

Algumas das vantagens de ser uma empresa orientada a processos, são:

Linguajar comum criado na empresa em função da arquitetura de processos
Integração de departamentos, disciplinas, fornecedores, etc
Aumento da moral da força de trabalho pela redução de conflitos, pelo senso de participação e visão comum e principalmente pelo foco no cliente
Possibilidade de eliminação de atividades que não têm valor agregado
Possibilidade de melhoria da capacidade e desempenho dos processos ao longo do tempo
Previsibilidade de resultados
Satisfação dos clientes

Todas estas razões levaram o guru da gestão por processos, Michael Hammer [HAMMER, 2001] a declarar: “O futuro do século XXI pertence às empresas gerenciadas por processos”

5. BENCHMARKING E PROLIFERAÇÃO DE PADRÕES

Compreendida a importância da gestão por processos como fator de produção e criação de valor, torna-se necessário entender por onde e como começar. É a partir deste ponto que as organizações começam a perguntar se devem começar do marco zero ou se procuram amparo nas melhores práticas correntes de mercado (benchmarking), de modo que consigam acelerar seus trabalhos e aproveitar lições aprendidas da comunidade.

Thomas Davenport [DAVENPORT, 2005], em seu artigo para a Harvard Business School, “The Coming Commoditization of Processes”, classifica a criação de padrões de processos em três tipos:

Padrões de Fluxo de Processos – seqüência e o conjunto de atividades a serem executadas por uma organização (cadeia de valor de Porter)
Padrões de Desempenho de Processos – conjunto de indicadores e referenciais de comparação para benchmarking
Padrões de Gestão por Processos – conjunto de melhores práticas para gestão e acompanhamento do desempenho dos processos da organização

A gestão e melhoria de processos baseada em padrões envolve o uso de modelos e melhores práticas reconhecidas e testadas pelo mercado para guiar a definição e melhoria contínua de uma arquitetura ou sistema de processos.

Ao longo dos últimos anos um conjunto considerável de modelos, normas e melhores práticas emergiram no campo da administração, tecnologia da informação e melhoria de processos, com o objetivo de ajudar os líderes empresariais a estruturar seus sistemas de gestão de forma efetiva e enxuta. Alguns modelos, normas e melhores práticas são descritas a seguir:

Prêmio Nacional da Qualidade (PNQ) – versão brasileira do prêmio Malcolm Baldrige norte-americano, é composto por uma estrutura de critérios (ex: Liderança, Pessoas, Clientes, Processos) que quando aplicados em uma empresa, a conduzem à Excelência Empresarial. É bastante genérico e abrangente e geralmente sua obtenção traz grande reconhecimento às empresas ganhadoras. É visto como o “estado da arte” em gestão empresarial. www.fnq.org.br
Norma ISO9001:2000 - a Norma ISO 9001 versão 2000 é formada por um conjunto de itens ou requisitos que visam orientar as organizações na estruturação de um sistema de gestão da qualidade efetivo. A norma é também bastante genérica, visando atender a todos os segmentos (governo, serviços, industrias, tecnologia, etc.) e se consolidou no mundo como um necessário “cartão de visita” para as empresas estabelecerem contratos e realizarem negócios. www.iso.org
CMMI - O “Capability Maturity Model Integration” é o modelo de integração de melhores práticas no campo da engenharia de sistema e de software do Software Engineering Institute (SEI). Ele é o pioneiro e o mais utilizado modelo de melhores práticas hoje no segmento de TI no mundo. Praticamente todos os demais padrões voltados especificamente a TI possuem uma arquitetura similar ao CMMI., principalmente na avaliação de níveis de maturidade e capacidade de processos (benchmarking), utilizando sua estrutura de cinco níveis (Fig. 7). www.sei.cmu.edu/cmmi

Fig. 7 – Os cinco níveis de maturidade do CMMI

People CMM - O “People Capability Maturity Model” é o modelo de melhores práticas no campo da gestão de pessoas e capital humano do Software Engineering Institute (SEI). Ele é também pioneiro em sua área de atuação e utiliza a mesma estrutura interna e de avaliação do CMMI. O P-CMM, como é chamado, aborda por meio de suas Áreas de Processos (PAs) questões críticas da área de recursos humanos, tais como: compensação, gestão de competências, gestão de conhecimento, gestão de equipes e grupos de trabalho, carreira e mentoring. http://www.sei.cmu.edu/cmm-p/version2/
CobiT – O “Control Objectives for IT and related Technologies” é um framework de “boas práticas” voltado para Tecnologia da Informação. Inicialmente orientado a auditorias, o CobiT vem se consolidando com uma estrutura abrangente e importante para aspectos mais estratégicos de TI, tais como governança e visão estratégica. Ele é composto por 34 processos, organizados por domínios, que se desdobram em objetivos de controle e objetivos detalhados de controle, além de sugerir indicadores, alinhamento com objetivos de TI, etc. www.isaca.org
eSCM – O “Enabled-IT Sourcing Capability Model” é um modelo desenvolvido recentemente pela Carnegie Mellon University (CMU) constituído de 84 práticas voltadas a melhorar a capacidade e qualidade do serviço do fornecedor de TI especificamente nos serviços e relacionamentos de terceirização ou sourcing (outsourcing e insourcing). As práticas do eSCM estão organizadas por uma diversidade de Áreas de Capacidade (conhecimento, gestão de pessoas, gestão de desempenho, gestão de ameaças, gestão de serviços, etc.) que atendem ao ciclo completo de um contrato de sourcing, tratando desde as atividades iniciais de pré-contrato até as atividades de transferência do controle e conhecimento de volta para a organização compradora, ao final de um relacionamento. http://itsqc.cs.cmu.edu
ITIL – A “Information Technology Infrastructure Library”, como o próprio nome já denota, é um conjunto de boas práticas direcionadas à gestão de serviços prestados pela área de tecnologia da informação. Formado por um conjunto de livros (daí o nome biblioteca - library) recheados de informação, é considerada o “padrão de facto” atualmente no segmento de infra-estrutura e operações de TI. É valido afirmar que, apesar da redundância existente entre os padrões, o ITIL (serviços e operações) é a contra-parte do CMMI (desenvolvimento e produtos). O ITIL aborda questões tais como gestão de capacidade, gestão de níveis de serviço, gestão de configuração, gestão de mudanças, entre outros, que estão fora do escopo do CMMI. http://www.ogc.gov.uk
OPM3 – O “Organizational Project Management Maturity Model”, em conjunto com o eSCM compõe o hall dos padrões mais novos na área de TI. Criado pelo Project Management Institute (PMI) e derivado do Project Management Body of Knowledge (PMBOK), o OPM3 possui uma estrutura de modelo de maturidade similar ao do CMMI, abordando questões específicas relacionadas ao mundo da gestão de projeto, programas e portifólio. www.pmi.org

Nesta busca incessante pela melhoria contínua de processos e conseqüentemente de desempenho, as empresas lutam para extrair o máximo de valor das melhores práticas mundiais, guiadas tipicamente por pressões dos clientes, dos compradores, do mercado ou mesmo pressões regulatórias. Neste cenário, a proliferação de padrões, que deveria ser um fator positivo, vem se tornando uma ameaça às estratégias das áreas de TI e, por conseqüência, impondo um conjunto desafiador de questões aos seus executivos, tais como:

Como posso criar um sistema de gestão (processos) baseado em modelos e melhores práticas que adicione efetivo valor aos negócios e me ajude a gerenciar riscos?
Como posso criar um sistema de gestão (processos) baseado em modelos e melhores práticas sem ter que lidar com múltiplos padrões, estruturas, investimentos, fornecedores, etc.?
É possível para minha empresa reduzir complexidade e custos através da integração de minhas diversas iniciativas de melhoria (ISO9001:2000, Seis Sigma, CMMI, ITIL, PMO, etc)?
É possível para minha empresa avaliar e/ou auditar a eficácia de meu sistema de gestão e dos meus fornecedores, avaliando resultados e riscos, utilizando um único framework de melhores práticas?

6. SOLUÇÃO INTEGRADA

O Integrated System Framework (ISF for Excellence) [VASQUES, 2001] ou framework integrado de melhores práticas, foi desenvolvido pela ISD Brasil com o objetivo de eliminar redundâncias, complexidade, confusão, barreiras e desperdícios (custos), no constante desafio das empresas de estruturar sistemas de gestão (processos) que agreguem valor e gerem resultados efetivos repetíveis para os acionistas e sócios. O framework visa ainda ajudar CIOs e executivos de TI a navegar e entender os diversos modelos e melhores práticas disponíveis, de uma forma pragmática e lógica, eliminando a necessidade de conhecimento profundo de “cada referência” (estruturas, abordagens, etc). Uma das intenções do ISF for Excellence é a consecução de alto desempenho nos processos de TI das organizações, a evolução em progressivos níveis de maturidade e, em ultima instância, a obtenção de conformidade e certificações com os diversos padrões de forma simultânea e transparente.

O surgimento do ISF for Excellence teve ainda como premissa a criação de uma estrutura sustentável e evolutiva que possa contemplar a inclusão e relacionamento de novos modelos à estrutura atual, conforme necessário. É importante enfatizar que o objetivo desta iniciativa não foi o desenvolvimento de um modelo novo, mas sim proporcionar ao mercado uma visão de maior grau de abstração (camada mais alta), mais simples e prática de como entender de forma integrada as diversas iniciativas de melhoria disponíveis no segmento de TI.

Para que a integração dos diversos padrões fosse possível, o primeiro passo foi reconhecer que os mesmos compartilham um conjunto de princípios e fundamentos comuns:

Compromisso e Liderança da Alta-Direção
Foco no cliente
Foco nas pessoas
Gestão por Processos
Decisão baseada em fatos
Aprendizado pessoal e organizacional
Gestão dos relacionamentos (stakeholders)

Padrões incorporados na versão inicial do ISF for Excellence.

Capability Maturity Model Integration – CMMI	ISO9001:2000 Standard
Control Objectives for Information and related Technology - CobiT	ISO15504 Standard
Enabled IT Sourcing Capability Model - eSCM	People Capability Maturity Model – People CMM
Information Technology Infrastructure Library - ITIL	Six Sigma Methodology
PNQ / Malcolm Baldrige Award	Organizational Project Management Maturity Model - OPM3

O ISF for Excellence utiliza diferentes visões gráficas para ilustrar a maneira evolucionária e incremental na qual os modelos e melhores práticas se integram.

Fig. 8 – Visão de Relacionamento do ISF for Excellence

A Visão de Relacionamento (Fig. 8) visa destacar o propósito “central” de cada modelo, bem como seu relacionamento com os demais. É importante destacar que esta visão do framework não pretende impor uma idéia de hierarquia ou mesmo induzir seus usuários a concluir que certos modelos não cobrem determinadas disciplinas ou áreas, mas apresentar os modelos de forma integrada, cada um sendo utilizado e explorado em seu potencial máximo e central.

A Visão Sistêmica (Fig. 9) traz uma perspectiva inovadora, proporcionando às organizações uma visão holística da aplicabilidade dos modelos e melhores práticas, facilitando a visualização de como os processos interagem uns com os outros para criação de valor (Tabela 1) e também auxiliando na análise e priorização de processos para implementação, controle, melhoria ou reengenharia. Esta visão também constitui o primeiro grande passo no esforço de integrar as diferentes estruturas e abordagens dos padrões envolvidos no framework. Nesta visão, categorias de processos são identificadas e estabelecidas e posteriormente desdobradas em “Áreas Críticas de Desempenho” (Fig. 10)

Fig. 9 – Visão Sistêmica do ISF for Excellence

Cadeia de Criação de Valor do ISF for Excellence (Fig. 9)

1. As empresas identificam suas estratégias baseadas em fatores internos (capital humano, desempenho, infra-estrutura) e fatores externos (benchmarking, informações de mercado e competição)

2. Baseadas no alinhamento necessário, na liderança e nos compromissos estabelecidos, as estruturas internas necessárias (RH, TI, etc.) são estabelecidas ou direcionadas a ajudar a empresa na missão de “entregar valor” aos clientes

3. Acordos de níveis de serviço e contratos são discutidos, negociados e fechados com os clientes

4. Produtos e serviços são projetados, construídos, testados e entregues

5. Gestão e suporte são empregados para entregas rápidas, baratas e com qualidade

6. O desempenho da organização e a satisfação e sucesso dos clientes são medidos, comparados e analisados para determinar áreas de melhoria e inovação

7. A estratégia é reavaliada, re-alinhada e redirecionada e o ciclo de melhoria começa novamente.

Tabela 1 – Cadeia de Criação de Valor do ISF for Excellence

Fig. 10 – Áreas Críticas de Desempenho – Desdobramento da Categoria “Human Capital”

O ISF for Excellence tem ainda por objetivo alavancar e utilizar os pontos fortes dos modelos e melhores práticas, sempre que possível. Um exemplo disto é o uso da representação de níveis de maturidade da família CMM do SEI, constituindo assim a Visão de Maturidade Integrada de TI (Fig. 11) do framework. Cada categoria de processo na base da pirâmide possui uma diversidade de Áreas Críticas de Desempenho (Fig. 10) distribuídas por nível de maturidade (2 ao 5) de forma que uma organização possa evoluir tanto na categoria específica (a) quanto na visão multifuncional (b).

Fig. 11 – Visão de Maturidade do ISF for Excellence

7. CONCLUSÃO
Em resumo, o papel do executivo de TI é garantir a colaboração e o alinhamento de sua organização, visando ajudar a empresa no objetivo máximo de gerar valor (ou não destruí-lo) de forma transparente, disciplinada e madura. Um grande instrumento disponível hoje para este alinhamento estratégico é o Balanced Scorecard (BSC) que facilita o desdobramento da estratégia da empresa até o nível dos processos produtivos (cadeia de valor de Porter) e dos ativos intangíveis, tais como capital humano e tecnologia. Em função do reconhecimento do poder e vantagem competitiva que se pode criar por meio de uma gestão baseada em processos, modelos, normas e melhores práticas foram criadas para auxiliar o executivo de TI em sua tarefa de conceber e melhorar continuamente um sistema de gestão (processos, estruturas, etc) eficaz. Entretanto, esta proliferação de padrões vem trazendo mais dificuldades e barreiras do que os benefícios prometidos. O ISF for Excellence vem preencher esta lacuna no sentido de facilitar o entendimento, implementação e avaliação destas melhores práticas, propiciando os seguintes benefícios:

É uma forma unificada de integrar e implementas melhores práticas oriundas de vários padrões diferentes
Valoriza as complementaridades e sinergias entre padrões e reduz redundâncias, complexidades e custos associados, apresentando resultados mais rápidos
Sua visão holística apresenta os padrões de forma lógica e simplificada
É um framework organizacional para gestão e governança de TI
Tem uma visão de modelo de maturidade multifuncional, englobando outras disciplinas, tais como: serviços, outsourcing, pessoas e estratégia
Possibilita avaliações e auditorias multi-modelos e multifuncionais (ex: eSCM, ISO9001, CMMI, ITIL)
Torna-se uma ferramenta estratégica na seleção e monitoramento de fornecedores em TI
É um caminho estruturado para implementação de gestão de processos de TI visando a excelência organizacional

8. REFERÊNCIAS
[BRIGHAM, 1999] BRIGHAM, Eugene; GAPENSKI, Louis e EHRHARDT, Michael. “Financial Management: Theory and Practice”, Editora Dryden, 1999.
[DAVENPORT, 2005] DAVENPORT, Thomas. “The Coming Commoditization of Processes”. Havard Business School, 2005.
[IBGC] Instituto Brasileiro de Governança Corporativa - http://www.ibgc.org.br/ibConteudo.asp?IDArea=2
[HAMMER, 2001] HAMMER, Michael. “The Process Enterprise”. Hammer and Company, 2001.
[HAMMER, 2002] HAMMER, Michael. “Process Management and the Future of Six Sigma”. MITSloan Management Review, Winter 2002.
[KAPLAN, 1992] KAPLAN, Robert e NORTON, David A. “The Balanced Scorecard: Measures that Drive Performance”, Harvard Business School , 1992.
[KAPLAN, 2004] KAPLAN, Robert e NORTON, David A. “Strategy Maps: Converting Intangible Assets into Tangible Outcomes”, Harvard Business School Press, 2004.
[PORTER, 1985] PORTER, Michael. “Competitive Advantage”. Editora Elsevier, 1985.
[VASQUES, 2001] VASQUES, Renato Chaves “Integrated System Framework for Excellence (ISF for Excellence)”. ISD Brasil, 2001.

CMM, CMMI, People CMM and Capability Maturity Model are registered in the U.S. Patent and Trademark Office for SEI
Malcolm Baldrige Award is intellectual property of NIST
Six Sigma is a registered trademark and service mark of Motorola, Inc
eSCM is intellectual property of Carnegie Mellon University
CobiT is intellectual property and trademark of ISACA
ITIL is intellectual property and trademark of OGC
OPM3 is intellectual property and trademark of PMI
ISO9001:2000 and ISO15504 is intellectual property and trademark of ISO
Integrated System Framework for Excellence (ISF for Excellence) is intellectual property of ISD Inc and is registered as a service mark of ISD Brasil
Appraisal Wizard, Model Wizard and Model Mapper are intellectual properties of ISD Inc.

Assuntos Relacionados: governança de TI; gestão de TI; alinhamento e planejamento estratégico de TI; melhoria de processos; gestão por processos; vantagem competitiva; qualidade; Balanced Scorecard; maturidade e desempenho organizacional; framework integrado.

Por Renato Chaves Vasques

Teste de Aceitação

2010-01-21T15:22:00.002-02:00

O teste de aceitação é realizado com o propósito de avaliar a qualidade externa do produto e, na medida do possível, também a qualidade em uso. Assim, só é possível quando o software está concluído e pronto para ser implantado. Evidentemente, é um teste com forte relação com o cliente, que participa do planejamento e realização dessa atividade.

O teste de aceitação é geralmente denominado de “alfa” quando realizado no ambiente de desenvolvimento (qualidade externa) e “beta” quando no ambiente do cliente (qualidade de uso). O teste de qualidade externa é com freqüência a única alternativa no caso de aplicações desenvolvidas para mainframes. Uma forma de paliar a impossibilidade de utilizar a plataforma definitiva de execução é simulá-la, por exemplo, utilizando dados reais.

Outro tipo de teste de aceitação possível é o teste de paralelo, quando um sistema é desenvolvido para
substituir outro já em funcionamento. O novo sistema pode funcionar em paralelo ao antigo e o comportamento de ambos é comparado, até que se decida que a substituição é possível. O teste em paralelo é indicado, por exemplo, em sistemas críticos.

Veja também:

Teste de Caixa-Preta
Teste de Caixa-Branca
Testes de Estresse
Teste de Integração
Teste de Orientado a Objetos

Teste Orientado a Objetos

2010-01-21T15:17:00.002-02:00

O teste orientado a objetos consiste em realizar seqüências de envios de mensagens. Essas sequências devem ser escolhidas de maneira a explorar o maior número possível de estados que um objeto possa assumir e as transições entre eles.

Para que esse tipo de verificação seja eficiente, é interessante reduzir ao mínimo o número de casos de teste aplicados. Considere estas duas seqüências em C++ usando a biblioteca STL:

Seqüência 1:
v.erase (v.begin() + 3);
v.insert (v.begin() + 3, 100);

Seqüência 2:
v.insert (v.begin() + 3, 100);
v.erase (v.begin() + 4);

As duas seqüências de chamadas provocam exatamente o mesmo efeito: substituir o terceiro elemento de um vetor. É possível criar inúmeros casos de teste diferentes que levam um objeto exatamente ao mesmo estado. Se não for relevante testar diferentes caminhos, isto é, as transições que provocam a mudança, é melhor utilizar um único caso de teste.

Existem ferramentas para geração de casos de teste para orientação a objetos, como JCrasher, gratuita, Jtest e JC++, da Parasoft, que evitam testes redundantes.

Veja também:

Teste de Caixa-Preta
Teste de Caixa-Branca
Testes de Estresse
Teste de Integração
Teste de Aceitação