You are on page 1of 246

QualidadeBR

Um ano falando sobre Teste e Qualidade de Software
























Fabrcio Ferrari de Campos



2


3
Dedicatria
Dedico esse livro a todos os leitores e visitantes do QualidadeBR, afinal vocs deram
foras para ele chegar no seu primeiro aniversrio. E espero que esse seja o primeiro
aniversrio de muitos.


4
Contedo
Prefcio por Andr Pantalio ...................................................................... 12
Sobre o Autor .............................................................................................. 13
Sobre o Livro ............................................................................................... 14
Teste e Qualidade de Software .................................................................... 15
1. O Que Qualidade de Software? ........................................................................... 16
2. O Que Bug? ......................................................................................................... 17
3. Qualidades de um especialista em teste .................................................................. 19
4. Defeito, erro e falha. tudo igual? ......................................................................... 20
5. Teste Estrutural X Teste Funcional ........................................................................ 21
6. FURPS+ .................................................................................................................. 22
7. Ambientes de Teste Virtuais................................................................................... 24
8. Quando os testes devem parar? .............................................................................. 26
9. Testar X Debugar.................................................................................................... 27
10. Carreira Teste de Software ................................................................................ 29
11. Qualidade Sem Nome ........................................................................................... 32
12. Testes de sobrevivncia ........................................................................................ 34
13. Fuzz Testing ......................................................................................................... 35
14. A Importncia da Usabilidade .............................................................................. 37
15. Qualidade de Software Processo ou Projeto? .................................................... 40
16. Mercado atual Teste e Qualidade de Software .................................................. 42
17. Tcnicas de Integrao de Sistema Incremental ................................................ 44
18. Tcnicas de Integrao de Sistema Top Down .................................................. 46
19. Por que testar? ...................................................................................................... 48
20. A Importncia do Teste de Software .................................................................... 49
21. Interface Homem-Mquina: Melhores Prticas de Usabilidade ........................... 50

5
22. Tcnicas de modelagem de teste (parte 1) ............................................................ 52
23. Tcnicas de modelagem de teste (parte 2) ............................................................ 53
24. Excelncia ............................................................................................................. 55
25. Coberturas ............................................................................................................. 57
26. Tcnicas de Integrao de Sistema Bottom Up ................................................. 59
27. Tcnicas de Integrao de Sistema Big Bang e Sandwich ................................ 62
28. O melhor da semana: 03/05 a 09/05 ..................................................................... 66
29. O melhor da semana: 10/05 a 16/05 ..................................................................... 67
30. O melhor da semana: 17/05 a 23/05 ..................................................................... 68
31. O melhor da semana 24/05 a 30/05 ...................................................................... 69
32 - Neutralizando Falhas ........................................................................................... 70
33 - O melhor da semana 31/05 a 06/06 ..................................................................... 72
34 - Anlise de Causa Raiz ......................................................................................... 74
35 - O melhor da semana 07/06 a 13/06 ..................................................................... 76
Ferramentas & Tutoriais ............................................................................. 77
1. Construindo um Ambiente Virtual (parte1)............................................................ 78
2. Construindo um ambiente virtual (parte2) ............................................................. 83
3. Construindo um ambiente virtual (parte3) ............................................................. 93
4. FireShot: Plugin para Screenshots ........................................................................ 103
5. Ferramentas bug tracking ..................................................................................... 104
6. Tutorial Eventum (parte 1) ................................................................................... 106
7. Tutorial Eventum (parte 2) ................................................................................... 114
8. Tutorial Eventum (parte 3) ................................................................................... 124
Certificaes .............................................................................................. 137
1. Certificao Brasileira de Teste de Software (CBTS) .......................................... 138
2. CTFL BSTQB ................................................................................................... 140
3. Certificao: IBM Certified Specialist Software Quality .................................. 143

6
4. QAMP (Quality Assurance Management Professional) ....................................... 145
5. Simulados CTFL-BSTQB .................................................................................... 147
6. Resoluo de questes CTFL: Q1S1 .................................................................... 148
7. Resoluo de questes CTFL: Q13S1 .................................................................. 150
8. Resoluo de questes CTFL: Q5S2 .................................................................... 154
9. Resoluo de questes CTFL: Q12S2 .................................................................. 157
10. Resoluo de questes CTFL: Q14S1 ................................................................ 159
11. Resoluo de questes CTFL: Q13S2 ................................................................ 161
12. Resoluo de questes CTFL: Q14S2 ................................................................ 162
13. Resoluo de questes CTFL: Q15S2 ................................................................ 164
14. Resoluo de questes CTFL: Q36S3 ................................................................ 166
15. Impresses exame CTFL-BSTQB ...................................................................... 167
16. Exame IBM 000-370 cancelado no Brasil .......................................................... 168
17. Impresses exame IBM 000-370 ........................................................................ 169
Eventos ...................................................................................................... 171
1. Brateste 2009 ........................................................................................................ 172
2. Cobertura BRATESTE 2009 (1 Dia) .................................................................. 176
3. Cobertura BRATESTE 2009 (2 Dia) .................................................................. 182
4. Concluso BRATESTE 2009 ............................................................................... 188
5. 1 Encontro Mensal da ALATS So Paulo ........................................................... 190
6. Impresses do 1 Encontro Mensal da ALATS So Paulo ................................... 192
7. 2 Encontro Mensal da ALATS So Paulo ........................................................... 195
8. Impresses do 2 Encontro Mensal da ALATS So Paulo ................................... 197
9. 2 Seminrio de Teste de Software do Rio de Janeiro .......................................... 200
10. Adiado o 3 Encontro Mensal da ALATS .......................................................... 201
Gerncia de Projetos ................................................................................. 203
1. TRIZ Teoria da Resoluo de Problemas Inventivos ........................................ 204

7
2. 3P Piores Prticas de Projeto (parte 1) .............................................................. 207
3. 3P Piores Prticas de Projeto (parte 2) .............................................................. 209
Modelos ..................................................................................................... 211
1. MPS.BR ................................................................................................................ 212
Desenvolvimento de Software .................................................................. 216
1. Qual a melhor metodologia?................................................................................. 217
Humor ........................................................................................................ 220
1. As Etapas do Desenvolvimento de Software ........................................................ 221
2.Vida de Programador ............................................................................................. 223
Dicas .......................................................................................................... 224
1. Padro de Nomes de Componentes ...................................................................... 225
2. Revistas sobre Teste e Qualidade de Software ..................................................... 228
3. O Twitter como meio de comunicao interna ..................................................... 229
Off ............................................................................................................. 231
1. TCC ...................................................................................................................... 232
2. Paixo ou dinheiro? .............................................................................................. 233
3. Apresentao TCC ................................................................................................ 235
4. Feliz Ano Novo .................................................................................................... 237
5. Errar humano ..................................................................................................... 238
6. Entusiasmo ........................................................................................................... 239
7. Trabalhe, trabalhe, trabalhe em equipe ................................................................. 240
8. A Importncia da Maturidade ............................................................................... 242
Curiosidades do QualidadeBR .................................................................. 245
As Caras do QualidadeBR ........................................................................ 246



8
Sumrio de Figuras
Figura 1 - (retirada do myoldmac) .................................................................................. 17
Figura 2 - (retirada de IBM Archives) ............................................................................ 17
Figura 3 - "Evoluo" do bug ......................................................................................... 20
Figura 4 - FURPS ........................................................................................................... 22
Figura 5 - FURPS+ (retirada de Rational Library) ......................................................... 23
Figura 6 - Hierarquia - rea de Testes ........................................................................... 31
Figura 7 - Exemplo Top Down ....................................................................................... 46
Figura 8 - Seu Creysson ................................................................................................. 57
Figura 9 - Coberturas ...................................................................................................... 58
Figura 10 - Integrao Bottom-up dos mdulos E, F, e G.............................................. 59
Figura 11 - Integrao Bottom-up dos mdulos B, C, e D com o E, F, e G. .................. 60
Figura 12 - Integrao Bottom-up do mdulo A com todos os outros. .......................... 60
Figura 13 - Big Bang ...................................................................................................... 62
Figura 14 - Ilustrao do uso da tcnica Big - bang ....................................................... 63
Figura 15 - Sanduche de Mortadela do Bar do Man no Mercado SP ........................ 64
Figura 16 - Arquitetura do servidor com 4 mquinas virtuais (retirada do Data Sheet do
VMware Server) ............................................................................................................. 78
Figura 17 - Primeiro passo da instalao do VMware Server ........................................ 79
Figura 18 - Segundo passo da instalao do VMware Server ........................................ 80
Figura 19 - Terceiro passo da instalao do VMware Server......................................... 81
Figura 20 - Quarto passo da instalao do VMware Server ........................................... 81
Figura 21 - Quinto passo da instalao do VMware Server ........................................... 82
Figura 22 - Sexto passo da instalao do VMware Server ............................................. 82
Figura 23 - Visualizao dos servios do VMware Server ............................................ 83
Figura 24 - Login no VMware Server ............................................................................ 83
Figura 25 - Criao da mquina virtual .......................................................................... 84
Figura 26 - Selecionando o sistema operacional que ser instalado ............................... 84
Figura 27 - Configurando a memria e a quantidade de processadores da VM ............. 85
Figura 28 - Criao do disco virtual ............................................................................... 85
Figura 29 - Configurando as propriedades do disco virtual ........................................... 86
Figura 30 - Criando o adaptador de rede ........................................................................ 87
Figura 31 - Ilustrao da conexo Bridged ..................................................................... 87

9
Figura 32 - Ilustrao da conexo HostOnly .................................................................. 88
Figura 33 - Ilustrao da conexo NAT ......................................................................... 88
Figura 34 - Definindo as propriedades da conexo de rede ........................................... 89
Figura 35 - Definindo o acesso ao drive de CD/DVD .................................................... 89
Figura 36 - Configurando o drive de CD/DVD .............................................................. 90
Figura 37 - Definindo o drive de disquete ...................................................................... 90
Figura 38 - Configurando o drive de disquete ................................................................ 91
Figura 39 - Definindo o controlador USB ...................................................................... 91
Figura 40 - Visualizao das informaes da VM ......................................................... 92
Figura 41 - Informaes sobre a VM.............................................................................. 93
Figura 42 - Aviso sobre a instalao do plug-in ............................................................. 94
Figura 43 - VMware Remote Console pronto para ser usado ........................................ 94
Figura 44 - Tela do VMware Remote Console............................................................... 95
Figura 45 - Host e VM .................................................................................................... 95
Figura 46 - Opes oferecidas ao iniciar pelo CD do Ubuntu........................................ 97
Figura 47 - Escolha o idioma .......................................................................................... 97
Figura 48 - Informe a sua localidade .............................................................................. 98
Figura 49 - Escolha o layout do teclado ......................................................................... 98
Figura 50 - Escolha a opo Assistido............................................................................ 99
Figura 51 - Informe os dados de login .......................................................................... 100
Figura 52 - Visualizao das informaes referentes a instalao ............................... 100
Figura 53 - Progresso da instalao do Ubuntu ............................................................ 101
Figura 54 - Aps a instalao necessrio reiniciar a VM .......................................... 101
Figura 55 - Aps ter reiniciado o Ubuntu j est instalado na VM .............................. 102
Figura 56 - FireShot ...................................................................................................... 103
Figura 57 - Primeiro passo da instalao do Apache2Triad ......................................... 107
Figura 58 - Defina o local da instalao do Apache2Triad .......................................... 108
Figura 59 - Defina a senha para acesso ao Apache2Triad ............................................ 108
Figura 60 - Apresentao da licena GNU ................................................................... 109
Figura 61 - Progresso da instalao do Apache2Triad ................................................. 109
Figura 62 - Instalao concluda ................................................................................... 110
Figura 63 - Informe a senha .......................................................................................... 110
Figura 64 - Ser necessrio reiniciar o computador ..................................................... 110
Figura 65 - Diretrio do Apache................................................................................... 111

10
Figura 66 - Pgina de instalao do Eventum .............................................................. 112
Figura 67 - Pgina aps a instalao do Eventum ........................................................ 113
Figura 68 - Pgina de login do Eventum ...................................................................... 113
Figura 69 - Pgina principal do Eventum ..................................................................... 114
Figura 70 - Pgina de administrao do Eventum ........................................................ 115
Figura 71 - Pgina de configurao do Eventum ......................................................... 116
Figura 72 - Pgina de gerenciamento de campo customizado...................................... 117
Figura 73 - Pgina de gerenciamento dos status .......................................................... 118
Figura 74 - Pgina de gerenciamento de usurios ........................................................ 119
Figura 75 - Pgina de gerenciamento de projetos ........................................................ 120
Figura 76 - Abaixo a opo de reportar uma issue sem logar ...................................... 122
Figura 77 - Pgina de reporte annimo de issue ........................................................... 122
Figura 78 - Pgina de reporte de issue .......................................................................... 124
Figura 79 - Pgina de fechamento de issue .................................................................. 125
Figura 80 - Gerenciamento de campos customizados .................................................. 127
Figura 81 - Tarefas agendadas do Windows ................................................................ 129
Figura 82 - Criao da tarefa agendada ........................................................................ 129
Figura 83 - Informe quando a tarefa vai ser executada ................................................ 130
Figura 84 - Informe o incio da tarefa........................................................................... 130
Figura 85 - Informe os dados de login para que a tarefa seja realizada ....................... 131
Figura 86 - Visualizao dos dados da tarefa agendada ............................................... 131
Figura 87 - Edio da tarefa agendada ......................................................................... 132
Figura 88 - Opes avanadas de agendamento ........................................................... 133
Figura 89 - Configuraes da tarefa agendada ............................................................. 133
Figura 90 - Visualizao da tarefa agendada ................................................................ 134
Figura 91 - Link para visualizar o status do envio de e-mail ....................................... 135
Figura 92 - Visualizao do status do envio de e-mail da issue ................................... 135
Figura 93 - Ilustrao do fluxo ..................................................................................... 151
Figura 94 - Ilustrao do fluxo ..................................................................................... 152
Figura 95 - Ilustrao do fluxo ..................................................................................... 160
Figura 96 - BRATESTE 2009 ...................................................................................... 175
Figura 97 - 7 nveis de maturidade (retirado do site da empresa Pentagrama) ............ 213
Figura 98 - Comparao entre as metodologias (retirado do material da AzIT) .......... 218
Figura 99 - Desenvolvimento de Software ................................................................... 222

11
Figura 100 - Vida de programador ............................................................................... 223
Figura 101 - Padro de nomes de componente ............................................................. 225
Figura 102 - Padro de nomes de componente ............................................................. 226
Figura 103 - Padro de nomes de componente ............................................................. 227
Figura 104 - Feliz Ano Novo ........................................................................................ 237
Figura 105 - Primeiro header ........................................................................................ 246
Figura 106 - Segundo header ........................................................................................ 246
Figura 107 - Terceiro header ........................................................................................ 246
Figura 108 - Quarto header ........................................................................................... 246


12
Prefcio por Andr Pantalio
Primeiramente um grande prazer ser convidado para escrever o prefcio deste livro do
Fabrcio.

Trabalho com o Fabrcio na Voice Technology j h alguns anos. E o tempo passa!
Estive presente no seu processo de seleo, onde ele teve seu primeiro contato
profissional com o mundo de software. Acompanhei o seu desenvolvimento at o
estgio atual, como Analista de Testes de nosso sistema Centrex de telefonia IP, o
Basix.

Esta caminhada na rea de testes foi traada com muito estudo, certificaes, dvidas,
tentativas e reflexes. Muitas dvidas foram sanadas e conhecimentos adquiridos ao
longo destes anos e em especial deste ltimo. Uma boa parte deste ltimo ano de
caminhada foi retratada nas pginas deste livro. Vale a leitura!

Antes de terminar, uma pequena observao. L na empresa costumamos dizer que
formamos bons profissionais. Mas, na verdade, somente auxiliamos um pouco, tentando
criar um ambiente propcio para desenvolvimento dos profissionais. O salto de
qualidade, o profissional diferenciado do mercado, s ser obtido aps muito esforo e
estudo. E este profissional diferenciado, que alegremente, podemos comprovar que
Fabrcio est se tornando.

No deixe de ler o livro e se discordar de algo, entre em contato com ele, critique e faa
sugestes. Assim todos evolumos e produzimos mais conhecimento.

Fabrcio, obrigado pelo convite e parabns!

13
Sobre o Autor
Sou Fabrcio Ferrari de Campos, certificado ISTQB e CBTS.
Trabalho na rea de Teste e Qualidade de Software na empresa
Voice Technology. Formado em Tecnologia em Anlise e
Desenvolvimento de Sistemas pela Faculdade de Tecnologia
Termomecanica.
Iniciei o QualidadeBR como forma de me motivar a estar estudando constantemente
sobre a rea de Teste e Qualidade de Software, assim como poder compartilhar os
conhecimentos e experincias adquiridos, afinal o conhecimento s tem valor, quando
compartilhado. :)
E tambm para tentar retribuir toda a ajuda que obtive, e ainda obtenho, da comunidade
de Teste e Qualidade de Software.


14
Sobre o Livro
Esse livro uma compilao de todos os posts publicados no blog QualidadeBR, entre
o perodo de 19 de junho de 2008 19 de junho de 2009, em comemorao do
aniversrio de 1 ano do blog.




15


Teste e Qualidade de Software

Teste e Qualidade de Software

16
1. O Que Qualidade de Software?
Para definir Qualidade de Software (QS), necessitamos primeiro saber o que
qualidade:

Segundo a Wikipdia: Qualidade um conceito subjetivo que est relacionado
diretamente s percepes de cada indivduo. Diversos fatores como cultura, modelos
mentais, tipo de produto ou servio prestado, necessidades e expectativas influenciam
diretamente nesta definio.

Como podemos perceber, qualidade um substantivo que pode ter muitos significados.
Isso acontece pela forte ligao com as percepes das pessoas, que tem pensamentos e
gostos diferentes.

Ento, qual seria a definio para QS? Estaria ela tambm fadada s percepes do
ser humano?

A QS assim como as outras est ligada diretamente as opinies das pessoas, que neste
caso, so representadas pelos clientes, usurios e envolvidos com o projeto de software.
Possuindo as seguintes caractersticas:

QS est fortemente relacionada conformidade com os requisitos;
Ela caracteriza o grau de satisfao do cliente;
No responsabilidade de apenas uma rea da empresa, e sim de todos;
Deve est presente desde o planejamento do software.

Atualmente, QS vem ganhando um grande foco nas empresas de TI, pois percebeu-se
que a Qualidade de Software no um gasto e sim um investimento. E com a evoluo
constante da tecnologia, os clientes esto cada vez mais exigentes. Podemos at fazer
uma analogia com o mundo dos games: antigamente (10 anos atrs), The Legend of
Zelda: Ocarina of Time, lanado para o Nintendo 64, era o game. Hoje, ser voc der a
uma criana o cartucho (nada de DVD, muito menos Blu-Ray), ela provavelmente vai
achar os grficos toscos e ainda vai perguntar porqu, movendo o controle ela no
move o personagem.

Espero que vocs tenham gostado do primeiro tpico do blog QualidadeBR. Fiquem,
vontade para comentarem.


17
2. O Que Bug?
O uso do termo bug j antigo, dizem que ele foi criado por Thomas Edison quando um
inseto causou problemas de leitura em seu fongrafo em 1878.
O primeiro bug em computadores possivelmente ocorreu em 1947. Quando os
engenheiros que trabalhavam com o Harvard Mark I, o primeiro computador digital
automtico de larga escala desenvolvido nos EUA, encontraram uma traa entre seus
circuitos, que causou um erro nos clculos da mquina, prenderam-na no livro de
registro e rotularam-na como o primeiro bug encontrado, como vemos na figura 1.
Naquela poca, havia literalmente bugs, devido as propores gigantescas dos
computadores (figura 2), que serviram de abrigo para vrios insetos e at para ratos.
Situao essa, que em muitas vezes ocasionava problemas no sistema.

Figura 1 - (retirada do myoldmac)

Figura 2 - (retirada de IBM Archives)

18
Mas e hoje, em pleno sculo XXI por que os bugs ainda fazem parte das notcias de TI e
so to freqentes?
Errar humano.
Essa frase to prolixa o motivo da existncia dos bugs, afinal por mais experiente que
seja o programador, ele tambm humano (embora alguns duvidem) e passa por dias
ruins. No entanto, no no desenvolvimento que ocorre a maioria dos bugs, segundo
informaes do QAI (Quality Assurance Institute), 36% dos erros encontrados nos
softwares so provenientes da codificao, e os outros 64% so erros de desenho e
anlise.
Um exemplo dessa proporo o bug mais famoso do mundo, o bug do milnio. Quem
no se lembra do temor causado na passagem do ano de 1999 para 2000, devido ao
armazenamento de datas com apenas 2 dgitos para o ano, ficando os restantes
implicitamente entendidos como sendo 19. Desta forma cada data armazenada
deixava de ocupar oito bytes (dois para o dia, dois para o ms e quatro para o ano), e
passava a ocupar somente seis bytes (somente dois no ano). Assim, quando o calendrio
mudasse de 1999 para 2000 o computador iria entender que estava no ano de 19 +
00, ou seja, 1900.
E a deciso do uso de apenas 6 bytes, ocorreu devido a necessidade real de economia de
memria e espao de armazenamento. Hoje isso parece insignificante, mas na poca
isso foi o suficiente para justificar a adoo do padro, tamanho o custo das memrias e
dispositivos de armazenamento.
Para resolver o problema, velhos programadores de COBOL foram tirados da
aposentadoria, para voltar a trabalhar em sistemas muitas vezes desenvolvidos por eles
mesmos, vinte anos antes. Pagando-se a eles 1 dlar por linha revisada.
O bug do milnio foi um marco para a Qualidade e Teste de Software, no qual
percebeu-se o quanto uma falha pode custar caro e como at mesmo o risco de tal, pode
abalar empresas e levar a perda de dinheiro e credibilidade. Tirando como lio
aprendida a importncia do processo de testes, durante o desenvolvimento do software,
para que se possa minimizar a probabilidade e o impacto dos riscos e diminuir o nmero
de defeitos.

Fonte:
http://pt.wikipedia.org/wiki/Bug_do_mil%C3%AAnio
http://www.clubedohardware.com.br/artigos/492/3

19
3. Qualidades de um especialista em teste
Ser especialista em algo exige uma gama de competncias e virtudes. E para um
especialista em teste tambm no diferente. Cito abaixo algumas caractersticas
esperadas de um expert em teste:
o Postura pragmtica: O testador pragmtico realista e objetivo, as suas
decises so baseadas no seu conhecimento terico e prtico das tcnicas de
teste e nas ferramentas disponveis no mercado. Por outro lado, o testador
pragmtico no se limita somente aos aspectos tecnolgicos; em contrapartida, o
testador pragmtico um contador estrias, abordando os problemas por meio
de metforas e analogias compensando assim a falta de requerimentos formais.
o Flexvel: flexibilidade um pr-requisito para qualquer profissional de TI e na
atividade de testes exigido mais ainda, pois os requisitos mudam, os prazos
afunilam e o especialista em teste no pode ser a verso as mudanas e deve-se
adaptar com facilidade as novas realidades.
o Criativo: deve pensar em todas as situaes possveis de teste e at as que
aparentam ser impossveis.
o Crtico: colocar sempre em dvida aquilo que est em teste, no se contentar
com resultados aparentes, ter um olhar crtico.
o Realista: tomar decises baseadas em fatos.
o Incansvel: sempre interrogar e investigar a causa raiz dos problemas e a razo
das coisas. Testar a exausto o software, nunca acreditar que no h mais
defeitos.
o Assertivo: nunca pressupe ou se baseia em informaes contidas nas
entrelinhas, todas as suas suposies so aferidas a fim de garantir a sua
veracidade.
o Diplomata: foca os seus esforos nos problemas ao invs de focar nas pessoas
que os causaram. Deve saber se comunicar com o desenvolvedor, nunca
desprezar ou criticar negativamente o seu trabalho.
o Perfeccionista: Cada detalhe conta na execuo do seu trabalho, no entanto, no
troca um timo resultado por um resultado perfeito (e provavelmente
impossvel).
Uma ltima caracterstica de um especialista em teste ser um generalista. Isso mesmo,
o conhecimento sobre outros assuntos so fundamentais para todo profissional de TI. A
especializao algo bem-vindo sempre, mas o mercado de TI pede cada vez mais por
profissionais generalistas, aquelas pessoas quadradas em determinados assuntos j
no tem mais espao nas empresas de TI. E a atividade de teste exige muitas vezes
conhecimentos de linguagens de programao, redes, linux, banco de dados e at de
negcios. Por isso, alm do entendimento do processo de teste o especialista de teste
deve buscar est sempre atento as tendncias de mercado e buscar a atualizao
constante.

Fonte:

http://www.linhadecodigo.com.br/Artigo.aspx?id=1083&pag=1


20
4. Defeito, erro e falha. tudo igual?
Muitas pessoas pensam que defeito, erro e falha so sinnimos. Porm, na rea de
Qualidade de Software, cada uma dessas palavras possui uma definio:
Defeito: resultado de um erro encontrado num cdigo ou num documento;
Erro: engano cometido por seres humanos;
Falha: resultado ou manifestao de um ou mais defeitos.
Exemplo: A aplicao entra em looping infinito, devido a um erro de lgica,
ocasionando o travamento da mesma.
No exemplo acima citado, o defeito o looping infinito, que foi causado devido a um
erro de lgica do programador e a falha o travamento da aplicao.
Como podemos notar, o maior problema a falha, pois ela que afeta diretamente o
usurio. Alm disso, um defeito poder demorar vrios anos para ocasionar uma falha,
sendo que ele j estava presente na aplicao, desde a sua instalao.

Figura 3 - "Evoluo" do bug

Fonte:
Bastos, A.; Rios, E.; Cristalli, R. & Moreira, T. Base de conhecimento em teste de
software. So Paulo, Martins Fontes, 2007.


21
5. Teste Estrutural X Teste Funcional
Os testes de software so divididos em dois tipos:

Teste Estrutural: garantem que os softwares e os programas sejam estruturalmente
slidos e que funcionem no contexto tcnico onde sero instalados [1].

Teste Funcional: garantem o atendimento aos requisitos, ou seja, que os requisitos esto
corretamente codificados [1].

Cada tipo de teste traz consigo diversas tcnicas, sendo ela o processo que assegura o
funcionamento adequado de alguns aspectos do sistema ou da unidade. Abaixo cito
algumas destas tcnicas, de acordo com o tipo de teste:

Tcnicas de Teste Estrutural
o Testes de carga;
o Testes de conformidade;
o Testes de desempenho (performance);
o Testes de estresse;
o Testes de execuo;
o Testes de operao;
o Testes de recuperao (contingncia);
o Testes de segurana;
o Testes de sobrevivncia.

Tcnicas de Teste Funcional
o Teste de controle;
o Teste de interconexo;
o Testes paralelos;
o Testes de requisitos;
o Testes de regresso;
o Testes de suporte manual;
o Testes de tratamento de erros.

As tcnicas de Testes Estruturais buscam garantir que o produto seja estruturalmente
slido e que funcione corretamente, o foco dos testes averiguar o comportamento do
sistema em determinadas situaes. J as tcnicas de Testes Funcionais objetivam
garantir que os requisitos e as especificaes do sistema tenham sido atendidos, o foco
dos testes justamente a comparao do que foi planejado com o que foi produzido.

Em prximos artigos estarei detalhando cada uma das tcnicas de testes, citadas aqui.
At l!
Fonte:
Bastos, A.; Rios, E.; Cristalli, R. & Moreira, T. Base de conhecimento em teste de
software. So Paulo, Martins Fontes, 2007.


22
6. FURPS+
FURPS um sistema para a classificao de requisitos, o acrnimo representa
categorias que podem ser usadas na definio de requisitos, assim como representam
atributos de Qualidade de Software, sendo ele parte do Rational Unified Process (RUP):

Functionality (Funcionalidade) - representa todo aspecto funcional do software, ou seja
seus requisitos. uma atributo com diversas caractersticas que variam de acordo com a
aplicao. Seu objetivo averiguar se os requisitos foram cumpridos.

Usability (Usabilidade) - o atributo que avalia a interface com o usurio. Possui
diversas subcategorias, entre elas: preveno de erros; esttica e design; ajudas (Help) e
documentao; consistncia e padres.

Reliability (Confiabilidade) - refere-se a integridade, conformidade e interoperabilidade
do software. Os requisitos a serem considerados so: freqncia e gravidade de falha;
possibilidade de recuperao; possibilidade de previso; exatido; tempo mdio entre
falhas (MTBF).

Performance (Desempenho) - avalia os requisitos de desempenho do software. Podendo
usar como medida diversos aspectos, entre eles: tempo de resposta, consumo de
memria, utilizao da CPU, capacidade de carga e disponibilidade da aplicao.

Supportability (Suportabilidade) - os requisitos de suportabilidade agrupam vrias
caractersticas, como: testabilidade, adaptabilidade, manutenibilidade, compatibilidade,
configurabilidade, instalabilidade, escalabilidade, localizabilidade entre outros.

Figura 4 - FURPS

23
O + do acrnimo engloba requisitos no-funcionais que devem ser lembrados:
Requisitos de desenho - Um requisito de design, freqentemente chamado de
uma restrio de design, especifica ou restringe o design de um sistema.
Exemplos podem incluir: linguagens de programao, processo de software, uso
de ferramentas de desenvolvimento, biblioteca de classes, etc.
Requisitos de implementao - Um requisito de implementao especifica ou
restringe o cdigo ou a construo de um sistema. Como exemplos, podemos
citar:
o padres obrigatrios;
o linguagens de implementao;
o polticas de integridade de banco de dados;
o limites de recursos;
o ambientes operacionais.
Requisitos de interface - especifica ou restringe as funcionalidades inerentes a
interface do sistema com usurio.
Requisitos fsicos - especifica uma limitao fsica pelo hardware utilizado, por
exemplo: material, forma, tamanho ou peso. Podendo representar requisitos de
hardware, como as configuraes fsicas de rede obrigatrias.

Figura 5 - FURPS+ (retirada de Rational Library)
Fonte:
Rational Unified Process
Rational Library
Peter Eeles (Process Consultant for IBM Rational)

24
7. Ambientes de Teste Virtuais
Uma das fases do processo de teste a preparao, cujo principal objetivo a
montagem do ambiente de teste. O que necessita muitas vezes de novos investimentos
em infra-estrutura. Neste momento, a Virtualizao aparece como uma boa alternativa
para a criao de ambientes de testes virtuais.
A Virtualizao uma das tecnologias que mais se tem falado nos ltimos anos. Se
caracteriza pela capacidade de executar vrios sistemas operacionais em um nico
hardware, fazendo uso de mquinas virtuais.

E todo o barulho que se faz em torno da Virtualizao tem um motivo, os seus
benefcios:
Otimizao do hardware: para se ter uma idia, muitos Data Centers esto
rodando apenas 10% ou 15% da sua capacidade de processamento. Em outras
palavras, 85% ou 90% do poder da mquina no est sendo usado [1].
Economia de energia e espao fsico: um bom exemplo a IBM que
recentemente divulgou que trocar 4 mil servidores de pequeno porte por 30
mainframes Linux, rodando mquinas virtuais. Ou seja, o espao fsico
necessrio ser bem menor, portanto o gasto com a refrigerao e com o prprio
consumo de energia resultar em uma melhor eficincia energtica.
Facilidade de administrao: com a reduo no nmero de mquinas fsicas a
administrao delas ser facilitada, afinal muito mais fcil administrar 30
mainframes do que 4 mil servidores.
Como podemos perceber, a virtualizao do ambiente de teste uma alternativa
interessante, principalmente em projetos de curto prazo, devido a facilidade de
montagem e desmontagem de ambientes virtuais. E as ferramentas de Virtualizao
existentes atualmente no mercado, criam arquivos de imagem das mquinas virtuais,
ento caso uma aplicao tenha que ser retestada, a montagem do ambiente de
teste ser muito mais fcil e gil, j que precisamos apenas subir a mquina virtual.
A criao de ambientes virtuais s no recomendada para os testes de desempenho,
pois no trar resultados reais, caso a arquitetura do projeto no faa uso de mquinas
virtuais.
Uma mquina virtual (Virtual Machine VM) pode ser definida como uma
duplicata eficiente e isolada de uma mquina real (Popek and Goldberg).


25
No prximo artigo, iniciarei um tutorial sobre a construo de uma mquina virtual
Linux utilizando o VMware Server. At l!
Fonte:
[1] Golden, B; Scheffy, C. Virtualization For Dummies Sun and AMD Special Edition.
Indianapolis, Wiley Publishing, 2008.


26
8. Quando os testes devem parar?
Essa uma das perguntas mais difceis de ser respondida quando estamos testando um
software. Se formos perguntar para um gerente de teste, ele provavelmente vai
responder que os testes devero parar quando o prazo para eles se esgotar. Porm, nem
sempre esse momento certo para encerrar a etapa de testes, pois os testes podem ter
sido interrompidos muito antes do tempo necessrio para a sua completa cobertura.
Uma das maneiras de saber quando devemos d por encerrado a etapa de testes
verificar os seguintes pontos:
O nmero de bugs achados que esto fechados maior do que o nmero de bugs
que se esperava achar;
Todos os testes foram executados;
A porcentagem de cobertura da aplicao pelos testes j o suficiente;
Todas as funcionalidades funcionam corretamente;
O software tornou-se confivel;
A estabilidade alcanada atingiu o esperado;
O sistema atende as mtricas de confiabilidade, disponibilidade e durabilidade
definidas no Plano de Teste;
O nmero e severidade dos bugs caram a um nvel satisfatrio;
O tempo mdio entre defeitos encontrados muito alto.
Logicamente, trabalharmos sempre buscando 100% do software, mas para que isso seja
possvel, geralmente, o prazo para os testes dever ser muito alto, o que em muitos
projetos invivel. Assim sendo, uma outra maneira de saber o momento de finalizar os
testes avaliar os riscos envolvidos com a liberao da aplicao para a produo,
comparando tais riscos com os da no-liberao. Pois, podemos chegar num momento
em que o custo das falhas que possam vir a ocorrer no ambiente de produo no
compensa o gasto adicional de dinheiro para tentar evit-las.
Fonte:
Bastos, A.; Rios, E.; Cristalli, R. & Moreira, T. Base de conhecimento em teste de
software. So Paulo, Martins Fontes, 2007.
Farrell-Vinay, P. Manage Software Testing. New York, Auerbach Publications, 2008.


27
9. Testar X Debugar
Testar e debugar parecem sinnimos no dicionrio de TI e somente nele, pois o verbo
debugar no existe na lngua Portuguesa. Muitos diriam que testar e debugar a
mesma coisa. Mas na verdade no so, pois cada um tem uma proposta diferente:
Proposta de testar: mostrar que o programa tem bugs.
Proposta de debugar: achar a falha ou o erro que conduziu o programa a falhar
e planejar e executar as mudanas necessrias para a correo do erro.
Fazendo uma analogia com o mundo da Frmula 1: o piloto aps d algumas voltas no
circuito, retorna ao boxes e fala para o seu engenheiro que o carro est saindo muito de
traseira, o engenheiro solicita a equipe de mecnicos a investigao e concerto do
problema. Neste caso, o piloto testou o carro achou um problema e a equipe de
mecnicos ir debugar o carro em busca da causa e soluo do problema.
Debugar normalmente associado a testar, mas eles se diferem nos objetivos,
metodologias e o mais importante na psicologia:
O teste inicia com condies conhecidas, uso de procedimentos predefinidos e
tem resultados previstos; somente se o programa falhar que o teste ser
imprevisvel. J a debugao (debug) parte de circunstncias possivelmente
desconhecidas e o fim no pode ser previsto, exceto estatisticamente.
O teste pode e deve ser planejado, projetado e programado. J a maneira e o
tempo para debugar no podem ser to controlados;
Testar uma demonstrao de que o programa possui falhas ou aparentemente
no. Debugar um processo dedutivo;
Testar prova que o programador cometeu um erro. Debugar a oportunidade do
programador arrumar o erro cometido;
O teste algo previsvel, maante, rgido e s vezes at desumano. A debugao
demanda de intuio, experimentao e de liberdade;
Muitos testes podem ser feitos sem um conhecimento prvio do projeto.
impossvel debugar sem um conhecimento aprofundado do projeto;
Os testes podem ser feitos por outras empresas. A debugao deve ser feita na
prpria empresa desenvolvedora;
Apesar de haver uma slida teoria de teste, na qual estabelecido os limites
tericos para os testes, o que pode ser feito e o que no pode. A debugao
apenas recentemente vem sendo estudada por tericos, alcanando resultados
ainda rudimentares;

28
Muitos dos testes podem ser automatizados. Automatizar a debugao ainda
um sonho.
Fonte:
Beizer, B. Software Testing Techniques, Second Edition. Pennsylvania, The Coriolis
Group, 1990.


