Já está aberto o prazo de submissão de artigos para o IV Encontro Brasileiro de Testes de Software em Recife/PE

Os interessados podem submeter seus trabalhos até o dia 29 de dezembro, em formato PDF, através do e-mail ebts@gotest.biz. Os artigos devem conter entre quatro e seis páginas e seguir o modelo da ACM SIG Proceedings, disponível gratuitamente no site www.acm.org/sigs/pubs/proceed/template.html.

Os artigos a serem submetidos ao IV EBTS devem oferecer um melhor entendimento sobre boas práticas de testes de software, além de se reportar a lições aprendidas, inovações e aplicações práticas. No dia 25 de janeiro, será divulgada a relação dos artigos aceitos. Os selecionados terão até o dia 15 de fevereiro para entregar a versão final e o material de apresentação a ser usado durante o evento.

O EBTS é um evento que visa promover o intercâmbio de idéias entre empresas e academia com o objetivo de estimular debates e discussões sobre testes de software, promovendo, assim, a troca de conhecimentos e a integração entre academia e o mercado.

O encontro acontecerá entre os dias 23 e 24 de abril e terá, em sua programação, palestras técnicas, mini-cursos, convidados renomados da área de testes, competições e premiações. A iniciativa é promovida pela GOTEST e conta com apoio do C.E.S.A.R e do Porto Digital.

Mais informações através do site http://www.gotest.biz/ebts2010/

Post excelente escrito pelo André Faria Gomes. Muito bom mesmo! Podcasts sem dúvida são um dos meios mais indicados para adquirir conhecimento em tecnologia, ainda mais quando você está antenado no que Martin Fowler, Kent Beck, Rod Johnson entre outros estão falando. Retirado do andrefaria.com.

Um dos maiores problemas da sociedade moderna é a dificuldade de locomoção diária, a maioria das pessoas passa horas em seus carros, ou em meios de transporte públicos para irem de lugar a outro. Há alguns anos atrás quando morava na zona norte de São Paulo e trabalha na zona sul, essa era minha realidade. Uma vez que naquela época passar por isso era inevitável procurei formas de fazer com esse tempo pudesse de alguma forma torna-se produtivo, foi então que comecei a ouvir à podcasts.

iPod FM radio remote por dan taylor

De acordo com a Wikipedia, Podcasting é uma forma de publicação de arquivos de mídia digital (áudio, vídeo, foto, etc.) pela Internet, através de um feed RSS, que permite aos utilizadores acompanhar a sua atualização. Assim, é possível o acompanhamento e/ou download automático do conteúdo de um podcast.

Neste post apresentarei os podcasts aos quais escuto e os episódios principais para que você ouça. Sugiro que você utilize o iTunes para inscrever-se nos podcasts e sincronizar com seu iPod.

Desenvolvimento Ágil

por pcalcado

Podcast da ImproveIt

por Vinícius Teles
http://improveit.com.br/podcast
Português

• Entrevista com Alisson Vale da Phidelis
• Entrevista com Alexandre Magno na Série Experiências Ágeis
• Entrevista com Carlos Barbieri sobre o MPS.BR
• Entrevista com a equipe da Ancar na Série Experiências Ágeis

AgilCast

Por AgilCoop
http://agilcoop.incubadora.fapesp.br/portal/agilcast
Português

• Uma Visão Geral Sobre Scrum
• Testes Automatizados
• Bancos de dados ágeis e refatoração de bancos de dados

Agile Toolkit Podcast
http://agiletoolkit.libsyn.com
Inglês

• Tom Goulet – Cucumber, Ruby and the transition to Generalizing Specialist (2009)
• Jim Miller – The Product Owner Role and Business Alignmnet
• Tips and Advice – Retrospectives

ThoughtWorks Podcast

http://www.thoughtworks.com/what-we-say/podcasts.html
Inglês

Open Source

FLOSS Weekly

por Leo Laport, Jono Bacon e Randal Schwartz
Inglês

• Entrevista com Kent Beck sobre Extreme Programming (XP)
• Entrevista com Linus Torvalds, o criador do Linux e do Git
• Entrevista com David Heinemeier Hansson criador do Ruby On Rails
• Entrevista com Tim O’Reilly, fundador e CEO da  O’Reilly Media
• Entrevista com John Resig criador e líder do Projeto jQuery
• Entrevista com Jan Lehnardt evangelista do projeto CouchDB
• Entrevista com  Jacob Kaplan-Moss criador do Django
• Entrevista com Bruno Souza sobre o OpenJDK
• Entrevista com Ward Cunningham inventor do Wiki e grande Personalidade da Comunidade Ágil
• Entrevista com  D. Richard Hipp criador do SQLite
• Entrevista com Nate Koechley sobre o Yahoo User Interface Library (YUI)
• Entrevista com Junio Hamano, Mantenedor do Git
• Entrevista com Rasmus Lerdorf, criador do PHP
• Entrevista com Guido van Rossum, Criador do Python
• Entrevista com o fundador da Wikipedia, Jimmy Wales

Java

HorecaExpo – Java por bramloquet

JavaPosse

Por Tor Norbye, Carl Quinn, Dick Wall e Joe Nuxoll
Inglês
http://www.javaposse.com

Java Technology Insider

Inglês
http://www.javaworld.com/podcasts/jtech

• Rod Johnson: SpringSource and the future of Spring (2008)

Grails Podcast

Por Glen Smith e Sven Haiges
http://grailspodcast.com

Ruby

Ruby on Rails por Andrew*

Rails Envy

Por Jason Seifer e Gregg Pollack
Inglês
http://railsenvy.com

Rails Podcast

por Geoffrey Grosenbach
Inglês
http://podcast.rubyonrails.com/

• Entrevista com David Heinemeier Hansson (2005)
• Entrevista com Dave Thomas (2005)
• Entrevista com Chad Fowler (2005)
• Entrevista com Obie Fernandez (2006)
• Entrevista com Dave Thomas e Mike Clark (2006)

Rubiverse Podcast

Por Mike Moore
Ingles
http://rubiverse.com

• Dave Hoover on Software Crafsmanship (2009)
• Obie Fernandez on the Rails Maturity Model (2009)
• Ola Bini on Polyglot Programming (2008)

JavaScript

jQuery Podcast

Português
http://blog.jquery.com/2009/11/13/announcing-the-official-jquery-podcast/

Gadgets

GeekBrief TV

por Cali Lewis
Inglês
http://www.geekbrief.tv

Software

Desk por Guillermo Esteves

Pragmatic Podcasts

por Pragmatic Bookshelf
Inglês
http://www.pragprog.com/podcasts

• Chad Fowler on the Passionate Programmer
• Fred Daoud on Stripes
• Chad Fowler Finding the Jagged Edges
• Andy Hunt on Pragmatic Wetware

Software Engineering Radio

por Software Engineering Radio
http://www.se-radio.net
Inglês

• Software Archaelogy with Dame Thomas
• Fearless Change with Linda Rising
• Learning as a Part of Development with Allan Kelly
• SQL with Jim Melton
• Continuous Integration with Chris Read
• Top 10 Architecture Mistakes with Eoin Woods
• Usability with Joachim Machate
• Introduction to AOP with Christa Schwanninger e Iris Groher
• Retrospectives with Linda Rising
• 10 years of Agile Experiences
• Joe Armstrong on Erlang
• Interview Dave Thomas
• Dick Gabriel on Lisp
• Jeff DeLuca on Feature Driven Development
• Interview Erich Gamma
• Gerard Meszaros on XUnit Test Patterns
• Static Code Analysis with Jonathan Aldrich
• Refactoring Pt. 1
• Refactoring Pt. 2
• eXtreme Programming Pt.1
• eXtreme Programming Pt.2
• Agile Documentation
• Interview Jutta Eckstein
• Interview Eric Evans
• Patterns

Elegant Code

por Elegant Code Community
http://elegantcode.com
Inglês

• Agile for Families
• Entrevista com Jim Wierich o Criador do Rake (Ruby)
• David Laribee on Lean / Kanban
• Uncle Bob Martin on Clean Code
• Alan Shalloway on Lean
• Entrevista com Jarod Ferguson
• Entrevista com Darrel Carver
• Entrevista com Scott Nichols
• Entrevista com Scott Schimanski

Google Developer Podcast

http://code.google.com/p/google-developer-podcast/downloads/list
Inglês

Hearding Code

http://herdingcode.com
Inglês

Tecnologia

IT Conversations

http://itc.conversationsnetwork.org
Inglês

net@Night

por Amber MacArthur e Leo Laport
http://www.twit.tv/natn

Twit – This Week in Tech

por  Leo Laporte, Jeff Jarvis, Baratunde Thurston, e John C. Dvorak
http://www.twit.tv/twit

MacBreak Weekly

por Leo Laporte, Don McAllister, Paul Kent, and Andy Ihnatko
http://www.twit.tv/mbw

This Week in Google

por Leo Laporte, Gina Trapani, Jeff Jarvis e Mary Hodder
http://www.twit.tv/twig

SitePoint Podcast

inglês
http://www.sitepoint.com/podcast

Empreendedorismo e Negócios

37 Signals Podcast

por 37 Signals
Inglês
http://37signals.com/podcast

Max Gehringer (CBN)

por Max Gehringer
Português
http://cbn.globoradio.globo.com/servicos/podcast/NOME.htm

Mundo Corporativo (CBN)

por Heródoto Barbeiro
Português em Áudio
http://cbn.globoradio.globo.com/servicos/podcast/NOME.htm

The Startup Success Podcast

http://startuppodcast.wordpress.com
Inglês

TED Talks

por TED Talks
Inglês
http://www.ted.com

Nossa sessão Links foi reestruturada e ampliada.

Sugestões e indicações são sempre bem vindas.

Obrigado,

Giovani Faria

Segue abaixo, as opiniões do Fabrício Ferrari:

• Antes de tudo, qual a real importância de estimar algo?
  • É uma atividade que pode ajudar muito no planejamento, gerenciamento e controle dos projetos. Mas é bom ter consciência que estimar não é adivinhar o futuro;
  • Antes de estimar, precisamos saber porque estamos estimando algo, e o que iremos fazer com as informações obtidas, pois precisamos usá-las para melhorar o nosso processo e não como forma de cobrança de profissionais, ou porque todos mundo fala que estimar é importante.
• “Você não pode controlar o que não pode medir”, isso ainda é uma verdade na empresa de vocês?
  • Como o próprio autor da frase (Tom DeMarco), disse recentemente: [...] a idéia de que controle seja talvez o mais importante aspecto de um projeto de software. Mas não é. Muitos projetos foram realizados quase sem controle e produziram produtos maravilhosos, como o Google Earth ou o Wikipedia.” (tradução do José Papo);
  • Medir é apenas uma das forma de controlar, adoramos números, tanto que há as mais variadas estatísticas hoje em dia. Porém, não é uma tarefa tão simples, e nem sempre a mais importante para uma determinada realidade.
• Quais são as maiores dificuldades de implantar APT?
  • Eu nunca usei APT, então não posso falar muito. Mas acho que as maiores dificuldades envolvem a empresa e as pessoas do projeto, todos precisam está alinhados, e cientes da importância da sua implantação;
  • Documentação é um problema em muitos projetos, e fazer uma estimação em cima de uma documentação desatualizada ou pouco consistência, é uma perda de tempo;
  • A expectativa, muitos acham que estimativas são verdades absolutas, quando na verdade não são, são apenas estimativas, e precisam está sempre sendo atualizadas;
  • Vivemos num mundo imediatista (tudo é pra ontem), e todos esperam que usando o APT os resultados apareçam logo, porém isso é muito difícil de acontecer, para não dizer impossível. Uma prática fundamental, quando se usa APT, é ajustar-la, e o ajuste só pode ser feito com o passar do tempo;
  • Estimar algo que envolve pessoas, é quase o mesmo que prever o tempo, ou querer saber quanto estará o dólar daqui há 4 meses. Portanto estimar por si só, é uma tarefa bem difícil.
• Quais as vantagens de usar APT? O custo-benefício vale a pena?
  • Mais uma vez, só poderei responder com base de informações teóricas. No segundo encontro da ALATS-SP (slides), deu para perceber que na empresa da Cristiane eles levam a sério estimativas, e elas já são usadas há um bom tempo, e desta forma, conseguiram construir uma boa base histórica. Com certeza tal base é uma fonte que fornece um bom diferencial e aumenta a eficiência no gerenciamento, planejamento e controle dos processo/projeto de Teste de Software;
  • O maior benefício, é que paramos de usar o achômetro e passamos a usar informações do nosso histórico.
• O que eu necessito para poder utilizar APT?
  • Saber o tamanho do sistema em pontos de função (APF);
  • Saber a complexidade do proceso de teste;
  • Saber o nível de qualidade que se pretende alcançar com os testes;
  • Saber o grau de envolvimento dos usuários com os testes;
  • Saber as interfaces que as funçõe testadas têm com os arquivos;;/
  • Saber a qualidade do sistema testado (o ciclo de reincidência de defeitos);
  • Saber o nível de cobertura esperado com os testes;
  • Saber a experiência e a produtividade da equipe de teste (por meio de indicadores históricos);
  • Saber o grau de automação dos testes;
  • Saber a qualidade do ambiente de teste, até mesmo sua capacidade de simular o ambiente de produção;
  • Saber a qualidade da documentação do sistema e, em especial, dos requisitos.

(fonte: Base de conhecimento em teste de software)

• Quando usar e quando não usar APT?
  • Sim
    • Quando você tiver a real necessidade, quando o custo-benefício realmente compensar;
    • Quando o seu ambiente permitir;
    • Quando a empresa tiver maturidade suficiente para entender e implantar-la.
  • Não
    • Tudo que disse para o “Sim” ao contrário.
• Quais são as lições aprendidas que vocês tiveram sobre estimar testes?
  • Estimar testes não é fácil (se fosse td mundo faria)
  • Precisamos estimar com as ferramentas que o nosso ambiente nos dá;
  • Mais uma vez, adaptação é essencial;
  • Quando não temos uma base histórica, o melhor a ser fazer é entender bem sobre o sistema sob teste e Teste de Software, e aí gerar as estimativas das pessoas. Como por exemplo, usando planning poker;
  • O que não podemos fazer, é ficar usando técnicas derivadas do achômetro, como por exemplo: “estimativa do dedo”,  “veja bem”, “se” e famoso Cálculo Hipotético Universal Técnico Estimativo (vulgo C.H.U.T.E).

Créditos
Fabrício Ferrari de Campos, CBTS, CTFL
Blog: qualidadebr.wordpress.com
Twitter: twitter.com/FabricioFFC

Segue abaixo palestras do 2° dia de palestras do EQPS Manaus 2009 (17/11/2009).

Aquisição IN04 RMCF

Projeto 6.10

Projeto 6.11