29
10. Carreira Teste de Software
A rea de Testes uma das que mais tem crescido, nos ltimos anos, para se ter idia
em mdia h umas 50 a 70 vagas da rea de Testes no Apinfo, site dedicado a vagas de
TI, tendo como base o estado de So Paulo.
Esse resultado d-se, devido a importncia da execuo dos testes, durante o ciclo de
desenvolvimento. Principalmente, com o boom das prticas de outsourcing e
de offshoring, que exigiu das empresas uma maior garantia da qualidade de seus
produtos.
Recentemente saiu uma lista dos empregos de TI prova de recesso, feita pela empresa
de recrutamento online JobFox, na qual se encontra na 12 posio os profissionais
especialistas em testes e controle de qualidade.
A carreira nesta rea geralmente respeita a seguinte hierarquia:
Tester (Testador) a posio de entrada na rea. O Tester responsvel pela
execuo dos testes, que em muitas vezes incluem as seguintes atividades: testar
configuraes de hardware e software, executar scripts simples de teste,
reproduzir e reportar bugs. Alguns trabalhos podem se tornar chatos e
repetitivos, mas com certeza o aprendizado obtido ser muito recompensador e
dar condies de galgar novas posies. nesta fase que o profissional poder
ir para o lado negro da fora (Desenvolvimento), caso seja notada habilidade e
vocao para a programao. No Desenvolvimento o Tester ser responsvel por
realizar os testes de Caixa Branca, principalmente os de nvel unitrio. E poder
preencher um gap existente na rea de programao, que a habilidade e
conhecimento em testes, podendo assim ser tornar um excelente e requisitado
programador.
Analista de Teste - o profissional responsvel pela modelagem e elaborao
dos casos de teste e pelos scripts de teste. Em algumas vezes, ele tambm o
responsvel pela execuo de testes mais especficos, por exemplo testes de
desempenho, estresse e homologao, nos quais exige um maior conhecimento e
maior responsabilidade. Este profissional tem bons conhecimentos em Anlise
de Sistemas, UML, modelos, normas, processos, banco de dados, ferramentas de
teste e principalmente tem pleno conhecimento do software que est sendo
testado.
Analista de Automao de Teste - o cargo mais recente da rea de Testes. O
Analista de Automao de Teste um profissional que tem como objetivo
principal, buscar a automatizao de testes, sempre que ela for possvel e vivel.
Utilizando para isso ferramentas, como por exemplo:
JMeter, Marathon, Selenium, SoapUI, WebLOAD, entre outras. O profissional
dever estar atento ao aparecimento de novas ferramentas, ter bons

30
conhecimentos de programao e buscar novas solues para a melhoria dos
testes. Ele necessita conhecer bem o processo de Teste e a realidade da empresa
para que possa automatizar os testes de acordo com a necessidade da empresa,
afinal a automatizao de testes no uma tarefa to simples e se feita de forma
equivocada poder trazer prejuzos ao invs de benefcios.
Arquiteto de Teste o responsvel pela montagem da infra-estrutura de teste,
monta o ambiente de teste, escolhe as ferramentas de teste e capacita a equipe
para executar seu trabalho nesse ambiente de teste. uma funo que exige um
bom conhecimento em redes, sistemas operacionais (Linux, Windows Server,
etc), servidores Web, banco de dados e principalmente conhecimento da infra-
estrutura do ambiente de produo, na qual o software que vai ser testado ser
futuramente instalado, para que o ambiente de teste seja o mais prximo do de
produo.
Lder de Teste - o profissional responsvel pela conduo dos testes e pela
equipe de Testes. Geralmente um profissional com alto grau de conhecimento
em ciclos de vida de testes, automao de testes, ambientes de testes e
documentao de testes. Ele ajuda o Gerente de Teste a elaborar os trs
relatrios bsicos para o acompanhamento do projeto: Relatrio de Status,
Relatrio de Progresso e Relatrio de Desempenho.
Gerente de Teste - o Gerente de Teste tem como funo primordial a iniciao
do projeto de teste a ser realizado no produto a ser testado. Suas qualificaes e
competncias se assemelham a um gerente de projetos tpico: elaborar o plano
do projeto de teste, aquisio de novos recursos, oramento, riscos, prazos,
elaborao de relatrios, limitaes do escopo do projeto de teste e outras
atividades gerenciais como constante comunicao com sua equipe, controle e
monitorao das atividades, gerao de mtricas para alimentar indicadores, etc.

31

Figura 6 - Hierarquia - rea de Testes

Os cargos e as tarefas dos cargos podem variar de empresa para empresa,
principalmente devido ao porte da empresa. E muito comum o acmulo de papis, por
exemplo: o Analista de Teste tambm ser responsvel pelas ferramentas de automao
de teste e da montagem do ambiente de teste.
A rea de Testes est a pleno vapor e os seus profissionais cada vez mais valorizados,
exemplo disso o surgimento de vrios cursos, certificaes e at MBA na rea. Que
mostram que o mercado est caa de profissionais qualificados.
Fonte:
Bastos, A.; Rios, E.; Cristalli, R. & Moreira, T. Base de conhecimento em teste de
software. So Paulo, Martins Fontes, 2007.
http://www.testexpert.com.br/?q=node/101
http://carreiradeti.com.br/carreira-areas-ti-tecnologia-prova-recessao/


32
11. Qualidade Sem Nome
Muitas vezes estamos buscando saber o que determinada coisa e no buscamos saber o
que ela deveria ser. Pela complexidade humana, encontramos uma distino nos
sistemas pela qual h sistemas que esto imersos na natureza e outros que no esto.
Pode parecer meio confuso, pois quando falamos em natureza, cada indivduo faz uma
associao diferente com a palavra natureza. Um sistema que est imerso na natureza,
seria um que possui poucas barreiras com o usurio, e com o qual o usurio tem uma
interface colaborativa, ou seja, que o comportamento do sistema possa reproduzir ou
emitir, em certo sentido, o comportamento normalmente esperado de um humano em
cooperao com o usurio.
Qualidade Sem Nome, ou Quality Without a Name (QWAN), foi definida pelo
arquiteto, matemtico e urbanista, Christopher Alexander, no seu livro The Timeless
Way of Building, como sendo:

Fugindo dessa definio filosfica, a qualidade central seria como o chassi de um carro:
ele que definir a qualidade do produto final (carro), no adianta ter um motor potente,
ou um bom piloto, se o chassi do carro foi mal projetado.
Alexander, ainda diz que a Qualidade no pode ser fabricada, mas sim gerada,
indiretamente, pelas aes das pessoas. Embora muitos ainda pensem que a Qualidade
esteja intrinsecamente ligada aos processos, metodologias ou ferramentas, quando na
verdade ela est diretamente ligada as pessoas e suas aes.
Aplicando a QWAN em TI, podemos associar ela ao real objetivo de algum programa,
ou seja, aos requisitos do projeto. E esses podem est errados, fazendo com que o
chassi da nossa aplicao fique totalmente prejudicado. Afinal, na maioria das vezes,
a falha est no planejamento do projeto e no no desenvolvimento.
E qual o motivo para esse fato?
A verdade que a Qualidade traduzida muitas vezes at a entrega final do produto, e
durante estas tradues podem ocorrer algumas das seguintes situaes:
O cliente no conseguiu traduzir corretamente o que ele realmente queria;
O gerente teve uma perspectiva diferente da vontade do cliente;
Uma qualidade central que a raiz da vida e esprito de um homem, uma
cidade, uma construo, da natureza. Tal qualidade precisa e objetiva, mas
no possui um nome.


33
Ao elaborar o escopo do projeto o gerente acabou incluindo alguns aspectos que
ele achou melhor colocar, pois pela sua experincia eles so essncias;
O design planejou toda a interface, seguindo o padro da empresa, no se
preocupando com as vontades do cliente.
O conceito de QWAN nos leva a uma revoluo, Alexander no apenas tentava achar
padres que explicassem a existncia da QWAN, mas tambm achar padres que gerem
objetos com essa qualidade.
QWAN proporciona uma conexo quase emocional com a estrutura projetada.
Proporciona queles que interagem com ele um sentimento de completude, de conforto,
de sentirem-se vivos. Os artefatos que a possuem so flexveis, extensveis, adaptveis,
reutilizveis, enfim, possuem qualidades que de um certo ponto de vista emulam vida.
Esta definio demasiada subjetiva para se adequar aos paradigmas atuais de
Engenharia de Software. O QWAN opera no nvel visceral de inteligncia humana e as
disciplinas da engenharia almejam o nvel comportamental.
Por fim, podemos entender que a QWAN nos fazem evidenciar que o produto dever
fornecer uma sensao imediata de compreenso e afetividade com o usurio. Por isso,
devemos colocar o usurio no centro do projeto e sempre estarmos nos perguntando e
comprovando se o sistema correto est sendo construdo. Buscando a criao de
estruturas que so boas para as pessoas e influem positivamente nelas, melhorando seu
conforto e qualidade de vida.
Fonte:
Christopher, A. The Timeless Way of Building, Oxford University Press, New York,
1979.
Valente, E. Padres de Interao e Usabilidade, UNICAMP, Campinas, 2004. (obtido
no site da Biblioteca Digital da UNICAMP)
Lehti, L.; Ruokonen, A. Foundation of the patterns. (obtido no link:
www.cs.tut.fi/~kk/webstuff/Foundationofpatterns.pdf)


34
12. Testes de sobrevivncia
Pessoal, h um tempo atrs publiquei um artigo sobre os tipos de testes, Teste Estrutural
(White Box) X Teste Funcional (Black Box), no qual disse que iria detalhar cada
tcnica de teste em futuros artigos. Pois bem, como dizem promessa divida e aqui
inicio falando sobre testes de sobrevivncia.
Segundo o livro Base de conhecimento em teste de software, os testes de sobrevivncia
avaliam a capacidade do software de continuar operando mesmo quando algum
elemento (software ou hardware) fica inoperante ou pra de funcionar. Ou seja, seria
uma verso do programa No Limite para o software, no qual iramos verificar o
comportamento do mesmo, em situaes atpicas. Por exemplo: queda de um dos
servidores utilizados, queda do banco de dados, etc.
Logicamente, no cobrado que a aplicao continue funcionando normalmente em tais
situaes, o que verificado o comportamento dela nessas situaes. A aplicao
dever est preparada para enfrentar esses desastres, por exemplo: uma aplicao
bancria ao perder conexo com o banco de dados, dever parar as suas execues
atuais e informar ao(s) usurio(s) do ocorrido e quando a conexo com a base de dados
for restabelecida ela dever d um rollback nas execues que foram paradas.
Outro objetivo dos testes de sobrevivncia conhecer os limites do software, para que
em produo evite-se submeter-lo a tais situaes. Podendo at esse limite tornar-se
uma restrio do software. Uma analogia pode ser feita com o elevador, no qual h uma
restrio quanto a quantidade de passageiros mximos ou peso mximo que o mesmo
pode transportar, pois foi realizado testes previamente, que revelaram que caso essa
restrio no seja respeitada o elevador corre risco de quebra.
Por fim, podemos concluir que os testes de sobrevivncias so essenciais para
aplicaes crticas, pois iro revelar os seus limites e ajudar a equipe a tomar decises
para prevenir tais situaes.
Fonte:
Bastos, A.; Rios, E.; Cristalli, R. & Moreira, T. Base de conhecimento em teste de
software. So Paulo, Martins Fontes, 2007.


35
13. Fuzz Testing
Um dos testes de Caixa Preta (Black Box) o Fuzz testing, cuja traduo seria algo
como teste aleatrio. uma tcnica que consiste basicamente na insero de
dados aleatrios na aplicao, com o objetivo de descobrir falhas no programa,
relacionadas com a insero/leitura de dados, e, assim, melhorar a confiabilidade do
software.
O procedimento de implantao do Fuzz testing composto por trs passos:
1. Preparar uma massa de dados de entrada para o seu programa;
2. Inserir a massa de dados no programa;
3. Verificar se ocorreu algum problema.
Para a preparao da massa de dados, geralmente utilizado algum script/programa
capaz de gerar dados aleatrios, sendo esses dados compostos muitas vezes por dados
ruins, ou seja, dados que muitas vezes no so esperados pela aplicao como, por
exemplo, caracteres especiais (@,$,%,,,,etc). A insero dessa massa de dados
tambm feita pelo script/programa, ou at pela prpria aplicao, por exemplo,
abrindo o arquivo da massa de dados.
O Fuzz testing tambm pode ser usado com o propsito de segurana, pois a sua
execuo pode encontrar negligncias e erros humanos, que colocariam a segurana da
aplicao em xeque. Podendo, simular problemas que causariam a quebra, como por
exemplo: buffer overflow, cross-site scripting (XSS para no confudir com CSS
Cascaded Style Sheet), ataques de negao de servio e injeo SQL.
Vantagens
As falhas que a tcnica de Fuzz testing pode encontrar so freqentemente de ordem
severa, podendo representar brechas de segurana que um hacker poderia explorar com
o intuito de invaso. Outra vantagem a contribuio para a robustez da aplicao que
dar maior confiabilidade a mesma, evitando assim futuros problemas em produo.
Desvantagens
A principal desvantagem que o Fuzz testing, geralmente s encontra falhas muito
simples. E sua eficcia varia bastante de acordo com a pessoa que est implementando o
teste, pois alm da criao do script/programa, ela que vai criar a massa de dados, ou
seja, a massa de dados ser o grande diferencial de um bom Fuzz testing para um mal.
Concluso
Fuzz testing uma tcnica que permite descobrir falhas que provavelmente no seriam
possveis de serem encontradas de forma manual. Por isso a necessidade da

36
automatizao do teste, por meio da criao de um script/programa. A sua execuo
aumenta a confiana e solidez da aplicao.
Essa tcnica ainda ajudar o programador a tomar futuramente as medidas preventivas
de acordo com as falhas encontradas. Algumas dessas medidas so descritas no artigo
do Elliotte Harold (vide fonte), para quem tiver interesse em conhec-las, o artigo
muito bom.
Fonte:
Harold E. Fuzz testing - Attack your programs before someone else does. IBM
Developer Works, 2006.
Fuzz testing Wikipedia


37
14. A Importncia da Usabilidade
Pessoal, estou realizando o meu TCC sobre Interface Homem-Mquina (IHC), cujo foco
principal a usabilidade. Um dos motivos de ter escolhido esse tema foi h falta de
preocupao das empresas e dos profissionais de TI com a usabilidade.
Um exemplo dessa despreocupao ocorre na prpria faculdade, cujos trabalhos que
envolvem o desenvolvimento de sistemas, muitas vezes no so avaliados tendo em
vista a usabilidade do sistema e o que importa mesmo a lgica e a utilizao de
conceitos aprendidos em sala de aula. Logicamente, que esses quesitos so de suma
importncia, principalmente em uma faculdade, porm e a usabilidade? Ela no deveria
ter uma importncia, ou vamos continuar com o pensamento arcaico que usabilidade
perfumaria?
Introduo
H duas definies principais para usabilidade:

A primeira definio a mais formal feita pela International Organization for
Standardization (ISO), j a segunda feita pelo especialista em usabilidade Jakob
Nielsen. Ambas tem o usurio como base, ou seja, a usabilidade est intrinsecamente
ligada ao usurio, portanto todo esforo da usabilidade tem como objetivo tornar a
aplicao mais usual e fazer com que o usurio tenha prazer na sua utilizao.
A importncia da usabilidade
Para explicar a importncia da usabilidade, vamos usar o exemplo da evoluo do
celular: no incio do milnio a maioria dos celulares, para no falar todos, tinham a
navegao puramente textual e basicamente serviram para mandar mensagens,
fazer/receber ligaes, agenda e ainda continham alguns joguinhos. Voc conseguia
fazer uso dessas funcionalidades sem nenhuma dificuldade por meio dessa interface
textual. Mas imagine hoje, se os novos celulares, ainda fizessem uso da interface por
texto, seria impraticvel fazer uso das dezenas de funcionalidades existentes nos
a extenso na qual um produto pode ser usado por usurios especficos para
alcanar objetivos especficos com efetividade, eficincia e satisfao em um
contexto de uso especfico. (ISO 9241-11)

Usabilidade est relacionada ao aprendizado, eficincia, na realizao da
tarefa de memorizao, minimizao de erros e satisfao subjetiva do
usurio. (Nielsen, J.)


38
celulares atuais, por isso a interface tambm teve que evoluir e hoje observamos um
padro, que basicamente o de uso de cones e menus.
O celular, assim como a internet, so as duas tecnologias que mais tem sofrido
evolues, quanto a usabilidade. E a razo para isso simples, um grande nmero de
pessoas fazem uso delas, portanto as interfaces tem que serem projetadas, tendo em
mente que pessoas com diferentes graus de instrues tero que ser capazes de usar tais
tecnologias.
Logo percebemos a importncia da usabilidade, que de fornecer uma interface o mais
prxima do usurio e por meio dela que as barreiras entre o software e o usurio vo
diminuindo.
Outro aspecto interessante, que a usabilidade pode ser o fator decisivo pela
adoo/compra de um produto. Um exemplo disso ocorreu na empresa que trabalho.
Estvamos em busca de uma ferramenta de gerenciamento de testes, ficando entre dois
softwares o Bugzilla e o JTester Manager (ferramenta desenvolvida pela prpria
empresa), o Bugzilla ganhava em nmero de funcionalidades, porm tinha um grande
problema, a usabilidade: fluxo no era linear, continha muitos campos em uma mesma
tela, etc. Enquanto o JTester Manager continha as funcionalidades essenciais e uma
tima usabilidade, devido principalmente a sua simplicidade. A deciso ento foi fazer
uso do JTester Manager, pois percebemos que a produtividade com o JTester Manager
seria bem maior do que com o Bugzilla.
Concluso
A usabilidade deve ser encarada com seriedade e ser focada no usurio, afinal ser ele
que far o uso do software. E caso no comearmos a nos preocupar com a usabilidade,
os usurios dos nossos sistemas podem ter um acesso de fria, assim como esse senhor
teve no vdeo abaixo:

Alis, quantas vezes voc mesmo(a) j no se irritou por no ter conseguido realizar
alguma tarefa, devido a falta de usabilidade do software?


39
Fonte:
Nielsen, J. (1993), Usability Engineering. Academic Press, Inc., San Diego.


40
15. Qualidade de Software Processo ou Projeto?
Essa uma daquelas perguntas que muitos responderiam comeando com Veja bem e
como j diria um amigo meu, quando voc inicia uma resposta com Veja bem voc
provavelmente ir enrolar, o popular encher lingia.
Antes de responder a essa pergunta precisamos, definir e diferenciar projeto
de processo:

Pela prpria definio j conseguimos notar a diferencia principal entre projeto e
processo, que a durao de cada um. O projeto tem incio, meio e fim, j o processo
contnuo. Para exemplificar essa diferena, vou usar dois exemplos:
O casamento um projeto, ele tem incio com os requisitos (igreja, tipo de
comemorao, lua-de-mel, etc), meio com a elaborao do projeto (tempo, pessoas
envolvidas, etc) e com a execuo (convite dos convidados, aluguel do local da festa) e
por fim o casamento em si.
A vida de casal seria (ou deveria ser) um processo, pois contnua, j possui
procedimentos (ex. almoo na casa da sogra no domingo) e artefatos (ex. o prprio
almoo na casa da sogra) estabelecidos.
Qualidade de Software como processo
A Qualidade de Software vista como processo, quando ela j tem um processo
definido, regular e previsvel, todo input (entrada) feito para a Qualidade de Software
respeitar esse processo. Um exemplo seria a rea de Qualidade de uma fbrica de
Software, cujos softwares desenvolvidos passam pela Qualidade seguindo o processo
dessa rea. Ou seja, o processo ser sempre reusado, o mximo que haver ser
customizaes e melhorias.



Um conjunto de atividades, mtodos, prticas e tecnologias que as pessoas
utilizam para desenvolver e manter software e produtos relacionados. (CMM)

Um projeto um esforo temporrio empreendido para criar um produto,
servio ou resultado exclusivo. (PMBOK)


41
Qualidade de Software como projeto
Um grande projeto ser desenvolvido pela empresa XPTO e ser necessrio o
envolvimento da equipe de Qualidade atual da empresa e a contratao de novos
funcionrios. A equipe de Qualidade notou que o seu processo no est adequado para a
magnitude do projeto, portanto ele ter que sofrer grandes modificaes.
No caso citado acima, a Qualidade de Software ser um subprojeto do projeto,
portanto ele pode ser classificado como projeto de Qualidade de Software, afinal os
esforos a serem dedicados sero temporrios (o perodo do projeto). Haver
necessidades de renovao, mudana, criao e inovao, e o fluxo estabelecido poder
ser vlido s para aquele projeto, e muitas vezes ele no ser reusado em sua integridade
em outros projetos, portanto ele se torna singular.
Concluso
A viso de Qualidade de Software muitas vezes confundida entre projeto e processo,
ambos podem ser associados a Qualidade de Software. O diferencial para ela ser um
processo ou um projeto ser a maneira que ela implantada na empresa. O importante
definir as atividades, mtodos, prticas e tecnologias, pois so eles os componentes
tanto de um processo quanto de um projeto.


42
16. Mercado atual Teste e Qualidade de Software
Pessoal, dando uma passada no blog do GUTS encontrei uma interessante apresentao
do Fernando Scarazzatto com o seguinte ttulo O Panorama do Mercado de TI e da
Profisso de Testador de Software no Brasil. Um dos assuntos abordados pelo
Fernando na apresentao a situao atual do mercado de TI, tendo em vista a rea de
Testes e Qualidade. Abaixo, comento sobre cada um dos itens citados nesta parte da
apresentao:
Carncia de profissionais especializados em testes de software esse um fato
comum em diversas reas de TI, por mais que parea estranho em um pas como
o Brasil. E na rea de teste de software ainda mais comum, pois a maioria das
faculdades e universidades ensinam como programar, mas no como testar.
Alm disso, muitas pessoas ainda desconhecem a rea de Testes de Software.
Carncia de ambientes estruturados para a execuo dos testes uma
caracterstica notvel, principalmente em empresas que recentemente
implantaram o processo de Teste de Software. O jeitinho brasileiro faz com
que os profissionais realizem testes em ambientes bem diferentes do de
produo, o que pode acarretar na descoberta de diversas falhas somente em
produo.
Cobertura de testes insuficientes em relao as funcionalidades e adequao
aos requisitos em algumas empresas a etapa de testes pensada somente no
momento do desenvolvimento, quando no somente no final. O correto seria ela
j se planejada e esperada na elaborao dos requisitos, pois muitos requisitos e
funcionalidades acabam tendo um baixo valor de testabilidade, dificultando e at
impossibilitando a realizao do teste.
Alto ndice de no atendimento aos requisitos quando perguntamos a um tester
se o que ele testou est de acordo com o requisito, ele poder nos surpreender
com a seguinte resposta Que requisito?. Tal fato no difcil de ser observado,
pois os requisitos so traduzidos muitas vezes durante o desenvolvimento de
um software. Por exemplo, o critrio de aceitao de um teste poder estar
totalmente diferente do requisito de uma determinada funcionalidade.
Informalidade do processo de testes (em geral executados pelos prprios
desenvolvedores) quando no h um processo de teste bem definido, o risco
dos testes serem executados de maneira informal grande, principalmente
quando executados pelos prprios desenvolvedores, j que esses, geralmente,
no possuem um conhecimento sobre o processo de teste.
Baixa relevncia atribuda ao processo de testes as empresas ainda tem
percepes arcaicas do processo de teste, achando que ele ir apenas gerar mais

43
custo e gastar tempo. Quando na verdade, ele fundamental no processo do
desenvolvimento e implicar no aumento da qualidade do produto final.
Necessidade de abordagem de teste diferenciada para novas tecnologias
novas tecnologias esto sempre surgindo e com ela novas abordagens de testes
se fazem necessrias. Desta maneira, a Engenharia de Software est sempre em
constante evoluo e melhoria, e a rea de Testes que um dos ramos da
Engenharia de Software tambm se v necessitada de novos processos, mtodos
e artefatos.
Fonte:
O Panorama do Mercado de TI e da Profisso de Testador de Software no Brasil
Fernando Scarazzatto


44
17. Tcnicas de Integrao de Sistema
Incremental
Ao realizar os testes de integrao uma dvida que pode surgir a de como combinar os
mdulos do software. Existem 5 abordagens diferentes para realizar a juno dos
mdulos, a fim de obter a montagem de todo o sistema:
Incremental
Top down
Bottom up
Sandwich
Big bang
Neste post, irei falar sobre a abordagem Incremental, que como o prprio nome sugere
ocorre aos poucos, mdulo a mdulo.
A interao ocorre atravs de uma srie de ciclos de teste. Em cada ciclo de teste, os
mdulos vo se integrando com os j existentes e testados para gerar maiores mdulos.
A idia concluir um ciclo de testes, os desenvolvedores corrigirem todos os erros
encontrados, e continuar o prximo ciclo de testes. O sistema completo construdo
incrementalmente, ciclo por ciclo, at que o sistema esteja operacional e pronto para a
realizao dos testes de nvel de sistema.
Uma aplicao da abordagem Incremental ocorre frequentemente na fabricao de
bolos: a confeiteira degusta a massa do bolo antes de coloc-la no forno, e antes de
colocar a cobertura ela verifica a sua consistncia e sabor.
A seguir veremos as vantagens e desvantagens do uso da abordagem Incremental na
realizao dos testes de integrao, sendo interessante notar que boa parte das vantagens
e desvantagens apresentadas, tambm ocorre no desenvolvimento incremental.
Vantagens
O tester no precisa esperar at que todo o sistema esteja pronto, para iniciar os
testes;
H um menor risco de fracasso geral do projeto, j que cada mdulo verificado
antes e caso algo esteja errado a correo ser implementada j no prximo ciclo
de teste;
A integrao dos mdulos s realizada, aps eles j terem sido verificados, ou
seja, se algum erro acontecer a causa, provavelmente, ser a comunicao entre
esses mdulos.

45
Desvantagens
A modulao pode ser uma tarefa difcil de ser realizada, pois os mdulos
necessitam ser pequenos, mas com alguma funcionalidade completa;
Em determinadas situaes, a realizao do teste s poder ser feita com a
utilizao de Mock Object.
Consideraes Finais
Na utilizao da abordagem Incremental para a realizao dos testes de integrao,
alguns aspectos devem ser considerados, tendo em vista o nmero de ciclos de testes:
O nmero de mdulos do sistema;
A complexidade dos mdulos;
A complexidade da interface entre os mdulos;
O nmero de mdulos a serem usados para o agrupamento em cada ciclo de
teste;
Verificar se os mdulos a serem integrados foram devidamente testados antes;
O tempo de resposta da equipe de desenvolvimento em cada ciclo de teste.
Por hoje s pessoal. Em breve comentarei sobre a tcnica Top-down, que uma
tcnica de fazer a integrao de forma incremental. At l!
Fonte:
NAIK, Kshirasagar; TRIPATHY, Priyadarshi. Software Testing and Quality
Assurance. Hoboken (New Jersey): John Wiley & Sons, Inc., 2008.
alisson.brito.googlepages.com/ProcessoDeSoftware_AlissonBrito.ppt


46
18. Tcnicas de Integrao de Sistema Top Down
A Top Down, que em traduo literal seria algo como de cima para baixo, uma das
tcnicas mais conhecidas para teste de Integrao usando a abordagem incremental.
Como se pode perceber pelo prprio nome, usando a tcnica Top-down, o teste comea
do nvel mais alto para o mais baixo, ou seja, os componentes de mais alto nvel so
integrados primeiro.
Para entender melhor, vamos pensar no exemplo abaixo:

Figura 7 - Exemplo Top Down

Como pode ser percebido, o sistema nesse exemplo, o lbum de msica, que
formado por vrias msicas, que sero chamadas de componentes. Por fim, uma msica
formada pela juno de vrios instrumentos, que sero chamados de mdulos.

47
Pela tcnica Top-down iremos primeiro testar os componentes de alto nvel, que so as
msicas, s para depois verificar cada mdulo (instrumento) de cada componente
(msica).
Algo importante de se notar, que no final do Teste de Integrao teremos a integrao
dos mdulos testados e no o sistema como um tudo. Na analogia apresentada, teramos
cada msica verificada e no o lbum inteiro. O teste que verificaria o lbum inteiro
seria o Teste de Sistema.
Vantagens
Permite verificao antecipada de comportamento de alto nvel;
Mdulos podem ser adicionados, um por vez, em cada passo, se desejado;
Permiti a busca em profundidade (depth-first search) e a busca em
largura(breadth-first search).
Desvantagens
Retarda verificao de comportamento de baixo nvel;
Entradas de casos de teste podem ser difceis de formular, por geralmente,
demandar de uma entrada maior de informaes;
Sadas de casos de teste podem ser difceis de interpretar, cada passo executado,
pode gerar um resultado e o Tester dever ficar atento a esses resultados, pois
essas sadas intermedirias pode apresentar alguma inconsistncia.
Bem, hoje vimos como que a tcnica Top-down funciona na realizao dos Testes de
Integrao, espero ter ajudado na compreenso dessa tcnica, caso tenha ficado alguma
dvida, sinta-se vontade em coloc-la nos comentrios. At a prxima!
Fonte:
Teste de Integrao, Sistema e Aceitao, Alexandre Mota. (link)


48
19. Por que testar?
Apresentao disponibilizada no SlideShare.


49
20. A Importncia do Teste de Software
Apresentao disponibilizada no SlideShare.


50
21. Interface Homem-Mquina: Melhores Prticas
de Usabilidade

Finalmente, entreguei o TCC com as correes finais!
Na verdade j faz um tempinho (quase um ms), e estava quase me esquecendo de
disponibilizar para vocs caros leitores do QualidadeBR. O link para download, segue
abaixo:
http://www.mediafire.com/?dn4zodmw5zj (4,5MB)
No comeo da monografia, trocamos vrias vezes de tema, para ter uma idia, a nossa
primeira escolha foi Sistemas em Tempo Real, depois cogitamos mudar para Interfaces
(que iria envolver at realidade aumentada) e decidimos por fim fazer sobre
Virtualizao.
Aps j est pesquisando sobre Virtualizao, a minha dupla, o Jayson, me perguntou
mais ou menos assim:
- Fabrcio, o que voc acha de fazer sobre usabilidade?
- hmmmusabilidade, ser que isso rende uma monografia? Acho que o assunto meio
limitado
A partir da, buscamos obter mais informaes sobre usabilidade, perguntando para
vrios professores nossos, e at com outros de fora, como o Samuka Ribeiro, que d
aula sobre Interface Homem-Mquina, e que ajudou com um rico material sobre o
assunto.
Acabamos percebendo que usabilidade podia sim, render uma boa monografia. E a
partir da, pude perceber que, a usabilidade no se resume a ser apenas uma
caracterstica de Qualidade de Software, e que h vrios estudos e aspectos que devem
ser levados em conta, durante o desenvolvimento de software.
Para mim, um dos maiores estmulos para escolher esse tema, foi o fato de muitas
pessoas, boa parte formada de desenvolvedores e profissionais de TI, acharem que a
interface de um software um mero detalhe, alis, eu at falei sobre a importncia da
usabilidade nesse post.
Eu at entendo, que para ns profissionais de TI, a interface algo que no tem tanta
importncia, afinal de contas, estamos acostumados a usar at prompts de comando e
terminais. Mas pense bem, a maioria dos usurios de computadores no formada por
profissionais de TI. E fique sabendo, que at na poca em que a interface de texto era
predominante, j haviam pessoas preocupadas com a usabilidade dos sistemas.

51
Mais uma revelao, se prepare, essa pode at te surpreender. Por que voc acha que os
usurios ligam tanto para o suporte da sua empresa, muitas vezes com dvidas que nem
so sobre o seu sistema?
1. Porque eles so usurios
2. Porque eles so pessoas carentes e gostam de ouvir uma voz amiga
3. Porque o sistema, realmente no est funcionando
4. Porque eles esto perdidos e nem saber como interagir com o seu sistema
5. Pode ser qualquer resposta citada acima
E a resposta correta a 5 (hehe), pois depende da circunstncia. Mas a alternativa 4
uma que acontece bastante, devido a falta de usabilidade, que necessita ser uma das
caractersticas de Qualidade de Software prioritrias. Principalmente se o sistema a ser
desenvolvido tiver como pblico alvo, os usurios comuns. Afinal de contas, at ns
profissionais de TI, s vezes, nos deparamos com uma interface ruim e ficamos
perdidos.
P.S.: Quem se interessar pelo assunto, e for d uma olhada na monografia, fique
vontade para comentar sobre ela. E se voc for fazer algum trabalho sobre
usabilidade/interface homem-mquina, eu tenho bastante material sobre o assunto e
posso enviar.


52
22. Tcnicas de modelagem de teste (parte 1)
Durante os estudos para a CTFL-BSTQB, utilizando o Syllabus. Notei que h um tpico
que ele no aborda com muito detalhes, ou melhor, com quase nenhum detalhe, o tpico
sobre as tcnicas de modelagem de teste.
Esse, alis, um dos tpicos mais importantes, pois em todos os simulados que fiz, h
pelo menos uma questo sobre o assunto. E geralmente, essas questes fazem parte das
5 de nvel difcil/muito difcil (mais detalhes sobre o exame aqui). Alm do mais, tais
tcnicas so muito utilizadas no dia-a-dia do teste de software, muitas vezes, por
exemplo, usamos a tcnica de partio de equivalncia sem saber que estamos.
Resolvi ento, fazer uma apresentao sobre o assunto, colocando os conceitos
principais de cada tcnica, exemplos e questes de simulados. Tendo como referncia
principal, o livro Foundations of Software Testing ISTQB Certification, que umas
das bibliografias recomendadas para a CTFL.
Disponibilizo abaixo a apresentao que fiz sobre as tcnicas de teste, sendo essa a
primeira parte, que abrange as tcnicas baseadas em especificao: Partio de
Equivalncia; Anlise do Valor Limite; Tabela de Deciso; Teste de transio de
estados; Teste de Caso de Uso.
Espero que possa servir de ajuda e complemento aos estudos tanto para a certificao,
quanto para a rea de Teste de Software.
Apresentao disponibilizada no SlideShare.


53
23. Tcnicas de modelagem de teste (parte 2)

Na segunda e ltima parte da apresentao sobre tcnicas de modelagem de testes, so
apresentadas as seguintes tcnicas:
Baseadas em estrutura
o Teste e Cobertura de Comandos
o Teste e Cobertura de Deciso
o Cobertura de desvio
o LCSAJ (Linear Code Sequence and Jump Seqncia de Cdigo Linear
e Salto)
o Cobertura de Caminho
Baseadas em experincia
o Suposio de erro
o Teste exploratrio
Apresentao disponibilizada no SlideShare.




54
Segundo o ISTQB Foundation Exam format and question writing guidelines, 29% das
questes do exame so sobre o captulo 4, resultando em 12 questes.
Sabendo disso, resolvi preparar um simulado especial para esse captulo, contendo 20
questes. Segue abaixo o link para download:
http://www.mediafire.com/file/imli0jjmeij/6.Simulado_CTFL-BSTQB (especial
captulo 4).pdf
Quem no tiver os demais simulados publicados num post anterior, pode baix-los pelo
link abaixo (no arquivo tambm est esse do captulo 4):
http://www.mediafire.com/file/ohy4jdwxijw/Simulados_CTFL-BSTQB.zip
Espero que as apresentaes, assim como os simulados, possam ajudar quem estiver se
preparando para a prova.
Bons estudos e boa sorte a todos!


55
24. Excelncia
Acabei de terminar o livro A Cabea de Steve Jobs e em tempo recorde, menos de
uma semana (geralmente eu levo muito mais do que uma semana para ler um livro).
E a voc pode est pensando: L vem o Fabrcio avacalhar e falar sobre algo que no
tem a ver com o foco do blog. Ou ainda, se voc me conhecer melhor, poder pensar:
Putz, l vem ele idolatrar o Steve Jobs, aquele cara que s faz coisas bonitinhas e
carinhas.
Bem, nem vou avacalhar e tambm no vou idolatrar o Steve Jobs, afinal nem preciso o
cara bom ponto final.
E sim comentar sobre a frase abaixo, que est no incio de um dos captulos do livro, e
tem a ver com a rea de Teste e Qualidade de Software:
Seja um padro de qualidade. Algumas pessoas no esto costumadas a um ambiente
onde se espera excelncia. (Steve Jobs)
Ser um padro de qualidade parecer se algo bem forte, neh? Principalmente se for
para uma pessoa ser um padro de qualidade, assim como o Steve Jobs na Apple.
Afinal, felizmente ou infelizmente no encontramos um Steve Jobs entre os candidatos
para uma vaga na nossa empresa.
Acredito que para a nossa realidade, a rea de Teste e Qualidade de Software deve ser
um padro de qualidade para a empresa, e mais precisamente para o projeto na qual est
participando.
E esse padro de qualidade no pode ser qualquer um, tem que ser o mais alto possvel.
Se isso parece abstrato, pense que ns precisamos ser mais exigentes do que o nosso
cliente mais exigente. J que bem melhor a gente reportar uma falha para a equipe de
desenvolvimento, do que o cliente reportar tal falha.
E outro ponto importante, que, alis, retrata muito bem o nvel da maioria das empresas
de TI no Brasil, a falta de costume das pessoas em fazer o seu trabalho com
excelncia, e quando eu digo excelncia no fazer tudo certo de uma vez, o que algo
que eu particularmente, acho impossvel. E sim est sempre se aperfeioando e
transformar o seu produto no melhor de todos.
E neste segundo ponto a equipe de Teste e Qualidade de Sistema tem um papel super
importante, o de est sempre verificando e validando se o processo e produto esto
realmente no nvel que se espera deles.
Muitos podem pensar que perfeccionismo, quando na verdade estamos buscando a
excelncia. E h uma grande diferente em o que perfeito e o que est excelente, o
primeiro nunca pode ser alcanado, j o segundo pode.

56
Mas agora vou te confessar uma coisa querido(a) leitor(a) se fosse achar que isso
difcil de ser aplicado, voc tem toda a razo. Eu tenho muito que melhorar, pois j teve
situaes em que algo no estava to bem feito, mas que funcionava. O famoso:
- T funcionando?
- Sim.
- Ento blz!
E o mais importante na minha opinio, saber dosar entre a excelncia e a sua
realidade, mas com o cuidado de no se acomodar e fazer da sua realidade uma desculpa
para no melhorar.
P.S.: Se algum que saber se eu recomendo o livro claro que sim uma excelente
fonte de conhecimento sobre um dos gnios contemporneos, Steve Jobs.


57
25. Coberturas
100% de cobertura de comando cobre 100% de cobertura de desvio? Ou o contrrio?
100% de cobertura de caminho garante 100% de cobertura de LCSAJ?
Se algumas dessas perguntas j passaram pela sua cabea, garanto que no foi somente
pela sua. Pela minha e de vrias outras pessoas tambm.
Ento o que voc acha de solucionar de uma vez todas as dvidas quanto as coberturas?
Se t brincando, Fabrcio?
Sei, sei e eu tambm vou te mostrar um esquema para acertar todos os nmeros da
loteria
Que isso pessoal, verdade. Eu agarantiu!!!