Segue abaixo palestras do 1° dia de palestras do EQPS Manaus 2009.

Seis Anos de MPS.BR
AMAZONSOFT
FAPS
FROISPI
Projeto 2.06
Projeto 2.08
Projeto 3.01
Projeto 3.02
Projeto 5.01
Projeto 6.07
Projeto 6.15
Projeto 6.22

Chegada ao final!

Para quem pensou que ter o aceite é a parte mais fácil… não imaginou como seria o seu fechamento! Aliais, existe alguma fase mais fácil dentro de um projeto? Acredito que não! Afinal são processos interativos e incrementais, nos quais um saindo errado acaba prejudicando todo o projeto. Então muita atenção em todas as fases.

Voltando a pergunta inicial. Uma das dificuldades é validar os requisitos solicitados, pois o projeto iniciou-se há uns seis meses e talvez ele nem lembre o que ele pediu. Por isso toda documentação é importante! E o que é pior que não lembrar? É “lembrar” de algo que não foi solicitado: “- Mas esse relatório é importante. Eu preciso dessa informação! Sem ela o sistema não ajuda em nada! Eu lembro que eu solicitei isso!”. Pois é cliente, mas esse requisito não está no documento. O que fazer? Adicionar prazo, custo? Mas eu tenho outros sistemas para cuidar e esse era para ser finalizado hoje!

E aquele aceite com gostinho de quero mais? “-Olha, eu vou aprovar, mas esse relatório tem que ser feito, pois é muito importante. Há, muda também a cor do fundo do sistema.” Bem, é aquele tipo de fechamento já pensando no custo da melhoria. Isso não deixa de ser bom, mas deve ser bem explicado para o cliente quando e como esse “novo” projeto de melhoria será realizado. Não deixe de formalizar o aceite final.

Recomendo muitas e muitas conversas, validação de requisitos, reuniões em intervalos aceitáveis que não permitam o projeto sair da linha, documentar e gerenciar sempre a expectativa do cliente, não fazendo com que o mesmo espere por um tigre e receba um “miau!”.

Forte abraço!

Renato Borges

Data de realização: 16 e 17 de Novembro de 2009
Local: FIEAM – Federação das Indústrias do Estado do Amazonas
Endereço: Avenida Joaquim Nabuco, 1919 – Centro - 69020-031 – Manaus – AM
Contato: Diva da Silva Marinho,               (61) 3317-7967       , pbqpsw@mct.gov.br

Inscrições sem ônus aqui
- Consulte Programação
Data limite para inscrições: 11 de novembro, quarta-feira, às 18 horas

Inscrição EQPS

Selecionei 5 textos da mesa redonda que foi realizada no Grupo DFTeste com o Tema: “Testar é tão fácil, que até a minha mãe testaria!”.  No Blog do Fabrício Ferrari contém uma compilação de todos as opiniões dos os participantes que no total foram 19.

Os participantes foram: Robson Agapito, Simon Rodrigues, Sarah Pimentel, Ronaldo Cruz, Renata Eliza, Ricardo Franco, Felipe Silva, Ricardo Franco Custodio, Camilo Ribeiro, Maria Meire Gomes, Rita Lima, Michel Mendoza, Carolina Baldisserotto, Emerson Gomes da Silva, Ueslei Aquino da Silva, Edwagney Luz, Andrea Cruz, Rodrigo Almeida de Oliveira e Fabrício Ferrari.

T E X T O   1
Fabrício Ferrari de Campos, CBTS, CTFL

Acredito que esse é um dos mitos mais fortes que existem na nossa
área.

Fruto da ignorância de pessoas que acreditam que Teste de Software, só
tem uma fase, a da execução, e que só fazem testes exploratórios de
forma manual.

Lembro de uma conversa que tive uma vez com um amigo meu, que estava
comentando como eram feitos os testes na empresa que ele trabalhava.
Lá os testes eram uma tarefa para os novos estagiários, o famoso
“Testa Aí”.

Vejo que a situação relatada pelo meu amigo, ainda é realidade em
muitas empresas. E essa realidade aliada com a falta de divulgação da
área (leia-se ausência da matéria Teste de Software em boa parte das
faculdades), fez com que esse mito nascesse.

Porém, testar não é tão fácil assim, aliás, é uma atividade, ou
melhor, um conjunto de atividades que podem oferecer um enorme desafio
e exigerem um alto nível de conhecimento dos profissionais.

Logicamente, que tudo depende do sistema sob teste, só que o mesmo
também baliza a dificuldade das outras atividades do desenvolvimento
de software (ex. arquitetura, análise, programação, etc).

Desenvolver um sistema que tenha só CRUD é extremamente fácil para um
desenvolvedor, e por consequência será extremamente fácil para o
profissional de Teste de Software testar esse software também.

E é importante lembrar que testar não é apenas executar um teste, há
diversas atividades relacionadas, como por exemplo: o planejamento,
análise e modelagem dos testes.

Dependendo da complexidade e tecnologias utilizadas no desenvolvimento
de um sistema, o Teste de Software torna-se extremamente difícil.

E há um outro mito associado a esse, o que o profissional de Teste de
Software necessita saber apenas duas coisas: Testar e conhecer o
sistema sob teste.

Ledo engano…

Atualmente, os profissionais de TI tendem a ser cada vez mais
generalistas, ou melhor, especialistas generalistas. E os
profissionais de Teste de Software são uns do que mais necessitam ser
especialistas generalistas, pois as suas tarefas envolvem várias áreas
de TI, principalmente se o profissional for focar na área técnica.

Portanto, afirmar que testar é fácil e ponto final, é um grande erro,
principalmente se estiver menosprezando esse conjunto de atividades,
que são tão importantes no desenvolvimento de um software.

Abraços!

T E X T O   2
Andrea Cruz.

Testar pode parecer fácil mas é puro engano.

Como surgiu o mito?
Nos primóridios do tempo surgiu a necessidade que foi verbalizada,
“TESTAR” e depois a designação para alguém: “Fulano testa isso aí para
mim” ou “Mãe testa isso aí para mim?” ou “Ciclano testa aí”

Até a chegada de uma nova era chamada era da Qualidade. Surgiram
profissionais dedicados e voltados para detectar imperfeições, nomes
como Controle da Qualidade, Quality Assurance e etc….  Os clientes,
a área de suporte  foram reportando bugs, falhas de comunicação entre
o desenvolvimento e o cliente…. A partir daí o desespero tomou conta
de alguns: do cliente e do analista e do gerente. Como evitar?
Precisamos identificar o problema antes do cliente. Precisamos buscar,
explorar bugs e encontrar falhas… Mãe, tia, papagaio, cachorro todos
a postos…. Alguns desenvolvedores viram a possibilidade de mudar de
área. Outros assumiram os testes…. Surgiu o titulo analista de teste
e  testador.  Mas, quem se aprofunda percebe logo que quem quer testar
gasta tempo e para ter Qualidade precisa ter algumas características
básicas como:

* ser preciso
* ser criterioso
* ser paciente
* mentalidade combinatória

Pq as pessoas ainda tem essa opinião?
As pessoas que ainda pensam que  qualquer um pode testar são pessoas
sem conhecimento ainda ignorantes neste mundo novo que surge. Um mundo
com conceito de qualidade.

O que fazer para acabar?

* Acreditar é o primeiro passo. É preciso crer, gostar, amar o seu
trabalho, saber vender suas idéias, valorizar as vantagens de fazer
testes e as desvantagens em não realizar testes.

* Segundo passo é ter argumentos bons: Como era antes dos testes?
Como é agora? Mostrar a evolução em gráficos, em números.

* Terceiro passo: Mercado: Quais empresas investem em qualidade de
software? Microsoft, Google, …..grandes empresas. Por que será? Será
que elas não estão pensando à frente???

A Área de Testes sofre Preconceito?
Preconceitos existem. A melhor forma é primeiro aceitar. Não adianta
reclamar. É preciso admitir que existe um preconceito oriundo de uma
grande falta de conhecimento nesta área e que por ignorância alguns
discriminam. Algumas pessoas do  desenvolvimento se sente ameaçadas.
Só você pode conscientizar as pessoas, esclarecê-las. Lutar pela
qualidade é lutar por um padrão que só traz benefícios. É ser amigo do
desenvolvedor e do cliente.

A luta continua companheiros…..

T E X T O   3
Robson Agapito.

Creio que este mito ocorre principalmente por falta de conhecimento de
muitas pessoas da área de TI. Então se começarmos a divulgar mais
sobre testes de software pode ajudar muito a não terem esta visão.

Uma situação que era extremamente importante para ter um
reconhecimento grande durante os próximos anos seria a inserção
inicial de uma matéria sobre testes de software nas universidades, e
quem sabe um curso na graduação sobre testes de software.

Mas não sei nem como introduzir isso em uma universidade. Como isso
seria o top, creio que a divulgação da área para outros setores que
tem contato com nossa área (desenvolvimento e infra) já seria um
grande avanço… temos que mostrar nossa “cara” e não ficarmos em uma
ilha isoladamente como muitas vezes estamos.

Esta é minha opinião.

Grande abraço a todos, e uma excelente semana.

T E X T O   4
Camilo Ribeiro, Software Quality Consultant
cbts, istqb certified tester
www.camiloribeiro.com

Durante esse tempo que estive testando notei que um dos motivos do
teste não ser valorizado em relação ao desenvolvimento é que o
desenvolvimento gera código e o “teste“ não gera nada.

O teste que não gera documentação, arquitetura, planejamento e
obviamente resultados não pode e não deve ser valorizado.

Profissionais que realizam testes “exploratórios” e nada mais não são
testadores. Esses testes “exploratórios” são o que nos enfraquecem,
fazem nosso trabalho parecer simples e como disse nosso amigo
Fabrício, o teste passa a ter uma única fase, a execução “porca”.

Muita gente acha que só fazemos esses testes “meia boca”, e isso em
grande parte por culpa dos que se dizem analistas de teste e na
verdade acabam por mostrarem-se amadores ou pessoas sem capacidade
técnica e organizacional para medir a eficiência do próprio trabalho.

A forma que temos de reverter isso começa em nós mesmos. Como disse
Tolstoi (se não me engano) “Todos querem mudar o mundo, mas ninguém
quer mudar a si mesmo”.

Ao mudamos nosso ambiente de trabalho aplicando técnicas, definindo um
processo, criando indicadores, gerenciando nossas atividades e
demonstrando o valor dos processos de teste dentro da organização que
nós trabalhamos nós mudamos nossa imagem e conseqüentemente a imagem
da nossa profissão.

Outra coisa fundamental na minha opinião é ser técnico. Saber
programar, orientação a objetos, SQL, design patterns, conhecer
ferramentas, usar frameworks, elaborar e revisar requisitos, escrever
processos, gerencia de configuração e etc não nos torna menos
testadores, muito pelo contrário, conhecer de tudo é saber identificar
defeitos em tudo. Como eu digo, a era do bug se foi, estamos na era do
defeito, o bug de software existiu em 1965.
Bug is dead.
Best Regards,

T E X T O   5
Ricardo Franco Custodio
IBM Certified SOA Associate [2008]
IBM Certified Specialist – Software Quality
IBM Certified Solution Designer – Rational Unified Process
desenvolvedor.rica…@gmail.com

Situação 1:

Um colega de trabalho – programador sênior – foi inserido (como forma
de punição) na equipe de testes devido a uma briga com o Gerente de
Projetos e o Gerente de TI…o cara ficava amargurado e dizia pra todo
mundo que estava se sentindo humilhado por estar ‘testando’ e não
trabalhando. Resultado: O cara pediu demissão.

Moral da história:  Os Gestores da minha ex-empresa não conheciam NADA
sobre testes / qualidade e a maioria dos programadores, que também não
conheciam NADA sobre testes / qualidade desprezavam a área.
—
Pra mim, isso aí é igual àquela estória da beterraba:

- Você gosta de beterraba?
- Não.
- Você já comeu beterraba?
- Não.
- Então porque você diz que não gosta se não sabe nem o sabor?
- Porque as pessoas dizem que é ruim.

—-

Situação 2:

Um Gerente de Projetos  de uma outra empresa que trabalhei falou pra
mim: ‘Testes pra mim ainda é uma incógnita!”
Quase que eu citei pra ele uma frase de Molière: “Um tolo instruído é
mais tolo que um tolo ignorante.”

—-

Situação 3:

Um colega de trabalho – Analista de Testes – me ligou desesperado um
dia desses, falando que o Gerente de Projetos falou pro
Analista de Requisitos da equipe dele, validar os casos de teste que
ele elaborava. (Sem comentários…)

—-

Concordo plenamente com o comentário do Ronaldo Cruz em que ele diz
“…boa parte dos gerentes, diretores e etc de hoje, foram os
programadores/testadores de anos atras, e eles ainda pensam sobre a
área da forma como trabalhavam antes”. Por isso, temos de tomar muito
cuidado com esses profissionais ‘Tarja-preta’ que fazem com que a área
de testes seja desvalorizada. Somos NÓS que carregamos a
responsabilidade de fazer com situações acima citadas não se repitam
mostrando conhecimento e experiência técnica sobre o assunto e saindo
daquela estória de ‘garantia da qualidade’ (isso é uma outra estória).
Com isso, ajudará a agregar um valor maior à área.

Abraços.

A Iterasys, com o objetivo de estimular e reconhecer a produção de artigos técnicos concederá vales descontos em seus treinamentos para os melhores textos inéditos sobre Teste de Software ou Garantia da Qualidade submetidos até 25/11/2009.

1º Colocado: R$ 1.000,00

2º Colocado: R$ 500,00

3º Colocado: R$ 250,00

Os artigos deverão ser enviados para contato @ iterasys . com . br, com a tag [Concurso Cultural] no Assunto.

Os artigos serão publicados no site da Iterasys. Os vencedores serão eleitos por juri popular (peso 4) e juri técnico (peso 6) composto por especialistas da Iterasys. A pontuação final será calculado por Nota do Juri Popular x 4 + Nota do Juri Técnico X 6. Os artigos serão votados no período de 26/11 à 11/12/09. O resultado será divulgado pelo site no dia 15/12/09.

Os vales descontos podem ser usados no Curso de Formação de Teste de Software ou no Curso Preparatório para a CBTS ou no Curso Preparatório para a CTFL, e serão válidos até 30/Jun/2010.

Todos os participantes ao enviarem os artigos concordam com os termos deste Concurso Cultural e permitem a Iterasys expor seus artigos no seu site durante e após a vigência do concurso.

Divulgue e participe dessa iniciativa!

Iterasys :: Liderança pela Qualidade
(11) 3254-7625 | contato@iterasys.com.br

Bem amigos do blog QualidadeBR!

No último domingo, tivemos o encerramento da eletrizante temporada 2009 da F1. E o desfecho do campeonato ocorreu no mais novo circuito da temporada o Yas Marina, localizado no maior emirado dos Emirados Árabes Unidos, Abu Dhabi.