Figura 8 - Seu Creysson

Eu criei uma representao grfica de qual cobertura cobre qual, baseada em uma outra
que a leitora Renata Eliza (muito obrigado!) me enviou:

58

Figura 9 - Coberturas

Ficou mais fcil no ficou?
Mas se mesmo assim restaram dvidas, segue abaixo a listagem de quais coberturas
cobrem quais, baseado no material da certificao CTFL, cedido pela BSTQB:
1. 100% da cobertura de deciso ou desvio garante 100% da cobertura de
comando, mas no vice-versa;
2. 100% de cobertura de deciso implica em 100% de cobertura de desvio, e vice-
versa;
3. 100% de cobertura LCSAJ implica em 100% de cobertura de deciso;
4. 100% de cobertura de caminho implica em 100% de cobertura LCSAJ.
E isso a pessoal. Espero que eu tenha ajudado.
Fonte:
ISTQB Glossrio de Termos de Teste (Verso 1.3 Portugus/Brasil);
Syllabus Foundation Level (em Portugus/Brasil).


59
26. Tcnicas de Integrao de Sistema Bottom
Up
Continuando a srie de posts sobre as tcnicas de integrao de sistema, alis, preciso
parar de comear e no terminar essas sries de posts (a das resolues de questes da
CTFL terminou, pelo menos por enquanto ).
No ltimo post sobre tcnicas de integrao de sistema, tnhamos comentado sobre a
Top-down. Agora irei falar sobre a inversa da Top-down a Botton-up.
Na tcnica Botton-up, a integrao do sistema comea com a partir do nvel mais baixo
do software, ou seja, o mdulo. O mdulo dito como o mais baixo nvel se ele no
depende de outro mdulo. A Bottom-Up assume que todos os mdulos foram
individualmente testados antes.
Para integrar um conjunto de mdulos usando a Bottom-Up, ns precisamos construir
driver (controlador) que chamar o mdulo a ser integrado. Uma vez que a integrao
de um grupo de baixo nvel de mdulos tenha sido considera satisfatria, o driver ir
substituir o atual mdulo e um ou mais drivers sero usados para integrar mais mdulos
com um conjunto de mdulos j integrados. O processo de integrao Botton-Up
continua at todos os mdulos terem sido integrados.
Segue abaixo um exemplo de uma integrao usando a tcnica Botton-up:

Figura 10 - Integrao Bottom-up dos mdulos E, F, e G

60

Figura 11 - Integrao Bottom-up dos mdulos B, C, e D com o E, F, e G.


Figura 12 - Integrao Bottom-up do mdulo A com todos os outros.

As vantagens da tcnica Botton-up so:
Permite verificao antecipada de comportamento de baixo nvel;
Stubs no so necessrios;
Mais fcil para formular dados de entrada para algumas sub-rvores;
Mais fcil para interpretar dados de sada para outras sub-rvores.
As desvantagens da tcnica Botton-up so:
Os testadores no podem visualizar as funes em nvel de sistema a partir de
uma parte do sistema j integrada. Alis, eles no podem visualizar as funes
em nvel de sistema at o ltimo driver ser colocado;

61
Geralmente, as decises principais esto incorporadas nos mdulos de alto nvel.
Desta maneira as principais falhas do sistema no podem ser encontradas at que
os mdulos de alto nvel estejam integrados. Logo a verificao de
comportamento de alto nvel retardada.
Aps ter visto a tcnica Botton-up e a Top-down (aqui), podemos comparar as duas:
Validao das principais decises: Os mdulos de alto nvel contm as
principais decises. As falhas na modelagem dessas decises so detectadas
antecipadamente, se a integrao realizada a Top-down. Na tcnica Botton-up,
essas falhas so detectadas no final do processo de integrao;
Dificuldade em elaborar os casos de teste: na abtcnica Top-down, como mais
e mais mdulos so integrados e stubs so utilizados mais distantes do mdulo
de alto nvel, torna-se cada vez mais difcil a elaborao do comportamento do
stub e a entrada do teste. No entanto, na tcnica Botton-up, um comportamento
elaborado para um driver, atravs da simplificao de um comportamento de real
do mdulo;
Reusabilidade de casos de teste: usando a tcnica Top-down os casos de teste
so elaborados para testar a interface de um novo mdulo e pode ser reusado
para fazer testes de regresso nas prximas iteraes. E futuramente os casos de
teste podem ser reusados para o teste de nvel de sistema. No entanto, usando a
tcnica Botton-up, todos os casos de testes incorporados aos drivers, exceto o
driver para o teste alto nvel, no podem ser reusados.
Fonte:
NAIK, Kshirasagar; TRIPATHY, Priyadarshi. Software Testing and Quality
Assurance. Hoboken (New Jersey): John Wiley & Sons, Inc., 2008.
Teste de Integrao, Sistema e Aceitao, Alexandre Mota. (link)


62
27. Tcnicas de Integrao de Sistema Big Bang
e Sandwich
Para finalizar a srie de posts sobre tcnicas de integrao de sistema, irei abordar a
tcnica Big-bang e a Sandwich.
Big-Bang

Figura 13 - Big Bang
Na tcnica Big-bang, os mdulos so testados isoladamente e depois integrados de uma
s vez, como pode ser visto na figura abaixo.

63

Figura 14 - Ilustrao do uso da tcnica Big - bang
Para executar uma integrao usando a tcnica Big-bang necessitamos de stubs e drives
para testar os mdulos isoladamente.
Ela normalmente usada devido s presses do dia a dia e os testes so aplicados para
demonstrar uma operabilidade mnima do sistema.
O maior problema do uso da tcnica Big-bang caso haja alguma falha na interface de
um mdulo com outro, pois neste caso, ser difcil ser preciso e encontrar a causa da
falha. J que ela uma tcnica que usa uma abordagem no incremental.
Vantagens
Conveniente para sistemas pequenos
Desvantagens
Necessita de drivers e stubs para cada mdulo;
S permite o teste em paralelo no incio dos testes;
Localizao difcil da falha;
Fcil perder falhas de interface.

64
Sandwich

Figura 15 - Sanduche de Mortadela do Bar do Man no Mercado SP
Na tcnica Sandwich, um sistema integrado misturando a tcnica Top-down com a
Botton-up, dividindo o sistema em trs camadas:
Lgica camada que contm os mdulos que so mais frequentemente
chamados. Esta camada testada utilizando a tcnica Bottom-up;
Meio (middle) so os restantes dos mdulos;
Operacional- camada que contm os mdulos principais, do ponto de vista
operacional. Sendo testada utilizando a tcnica Top-down.
Muitas vezes uma abordagem combinada Top-down para os nveis superiores e Botton-
up para os nveis inferiores pode ser o melhor ajuste para o teste de integrao da sua
aplicao. Se os nveis superiores da estrutura do programa forem integrados de cima
para baixo, o nmero de drivers pode ser reduzido substancialmente na integrao dos
mdulos inferiores. Agora se os mdulos inferiores forem integrados de baixo para
cima, o nmero de clusters (mdulos que executam uma sub-funo do sistema) pode
ser reduzido substancialmente na integrao dos mdulos superiores.
Usando a tcnica Sandwich a integrao mais flexvel e adaptativa, porm ela mais
complexa de ser planejada.
Comparao
Para encerrar o ltimo post dessa srie, segue abaixo, uma tabela comparativa das 4
tcnicas de integrao que vimos nessa srie:


65
Bottom-up Top-down Big-bang Sandwich
Integrao
Cedo Cedo Tarde Cedo
Tempo para o
funcionamento bsico
do programa
Tarde Cedo Tarde Cedo
Drivers
Sim No Sim Sim
Stubs
No Sim Sim Sim
Trabalho em paralelo
no incio
Mdio Baixo Alto Mdio
Capacidade de testar
caminhos particulares
Fcil Difcil Fcil Mdio
Capacidade de
planejar e controlar a
sequncia
Fcil Difcil Fcil Difcil
Fonte:
Chapter 8 Testing the Programs, Software Engineering: Theory and Practice:
wps.prenhall.com/wps/media/objects/3087/3161346/slides08.ppt
V. Binder. Testing Object-Oriented System: Models, Patterns, and Tools. Addison
Wesley, 2000.
Aula 13 Teste de Software, Walter de Abreu Cybis:
http://www.inf.ufsc.br/~cybis/ine5322/Aula13_Teste_de_SW_cont.pdf
System Integration, Dr. Stphane S. Som. University of Ottawa:
http://www.site.uottawa.ca/~ssome/Cours/SEG3203/integration.pdf


66
28. O melhor da semana: 03/05 a 09/05
Pessoal,
Aqui comea uma nova srie de posts, O melhor da semana, que trar notcias,
artigos, posts, etc relacionados a rea de Teste e Qualidade de Software.
O intuito dessa srie divulgar o bom trabalho de pessoas que contribuem para a nossa
rea e tambm enriquecer o contedo do QualidadeBR, para voc querido(a) leitor(a).
Alm disso, h muitos assuntos que eu gostaria de comentar aqui no QualidadeBR,
mas infelizmente falta tempo. E com O melhor da semana poderei trazer matrias que
li durante a semana, e que achei interessante sobre tais assuntos.
E voc, caro(a) leitor(a) tambm poder contribuir, deixando o seu comentrio sobre
algo que viu e achou interessante.
Vamos para o primeiro O melhor da semana:
Palestra: Testes de Unidade com JUnit Paulo Csar M. Jeveaux (Jeveauxs
Weblog);
O que significa Qualidade? Mark Levison, traduzido por Andr Pantalio
(InfoQ);
Testador dedicado em um time gil Vikas Hazrati, traduzido por Samuel
Carrijo (InfoQ);
Borland vendida por US$ 75 milhes Daniela Moreira (INFO Online);
Aula: Teste de Software no CTAI Victor Hugo Germano (A Maldita
Comdia);
Aula 2: Teste de Software no CTAI Victor Hugo Germano (A Maldita
Comdia);
Adicionando um campo customizado na View do Mantis Elias Nogueira (Sem
Bugs);
Configurando o JMeter para Stress Test no IBM WebSpherePortal Server
Fbio Queiroz (Caf com Tecnologia);
JMeter na prtica: teste de carga no IBM WebSphere Portal Fbio Queiroz
(Caf com Tecnologia).
Bem isso pessoal, por hoje s. Espero que vocs tenham gostado do primeiro post da
srie O melhor da semana.


67
29. O melhor da semana: 10/05 a 16/05
Segue abaixo, a lista das melhores matrias que li nessa semana, alis, essa semana
consegui ler bastante coisa boa:
Ferramentas da Qualidade: Grfico Controle Elias Nogueira (Sem Bugs);
Scrum na globo.com derrubando mitos Danilo Bardusco (Barduscos Blog);
Usabilidade: uma introduo - Ezequiel C. Blasco (Linha de Cdigo);
Software Testing Diplomacy: A Testers Guide on How to Deal with
Programmers! Debasis Pradham (Software Testing Zone);
Testando aplicaes web com Selenium Miguel Galves (Log4Dev);
Best Practices for Testing in Offshore Agile Projects Peter Vaihansky e Anna
Obuhova (Offshore Agile);
Retorno de Investimento para Testes Automatizados Amr Elssamadisy,
traduzido por Roberto Costa (InfoQ);
Testes de Software no FISL Luiz Gustavo S. Vieira (TESTAVO);
YSlow: Melhore a Performance do seu Website Thiago Ferreira (iMasters);
Encontrando vulnerabilidades em aplicaes web com teste fuzzy Wagner
Elias (Wagner Elias Think Security First);
Scrum Gathering: Scrum e Mudana Organizacional Andr Pantalio
(Ensinar).
Voc leu algo interessante, relacionado a rea de Teste e Qualidade de Software, e quer
compartilhar? Sinta-se vontade em colocar nos comentrios.
Abraos! E uma tima semana!








68
30. O melhor da semana: 17/05 a 23/05
Segue abaixo, a lista do melhor dessa semana, espero que gostem:
Metodologias geis no Estilo Dr House Eduardo Bregaida (Java Anywhere);
Falhas em projetos culpa da Cultura e no da Metodologia Eduardo Bregaida
(Java Anywhere);
Ten Principles for Agile Testers Jeff Langr (Agile: In A Flash);
Slides da Apresentao Contratos e Scrum: The Good, The Bad and The Ugly
realizada no Brazil Scrum Gathering 2009 Jos Papo (Jos Papo Weblog);
Cinco um Tamanho Ideal para as Equipes? -Vikas Hazrati, traduzido por
Roberto Costa (InfoQ);
Tutorias recomendados sobre TDD Vikas Hazrati, traduzido por Alberto
Souza (InfoQ);
Qual a Taxa Apropriada de Testadores geis para Desenvolveres? Isso
Depende. Chris Sims, traduzido por Anderson Duarte Vaz (InfoQ);
Livros de Usabilidade e IHC Os 5 Mais Ezequiel Blasco (TestExpert).
Abraos! E tenham uma tima semana!


69
31. O melhor da semana 24/05 a 30/05
Segue abaixo, a lista do melhor da semana, alis, nessa semana nasceu um novo blog
sobre Teste e Qualidade de Software, o Ensaios de Qualidade da Sarah Pimentel,
recomendo visitar e assinar o feed do blog da Sarah.
CTAL Inside Sarah Pimentel (Ensaios de Qualidade);
Novo blog sobre Qualidade e Teste de SoftwareNovo blog sobre Qualidade e
Teste de Software Elias Nogueira (Sem Bugs);
10 Dicas de sobrevivncia para um Analista de Testes Zauza (TestExpert);
Rational Performance Tester v7 Livro em PDF Grtis Fbio Martinho
Campos (TestExpert);
Qualidade, Qualidade de Software e Garantia da Qualidade de Software So as
Mesmas Coisas ? Fbio Martinho Campos (TestExpert);
How on earth did we test the web without these tools? Alan Richardson (Evil
Tester);
Testing Experience Security Testing (nova edio da Revista Testing
Experience);
Scrum Gathering Os desafios de escalar Scrum Andr Pantalio (Ensinar).
Voc leu algo interessante, relacionado a rea de Teste e Qualidade de Software, e quer
compartilhar? Sinta-se vontade em colocar nos comentrios.
Abraos! E tenham uma tima semana!


70
32 - Neutralizando Falhas
Esses dias estava executando um teste, quando de repente me deparo com uma falha
estranha, algo que sempre funciona, que at uma funcionalidade bsica do sistema,
para de funcionar.
Porm, a falha ocorria de forma intermitente, e havia muitos fatores que poderiam est
influenciando a ocorrncia da falha.
E neste momento, que devemos ter calma e pacincia para investigar melhor o ocorrido.
E no sair j cadastrando a falha no bug tracking. Precisamos antes neutralizar a falha.

Como assim neutralizar a falha?
Para tentar explicar o uso do verbo neutralizar, no contexto de Teste de Software, vou
utilizar uma analogia, seguida por uma situao de teste:
Analogia
Voc acaba de adquirir a TV Digital de uma empresa de telecomunicaes verde, e aps
um tempo de uso a sua me comea a reclamar, falando que s vezes a TV est sem
sinal. Voc acha estranho, pois quando voc assisti a TV a imagem est perfeita.
Mas numa certa noite chuvosa, voc chega em casa mais cedo para assistir o jogo do
seu time e percebe que a TV est sem sinal. E lembrando das vezes que a sua me tinha
reclamado, percebe que naqueles dias tambm tinha chovido.
Situao de teste
De vez em quando, ao realizar um cadastro voc percebe que o carregamento da pgina
demora mais do que o comum. Voc acha estranho e tenta achar o motivo para tal falha.
Analisando cada passo feito, e alternando os dados dos campos voc acaba descobrindo
que o atraso ocorre sempre quando voc preenche o campo e-mail, com o endereo do
usurio igual ao domnio.

71
Tanto na analogia como na situao de teste, havia duas falhas e poderamos (mas no
deveramos) informar a falha da seguinte maneira:
Analogia: De vez em quando a TV est sem sinal.
Situao de teste: O carregamento da pgina, aps ter realizado o cadastro,
demora mais de X segundos de forma intermitente.
Mas aps uma melhor anlise das falhas, conseguimos descobrir o cenrio exato em que
a falha ocorre, e assim elas deixam de ser intermitente e passam a ser fceis de ser
reproduzidas.
Ento neutralizar igual isolar a falha?
Sim, afinal ambas as aes tem o mesmo objetivo: identificar o cenrio exato da falha,
eliminando todos fatores que no influenciam a ocorrncia da falha.
Sempre possvel neutralizar as falhas?
No, e isso ocorre geralmente por trs motivos:
Falta de conhecimento sobre a aplicao que est sob teste;
Os fatores influenciadores da falha esto no nvel estrutural do sistema, portanto
no so possveis de ser descobertos nos testes funcionais;
No h tempo para a investigao.
Qual importncia da neutralizao?
A neutralizao da falha uma das tarefas mais importantes do testador, e exige um
esprito investigativo. Afinal nem sempre a falha fcil de ser descoberta e isolada.
E ela ajuda, e em muito, o trabalho de extermnio de bugs dos nossos amigos
desenvolvedores. Devemos sempre nos preocupar em passar da melhor e mais detalhada
forma o cenrio da falha ( melhor informao a mais do a menos ).
Quando temos um cenrio bem detalhado, o desenvolvedor s vezes consegue descobrir
onde est o bug, s com a leitura do cenrio.
E para encerrar esse post, deixo abaixo uma frase do Sherlock Holmes que tem haver
com o tema do post:
Voc v, mas no observa.


72
33 - O melhor da semana 31/05 a 06/06
Hoje vou comear o melhor da semana de uma forma diferente. Afinal no sempre
que um novo blog de Teste e Qualidade de Software nasce, e em menos de duas
semanas dois novos blogs nasceram.
No dia 20 de maio nasceu o Ensaios de Qualidade da Sarah Pimentel (at comentei no
ltimo o melhor da semana), que tem como objetivo a troca de experincias e
conhecimento na rea de Qualidade de Software, especialmente Testes de Software.
E nesta ltima tera-feira (02/06), o Gustavo Quezada iniciou o seu blog Falando em
Teste e Qualidade de Software, cujo objetivo ser ajudar no compartilhamento de
informaes para a nossa rea de Teste e Qualidade de Software.
Fiquei muito feliz com o surgimento desses novos blogs, o que prova que a nossa rea
est a pleno vapor! E at aproveito para parafrasear o nosso presidente:
Nunca na histria deste pas, a rea de Teste e Qualidade de Software esteve to
atuante!
Bem, agora vamos para a lista do melhor da semana:
Usando Rede Bayesiana e Critrio de Adequao para Obter uma Melhor
Cobertura de Teste de Requisitos 2. BRATESTE ALATS Gustavo
Quezada (Falando em Teste e Qualidade de Software);
Prova da CBTS em SP Maio de 2009 Robson Agapito (TestExpert);
Porque a Certificao importante Elias Nogueira (TestExpert);
Como testar sites em vrios navegadores de uma s vez Rafael Perrone
(fazendoacontecer.net);
Encontre os bugs perdidos no seu cdigo com Sonar Fernando Boaglio
(BOAGLIO.COM);
Mini-cursos gratuitos Borland Elias Nogueira (Sem Bugs);
Teste no ciclo de vida de software Sarah Pimentel (Ensaios de Qualidade);
Desenvolvimento responde por 96% das falhas em sites de negcios Redao
do IDG Now! (CIO);
Como TDD e Pareamento Aumentam a Produtividade Mike Bria, traduzido
por Samuel Carrijo (InfoQ);
O pice no Ciclo do Scrum Andr Pantalio (InfoQ);

73
Desculpas clssicas para procrastinar na carreira profissional Vinicius
(Carreira e Certificaes em TI);
Seria o acidente do A330, causado por um bug? Luiz Gustavo Schroeder
Vieira (TestExpert);
Entrevista de Jakob Nielsen o Papa da Usabilidade na Folha Online
Ezequiel Blasco (TestExpert);
ABC da Usabilidade Testes Empricos com Usurios (Fase 1 Preparao)
Ezequiel Blasco (TestExpert);
Mtricas subjetivas e objetivas em Testes de Software Zauza (TestExpert);
My Selenium Tests Arent Stable! Simon Stewart (Google Testing).
Voc leu algo interessante, relacionado a rea de Teste e Qualidade de Software, e quer
compartilhar? Sinta-se vontade em colocar nos comentrios.
Abraos! E tenham uma tima semana!


74
34 - Anlise de Causa Raiz
Problemas sempre acontecem, e na rea de TI eles so constantes. Desde falhas de
segurana no sistema at falhas na comunicao interna.
E muitas vezes, passamos dias, meses e at anos s apagando incndios, ou seja, s
amenizando os efeitos dos problemas existentes. E neste momento, se a causa raiz dos
nossos problemas fosse uma pessoa, ela estaria dando boas gargalhadas.
Mas no h nenhuma graa nessa histria. A tarefa de apagar incndios no pode
entrar na nossa rotina. E para mudar essa histria, precisamos descobrir a causa raiz dos
nossos problemas.
Uma das tcnicas mais bsicas e importantes, em qualquer programa de melhoria da
qualidade, pode nos auxiliar na busca da causa raiz: a Anlise de Causa Raiz.
Introduo
A Anlise de Causa Raiz, tambm conhecida como RCA (Root Cause Analysis) uma
maneira de identificar as causas de um problema, afinal os problemas so melhores
resolvidos ao tentar corrigir ou eliminar as suas causas.
Ela uma tcnica usada nas mais variadas reas, alis, voc j deve ter visto uma das
formas de implementar ela: o famoso diagrama de Ishikawa, conhecido tambm como
Diagrama de Causa e Efeito ou Espinha-de-peixe (fishbone), nas aulas de
Administrao na faculdade.
Como podemos implementar a Anlise de Causa Raiz?
H muitas tcnicas, com as quais podemos implementar a Anlise de Causa Raiz, entre
as principais se encontram:
Diagrama de Causa e Efeito: permite identificar, explorar e apresentar
graficamente todas as possveis causas, relacionadas a um nico problema.
Utilizando em equipe, criamos uma foto do conhecimento e consenso de todos
os envolvidos, a respeito do problema.
Cinco Porqus: desenvolvida por Sakichi Toyoda (fundador da Toyota),
baseada na realizao de 5 iteraes perguntando o porqu daquele problema,
sempre questionando a causa anterior. E na prtica no necessrio fazer 5
perguntas, pode ser mais ou menos, o importante chegar causa do problema.
Reunio de Anlise Causal: as causas do problema so levantadas em reunies
do tipo Brainstorming. As causas mais provveis podem ser discutidas entre a
equipe, e aps descobrir as causas dos problemas, os participantes podem propor
aes que ajudem na preveno desses problemas no futuro.

75
possvel e at recomendado que se use mais de uma tcnica ao mesmo tempo, por
exemplo: na reunio de Anlise Causal utilizar o Diagrama de Causa e Efeito.
Concluso
A Anlise de Causa Raiz um importante elemento em qualquer rea de TI, e pode ser
usado em qualquer fase do projeto.
Um momento bom para ela ser usada, durante a reunio de lies aprendidas. Pois
nada melhor do que descobrimos a causa real dos problemas que enfrentamos no
projeto, com todos envolvidos participando e opinando.
Ela tambm poder ser usada pelos desenvolvedores para encontrar a causa para o
defeito, e desta maneira, alm de poder corrigir tal defeito eles ainda podero prevenir a
sua ocorrncia no futuro.
E para finalizar, acredito que clara a necessidade de encontrar a causa raiz dos
problemas que vivenciamos no dia-a-dia, e que essa uma tarefa que deve ser feita em
equipe, sempre que possvel. Afinal, nem sempre a causa de um problema to visvel
ou fcil de ser encontrada, como por exemplo: problemas de performance, s vezes
passamos at meses para descobrir, onde estava o gargalo da aplicao. Mas com
certeza, muito melhor gastar massa ceflica do que desperdiar dinheiro comprando
novos servidores, alm claro, da satisfao e benefcios de ter encontrado o real
motivo do problema.
Fonte:
Software Quality, Module 10: Effective Practices for Quality Analysis Lesson 3:
Root-Cause Analysis (AzIT)
5 Porqus Luiz de Paiva


76
35 - O melhor da semana 07/06 a 13/06
Pessoal,
Segue abaixo, a lista do melhor da semana, espero que gostem:
Agile NO para preguiosos Manoel Pimentel (Blog Viso gil);
Quanto testar Clavius Tales (Clavius Tales);
Estimativa de Teste utilizando uma Matriz de Teste por Tipo de Funcionalidade
Gustavo Quezada (Falando em Teste e Qualidade de Software);
O mundo pertence aqueles que pensam em novos caminhos Gustavo Quezada
(Falando em Teste e Qualidade de Software);
Top 10 Motivos para Amar Teste gil Mark Levison, traduzido por Gisela
Nogueira (InfoQ);
Como TDD e Pareamento Aumentam a Produtividade Mike Bria, traduzido
por Samuel Carrijo (InfoQ);
A agenda Semanal de Uma Equipe gil Chris Sims, traduzido por Vinicius
Assef (InfoQ);
James Shore com mais sobre se Manter (gil) na Real Mike Bria, traduzido
por Marcus Rehm (InfoQ);
Por que alguns profissionais de TI adquirem experincia mais rapidamente?
Paulo Farias (iMasters);
Quanto ganha o profissional de TI em So Paulo? ==> Dessa Vez Tem Analista
e Arquiteto de Teste <== Fbio Martinho Campos (TestExpert);
tica em Testes de Software Luiz Gustavo Schroeder Vieira (TestExpert);
ABC da Usabilidade Testes Empricos com Usurios (Fase 2 Aplicao)
Ezequiel Blasco (TestExpert);
Procedimento de Introduo ao Selenium Antonio Geilson Parente Lopes
(TestExpert);
No Repita o que esta Convencionado Inove Nelson Abu Samra Rahal
Junior (Blog do Abu).
Voc leu algo interessante, relacionado a rea de Teste e Qualidade de Software, e quer
compartilhar? Sinta-se vontade em colocar nos comentrios.
Abraos! E tenham uma tima semana!

77

Ferramentas & Tutoriais

Ferramentas & Tutoriais

78
1. Construindo um Ambiente Virtual (parte1)
No artigo anterior, falei sobre Virtualizao e como ela pode ser uma boa alternativa
para a criao de ambientes de teste. Agora irei colocar a mo na massa, explicando
passo a passo a construo de uma mquina virtual (Virtual Machine VM), utilizando
o VMware Server 2.0 (beta) para a sua criao, que pode ser obtido gratuitamente no
link abaixo:
http://www.vmware.com/download/server/
Muito prazer! Eu sou o VMware Server!
Ele tornou-se gratuito desde 12 de junho de 2006 e voltado ao uso em servidores de
pequeno e mdio porte. Sua principal diferena, comparado s outras ferramentas de
Virtualizao, que o VMware Server roda remotamente, e acessado atravs de uma
interface de administrao via web (chamada de VMware Infrastructure Web Access,
ou VI Web Access), onde voc pode:
Criar, configurar e deletar VMs;
Adiciona e remover VMs do inventory;
Iniciar, parar, restartar, suspender ou voltar as VMs;
Monitorar a operao das VMs;
Interagir com os sistemas que esto rodando nas VMs;
Gerar linhas de comando que permitam que usurios interajam diretamente com
sistema operacional convidado, usando o VMware Remote Console;
Criar atalhos Web para os usurios das mquinas virtuais, com opes para
limitar a visualizao do console ou visualizar apenas uma VM;
Configurar as opes de virtualizao.
H algumas limitaes, mas que no afetam a grande maioria dos usurios, como o
suporte de at 8 GB de memria RAM e de 950GB de HD (tanto IDE quanto SCSI) e
de no mximo 4 mquinas virtuais por processador.

Figura 16 - Arquitetura do servidor com 4 mquinas virtuais (retirada do Data Sheet do VMware Server)