O intuito do post é fazer um breve estudo de caso, de algo que ocorreu na construção do circuito e que também ocorre em projetos de software.

Para começar o estudo de caso do circuito de Abu Dhabi, é preciso antes falar sobre o seu projeto, que custou a bagatela de 1,322 bilhões de dólares (segundo a Wikipedia).

A construção do circuito teve início em fevereiro de 2007, com o “modesto” desafio de construir um dos mais modernos circuitos da F1 no meio do deserto. Alguns números da “singela” construção:

• Uma força de trabalho de 14.000 homens;
• 35 milhões de hora-homem investidos;
• 1,6 milhão de metros cúbicos de terra foram deslocados;
• 720 mil metros quadrados de asfalto;
• 25 quilômetros de cabeamento elétrico;
• 5 mil árvores plantadas;
• 430 mil metros quadrados de terreno foram ajardinados;
• 40 quilômetros de blocos instalados;
• Um hótel 5 estrelas foi construído no meio do circuito.

Ou seja, um construção daquelas que costumamos ver no programa Mega Construções do Discovery Channel.

E como todo projeto, há objetivos a serem alcançados ao término:

• Construir um circuito moderno e de acordo com as novas premissas estabelecidas pela FIA;
• Suportar um grande público e oferecer conforto ao mesmo;
• Uma boa iluminação que permita a realização de corridas noturnas;
• Encerrar o projeto em 2009, antes das inspeções da FIA para o grande prêmio de Abu Dhabi de F1.

Bem, esses são alguns objetivos que eu acredito que poderiam medir o nível de sucesso do projeto do circuito de Yas Marine. Abaixo, segue uma galeria de fotos, que mostra o circuito desde o início da construção até o término.

E além daqueles objetivos que citei, em uma reportagem divulgada no site PlanetF1, Richard Cregan, o administrador do circuito, revelou que os stakeholders do projeto esperavam algo incrível.

Portanto, de acordo com os objetivos citados e a expectativa dos stakeholders o projeto foi um sucesso, afinal o circuito ficou pronto no tempo e com certeza impressionou os stakeholders, dentre eles a FIA.

Eu mesmo comentei no twitter, após assistir os melhores momentos da classificação, que o circuito é fabuloso, nos faz perceber o quanto evoluímos em termos de construções, fazer um circuito daquele em pouco mais de 2 anos é um feito muito impressionante mesmo.

Porém…

Acho que faltou a opinião de alguém na história, não faltou?

Faltou “só” a opinião dos pilotos e dos espectadores.

Pelo que li pela internet e ouvi na narração da corrida, todos os pilotos ficaram impressionados com o circuito, porém poucos ficaram impressionados com o desafio que o circuito proporciona, tanto que o Rubinho disse que o ponto mais perigoso da pista é o túnel da saída do pit-stops, ou seja, pelo visto não é um circuito muito desafiador, até porque, se o piloto escapar em alguma curva, ele terá uma boa área de escape asfaltada para retornar a pista, o que vai causar apenas uma perda de tempo.

Como espectador, achei a pista bem sem graça, quase não há pontos de ultrapassagens, o que resultou numa corrida bem monótona.

Acredito que os stakeholders se esqueceram de dois ingredientes essenciais para uma corrida de F1: o desafio e ultrapassagens. Afinal, a ultrapassagem está para a F1, assim, como o gol está para o futebol.

E na lista de stakeholders da construção do circuito, acho que não foram incluídos os pilotos. (fail)

O ponto que quero chegar

O que ocorreu no projeto do circuito Yas Marina é algo que também ocorre em projetos de TI: a negligência em relação aos usuários.

Os projetos nascem e morrem de acordo com os interesses dos envolvidos, até aí tudo bem. O grande problema é quando esses interesses não incluem os interesses dos reais usuários do fruto daquele projeto. Quem participa do mundo da gerência de projetos ou já teve algum contato, sabe que nem sempre, o cliente será o usuário daquele determinado produto a ser desenvolvido, portanto o cliente tem um papel primordial de representar os usuários. Porém, nem sempre o cliente tem pleno conhecimento sobre o que os usuários esperam daquela determinada solução.

Algo que ocorre com uma certa frequência incômoda em projetos de software, é que eles não são centrados no usuário,  muitas vezes os usuários só terão contato com o sistema após o término do mesmo. E isso deve-se há vários motivos, dentre os quais um muito estranho é o medo do pessoal de TI de se envolver com os usuários, pois eles tem em mente que se forem conversar com os usuários eles irão pedir mais uma “trocentas” mudanças, e mudanças para esses profissionais é algo muito ruim. Afinal das contas, os interesses deles, às vezes se limitam em apenas obter o melhor ROI, e que se dane que a solução desenvolvida não solucione nada, seja difícil de utilizar, e que ainda tenha vários bugs. Para esses “profissionais” isso é até melhor, pois assim eles irão ganhar dando treinamentos e novos contratos de manutenção irão surgir. Ou seja, uma maneira de desenvolver software a lá Dick Vigarista e seguindo a Lei de Gérson, e que a médio e longo prazo não traz nem mais retorno financeiro, já que a fama da empresa já terá se espalhado entre os clientes.

Um outro ponto interessante de se comparar a construção do circuito de Yas Marina com a construção de um software, é que às vezes nós acabamos fazendo o mesmo que a FIA fez, burocratizar e criar padrões demais, e o mais preocupante, padrões fora do contexto da realidade, como por exemplo, criar circuitos que dificultem as ultrapassagens. Por isso, que é bom de vez em quando tirar a cabeça do prato.

Lembre-se que a qualidade é uma questão de ponto de vista, e no desenvolvimento de software o ponto de vista mais importante é o do usuário.

Fique por dentro das novidades, assine o feed do QualidadeBR.

Fonte:

http://en.wikipedia.org/wiki/Yas_Marina_Circuit

http://www.itv-f1.com/Feature.aspx?Type=General&id=47272

http://www.planet-f1.com/story/0,18954,3213_5658598,00.html

Imagens:

http://www.architecturelist.com/wp-content/uploads/2009/05/yashotel-asymtote.jpg

http://www.ameinfo.com/images/news/1/80441-YasMarina.jpg

http://www.bustler.net/images/uploads/asymptote_yas_hotel_06x.jpg

http://www.thenational.ae/apps/pbcsi.dll/bilde?Site=AD&Date=20090918&Category=NATIONAL&ArtNo=709179849&Ref=AR

Li essa frase (título do post) na capa da revista PM Network, e desde então sempre faço essa pergunta no início do dia: como fazer o GP ser indispensável?

Em minha área (Desenvolvimento de Software) busco sempre o desenvolvimento de produtos que agreguem valor ao negócio. Para isso, tenho que estar ”antenado” no plano estratégico da empresa para os próximos anos, buscando espaço para encaixar a tecnologia e trazer um ótimo retorno para o cliente.

Se a estratégia for reduzir custos, por exemplo, o foco deve ser em algo que facilite o gerenciamento dos custos, que permita um maior acompanhamento dos gastos da empresa, bem como saber o porquê da realização de cada gasto.

Com o plano estratégico em mãos o papel do GP é propor projetos bem estruturados, com início e fim, escopo definido, benefícios esperados, custos de arquitetura, usuários impactados, qualidade, recursos, riscos, etc. E ainda ter a capacidade de vender esse projeto para alta gerência. Acabou o trabalho? Não! Agora que ta começando… o projeto foi aceito! Tenho que continuar executando as tarefas que me tornem indispensável para o bom resultado do negócio, obtido através da gestão de projetos com confiança, transparência e credibilidade.

E você, já se fez essa pergunta? Se sim, qual a sua resposta?

Forte Abraço!

Post Publicado simultaneamente no Blog Renato Borges

Dia Mundial da Qualidade, 15 de novembro.

Se você fez parte de algum projeto ou case de qualidade em sua empresa mande relato para publicar no Blog Qualidade Manaus.

quadrinho: http://www.qualidadeemquadrinhos.com.br/

Se você é da área de TI, Informática ou Computação, provavelmente já ouviu falar de CMMI. CMMI (Capability Maturity Model Integration) é um conjunto de boas práticas de gerenciamento e melhoria de qualidade a serem aplicadas no processo de desenvolvimento de software.
Ao contrário do que muitos pensam, o CMMI não é uma metodologia de desenvolvimento de software! O CCMI é um conjunto de boas práticas para o processo de desenvolvimento e não para os projetos em si. Nesse caso, o CMMI deve ser visto no processo de forma macro e suas regras podem ser aplicadas nos mais diversos tipos de metodologias de desenvolvimento.
O metamodelo define uma série de medidas para a maturidade do seu processo de produção e classifica os processos de software em 5 níveis, de acordo com sua maturidade:

Etapas do CMMI

1.Realizado: Todas as metas específicas da área de processo foram satisfeitas. Isso inclui: definição de escopo dos projetos, ciclo de vida do projeto, estimativa de custos, prazos e esforço demandado para cada módulo/funcionalidade.

2.Gerido: Todo trabalho associado à área de processo está de acordo com a política definida pela organização. Envolve práticas de gerenciamento mais sofisticadas, algumas semelhantes à práticas do PMBoK, tais como: Gestão de Riscos, Orçamentos, Cronogramas, Planejamento de Recursos, Project Charter etc.

3.Definido: Todos requisítos do nível 2 foram alcançados e a empresa está alinhada com as ferramentas e comprometida com o modelo. O processo é mapeado e documentado.

4.Quantitativamente Gerido: A área de processo é controlada e aperfeiçoada usando medições e avaliação quantitativa. Indicadores para avaliação do desempenho dos projetos são criados.

5.Otimizado: O processo entra em fase de melhoria contínua. A maturidade é tanta que não é necessário mais criar novos subprocessos, apenas refinar os já existentes através de métodos estatísticos, garantindo maior qualidade e maior satisfação do cliente.

Obs: Os processos que não alcançam nem o nível 1 são considerados como Incompletos, e classificados a parte como nível 0.

E aí, qual é o nível de maturidade do seu processo produtivo?

Gantt - Projeto - Sonho (ou pesadelo)

Feliz aquele que consegue sair do trabalho e esquecer as pendências dos seus projetos. Será? Muitas das soluções aparecem quando menos se espera: no carro, caminhando, antes de dormir ou até mesmo dormindo!

Ultimamente tenho sonhado (no sentido real da palavra!) bastante com os projetos. Algumas noites mal dormidas, no qual o prazo e as tarefas são presenças constantes. Muitos contam carneirinhos… eu acabo contando os dias do meu prazo. Os sonhos (confesso que alguns pesadelos) são tão diversos quanto as áreas de conhecimento do gerenciamento de projeto:  o que conversar com o cliente – comunicação; o que conversar com a equipe – RH; como executar uma tarefa; como mitigar os riscos? Onde eles estão?; os testes serão suficientes?; Qualidade do software?.

Os sonhos bons têm um sistema funcionando, um cliente satisfeito, uma equipe valorizando o conjunto e celebrando o sucesso, uma ação eficaz para cada risco e um escopo sem alteração. Mas os pesadelos… me fazem acordar assustado, querer chegar ao trabalho para resolver tudo, acordar treinando sobre as ações a serem tomadas ou simplesmente passar a noite meditando sobre o que fazer para o projeto ter sucesso.

Sei que toda essa preocupação faz parte do dia a dia do profissional de projetos. Afinal, são esses projetos (trabalho) que permitem a realização dos projetos pessoais. Isso vai diminuindo com o tempo, com experiência e estudo, bem como conhecendo e confiando mais em sua equipe. Até lá, a minha esposa terá que aceitar (certos dias) eu acordando sem sentindo, suado e querendo só um abraço.

Falando em abraço… Forte Abraço!

Renato Borges

http://renatobs.wordpress.com

Definir o que queremos obter através de resultados de qualidade é muito importante, para que possa existir paramentros e métricas para a avaliação.

Em Tecnologia da Informação é comum observar a troca de garantia da qualidade e controle da qualidade, sendo assim se torna comum observar equipes de garantia da qualidade executando tarefas relacionas com o controle de qualidade.

Podemos afirmar que existem duas categorias para métodos de qualidade:

• Métodos preventivos
• Métodos de detecção

Esse agrupamento em duas categorias é o que torna a fácil distinção entre qualidade e método.

Definições

Garantia da Qualidade

É formada por um conjunto sistemático e planejado de atividades, seguindo o planejamento os produtos e serviços adquirem o mínimo de confiança pelo cliente e provavelmente estarão de acordo com suas necessidades (requisitos). Os responsáveis pela garantia da qualidade em uma empresa deve ser atribuída aos funcionários envolvidos com a implantação da política de qualidade.

Controle de Qualidade

Quando é realizada a comparação de um produto com os padrões aplicáveis estamos exercendo um controle de qualidade, sendo assim qualquer desvio identificado na comparação e avaliação é passivel de registro de não conformidade, que assim que for identificada deve seguir os passos para o devido tratamento. O controle de qualidade é uma função em linha, e o trabalho é realizado em um processo que permite assegurar que o produto funcione de forma correta (dentro dos padrões) e os requisitos sejam atendidos.

“Tanto a garantia da qualidade quanto o controle de qualidade se distinguem da função de auditoria interna. A auditoria interna é uma atividade independente dentro da organização, tem o propósito de revisar as operações e é uma tarefa de gerenciamento. É um controle gerencial para medir e avaliar a eficiência de outros controles” [*]

CMMI

No CMMI (Capability Maturity Model Integration), o propósito da Garantia da Qualidade de Software é fornecer ao gerenciamento a visibilidade da eficácia, com a intenção de desenvolver o produto com qualidade. A forma encontrada para avaliar o produto é realizar auditorias em módulos (parte do produto), afim de avaliar o resultado e facilitar a correções de desvios. Uma forma simples de executar tal tarefa é a utilização de Checklists definidos anteriormente.

As afirmações a seguir ajudam a diferenciar Controle e Garantia

Controle de qualidade

• está realacionado a um produto ou serviço específico;
• verifica se um produto ou serviço específico tem um atributo específico;
• identifica defeitos com o próposito principal de corrigi-los;
• é responsabilidade da equipe/ do funcionário.

Garantia da Qualidade

• ajuda a estabelecer processos;
• determina programas de medida para avaliar processos;
• identifica fraquezae em um processo e os aperfeiçoa;
• é um responsabilidade de gerenciamento;
• está realacionada com todos os produtos que serão gerados por um processo;
• avalia se o controle de qualidade está funcionando.

Dica:

• Controle de qualidade (relacionada a produto ou serviço)
• Garantia de qualidade (relacionada a processo)

Referência (Fonte):
* Base de Conhecimento em Teste de Software – Aderson Bastos, Ricardo Cristalli, Trayahú Moreira, Emerson Rios (8599102893)