79
Instalando o VMware Server
Os requisitos mnimos para a instalao do VMware Server um processador de
733MHz e 512MB de RAM, o sistema operacional pode ser tanto Windows, do 2000
para cima, quanto Linux (Red Hat, SUSE, Ubuntu, Mandriva, Mandrake, etc). Vou
instalar o VMware Server em um Athlon 64 3000+ (2.00 GHz) com 512MB de RAM
rodando o Windows XP (SP2).
Antes de instalarmos o VMware Server precisamos de uma serial, que pode ser obtida
gratuitamente no site da VMware, bastando para isso preencher um
cadastro(http://www.vmware.com/beta/server/registration.html).
A instalao do VMware Server bem simples, na figura abaixo vemos a tela de incio
da instalao, basta clicar em Next.

Figura 17 - Primeiro passo da instalao do VMware Server
Aps a tela de acordo da licena aparecer a tela abaixo, onde pode-se mudar o local de
instalao do VMware Server.

80

Figura 18 - Segundo passo da instalao do VMware Server
Na tela seguinte podemos alterar as configuraes do servidor. O diretria onde ficar
os arquivos da mquina virtual. O nome do domnio, utilizado para criar o atalho no
desktop que abre o VI Web Access. A porta HTTP a porta que voc acessa a interface
Web localmente e a HTTPS utilizada para o acesso remoto, recomendado que seja
deixado as configuraes padres. E abaixo, h um checkbox que caso esteja marcado,
permitir o incio e a finalizao automaticamente das mquinas virtuais com o sistema.
Aps, configurada todas as opes, basta clicar no boto Next.

81

Figura 19 - Terceiro passo da instalao do VMware Server
Depois da escolha dos atalhos a serem criados, a tela abaixo ser apresentada, na qual
clicamos em Install para iniciar a instalao do VMware Server.

Figura 20 - Quarto passo da instalao do VMware Server
Terminada a instalao hora de registrar a ferramenta, no campo editvel Serial
Number inserimos o serial, obtido anteriormente no site da VMware. E clicamos no
boto Enter.

82

Figura 21 - Quinto passo da instalao do VMware Server
Pronto! J temos o VMware Server instalado. Agora vamos para a parte mais divertida,
a criao da mquina virtual. Mas s na segunda parte deste tutorial. At l!

Figura 22 - Sexto passo da instalao do VMware Server
Fonte:
VMware Server Users Guide, obtido no site da VMware

83
2. Construindo um ambiente virtual (parte2)
Na primeira parte deste tutorial instalamos o VMware Server (VMS), agora iremos para
a parte mais divertida, a criao da VM.
O que aconteceu com o logon do Windows?
Para quem usa a troca rpida de usurio, uma das primeiras mudanas que pode ser
notada justamente a maneira do logon do Windows, com a instalao do VMS a opo
de troca rpida de usurio fica desativada, portanto o logon vai ser com a tela de boas-
vindas.
Acessando a interface Web
Para acessar o VMS, voc pode clicar no atalho criado na instalao ou digitar o
endereo no seu browser (http://127.0.0.1:8308/ui/). Caso no aparea a dela de login
verifique se os servios do VMS foram iniciados:
1. Acesse o Executar (tecla Windows + R);
2. Digite services.msc (sem as aspas) no Executar;
3. Inicie os servios do VMS (figura abaixo), recomendvel deixar automtico a
inicializao de tais servios.

Figura 23 - Visualizao dos servios do VMware Server
No login utilize os mesmos dados do login do Windows.

Figura 24 - Login no VMware Server
Passo 1 Nome e local da VM
No menu a direita (Commands) clique em Create Virtual Machine, a tela abaixo
aparecer, na qual ser feita a escolha do nome e do datastore da VM, que nada mais

84
do que o local onde os arquivos da sua VM ficaro. Escolha o datastore standard, que
foi criado j na instalao da VMS e clique em Next.

Figura 25 - Criao da mquina virtual
OBS.: Caso voc deseje renomear um datastore ou criar um novo, basta selecionar o
datastore no menu Datastores e depois no menu Commands haver as opes de
configurao do datastore.
Passo 2 Sistema Operacional
O prximo passo a especificao de qual sistema operacional ser instalado na VM,
no nosso caso escolha a opo Linux operating system e no combo box da Version
selecione Ubuntu Linux (32-bit), que ser o sistema operacional que iremos instalar.

Figura 26 - Selecionando o sistema operacional que ser instalado


85
Passo 3 Memria e Processador
Aps clicar em Next, a tela abaixo ser apresentada, onde feita a configurao da
quantidade de memria e de processadores que a VM utilizar. Configure de acordo
com a capacidade da sua mquina, busque sempre configurar de acordo com a sua
necessidade, lembrando que no meu caso eu estou dividindo metade da minha RAM
entre a VM e o Host.

Figura 27 - Configurando a memria e a quantidade de processadores da VM
Passo 4 Capacidade de Armazenamento
Agora vamos configurar o tanto de HD que a nossa VM ter. Podemos criar um disco
virtual, usar um disco virtual j existente ou no adicionar um disco virtual. Vamos
escolher a opo Create a New Virtual Disk, para criar um disco virtual, depois clique
no boto Next.

Figura 28 - Criao do disco virtual

86
Na configurao do disco virtual definimos a capacidade dele e o seu diretrio. Tambm
h outras opes que no iremos modificar:
File Options especifica como ser a alocao do disco, onde podemos alocar o
espao todo de uma vez ou dividir em arquivos de 2GB;
Disk Mode se as mudanas so salvas permanentemente, como um disco
rgido normal, caso marcado a opo Persistent ou se ele altera de acordo com
as Snapshots descartando as mudanas a cada reinicio ou desligamento caso
marcado a opo Nonpersistent;
Virtual Device Node - qual o tipo do disco (IDE/SCSI) e qual device;
Policies oferece a opo de otimizar o disco em busca de segurana ou
desempenho.

Figura 29 - Configurando as propriedades do disco virtual
Passo 4 Adaptador de Rede
Uma das etapas mais importantes a configurao da rede virtual. Aqui selecionamos
Add a Network Adapter para que a nossa VM possa se conectar rede.

87

Figura 30 - Criando o adaptador de rede
O VMS oferece trs maneiras de conexo com rede:
Bridged: conecta a VM rede usando a rede do Host. Esta a opo mais fcil
se o computador Host estiver em uma rede. A VM receber um IP prprio e ser
visvel para todos os computadores da rede.

Figura 31 - Ilustrao da conexo Bridged
HostOnly: cria uma conexo direta com o Host, como tivesse um cabo cross-
over conectando a VM com o Host. uma boa opo se o interesse isolar a
rede virtual.

88

Figura 32 - Ilustrao da conexo HostOnly
NAT: conecta a VM rede usando o IP do Host. um modo fcil para acessar a
Internet, porm no d acesso rede externa. No sendo uma opo para um
servidor, j que os computadores da rede no tm acesso a VM.

Figura 33 - Ilustrao da conexo NAT
Para a nossa VM escolhemos o modo de conexo Bridged e marcamos o check box para
que ela se conecte rede ao ligar.

89

Figura 34 - Definindo as propriedades da conexo de rede
Passo 5 Drive de CD/DVD
Escolhemos a opo Use a Physical Drive, para que possamos utilizar o drive de
CD/DVD do Host e clicamos em Next. A opo Use an ISO Image interessante,
caso queria instalar o Sistema Operacional atravs de uma ISO.

Figura 35 - Definindo o acesso ao drive de CD/DVD
Aqui escolhemos a unidade que est o drive de CD/DVD e marcamos o check box para
que ele possa est acessvel ao ligar a VM. Aqui tambm podemos configurar o tipo de
adaptador e o device.

90

Figura 36 - Configurando o drive de CD/DVD
Passo 6 Drive de Disquete
Caso voc tenha um drive de disquete, marque a opo Use a Physicak Drive, caso
contrrio a Dont Add a Floppy Drive e clique em Next.

Figura 37 - Definindo o drive de disquete
Aqui selecionamos a unidade em que est o drive de disquete e marcamos a opo de
ativ-lo ao ligar.

91

Figura 38 - Configurando o drive de disquete
Passo 7 Controlador USB
Selecionamos a opo Add a USB Controller, para que a nossa VM tenha acesso a
dispositivos USB e clicarmos em Next.

Figura 39 - Definindo o controlador USB
Agora a nossa VM j est configurada, verificamos as configuraes e clicamos em
Finish.

92

Figura 40 - Visualizao das informaes da VM
Pronto! J temos uma mquina virtual, porm ela est sem sistema operacional. Mas a
instalao do Ubuntu ser apresentada s na prxima parte do tutorial. At l!
Fonte:
VMware Server Users Guide, obtido no site da VMware


93
3. Construindo um ambiente virtual (parte3)
Chegamos a terceira e ltima parte deste tutorial, aqui iremos instalar o Ubuntu 8.04
Hardy Heron, mas antes disso vamos entender melhor a interface web do VMS,
chamada de VI Web Access.
Na primeira parte deste tutorial, foram citadas as funcionalidades que podem ser
utilizadas no VI Web Access. Agora vamos conhecer um pouco melhor algumas dessas
funcionalidades:
Inventory: apresenta a mquina Host e as VMs que podem ser acessadas;
Virtual Machine Workspace: quando uma VM selecionada no painel
Inventory, o workspace da VM apresenta informaes dela, sendo dividido em
abas:
o Summary: traz informaes de configurao, desempenho e status. Aqui
voc pode tambm modificar as configuraes da VM;
o Console: Permite que voc controle diretamente a VM;
o Tasks: mostra as tarefas que os usurios executaram na VM;
o Events: mostra os eventos ocorridos na VM;
o Permissions: apresenta e permite a configurao das permisses da VM.
Na parte inferior da pgina apresentado um histrico das ltimas tarefas
realizadas.
Na parte superior da pgina est localizado os botes para parar, pausar, iniciar e
restaurar a VM.

Figura 41 - Informaes sobre a VM
Plugin VMware Remote Console
Ao clicar na aba console nos deparamos com a seguinte tela:

94

Figura 42 - Aviso sobre a instalao do plug-in
Para instalar o plugin, basta clicar em Install plug-in, a instalao bem rpida. E
logo aps a instalao o console j poder ser usado, clicando nele o VMware Remote
Console ser aberto.

Figura 43 - VMware Remote Console pronto para ser usado
OBS.: O Firefox 3, at a data deste tutorial, no tem suporte a esse plugin.
Conhecendo o VMware Remote Console (VMRC)
atravs do VMRC que acessamos diretamente a nossa mquina virtual.

95

Figura 44 - Tela do VMware Remote Console
Nele temos as opes de reiniciar, suspender, e desligar a VM e tambm podemos
habilitar/desabilitar os devices. Uma vez no VMRC todo input ser feito na VM, para
voltarmos ao Host apertamos as teclas Ctrl+Alt.

Figura 45 - Host e VM



96
Por que o Ubuntu?
Atualmente, o Ubuntu uma das distribuies Linux que mais vem crescendo em
nmeros de usurios nos ltimos anos, devido a quatro fatores bsicos:
Facilidade de instalao: Atravs do LiveCD do Ubuntu, voc consegue
instalar facilmente o Ubuntu em qualquer computador e a verso 8.04 ainda traz
uma nova funcionalidade, a instalao do Ubuntu dentro do prprio Windows,
sem a perda de qualquer arquivo e sem mudar nenhuma configurao, a no ser
o boot.
Reconhecimento de hardware e perifricos: quase sempre ao ser instalado, o
Ubuntu reconhece todo o hardware da sua mquina, instala os drivers
corretamente e deixa tudo funcionando pra voc.
Facilidade de instalao de softwares: o Ubuntu derivado do Debian e por
isso contm o apt-get, que o gerenciador de pacotes. Com ele a instalao e
atualizao de programas muito simples em comparao a outras distribuies
que no fazem uso do apt-get.
Usabilidade: o Ubuntu tem uma interface grfica limpa e agradvel, na qual
possvel realizar a maioria das configuraes.
O Ubuntu pode ser obtido gratuitamente por trs maneiras:
Por download: a maneira mais simples, rpida e fcil de obter. Podendo ser
feito nos seguintes sites:
- http://www.ubuntu-br.org/download
- http://www.ubuntu.com/getubuntu/download
CDs gravados (comunidade): No link abaixo apresentada uma lista contendo
o contato de usurios que esto distribuindo voluntariamente CDs do Ubuntu em
todo o Brasil.
- http://wiki.ubuntu-br.org/CDsNoBrasil
CDs gravados (ShipIt): A Canonical, empresa que patrocina o
desenvolvimento do Ubuntu, possui um servio de distribuio de CDs. Para
receber o CD basta preencher um cadastro no site:
- https://shipit.ubuntu.com/
Chega de embromao vamos a instalao!
A instalao do Ubuntu uma tarefa to simples (Next-Next) que nem precisava de um
tutorial, mas como informao nunca demais e sempre tem os marinheiros de primeira
viajem, vou mostrar passo a passo a instalao do pingim:
Logo que ligamos a VM, clicando no boto play, a tela abaixo ser apresentada, onde
selecionamos a opo Instalar o Ubuntu.

97

Figura 46 - Opes oferecidas ao iniciar pelo CD do Ubuntu
O primeiro passo a escolha do idioma que ser usado durante a instalao, escolhido o
idioma clique em Avanar.

Figura 47 - Escolha o idioma

98
Escolha o fuso horrio da sua cidade. Lembrando que a hora pode ser ajustada depois da
instalao.

Figura 48 - Informe a sua localidade
Terceiro passo, a escolha do modelo do seu teclado, caso tenha alguma dvida faa o
teste no campo editvel.

Figura 49 - Escolha o layout do teclado

99
Chegamos num momento de tenso, o particionamento do disco, mas no tenha medo o
seu HD no ser particionado, lembre-se que vamos utilizar o disco virtual, criado no
momento da criao da nossa VM, portanto s selecion-lo e clicar em Avanar.


Figura 50 - Escolha a opo Assistido
Agora a hora de definir o nome do usurio e a sua senha, lembrando que com esse
usurio e senha que voc far login no Ubuntu. Sendo, que esse usurio apenas um
usurio avanado e no o usurio root. O Ubuntu, por questo de segurana, vem com o
usurio root desabilitado, para habilit-lo basta digitar o seguinte comando no terminal:
$ sudo passwd root
password: (digite a senha criada da instalao)
New Password Unix: (digite a senha que ser do root)
Repeat Password Unix: (repita a senha que ser do root)

100

Figura 51 - Informe os dados de login

A seguir, so apresentadas as configuraes do seu novo sistema operacional. Clique
em Instalar para iniciar a instalao do Ubuntu.


Figura 52 - Visualizao das informaes referentes a instalao
O processo de instalao demora em torno de 30 minutos, nesse tempo voc pode ir
fazer outra coisa tranqilo, pois diferente do Windows o Ubuntu no faz nenhuma
pergunta durante a instalao.

101

Figura 53 - Progresso da instalao do Ubuntu
Terminada a instalao, precisamos reiniciar o computador para comear a usar o
Ubuntu.

Figura 54 - Aps a instalao necessrio reiniciar a VM
Aps ter reiniciado o sistema, j podemos nos divertir no nosso novo sistema.
Lembrando que voc pode acessar a VM de qualquer outro computador da rede,
bastando digitar o IP do Host e a porta do VMS, no nosso caso a porta a 8308.

102

Figura 55 - Aps ter reiniciado o Ubuntu j est instalado na VM
Espero que vocs tenham gostado do primeiro tutorial do QualidadeBR. Qualquer
sugesto, crtica ou dvida, sintam-se vontade!


103
4. FireShot: Plugin para Screenshots
Alm de achar o bug o Tester deve comprovar a existncia do mesmo. E nesta hora um
recurso muito usado a captura da tela, que nunca mais ser a mesma com o uso do
FireShot.
O FireShot um excelente plugin, disponvel para o Firefox e para o IE, cuja principal
funo o screenshot. Mas agora voc pode est se perguntando: para que instalar um
plugin se eu tenho a tecla Print screen?
Com o FireShot alm de capturar a parte visvel da tela, voc ainda pode capturar a
pgina inteira e edit-la, utilizando recursos como:
Edio do screenshot;
Adio de anotaes;
Fazer desenhos estilo Paint;
Salvar nas extenses bmp, gif, jpeg e png;
Enviar por e-mail;
Fazer upload do screenshot.
E tudo isso sem pagar um centavo, o FireShot pode ser obtido gratuitamente nos
seguintes links:
Verso para Firefox: https://addons.mozilla.org/pt-BR/firefox/addon/5648
Verso para IE: http://screenshot-program.com/fireshot_ie_install.zip

Figura 56 - FireShot

104
5. Ferramentas bug tracking
Ao encontrar um bug o Tester pode avisar o desenvolvedor, por vrias maneiras, como
por exemplo: pessoalmente, msn, e-mail, documentos, ferramentas de bug tracking, etc.
Podemos perceber, que dentre as alternativas apresentas, h meios formais e informais
de relatar a existncia de bugs. A melhor maneira depender da dinmica da equipe
Testes e do seu processo.
Eu particularmente j utilizei os 5 meios de relato de bug apresentados, e muitas vezes,
at mais de um ao mesmo tempo. Atualmente, ao me deparar com algum resultado
imprevisto, eu busco conversar com o desenvolvedor, para que juntos possamos buscar
qual a real causa para aquele problema. Isso ocorre devido a complexidade do sistema, e
para obter um melhor detalhamento do bug.
Ao coletar todas as informaes necessrias sobre o bug, o passo seguinte cadastrar na
ferramenta bug tracking, chamada Eventum.
Para os marinheiros de primeira viagem, um software de bug tracking tem como
objetivo principal, ajudar a equipe de Teste e a de Desenvolvimento a manterem um
histrico dos bugs do sistema. Nela estaro todos os dados do bug encontrado, sendo de
grande ajuda para ambas as equipes, pois facilita o gerenciamento dos bugs.
H no mercado vrias ferramentas de bug tracking, dentre as quais podemos destacar as
seguintes:
Bugzilla - a mais famosa e usada ferramenta de bug tracking open source.
Baseada em Web, ela mantida por voluntrios, sendo utilizada por diversos
projetos e empresas, dentre os principais: Mozilla, Gnome, Nasa, NBC e
Wikipedia. (site oficial)
Eventum - criada e disponibilizada gratuitamente pela MySQL, ela se encontra
atualmente na verso 2.1.1. Ela fornece uma interface amigvel e flexvel
sistema de emisso de rastreamento que pode ser utilizado, tanto, por um
departamento de suporte tcnico para monitorar solicitaes de suporte ou por
uma equipe do desenvolvimento de software, a fim de organizar tarefas e
bugs. O Eventum usado pela equipe de Suporte Tcnico do MySQL Lab. (site
oficial)
FogBugz - o FogBugz alm de oferecer o controle de bugs, ele traz um sistema
completo de gerncia de projeto, a fim de auxiliar a comunicao nas equipes de
software. Um de seus diferenciais a incluso de uma wiki, onde se pode criar
documentos e especificaes tcnicas e funcionais. (site oficial)

105
Jira - uma aplicao J2EE de acompanhamento e gesto dos problemas. Ela
tambm tem a funcionalidade de gesto de projetos. O Jira pode ser baixado de
graa, porm em verso Trial, que expira aps 30 dias. (site oficial)
Mantis - uma ferramenta de bug tracking livre. Ela foi escrita em PHP e
trabalha com MySQL, MS SQL e PostgreSQL, sendo baseada em Web. O
Mantis roda em Windows, Linux, Mac OS, OS/2, dentre outros. Ela est sobre
os termos da licena GPL. (site oficial)
Trac - o Trac alm de ser um sistema de gerenciamento de bugs, possui a
funcionalidade de wiki para documentao. Sua interface web, e tambm est
sobre a licena GPL. Dentre os seus usurios est o Laboratrio de Propulso a
Jato da NASA. (site oficial)
Zephyr - uma aplicao com interface Web, feita em Flash, especifica para
equipes de Testes. Dentre suas principais funcionalidades esto: criao de testes
suites, execuo de testes, gerao de relatrios e o gerenciamento de bugs. Sua
licena gratuita at 3 usurios. (site oficial)
O Eventum o software que utilizamos na empresa em que trabalho, aps analisar
vrios outros softwares, chegamos a deciso de utilizar-lo por vrios motivos, sendo o
principal: o fato dele conseguir ser, ao mesmo tempo, simples e oferecer vrias
funcionalidades, que possibilitam um eficaz gerenciamento de bugs.
Em prximos artigos, trarei um tutorial que abordar, desde a instalao do Eventum at
o reporte de bugs utilizando-o. At mais!
Saiba mais
Quem ficou curioso em conhecer mais algumas ferramentas de bug tracking, segue
abaixo, alguns links contendo comparaes e informaes mais detalhadas sobre tais
softwares:
Comparaes
http://www.issue-tracking-software.de/
http://en.wikipedia.org/wiki/Comparison_of_issue_tracking_systems
http://www.pronus.eng.br/artigos_tutoriais/analises/ferramentasControleMudanca.php
Lista das melhores ferramentas Open Source para gesto e automao de testes.
(Cristiano Caetano)
http://www.linhadecodigo.com.br/Artigo.aspx?id=1392
Mind Map das ferramentas Open Source gratuitas (Cristiano Caetano)
http://www.mindomo.com/view?m=d1535d37f8b0aa6df765a1db90bfa317

106
6. Tutorial Eventum (parte 1)
Para estrear o ano, preparei um tutorial da ferramenta de bug tracking Eventum. Irei
comear explicando um pouco sobre a ferramenta, e logo aps, sobre a sua instalao.
Eventum
O Eventum um sistema de monitoramento de problemas, criada e disponibilizada pela
MySQL. Ele se adqua tanto para equipes de Suporte, quanto para de Testes. Nas
equipes de Teste o seu uso como bug tracking, ou seja, para o controle de bugs.
Abaixo, apresento algumas caractersticas do Eventum:
Interface usual - em pouco tempo a equipe j consegue dominar o uso da
ferramenta;
Hierarquia de usurios - h vrios tipos de usurios, com diferentes
permisses de acesso;
Campos customizveis - a equipe pode criar quantos campos novos quiser, para
que a ferramenta suporte melhor as caractersticas da equipe;
Busca avanada uma das melhores funcionalidades do Eventum. A busca de
bugs pode ser feita por vrios parmetros, o que muito bom, principalmente
em projetos grandes;
Aviso por e-mail ao cadastrar um bug, as pessoas que esto participando do
projeto recebero um aviso por e-mail, com os dados do bug;
Apresentao dos dados em grficos - logo na tela principal, a equipe j pode
visualizar uma srie de grficos sobre os bugs cadastrados;
Relatrios - possvel a extrao de vrias informaes em relatrios
estatsticos;
Importao de dados - voc pode importar a sua lista de bugs para arquivo .xls
(Excel).
Verso estvel - o Eventum uma ferramenta madura, atualmente na verso
2.1.1. Por isso, o seu trabalho, dificilmente, ser prejudicado por um bug;
Sem custos - nada melhor do que, uma boa ferramenta e ainda poder adquirir-la
de forma gratuita. O Eventum est sobre a licena GNU GPL.
Requisitos
Antes de tudo necessrio fazer o download do servidor Web, afinal o Eventum um
software baseado em Web. A ferramenta que vou usar vai ser o Apache2Triad, servidor
open source WAMP. O Eventum ir utilizar os seguintes softwares do Apache2Triad:
O servidor Web Apache;
Banco de dados MySql;
Servidor de e-mail Xmail;
A linguagem PHP 5.
O download do Apache2Triad pode ser feito no link abaixo, a verso a ser baixada a
1.5.4:

107
Download Apache2Triad
Aps feito o download, hora da instalao do Apache2Triad. Ela bem simples, mas
caso voc encontre alguma dificuldade, confira o passo a passo, apresentado na
sequncia.
Instalao do Apache2Triad
A primeira janela que ir aparecer, ser a de customizao da instalao. Voc poder
escolher quais componentes instalar. No nosso caso, iremos instalar tudo, portanto basta
clicar no boto Next >.

Figura 57 - Primeiro passo da instalao do Apache2Triad
Agora a hora de especificar o local, onde ser feita a instalao. Por default, a
instalao feita no diretrio raiz. Caso voc queira mudar, sinta-se vontade, s
lembrando que o local da instalao dever ter, pelo menos, 348.7MB de espao livre.

108

Figura 58 - Defina o local da instalao do Apache2Triad
Prximo passo ser setar a senha global, que dever ter no mnimo 8 caracteres, para
acessar os componentes do Apache2Triad. Lembrando que estamos definindo a senha
do root, e com ele que iremos realizar o acesso.

Figura 59 - Defina a senha para acesso ao Apache2Triad
Na prxima tela ser apresentada a licena GNU, basta clicar no boto I Agree
(concordo).

109

Figura 60 - Apresentao da licena GNU
Aps concordar com a licena do software, a instalao ser iniciada.

Figura 61 - Progresso da instalao do Apache2Triad
Agora hora de ir tomar um cafezinho, pois a instalao demorar em torno de 10
minutos. No seu trmino, a seguinte tela ser apresentada.

110

Figura 62 - Instalao concluda
Ainda restam algumas configuraes que sero feitas automaticamente, bastando para
isso digitar a senha, que foi definida anteriormente, na tela do prompt que se abrir.

Figura 63 - Informe a senha
Aps, a configurao ser terminada com sucesso. Uma nova tela ser apresentada, basta
clicar no boto OK. O sistema ser reiniciado e voc j poder utilizar o
Apache2Triad.

Figura 64 - Ser necessrio reiniciar o computador
Instalao do Eventum
Se a instalao do Apache2Triad j fcil. A do Eventum mais ainda.
O primeiro passo fazer o download da verso 2.1.1, no site da MySQL. Segue abaixo,
o link:

Download Eventum

111
Aps o download, precisamos descompactar o arquivo na pasta do Apache2Triad. Mais
precisamente na pasta htdocs, que se encontra no diretrio principal do Apache2Triad
(local que voc fez a instalao\apache2triad\htdocs ). Assim, que a pasta do Eventum
estiver na htdocs, j poderemos d incio a sua instalao.
A instalao do Eventum toda feita pela Web, ento, agora necessrio voc iniciar o
seu navegador e colocar o seguinte endereo na barra de navegao: http://localhost/
Aparecer a seguinte pgina.

Figura 65 - Diretrio do Apache
Clicamos sobre o link eventum-2.1.1/.
Uma nova pgina aparecer, e ser nela que iremos fazer a configurao da instalao
do Eventum. Isso mesmo, tudo em uma tela s, bem simples e rpido. Confira o passo a
passo para a configurao do Eventum e a do servidor SMTP, e antes de clicar no boto
Start Installation, verifique se est tudo certo, embora caso exista algum erro, o
prprio Eventum ir mostrar onde ele ocorreu.
1. Server Hostname aqui recomendo voc a colocar o IP da mquina, que o
Eventum est sendo instalado. Principalmente, se voc estiver fazendo a
instalao, a fim de utiliz-lo no trabalho. Pois, o Eventum ao enviar o e-mail do
bug, coloca o endereo do mesmo, que ser conforme o nome do servidor. Ou
seja, se for colocado localhost, ningum conseguir acessar o link. Ao lado, h o
check box SSL Server para configurar se a conexo com o Eventum ser com
SSL (se for marcado), ou no (se for deixado desmarcado);
2. Eventum Relative URL - o endereo do Eventum, voc pode deixar o default,
ou colocar qualquer outro;
3. MySQL Server Hostname - o nome do servidor MySQL, que o mesmo do
servidor. Aqui tanto faz colocar o IP da mquina ou localhost;
4. MySQL Database - coloque o nome do banco de dados a ser criado. Ao lado,
deixe o check box Create Database marcado;
5. MySQL Table Prefix - coloque o prefixo das tabelas ou deixe o default.
Abaixo, deixe o check box Drop Tables If They Already Exist desmarcado;
6. MySQL Username - coloque o nome do usurio do banco de dados que o
root;

112
7. MySQL Password - coloque a senha do usurio root, a mesma definida na hora
da instalao. Abaixo, deixe o check box Use a Separate MySQL User for
Normal Eventum Use desmarcado;
8. Sender aqui comea a configurao do servidor SMTP, que ser usado pelo
Eventum. Recomendo utilizar o prprio servidor do Apache2Triad, o XMail.
Preencha o campo com admin@localhost que a conta padro do servidor
Xmail;
9. Hostname coloque o endereo do servidor localhost;
10. Port coloque a porta 25, que utilizada pelo XMail. Abaixo, marque a opo
Yes do combo box Requires Authentication?;
11. Username preencha novamente com a conta de e-mail admin@localhost;
12. Password coloque a senha da conta de e-mail, que a mesma do usurio root;
13. Pronto, agora s clicar no boto Start Installation.
Caso tenha ficado alguma dvida, durante a instalao do Eventum, segue abaixo, um
printscreen com configurao.

Figura 66 - Pgina de instalao do Eventum
Aps a instalao, aparecer uma pgina, na qual haver trs informaes importantes:
o link para a pgina do Eventum, o endereo de e-mail para fazer acesso, e a senha de
acesso. Lembrando que esse login poder ser alterado depois.

113

Figura 67 - Pgina aps a instalao do Eventum
Pronto, j temos o Eventum instalado. E aqui encerro a primeira parte desse tutorial. Na
prxima parte, iremos ver como realizar algumas customizaes, configuraes e fazer
uso da ferramenta. At l!

Figura 68 - Pgina de login do Eventum
Se ficou com alguma dvida, ou travou em alguma parte, deixe a sua questo nos
comentrios, pois ela poder ser a dvida de outras pessoas tambm. Sinta-se vontade!


114
7. Tutorial Eventum (parte 2)
Chegamos a segunda parte do tutorial sobre o Eventum. E tenho uma novidade: o
primeiro vdeo do QualidadeBR. Eu estava pensando, em como passar melhor as
informaes, e como nessa segunda parte do tutorial iremos aprender como trabalhar
com o Eventum. Muita coisa fica difcil de entender e de explicar, usando apenas o
texto. Portanto, espero que o vdeo possa ajudar voc, caro leitor(a), e complementar
este tutorial.
Bem, agora hora da ao. Mos a obra!
Menu principal
A interface do Eventum bem simples. Logo na pgina principal, j podemos ver quais
so as funcionalidades principais.

Figura 69 - Pgina principal do Eventum
Administration - clicando aqui, voc ir para a pgina de administrao do
Eventum, que ser melhor detalhada mais abaixo;
Create Issue - neste link que voc clicar quando for cadastrar uma issue, ou
seja, o problema/bug;
List Issues - opo de listagem das issues j existentes, tambm permite a busca
e a ordenao das issues por vrios parmetros;
Advanced Search - abrir a busca avanada, permitindo uma busca bem
detalhada e por diferentes parmetros. Voc ainda pode salvar as suas buscas;
Associate Emails - til para a associao manual de issues com os e-mails dos
responsveis;
My Assignments - apresenta as issues que esto designadas ao usurio logado;
Stats - apresenta uma srie de grficos sobre as issues do projeto;
Reports - fornece uma boa quantidade de relatrios, baseados nas issues do
projeto;

115
Internal FAQ - um FAQ interno apresentado, sendo que este necessita ser
criado antes na parte de administrao;
Help - a ajuda do Eventum, que fornecer uma boa noo da ferramenta.
Administrao
Agora veremos uma das principais pginas do Eventum, a de administrao. O meu
intuito apresentar as principais funcionalidades, no ter como falar de todas por dois
motivos: h muitas opes, o que resultaria quase num livro; e o no uso de boa parte
das funcionalidades, o famoso pareto (onde 20% do software mais usado).
Para acessar a pgina de administrao, basta clicar sobre o link Administration .

Figura 70 - Pgina de administrao do Eventum
Toda a navegao pelas opes ocorre na parte da esquerda da pgina, onde elas esto
listadas. Na parte direita, feita toda edio da configurao desejada. As principais
configuraes so:
General Setup aqui voc poder mudar as configuraes de envio de e-mail,
aquelas que voc fez na instalao, podero ser alteradas aqui. H ainda a opo
de configurao de outras funcionalidades, como as dicas dirias (Daily Tips) e a
integrao SCM (Source Code Management - Sistema de Controle de Verso),
sendo que o Eventum suporta o CVS e o Subversion (mais detalhes);

116

Figura 71 - Pgina de configurao do Eventum

117
Manage Custom Fields onde voc poder criar os seus campos
customizveis, definindo: seu nome (Title), descrio (Short Description),
projetos onde sero usados (Assigned Projects), em qual formulrio sero usados
(Target Forms), se ser ou no mostrado na lista de issues (Display on List
Issues Page), o tipo do campo (Field Type), as opes do campo (Field
Options), qual o papel mnimo de usurio que poder visualizar o campo
(Minimun Role); em qual posio ele estar (Rank);

Figura 72 - Pgina de gerenciamento de campo customizado
Manage Statuses - o Eventum permite a customizao dos status, possibilitando
a criao, edio e deleo. Voc poder configurar os seguintes dados do
estado:
o Title o ttulo do seu novo status;
o Abbreviation a abreviao do seu status (trs letras);
o Rank a posio do status;
o Closed Context caso selecionada a opo Yes, o status estar presente
no formulrio de fechamento da issue, caso contrrio, ele estar no
formulrio de cadastro da issue;
o Assigned Projects em quais projetos o status estar presente;
o Color - possibilita a escolha da cor do status, sendo que ela dever estar
em HTML (tabela de cores).

118

Figura 73 - Pgina de gerenciamento dos status
Manage Projects nesta rea voc poder criar e editar os seus projetos. Na
instalao do Eventum um projeto j criado: o Default Project. Voc pode criar
e configurar os seus prprios projetos. Veremos melhor a parte de criao de
projetos mais a frente, alis, o vdeo mostra a criao de um projeto;
Manage Users no Eventum h sete nveis de usurio, sendo que o papel do
usurio est associado ao projeto, ou seja, um usurio pode exercer papeis
diferentes, dependendo de cada projeto:
o Viewer - pode visualizar todas as issues dos projetos que ele est
associado, e no pode criar ou editar issues;
o Reporter permite visualizar todas as issues associadas a ele, e tambm
criar novas issues e enviar e-mail nas issues j existentes;
o Customer - esta uma permisso reservada para uma API de integrao
com o cliente, que permite que voc integre o Eventum com a base de
dados do seu CRM. Quando esta funcionalidade est habilitada, este
papel de usurio pode acessar as issues associadas ao seu prprio cliente.
Permite a criao de issues, atualizao e envio de e-mails de issues j
existentes (mais detalhes);
o Standard User o usurio padro pode visualizar todas as issues dos
projetos que ele est associado, criar/atualizar issues, e enviar e-mail e
notas nas issues existentes;
o Developer ele parecido com o Standard User, porm ainda permite
separar os usurios que iro lidar com as issues, e a equipe de usurios
que no lidar com suas prprias issues;
o Manager permite visualizar todas as issues dos projetos que ele
associado, criar/atualizar issues e enviar e-mails e notas nas issues
existentes, Ele ainda pode, editar a rea de administrao do Eventum,
menos a rea de configurao;
o Administrator - tem acesso total ao Eventum.

119
Para criar um novo usurio, basta informar as seguintes informaes: o e-mail
do usurio (nele ser enviado o e-mail pelo Eventum), a senha, o nome, e quais
projetos que ele participar e qual ser o seu papel.

Figura 74 - Pgina de gerenciamento de usurios
Criando um projeto
Antes de comear a utilizar o Eventum pra valer necessrio criar um projeto antes. O
Eventum organizado por projeto e cada um pode ter suas caractersticas especficas.
Abaixo, explico cada um dos campos existentes no formulrio de cadastro do projeto.

120

Figura 75 - Pgina de gerenciamento de projetos
Title o nome do projeto;
Status o estado do projeto, que pode ser Active (usado na criao) ou
Archived (usado no fechamento do projeto). Como estamos criando um projeto
selecionamos a opo Active;
Customer Integration Backend rea para configurao da integrao com o
CRM, citada anteriormente. Lembrando que para utilizar essa funo
necessrio adicionar uma classe no cdigo do Eventum. Portanto, selecionamos
a opo No Customer Integration, pois no iremos usar essa funcionalidade;
Workflow Backend como o nosso projeto no tem integrao, selecionamos a
opo No Workflow Management no combo box;
Project Lead selecionamos o lder do projeto, dentre os usurios j
cadastrados. Se voc s tem o usurio Admin cadastrado, basta ir na opo
Manage Users, explicada anteriormente, e cadastra os usurios que fazem parte
do projeto. O cadastro bem simples;
Users selecionamos os usurios que participaro do projeto;
Statuses aqui escolhemos quais status sero usados no projeto;
Initial Status for New Issues quando a issue criada ela tem um status
inicial, definimos ele aqui como discovery (descoberto);
Outgoing Email Sender Name - informamos qual o nome do remetente do
envio de e-mail;
Outgoing Email Sender Address colocamos o endereo de e-mail do
remetente;

121
Remote Invocation caso habilitado (Enabled) permitir o uso de CLI pelos
desenvolvedores para ver e editar as informaes, sem o uso de navegador web
(mais detalhes). Selecionamos a opo Disabled;
Segregate Reporters opo, que caso habilitada (Yes) que permite que os
usurios com o papel Reporter sejam capaz de ver somente as issues reportadas
por eles. Selecionamos a opo Yes.
Pronto, nosso primeiro projeto est pronto, ou melhor, quase pronto. Ainda
necessitamos configurar, pelo menos, duas caractersticas do projeto (Categories e
Priorities):
Releases - onde so cadastrados as releases, usados durante o cadastro da issue,
para definir qual verso, representa o deadline para a correo da issue. Sendo
esse campo opcional;
Categories - precisamos definir as categorias do projeto, que podem ser
entendidas como os mdulos da aplicao. Por exemplo: login, cadastro de
usurios, vendas, etc. Sendo o seu cadastro requerido, pois durante o cadastro de
uma issue necessitamos informar em qual categoria o bug ocorreu;
Priorities - cadastro das prioridades. Sendo o seu cadastro requirido, pois
precisamos definir qual a prioridade da issue, durante o seu cadastro. Voc pode
usar as mesmas prioridades do Default Project ou criar as suas prprias;
Phone Support Categories - adicionar uma categoria de telefone do suporte,
que aparece na edio de uma issue, na parte Phone Calls. Geralmente, usado
apenas em equipes de Suporte. O seu cadastro opcional;
Anonymous Reporting permite o reporte Anonymous de issues, que na
verdade, possibilita que o usurio reporte uma issue sem precisa logar no
Eventum. Para isso ele precisa habilita o Anonymous Reporting e escolher o
usurio que poder fazer isso, a categoria, a prioridade e a pessoa que ser
associada issue, que ser cadastrada sem o login no Eventum. Feito isso o
usurio pode deslogar do Eventum, e na tela de login aparecer uma nota
avisando que ele poder reportar issues sem realizar o login, usando uma
determinada URL. Esta configurao opcional;

122

Figura 76 - Abaixo a opo de reportar uma issue sem logar

Figura 77 - Pgina de reporte annimo de issue
Fields to display - aqui voc pode definir quais campos podem ser visualizados,
por quais nveis de usurio. Essa configurao opcional;
Columns to display - possibilita a configurao de quais campos sero
apresentados na listagem de issues. Sendo essa configurao opcional.
Essas so as configuraes necessrias para criar um novo projeto. Agora com o seu
projeto pronto, j poderemos cadastrar a nossa primeira issue. Porm, s na prxima
parte desse tutorial, alis, ser a ltima. Onde veremos os seguintes tpicos: reporte e

123
fechamento de uma issue, criao de um campo customizado e o envio de e-mail
automtico.
Mas antes de encerrar a segunda parte, segue abaixo o vdeo que eu havia comentado no
comeo do post. Ele apresenta a criao e configurao de um novo projeto, espero que
vocs gostem. At a prxima!

Se voc quiser fazer o download do vdeo, com qualidade mxima e sem esses zooms
(tive que fazer devido a qualidade do vdeo no Youtube), segue abaixo, o link:
http://www.mediafire.com/?wdahjm3zjiy (tamanho 4,62 MB)
Fonte:
http://eventum.mysql.org/wiki/


124
8. Tutorial Eventum (parte 3)
Chegamos a terceira e ltima parte do tutorial da ferramenta bug tracking Eventum.
Nesta ltima parte, iremos aprender mais sobre a sua utilizao, vendo na prtica, por
meio de vdeos, o seu uso.

Aperte os cintos, pois a ltima parte do tutorial do Eventum ir decolar agora.

Terminamos a segunda parte do tutorial, com a criao de um projeto. Agora que j
temos o nosso prprio projeto pronto, hora de aprender como a criao de uma issue.

Mas antes de comear a criar a issue, quero frisar que o reporte de um bug uma tarefa
muito importante. O Tester deve buscar ser detalhista ao mximo, e descrever todos os
passos que foram executados para encontrar o bug. De nada adianta uma ferramenta de
bug tracking, se o reporte do bug for superficial. Devemos sempre lembrar, que um bom
gerenciamento de bugs, depende muito mais das equipes de Testes e Desenvolvimento,
do que da ferramenta propriamente dita, pois como j diria um ditado popular
americano, tolos com ferramentas ainda so tolos.
Reportando uma issue
O reporte de uma issue bem fcil de fazer no Eventum. O primeiro passo a ser dado
clicar sobre o link Create Issue, que se encontra no menu principal. A seguinte pgina
ir abrir.

Figura 78 - Pgina de reporte de issue
Category - aqui sero listadas as categorias criadas anteriormente. Selecione a
categoria na qual o bug foi encontrado;

125
Priority - defina qual a prioridade do bug;
Assignment - selecione os responsveis pela issue, lembrando que eles iro
receber um e-mail, de notificao do cadastro da issue;
Scheduled Release - campo opcional, usado para estimar em qual release sair a
correo;
Summary - neste campo coloca-se o ttulo da issue. Uma dica tentar se o mais
especfico possvel, pois facilitar a busca pelas issues;
Initial Description - aqui voc ir descrever a issue, costuma- se colocar os
seguintes dados, quando necessrios: pr-condio, cenrio (o passo a passo),
resultado invlido, resultado esperado e observaes;
Estimated Dev. Time - campo opcional, usado para estimar as horas de
desenvolvimento necessrias para a correo da issue;
Private - caso marcado Yes os usurios com papel Reporter no iro ver a
issue;
Files - voc pode fazer o upload de algum arquivo que prove a ocorrncia do
bug, por exemplo, um printscreen.
Se aps a criao da issue, houver a necessidade de colocar alguma nova informao,
podemos fazer essa adio de duas maneiras: atualizando a issue ou colocando um Post
Internal Note. A primeira usada mais, quando alguma informao cadastrada foi
colocada incorretamente, e a segunda maneira serve para fazer algum comentrio sobre
a issue, como por exemplo: O bug continua ocorrendo na verso X.
Fechando uma issue
O melhor momento esse, e se o cadastro de uma issue j foi fcil, o fechamento dela
mais ainda. preciso ir na pgina da issue. Nela h um boto chamado Close Issue,
clicamos nele. A pgina seguinte ir aparecer.

Figura 79 - Pgina de fechamento de issue

126
Status informe qual o status do fechamento. Lembrando que voc pode
cadastrar os seus prprios status na pgina de administrao;
Resolution - selecione qual foi a resoluo tomada para a soluo da issue;
Send Notification About Issue Being Closed - boas notcias so sempre bem-
vindas, portanto escolha a opo Yes para avisar a todos sobre o fechamento
da Issue;
Send Notification To - aqui voc pode definir se todos iro receber a
notificao, ou apenas os responsveis pela issue;
Reason for closing issue - descreva qual foi a razo do fechamento da issue;
Time Spent - campo opcional, usado para colocar o tempo que foi gasto na
resoluo da issue;
Time Category - campo opcional, para informar onde foi gasto o tempo para
solucionar a issue.
Abaixo, se encontra um vdeo mostrando a criao e o fechamento de uma issue:

Para o download do vdeo com qualidade mxima, clique no link abaixo:
http://www.mediafire.com/?yz25t0zuiwn (6,49 MB)
Criao de um campo customizado
Um dos diferenciais do Eventum a possibilidade de criar um campo customizado, pois
muitas vezes, h alguma informao especfica de um projeto, que precisa ser colocada
na issue, e acabamos colocando no campo de descrio, o que no a soluo ideal.
Para criar um campo customizado necessrio est logado com um usurio
Administrator, e clicar sobre o link Administration. Na pgina de administrao
clicamos sobre o link Manage Custom Fields que se encontra na parte de
Configuration. A pgina abaixo, ir aparecer.

127

Figura 80 - Gerenciamento de campos customizados
Na criao do campo customizado, precisamos preencher os seguintes campos:
Title - defina um nome para o seu campo;
Short Description - defina uma descrio breve do campo, ela ficar localizada
ao lado do campo;
Assigned Projects - escolha em quais projetos esse campo customizado estar
presente;
Target Forms - defina em qual parte do formulrio o campo estar e se ele ser
ou no obrigatrio:
o Report Form - no formulrio de criao da issue;
o Anonymous Form - no formulrio de anonymous, que aquele que
vimos na segunda parte do tutorial;
o Close Form - ou no formulrio de fechamento da issue.
Display on List Issues Page - se ele aparecer ou no na listagem de issues;
Field Type - qual ser o tipo do campo;
Field Options - dependendo do tipo do campo escolhido, ser necessrio
preencher os dados desse campo;
Minimum Role - a partir de qual tipo de usurio, o campo poder ser visto;
Rank - em qual posio o campo customizado estar, perante os demais campos
customizados.
Caso tenha ficado alguma dvida, durante a criao do campo customizado, confira a
criao de um campo customizado, no vdeo abaixo:

128

Para o download do vdeo com qualidade mxima, clique no link abaixo:
http://www.mediafire.com/?ukmyvaycymh (2,4 MB)
Envio de e-mail automtico
Antes de ver como configurar o envio de e-mail automtico, bom saber que para o
usurio receber o e-mail, ele precisa habilitar essa opo, nas suas preferncias. Para
isso v em Preferences, ao lado do nome do usurio. Na nova pgina precisamos
marcar a opo Yes para as perguntas: Receive emails when all issues are created e
Receive emails when new issues are assigned to you. Infelizmente, sempre que voc
criar um projeto novo, os usurios que participaro do projeto, estaram configurados
para no receber os e-mails. Eu ainda no encontrei um meio menos macaco, para a
soluo desse problema. At perguntei no frum da MySQL, mas por enquanto nada.
Um meio de contornar esse problema, enviar um e-mail para todos os usurios do
projeto, pedindo a configurao para o recebimento de e-mail do projeto criado no
Eventum.
Outra notcia ruim: o Eventum no tem suporte a servidores SMTP usando SSL, ou
seja, a maioria dos servidores que poderamos usar (como o Gmail), no podero ser
usados. Mas agora uma notcia boa: ns temos o nosso prprio servidor SMTP, o
XMail, que configuramos na primeira parte deste tutorial, durante a instalao do
Eventum.
Bem, vamos para a configurao do envio de e-mail automtico. Voc pode est se
perguntando: o Eventum j no manda e-mail automaticamente? E a resposta no.
Para o Eventum enviar os e-mails preciso executar um script o
process_mail_queue.php (que se encontra na pasta misc). No linux voc pode usar o
Cron, para fazer essa tarefa. E no Windows, precisamos usar o agendador de tarefas.
Abaixo, segue o passo a passo, para a criao da tarefa agendada no Windows. V em:
Iniciar > Todos os programas > Acessrios > Ferramentas do Sistema > Tarefas
agendadas. A seguinte tela abrir.

129

Figura 81 - Tarefas agendadas do Windows
Na nova tela, clique sobre a opo Adicionar tarefa agendada e na tela que abrir
clique sobre o boto Avanar. Depois selecione o navegador, de sua preferncia, para
executar a tarefa, e clique em Avanar.

Figura 82 - Criao da tarefa agendada

130
Agora informe o nome da tarefa e selecione a opo Diariamente, para que a tarefa
seja executada todos os dias.

Figura 83 - Informe quando a tarefa vai ser executada
Na prxima tela, coloque o horrio de incio da tarefa, selecione a opo Todos os dias
e clique no boto Avanar.

Figura 84 - Informe o incio da tarefa
Agora informe a senha do usurio que executar a tarefa.

131

Figura 85 - Informe os dados de login para que a tarefa seja realizada
Antes de concluir a tarefa, marque o check box, pois ser necessrio configurar algumas
opes da tarefa. Marcado o check box, clique no boto Concluir.

Figura 86 - Visualizao dos dados da tarefa agendada
Agora estamos nas propriedades da tarefa. Na primeira aba Tarefa acrescente
localhost/eventum-2.1.1/misc/process_mail_queue.php (com as aspas mesmo), ao
comando. Ficar assim o comando no campo Executar:
C:\ARQUIV~1\MOZILL~1\firefox.exe http://localhost/eventum-

132
2.1.1/misc/process_mail_queue.php. Ou seja: Endereo do navegador [espao]
endereo do script entre aspas.

Figura 87 - Edio da tarefa agendada
Agora v na aba Agendar e clique sobre o boto Avanado. Aqui marcamos o check
box Repetir a tarefa. Definimos o intervalo de tempo que ela ser repetida, colocando
5 minutos, e at que horas ela ser executada, at s 23:59. Por fim, marcamos o check
box Se a tarefa estiver em execuo, interromp-la nesta hora., e clicamos no boto
Ok.

133

Figura 88 - Opes avanadas de agendamento
Vamos agora na aba Configuraes e marcamos apenas o check box Interromper a
tarefa se ela for executada por, configurando em 2 minutos.

Figura 89 - Configuraes da tarefa agendada

134
Depois clique sobre o boto Aplicar. Uma nova tela abrir, pedindo a sua senha e
confirmao da mesma. Pronto, j temos nossa tarefa agendada concluda corretamente.

Figura 90 - Visualizao da tarefa agendada
A tarefa criada ir executar o script do Eventum, para envio dos e-mails, a cada 5
minutos. Portanto, aps a criao de uma issue, o e-mail ser enviado no tempo mximo
de 5 minutos. Para verificar se o e-mail foi enviado com sucesso, v na pgina da issue
que se deseja consultar, e clique sobre o link Mail Queue Log (localizado na parte
inferior direita da pgina).

135

Figura 91 - Link para visualizar o status do envio de e-mail
Uma nova pgina abrir mostrando o status do envio do e-mail.

Figura 92 - Visualizao do status do envio de e-mail da issue
Aqui encerro a terceira e ltima parte do tutorial sobre o Eventum. Espero que ele possa
ajud-lo(a), caro leitor(a). Qualquer dvida, crtica, ou sugesto, sinta-se vontade em
colocar nos comentrios. At a prxima!



136
Saiba mais
Quem quiser conhecer mais sobre a ferramenta, recomendo a wiki do Eventum. Caso
tenha algum problema ou dvida, tambm h o frum da MySQL, o FAQ, a lista de
discusso, e o QualidadeBR (hehehe).


137
Certificaes
Certificaes

138
1. Certificao Brasileira de Teste de Software
(CBTS)
Pessoal, aps ter conseguido a CBTS elaborei um breve FAQ para a empresa onde
trabalho a respeito da certificao. Agora disponibilizo vocs o mesmo, lembrando
que a prxima prova tem data prevista para o dia 29 de Novembro de 2008. Boa sorte a
todos!
O que visa a CBTS?
A CBTS visa atender a uma exigncia do mercado brasileiro que sempre demandou um
processo de certificao e qualificao de profissionais em teste de software. A CBTS
busca estabelecer padres para uma avaliao da qualificao dos profissionais de TI
com funes na rea de Testes.
Qual o seu pblico alvo?
O exame CTBS se destina aos profissionais de TI da rea de Desenvolvimento de
Sistemas e em especial aqueles que atuam na rea de Teste de Software, que tenham
interesse em obter um certificado de reconhecimento tcnico vlido para o mercado
brasileiro.
Qual a importncia desta certificao para o profissional?
Adquirir o certificado CBTS para o profissional da rea de Teste um grande
diferencial, pois indica que o mesmo possui um excelente nvel de competncia
profissional nos princpios e nas prticas de Teste/Qualidade de Software, dentre os
demais profissionais de TI. Tornar-se um certificado CBTS, significa tornar-se membro
de um grupo seleto de profissionais reconhecidos na rea de teste de software, e receber
este reconhecimento de sua competncia, conseguir uma ascenso potencialmente
mais rpida em sua carreira, e uma maior aceitao no mercado de TI.
Quais os benefcios para empresa ter um profissional certificado?
So atravs das certificaes, que os profissionais podem atestar seu nvel de domnio e
conhecimento de seu servio, assim como as empresas podem demonstrar que possuem
um quadro capacitado para atender as demandas com qualidade e profissionalismo.
Resultando para a empresa na melhoria de seus processos e ampliao da qualidade e
produtividade de seus servios.
Quantos profissionais atualmente possuem a CBTS?
So atualmente 201 profissionais certificados na CBTS em todo o Brasil.
Quem o responsvel pela CBTS?
A ALATS (Associao Latino-Americana de Testes de Software) a responsvel pela
CBTS. Fundada em 2002, com a misso de tornar-se uma instituio que representasse

139
de forma mais isenta e imparcial possvel, todas as empresas e profissionais que
possuam vnculo e interesse com os rumos do mercado de testes e qualidade de software
no Brasil. Desde sua fundao, um dos principais objetivos da ALATS era estabelecer
uma certificao que avaliasse o nvel de conhecimento dos profissionais sobre as
disciplinas de testes e qualidade de software, forando um processo de amadurecimento
e profissionalizao da rea de testes. Objetivo esse que deu origem a CBTS.
A ALATS uma organizao sem fins lucrativos, no possuindo nenhum vnculo direto
ou indireto com instituies privadas. Todos os trabalhos so feitos de forma voluntria,
inexistindo qualquer tipo de remunerao dos membros diretores ou participantes dos
projetos de inovao.
Qual o custo desta certificao?
O valor de R$ 300,00, para a realizao do exame de certificao. Serve para bancar
os custos relativos de viagens, hospedagens, materiais de treinamento, divulgao dos
trabalhos e despesas administrativas de divulgao da CBTS. Para a realizao do
exame, no necessrio participar de nenhum treinamento formalmente estabelecido.
Qual o critrio de aprovao?
O candidato dever obter 75% de acertos na prova para ser aprovado. Sendo a prova
constituda de 100 (cem) questes com respostas de mltipla escolha. Cada questo
proposta apresenta 4 (quatro) alternativas de resposta, sendo apenas uma delas a correta.
A certificao possui uma validade?
A certificao CBTS ter validade de 3 (trs) anos, que so contados a partir do ano
seguinte ao da realizao e aprovao no exame.
Faz-se necessrio uma re-certificao at o trmino da data de validade de 3 (trs) anos
para que o profissional permanea certificado.
Fonte:
ALATS
Artigo do Alexandre Bartie


140
2. CTFL BSTQB
Nessa semana, comecei um grupo de estudo na empresa que trabalho (Voice
Technology), para a certificao CTFL Certified Tester Foundation Level. Estamos
planejando realizar o exame, j na prxima data, que dia 03 de abril de 2009. Mas o
intuito inicial adquirir maior conhecimento na rea de Testes de Software, e aqueles
que se sentirem confiantes para realizar a prova, a sim, prestar o exame.
Para o primeiro encontro do grupo de estudo, preparei uma apresentao, que est sendo
disponibilizada abaixo, sobre a certificao CTFL BSTQB. A diante, explicarei um
pouco mais sobre a certificao.
Apresentao disponibilizada no SlideShare.

BSTQB
O BSTQB - Brazilian Software Testing Qualifications Board um representante oficial
do ISTQB - International Software Testing Qualifications Board, no Brasil. Ele um o
responsvel pela aplicao do exame para a certificao CTFL. A sua misso :
promover o profissionalismo na rea e o reconhecimento da disciplina teste e qualidade
de software como uma essncia de conhecimento e uma especializao profissional no
Brasil. O BSTQB uma entidade sem fins lucrativos
CTFL
uma das certificaes de Teste de Software mais reconhecidas, tanto no Brasil como
no mundo. Atualmente j so cerca de 32.000 profissionais certificados no mundo.

141
Ela voltada para qualquer pessoa envolvida em teste de software. Isto inclui pessoas
em funes especficas de teste como: testadores, analistas, engenheiros, consultores,
gerentes, usurios que realizam teste de aceite e desenvolvedores de software.
Os objetivos da CTFL BSTQB so esses:
Estar apto a comparar a prtica do teste entre os diferentes pases.
Capacitar os testadores a trocar conhecimento mais facilmente entre as
comisses.
Permitir com que projetos multinacionais/internacionais tenham uma
compreenso comum do empreendimento do teste.
Aumentar o nmero de testadores qualificados ao redor do mundo.
Ter mais impacto como uma iniciativa baseada internacionalmente do que
qualquer abordagem de um pas especfico.
Desenvolver um corpo comum internacional de compreenso e conhecimento
sobre teste e terminologias atravs do Syllabus e aumentar o nvel de
conhecimento sobre teste para todos os participantes.
Promover o teste como uma profisso em mais pases.
Capacitar testadores a obter qualificao reconhecida na sua linguagem nativa.
Permitir o compartilhamento de conhecimentos e recursos entre os pases.
Prover o reconhecimento internacional de testadores e desta qualificao junto a
participao de muitos pases.
A CTFL no expira e vlida internacionalmente.
Requisitos
O nico requisito existente o interesse do candidato, em se qualificar e buscar o
aperfeioamento profissional na rea de Teste de Software. Sendo recomendvel
experincia profissional na rea.
Como se preparar?
A bibliografia recomendada :
ISTQB Glossrio de Termos de Teste (Verso 1.3 Portugus/Brasil);
Syllabus Foundation Level (em Portugus/Brasil);
Normativos ISO/IEC, IEEE, BS, DO e bibliografia citados nos 2 documentos
acima;
Foundations of Software Testing: ISTQB Certification (Dorothy Graham, Erik
van Veenendaal, Isabel Evans, Rex Black);
Software Testing Foundations: A Study Guide for the Certified Tester Exam
(Andreas Spillner, Tilo Linz, Hans Schaefer.
As pessoas que j prestaram o exame, que eu conheo, dizem que estudando bem o
Syllabus e fazendo os simulados, possvel ser aprovado no exame, caso voc j tenha
experincia na rea de Teste de Software.


142
Como fazer a inscrio para o exame?
A inscrio feita no prprio site da BSTQB. Sendo necessrio preencher um cadastro
e efetuar o pagamento de R$350,00.
O exame
O exame composto de 40 questes, com quatro alternativas cada, sendo apenas uma a
certa e com durao de 1 hora.
Conversando com o Luiz Gustavo, que certificado CTFL, ele me disse que a prova
composta por:
20 questes de nvel muito fcil abordando definies simples de conceitos,
no exige pensar, s decorar;
15 questes de nvel mdio/difcil abordando definies mais complexas de
conceitos, as quais muito provavelmente, o candidato vai ficar entre 2 opes;
5 questes de nvel muito difcil no abordando definies, e sim, problemas
que exigem pensar muito, tem pegadinhas e geralmente conflitam 2 definies,
s vezes at definies simples.
Havendo questes prticas, que trazem cenrios reais, como por exemplo, o uso da
anlise de valor de fronteira.
Para obter a certificao preciso acertar 60% das questes, ou seja, 24 questes.
Por hoje s pessoal. Bons estudos para os que vo prestar a certificao!
Fonte:
http://bstqb.org.br/


143
3. Certificao: IBM Certified Specialist
Software Quality
Pessoal,
Ontem eu recebi um e-mail, digamos que um pouco suspeito, sobre uma certificao na
rea de Qualidade de Software. Voc pode est se perguntando, por que um e-mail
sobre uma certificao pode ser suspeito?
O que eu achei suspeito foi o fato dela ser gratuita. Isso mesmo, sem nenhum custo, a
no ser o tempo de estudo e o deslocamento para o centro de treinamento que ir aplicar
o exame.
Trata-se da certificao IBM Certified Specialist Software Quality, eu mesmo
nunca tinha ouvido falar sobre tal, e o Fbio Martinho Campos, que um especialista
em certificaes de qualidade e testes, me disse, no seu grupo de discusso dedicado as
certificaes de Qualidade e Teste de Software, que ele tambm no a conhecia.
Portanto, pelo menos no Brasil, ela deve ter sido lanada agora.
Ela uma certificao voltada para desenvolvedores, testadores e profissionais em
Qualidade de Software que desejam melhorar seus conhecimentos em Qualidade de
Software, e assim desenvolver um trabalho mais eficiente.
A prova composta de 45 questes e o tempo de realizao de 1 hora e 15 minutos
(segundo a ficha de confirmao da inscrio do exame, enviada pela Prometric), no site
da IBM diz que o tempo da prova de 60 minutos. A diferena de tempo deve ser por a
prova ser em ingls, que no a nossa linguagem nativa.
Para obter a certificao preciso acerta 71% das questes, ou seja, 32 questes.
O estudo para a prova feito com base em um material de uma instituio de e-
Learning, a AzIT. O material tambm obtido, de forma gratuita no site da AzIT,
bastando fazer um simples cadastro (clicando no link Enroll).
O material disponibilizado no site est em formato de apresentao, voc pode assistir
pelo site ou baixar o arquivo do mdulo que est sendo estudado. Eu reunir todo o
material disponibilizado no site da AzIT, e estou compartilhando nos links abaixo, ele
est separado por rea de estudo, assim como est no site:
Engineering Quality in Software Development (78.27 MB)
Software Quality (56.7 MB)
Software Testing (76.96 MB)
Para fazer a inscrio do exame, basta acessar o site da Prometic, e seguir o passo a
passo:

144
1. Clicar no banner START
2. Clicar no link Schedule an Appointment
3. Selecionar no combo box Country a opo Brazil e clicar em <NEXT>
4. No list box Program selecione IBM (000,001) e clique em <NEXT>
5. <NEXT>
6. A prova 000-370 e clique em <NEXT>
7. Escolha o Test Sites mais prximo da sua casa.
8. Login e confirm process
No site da IBM h um simulado do exame, que pode ser acessado no link abaixo:
http://www14.software.ibm.com/cgi-bin/pwdown/public/httpdl/certify/sam370.pdf
Bem, na minha opinio essa uma excelente oportunidade para adquirir novos
conhecimentos, e ainda poder tirar uma certificao de uma empresa reconhecida
mundialmente, que a IBM.
Eu j marquei o meu exame para o dia 31 de maro, vou ver se consigo tirar a
certificao. Mas pelo que vi nos objetivos da certificao e pelo material fornecido pela
AzIT, a prova oferece um alto grau de dificuldade, principalmente por abordar tanto o
Teste de Software, Qualidade de Software, como o Desenvolvimento de Software.
Portanto, acredito que ser um grande desafio, e o mais importante ser adquirir novos
conhecimentos e poder coloc-los em prtica.
Quem ficou interessado em fazer o exame, melhor correr, pois a gratuidade do exame
somente por um tempo determinado, no sei at quando. Como pode ser conferido no
texto abaixo, retirado do site da AzIT:
Information about the Test:
Cost of the exam: $0 (The test fee is waived for US Citizens during the grant
period. If you are taking the test outside of the US Check with your local
Authorized Prometric test center for testing fees.)
Saiba mais:
Pgina oficial da certificao
Fonte:
http://www-03.ibm.com/certify/tests/ovr370.shtml
http://br.groups.yahoo.com/group/certificacoesqualidadetestedesoftware/


145
4. QAMP (Quality Assurance Management
Professional)
A QAMP (Quality Assurance Management Professional) uma nova certificao de
Teste e Qualidade de Software, criada em 2008 pelo iSQI.
O seu foco est em aperfeioar os profissionais da rea, de acordo com as necessidades
do mercado de TI. Sendo direcionada para os gestores de qualidade, pois eles
necessitam ter competncia em todo o processo de desenvolvimento.
Para a sua obteno o candidato precisa completar 4 passos:
1. O primeiro obter CPRE (Certified Professional for Requirements Engineering)
Foundation Level, oferecida pela IREB;
2. O prximo passo obter a CTFL, oferecida pelo ISTQB, e aqui no Brasil pela
BSTQB;
3. O terceiro passo obter uma certificao especfica na rea de Testes de
Software, podendo ser uma das seguintes: iSAQB Certied Professional for
Software Architecture; iSTQB Certied Tester Advanced Level Test
Manager; iNTCCM International Certied Conguration Manager; iSQI
Certied Professional for Project Manager; iSQI Certied Professional for IT
Security Management.
4. E o ltimo passo comprovar pelo menos 2 anos de experincia na rea.

Segundo Stephan Goericke, diretor do iSQI e idealizador da QAMP, A QAMP ir
prover uma certificao modular que cobrir os gaps existentes entre o analista de
negcio e os executores de teste. Alm disso, a experincia em projetos tambm
reconhecida e de avaliao independente.
Os profissionais certificados QAMP demonstram conhecimento na coleta de requisitos,
teste de software e gerenciamento do teste. E este conhecimento est adequado com os
padres adotados por vrias instituies de certificao, como por exemplo: a
International Software Testing Qualifications Board (ISTQB), que hoje possuem mais
de 100 mil profissionais certificados.

146
A QAMP no est disponvel no Brasil, at porque os exames avanados de Teste de
Software, como o CTAL (Certified Tester Advanced Level) da ISTQB, no so
aplicados no Brasil. Portanto, se algum tiver interesse em tirar tais certificaes, s
indo para fora do pas mesmo.
Apresentao disponibilizada no SlideShare.

Quem quiser saber mais sobre a QAMP, confire a apresentao abaixo, ou acesse o site
oficial da QAMP.
Fonte:
News. Industry Leaders Announce New Software Quality Testing Certification. Testing
Experience The Magazine for Professional Testers, Alemanha, Ano1, n4, p. 7,
dezembro, 2008
http://www.qamp.org


147
5. Simulados CTFL-BSTQB
Algo que ajuda muito, na preparao para certificaes a realizao de simulados. E
como disse aqui, montei um grupo de estudo na empresa que trabalho, para a
certificao CTFL-BSTQB.
No comeo dos estudos, todos me perguntavam se eu tinha algum simulado, e eu s
tinha os do grupo do BSTQB, at o momento que entrei em contato com o Luiz
Gustavo, que j obteve a certificao, e me passou uma porrada de simulados (alis,
muito obrigado!). Porm, eles estavam em ingls e como nem todos tm facilidade com
o idioma e a prova aplicada pela BSTQB em portugus, resolvi traduzir esses
simulados.
Bem, chega de conversa, e vamos ao que interessa, os simulados. Segue abaixo, o link
para download dos simulados traduzidos e dos originais em ingls:
http://www.mediafire.com/file/ohy4jdwxijw/Simulados_CTFL-BSTQB.zip
http://www.mediafire.com/file/ejiyunzujvi/Simulados (originais).zip
So 5 simulados traduzidos, dois com 20 questes e trs com 40 questes, que a
quantidade de questes da prova oficial. Ou seja, no total so 160 questes.
J os simulados originais (em ingls) tm 27 questes a mais, por ter algumas repetidas
e outras um pouco estranhas, que preferi no traduzir.
Caso algum encontre algum erro nos simulados, por favor reporte para meu e-mail
(ffc.fabricio@gmail.com.br). E se tiverem alguma dvida, sugesto ou crtica, sintam-se
vontade em comentar.
Espero que os simulados ajudem nos estudos e na futura obteno da certificao.
Bons estudos a todos!


148
6. Resoluo de questes CTFL: Q1S1
Durante os estudos para a CTFL (Certified Tester Foundation Level), algumas
questes dos simulados geraram dvidas, tanto para mim, quanto para outras pessoas,
que at entraram em contato comigo perguntando sobre a resoluo de tais.
Pensando no alto grau de dificuldade que muitas questes trazem, e que em muitas
vezes apenas engolimos a resposta, e no entendemos o motivo dela. Vou fazer uma
srie de posts, com a resoluo das questes que achei mais complicadas e tambm que
outras pessoas acharam.
E para comear vamos ver a resoluo da primeira questo do simulado 1 (Q1S1), uma
questo que no to difcil, mas que pode gerar dvida:
Um campo de entrada (input field) referente ao ano de aniversrio aceita valores
de 1900 at 2004. Utilizando a anlise do valor limite o teste usaria quais valores?
a) 0,1900,2004,2005
b) 1900, 2004
c) 1899,1900,2004,2005
d) 1899, 1900, 1901,2003,2004,2005
Analisando o enunciado da questo
O campo aceita valores entre 1900 e 2004. E temos que usar a anlise do valor limite
para determinar os valores que usaremos no teste.
Resoluo
A tcnica de anlise de valor limite faz uso dos valores: mnimo invlido, mnimo
vlido, mximo vlido e mximo invlido. Portanto, teremos que ter quatro valores para
o teste. Ento j eliminamos duas alternativas: b e d
Agora que surge a dvida
Alternativa a
0 = valor mnimo invlido
1900 = valor mnimo vlido
2004 = valor mximo vlido
2005 = valor mximo invlido
Alternativa c