Leitores,

O Fábricio Ferrari, blogger (qualidadebr.wordpress.com) teve a boa iniciativa de compartilhar um repositório com arquivos relacionados a área de Teste e Qualidade de Software no DropBox.

O objetivo é bem simples: compartilhar arquivos relacionados a área de Teste e Qualidade de Software, a fim de incentivar e facilitar o aprendizado.

Para maiores detalhes acesse:
http://qualidadebr.wordpress.com/repositorio-beta/

Qualquer dúvida, sugestão ou crítica entre em contato com o Fábricio.
Fabrício Ferrari de Campos, CBTS, CTFL
Blog: qualidadebr.wordpress.com
Twitter: twitter.com/FabricioFFC

Como comentei neste post, na minha opinião, a contratação de um profissional é um processo de suma importância, para ambos os lados.

Falando mais especificamente do projeto Basix, eu não posso explicar como foi desde o começo, pois entrei no projeto após mais de 3 anos do seu início. Então, nada melhor do que conversar com o Antonio, que gerencia o projeto desde o seu início, e até já fez um post relacionado ao assunto: O que vale mais conhecimento técnico, ou características pessoais?

Abaixo, segue a entrevista que fiz com o Antonio, focada no assunto contratação e especificamente da área de Teste e Qualidade de Software. Espero que gostem.

Fabrício: Antonio, antes de mais nada, em qual momento você percebeu que o projeto necessitava de uma área de Teste e Qualidade de Software?

Antonio: Percebemos isto desde a concepção do projeto, pois vínhamos de experiências em desenvolvimento de software sem uma área de qualidade, e já que estávamos começando um novo projeto não podíamos errar novamente da mesma forma.

Fabrício: E como foi o processo de contratação?

Antonio: Foi complicado, pois há 5 anos atrás era muito difícil convencer profissionais a trabalhar na área de qualidade de software, pois esta área não tinha a ênfase que tem hoje no Brasil, e as faculdades de TI não tinham disciplinas que ensinavam qualidade de software, no geral elas preparam os estudante para serem desenvolvedores.

Fabrício: A pessoa para atuar na área, necessita ter características específicas? Se sim, quais?

Antonio: Precisa sim Fabrício, aqui vou reproduzir o perfil que divulgamos no último processo seletivo que fizemos para a área de qualidade:

• Conhecimentos técnicos
  • Boa base de informática;
  • Raciocínio lógico;
  • Capacidade de abstração;
  • Capacidade de análise de problemas;
  • Inglês técnico (quanto mais experiente melhor).
• Funcionamento do grupo
  • O grupo de qualidade é um grupo que trabalha com atividades rotineiras, pois sempre que é liberado uma nova versão do software é necessário refazer todos os testes, necessário muita acuidade no trabalho, pois é o controle de qualidade do produto. É um grupo de generalistas, pois é necessário ter conhecimento de muitos componentes que constroem o produto.
• Personalidade que ajudaria a desenvolver o grupo
  • Perfeccionismo;
  • Organização;
  • Crítico;
  • Pesquisador.
• Características pessoais
  • Boa auto estima;
  • Extrovertido;
  • Bom relacionamento interpessoal;
  • Estar aberto a aprender;
  • Pró atividade;
  • Estar aberto a receber criticas.

Fabrício: Qual foi a maior dificuldade encontrada na contratação dos profissionais?

Antonio: Por ser uma área relativamente nova, foi bem difícil encontrar pessoas que queriam trabalhar na área de testes, a grande maioria queria desenvolver, então o processo de contratação também era um processo de convencimento, pois procuramos as pessoas que tinham as características ideais para trabalhar com qualidade, e muitos destes nós tivemos que convencer que era uma boa trabalhar na área de qualidade, e de qualquer forma tivemos muitos profissionais que depois de um tempo decidiram ir para o desenvolvimento, esta rotatividade foi uma dificuldade muito peculiar da área de qualidade.

Fabrício: Na sua opinião, até que ponto uma certificação ou especialização (ex. Pós-Graduação) ajuda o candidato durante o processo seletivo?

Antonio: Acredito que certificação ou cursos de especialização são sempre bem vindos, principalmente porque se um profissional decidiu  por conta própria estudar para conseguir um titulo deste isto no mínimo significa que a pessoa está interessada na área, e teve competência para obter o título, mas existe um outro lado para mim certificações e títulos não são de forma alguma os principais fatores para avaliar um bom profissional, pois existem profissionais excelentes que não tem nem a graduação completa.

Fabrício: Para fechar, de 2005 até hoje, a contração de profissionais para a área de Teste e Qualidade de Software ficou mais fácil? Ou ainda é difícil encontrar pessoas com o perfil e conhecimento para entrar na área?

Antonio: Com certeza o panorama do mercado da área de qualidade de software mudou completamente nestes últimos 4 anos, hoje já temos faculdades ministrando disciplinas voltadas para qualidade de software, existem comunidades de  que fomentam a área, e isto já reflete no mercado como um todo, hoje é muito mais fácil você achar pessoas que querem trabalhar com teste de software, e posso falar isto com tranqüilidade pois até o problema de rotatividade que tivemos diminuiu muito ao longo do tempo, hoje temos uma equipe de qualidade bem estável e onde todos realmente gostam de testar!!!

Muito obrigado Antonio pela entrevista.

No próximo post da série, irei falar sobre a complexidade do projeto e o papel da área de Teste e Qualidade de Software. Até lá!

Fique por dentro das novidades, assine o feed do QualidadeBR.

O teste de controle é um tipo de teste que está presente na Técnica de teste Funcional.

O nome sugeri a sua função como tipo, que é de controlar aspectos do sistema relacionados a integridade. Dentre os controles estão a validação de dados, a integridade de arquivos, as trilhas de auditoria, o backup e a recuperação, a documentação dentre outros aspectos.

Objetivos

O teste de controle é a ferramenta de gestão necessária para assegurar que o processamento seja realizado conforme o estabelecido no planejamento.

O teste de controle deve garantir:

• os dados estejam completos e corretos;
• as transações sejam autorizadas;
• a manutenção das informações da trilha de auditoria seja realizada;
• os processamentos sejam eficientes, eficazes e econômicos;
• o processamento atenda às necessidades dos usuários.

Como usar

O teste de controle pode ser considerado um teste dentro de outro. Os controles são desenhados para reduzir riscos, e, para isso, estes devem ser identificados.

Dica: Utilizar a Matriz de risco para ter uma melhor visão e assim verificar os controles.
Exemplos

• Determinar se os controles manuais, que servem para garantir que o processamento de sistema está correto, estão implantados e sendo usados apropriadamente.
• Selecionar transações de teste e verificar se o processamento para essas transações pode ser reconstituído.

Quando Usar

Os controles devem ser vistos como um sistema dentro do software de aplicação e testados em paralelo com os testes de outros softwares.

Fonte: Livro, Base de conhecimento em teste de software.

O gerenciamento de Comunicação em TI é muito similar as utilizadas em um projeto.

Sabe por quê ?
Utiliza processos de comunicação formal

• Correios eletrônicos
• Documentos Impressos
• Reuniões com Ata

Como melhorar a comunicação em uma equipe

• Reuniões semanais, sempre ao fim da semana, visando ter o fechamento do que foi realizado durante a semana.
• Informação sobre serviços de TI deveram estar em local público, de preferência em um diretório da rede e versionada, assim a equipe tem acesso a custos, prazos e atividades realizadas.
• Processos devem ser documentados e armazenados em local de fácil acesso (lógico e fácil).
• Solicitações no processo de comunicação devem ser feitas por escrito em documentos impressos e/ou através de e-mail e sempre deverão passar pelo crivo do gerentre de TI.
• Evitar reuniões de “Lavagem de roupa suja”.