149
1899 = valor mnimo invlido
1900 = valor mnimo vlido
2004 = valor mximo vlido
2005 = valor mximo invlido
Agora voc pode est pensando: Ento temos duas alternativas corretas?
No, pois a anlise do valor limite, como o prprio nome j sugere, est interessada nos
valores limites.
Hmmm, j sei! O 0 no um valor limite.
Perfeito! isso mesmo! O 0 um valor mnimo invlido, porm est bem abaixo do
limite mnimo.
Resposta
Alternativa: c) 1899,1900,2004,2005
Se voc achou alguma questo difcil ou no clara, e gostaria que eu colocasse aqui, s
fazer um comentrio. Que iremos discutir sobre ela.
Ahhse a explicao estiver confusa ou no for suficiente para o entendimento, sinta-
se vontade em comentar.
At a prxima!


150
7. Resoluo de questes CTFL: Q13S1
Acredito que a grande dificuldade desta questo o desconhecimento da complexidade
ciclomtica de McCabe, eu mesmo no fazia a menor idia do que era, antes de ver essa
questo. E o pior de tudo que o Syllabus no fala dela, e o mximo que podemos
encontrar no material sedido pela BSTQB a sua definio no ISTQB Glossrio de
Termos de Teste.
Mas o intuito do post no explicar a complexidade ciclomtica de McCabe, e sim
apresentar a resoluo da questo 13 do simulado 1. Quem quiser entender melhor a
complexidade ciclomtica, recomendo os seguintes links abaixo:
http://logbr.reflectivesurface.com/2008/11/12/conceitos-de-programacao-complexidade-
ciclomatica/
http://www.antoniopassos.pro.br/blog/?p=347
http://en.wikipedia.org/wiki/Cyclomatic_complexity
Agora vamos para a questo
Dado o seguinte programa:
1 IF X < Y
2 THEN Statement 1;
3 ELSE IF Y >= Z
4 THEN Statement 2;
5 END
A complexidade ciclomtica de McCabe :
a) 2
b) 3
c) 4
d) 5
Anlise do cdigo
Temos dois IFs, sendo que o segundo dependente do primeiro, ou seja, a sua execuo
depende do resultado do primeiro IF, pois o segundo IF est associado ao ELSE do
primeiro IF.

151
Acredito que essa histria de primeiro e segundo IF, pode ter te deixado confuso
querido(a) leitor(a). Ento, vamos facilitar as coisas, abaixo segue o fluxo do cdigo da
questo:

Figura 93 - Ilustrao do fluxo
Resoluo
Temos duas maneiras de resolver essa questo: fazendo o fluxo com os caminhos
lgicos possveis (parecido com a figura acima), ou usando a frmula da complexidade
ciclomtica.
Vamos primeiro para a maneira mais difcil, usando a frmula:
M = E N + 2P
M= complexidade ciclomtica
E= nmero de arestas (linhas/caminhos)
N= nmero de nodos
P= nmero de componentes conectados
M= 6 5 + 2X1
M= 1 + 2
M =3
Portanto j sabemos que a complexidade ciclomtica igual a 3.

152
Agora vamos resolver essa mesma questo, de uma maneira mais simples e fcil:

Figura 94 - Ilustrao do fluxo
Sabendo que a complexidade ciclomtica medi o nmero de caminhos de uma
determinada funo. Fica claro na figura acima, que o cdigo apresentado tem 3
caminhos lgicos possveis:
Verde: X menor que Y > executar o Statement 1 > END
Azul: X maior que Y > Y menos que Z > END
Vermelho: X maior que Y > Y maior igual que Z > THEN Statement 2 > END
E o motivo por eu achar a segunda maneira mais fcil simples: eu dificilmente foi
lembrar da frmula da complexidade ciclomtica na hora da prova. E como tenho
certeza que a pessoa que ir aplicar o exame no ir colocar a frmula na lousa (como
nos tempos de escola), prefiro fazer o fluxo do cdigo, afinal no vou esquecer de como
faz crculos e retas, durante a prova.
Logicamente essa minha opinio, se voc acha melhor resolver usando a frmula, tudo
bem.




153
Resposta
Alternativa: b) 3
Por hoje s pessoal. No prximo post irei resolver a questo 5 do simulado 2, a que o
Clauriston comentou no post anterior. At l!


154
8. Resoluo de questes CTFL: Q5S2
Nossa! Como est questo meu deu dor de cabea. Primeiro por culpa minha mesmo, de
ter errado na traduo: me esqueci da palavra vlidas no enunciado, o que acabou
tornando a questo bem confusa.
E depois, quando parecia tudo est resolvido, o leitor Antonio Moraes fez uma
excelente pergunta no post sobre a Q1S1. Segue ela abaixo:
[...] de acordo com a correta traduo da questo 5 do simulado 2, a alternativa correta
no seria a D. No entendi o porque do valor 50.000 precisar ser testado.
Voc tem idia?
Da resolvi me interessar (como j diria um amigo meu) e entender melhor a questo. E
encontrei uma grave inconsistncia na questo:
A traduo foi feita com base em um simulado com 5 alternativas (2.PracticeExam1
(English) Q40), que dava como correta a alternativa C, porm a C est assim nesse
simulado: c) 10000, 50000, 9999
O que est incorreto pois 9999 um valor invlido e desta maneira a alternativa estaria
incorreta. Ento pesquisei pela questo original na internet e encontrei a mesma questo
(fonte), com a alternativa C com os valores: 10.000, 50.000, 99.999
A primeira coisa que fiz foi arrumar esse erro na traduo. Porm, novamente cometi
mais um erro, no prestei ateno que o simulado que eu me baseei tinha 5 alternativas
e uma delas com uma alternativa mais correta do que a alternativa C. A alternativa D.
E aps de at ter mudado o simulado. Em uma discuso no grupo DFTestes, onde o
pessoal disse que a alternativa correta a C e no a D. Parei novamente, li e reli a
questo original e a traduzida, e percebi que realmente a C a alternativa correta. E um
dos motivos para a minha confuso foi que a traduo, ainda no estava to parecida
quanto a questo original, ento dei uma melhora na traduo para deixar mais parecida
com a original e tambm entendvel em portugus.
Bem, segue abaixo a questo e a resoluo desta questo que gerou tanta discusso e
confuso.
Questo
O nmero em um sistema de controle de estoque pode variar entre 10.000 e
99.999 inclusive. Quais das seguintes entradas poderiam ser o resultado da modelagem
de teste usando apenas classes de equivalncias vlidas e limites vlidos?
a) 1.000, 5.000, 99.999
b) 9.999, 50.000, 100.000
c) 10.000, 50.000, 99.999

155
d) 10.000, 99.999
e) 9.999, 10.000, 50.000, 99.999, 100.000
Analisando o enunciado da questo
Pede-se apenas os valores vlidos e usando as tcnicas de classe de equivalncia e de
valores limites.
Resoluo
Seguindo as tcnicas propostas:
Tcnica de classe de equivalncia temos 3 parties:
Invlida mnima = valores menores que 10.000;
Vlida = valores entre 10.000 e 99.999;
Invlida mxima = valores maiores que 99.999.
Tcnica de valores limites temos 4 limites a serem verificados:
Invlido mnimo = 9.999;
Vlido mnimo = 10.000;
Vlido mximo = 99.999;
Invlido mximo = 100.000.
E como a questo pede somente os valores vlidos, chegamos aos seguintes valores:
10.000, 50.000 e 99.999
Da voc pode me perguntar: O 50.000 no necessrio, pois o 10.000 e o 99.999 j
fazem parte da classe de equivalncia vlida.
Bem esse foi o pensamento que tive, quando acreditei que a alternativa D estava correta.
Mas, prestando mais ateno percebi que a questo pede para usar a tcnica de classe de
equivalncia e de valores limites, e apenas valores que caracterizem o uso de cada uma
delas, lembrando que esses valores precisam ser de classes e limites vlidos.
Portanto a alternativa C a correta. Pois:
10.000 = limite mnimo vlido
50.000 = valor da classe de equivalncia vlida
99.999 = limite mximo vlido
Desta maneira estamos claramente usando as duas tcnicas.



156
Resposta
Alternativa: c) 10.000, 50.000, 99.999
Eu j atualizei o simulado 2, com est correo. Quem quiser baix-lo ele est sendo
disponibilizado no link abaixo:
http://www.mediafire.com/file/ohy4jdwxijw/Simulados_CTFL-BSTQB.zip
Peo desculpas, por mais esse erro.
At mais!


157
9. Resoluo de questes CTFL: Q12S2
Dois dos assuntos que mais apresentam dificuldade so os de cobertura de sentena
(comando) e desvio. E acredito que o motivo que ns (da rea de Teste e Qualidade de
Software), na maioria das vezes no somos os responsveis por usar tais coberturas. E
sim os desenvolvedores, j que elas so tcnicas baseadas em estrutura.
Irei apresentar a resoluo da questo 12 do simulado 2, e em outros posts tambm
abordarei as questes 13, 14 e 15 deste mesmo simulado, que tambm falam sobre
cobertura de sentena (comando) e desvio.
Questo
Dado o seguinte cdigo, o que verdadeiro sobre o nmero mnimo de casos de
teste necessrios para uma total cobertura de sentena (comando) e desvio:
1. Read P
2. Read Q
3. IF P+Q > 100 THEN
4. Print Large
5. ENDIF
6. If P > 50 THEN
7. Print P Large
8. ENDIF
a) 1 teste de cobertura de sentena (comando), 3 para a cobertura de desvio
b) 1 teste de cobertura de sentena (comando), 2 para a cobertura de desvio
c) 1 teste cobertura de sentena (comando), 1 para a cobertura de desvio
d) 2 testes de cobertura de sentena (comando), 3 para a cobertura de desvio
e) 2 testes de cobertura de sentena (comando), 2 para a cobertura de desvio
Anlise do cdigo
Temos dois IFs, e um detalhe importante: so dois IFs independentes, ou seja, o
resultado do primeiro IF no impacta no segundo IF.
Resoluo
Antes de ir para resoluo propriamente dita, bom lembrar dos conceitos de cobertura
de sentena (comando) e da cobertura de desvio:
Cobertura de sentena (comando) = est associada a quantidade de linhas do cdigo
que est sendo testada
Cobertura de desvio = est associada a quantidade de desvios que so testados, o que
inclui fazer o teste da sada verdadeira e falsa de um desvio (desvio = IF, CASE,
SWITCH, WHILE, etc)
Agora vamos para a resoluo, usando as duas tcnicas:

158
Sentena (comando)
Com um nico teste podemos alcanar a cobertura total de sentena, por exemplo:
P = 100
Q = 1
Iremos passar pelos dois IFs. Logo cobrimos todas as sentenas: 1,2,3,4,5,6,7,8.
Desvio
J para alcanar a cobertura total de desvio precisamos de dois testes: um que passe
pelos dois IFs e outro que no passe por eles, por exemplo:
Teste 1
P = 100
Q = 1
Com estes valores de entrada, iremos passar pelo primeiro IF e tambm pelo segundo.
Teste 2
P = 50
Q = 1
Com estes valores de entrada, no iremos passar pelo primeiro IF e nem pelo segundo.
Detalhe da questo: No enunciado da questo pede-se o nmero mnimo de casos de
teste.
Resposta
Alternativa: b) 1 teste de cobertura de sentena (comando), 2 para a cobertura de
desvio


159
10. Resoluo de questes CTFL: Q14S1
Voltando ao simulado 1. Vamos ver a questo de nmero 14.
Questo
Quantos casos de testes so necessrios para cobrir todas as possibilidades de
declaraes (caminhos) para o seguinte fragmento de cdigo? Supondo que as
duas
condies so independentes entre elas.

1. if (Condition 1)
2. then statement 1
3. else statement 2
4. fi
5. if (Condition 2)
6. then statement 3
7. fi

a) 2
b) 3
c) 4
d) No h como estimar
Anlise
A questo pede o total de testes para cobrir todas as possibilidades de declaraes
(caminhos), ou seja, pede-se a cobertura de cobertura de caminho.
Quanto ao cdigo, podemos perceber que h dois IFs independentes, como o prprio
enunciado j fala.
Resoluo
A melhor maneira de resolver essa questo fazendo o fluxo do cdigo para pode
visualizar os caminhos existentes:

160

Figura 95 - Ilustrao do fluxo
Olhando a figura acima, podemos visualizar que h 4 caminhos possveis:
Azul: Condition 1 verdadeira > executa o statement 1 > Condition 2 falsa > finaliza
Preto: Condition 1 verdadeira > executa o statement 1 > Condition 2
verdadeira>executa o statement 3 > finaliza
Vermelho: Condition 1 falsa> executa o statement 2 > Condition 2 verdadeira>
executa o statement 3 > finaliza
Verde: Condition 1 falsa > executa o statement 2 > Condition 2 falsa > finaliza
Resposta
Alternativa: c) 4

161
11. Resoluo de questes CTFL: Q13S2
Retomando o simulado 2. Vamos resolver a questo 13, que bem simples, comparada
as demais apresentadas anteriormente.
Questo
Dado o seguinte cdigo:
1. Switch PC on
2. Start outlook
3. IF outlook appears THEN
4. Send an email
5. Close Outlook
6. ENDIF
a) 1 teste de cobertura de sentena (comando), 1 para a cobertura de desvio
b) 1 teste de cobertura de sentena (comando), 2 para a cobertura de desvio
c) 1 teste de cobertura de sentena (comando), 3 para a cobertura de desvio
d) 2 testes de cobertura de sentena (comando), 2 para a cobertura de desvio
e) 2 testes de cobertura de sentena (comando), 3 para a cobertura de desvio
Anlise do cdigo
Temos apenas um IF. Ou seja, mamo com acar.
Resoluo
Para alcanar a cobertura de sentena precisamos de apenas um teste, no qual iremos
passar pelo IF. Ou seja, o outlook ir aparecer e executaremos as linhas 4 e 5,
juntamente com as demais.
J para alcanar a cobertura de desvio precisamos de dois testes, um que passe pelo IF
e outro que no passe. Ou seja, num teste o outlook ir aparecer e no outro no.
No falei que seria fcil.
Resposta
Alternativa: b) 1 teste de cobertura de sentena (comando), 2 para a cobertura de
desvio


162
12. Resoluo de questes CTFL: Q14S2
Essa uma questo casca grossa. E a principal razo para eu dizer isso, que ela quebra
uma regra que eu tinha: o nmero de testes para garantir a cobertura de desvio ser
sempre maior que o nmero de testes para garantir a cobertura de sentena.
Questo
Dado o seguinte cdigo, qual a alternativa verdadeira:
1. IF A > B THEN
2. C = A B
3. ELSE
4. C = A + B
5. ENDIF
6. Read D
7. IF C = D Then
8. Print Error
9. ENDIF
a) 1 teste de cobertura de sentena (comando), 3 para a cobertura de desvio
b) 2 testes de cobertura de sentena (comando), 2 para a cobertura de desvio
c) 2 testes de cobertura de sentena (comando), 3 para a cobertura de desvio
d) 3 testes de cobertura de sentena (comando), 3 para a cobertura de desvio
e) 3 testes de cobertura de sentena (comando), 2 para a cobertura de desvio
Anlise do cdigo
Temos dois IFs independentes, sendo que o primeiro IF tem um ELSE.
Resoluo
Cobertura de sentena
Com um nico teste poderamos garantir quase toda a cobertura de sentena, por
exemplo:
Teste 1
A = 20
B = 10
C = ser 10
D = 10
Com o teste 1 iremos passar pelo primeiro e segundo IF, porm, no iremos passar pelo
ELSE. Portanto precisamos de mais um teste:
Teste 2

163
A = 0
B = 10
C = ser 10 (o valor de C nem interessa nesse teste)
D = 9 (o valor de D nem interessa nesse teste)
Com o teste 2 passamos pelo ELSE, porque A igual a B e nos levar a linha 4, a nica
pela qual no tnhamos passado.
Cobertura de desvio
Podemos usar os mesmos testes feitos na cobertura de sentena. Mas com uma
diferena: no teste 2, os valores de C e D nos interessam, pois iro cobrir o resultado
falso (a no passagem) do segundo IF.
Portanto, com apenas dois testes tambm alcanamos a cobertura de desvio.
Resposta
Alternativa: b) 2 testes de cobertura de sentena (comando), 2 para a cobertura de
desvio
Dica
Adaptando a minha regra inicial: o nmero de testes para garantir a cobertura de desvio,
na maioria das vezes, ser maior que o nmero de testes para garantir a cobertura de
sentena.


164
13. Resoluo de questes CTFL: Q15S2
Essa deveria ser uma questo mais fcil de cobertura de sentena e desvio, por usar a
nossa linguagem. Porm, aplicada numa questo de Teste de Software, as coisas ficam
confusas.
Questo
Considere o seguinte:
Pegar e ler o jornal
Olhe o que est passando na televiso
Se tiver um programa que voc estiver interesse em assistir, ento, veja a TV e
assista o programa
Caso contrrio
Continue lendo o jornal
Se existe uma palavra cruzada no jornal, ento tente completar
a) CS = 1 e CD = 1
b) CS = 1 e CD = 2
c) CS = 1 e CD = 3
d) CS = 2 e CD = 2
e) CS = 2 e CD = 3
Anlise do cdigo
Que cdigo?
Esse daqui:
1. Pegar jornal
2. Ler jornal
3. Olhar televiso
4. IF tiver um programa que voc estiver interesse em assistir THEN
5. Veja a TV
6. Assista o programa
7. ELSE
8. Continue lendo o jornal
9. IF existe uma palavra cruzada no jornal THEN
10. Tente completar
11. ENDIF
12. ENDIF
Acredito que uma maneira de resolver essa questo passando o cenrio descrito para
um pseudocdigo, embora gaste mais tempo. Mas no momento o importante
compreender a questo, leve o tempo que levar.
Analisando o cdigo temos dois IFs, sendo que o primeiro tem um ELSE, e o segundo
est associado ao ELSE, ou seja, dependente do primeiro IF.

165
Resoluo
Cobertura de sentena
Dois testes so necessrios: um para passar pelo primeiro IF e outro para passar pelo
segundo IF. E passando pelos dois IFs, iremos executar todas as sentenas.
Cobertura de desvio

J para a cobertura de desvio preciso 3 testes:
Teste 1
Est passando um bom filme e o cidado vai assistir. (primeiro IF verdadeiro)
Teste 2
Est passando o Fausto e o cidado vai continuar a leitura do jornal de domingo.
(primeiro IF falso)
O cidado acaba de encontrar uma palavra cruzada e logo tenta completar. (segundo IF
verdadeiro)
Teste 3
Est passando de Volta a Lagoa Azul e o cidado vai continuar a leitura do jornal.
(primeiro IF falso)
No h uma palavra cruzada no jornal. (segundo IF falso)
Resposta
Alternativa: e) CS = 2 e CD = 3


166
14. Resoluo de questes CTFL: Q36S3
Mais uma questo sobre classe de equivalncia. Bom para treinar mais um pouco.
Questo
Na modelagem de um sistema que trabalha com impostos a serem pagos: Um
empregado recebe R$4.000 de salrio livre de impostos. Os prximos R$1.500 so
tributados em 10%. E os prximos R$28.000 so tributados em 22%. Qualquer outro
valor tributado em 40%. Para o mais prximo valor inteiro, qual desses grupos de
nmeros cai na mesma classe de equivalncia?
a) R$4.800; R$14.000; R$28.000
b) R$5.200; R$5.500; R$28.000
c) R$28.001; R$32.000; R$35.000
d) R$5.800; R$28.000; R$32.000
Anlise
Precisamos saber qual alternativa contm valores que caem na mesma classe de
equivalncia. Portanto precisamos, antes de mais nada, saber quais classes de
equivalncias temos.
Resoluo
De acordo com o enunciado da questo temos 4 classes de equivalncia, que so:
1. Valores at 4000 = no tributados
2. Valores entre 4001 e 5500 = tributados em 10%
3. Valores entre 5501 e 33500 = tributados em 22%
4. Valores maiores que 33501 = tributados em 40%
Logo os valores da alternativa D R$5.800; R$28.000; R$32.000, pertencem a mesma
classe de equivalncia que a 3.
Resposta
Alternativa: d) R$5.800; R$28.000; R$32.000
At mais!


167
15. Impresses exame CTFL-BSTQB
pessoal. Hoje das 09:00 s 10:00 fiz o exame da CTFL (Certified Tester Foundation
Level).
Segue abaixo as minhas impresses sobre o exame:
Bom nvel de dificuldade: naquela mdia de: 20 questes fceis, 15 questes de
mdio/difcil e 5 questes de nvel muito difcil;
Bem elaborada: as questes eram bem feitas e claras;
Pouco tempo: 60 minutos para 40 questes? Pouco! Muito pouco! O tempo foi o
maior vilo da prova. Eu que costumo fazer as provas com calma, comecei e
terminei o exame a 100km/h e mesmo assim s fui passar as respostas para o
gabarito, faltando 5 minutos para o trmino da prova. Acabei quase em cima do
tempo mximo;
Revisar luxo: se voc tambm tem o hbito de revisar as questes, ento
esquece! No d para revisar as questes, devido ao pouco tempo. Eu at tentei
revisar umas de tabela de deciso, mas desisti;
Enunciados grandes: vrias questes eram bem longas, onde apresentavam
alguma situao;
Cdigos e tabelas de decises: acho que poucas pessoas conseguiram realmente
resolver essas questes, devido ao curto tempo. Eu mesmo s analisei a questo
e marquei a alternativa mais prxima do que eu achava, ou seja, quase um
Clculo Hipottico Universal de Tempo e Espao (C.H.U.T.E.).
Bem agora esperar at no mximo 20 dias para saber o resultado do exame. Espero
que ele seja positivo
Boa sorte a todos que fizeram o exame!!!


168
16. Exame IBM 000-370 cancelado no Brasil
Pelo menos por enquanto.
Fiquei sabendo pelo grupo DFTestes, que o exame para a certificao IBM Certified
Specialist Software Quality foi cancelado aqui no Brasil.
E em alguns estados o exame de quem j tinha marcado tambm foi cancelado.
O meu que eu tinha remarcado para 04 de maio, ainda est marcado l no site da
Prometric. Ento, acredito que quem marcou para fazer aqui em So Paulo no teve o
exame cancelado.
O exame IBM 000-370 no poder ser mais agendado. Tanto que pelo prprio site da
Prometric, voc no tem mais a opo de escolha desse exame, caso tenha colocado
Brasil como pas.
Achei estranha a atitude da IBM, principalmente o cancelamento dos exames das
pessoas que j tinham marcado. Mas fiquei sabendo tambm, que parece que a IBM
divulgou o exame no Brasil, para saber como est o mercado, e ver ser vivel aplicar
essa certificao aqui.
Ou seja, eles estavam vendo se h demanda no Brasil pela certificao, fato que justifica
a gratuidade do exame.
Agora resta aguardar para ver se a certificao voltar. Particularmente, acredito que ela
voltar sim, pois bastante profissionais se interessaram, porm nesse retorno ela dever
ser paga.
O bom dessa histria toda o excelente material que foi disponibilizado e divulgado. Eu
ainda no li todo (alis, deveria ter lido, pois a data do exame est chegando huahua),
mas pelo o que estudei at agora, o material tem bastante contedo, est bem organizado
e didtico.


169
17. Impresses exame IBM 000-370
Foi hoje de manh o meu exame da certificao IBM Certified Specialist Software
Quality. Acertei 67% (30 questes) e precisava ter acertado 71% (32 questes) das
questes.
Mas mesmo com o resultado negativo, fiquei feliz e at surpreso com o resultado, pelo
pouco tempo de estudo que dediquei.
Abaixo segue as impresses que tive do exame e tambm algumas dicas para aqueles
que iro fazer o exame.
Dificuldade
O exame oferece um alto grau de dificuldade, devido as seguintes caractersticas:
Baseado em um contedo muito extenso;
H muitas questes com alternativas parecidas, e voc tem que escolher a
melhor alternativa;
Os conceitos que caem no exame so de acordo com a IBM, e alguns so bem
diferentes dos usados pela maioria.
Idioma
O exame em Ingls, a maioria das questes usam termos tcnicos, e se voc no teve
dificuldade com as questes existentes no material de estudo, o idioma no ser um
problema. Mas por via das dvidas bom levar um dicionrio.
Durao
O exame tem durao de 60 minutos, tempo suficiente para fazer as questes e at
revisar as que voc ficou em dvida.
Resultado
O resultado sai na hora e mostra at a porcentagem de acertos em cada rea
(Engineering Quality in Software Development, Software Quality e Software Testing).
Dicas
Para o estudo para a certificao h basicamente duas tticas que podem ser seguidas:
Ler todo o material;
Ler o material de acordo com os objetivos do exame.
A primeira boa para quem quer, alm de obter a certificao, aumentar o
conhecimento sobre as reas de abordadas. E uma boa que o material abrange muitos
assuntos que ns que trabalhamos com Teste e Qualidade de Software, no
vivenciamos, mas que so legais de saber.

170
J a segunda ttica a ideal para quem objetiva a obteno da certificao e no est
com muito tempo para os estudos. Usando ela aconselho estudar os seguintes mdulos,
prestando ateno aos objetivos do exame [1]:
Engineering Quality in Software Development
o Creating Secure Software
o Essentials for Unit Testing
o Estimating Effort for Development Tasks
o In-Process Metrics for Software Developers
o Inspections in the Software Lifecycle
o Static Code Analysis
o Topics in Design Design Review Checklist
Software Quality
o Todos os mdulos
Software Testing
o Todos os mdulos
[1] http://www-03.ibm.com/certify/tests/obj370.shtml
Eu acabei usando uma terceira ttica (rsrs), estava sem tempo de estudar, ento s fiz as
questes de cada mdulo. O que at ajudou bastante na prova, pois essas questes so
focadas geralmente nos objetivos das lies e algumas at apareceram no exame.
Agora aguardar a volta da certificao aqui no Brasil!
Boa sorte aos que ainda iro prestar o exame!
E quem quiser saber mais dicas sobre o exame, entre no grupo Certificaes
Qualidade e Teste de SW, do Fbio Martinho Campos, l ele deu vrias outras dicas
para o exame.


171


Eventos

Dicas Eventos

172
1. Brateste 2009
Durante os dias 12 e 13 de maro de 2009, So Paulo sediar o 2 Seminrio Brasileiro
de Teste de Software, o Brateste 2009.
O evento ocorrer das 09 s 18 horas, no Renaissance So Paulo Hotel, localizado
na Alameda Santos, 2233 So Paulo, Brasil, sendo organizado pela
ALATS (Associao Latino-Americana de Teste de Software).
Ele voltado para todos os profissionais envolvidos com as atividades de
desenvolvimento e teste de sistemas, trazendo 14 palestras tcnicas, sendo duas
ministradas por Martin Pol, um dos cones globais do setor, autor de diversos livros
sobre o assunto e criador dos modelos TMap e do TPI, ambos usados como referncia
na Europa. O encontro tambm conta com palestras de personalidades renomadas da
Blgica, Amrica Latina e do Brasil.
Alm das novidades do setor, na ocasio haver a apresentao de produtos e servios,
atravs de uma rea de exposio e palestras tcnicas, assim como ofertas da literatura
sobre teste de software, num espao reservado para livrarias especializadas.
A grade (provisria) de palestras do Brateste 2009, segue abaixo:
Dia: 12/03/2009
Horrios Palestra Palestrante
09:00-
09:15
Abertura
Emerson Rios
ALATS
Brasil
09:15-
10:30
The evolution of
Testing
Martin Pol
Polteq International
Testing Services
Holanda
10:30-
11:00
Coffee break e visita aos stands
11:00-
12:00
Using offshore
partners for software
factory approach
Luc Vandergoten
BTR Services
Blgica
12:00-
13:00
Almoo e visita aos stands
13:00-
13:50
Un Modelo para la
Externalizacin de
Pruebas SW (Um
modelo para a
externalizao de
Teste de Software)
Mamdouh El Cuera
Mtodos y Tecnologa
(MTP)
Espanha


173

13:50-
14:40

Preveno de
defeitos

Arndt Von Staa
PUC-Rio Brasil

14:40-
15:30
Fabrica de Teste
Futuro ou realidade
Ricardo Cristalli
iTeste / Quality
Brasil
15:30-
16:00
Coffee break e visita aos stands
16:00-
16:50
Usando Rede
Bayesiana e Critrio
de Adequao para
Obter uma Melhor
Cobertura de Teste
de Requisitos
Gustavo Quezada
Brasil
16:50-
17:40
MPT Melhoria de
Processo de Teste de
Software
Emerson Rios
ALATS
Brasil
17:40-
18:30
Comparativo entre
Testes Manuais,
Automao e Alta-
Automao: 40
projetos reais, em 08
pases usando
Compuware,
Rational, Borland e
Mercury.
Marco Csar Bassi
CEO
Grupo HDI
18:30-
19:20
Central ou Fbrica de
Testes Uma
abordagem para
testes independentes
Adriano Romero e Ana
Aquino
BORLAND
Brasil
Dia: 13/03/2009
Palestra Palestrante
09:00-
10:30
Test Outsourcing
Martin Pol
Polteq International
Testing Services
Holanda
10:30-
11:00
Coffee break e visita aos stands
11:00-
12:00
Automao de Testes
de M Qualidade:
Como Evitar
Leonardo Molinari
MZP
Brasil
12:00-
13:00
Almoo e visita aos stands
13:00-
13:50
Experincia de testes
com Alta Automao:
A Experincia da
Falabella Chile
Jorge Maturana Palma
(Falabella)
Chile

174
13:50-
14:40
Casos de testes:
como, por que y para
que.
Marcelo de los Santos
Uruguai
14:40-
15:30
Benefcios da
utilizao de Testes
Exploratrios em
projetos Offshore e
Onshore
Aderson Bastos de
Souza
Stakeholder
Consultancy Services
Brasil
15:30-
16:00
Coffee break e visita aos stands
16:00-
16:50
Behaviour-Driven
Development: A nova
Era do Test-Driven
Development e
Acceptance Test-
Driven Development.
Com exemplos em
Concordion e
JBehave 2.
Jos Paulo Levandovski
Papo
BRQ IT Services
Brasil
16:50-
17:40
Aumentando a
produtividade em
testes de sistemas
usando Six Sigma -
Caso Real
Ftima Mattos
EDS
Brasil

Nota: As Palestras em ingls tero traduo simultnea.
A inscrio para o evento pode ser feita no prprio site da ALATS. E quem for, realize
logo o pagamento, pois depois do dia 06/02 o valor ir passar de R$350,00 para
R$450,00.
Eu estarei presente l, espero que o evento seja um sucesso, pelas palestras e
palestrantes, tem tudo para ser muito bom.

175

Figura 96 - BRATESTE 2009
Fonte:
ALATS


176
2. Cobertura BRATESTE 2009 (1 Dia)
Caros leitores,
Comea aqui a cobertura de um dos maiores eventos de Teste e Qualidade de
Software do Brasil, seno o maior, o BRATESTE 2009. Boa leitura!
Abertura Emerson Rios ALATS Brasil
O Presidente da ALATS fez a abertura do evento apresentando um pouco sobre a
Associao Latino-Americana de Teste de Software (ALATS) e sobre os dois
projetos que ela tem: a Certificao Brasileira de Teste de Software (CBTS) e a
Melhoria de Processo de Teste de Software (MPT). O primeiro com o foco na
qualificao profissional e que hoje j conta com 202 certificados ( j contando os
dois novos certificados de hoje, mais detalhes daqui a pouco). J o segundo projeto
foca a melhoria do processo de teste, pois como o prprio Emerson Rios disse, no
adianta temos excelentes profissionais, se o nosso processo e ineficaz.
Emerson Rios ainda enfatizou a importncia da comunidade de teste no Brasil, e
que ela seja colaborativa. E ainda fez a platia levantar para falar em unssono, uma
frase que ele parafraseou de Karl Marx: Testadores do Brasil uni-vos!
The evolution of Testing Martin Pol Polteq International Testing Services /
Holanda
Se eu for colocar todas as minhas anotaes sobre essa palestra, precisarei de vrios
posts (quase acabei um bloco de notas). A palestra foi sensacional! Ao seu trmino
j valeu a pena ter participado do BRATESTE 2009, s por essa palestra. Por que
eu digo isso?
Pelo palestrante, ser uma das maiores autoridades em Teste e Qualidade de
Software no mundo;
Por ter provado ser digno de tal grandeza;
Por ter falado sobre o Teste de Software, do seu incio at os dias atuais, em
50 minutos;
Por ter comentado sobre assuntos que j cansamos de ouvir, mas que
ouvindo um gringo falar parece ter mais importncia;
E por fim, pelo Martin Pol de sido certificado CBTS, devido aos seus
conhecimentos e atitudes em promover o Teste de Software no mundo todo.
Martin Pol o certificado CBTS de nmero 201.


177
Using offshore partners for software factory approach Luc Vandergoten
BTR Services/Blgica
Luc comeou a sua apresentao falando um pouco sobre a sua empresa na Blgica,
que j est h mais de 10 anos no mercado. Luc tinha duas grandes necessidades: a
de mo de obra especializada, que falta na Blgica, e de trabalhar de uma maneira
internacional. E para tentar sanar as suas necessidades a sua empresa comeou a
prtica o Offshore, terceirizando o desenvolvimento de software para a ndia e a
QA (Quality Assurance) para o Brasil.
Trs fatos que o Luc Vandergoten disse na sua apresentao, me chamaram a
ateno:
Os problemas com a ndia:
o Cultura
Sempre dizer Sim;
No aceitar falhas, sentir-se ofendido ao receber o reporte das
falhas.
o Educao
Foca os estudos em tecnologias velhas (ex.: Mainframe,
COBOL, etc);
Sem inovao
o Qualidade
Sem teste
O uso de metodologias geis, mas especificamente o uso do Scrum. Mesmo
com o grande problema da localizao diferente das equipes. Tendo que
realizar a daily meeting via Skype;
O desafio de gerenciar um projeto que est sendo desenvolvidos em trs
pases diferentes (Blgica, Brasil e ndia).
Luc concluiu a sua apresentao dizendo que Offshore no fcil, mas em
contrapartida, traz boas redues de custo. E ainda disse que solues globais so
melhores construdas globalmente.
Un Modelo para la Externalizacin de Pruebas SW (Um modelo para a
externalizao de Teste de Software) Mamdouh El Cuera (MTP)/Espanha
O palestrante, Mamdouh El Cuera, mostrou como funciona o Teste de Software na
sua empresa, focando em trat-lo como um servio. Para ter idia, ele aplica
conceitos de ITIL no processo de teste, e at faz uso de KPIs. Ele ainda disse que os

178
projetos de testes fracassam, devido aos clientes pensarem que tero resultados
imediatos, quando na verdade, os resultados do Teste de Software ocorrem a mdio
e longo prazo.
Mamdouh ainda destacou a existncia de um planejamento consistente e de uma
equipe de teste, formada por especialistas.
O interessante da palestra foi o tratamento do Teste de Software como servio.
Preveno de Defeitos Arndt Von Staa PUC-Rio/Brasil
A quarta palestra do dia foi a segunda melhor (na minha opinio, s perdendo para
a do Martin Pol). O professor Arndt Von Staa, que est na rea de computao h
mais de 47 anos ( ele escreveu o seu primeiro programa em setembro de 1962),
abordou com propriedade a importncia da preveno de defeitos.
Ele iniciou explicando um pouco sobre algumas terminologias (engano, defeito,
erro, falha, etc). Enfatizou a importncia do software ser fidedigno. Argument ou
sobre as crenas existentes em TI, dizendo que no se pode esperar que os sistemas
no possuam defeitos, e que mesmo em sistemas perfeitos pode haver falhas.
No final da apresentao Arndt comentou que podemos obter bons resultados com o
uso de tcnicas formais leves, revises e inspees.
Aps o encerramento da palestra, Arndt Von Staa recebeu o certificado CBTS, por
toda a sua bagagem acadmica e pelos 47 anos de TI. E se tornou o 202 certificado
CBTS do Brasil.
Fbrica de Teste Futuro ou realidade Ricardo Cristalli
iTeste/Quality/Brasil
Logo de incio o Ricardo Cristalli provocou a platia, perguntando se o Teste de
Software pode ser encarado como um projeto, e a grande maioria dos participantes
(incluindo esse que vs fala) levantou a mo. Na sequncia explicou um pouco
sobre o teste ser tratado como projeto, citando o PMI.
Dentre os tpicos abordados pelo Ricardo, destaco: a otimizao de recursos
internos; importncia da automao e da reusabilidade; a necessidade de saber onde
procurar os defeitos; conhecer os atributos do software; testar no uma atividade
simples; o processo deve representar o dia-a-dia; uso de ferramentas, somente se
forem adequadas ao projeto; virtualizao de ambiente de teste; sem especificao
no podemos ter um bom teste.
Para fechar a apresentao, o Ricardo mostrou algumas notcias que mostram que
fbricas de teste so uma realidade no Brasil, dentre as principais esto: CPM
Braxis, T&M Testes e RSI.


179
Usando Rede Bayesiana e Critrio de Adequao para Obter uma Melhor
Cobertura de Teste de Requisitos Gustavo Quezada/Brasil
Essa foi a apresentao mais tcnica do dia. O Gustavo Quezada apresentou o
conceitos sobre rede Bayesiana, uma rede que modela a implementao do software
permitindo simular diferentes cenrios. E tambm a importncia de definir os
critrios de adequao.
O uso de rede Bayesiana, geralmente, feito em grandes projetos para garantir a
cobertura de teste dos requisitos. Sendo muito til para reduzir a falha ou
ambiguidade dos requisitos, alm de diminuir o retrabalho. E a rede Bayesiana
ainda pode servir como um complemento as documentaes do software.
MPT Melhoria de Processo de Teste de Software Emerson Rios
ALATS/Brasil
Emerson Rios retorna ao palco, agora para d mais detalhes sobre a MPT
Melhoria de Processo de Teste de Software. Cujo motivo do seu surgimento, foi a
inexistncia de uma entidade para aplicar um modelo de melhoria do processo de
teste no Brasil, j que o TMM no avaliado aqui. Alm do intuito de fazer um
modelo brasileiro, que seja de baixo custo, comparado ao MPS.BR e CMMI.
A MPT tem 8 nveis (de 1 at 8), que representam o grau de maturidade do processo
de Teste de Software. No momento os dois primeiros nveis j esto definidos, e
podem ser consultados no arquivo disponibilizado pela ALATS. E o terceiro j est
em fase final e dever est pronto em julho, que a data prevista para a formao
de avaliadores MPT.
O Emerson Rios ainda disse, que a MPT poder ser aplicada a qualquer equipe de
teste, independente do seu tamanho.
No final da apresentao o Emerson Rios ainda simulou uma entrevista da MPT
nvel 1 com uma participante do evento.
Central ou Fbrica de Testes Uma abordagem para testes independentes
Adriano Romero e Ana Aquino Borland/Brasil
Palestra de cunho mais comercial, onde os palestrantes Adriano Romero e Ana
Aquino mostraram as vrias ferramentas para cada rea do Teste de Software, que a
Borland oferece. Sendo elas:
Caliber Defineit para definir os requisitos e criar as storyboard;
Caliber RM realizar a matriz de rastreabilidade e estimativa;
Silk Central gesto dos documentos de testes, apresentao de informaes
em grficos e relatrios e rastreabilidade da falha;
Silk Test gravao e execuo dos testes;

180
Silk Performer cria e executa os testes de performance e tambm monitora
o sistema.
A Ana Aquino ainda explicou o bom e velho Modelo-V, encaixando as ferramentas
da Borland de acordo com a atividade de teste.
Comparativo entre Testes Manuais, Automao e Alta-Automao: 40 projetos
reais, em 8 pases usando Compuware, Rational, Borland e Mercury Marco
Csar Bassi CEO-Grupo HDI
Se uma pessoa chegasse para voc hoje, e dissesse que ela tem uma ferramenta que
cria, executa e retornar os resultados dos testes de forma automtica, usando
Inteligncia Artificial (IA), e se voc precisar simular a interao do usurio via
teclado, ela tem um robozinho que faz isso. O que voc acharia dessa pessoa?
1. Um doido varrido;
2. Um charlato dos piores;
3. Boa piada essa!
4. Voc sonhou com isso?
5. Aham e Papai Noel existe tambm.
Resposta correta, nenhuma das alternativas. tudo verdade, pelo menos o que
garante o CEO do Grupo HDI, Marco Csar Bassi. Cuja apresentao foi muito boa,
simples e direta. E o melhor de tudo, com fatos que comprovam a eficcia da sua
plataforma de Alta-Automao.
A soluo do Grupo HDI vendida como servio, eles no vendem a ferramenta. E
j foi aplicada em mais de 40 projetos, em 8 pases. E dentre os interessantes dados
coletados, esto:
89% das falhas so validaes de campos e formatos (falhas bobas);
100% dos sistemas tinham falhas de segurana;
Os pases que mais erram so EUA e ndia (os americanos apenas fazem
normas para os outros ler, eles mesmos no lem);
O pas que menos erra a Irlanda (segundo o Marco, no foi encontrado
nenhuma falha no sistema deles);
O Brasil o 4 melhor pas em desenvolvimento (no total so 8 pases
avaliados);
48% de falhas em requisitos.

181
A palestra do Marco, fechou o primeiro dia da BRATESTE com chave de ouro,
despertou muita curiosidade em saber como tudo isso funciona (tentarei buscar
mais informaes amanh).
Bem, aqui encerro a cobertura do primeiro dia, espero que vocs tenham gostado.
Amanh tem mais!
Quem quiser fazer o download das apresentaes do BRATESTE 2009, segue
abaixo o link:
http://www.mediafire.com/file/4ol4yz5nmin/Palestras BRATESTE 2009.zip
(22.34 MB)


182
3. Cobertura BRATESTE 2009 (2 Dia)
O segundo dia do BRATESTE teve 7 palestras, duas a menos do que o primeiro dia.
Mas nem por isso deixou a desejar, pelo contrrio, foi mais um dia para conhecer e
aprender mais sobre Teste e Qualidade de Software.
Vamos ento comear a cobertura do segundo dia do BRATESTE 2009. Boa
leitura!
Test Outsourcing Martin Pol Polteq International Testing
Services/Holanda
Comeamos mais um dia com a presena de Martin Pol no palco. Dessa vez para
falar sobre a terceirizao de teste (famoso Test Outsourcing).
O primeiro e ltimo slides da apresentao de Martin, tinham as fotos de Romrio,
Ronaldo e Alex (Chelsea). Muitos podem est se perguntando: Mas que por que
diacho esse gringo colocou a fotos desses trs?
O motivo simples, os jogadores de futebol so uns dos melhores exemplos do bom
funcionamento e benefcio da terceirizao. Se voc ainda no est satisfeito com
essa analogia, e ainda se pergunta: Por que terceirizar o Teste de Software?
Martin Pol poderia fazer uma lista com 40 motivos, mas sabendo que ele no seria o
nico palestrante do dia, citou apenas os principais, que so eles:
Usar a capacidade de outras pessoas;
Equipe independente;
Foco no core do negcio;
Reduo de tempo perdido;
Falta de recursos;
Transferir funes de negcios para um parceiro externo.
Ops quase esqueci de um, a REDUO DE CUSTO (calma no estou gritando,
apenas enfatizando esse motivo que acredito que nenhum gerente deve ligar).
Bem, agora voc pode est maravilhado com a descoberta de Martin Pol, e
falando: Esses gringos so fo#!%* mesmo. Mas muita calma nessa hora, a
terceirizao algo comum, antigo e natural. Exemplo disso, so alguns pssaros
que fazem ninhos para outros pssaros. E ainda temos outros exemplos da
construo civil e aviao.
E lgico que quando a terceirizao ganha o mundo de TI, logo surgem novos
termos e ela classificada:

183
Off-shoring:
Co-sourcing:
Business Process Outsourcing:
Joint Venture:
Right-sourcing:
Blended sourcing;
Near-shoring;
Home shoring.
Bem, para encerrar essa longa cobertura da palestra de Martin, vou deixar alguns
conselhos e experincia que Martin Pol disse:
H uma grande dificuldade no idioma, principalmente na Europa, onde mais
de 23 idiomas so falados;
Gerenciamento e controle, gerenciamento e controle, gerenciamento e
controle, gerenciamento e controle, gerenciamento e controle so muito
importantes (o Martin repetiu muitas vezes essas duas palavras);
Dosar a rigidez e flexibilidade do processo;
Tenha uma direo, antes de entrar na terceirizao;
Defina uma estratgia, selecione um fornecedor, crie o contrato, se preocupe
com a transio e administre e monitore a terceirizao;
O retorno do investimento demora em mdia 1 ano;
Tenha mais de um fornecedor, mas no muitos.
Torne-se especialista;
Pense sobre o divrcio antes de assinar o contrato.
Como vocs puderam perceber, eu nem gostei dessa palestra, na verdade s achei
um pouco longa demais (1h30min). Mas foram 90 minutos muito bem gastos.
Automao de Testes de M Qualidade: Como Evitar Leonardo Molinari
MZP/Brasil
Grande Molinari! Estava ansioso para ver o que ele tinha a falar, afinal ele um dos
grandes nomes da nossa rea aqui no Brasil.
Durante a sua apresentao, ele falou sobre os seguintes assuntos: automao no
resolve tudo, mas uma grande ajuda; automao de testes precisa ser aprendida

184
corretamente; automao de teste no substitui uma equipe de testes; nem tudo pode
ser testado, mesmo usando automao; nem tudo que pode ser testado precisar de
automao.
Bem, minha impresso foi que mesmo com o Leonardo dizendo que no ia chover
no molhado, acabou chovendo no molhado. Porm, levantou pontos importantes,
como:
No podemos falar que uma ferramenta uma porcaria, sem antes a estudar
direito;
Sempre possvel melhorar;
Ir sempre alm da ferramenta;
Estudar, estudar e estudar;
O testador manual no vai morrer, devido ao seu conhecimento sobre o
negcio.
No final da apresentao, Molinari ainda revelou uma surpresa (tcharam!)seu
novo livro sobre Testes de performance, que em breve estar nas melhores livrarias
do pas (hehe).
Experincia de testes com Alta Automao: A Experincia da Falabella Chile
Jorge Maturana Palma (Falabella)/ Chile
Nessa palestra, Jorge Maturama falou sobre o caso de sucesso da Alta Automao,
implantada pelo grupo HDI (o do Marco Bassi). Mostrando um pouco das suas
expectativas com o Teste de Software, o uso da ISO-IEC 926 e ainda a importncia
dos usurios estarem felizes com o produto entregue.
O interessante da palestra foi o fato de uma empresa brasileira, ter ganhado a
licitao do projeto, concorrendo com grandes empresas multinacionais como IBM
e Accenture. E com uma soluo inovadora que a plataforma de Alta Automao
do grupo HDI (que foi apresentada no primeiro dia).
Casos de testes: como, por que y para que Marcelo de los Santos/Uruguai
O Marcelo o diretor da diretoria da ALATS no Uruguai, a primeira diretoria fora
do Brasil. E apresentou a sua experincia com Teste de Software, focando no uso
dos casos de testes, mas tambm comentando sobre: checklist e uso de mquinas
virtuais para a montagem dos ambientes de teste.
Algo interessante que notei, foi o fato, de pases diferentes enfrentarem os mesmos
problemas. Logo surgi uma necessidade em comum, e alianas e trocas de
informaes podem e devem ser feitas. O que mostra que a tentativa da ALATS em
atingir a Amrica Latina muito vlida.

185
Benefcios da utilizao de Testes Exploratrios em projetos Offshore e
Onshore Aderson Bastos de Souza - Stakeholder Consultancy Services/Brasil
Duas coisas me impressionaram nesta palestra:
1. Eu pensava que o Aderson Bastos era da mesma faixa de idade do Emerson
Rios e Trayah Moreira, quando na verdade, ele bem novo, deve ter uns 30
anos no mximo;
2. O uso de Testes Exploratrios como uma forma de alcanar o sucesso em
projetos de teste.
Uma das melhores palestras do BRATESTE, teve incio com a apresentao dos
conceitos de Teste Exploratrio. E logo em seguida o Aderson mostrou dois casos
de sucesso usando Testes Exploratrios, um offshore (para Nova York) e outro
onshore (para uma grande empresa).
Na minha opinio, o Aderson Bastos conseguiu tirar leite de pedra em ambos os
projetos. Pois nos dois a especificao quase no existia, e o pouco que havia era
bem desatualizada e inconsistente. Tornando o processo de teste muito complicado
e difcil.
E tais cenrios demandavam do uso de Testes Exploratrios, que realizados pela
sua competente equipe, conseguiram trazer bons resultados, tendo o foco na
cobertura dos requisitos do negcio, que eram o pouco de documentao que existia
nos projetos.
E com o decorrer dos projetos o Aderson Bastos conseguiu mudar a viso dos
clientes sobre o Teste de Software, e fazer-los ajudar no teste tambm. Alm de
conseguir aumentar o esforo de teste de 2% para 10%, o que ainda pouco, mas j
um bom salto para dois anos de projeto.
O mais interessante da palestra, foi a superao do grande desafio que a empresa do
Aderson teve, um desafio que muitas empresas indianas tiveram medo de enfrentar.
O que mostra que ns brasileiros podemos oferecer Teste de Software melhor do
que outros pases, principalmente, quando necessrio criatividade para superar os
desafios.
Behaviour-Driven Development: A nova Era do Test-Driven Development e
Acceptance Test-Driven Development. Com exemplos em Concordion e
JBehave 2 - Jos Paulo Levandovski Papo BRQ IT Services/Brasil
O que falar de uma palestra, que antes do seu incio, voc j tem a certeza de que
vai ser muito boa. Afinal, no palco est Jos Paulo Levandovski Papo, o
famoso Jos Papo.
A palestra foi uma verdadeira aula sobre: Test-Driven Development (TDD);
Behavior-Driven Development (BDD); e o Acceptance Test-Driven Development

186
(ATDD). Apresentando os conceitos, benefcios e dificuldades de cada prtica. E
ainda mostrou alguns exemplos, usando ferramentas como o Concordion.
Os pontos mais importantes levantados pelo Papo foram:
Os testes unitrios so feitos pelos desenvolvedores e so de grande valor na
preveno dos defeitos;
possvel fazer o teste de aceite antes do sistema est totalmente pronto;
muito importante envolver os stakeholders;
Com o BDD, qualquer pessoa pode entender o teste;
Com o uso do ATDD, cria-se uma especificao executvel.
E como toda boa aula, o professor nos deixou, de maneira indireta, uma lio de
casa. Estudar melhor tais prticas e tentar coloc-las nas nossas empresas, ou pelo
menos, mostrar ao desenvolvedores que tais prticas existem.
Aumentando a produtividade em testes de sistemas usando Six Sigma Caso
Real Ftima Mattos EDS/ Brasil
A palestra da Ftima mostrou como que a sua equipe fez para tentar aumentar a
produtividade da fase de teste em 20%, utilizando para isso o Six Sigma, que uma
metodologia estruturada com foco na melhoria contnua.
A sua equipe enfrentava um grande problema de no encontrar o testware, por ele
no est armazenado de uma maneira fcil a ser consultado.
Para superar esse problema ela usou o DMAIC, que defini 5 passos para a melhoria
contnua: Definir->Medir->Analisar->Melhorar->Controlar.
Aps todo o esforo realizado pela equipe, eles obtiveram um ganho de 93% na
produtividade. E a soluo adotada foi a criao de um repositrio de
conhecimento, o que aumentou em 127% o uso do testware.
Aps a palestra da Ftima Mattos, houve o show de encerramento, com direito a
samba e o pessoal da ALATS sambando no palco (esse o Brasil!, tudo no final
acaba em samba, faltou apenas uma pizza).
Bem pessoal, aqui encerro a cobertura do BRATESTE 2009, espero que vocs
tenham gostado.
Mas esse no o fim, ainda irei fazer um post com a minha concluso sobre o
evento. E j posso adiantar que elas foram excelentes!


187
Quem quiser fazer o download das apresentaes do BRATESTE 2009, segue
abaixo o link:
http://www.mediafire.com/file/4ol4yz5nmin/Palestras BRATESTE 2009.zip
(22.34 MB)


188
4. Concluso BRATESTE 2009
Se voc me pedir para resumir o BRATESTE em uma palavra, eu diria:
SENSACIONAL!!!
Motivos no faltam para chegar nessa concluso, tanto em termos de organizao
quanto da qualidade do evento. Listo abaixo, alguns desses motivos:
Bem organizado: local, estrutura, equipes, stands, grade de palestra e
divulgao;
Palestrantes de alto nvel;
Objetivo de unir a comunidade de testadores do Brasil;
Apresentao de novidades, como o MPT (Melhoria de Processo de Teste de
Software);
A participao de profissionais de vrios estados do Brasil;
Foco nas tendncias de mercado.
Logicamente, que todo evento tem alguns pontos fracos, e aqui vo alguns que
notei:
Atraso de algumas palestras, principalmente no primeiro dia, cuja abertura
teve incio com 40 minutos de atraso;
Demora na distribuio das credencias, o que acabou influenciando o atraso
da abertura;
Falhas em alguns links de apresentaes, que no estavam corretos, sendo
que um deles, fez com que a palestra do Marco Bassi, do grupo HDI, fosse
trocada pela do pessoal da Borland;
Por que no fazer o almoo no local? Principalmente, pelo fato de ser difcil
de controlar o horrio de 1 hora de almoo, sendo ele fora do local do
evento, que geralmente era insuficiente e muitas pessoas se atrasavam para
as palestras que ocorriam depois do almoo.
Como puderam perceber foram pequenas falhas que ocorreram, nada que
comprometesse a qualidade final do evento.
Tendncias
De acordo com os temas das palestras, ficaram claras algumas tendncias, como:
O uso de metodologias geis e os benefcios e desafios na aplicao do Teste
de Software;