Ata de Reunião

Todos os eventos do projeto deverão apresentar Ata de Reunião com no mínimo, os seguintes dados.

• Lista de presença
• Pauta
• Decisões Tomadas
• Pendências não solucionadas
• Aprovações

Desde o surgimento do modelo em cascata busca-se definir padrões de desenvolvimento de software, bem como a definir o passo a passo para a entrega do produto final. Devido a algumas semelhanças do desenvolvimento de software com conceitos de Gerenciamento de Projetos, essas duas áreas agora trabalham juntas na busca de qualidade, prazo e custo na implementação do sistema. Esse breve post trata de um exemplo de produtos e marcos de um projeto de software. Cada marco possui um produto e uma data/prazo de entrega. Eles são apresententados para acompanhamento por parte do cliente.

1 ) Planejamento: Project Chart, Descrição da demanda, etc.
2 ) Aprovação da Ordem de Serviço: o aceite do cliente para com a realização do projeto.
3 ) Implementação: Análise de requisitos, casos de uso, modelo de dados, telas, codificação, etc.
4 ) Testes e Ajustes: Estruturar ambiente de testes e definir os testes a serem realizados.
5 ) Disponibilizar para Homologação: Disponibilizar ambiente a ser utilizado pelo cliente.
6 ) Homologar: Aceite do produto por parte do cliente.
7 ) Implantar o sistema: Colocar o sistema em produção, pronto para utilização.
8 ) Fechamento do Projeto

Muitas dessas fases podem ser feitas em paralelo, de acordo com seu planejamento. A fase de planejamento de teste, por exemplo, pode começar logo após a definição das regras de negócio e casos de uso.
A qualidade do produto entregue dependerá de como essas fases serão gerenciadas e executadas.
O interessante é agendar reuniões com o cliente para acompanhamento dos marcos, verificando o que está em atraso e definindo novos prazos.
As fases acima é somente um exemplo de como estruturar um projeto de desenvolvimento de software.

Forte Abraço!

Renato Borges
http://renatobs.wordpress.com

Autor: Daniel Goettenauer

Sobre a Certificação
Objetivos da qualificação internacional (adaptado da reunião do ISTQB em Sollentuna, Novembro de 2001)

• Estar apto a comparar a prática do teste entre os diferentes países.
• Capacitar os testadores a trocar conhecimento mais facilmente entre as comissões.
• Permitir com que projetos multi-nacionais / internacionais tenham uma compreensão comum do empreendimento do teste.
• Aumentar o número de testadores qualificados  ao redor do mundo.
• Ter mais impacto como uma iniciativa baseada internacionalmente do que qualquer abordagem de um país específico.
• Desenvolver um corpo comum internacional de compreensão e conhecimento sobre teste e terminologias através do syllabus e aumentar o nível de conhecimento sobre teste para todos os participantes.
• Promover o teste como uma profissão em mais países.
• Capacitar testadores a obter qualificação reconhecida na sua linguagem nativa.
• Permitir o compartilhamento de conhecimentos e recursos entre os países.
• Prover o reconhecimento internacional de testadores e desta qualificação junto a participação de muitos países.

Requisitos básicos para esta qualificação

O critério para fazer o exame do ISTQB (Certified Tester, Foundation Level – CTFL) é que o candidato tenha um interesse em teste de software. No entanto, é altamente recomendável que o candidato também:

• Tenha um mínimo conhecimento em qualquer desenvolvimento de software ou teste de software, seis meses de experiências em um sistema ou teste de aceite ou desenvolvedor de software.
• Fazer o curso que é autorizado pelos padrões do ISTQB (por uma comissão nacional reconhecida)

Histórico da Certificação do Fundamento em Teste de Software

A certificação independente de testadores de software começou no Reino Unido com a British Computer Society´s Information Systems Examination Board (ISEB), quando uma comissão de teste de software surgiu em 1998 (www.bcs.org.uk/iseb). Em 2002, ASQF na Alemanha começou a dar suporte a um esquema de qualificação ao testador (www.asqf.de). Este syllabus é baseado no ISEB e ASQF syllabi; inclui um conteúdo organizado, atualizado e novo, e a ênfase é dada aos tópicos que fornecem ajuda mais prática aos testadores.

Um Certificado nos Fundamentos de Teste de Software (ex: ISEB, ASQF ou outra organização reconhecida por uma comissão nacional do ISQTB) obtido por alguém, antes que o Certificado Internacional fosse criado, será considerado equivalente ao certificado internacional. Este certificado não expira e não precisa ser renovado.

Com a participação de cada país, aspectos locais são controlados pela comissão nacional reconhecida pelo ISTQB. As responsabilidades da comissão nacional são especificadas pelo ISTQB, mas são implementadas em cada país. Dentre as obrigações das comissões dos países estão a autorização para prover treinamentos e a ministrar os exames.

Informações

Data: 09/10/2009
Inicio: 9h (horário de Brasília)
Duração: 1 hora
Local: UFAM – Universidade Federal do Amazonas – Av. General Rodrigo Octávio Jordão Ramos, 3000 – Campus Universitário – Bairro Coroado I – Manaus – AM, sala à definir.
Preço: R$ 350,00

Link: http://www.bstqb.org.br/modules/eguide/event.php?eid=77

Autor: Daniel Goettenauer
Iniciativa do Analista de qualidade Ueslei Silva da MXM em criar um blog para discussão e informações a respeito do MPT.BR.

http://mptbr.blogspot.com/

Uma nova perspectiva de Processo de teste no Brasil

Tendo como fundamento toda história em torno de “Teste de Software” e a realidade do mercado brasileiro de desenvolvimento de software, em novembro de 2007, após avaliações, análises e comparações Emerson Rios chega à conclusão de que mais do que criar um modelo de maturidade independente para o processo de teste de software temos, a primeira vista, o privilégio de implementar o que por ele foi chamado de processo compartilhado, ou seja, o MPS.BR (modelo criado com base no CMMI, normas ISO 12207 e 15504, para melhoria do processo de software brasileiro – seu foco é tornar possível a implementação do modelo nas empresas de pequeno e médio porte) é flexível ao ponto de se enquadrar completamente a realidade de uma fábrica de teste, a partir do momento em que o teste é tratado como projeto como relata o autor:

“Os métodos usados para testar software evoluíram à medida que os sistemas tornaram-se maiores, mais complexos e destinados a variados ambientes. Os testes passaram a ser executados por equipes especializadas e as empresas criaram áreas dentro de sua estrutura organizacional para cumprir esse papel. Passamos a ter projetos e processos de teste, que como tal são passíveis de melhorias. Há diversos modelos de maturidade de teste, entretanto o autor os considera desnecessários, propondo que seja utilizado o MPS.BR como modelo de maturidade…” (Rios, Emerson)

Algumas adaptações seriam necessárias e estas seriam em função da diferença entre os documentos adotados para o projeto de software e de teste.

Não tendo esta proposta aceita pelo MPS.Br. A ALATS em parceria com a RioSoft dão início ao desenvolvimento de um modelo de maturidade de processo de teste baseado no MPS.Br. Este modelo, que atualmente consta com os níveis 1 e 2 desenvolvidos e em implementação com projetos piloto, é chamado de MPT.BR (Melhoria do Processo de Teste Brasileiro).