189
O outsourcing de Teste de Software, principalmente como offshore;
A automao do Teste de Software e a preocupao com uma boa
automao;
O conceito de fbrica de teste, que, alis, uma realidade h um bom tempo
no Brasil, prova disso a empresa T&M Testes de Software, que h mais de
25 anos fornece servios in-house/out-house in-shore/off-shore de Teste de
Software.
Consideraes Finais
Com certeza valeu muito apena ter sacrificado dois dias de trabalho, para participar
do BRATESTE. Ter a certeza que voc no o nico que passa por dificuldades na
prtica do Teste de Software; o fato de haver pessoas no mundo todo, preocupadas
com o Teste de Software. E ainda a oportunidade de est a par das novidades e
tendncias da nossa rea.
Para encerrar, parabns para ALATS pela organizao do evento, e pela
preocupao em disseminar conhecimento e buscar a melhoria da nossa rea no
Brasil. E mais uma vez, obrigado a Voice Technology (empresa na qual trabalho),
por me permitir e incentivar participar do BRATESTE.
E como disse o Emerson Rios: TESTADORES DO BRASIL UNI-VOS!
Quem quiser fazer o download das apresentaes do BRATESTE 2009, segue
abaixo o link:
http://www.mediafire.com/file/4ol4yz5nmin/Palestras BRATESTE 2009.zip
(22.34 MB)


190
5. 1 Encontro Mensal da ALATS So Paulo
tima iniciativa da diretoria de So Paulo da ALATS!
Acredito que encontros assim, so excelentes oportunidades para aumentar o
famoso networking, assim como est a par das novidades e discusses, referentes a
nossa rea. E porque no, uma terapia em grupo, afinal nesses momentos
percebemos que no apenas a gente que passa por determinados problemas e
situaes.
Espero que esse seja o primeiro de muitos encontros!
Eu pretendo ir (quase certeza).
Segue abaixo mais dados sobre o encontro, recebidos por e-mail:
A Diretoria Regional da ALATS em So Paulo convida para o seu 1 Encontro
Mensal.
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 prticas de sucesso.
Tema do Encontro: A Arte de Testar Software: 30 anos Depois e Alm
Agenda:
18:30 Credenciamento
19:00 Incio da Palestra
20:00 Coffee break
20:30 Continuao da Palestra
21:30 Espao aberto para perguntas sobre Teste de Software, ALATS e certificao
CBTS
22:00 Encerramento
Contedo da Palestra
1979: O ano de lanamento do livro The Art of Software Testing, por
Glenford Myers
30 Anos de Teste de Software
Quais conceitos da obra so vlidos at hoje?
Qual o futuro da rea da Qualidade?
A participao na palestra Vale 3 PDTS para a renovao da CBTS
Palestrante:
Jos Correia, diretor regional de So Paulo da ALATS, coordenador da Iterasys, 14

191
anos de atuao na rea de TI. Formado em Processamento de Dados pela FATEC,
ps-graduado em Gesto Empresarial pela CEETEPs-IPEN/USP, certificado CBTS,
CSTE e CTFL, entre outras.
Local: Em definio (prximo ao Metr)
Data: 16 de Abril (quinta-feira)
Horrio: 18:30 22:00
Inscries:
- Associados ALATS: R$ 25,00
- No Associados: R$ 30,00
Reserve pelo e-mail contato@iterasys.com.br
Bnus: A Iterasys sortear entre os participantes 3 vale desconto em seus
treinamentos no valor de R$ 400,00/cada.
Dvidas: contato@iterasys.com.br ou (11) 3254-7625


192
6. Impresses do 1 Encontro Mensal da ALATS
So Paulo
Ontem em So Paulo das 18:30 s 22:00 ocorreu o 1 Encontro Mensal da ALATS So
Paulo, sendo tambm o 1 encontro de Teste de Software a ser realizado pela ALATS.
Abaixo relato quais foram as minhas impresses sobre essa excelente iniciativa da
ALATS.
Expectativa
Antes de falar do encontro em si, bom falar do eu esperava dele. Bem, eu j estava
empolgado pela iniciativa e oportunidade. E o legal desse tipo de evento que ele acaba
sendo menos formal, tem um menor pblico e mais focado, afinal um encontro.
Primeira impresso
Ao chegar no local do encontro, juntamente com os amigos do trabalho (Daniele
Guimares, Francisco Simes e Rodrigo Ribeiro) ficamos com uma sensao de que
parecia que no ia ser AQUELE encontro. Pois havia s mais um outro grupo de umas 4
pessoas no local. E eu pensei que o encontro seria no auditrio do IMAM (alis, o
mesmo local em que eu fiz a prova da CBTS). Mas no o encontro ia ser numa salinha
ao lado, com espao para umas 20 pessoas.
Primeira parte do encontro
Jos Correia, diretor regional da ALATS So Paulo, iniciou o encontro falando um
pouco sobre o objetivo desses encontros, que proporcionar uma forma de contato entre
as ilhas de testadores de software, pois atualmente h muitos testadores, porm quase
todos em ilhas e o encontro mensal pode ser uma maneira de aproximar esses
profissionais para troca de informaes e experincias. E ainda disse que os
participantes dos encontros tambm podem participar do encontro como palestrante.
Logo em seguida, todos os participantes se apresentaram, e foi um dos momentos mais
legais do evento.
Parar tudo!O senhor um fanfarro em Fabrcio!Dizer que um dos momentos
mais legais do evento foi a apresentao das pessoas, brincadeiranem quero saber
como foi o restante do encontro!
Que isso, vou explicar melhor porque achei esse momento legal: ao todo tinhas umas 14
pessoas e o Jos Correia pediu para cada um ser apresentar de forma breve, porm
alguns se empolgaram e comentaram um pouco sobre a experincia deles na rea (o que
foi muito vlido). Da pareceu uma terapia em grupo (leia-se TA Testadores
Annimos), onde um falava sobre determinada situao e o outro falava que j passou
por isso, etc.

193
Acredito que esses momentos so bem legais, pois sinto que muitas vezes estamos
muito bitolados com os estudos e o trabalho, e muitos de ns no tem essa oportunidade
de falar sobre o trabalho com pessoas da mesma rea (eu mesmo tenho poucos amigos
que trabalham com Teste de Software, tirando os amigos do trabalho).
E tambm estamos em uma era onde lemos muito e discutimos pouco, alis, esse um
motivo pelo qual esquecemos muitas das coisas que lemos e estudamos.
Agora sobre a primeira parte da palestra, cujo tema era: O ano de lanamento do livro
The Art of Software Testing, por Glenford Myers. O Jos Correia abordou com
bastante propriedade o assunto, comentando sobre os captulos dessa obra que
considerada a bblia do Teste de Software, sempre fazendo comparaes com a poca de
Myers, dcada de 70, e os anos atuais.
Segunda parte do encontro
Aps um belo de um Coffee Break, Jos Correia continuou a sua apresentao,
comentando sobre os captulos do livro de Myers.E ainda falou sobre o futuro do Teste
de Software, tendo como base as 10 tendncias de TI (ele citou as de 2008, que ainda
so vlidas).
O mais legal da apresentao do Jos Correia foi a maneira (bem otimista) que ele
ilustrava o Teste de Software e a sua importncia, tanto quando comentou sobre o livro
de Myers, como quando falou sobre o futuro da nossa rea. Particularmente, tambm
vejo com bastante otimismo o futuro da nossa rea
A concluso que chegamos ao final da apresentao que muitos dos conceitos que
Myers falava em 1979, ainda so vlidos para os dias atuais. Tanto que os livros e
certificaes de Teste de Software, sempre tm como referncia o livro The Art of
Software Testing. E Teste de Software uma rea que est crescendo e ir crescer
ainda muito, pois cada vez ser mais necessrio testar software.
Quem quiser fazer o download da apresentao, ela est sendo disponibilizada no site
da Iterasys, link abaixo:
http://www.iterasys.com.br/downloads/ALATS-SP-Encontro-Mensal-001.pdf
Consideraes finais
Com certeza o primeiro encontro da ALATS foi um sucesso! Pudemos compartilhar
experincias, conhecer novas pessoas da rea e ainda ter uma excelente palestra com o
Jos Correia.
Agora torce para que esses encontros aconteam mensalmente mesmo. E para que isso
acontea, tambm precisamos ajudar. Pessoal participem e divulguem o encontro, quem
sabe a prxima j no pode ser no auditrio do IMAM e com ele lotado!

194
Parabns a ALATS pela iniciativa e a todos os participantes do primeiro encontro,
espero que esse seja o primeiro de muitos!!!
Notcias quentes
Alm da excelente apresentao e encontro, ficamos sabendo sobre:
O BRATESTE 2010 j tem data definida para acontecer! 23, 24 e 25 de maro
de 2010. Agora sero trs dias de evento \O/. E ele ser realizado em So Paulo.
(alis, essa informao j est na pgina principal do site da ALATS);
Ser feito em 2010 um evento em comemorao aos 31 anos do Teste de
Software, no dia 20 de fevereiro;
O prximo encontro j tem data marcada. Ser no dia 13 de maio de 2009, das
18:30 s 22:30 e ser sobre Estimativas. O palestrante ainda segredo, mas
parece que algum da ALATS.
Bem pessoal isso!
P.S.: O Jos Correia o senhor das analogias (quase todas excelentes!!!as no
excelentes foram boas.eu particularmente gosto muito de analogias), alis, vou at
fazer alguns posts, em um futuro breve, sobre algumas delas .


195
7. 2 Encontro Mensal da ALATS So Paulo
O 2 encontro mensal da ALATS em So Paulo ter como tema, algo que gera bastante
discusso e que muita gente se descabela na hora de fazer: Estimativas.
E nesse encontro teremos a oportunidade de tirar as nossas dvidas com uma
especialista no assunto, a Cristiane Pelossi Genovese Barroso, CFPS Certified
Function Point Specialist.
E claro que eu no vou perder essa oportunidade.
Segue abaixo, mais dados sobre o evento, recebidos por e-mail:
A Diretoria Regional da ALATS em So Paulo convida para o seu 2 Encontro Mensal.
Objetivo: Aumentar o contato entre profissionais da rea de Teste de Software e
Garantia da Qualidade, bem como estimular a troca de conhecimentos, experincias e
prticas de sucesso.
Tema do Encontro: Estimativas
Agenda:
18:30 Credenciamento e Networking entre os Participantes
19:00 Estimativa do Tamanho do Software atravs da APF
20:00 Coffee break e Networking
20:30 Estimativa do Esforo de Teste atravs da APT
21:00 Outras Formas de Estimar
21:30 Espao aberto para discusso de temas da ALATS e da comunidade de Qualidade
de Software em geral
22:00 Encerramento
Contedo da Palestra
Estimativa do Tamanho do Software atravs da Anlise de Pontos de Funo (APF),
por Cristiane Pelossi Genovesi Barroso
Estimativa do Esforo de Teste atravs da Analise de Pontos de Teste (APT), por Jos
Correia
Outras Formas de Estimar
A participao na palestra Vale 3 PDTS para a renovao da CBTS
Palestrantes:
Cristiane Pelossi Genovese Barroso, CFPS Certified Function Point Specialist,
tradutora para o portugus do Counting Practices Manual, o guia oficial da Anlise de
Pontos de Funo, proprietria da Softsize e gerente em uma das principais consultorias
de TI brasileiras.

196
Jos Correia, diretor regional de So Paulo da ALATS, coordenador da Iterasys, 14
anos de atuao na rea de TI. Formado em Processamento de Dados pela FATEC, ps-
graduado em Gesto Empresarial pela CEETEPs-IPEN/USP, certificado CBTS, CSTE e
CTFL, entre outras.
Local: IMAM Rua Loefgreen, 1.400 Vila Mariana prximo a Estao de Metr
Santa Cruz, estacionamento no local (no incluso)
Data: 13 de Maio (quarta-feira)
Horrio: 18:30 22:00
Inscries:
- Associados ALATS: R$ 25,00
- No Associados: R$ 30,00
Reserve pelo e-mail contato@iterasys.com.br
Bnus: A Iterasys sortear entre os participantes 1 vale desconto em seus treinamentos
no valor de R$ 400,00.
Dvidas: contato@iterasys.com.br (11) 3254-7625


197
8. Impresses do 2 Encontro Mensal da ALATS
So Paulo
Hoje das 18:30 at s 22:00 ocorreu o 2 Encontro Mensal da ALATS em So Paulo.
O tema dessa vez foi Estimativas, e foi dividido em duas palestras: Estimativa do
tamanho do Software atravs da Anlise de Pontos de Funo (APF), palestrada pela
Cristiane Pelossi Genovese Barroso, CFPS Certified Function Point Specialist e
Estimativa do tamanho do Software atravs da Anlise de Pontos de Teste (APT),
palestrada pelo Jos Correia, diretor da ALATS So Paulo.
Abaixo, relato as minhas impresses do 2 encontro mensal.
Estimativa do tamanho do Software atravs da Anlise de Pontos de Funo (APF)
A palestra ocorreu no auditrio do IMAM para 44 participantes (no 1 encontro foram
14). E no seu incio a Cristiane apresentou como que surgiu a APF e um breve
panorama da situao de mercado, alis, um dado informado bem interessante a falta
de pessoal qualificado para a rea.
Em seguida a palestrante explicou os conceitos de APF, ela uma tcnica para medir o
tamanho do software, e est fortemente relacionada com os requisitos funcionais
solicitados pelo cliente.
Alm de sua funo principal, a APF ainda ajuda na complementao e melhoria dos
requisitos. E com ela fica mais fcil explicar o tempo do projeto e estimar o valor do
mesmo (que muitas vezes definido por horas e no por funo).
A Cristiane ainda explicou como funciona a certificao CFPS, que j tem mais de 500
certificados no Brasil, alis, o Brasil o pas que mais tem certificados.
Bem, para finalizar a impresso da palestra da Cristiane, ficou claro que aplicao da
APF traz bons resultados, porm ela no fcil de ser aplicada, h muitos fatores que
podem influenciar, e temos que est capacitados para tal tarefa. Tanto a nvel de
conhecimento da APF como do sistema que est sendo avaliado.
Um ponto interessante, apresentado pela Cristiane que a APF pode ser aplicada
mesmo com o projeto j em andamento, para as novas funcionalidades, por exemplo.
Estimativa do tamanho do Software atravs da Anlise de Pontos de Teste (APT)
A palestra do Jos Correia foi bem curta e mais para d uma viso geral na APT, criada
por Martin Pol, Ruud Tennissem e Erik Van Veenendaal.
O que ficou legal, foi que aps ter visto a APF ficou bem claro a importncia da APT,
pois ela mais especifica e abrangente para a rea de Testes. Sendo muito til para

198
estimar o esforo de teste necessrio, e muito melhor que a estimativa do dedo, ou a
do veja bem, ou ainda a do se.
O Jos Correia alertou que precisamos usar mais a APT no Brasil, afinal ela uma
continuao de uma metodologia vlida, e bem usada na Europa, o que mostra que ela
pode sim nos auxiliar nas estimativas.
No final o palestrante ainda comentou sobre outras formas de estimar:
Top down
o Custos
o Restries
o Ponto de Funo
o Cocomo
Julgamento experiente
Botton up
o Baseado na WBS

E ainda Jos Correia nos contou duas novidades, o lanamento do Comit de
Estimativas e da BLAETS (Base Latina Americana de Estimativas de Teste de
Software) um projeto que visa proporcionar a todos da rea, uma fonte para obter
estimativas de esforo no Teste de Software.
E para o desenvolvimento da BLAETS ns precisaremos ajudar, pois ela ser construda
a partir de dados fornecidos por ns. A ALATS ir coletar, analisar e divulgar tais
dados, que no tero nenhuma informao particular, como os dados da empresa.
Mais uma boa iniciativa, e o sucesso dela s depende da comunidade brasileira de Teste
de Software, ou seja, de ns mesmos.
Coffee Break
O coffee break foi um momento mpar do encontro, alm dos excelentes salgados e
doces, o restaurante estava cheio e foi um bom momento para conversar com o pessoal.
Alis, tive o prazer de conhecer pessoalmente o Elias Nogueira e tambm o Robson
Agapito, junto com o pessoal da Mega, e tambm algumas pessoas que j visitaram
o QualidadeBR.
Encontro
O segundo encontro foi muito bom, uma oportunidade nica para entender melhor a
APF e APT, e ainda aproximar mais a comunidade de Teste e Qualidade de Software.
Parabns a Cristiane pela palestra, ao Jos Correia e o pessoal da Iterasy (que auxiliam a
organizao do evento) por mais um encontro e pelo esforo dedicado, e tambm a
todos os participantes, afinal sair do trabalho e ir para o encontro no fcil.

199
E para encerrar esse post, nada melhor do que falar sobre o 3 encontro mensal, que ter
Fbio Martinho Campos, grande especialista da rea, palestrando sobre Teste de
Performance, no dia 16 de junho no IMAM.
Abraos a todos! E at o prximo encontro!
Saiba mais:
Quem quiser saber mais sobre os encontros mensais da ALATS em So Paulo, e
tambm fazer o download da apresentao do 2 encontro, segue abaixo o link:
http://www.alats.org.br/Default.aspx?tabid=144


200
9. 2 Seminrio de Teste de Software do Rio de
Janeiro
Fiquei sabendo via e-mail, que haver o 2 Seminrio de Teste de Software do Rio de
Janeiro, promovido pela ALATS. Segue abaixo maiores informaes do evento:

Dia: 15/07/2009
Local: Rua So Jos 40 4 andar Centro Rio de Janeiro RJ
Horrio: 09 s 17 horas.
Preo: R$ 160,00
Preo para associados: R$ 120,00
Nmero de inscries limitada: 60 pessoas
Inscries e maiores informaes: pelo site da ALATS


201
10. Adiado o 3 Encontro Mensal da ALATS
Pessoal,
O encontro que iria ocorrer amanh (16/06), foi adiado para o prximo dia 23 (tera-
feira). Ou seja, quem ainda no se inscreveu ou no estava ciente do evento tem mais
uma semana para se programar e poder confirmar a presena no encontro.
O 3 encontro em So Paulo ter como tema Teste de Performance, e ser palestrado
pelo Fbio Martinho Campos, especialista de Teste de SW e um dos profissionais mais
participativos na comunidade de Teste e Qualidade de Software Brasileira.
Segue abaixo, maiores detalhes do evento retirados do site da ALATS:
3 Encontro Mensal da ALATS
Data: 23 de Junho (tera-feira)
Horrio: 18:30 22:00
Objetivo: Aumentar o contato entre profissionais da rea de Teste de Software e
Garantia da Qualidade, bem como estimular a troca de conhecimentos, experincias e
prticas de sucesso.
Tema do Encontro: Teste de Performance
Agenda:
18:30 Credenciamento e Networking entre os Participantes
19:00 Introduo ao Teste de Performance
20:00 Coffee break e Networking
20:30 Teste de Performance na Prtica
21:30 Espao aberto para discusso de temas da ALATS e da comunidade de Qualidade
de Software em geral
22:00 Encerramento
Palestrante:
Fbio Martinho Campos, CBTS, CQA, CST, CSCM, CTFL e IBM Certified Specialist.
Bacharel em Computao pela UNITAU (Universidade de Taubat), MBA em Gesto
de Projetos pelo IPT (Instituto de Pesquisas Tecnolgicas-USP). Especialista em Teste
de Performance na CPM Braxis.
Local: IMAM Rua Loefgreen, 1.400 Vila Mariana prximo a Estao de Metr
Santa Cruz, estacionamento no local (no incluso)




202
Inscries:
Associados ALATS: R$ 25,00
No Associados: R$ 30,00
A participao na palestra Vale 3 PDTS para a renovao da CBTS
Inscrio e pagamento pelo site:
http://www.alats.org.br/default.aspx?tabid=144




203
Gerncia de Projetos



Gerncia de Projetos

204
1. TRIZ Teoria da Resoluo de Problemas
Inventivos
Pessoal, hoje vou falar sobre essa metodologia que se prope a ajudar em algo que
muito comum em nosso dia a dia, os problemas.

Os problemas em uma organizao de TI, geralmente so os geradores de conflitos, que
podem ser entendidos como situaes de oposio, desacordo ou incompatibilidade
entre pelo menos duas pessoas ou grupos.

E podemos ter duas vises a respeito dos conflitos:

Conservadora: Eles tendem a considerar os conflitos como indesejveis. Sendo
causados por pessoas problemticas, que insistem em no ajustar-se e devem ser,
sempre e assim que possvel, suprimidos.
Progressista: Os conflitos so encarados como inevitveis. Se geridos com
habilidade, podem ser muito benficos, contribuir para o desenvolvimento das
pessoas e organizaes e revelar questes importantes, como, por exemplo, as
falhas que uma determinada soluo que estava para ser adotada continha.

Na rea de Teste de Software estamos sempre descobrindo problemas e ao relatar tais,
podemos acabar gerando conflitos, devido a existncia de pontos de vista diferentes, por
exemplo: a equipe de Teste percebeu uma inconsistncia e falta de padro na maneira de
validao dos campos, que hora feita com caixa de mensagens (message box) e hora
utilizando rtulos (labels) e decide reportar tal problema para a equipe de desenvolvi-
mento, que por sua vez entende que isso no um problema, pois a validao feita de
acordo com cada formulrio, podendo portanto ser diferente. Surgi assim um impasse,
entre a equipe de Teste e a de Desenvolvimento, que dependendo dos grupos, s poder
se resolvido com a ao do gestor do projeto.

Quanto a resoluo de conflitos h cinco possveis abordagens:

1. Enfrentamento - o mtodo mais utilizado pelos gestores de projeto. Envolve
a cooperao franca no sentido de criar uma soluo que satisfaa a todas as
partes envolvidas (ganha-ganha).
2. Compromisso quando o enfrentamento no funciona, costuma-se tentar o
compromisso, onde as partes conflitantes barganham at chegar a uma soluo
aceitvel por todas. Pode ser adequado quando h um impasse, todas as partes
precisam ganhar alguma coisa e no h tempo.
3. Moderao corresponde a acomodar ou favorecer. Busca-se desarmar o
contexto emocional e focar no objetivo a ser atingido, mesmo que seja
necessrio uma das partes sacrificar suas prprias demandas para satisfazer as
das outras partes.
4. Imposio um estilo competitivo, controlador ou dominador de resolver os
conflitos. Podendo ser legtima, quando a situao crtica, h muito em jogo,
princpios importantes esto em risco, a relao entre as partes no muito
importante e uma resoluo rpida necessria.

205
5. Recuo aqui tenta-se evitar completamente o conflito ou adi-lo. Ser uma
soluo temporria, porque o problema no resolvido. Podendo ser uma opo
quando no se poderia ganhar, acredita-se que o problema pode desaparecer por
si s ou o atraso , em si, um ganho.

Como vimos o mtodo do enfrentamento o mais utilizado e juntamente com ele
podemos adotar a metodologia sistemtica TRIZ (Teoria da Resoluo de Problemas
Inventivos), criada por G. S. Altshuller, um brilhante pensador de origem judaico-russa.
Ela orientada ao ser humano e baseada em conhecimento, para a resoluo de
problemas inventivos.

Pela TRIZ os conflitos so contradies, ou seja, declaraes que afirmar coisas
aparentemente incompatveis ou opostas. Ela configura-se como a abstrao,
compilao e organizao das melhores formas de resolver problemas na forma de
estratgias e princpios. Isso aconteceu primeiro, nas engenharias mais antigas (os
primeiros estudos de Altshuller envolveram solues da engenharia mecnica, civil,
eltrica e qumica) e, atualmente, acontece em todas as reas do conhecimento
(publicidade, artes, pedagogia, administrao, etc.).

O primeiro passo a identificao das contradies, lembrando que quanto mais a
contradio parecer impossvel de resolver, melhor. Isso significa que o pano de fundo
est posicionado para que no sejam facilmente aceitas as solues de compromisso e,
portanto, que cresce o potencial de chegar a soluo verdadeiramente inventiva.
Aps formular a contradio, necessitamos resolv-la. A soluo envolve quatro
possibilidades, apontadas pelos princpios de separao: no espao, no tempo, no
sistema e conforme a condio.

Para entender melhor, vamos utilizar essa metodologia para solucionar o seguinte
problema:

A fbrica de software TXY reconhecida por entregar os projetos no tempo hbil,
porm h um projeto que est com atraso e a gerncia de projeto j est preocupada
com tal atraso e para tentar evit-lo, foi decidido o encerramento dos testes
prematuramente. No entanto a equipe de Testes est relutante a essa deciso e se
justifica dizendo que o encerramento prematuro dos testes trar como conseqncia
uma maior necessidade de manuteno do sistema o que custar muito mais caro para
a empresa, portanto percebeu-se que o encerramento dos testes prematuramente
resultar em mais custos no futuro.

No exemplo acima, encontramos a seguinte contradio: Precisamos garantir a
qualidade do software, mas no temos tempo hbil para isso. Formulada a contradio
vamos tentar utilizar os princpios de separao em busca de idias:

Separao no espao
o Aumentar a equipe de desenvolvimento, em busca de uma acelerao do
desenvolvimento para que haja um maior tempo para os testes.
Separao no tempo
o Expandir a capacidade no tempo: trabalhar at mais tarde e se necessrio
trabalho durante o final de semana.
Separao conforme a condio

206
o Negociar com cliente um maior prazo, justificando com a garantia de
maior qualidade do software.
Separao no sistema
o Alguns recursos do desenvolvimento executaro testes em paralelo com
a equipe Testes.

Como podemos perceber existem diversas possibilidades de solucionar os problemas
sem que o projeto precise ser atrasado e sem encerrar a etapa de testes prematuramente.

E as idias de soluo que no sejam imediatamente viveis podem ser novamente
analisadas com o uso do mtodo de separao, at que alternativas ganha-ganha sejam
encontradas.

Concluirmos que a utilizao da metodologia TRIZ capaz de gerar idias inventivas
em um curto espao de tempo, a fim de encontrar a melhor maneira para solucionar os
problemas. E percebemos que a resoluo dos problemas muitas vezes, depende apenas
de boa vontade das partes e da capacidade de pensar em conjunto, tendo como foco o
bem para todos e no o de um nico ser.

Fonte:

De Carvalho, M. A. Resolvendo Conflitos na Gesto de Projetos atravs da metodologia
TRIZ. Revista Mundo Project Management (Mundo PM), Rio de Janeiro, Ano4,
n20, p. 18-22, Abr/Mai 2008.
http://www.decarvalho.eng.br/triz.html



207
2. 3P Piores Prticas de Projeto (parte 1)
Melhores Prticas de Projeto um dos temas que mais vem ganhando espao no mundo
de TI, pois percebemos que um bom gerenciamento fundamental para o sucesso do
projeto. Mas se temos as melhores prticas, quais seriam as piores prticas?

Abaixo explico algumas das piores prticas de projeto (3P) que devemos tomar cuidado
para no cometemos:

No envolvimento dos stakeholders - Por mais absurdo que possa parecer, essa uma
das prticas que mais acontecem, na qual um ou mais stakeholders (envolvidos com o
projeto) no participam ativamente do projeto, ou participam apenas no incio,
ocasionando vrios problemas, como requisitos mal especificados. Este uns dos
problemas que afetam diretamente o prazo e custo do projeto e em determinados casos,
pode at representar o fim de um projeto. Um exemplo de no envolvimento dos
stakeholders aconteceu com o projeto do Rodoanel, onde grupos ambientais no foram
colocados como stakeholders no incio do projeto, e esses acabaram gerando impasses
para o governo, resultando em grandes atrasos nas obras e aumento do custo.

Contratao de funcionrios, quando o projeto est atrasado - No desespero,
muitos gerentes acabam contratando novos funcionrios, quando o prazo do projeto j
est com seu prazo vencendo, pois acreditam na teoria de quanto mais pessoas mais
produtividade. Porm, na prtica a histria outra, esse novo funcionrio, por mais
habilidoso e experiente que seja, ter que receber um treinamento a ser dado por um
funcionrio, portanto o projeto perder um funcionrio ao invs de ganhar um. Para
entender melhor, seria como voc contratar um novo jogador de futebol faltando cinco
rodadas para o trmino do campeonato, por mais habilidoso que ele seja, ele ter o seu
tempo de adaptao e se ele for colocado em campo, o desentrosamento pode prejudicar
o time.

Falta de documentao - essa umas prticas mais adotadas pelas empresas, por
parecer a curto prazo uma boa prtica, pois economizar tempo. Porm, a longo prazo
ela pode fazer com que o projeto seja o caos. Imagine a seguinte situao: na empresa
XPTO Z programador snior e responsvel por um mdulo crtico da aplicao,
porm no costuma documentar nada que faz, nem ao menos comenta o cdigo. Um
certo dia, Z consegue um emprego melhor e sai da XPTO. E agora como o projeto
continuar sem o Z? Ele era o nico que tinha conhecimento sobre aquele mdulo e
sem esse mdulo o projeto no poder ser entregue.

pessoal, vocs podem estarem achando que tal situao apresentada no acontece nas
empresas, mas por mais incrvel que parea essa uma das que mais acontece e que faz
muitos dos gerentes arrancarem os cabelos (quando ainda tem). Por isso o projeto tem
que ser documentado e bem documentado.

Documentar no final - No sei o que pior, no documentar ou documentar no final do
projeto. Uma documentao feita no final do projeto, por mais esforo que se faa, ser
fraca e imprecisa e a razo para isso simples, as pessoas acabam esquecendo o que
elas fazem. Para exemplificar uma pergunta clssica: o que voc comeu ontem no
almoo?

208
Talvez, voc at se lembre do que voc comeu ontem, mas e antes de ontem, e na
semana passada?

Se eu fosse pedir para voc me fazer uma documentao do seu almoo por um ms, ela
teria que ser feita antes do almoo, onde voc colocaria qual o restaurante que voc vai
almoar, qual ser o pedido, etc; durante o almoo, situao em que voc falaria sobre a
qualidade da comida escolhida; e aps o trmino do almoo, voc iria descrever como
foi o atendimento e quanto custou o almoo.

Logo percebemos que a documentao uma tarefa que tem que ser feita, durante todo
o projeto e no somente durante uma determinada etapa do projeto.

Bem pessoal, por hoje s. Em breve trarei a segunda parte do 3P. At a prxima!


209
3. 3P Piores Prticas de Projeto (parte 2)
Continuamos falando sobre as piores prticas de projeto, mais uma vez com o intuito de
alertar e prevenir tais prticas:

Telefone sem fio a comunicao essencial no apenas para a sobrevivncia do ser
humano, mas como tambm para a dos projetos. Portanto, devemos estar sempre nos
perguntando se a informao est sendo gerada, coletada, documentada e passada para a
pessoa certa. Segundo o PMI h quatro processos de gerenciamento das comunicaes:

Planejamento das comunicaes determinao das necessidades de
informaes e comunicaes das partes interessadas no projeto.
Distribuio das informaes colocao das informaes necessrias
disposio das partes interessadas no projeto no momento adequado.
Relatrio de desempenho coleta e distribuio das informaes sobre o
desempenho. Isso inclui o relatrio de andamento, medio do progresso e
previso.
Gerenciar as partes interessadas gerenciamento das comunicaes para
satisfazer os requisitos das partes interessadas no projeto e resolver problemas
com elas.

Eu quero eu posso Essa uma prtica muito natural, sempre achamos que basta
querer para poder realizar ou obter algo. Em projetos devemos avaliar o quanto de
esforo que ele demandar e se o time est preparado, caso contrrio o projeto ter
grandes chances de sofrer atrasos, aumento de custo ou at fracassar. Um exemplo dessa
prtica foi o Pan de 2007, o maior evento poliesportivo j realizado no pas, onde
devido a falta de preparo dos realizadores e a problemas polticos o oramento final
ficou 1.289% a mais do que estava previsto inicialmente.

Excesso de documentao documentao um dos fantasmas em projetos de TI, isso
porque o bom senso muitas vezes no usado. E quando a equipe do projeto tem grande
preocupao em documentar ou a metodologia usada tem como base a gerao de
documentos para tudo, um risco que aparece o excesso de documentao, onde
podemos ainda estar realizando a anlise de risco e o prazo do projeto j ter acabado.
Uma das medidas para evitar tal prtica sempre averiguar a importncia que a
documentao ter para o projeto e o que ser documentado e o que no ser.
Lembrando que mais importante do que documentao gerada software funcionando.

Achmetro - por ltimo umas das prticas mais utilizadas no somente em projetos de
TI, mas como tambm na nossa vida. Afinal, o achmetro tem como base o conselho
que segundo o texto de Mary Schmich, que foi transformado em um discurso musicado
por Pedro Bial com o nome Filtro Solar:

Conselho uma forma de nostalgia. Compartilhar conselhos um jeito de
pescar o passado do lixo, esfreg-lo, repintar as partes feias e reciclar tudo por
mais do que vale. (Advice, like youth, probably just wasted on the young-
Mary Schmich)


210
Devemos usar o achmetro somente em momentos que realmente no teramos como
obter um histrico de dados, como por exemplo, no primeiro projeto de uma recm
criada empresa. Sempre que possvel, precisamos justificar as nossas aes e estratgias
com base em informaes e no na opinio prpria ou de outras pessoas.
Aqui chego ao fim das 3P, mas com certeza h ainda muitas piores prticas de projetos
que no foram citadas. Por isso, caso algum queira colocar alguma prtica que
vivenciou ou conhece, por favor sinta-se vontade. O seu comentrio ser bem-vindo!

Fonte:

Um Guia do Conjunto de Conhecimentos em Gerenciamento de Projetos (Guia
PMBOK); Terceira edio, 2004. Project Management Institute, Four Compus
Boulevard, Newton Square, PA 19073-3299 EUA.
http://www1.folha.uol.com.br/folha/esporte/ult92u450247.shtml


211
Modelos
Modelos

212
1. MPS.BR
Pessoal, participei nessa semana de uma palestra sobre MPS.BR, ministrada por Sarah
Kohan e David Yoshida, duas pessoas que participam ativamente na difuso do
MPS.BR no Brasil. Abaixo explico um pouco sobre esse novo programa para Melhoria
de Processo do Software Brasileiro.
O que o MPS.BR?
Ele um programa para Melhoria de Processo do Software Brasileira, criado em
dezembro de 2003, voltado especialmente para pequenas e mdias empresas, com o
objetivo de definir e aprimorar um modelo de melhoria e avaliao de processo
de software.
O MPS.BR tem algum apoio?
O MPS.BR conta com apoio do Ministrio da Cincia e Tecnologia (MCT), da
Financiadora de Estudos e Projetos (FINEP) e do Banco Interamericano de
Desenvolvimento (BID). Sendo coordenado pela Associao para Promoo da
Excelncia do Software Brasileiro (SOFTEX).
O MPS.BR baseado em algum modelo ou norma?
Ele tem como base tcnica trs fontes, sendo elas:
ISO/IEC 12207 A norma ISO/IEC 12207 e suas emendas 1 e 2 estabelecem
uma arquitetura comum para o ciclo de vida de processos de software com uma
terminologia bem definida. Contm processos, atividades e tarefas a serem
aplicadas durante o fornecimento, aquisio, desenvolvimento, operao e
manuteno de produtos de software e servios correlatos.
ISO/IEC 15504 A ISO/IEC 15504 presta-se realizao de avaliaes de
processos de software com dois objetivos: a melhoria de processos e a
determinao da capacidade de processos de uma unidade organizacional.
CMMI O CMMI (Capability Maturity Model Integration) um modelo de
maturidade para o desenvolvimento de software. Sendo um conjunto de boas
prticas para o desenvolvimento de projetos, produtos, servios e integrao de
processos.
Como o MPS.BR est organizado?
Assim como o CMMI, o MPS.BR organizado em nveis de maturidade, nos quais a
melhoria continua do processo e o cumprimento de novos atributos se faz necessrio
para alcanar o nvel acima.


213
Os 7 nveis de maturidade
O MPS.BR define sete nveis de maturidade, que podem ser comparados ao nveis do
CMMI como na figura abaixo:

Figura 97 - 7 nveis de maturidade (retirado do site da empresa Pentagrama)

A escala de maturidade se inicia no nvel G e progride at o nvel A. Para cada um
destes sete nveis de maturidade atribudo um perfil de processos que indicam onde a
organizao deve colocar o esforo de melhoria. O progresso e o alcance de um
determinado nvel de maturidade do MPS.BR se obtm quando so atendidos os
propsitos e todos os resultados esperados dos respectivos processos e dos atributos de
processo estabelecidos para aquele nvel. A diviso em estgios, embora baseada nos
nveis de maturidade do CMMI tem uma graduao diferente, com o objetivo de
possibilitar uma implementao e avaliao mais adequada s micros, pequenas e
mdias empresas. A possibilidade de se realizar avaliaes considerando mais nveis
tambm permite uma visibilidade dos resultados de melhoria de processos em prazos
mais curtos.
Como ele implementado e avaliado?
A implementao e avaliao do MPS.BR dividida em seis etapas:
O que requerido?
o Definio do nvel de maturidade desejado
o Definio da rea/unidade da empresa que ser preparada para a
avaliao MPS.BR
Como est o processo?

214
o Realizao de diagnstico do processo, para que se possa saber como
esto os processos atuais da empresa.
o Conhecer a prtica da empresa para o nvel requerido.
Plano de adequao
o Com base nos resultados do diagnstico elaborado um plano do projeto
de implementao do MPS.BR na empresa
Implementar processos adequados
o Treinamento das pessoas da empresa que sero responsveis pela
implementao do MPS.BR, geralmente duas pessoas: um que ser o
coordenador e o outro ser o assistente.
o Assessoramento a empresa, realizao de reunies podendo ser remotas
ou presenciais.
o Avaliao de atendimento s metas realizadas, sendo realizada duas
avaliaes: a de 50% feita aps 6 meses do incio do programa e a de
100% feita aps 12 meses.
Avaliao preliminar dos processos
o Antes da avaliao final realizada uma avaliao de atendimento
meta de 100%, com intuito de verificar o nvel de prontido da empresa
em relao ao nvel de maturidade desejado.
Avaliao oficial
o Atendendo meta de 100%, avaliada anteriormente, inicia-se contatos
com a Instituio Avaliadora que realizar a avaliao oficial, que
atribuir o nvel de maturidade encontrado.
o A Instituio Avaliadora no pode ser a Instituio que implementou o
MPS.BR na empresa.
Qual o custo da MPS.BR?
O custo para o nvel G, o primeiro nvel, est em torno de R$ 70.000,00. J para o nvel
F estima-se R$ 104.000,00. Sendo que esses preos podem ser negociados e parcelados
de acordo com a necessidade da empresa.
Quanto tempo demora a implantao do MPS.BR?
O tempo do projeto dura em mdia 15 meses, podendo variar de acordo com o grau de
comprometimento das pessoas envolvidas.


215
Concluso
A melhoria do processo de software uma necessidade cada vez maior nas empresas de
TI. Alm do mais, muitas delas ainda sequer possuem processos definidos. Diante dessa
realidade, o MPS.BR uma forma de alcanar a maturao dos processos que vem
crescendo a cada ano, com novas empresas adquirindo a certificao ou melhorando o
seu nvel. Sendo muito bem aceita no mercado nacional (no mercado internacional ela
ainda no reconhecida). Portanto, a MPS.BR mais recomendada para empresas que
tem sua cartela de clientes localizados no Brasil. Para as demais, ela se apresenta como
um primeiro passo antes do CMMI, j que a sua adequao mais simples e seu custo
menor comparado ao CMMI.
E devemos ter sempre em mente que os modelos, normas e etc, existem para auxiliar na
melhoria do processo da nossa empresa e credibiliz-la perante aos clientes. E s so
possveis de serem conquistados com o envolvimento das pessoas e por isso devemos
estar atento no s a melhoria dos processos, mas tambm a de nossa equipe. Afinal,
como j dizia Carl Gustav Jung No o diploma mdico, mas a qualidade humana, o
decisivo.
Fonte:
http://www.softex.br/mpsBr
SOFTEX. MPS.BR Guia Geral (Verso 1.2), Junho de 2007.


216
Desenvolvimento de Software
Desenvolvimento de Software

217
1. Qual a melhor metodologia?
Essa uma questo polmica, e vejo muitos profissionais tentando responder e justificar
a sua resposta. E a cada vez, que eu leio algo sobre o assunto, fico com uma outra
dvida: Ser que existe a melhor metodologia para o desenvolvimento de software?
Mas antes de abordar as metodologias de software, vamos definir o que metodologia.
De acordo com a Wikipdia, Metodologia o estudo dos mtodos. Hmmm, no
ajudou muito, neh
Vamos agora ver o que o Michaelis tem a dizer sobre metodologia:
1 Estudo cientfico dos mtodos. 2 Arte de guiar o esprito na investigao da verdade. 3
Filos Parte da Lgica que se ocupa dos mtodos do raciocnio, em oposio Lgica
Formal. M. didtica: teoria dos procedimentos de ensino, geral ou particular para cada
disciplina; didtica terica.
Essa segunda definio bem profunda, e ajudaria bastante os marqueteiros, imagina s
um falando: A metodologia da nossa empresa, representa a arte de guiar o esprito ao
cumprimento dos requisitos.
Juntando as definies que foram apresentadas, podemos dizer que metodologia um
conjunto de procedimentos que so realizados visando um objetivo maior.
Vamos agora, ir para o mundo do desenvolvimento de software, no qual h vrias
metodologias que podem ser seguidas. Podemos dividir as principais metodologias em
trs categorias:
Cascata: Cascata Clssica, Cascata Modificada e Modelo V;
Iterativa: Modelo Espiral e RUP;
gil: Extreme Programming (XP) e Scrum.
Cada uma dessas metodologias, como tudo na vida, tem suas vantagens e desvantagens,
abaixo apresento uma comparao das metodologias, de acordo com alguns cenrios:

218

Figura 98 - Comparao entre as metodologias (retirado do material da AzIT)

Como pode ser visto na figura acima, de acordo com os cenrios apresentados, a melhor
metodologia seria o RUP. A razo para esse fato, que a figura foi retirada do material
para a certificao IBM Certified Specialist Software Quality, e o RUP um
processo proprietrio criado pela Rational Software Corporation, adquirida pela IBM.
Logo a IBM apresenta o RUP como melhor metodologia, o que pode at ser verdade,
dependendo do projeto de software.
Agora voc pode est se perguntando: Como assim, pode at ser verdade, ou uma
metodologia a melhor ou no !.
A est justamente o erro: tentar definir a melhor metodologia. Buscar a melhor
metodologia para a sua empresa algo louvvel, afinal, boa parte das empresas de TI,
ainda usam a metodologia VAMO QUE VAMO, ou pior ainda, a EMPURRANDO
COM A BARRIGA. Mas selecionar a melhor e coloc-la goela abaixo na sua empresa,
com certeza no o melhor caminho, e ao invs de achar uma soluo, voc vai achar
mais problemas.

219
Para tentar explicar melhor o meu ponto de vista, vou fazer uma analogia com os
eletrodomsticos e eletrnicos da sua casa. Voc como um consumidor atento e sempre
buscando a qualidade, alinhada ao custo-benefcio, tem eletrodomsticos e eletrnicos
das diversas marcas: LG, Sony, Arno, Brastemp, Consul, Bosch, Philips, etc. Cada um
dos eletrodomsticos e eletrnicos atende uma necessidade da sua famlia, e para cada
um h um melhor fabricante, portanto, voc no vai comprar tudo de uma nica marca,
at porque uma nica marca no fabrica todos os tipos de eletrodomsticos e
eletrnicos.
Ao escolher uma metodologia voc tambm tem diversas necessidades e vrias
metodologias que buscam saciar a sua necessidade. Voc at pode encontrar tudo o que
voc precisa em uma nica metodologia, mas dificilmente voc vai seguir todos os seus
conceitos e mtodos. O melhor a ser fazer tentar encontrar um meio-termo, ver o que
h de melhor em cada metodologia e o que se adapta a sua realidade. E quando a sua
realidade mudar, mude tambm a sua metodologia, devemos sempre lembrar que a
mudana no ruim, e sim uma grande oportunidade.
E lembre-se que se uma metodologia funcionou bem em um projeto, era poder no
funcionar to bem em outro projeto, e vice-versa.
Fonte:
Engineering Quality in Software Development, Module 1: Overview of Software
Development Practices (AzIT)


220
Humor
Humor

221
1. As Etapas do Desenvolvimento de Software


222

Figura 99 - Desenvolvimento de Software


223
2.Vida de Programador
Uma homenagem (bem atrasada) aos nossos amigos programadores pelo dia do
programador, comemorado no dia 12 de Setembro.


Figura 100 - Vida de programador

Fonte:

Cartoon adaptado do blog SuperfolderK28


224

Dicas


Dicas

225
1. Padro de Nomes de Componentes
Quantas vezes escrevendo um caso de teste ou reportando um bug, a gente no acaba se
esquecendo do nome de um determinado componente ou at confundindo com outro. E
em equipes de Teste de Software, muito comum uma pessoa acabar citando o
componente de maneira diferente da outra. O que acaba resultando na falta de
padronizao e at pode comprometer o entendimento do desenvolvedor, que por sua
vez, est acostumado a tratar o componente utilizando outro nome.

Tendo em vista evitar tais situaes, montei uma galeria de imagens, que apresenta os
nomes dos componentes mais utilizados em aplicaes Web, espero que sirva de ajuda:

Figura 101 - Padro de nomes de componente

226

Figura 102 - Padro de nomes de componente

227

Figura 103 - Padro de nomes de componente

228
2. Revistas sobre Teste e Qualidade de Software
Abaixo apresento 5 revistas que trazem interessantes artigos sobre Teste e Qualidade de
Software, todas elas podem ser obtidas de forma gratuita em seus respectivos sites:
Engenharia de Software Magazine: O grupo DevMedia lanou em Maro deste ano a
revista Engenharia de Software Magazine (ES Magazine), cujo foco preencher uma
lacuna que existe no mercado editorial brasileiro - Engenharia de Software
Aplicada. O seu objetivo levar ao mercado brasileiro de desenvolvimento de software
conceitos e prticas associadas ao uso da engenharia de software. A primeira edio da
ES Magazine, que pode ser baixada gratuitamente no site, traz em sua capa Qualidade
de Software, abordando o tema de forma muito clara e didtica. (download)
Professional Tester: Embora a sua publicao tenha sido encerrada, em Maro de
2006, o site da revista ainda opo de download das edies 14 18 e dos artigos da
edies 21 e 22. Ela foi umas das primeiras revistas a ter como foco a rea de Testes de
Software. (download)
Software Test & Performance: Lanada em 2004, pela BZ Media LLC (que tambm
produz a SD Times e a Systems Administration News), a Software Test & Performance
traz mensalmente excelentes artigos sobre o que h de mais atual na rea de Qualidade e
Teste de Software. (download)
TE Testing Experience: A TE Testing Experience teve o seu lanamento em
Maro de 2008, reunindo artigos de profissionais experientes e bem conhecidos da
Europa. Ela aborda de uma maneira bem abrangente a rea de Qualidade e Teste de
Software. E est em sua segunda edio e j atingiu mais de 75.000 leitores pelo mundo
todo, sendo produzida por uma comunidade de autores, que est sempre aberta a novos
profissionais, do mundo todo, que queiram contribuir com novos artigos. (download)
What Is Testing Magazine: What Is Testing a primeira revista sobre Testes de
Software da ndia, um dos maiores plos de TI do mundo. Seu lanamento foi realizado
em Abril deste ano, com a proposta de trazer artigos de autores do mundo todo.
(download)
Fonte:
DevMedia. Editorial. Engenharia de Software Magazine, Brasil, Ano 1 1 Edio
2007.
http://www.professionaltester.com/
http://www.stpmag.com/
http://www.testingexperience.com
http://www.whatistesting.com

229
3. O Twitter como meio de comunicao interna
Acredito que a maioria de vocs devem saber da existncia, de um tal de Twitter, mas
ainda no descobriram uma real utilidade para ele.
De tanto ouvir falar desse Twitter, resolvi ver o que o pessoal tanto faz com nele. E
acabei descobrindo que a maioria dos twitteiros (usurios do Twitter) utiliza-o para
fazer um auto Big Brother (coisa de doido, neh no!?), principalmente sendo um auto
Big Brother da vida pessoal (privacidade luxo).
Porm, de repente, pensei numa possvel utilidade para o Twitter: usar ele para
comunicao interna. Afinal, a comunicao interna de extrema importncia em
qualquer empresa, e se houver uma nova maneira de torn-la mais dinmica e acessvel,
melhor ser.
Mas a surgiu um problema, esse canal de comunicao deve ser privado, e o Twitter
pblico.
E pesquisando para ver se h alguma maneira de tornar o Twitter privado, descobrir que
ele tem uma opo para proteger os meus tweets (nome dado a cada mensagem postada
no Twitter). Pronto problema solucionado!
At comeamos a brincar um pouco com ele na empresa. E as primeiras impresses
foram boas.
Depois pesquisando um pouco mais sobre o Twitter, encontrei um irmo dele,
o Yammer, um Twitter para empresas.
Sensacional! O Yammer atingi melhor o objetivo de servir como um meio de
comunicao interna, e mais seguro do que o Twitter.
Ainda no estamos utilizando para valer o Yammer aqui na empresa. Mas acredito que
ele possa ajudar na nossa comunicao interna.
Ahhtambm acabei entrando nessa onda de Twitter, nele estou falando de tudo um
pouco (menos fazendo um auto Big Brother), se algum quiser conferir, ou melhor me
seguir, abaixo se encontra o endereo do meu Twitter pessoal:
http://twitter.com/FabricioFFC
Dica
Para acompanhar as pessoas e twittar (verbo, ao ou efeito de postar alguma coisa no
Twitter), h uma excelente extenso para o Firefox, o TwitterFox, que pode ser obtido
no link abaixo:
https://addons.mozilla.org/pt-BR/firefox/addon/5081

230
Saiba mais
Sobre o Yammer
http://www.yammer.com/
http://www.twitterbrasil.org/2008/10/30/um-twitter-para-empresas/
Sobre o Twitter
http://www.twitterbrasil.org


231
Off

Off

232
1. TCC
Ufa! Finalmente consegui terminar o meu TCC (\O/), cujo nome : Interface Homem-
Mquina: Melhores Prticas de Usabilidade. Ele foi o motivo desse ms pouco
produtivo de posts, afinal no consegui fugir da praxe do ms da entrega do TCC,
conhecido tambm, como ms anti-social (rsrs), no qual perdemos finais de semana e
noites em claro, fazendo o bendito trabalho de concluso de curso. Por sorte, no
precisei perder noites de sono, apenas algumas horas.
Mas como dizem: entre mortos e feridos, salvaram-se todos. E estou de volta, a um
dos meus lazeres preferidos que escrever (tem doido para tudo mesmo), se bem, que
nesse ms o que mais fiz foi escrever, e no posso deixar de admitir que apesar de tudo
foi divertido fazer o TCC, alm de ter sido uma experincia nova. E com certeza ele
render vrios posts, pois acredito que a Usabilidade um requisito de Qualidade de
Software que merece maior preocupao e ateno.
Bem, vou parar por aqui, seno vou ter que criar mais uma categoria: Fala que eu te
escuto.
Esse post foi mais para dizer que estou vivo e em breve estarei de frias escolares (desta
vez eterna, pelo menos do curso de ADS da FTT), e poderei dedicar mais tempo para
o QualidadeBR. Espero que vocs continuem acompanhando, pois haver novidades!


233
2. Paixo ou dinheiro?
Caros leitores,
O pessoal que me conhece, sabe que uma das minhas paixes a Formula 1 e como
muitas devem ter ficado sabendo, a equipe Honda deixou a categoria. Mas no ser
sobre a F1 que irei comentar nesse post e sim sobre algo que me preocupa: o prazer em
fazer o que gosta. E aproveito para lhes fazer uma pergunta: Por que voc trabalha?
Logicamente, que uma das primeiras respostas ser para garantir o meu sustento e de
minha famlia (alis, essa seria minha resposta tambm), porm uma vez eu li em algum
lugar (no me lembro onde), que o ser humano ao invs de viver est sobrevivendo.
Para mim, a diferena est na obrigao, quando fazemos algo por obrigao ou algo
que no seja da nossa natureza estamos sobrevivendo. J quando fazemos algo com
amor e nos divertindo, a sim estamos vivendo.
Bem, vou tentar linkar melhor essa histria da F1, apresentada no incio do post, com
o nosso mundo (TI). Vejo muitos colegas meus buscando $$$ e mais $$$, uma busca
sem fim, pois quanto mais temos mais queremos ter. E vejo poucos buscando o prazer,
afinal voc ir passar mais de 86.400 horas (8 horas X 20 dias X 12 meses X 45 anos)
da sua vida trabalhando, isso sem contar as horas extras, que algo muito freqente na
nossa rea.
Na F1 o cenrio atual no muito diferente, os chefes das equipes que antes eram os
apaixonados por velocidade e pela F1, agora so os manda-chuvas de grandes
corporaes que esto mais preocupados com o lucro e aumento do marketing que
conseguiro com a F1. E a maior diferena o fato de quando as coisas vo mal eles so
os primeiros a pularem fora do navio, enquanto os apaixonados lutam at o fim para
tentar manter a categoria, pois h certas coisas que s apaixonados conseguem fazer.
Esse um dos motivos pelo qual diversos sistemas falham e muitos projetos no
terminam. As pessoas no esto comprometidas e sim apenas envolvidas (a
velha histria do porco e da galinha). E a razo da falta de comprometimento muitas
vezes ausncia da paixo, pois voc no ser comprometido com algo que voc no
gosta. Por isso, volto a frisar, que devemos sempre buscar fazer o que a gente gosta,
pois me lembro muito bem, de uma palestra que assisti sobre a rea de Jornalismo,
quando tinha uns 15 anos, onde uma jornalista, disse: Se voc for bom, com certeza
voc ganhar bem..
Para encerrar esse post, aqui fica uma dica, de algum que ainda no encontrou a mina
de ouro, mas que j descobriu a sua estrada: Siga os seus princpios, quando encontrar
um atalho, siga o seu corao ao se deparar com uma bifurcao e siga a sua
inteligncia ao se deparar com os obstculos.
Nota: Como vocs perceberam, estou tentando trazer assuntos diferentes e no apenas
sobre Testes e Qualidade de Software, pois muitas vezes gosto de compartilhar

234
pensamentos e opinies, por isso sintam-se vontade para comentarem. Mas no se
preocupem, que o foco do QualidadeBR ainda ser Testes e Qualidade de Software,
afinal uma rea que eu tenho paixo em trabalhar e estudar.


235
3. Apresentao TCC
Na semana passada, para ser mais exato, na sexta-feira dia 12 do 12 (que coisa, hein),
fiz a minha apresentao da defesa de trabalho de concluso de curso.
Na apresentao, para variar, fiquei hiper nervoso, mas segundo o pessoal que estava
presente, foi legal a apresentao. A parte que eu gostei, foi a das perguntas. Todo
mundo se preocupa muito nessa hora, mas eu estava tranquilo, afinal acredito que
ningum sabia mais do assunto do que eu e o Jayson, minha dupla de TCC. E ns
gostamos bastante do assunto, ento seria at legal confrontar opinies com o pessoal da
banca.
As perguntas foram bem legais, gerou bastante discusso. Duas delas eu achei bem
interessante, uma foi sobre a usabilidade nos celulares e a outra sobre o impacto no
hardware, causado por uma boa usabilidade.
Na primeira, a discusso gerada foi em torno da usabilidade do celular, que est num
passo a frente da existente nos computadores. Fato que justificado, devido ao nmero
de usurios de celulares que muito maior e mais diversificado que os de computador,
logo, a preocupao com a usabilidade, se torna mais inerente no desenvolvimento dos
softwares para celular.
A segunda questo tocou no assunto entre usabilidade versus desempenho. Muitos
sistemas com uma usabilidade melhor, acabam sendo mais pesados e exigindo mais do
hardware, exemplo o Pacote Office 2007, que mesmo tendo uma melhor usabilidade do
que a verso 2003, ainda no emplacou. Ou seja, de nada vale uma interface mais usual,
se ela no consegue ser processada pelo hardware. Mas, para ter uma interface com boa
usabilidade no preciso oferecer um design mais pesado, muitas vezes, a simplicidade
resolve boa parte dos problemas de usabilidade, como exemplo temos o navegador do
Google, o Chrome, e a distribuio Linux Linpus.
Quem quiser conferir a apresentao, ela est sendo disponibilizada no link abaixo, caso
algum tenha alguma dvida, sugesto ou crtica, sinta-se vontade em colocar nos
comentrios.
Download da apresentao
Para encerrar esse post, tenho alguns agradecimentos a fazer (hehehe), de pessoas que
ajudaram no desenvolvimento desse trabalho:
- Ao Jayson, minha dupla de TCC, que sempre esteve preocupado com a qualidade do
trabalho e mostrou grande dedicao, mesmo nos momentos difceis.
- Ao Andr Pantalio, que uma das pessoas que eu tenho um prazer enorme de
trabalhar, e que me emprestou vrios materiais sobre usabilidade e deu boas idias para
o trabalho.

236
- Ao Prof. Ms. Flvio Viotti, que mesmo com as dificuldades que tivemos, ainda estava
sempre nos cobrando e se preocupando com o andamento do TCC.
- Por fim, a todos os alunos de ADS6, pelas risadas, conhecimentos, emoes e brigas,
vividas nesses trs anos, que com certeza ficaro na memria e no corao para toda a
vida.


237
4. Feliz Ano Novo
Mais um ano est se encerrando. E 2008 deixar saudades.
Mas como dizem: A msica no pode parar. O ano de 2009 est chegando, e como
sempre, temos novos planos e desafios. E com o QualidadeBR no diferente.
Em 2009 teremos novidades, e o desafio de ser um blog de referncia em Testes e
Qualidade de Software aqui no Brasil, e quem sabe at do mundo. Afinal, temos que
sonhar grande e o mais importante est sempre lutando e nunca desistir, pois somos
brasileiros e to capazes quanto os gringos.
Portanto, desejo a todos um maravilhoso 2009, que nesse ano voc possa realizar os
seus sonhos e superar os desafios com alegria. Obrigado, do fundo do corao, por
acompanhar o QualidadeBR. At 2009!!!

Figura 104 - Feliz Ano Novo



238
5. Errar humano
Hoje, conversando com um amigo meu no trabalho, sobre como foram os testes durante
a atualizao do ambiente de produo, ele me disse que ele acabou errando em uma
mudana e teve que derrubar e subir novamente o ambiente, que acarretou em um
pequeno atraso na atualizao. Isso durante os testes de performance, que so
executados no ambiente de produo, logo aps, os testes funcionais.
O que me chamou dessa histria toda, no foi o fato dele ter cometido um erro, e sim a
cara e a forma que ele me contou. Como se ele tivesse feito algo, realmente ruim, como
se a falha tivesse ocorrido devido a uma falta de ateno o algo do tipo. Mas no, a falha
ocorreu, devido a complexidade do teste e do sistema. Para se ter uma idia, na nossa
equipe, ele a nica pessoa que executa os testes de performance e HA (High-
Availability), e tais testes exigem um alto conhecimento da aplicao e sua arquitetura,
alm da ferramenta utilizada, o SIPp. O que torna esse profissional, um diferencial para
a equipe. E o erro cometido por ele, eu no iria cometer, pois no tenho conhecimento
suficiente para fazer esses testes, logo no iria tentar fazer o teste.
Logo, percebemos algo muito importante, s erra aquela pessoa que tenta. Sei que errar
parece ser algo ruim. E parcela desse pensamento, deve-se a nossa formao acadmica,
na qual quando cometamos algum erro, logo recebamos alguma punio ou um belo
de um X vermelho.
Isso faz com que a gente, tente evitar ao mximo um erro, principalmente na equipe de
Qualidade e Testes, onde caamos falhas, que so originrias de um erro de alguma
outra pessoa. Mas, tenha a certeza, que mesmo evitando os erros, estamos sempre
correndo o risco de errar, pelo simples fato, de sermos humanos. E ns aprendemos
muito mais com um erro, do que com um acerto.
O que errado a pessoa no reconhecer o prprio erro, e pior ainda no tentar.
Lgico, que se voc ficar na sua cama deitado, voc no vai cometer nenhum erro.
Assim, como um carro no quebra, se ficar na garagem.
Por isso, se as pessoas te crucificarem por um erro, lembre-se de uma frase, dita por
algum bem conhecido: perdoa-lhes, pois eles no sabem o que fazem.
E para mim, errar no tentar.


239
6. Entusiasmo
Hoje lendo meus feeds sobre Frmula 1, vi uma notcia muito legal sobre o retorno do
Rubens Barrichello F1. Eu particularmente, sempre gostei do Rubinho, um sujeito
sereno, que nunca se deixou ser levado pelo sucesso ou influenciado pelo mundo da F1,
e o que mais me chama a ateno a sua persistncia e entusiasmo.
Ele tem 36 anos, uma famlia, 9 vitrias na F1, dois vice-campeonatos e uma condio
financeira invejvel. E poderia muito bem se aposentar da F1 e curtir a sua famlia, mas
no, ele continua com o mesmo nimo de um garoto que comeou ontem na F1. E se ele
conseguir ou no obter bons resultados na ex-Honda, agora Brawn GP, s o tempo
poder dizer. Mas com certeza ele j obteve uma grande vitria esse ano, a de provar a
todos que ainda tem competncia para fazer o que mais gosta.
Agora, outro acontecimento que me chamou ateno essa semana, a estria do Ronaldo
(o fenmeno) pelo Corinthians. E olha que eu sou Palmeirense, mas mesmo assim no
resisti ao ver na Globo.com que ele ia entrar em campo, e liguei a TV para ver a sua
estria.
E assistindo ao jogo, pude perceber a raa e vontade com que ele jogava muito maior do
que muitos jogadores que comearam ontem a jogar. Mesmo sem ritmo de jogo e ainda
fora do peso ideal, ele correu, se movimentou, chutou e driblou com a vontade de um
estreante.
O Ronaldo com certeza mais uma prova do que o entusiasmo pode fazer, um jogador
que j passou por muitas leses bem srias, ganhou duas copas do mundo (1994 e
2002), foi trs vezes eleito o melhor do mundo e mesmo assim, ainda continua se
esforando para voltar a jogar futebol, aps de mais de um ano sem jogar.
Acredito que o entusiasmo algo necessrio em qualquer rea, para qualquer
profissional. Precisamos buscar ser entusiastas em tudo que fazemos. E muitas vezes
precisamos entusiasmar as pessoas, pois o trabalho em equipe algo fundamental na
nossa rea, e com uma equipe entusiasmada as chances de um projeto ser um sucesso e
at superar as expectativas muito alta.
Quantas vezes voc j no ouviu frases do tipo: Voc no vai conseguir fazer isso;
Desisti muito complicado; O projeto est atrasado, a gente no vai conseguir
entregar no prazo; Voc est perdendo o seu tempo fazendo isso; e tantas outras.
Mas essas frases s fazem os entusiastas ficarem com mais e mais vontade de
conquistar o que deseja.
Deixo abaixo, uma frase muito boa sobre entusiasmo:
O entusiasmo a maior fora da alma. Conserva-o e nunca te faltar poder para
conseguires o que desejas. Napoleo Bonaparte

240
7. Trabalhe, trabalhe, trabalhe em equipe
Esse post mais para d uma quebrada nessa srie de resolues de questes da CTFL.
E comentar sobre algo muito importante, que muitos dizem, e que s vezes pode parecer
at clich, mas a pura verdade.
E tambm estava querendo comentar sobre a dobradinha da Brawn GP (hehe), j que
abandonei h muito tempo atrs o meu blog de F1.
Ento chega de bl-bl, e vamos para o post.
Superar desafios
Estamos sempre estudando, trabalhando, nos esforando para alcanar o algo a mais.
Superar desafios, que no param de chegar (que bom), desde aquelas misses
impossveis que te aparecem s 18:00, quando voc j estava arrumando as coisas para
sair do trabalho, mas acaba tendo que ficar para resolver. At os seus desafios pessoais:
passar numa prova, emagrecer (no meu caso engordarrsrs), aprender um novo idioma,
etc.
O caso BBB
Calma, no vou falar do Big Brother Brasil e sim de trs pessoas, que representam toda
uma equipe de Frmula 1: Button, Barrichelo e Brawn. O primeiro o companheiro de
equipe do Rubinho, e o terceiro o chefe da equipe, Ross Brawn.
Hoje de madrugada estavam os trs no pdio do grande prmio da Austrlia, o Button
no lugar mais alto o Rubinho no segundo e o Ross Brawn para receber o prmio da
equipe vencedora.
E os trs superaram diversos desafios para chegar at l. E a razo dos trs estarem l
no apenas devido as prprias habilidades e esforos de cada um. E sim de uma
equipe toda, aquela velha histria de que a vitria de todos: desde o mecnico at o
chefe da equipe.
S em equipe
Se voc tiver um grande desafio, como a Brawn teve, no adianta apenas voc se
esforar, assim como no adiantava apenas o Rubinho d o seu mximo e o carro no
ser bom, fato que ocorreu nos anos anteriores.
Voc ir precisar de uma equipe. E todos ns fazemos parte de uma equipe (acredito
eu). No meu trabalho mesmo, temos um grande projeto, enormes desafios, cobranas e
uma equipe que adora super-los. Eu sozinho no ia conseguir garantir a qualidade do
sistema, por mais que eu me esforce. um desafio que deve ser encarado por uma
equipe e todos na equipe devem trabalhar, trabalhar e trabalhar.

241
O gerente do projeto por mais que ele seja competente no conseguir gerenciar todas as
equipes e as tarefas, ele precisa de outras pessoas para ajud-lo. Os desenvolvedores no
conseguiro garantir que o sistema estar de acordo com os requisitos sem a nossa
ajuda.
Em equipe, grandes obstculos se tornam menores. Exemplos diversos:
mais fcil fazer dieta junto com os seus amigos (as), j que todos vo evitar ir
numa churrascaria ou comer uma feijoada na quarta-feira;
Estudar para uma prova em grupo, onde todos pensaro em como resolver uma
questo confusa e compreender melhor um captulo difcil;
Gravar um CD de rock sozinho algo quase impossvel, j que temos pelo
menos trs instrumentos (guitarra, baixo e bateria), embora Dave Grohl, tenha
tocado todos os instrumentos do primeiro lbum do Foo Fighters sozinho.
Hoje em dia vivenciamos o progresso, e com ele muitas coisas se tornaram mais fceis,
porm os nossos desafios esto cada vez mais difceis. Portanto temos que trabalhar
duro e em equipe. A velha histria de que a unio faz a fora.
Se um projeto d certo ou errado a culpa ou a glria no sero apenas de uma nica
pessoa e sim de todos.
E para terminar, no adianta temos uma excelente infra-estrutura, usar a melhor
metodologia, ter um bom prazo, seno temos uma boa equipe. As pessoas so e sempre
sero o diferencial, a razo do fracasso ou do sucesso de um projeto. No tente
terceirizar a culpa para a metodologia e nem se vangloriar sozinho. E quando eu falo em
pessoas os clientes tambm esto inclusos, alis, so os primeiros que devem est
comprometidos com o sucesso do projeto.
Eu sou parte de uma equipe. Ento, quando veno, no sou eu apenas quem vence. De
certa forma, termino o trabalho de um grupo enorme de pessoas. - Ayrton Senna
Um floco de neve uma das mais frgeis criaes, mas veja o que eles conseguem
fazer quando se juntam! - Autor desconhecido


242
8. A Importncia da Maturidade
Aviso:
Este post fruto da experincia do autor desse blog, no baseado em teorias ou
grandes autores, mas os mesmos ajudaram esse autor a chegar as concluses que iro d
forma a esse post, cuja essncia foi extrada da prtica.
O que maturidade?
Maturidade na sua essncia voc saber o que quer e como alcanar o seu objetivo, sem
prejudicar as pessoas e de forma tica e moral.
Exemplo:
Ao chegar numa certa idade, voc no ter mais os seus pais para tomar a deciso por
voc, e em certos momentos da sua vida, geralmente no momento que voc mais
precisar, no poder contar com a opinio de um amigo ou familiar. Porm ter a sua
inteira disposio a sua maturidade, ela que ir te ajudar.
Maturidade no mundo de TI
A maturidade no mundo de TI algo no muito comum, ou pelo menos no era at
pouco tempo. E o motivo para eu ter chegado nessa concluso bem fcil de entender,
quantos projetos que voc j viu atrasar ou serem cancelados? Muitos no !? E olha
que eu nem perguntei a quantidade de projetos que foram para a produo sem ter a
qualidade desejadaputz, mas verdade, que qualidade desejada? Para mim se tiver
funcionando t timo.
Para ilustrar a importncia da maturidade no mundo de TI vou citar um exemplo de uma
empresa que quase ningum conhece, o Google. Enganam-se aqueles que acham que o
Google aquele palavro, parecido com soda, e ponto final. Na verdade o Google
maturo. Larry Page e Sergey Brin, os fundadores do Google, nunca imaginaram,
acredito eu, que iriam construir uma empresa como o Google, logo quando estavam
crescendo, perceberam que precisavam de algum com experincia para ajudar a
gerenciar o Google, e assim contrataram Eric Schmidt, que tinha uma experincia de 20
anos na Novell.
Voc faz idia da complexidade que gerenciar uma empresa como o Google, ou como
a Microsoft? Eu tambm no fao, mas com certeza no uma das tarefas mais fceis, e
para se manter entre os grandes preciso muita maturidade.
Uma atitude matura que o Google tem, dentre as vrias, a liberdade que eles do aos
colaboradores. L voc pode dedicar 20% de seu tempo em projetos independentes. E
no precisa ficar preso 8 horas na sua baia, pode sair para relaxar (jogar um pouco de
video game, deitar num puff, jogar sinuca com os amigos, etc).

243
No mundo de TI h at certificaes que comprovam o nvel de maturidade dos
processos das empresas, o CMMI (Capability Maturity Model Integration) o mais
conhecido. E com certeza deve ajudar a sua empresa a alcanar um melhor nvel de
maturidade, mas sinceramente, pela minha experincia vejo que no to fcil aplicar o
CMMI em todas as empresas, pelo simples fato, que elas atuam em mercados bem
diferentes e tem realidades bem distintas.
No a toa, que outros modelos de referncia surgem, como o MPS.BR. E todos eles
objetivam a melhoria do processo.
Voc t de brincadeira mais uma vez, Fabrcio! Fez todo esse barulho para falar
sobre CMMI e MPS.BR!?
No, pois vejo que sempre temos dificuldade em adaptar tais prticas em nossa
realidade. Afinal seria muito bom e fcil se houvesse alguma receita de bolo, que
seguindo ela corretamente conseguiramos alcanar a maturidade necessria para a
nossa empresa. Alis, algum sabe qual o nvel CMMI do Google?
Ento como posso aprimorar o meu processo e torn-lo mais maduro e eficiente?
Errando e aprendendo com os erros.
No h segredo, no h receita mgica. E como o Muricy Ramalho, tcnico do So
Paulo FC, diz: trabalho, meu filho!. E s com muito trabalho poderemos
melhorar algo. E no adianta ficar choramingando, botando a culpa na metodologia, ou
na cultura da empresa. Alis, falando em cultura da empresa, ela um dos grandes
obstculos que necessitamos enfrentar, quando estamos tentando fazer algo diferente,
algo para melhorar o nosso processo. E voc ter que ser paciente, no poder bater de
frente com ela, ter que plantar a semente da mudana e ir cultivando.
No h espao para a acomodao, mesmo quando estivermos bem: prazos esto sendo
cumpridos, equipe est motivada, ainda poderemos melhorar.
Na minha opinio, dois pontos so fundamentais para aumentar a maturidade de um
processo:
A equipe
O cliente
De um lado precisamos ter uma equipe motivada, em sintonia, um verdadeiro time. E
nesse time no haver espao para estrelinhas (sabe aquelas caras que tem uma porrada
de certificao e que se acham o cara, ou ainda aqueles que esto a X dcadas na
empresa e s esto preocupados com os investimentos que tem na bolsa de valores), e
haver muito espao para: troca de idias e opinies, transparncia, companheirismo e
mudanas.

244
J do outro lado, precisamos ter um cliente que saiba que o seu fornecedor (ns) est
comprometido com a sua satisfao, e que entenda que ele tambm um fator para o
sucesso do projeto. Ele ter que ser mais participativo com a equipe, tentar compreender
melhor as suas reais necessidades e avaliar sempre se toda informao foi passada para
o seu fornecedor, de maneira clara e objetiva.
E como voc pode perceber, o mais importante para a maturidade de um processo so as
pessoas, portanto as pessoas tambm precisam ser maduras o suficiente para entenderem
os seus papis, afinal os profissionais de TI no so meros escovadores de bits e sim
causadores da mudana e do progresso da empresa.
E algo que mudou bastante a maneira como vejo o desenvolvimento de software foi a
leitura e compreenso do Manifesto gil (leia voc tambm ), que traz princpios que
podem aprimorar e tornar mais eficiente o seu processo.
Estude sobre metodologias, modelos, estudos de caso, faa e use as lies aprendidas,
etc. Pois mesmo no podendo aplicar na prtica tudo que voc estudou, com certeza, em
um certo momento, voc ter a chance de mudar algo, tendo como base algo que voc
estudou.
Como posso medir a maturidade da minha empresa?
Acredito que algo mais importante do que certificaes, logicamente que tendo uma
viso interna do processo, so as cinco caractersticas, que cito abaixo:
A empresa est tendo lucro;
Os clientes esto satisfeitos com o produto entregue;
A equipe est motivada;
O ambiente de trabalho propicia discusso e o surgimento de novas idias;
Sempre h algum pentelho mudando algo.
Antes de terminar, s gostaria de deixar claro mais uma coisa: no sou contra CMMI,
MPS.BR, ISO, etc, pelo contrrio, elas ajudam bastante a melhoria do processo da
empresa e principalmente a credibilidade, perante o mercado. No entanto, penso que um
nvel excelente de maturidade alcanado, quando o seu processo tem total conscincia
das dificuldades e necessidades, e consegue se adaptar as novas realidades, desafios e
principalmente, no fica preso a uma prtica, metodologia ou modelo.
Um dia voc aprende que maturidade tem mais a ver com os tipos de experincia que
se teve e o que voc aprendeu com elas, do que com quantos aniversrios voc
celebrou. (William Shakespeare)
Abraos! E se quiserem concordar ou discordar de algo, sintam-se vontade, at porque
a maior parte do que falei, so opinies que tenho hoje, talvez at eu no futuro, discorde
de algo.

245
Curiosidades do QualidadeBR
Ele nasceu no dia 19 de junho de 2008;
O ms mais agitado (com maior nmero de posts) foi o de maro de 2009,
causado pela srie de posts com resolues de questes do exame
CTFL/BSTQB;
O ms menos agitado foi o de novembro de 2009, devido ao TCC que o autor
estava escrevendo para a concluso da sua graduao;
Todo contedo publicado no QualidadeBR est sob a licena Creative
Commons:
o Os leitores podem:
Copiar, distribuir, exibir e executar a obra;
Criar obras derivadas.
o Sob a seguinte condio:
Atribuio - Voc deve dar crdito ao autor original, da forma
especificada pelo autor ou licenciante.
Os cinco posts mais vistos do QualidadeBR so:
1. Certificao: IBM Certified Specialist Software Quality;
2. Simulados CTFL-BSTQB;
3. FURPS+;
4. Tutorial Eventum (parte 1);
5. Teste Estrutural (White Box) X Teste Funcional (Black Box).
E os cinco posts menos vistos so:
84. Qualidades de um especialista em teste;
85. Qualidade Sem Nome;
86. Feliz Ano Novo;
87. Padro de nomes de componentes;
88. Adiado o 3 Encontro Mensal da ALATS.
Alguns nmeros alcanados pelo QualidadeBR nesse um ano de vida:
o Mais de 17.000 visualizaes de pginas;
o 88 posts publicados;
o 158 comentrios;
o Uma mdia 1.9 posts por semana;
o 47 leitores do feed.


246
As Caras do QualidadeBR

Figura 105 - Primeiro header


Figura 106 - Segundo header


Figura 107 - Terceiro header


Figura 108 - Quarto header

You might also like