Arquivo mensal: fevereiro 2010

Arquitetura para automação de testes

A 13ª Mesa Redonda DFTestes teve como tema “Arquitetura para automação de testes”, e tivemos 6 respostas e 3 participantes: eu, Elias Nogueira e o Felipe Silva.

A seguir, segue o resumo da discussão, quem quiser acessar a discussão na íntegra, basta acessar esse link.

Quais as atividades de um arquiteto de automação?

Segundo o Elias Nogueira:

As atividades são diversas, vou listar algumas aqui, mas não se restringe somente nisso:

->Criar a arquitetura de automação de testes;
->Criar a estratégia e direcionamento para os testes não-funcionais;
->Levantar/direcionar quais ferramentas podem ser usadas para determinado projeto;
->Sugere melhorias na arquitetura do sistema, para que fique compliance com a aplicação;
->Lidera/coordena uma equipe de automação, dando todos os direcionamento e resolvendo os problemas que os automatizadores tiverem;
->Cria todo o ambiente necessário de hardware e software para a aplicação da arquitetura de automação.

O Felipe Silva fez um comentário a respeito do papel do Arquiteto de Testes:

Não sou arquiteto. Como o Elias disse não é muito comum ver, trabalhar com um arquiteto ou ser um arquiteto de testes, eu particularmente só conheço o Elias, por este motivo não posso me aprofundar no assunto, só deixar minha opinião sobre o que eu penso à respeito.

A minha opinião sobre este papel é que é um papel extremista tecnicamente, digo extremista no sentido de que os skills necessários são diferentes de um skill de um tester funcional, pra quem gosta de programação mas ama testes mais do que desenvolvimento acho que este é o caminho, pra quem não gosta de programação e afins eis aqui o detalhamento do Elias da função para te ajudar saber se você realmente não gosta, pra quem gosta de um pouco de tudo, como eu, pense bem se quer ser um arquiteto ou não.
Uma coisa que gosto muito no cargo de analista de testes é que eu tenho uma liberdade de trabalhar com tudo um pouco, tornando o trabalho menos cansativo, quando eu “acordo para programação” crio scripts de automação ou desenvolvo alguma ferramenta para ajudar o time, quando não “acordo para programação” faço testes manuais, planejamento de cenários, revisão de documentos, casos de testes.

Na minha opinião as atividades que o Elias citou são as principais, destacaria apenas que o Arquiteto de Automação não é o Superman, e levará todo o projeto de automação nas costas, ele pode sim direcionar o rumo da arquitetura, mas todos podem participar e ajudar o mesmo a definir a arquitetura.

Além disso, quando estamos começando um projeto é essencial incluir esse profissional logo nas primeiras reuniões do time de desenvolvimento, pois o trabalho do Arquiteto fica MUITO mais fácil e é MAIS eficiente, quando temos um sistema com uma boa testabilidade.

Quais os conhecimentos que o arquiteto precisa ter para fazer uma boa arquitetura?

O Elias citou vários conhecimentos que um arquiteto necessita ter e disse posteriormente que “não é necessário ter 100% dos conhecimentos listados, mas sim fazer acontecer.”:

Precisa saber sobre muita coisa ao meu ver… Vocês conhecem algum arquiteto de aplicações (Java, .NET, etc..)? Um arquiteto de aplicações deve conhecer sobre diversas tecnologias, padrões, etc… sendo um profissional com o perfil muito técnico.

Ao contrário do que muitos pensam também, ele também conhece (ou deve conhecer) do negócio, justamente para montar uma arquitetura com base nas necessidades de negócio.

Alguns conhecimentos necessários de modo genérico:

->Conhecer de automação de teste em todos os níveis (óbvio); 😛
->Conhecer pelo menos mais que uma linguagem de programação, e ser bom pelo menos em uma;
->Conhecer sobre arquitetura de aplicações e design patterns;
->Conhecer a linguagem SQL, sendo bem mais que um simples ‘select’ (PL/SQL por exemplo);
->Conhecer sobre Sistemas Operacionais e virtualização;
->Conhecimentos avançados em Teste de Software;
->Conhecer uma gama de ferramentas de todos os níveis (de apoio, unitário, integração, funcional e aceitação);
->Conhecer muito bem Diagramas UML e ER, pois a base de uma arquitetura de automação desenhada se dá por essas ferramentas.

Realmente, é uma lista bem grande mesmo de conhecimentos que o arquiteto necessita, mas vejo que além de todos os conhecimentos citados pelo Elias (concordo com todos), ele necessita ter um bom senso e uma boa visão do todo.

E falo isso, pois com todo esse arsenal de conhecimento adquirido, ele pode querer construir uma bomba atômica para matar uma mosca.

A visão do todo é sempre importante de ter em mente, pois às vezes podemos esquecer dela, e acabar desviando do caminho que deveríamos seguir.

Desenvolver uma ferramenta própria ou utilizar uma ferramenta do mercado?

O Elias deu a sua opinião dizendo:

Isso é um discussão boa. Eu creio que hoje em dia não há necessidade de criar uma ferramenta própria para a maioria de trabalhos que são de mercado (aplicações comerciais, bancárias, COTS, etc…).
Hoje existem muitas ferramentas pagas e opensouce/free que suprem essa necessidade, e quando precisamos de customizações, ou nós mesmo fazemos em uma free/opensource (se é que já alguém não fez) ou pagamos/baixamos plugins que suprem a nossa necessidade de customização.

Claro que existe o contraponto. Há uns 2 meses eu dei aula de automação para um desenvolvedor que fazia softwares para controle de radares e mísseis, uma coisa totalmente atípica. Como aplicar automação para um tipo de sistema desses?
Resposta: é necessário desenvolver um!a

Existe também empresas que querem desenvolve suas próprias ferramentas: frameworks de automação, issue tracker, etc… E isso não é errado. Na verdade não existe certo ou errado, existe o que é o melhor para a organização.

Minha opinião então fica:
Se não existe nenhuma diretriz que a empresa tenha que desenvolver uma ferramenta: compre ou adote uma
Se existe uma diretriz para que a empresa crie uma ferramenta: desenvolva, e fique atendo as ferramentas opensources, pois você pode (dependendo da licença da ferramenta) utilizá-la como base para a sua.
Minha empresa faz algo “não usual” de aplicações comercias: desenvolva uma ferramenta, se isso for realmente de ajudar. Mas lembre-se de que isso pode não ter um retorno imediato.

A resposta dessa pergunta depende muito da natureza do projeto, e é uma das primeiras que o arquiteto deve buscar responder.

No meu caso atual por exemplo:

  • Estou utilizando o Selenium para criar uma API, que possa ser utilizada pelos testadores (ainda estou estudando como os testadores irão utilizar essa API, minhas opções são: JUnit, easyb e Concordion). Ou seja, optei por criar uma ferramenta própria, só que utilizando outras ferramentas já existentes no mercado; 🙂
  • Já em um outro projeto o desenvolvedor criou uma aplicação que executa os testes criados por nós, mas ela possibilita apenas executar as ações, e agora estamos criando uma aplicação que automatiza toda a execução dos testes (pré-condições, ações e verificações). Neste caso, optamos por uma ferramenta própria.

Quais os maiores problemas dessa área?

Para o Elias os maiores problemas são:

O maior problema é de, na maioria das vezes, não termos essa cargo tão bem definidos, ou termos pessoas que ocupam esse tipo de cargo que não são tão preparadas tecnicamente, o que pode fazer da automação um negócio caro, pois ele pode ser arquitetado e construído da maneira errada.

Também as empresas necessitarem deste tipo de profissional explicitamente. É bem pouco comum acharmos uma vaga como esta no mercado.

E a principal é o conhecimento de uma pessoa que se propõe a ser um Arquiteto de Automação. São muitos conhecimentos que temos que ter para desempenhar essa função, além dela ser a função mais técnica dentro da área de Teste de Software. E sabemos que muitas pessoas ‘não gostam de ser técnicas’ dentro da área.

Eu colocaria também o Arquiteto de Automação em Teste de Software nas reuniões de pré-venda com o cliente e, posteriormente, em contato com os arquitetos da empresa que está contratando estes serviços. Isso pode poupar muita dor de cabeça em “negócios mal vendidos” e pode realmente mostrar o que pode e o que não pode ser feito para o projeto.

Ao invés de Arquiteto de Automação, eu diria que o profissional é um Arquiteto de Teste. Para mim toda a pessoa que se diz “Arquiteto de Teste” deve ter estes conhecimentos.

Eu destaco os seguintes:

  • A testabilidade dos sistemas sob teste, principalmente nos casos de sistemas legados;
  • É uma área bem recente, por isso ainda não temos cargos bem definidos;
  • Difícil encontrar bons profissionais;
  • Nos caso de arquiteturas de automação de testes, é necessário primeiro convencer as pessoas que a automação é viável e pode ajudar a minimizar/resolver os problemas enfrentados, e isso muitas vezes não é uma tarefa fácil.

E vocês pessoal, alguém aqui é arquiteto? Alguém gostaria de virar um? Quais as suas opiniões sobre o assunto?

O Felipe Silva deu a sua resposta dizendo:

Eu acho que eu gostaria sim de ser um arquiteto, gosto muito da parte técnica, trabalho muito com muito com isso também (por que eu quero), porém meu medo atualmente seria assumir um papel menos flexível no sentido de poder fazer de tudo um pouco, o que faz o serviço mais saudável ao meu ver.

Não sou. É uma possibilidade no mínimo interessante, eu diria. 😀

Se já é difícil encontrar um bom Analista de Teste no mercado, encontrar um bom Arquiteto de Teste é mais difícil ainda. E isso ocorre por uma série de fatores, dentre os quais eu destaco três:

  • Acredito que boa parte dos companheiros de profissão, costumam ter a sua atuação mais voltada para a parte de Validação (negócio). Sendo assim, acabam indo em direção a área Gerencial (pensando em uma carreira em Y);
  • Ser um arquiteto é difícil, e você não se torna um, da noite para o dia (vide tempo necessário de experiência para essa vaga, por exemplo). Como o Elias e o Felipe disse, tal profissional necessita de diversos conhecimentos, e de forma sólida, e além é claro de boa experiência na área (lembrando que experiência é diferente de tempo na área);
  • O mercado ainda não sabe bem o que quer. Isso, infelizmente, é ainda uma realidade no mercado brasileiro, vide discussões já ocorridas no DFTestes sobre descrições de vagas de emprego.

Pra encerrar, acho importante a pessoa não buscar uma carreira simplesmente pelo status do cargo, você deve buscar a carreira que te dá mais satisfação profissional. Aliás, essa coisa de cargo na nossa área, na maioria das vezes, só serve para preencher no contrato ou na carteira.

Bem pessoal é isso.Continuem de olho na lista do DFTestes, pois sempre há assuntos bem interessantes lá, e poderão haver novas respostas nessa mesa redonda.

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

O melhor da semana 21/02 a 27/02

Pessoal,

Segue abaixo, a lista com o melhor da semana, espero que gostem:

Você leu algo interessante, relacionado a área de Teste e Qualidade de Software, e quer compartilhar? Sinta-se à vontade em colocar nos comentários. 🙂

Abraços! E tenham uma ótima semana!

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

Post mesa redonda

Disciplina * Habilidade = Artesão

Ontem li um artigo muito interessante no site do Jurgen. O artigo traz várias visões que também compartilho e acho importante, para quem trabalha com desenvolvimento de software conhecê-las e tirar as suas próprias conclusões.

Resolvi pedir a autorização e traduzir na íntegra o artigo do Jurgen (thank you Jurgen!).

Segue abaixo, a tradução do artigo, espero que gostem. 😉

Tenho certeza de que você reconhece esse problema. Você está com pressa, e ignora a rotina de verificar, ao sair de casa, se todos os seus pertences estão com você. Meia hora depois você está dirigindo de volta para casa, rosnando e xingando porque você esqueceu sua carteira, e agora está ainda com mais pressa do que estava antes.

Creio que a disciplina é uma das duas essenciais dimensões de um artesão. Qual impressão você teria de um piloto que se esquece de verificar regularmente os motores do avião? Ou um cirurgião que às vezes não tem tempo para lavar as mãos? Ou um ator em pleno palco, que às vezes não sabe as suas falas? Como consumidor, ou paciente, você aceitaria a desculpa: “Desculpe, eu estava com pressa?”

A importância da disciplina em qualquer ofício é evidente. Gerald Weinberg escreveu sobre o Efeito Boomerang nas pessoas que não seguem procedimentos: uma parte da garantia de qualidade é, simplesmente ignorada, o que acaba formando o seguinte efeito dominó:

  1. Aumento do número de problemas no produto que está no mercado;
  2. Aumento do número de problemas reportados pelos clientes;
  3. Sobe o número de interrupções de emergência;
  4. A pressão de tempo na equipe de desenvolvimento aumenta;
  5. E por fim mais procedimentos começam a ser ignorados.

Nós todos sabemos por experiência própria, que no fim das contas, ignorar a disciplina faz você ir mais devagar, não mais rápido.

No mesmo sentido, Mary e Tom Poppendieck descrevem que uma equipe de desenvolvimento de software não pode ser rápida, sem se preocupar em colocar qualidade em seus produtos. Ignorar checklists e procedimentos  só faz parecer que você está indo mais rápido, no início. Mas muito em breve, a falta de qualidade no seu produto, vai fazer você ir mais lento.

Weinberg descreveu seis níveis de maturidade para os seguintes processos:

  1. Perdido: “Nós nem sequer sabemos que estamos realizando um processo”;
  2. Variável: “Nosso trabalho depende de que como estamos no sentindo naquele determinado momento”;
  3. Rotineiro: “Seguimos nossas rotinas (exceto quando entramos em pânico)”;
  4. Guiado: “Escolhemos dentre as nossas rotinas, aquelas que trazem melhores resultados”;
  5. Premeditado: “Estabelecemos rotinas baseado nas experiências vividas com elas”;
  6. Coerente: “Todos estão envolvidos na melhoria de tudo o tempo todo.”

Weinberg usou esses seis níveis para classificar as organizações, mas eu prefiro qualificar somente os indivíduos de acordo com as suas atividades específicas. Qualquer coisa que acontece com uma organização é resultado emergente da interação entre as pessoas, muitas delas tem diferentes níveis de disciplina para diferentes atividades. Às vezes sou elogiado pela minha disciplina na escrita de um livro, que pode ser de nível 5 (premeditado) ou mesmo nível 6 (coerente). Mas, ao mesmo tempo, se você ouvir alguém xingando e gritando, pode ser que seja eu voltando para pegar a minha carteira, uma atividade que, aparentemente, está ainda no nível 1 (perdido). (Ou poderia ser meu esposo. Surpreendentemente, enquanto eu estava reescrevendo este parágrafo, ele voltou para recuperar sua carteira, depois de ter deixado a casa dez minutos antes …)

Uma combinação similar dos seis níveis foi introduzida por Ross Pettit da ThoughtWorks, que nomeou seus níveis: Regressivo, Neutro, Colaborativo, Operacional, Adaptável e Inovador. O significado dos seis níveis de Pettit é um pouco diferente, mas, como Weinberg, ele parece estar indicando níveis de maturidade na seleção e aplicação de processos.

A segunda característica essencial do artesão é a habilidade. Um desenvolvedor de software habilidoso pode ainda se dar ao luxo de ser indisciplinado, já um desenvolvedor disciplinado não é necessariamente habilidoso. Sendo assim, parece-me que o nível de habilidade da pessoa é uma outra característica que podemos utilizar para classificar a maturidade.

Há duas abordagens similares para indicar o nível de habilidade dos artesãos e artesãs: O sistema de guilda, que decorre da Europa medieval, especifica três níveis para as pessoas que treinam uma arte particular: aprendiz, artesão e mestre artesão. Este sistema é praticamente o mesmo que a variante japonesa Shuhari que descreve os três estágios dos praticantes de uma arte marcial: Shu, Ha, e Ri.

Em ambos os sistemas, as pessoas classificadas no primeiro nível estão aprendendo técnicas fundamentais, já as classificadas no segundo nível focam nas exceções e reflexões, enquanto não é necessário pensar muito, e tudo isso vem naturalmente, para as pessoas que estão no terceiro nível.

Nesta figura você pode ver que eu sou melhor como motorista, do que como escritor. Já faz 20 anos que eu dirijo, enquanto só faz 2 anos que escrevo. Mas a minha disciplina diária, como escritor, é melhor.

Quando desenhamos as duas características, disciplina e habilidade, chegamos a um diagrama bem útil para os artesões. O diagrama retrata bem que a maturidade pode ser medida em duas direções.

A habilidade pode ser perdida, com o envelhecimento, lesões físicas, ou avanços tecnológicos, já a disciplina pode ser perdida através da desmotivação ou distrações. Artesões necessitam de ambas características, portanto, os gerentes precisam se preocupar com as duas.

Revisado por André Pantalião.

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

P.S.: Obrigado ao Fernando Fontes, por ter compartilhado o artigo no Google Reader. 🙂

O melhor da semana 14/02 a 20/02

Pessoal,

Segue abaixo, a lista com o melhor da semana, espero que gostem:

Você leu algo interessante, relacionado a área de Teste e Qualidade de Software, e quer compartilhar? Sinta-se à vontade em colocar nos comentários. 🙂

Abraços! E tenham uma ótima semana!

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

9º Encontro Mensal da ALATS-SP

O  nono encontro Mensal da ALATS-SP terá a participação do Claúdio Schoeps falando sobre o X-Zone, framework open-source de teste criado pelo Alexandre Bartiê.

O encontro acontecerá no dia 6 de março (sábado) das 08:30 até às 12:00. Abaixo, segue maiores detalhes do evento, retirados do site da ALATS-SP:

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

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

Tema do Encontro:
X-Zone

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

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

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

Inscrições:
– Não Associados: R$ 30,00

– Associados ALATS 15% de desconto

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

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

Como evitar o “Testa aí”?

O tema da 12ª Mesa Redonda DFTestes foi “Como evitar o “Testa aí”?”, e a discussão teve 31 respostas e 12 participantes, sendo eles: eu, Camilo Ribeiro, Shmuel Gershon, Marcelo Andrade, Vicenzo Naves, Rafael Porfirio, Cristiano Fernandes, Felipe Silva, Luis Barros, Fermiano de Queiroz Filho, Jorge Diz e Edwagney Luz.

Abaixo segue o “resumo” do que foi discutido na mesa redonda, quem quiser acessar a discussão na íntegra e só acessar esse link.

Como evitar o “Testa aí”?

Segundo o Shmuel Gershon:

Não precisa evitar (!).

O que precisa é preparar os testadores e os outros colaboradores (programadores, administradores) para trabalhar no modo Testa aí.
“Testa aí” pode ser de muita utilidade em vários casos: Logo antes de publicar o programa, ou em quando o programador tem algumas versões intermediárias e quer saber se alguma tem problemas.

Mas todos devem saber os limites do “Testa Aí”, inclusive o testador.

Um “Testa Aí” bem feito leva em conta o conhecimento prévio e o tempo disponível, para decidir as áreas com mais necessidade de testes.

Para o Marcelo Andrade a participação ativa dos profissionais de Teste de Software é uma maneira de evitar o “Testa aí”:

Participando ativamente dentro do dia-a-dia do projeto. O testador deve vivenciar a equipe. Ele não deve ser uma pessoa estranha ao projeto.

Quais são os motivos que levam ao uso do “Testa aí”?

O Camilo Ribeiro acredita que vários motivos podem levar a empresa a usa o “Testa aí”:

Vários, mas o principal motivo é a falta de conhecimento do que um processo de testes pode agregar.

Muitas vezes, essa falta de conhecimento do valor é nossa culpa mesmo, pois não medimos o nosso trabalho, não aproveitamos o tempo livre para melhorar as nossas técnicas, não enviamos feedbacks como os gerentes precisam e focamos nossas melhorias em aquisição de ferramentas sem conhecer o nosso processo.

Segundo o Marcelo Andrade, são dois motivos:

Apenas duas coisas: o distanciamento e a falta de comunicação.

O Vicenzo Naves acredita que:

Eu creio que o que leva uma empresa a usar o testa ai é simplesmente o costume de não se testar e de alguns anos para cá a competitividade é tão grande que eles precisam tentar se assegurar o máximo possível (ou talvez o mínimo como se é feito em empresas mais antiga com sistema de legado) garantindo que as telas funcionam dentro do padrão, quando se fala em fluxo alternativo e fluxo de exceção pessoas ficam até com calafrios em empresas mais antigas, porque eles devem saber de bugs em fluxos alternativos que não conseguem corrigir por causa de POG utilizado em massa em sistemas muito antigos

O Felipe Silva listou os seguintes motivos:

  1. Falta de tempo
  2. Falta de necessidade
  3. Falta de conhecimento da importância de uma teste abrangente
  4. Planejamento de um Highlevel (teste exploratório) para achar defeitos óbvios nos primeiros instantes do testes (como dito pelo Rafael Porfírio)
  5. Falta de profissional qualificado
  6. Falta de informações básicas ao testes (requisito ou qualquer outra coisa que dê um norte da validação)
  7. Priorização de um outro teste de uma parte do sistema que ainda não está estável (highlevel de integração, em outras palavras um fast-regression)

    8. PS: Notem que citei casos onde o “Testa aí” ajuda e outros em que é prejudicial.

Segundo o Luis Barros:

Inicialmente a falta de um processo bem definido, não só de testes, mas no fluxo de desenvolvimento mesmo. Em seguida, a falta de visão geral, principalmente pelo time de desenvolvimento que ainda pensam que os testers são usuários sem noção e que os erros mesmo só vão aparecer em produção mesmo (sim, isso ainda existe).

Eu também acredito que vários motivos podem nos fazer usar o “Testa aí”:

  • A ignorância perante ao processo de Teste de Software;
  • Prazos apertados;
  • Problemas de comunicação;
  • Processos não humanos (onde ninguém pensa, tudo mundo já sai fazendo);
  • Imaturidade do time.

O Jorge Diz acredita que:

Acredito que falta ainda visibilidade da disciplina de testes entre os gestores de TI.

Ainda é difícil aprovar qualquer alocação de recursos financeiros (incluindo as horas das pessoas) específica para testes.

Provavelmente isto já dá para iniciar outra trilha de discussões, mas vejo alguns motivos para isso:

-> A falta de visibilidade do teste de software para o público em geral (o que inclui a alta gestão)
-> A ocupação de “mindshare” por parte da área de qualidade (entendida como institucionalização de processos) que, por motivos históricos, também não dá importância devida ao teste de software
(e, em muitos casos, nem àquilo que de fato promove a qualidade em geral). “Já estamos gastando em implantação de CMMi, deixa testes para depois”
->  A cultura de desenvolvimento sob medida no Brasil, em oposição ao software produto. Os riscos de software produto puxam antes a importância de testes para a gestão.

Qual conselho você daria para um pessoa que é vítima dessa “metodologia”? É possível alcançar bons resultados com ela?

O Camilo Ribeiro destacou a importância da mudança de postura do profissional de Teste de Software:

Pró-atividade.

Enquanto a pessoa que passa a maior parte do tempo no “testa aí” não gritar “Processo de teste ou morte” ela vai continuar no “testa aí”. Claro que não mudamos o mundo do dia para a noite, mas se gastar um pouco mais de energia desenvolvendo um processo, criando casos de teste, pesquisando e mostrando resultados, com certeza um dia os gerentes que diziam “testa aí” vão dizer “Quanto tempo precisa para testar?”. Outra coisa importante. Quando essa oportunidade aparecer, se for desperdiçada, existem poucas chances de uma nova oportunidade de mostrar o valor do teste novamente. O velho ditado: “Você não tem uma segunda chance de deixar uma boa primeira impressão”.

Sobre os bons resultados, se você for um excelente testador, pode conseguir resultados satisfatórios em projetos de pequeno porte (CRUDs e relatórios), mas na maioria das vezes é quase impossível, ainda porque, não existe forma de provar que teve um bom resultado com o “testa aí”.

O Shmuel Gershon lembrou da metodologia Rapid Software Testing, dizendo:

A metodologia chamada “Rapid Software Testing”, desenvolvida por Michael Bolton e James Bach é um dos métodos usados para “Testar Aí” de maneira eficiente, usando métodos puramente exploratórios e sendo 100% transparente com as partes aonde falta testes, conhecimentos ou mais tempo.
James Bach descreve seu curso assim: “Quando alguém te dá um programa e diz ‘você tem uma hora para testar isto’, você consegue fazê-lo? Você se sente confiante no trabalho feito? Pode explicar o que fez e por que?” (isto me parece bem ‘testa aí’), e continua “Rapid Software Testing é a arte de testar qualquer software, a qualquer momento, baixo quaisquer condições, de modo que o trabalho possa enfrentar um olhar examinador”. As traduções são minhas e ficaram horríveis de novo :).

Eu não sou um Rapid Software Tester oficial e profissional.

Mas em alguns casos meu time teve que testar um programa com pouco aviso prévio e curto prazo final. O modo como organizei isso foi deixando todos experimentarem um pouco com o software e logo organizando uma ou mais reuniões para identificar as áreas de ‘ataque’. Acredito que tivemos sucesso, mas não tenho como comparar isso a outra metodologia, então aceitem meu conselho com cautela e reserva.

O Marcelo Andrade respondeu dizendo:

Testador: converse mais, interaja mais, participe mais. A equipe precisa do seu feedback para desenvolver melhor. Você precisa do feedback da equipe para testar melhor.

O Felipe Silva deu o seguinte conselho:

Eu aconselho que a pessoa garanta que o “Testa aí” cobre a qualidade que exigem desta pessoa, se não cobrir ou essa pessoa tem que dar um jeito de lutar para mudar isso ou pode perder o emprego sendo acusado de não “testar direito”.

O Luis Barros disse o seguinte:

Quando possível forçar que o processo seja seguido, mesmo que para muitos ele seja “burocrático demais!” (10 minutos para liberar uma Release Formal)

Na minha opinião a primeira coisa a ser feita é conhecer melhor o processo de Teste de Software, as atividades, etc.

Depois converse com o seu líder/gerente a respeito do processo atual e dos problemas enfrentados, não precisa tentar convencer ele, às vezes só apresentar os fatos e as possibilidades de melhoria, já farão que ele mesmo perceba que algo precisa ser mudado.

Deixe claro que a mudança será benéfica a todos.

Agora sobre se é possível alcançar bons resultados, depende do que são bons resultados na sua realidade, acredito que a curto prazo até é possível, utilizando por exemplo testes exploratórios para aprender sobre o sistema, buscando se aproximar do desenvolvedor, etc. Mas a médio e longo prazo o “Testa aí” não é nenhum um pouco saudável.

O Jorge Diz deu as seguintes sugestões:

Tentar deixar claros os riscos de não haver testes apropriados dentro daquele contexto. Se isto falhar, o que normalmente acontece, procurar usar técnicas de teste exploratório focadas nas áreas de maior risco para o negócio. Lembro do Brateste do ano passado: na palestra do Ricardo Cristalli foi apresentado um cenário de pesadelo no qual, se lembro bem, ele tinha apenas janelas de tempo dentro de um confcall para instruir alguém a realizar testes exploratórios remotamente: ele trabalhou com o conceito de “test ideas” e conseguiu ser eficaz dadas as limitações do contexto.

Sempre se pode testar. Não adianta brigar com o que não podemos mudar no curto prazo: é necessário  dançar conforme a música e procurar baixar as expectativas de quem pede o “testa aí”. Obviamente, a eficácia fica comprometida: “bons resultados” devem ser relativizados pelo contexto.

Como convencer a empresa a parar de usa o “Testa aí”?

Mais uma vez, o Camilo Ribeiro acredita que a pró-atividade é uma importante característica que deve ser exercida:

Acho que a pró-atividade continua sendo o importante aqui. Nós somos o fator de mudança e essa mudança é conquistada com tempo e muito esforço. O conselho acima continua valendo: Feedbacks sobre qualquer melhoria e sua causa. Ser claro com os líderes sobre as condições do projeto. Tentar ser o mínimo técnico no sentido de ficar mostrando livros ou artigos sem mostrar resultados reais. Se conseguir mostrar resultados reais, com certeza haverá espaço para novas melhorias. Muita calma, mudanças são uma das coisas mais complicadas para os humanos.

Para o Shmuel Gershon não é preciso parar de usar o “Testa aí”, o que é preciso é usá-lo de modo correto:

De acordo com o que escrevi antes, a empresa não deve /parar/ de usar o “Testa Aí”, apenas deve usar o “Testa Aí” de modo correto. A maior parte do trabalho para isso recai sobre a equipe de testes, que deve ganhar a confiança do resto da organização.

O Marcelo Andrade disse:

Todos sabem que quanto antes um erro for descoberto, mais barato é corrigí-lo. Na prática, se é uma empresa 1.0 :-), esse convencimento é paulatino e só pode se dar quando os resultados aparecem. Feedback constante é essencial.

Para o Felipe Silva:

Mostrando dados, gráficos, números, dinheiro investido, para os dois casos (com “Testa aí” e sem “Testa aí”).

PS: Considerando que a minha colocação acima só é válida ao “Testa aí” prejudicial.

O Luis Barros lembrou que essa é uma questão cultural da empresa:

Cultura! Quando todos (do diretor ao próprio tester) derem o devido valor à disciplina de Testes as coisas, certamente mudam.

Eu vejo que você precisa apresentar informações relevantes e possibilidades de melhoria, converse primeiro com as pessoas que você acredita que irão concordar com você, e busque apoio.

Segundo o Jorge Diz:

De novo, mostrando os riscos e o impacto financeiro / de imagem. Mostrar para o gestor que ele também será visto como (ir)responsável caso Murphy decida dar o ar da graça;

O “Testa aí” pode acontecer mesmo quando já temos um processo definido?

Para o Camilo Ribeiro:

Processo definido != Processo institucionalizado.

O simples fato de ter um processo definido CMMi 5 ou ISO 9000/9001 não faz com que os problemas da empresa desapareçam, muito pelo contrário. Da mesma forma que agente não pode “mostrar menos” quando temos a oportunidade de “testar de verdade”, não podemos mostrar menos valor quando usamos o processo que está definido, pois se esse processo fracassar, mesmo que passe no SCAMPI dificilmente será usado com facilidade.

Sendo mais direto, o processo definido não significa nada, mas se o processo estiver institucionalizado, dificilmente haverão ocasiões de “testa aí”.

Segundo o Shmuel Gershon:

Sim, acho que um processo definido pode incluir o Testa Aí. Isso vai fazer o Testa Aí ficar mais fácil, pois em vez de aparecer de surpresa, a equipe de testes pode se preparar a tempo e escolher os testadores mais apropriados.

Já para o Marcelo Andrade:

Primeiro, sempre há um processo definido, mesmo quando ele não está escrito em lugar nenhum.

Processos devem refletir a cultura, os costumes e os valores daqueles que com ele trabalham. Se as pessoas são obrigadas a seguir um processo que não lhes parece natural, “faz aí porque está no processo” ou “testa aí porque está no processo” acaba sendo tudo a mesma coisa.

O Felipe Silva também acredita que é possível:

Sim pode, ver na resposta da primeira pergunta que muitas respostas se encaixam em uma situação de processo definido, tudo depende de como o processo foi definido, se permite ou não o “Testa aí”.

Segundo o Luis Barros:

Sim. Principalmente quando existe a falta de tempo: Todo mundo está “apagando incêndio” tudo vira prioridade. Aí entra o “Testa aí pelo amor de Deus!”, então a culpa, caso as coisas não funcionem, é do tester que não encontrou o(s) bug(s).

Também acredito que é possível, principalmente se o “Testa aí” já foi utilizado antes pelas pessoas, pois caso ocorra algum aperto, a primeira coisa que costuma ser feito é utilizar o “Testa aí”, e o grande problema é quando ele ocorre e apenas quem participa (famoso: fulano eu fiz só uma pequena alteração de nada, você poderia verificar ela aí?), geralmente desenvolvedor e testador, sabem disso e não reportam isso para outros profissionais, exemplos líderes e gestores.

O Jorge Diz fez o seguinte comentário:

Concordo com o Marcelo: processo definido não significa que seja o processo que está sendo usado. Aliás, cansei de ver processos de gaveta, que foram definidos por alguém externo (consultoria ou área de qualidade sem vivência no processo real) e que são impraticáveis.

O que já vi acontecer nesses casos é que os “desvios de processo” acabam virando o próprio processo. É a confirmação da teoria da janela quebrada: ninguém se sente obrigado a seguir qualquer processo.

Toda organização tem seus processos, escritos ou não, e as melhorias são feitas a partir dali, com a participação daqueles que usam os processos.

Mudanças em processos são complicadas, e são necessárias ações inteligentes para promove-las. Escrever um documento, convencer o gestor a assinar embaixo e desfilar  por ai com um chicote não é uma estratégia que costume promover melhorias sustentáveis.

O que afinal é o “Testa aí”?

Durante a discussão um ponto que não ficou muito claro foi o entendimento sobre o que é o “Testa aí”. Abaixo, explico o meu entendimento sobre essa “metodologia” e também trago alguns comentários do Camilo Ribeiro e do Shmuel Gershon.

Para mim o “Testa aí” tem as seguintes características:

  • O testador não tem informações sobre o sistema;
  • O prazo é apertado;
  • As pessoas esperam resultados rápidos do “Testa aí”;
  • Não há planejamento dos testes;
  • A comunicação entre desenvolvimento e testes é ruim;
  • O testador age de forma reativa.

Resumindo, seria um cenário de caos para o Teste de Software!

Um exemplo:

  • O desenvolvedor libera uma nova versão para o testador, passando a mesma por MSN (agh!);
  • O testador vai fazer alguns” testes que até a minha mãe faria”, pois o prazo para a entrega da versão já está estourado e não tem muito conhecimento sobre o sistema.

O Camilo Ribeiro disse o seguinte sobre o “Testa aí”:

O que eu entendo como “testa aí” é a entrega de uma demanda para uma pessoa realizar smoke tests e testes exploratórios sem o mínimo de planejamento, correndo contra o tempo e sem nenhuma garantia de cobertura. Desculpe a franqueza, mas não vejo nada de positivo nessa abordagem.

Concordo com o que o Camilo disse, também não vejo nenhuma vantagem no seu uso, e vejo que o mesmo só ocorre por uma série de fatores. Ou seja, ninguém deve usar o “Testa aí” por escolha, e sim por necessidade da situação, mas sempre tendo em mente os efeitos colaterais que o uso pode trazer.

O Shmuel concorda com as características que citei e faz alguns ressalvas:

Concordo com todas (informação, prazo, resultados rápidos…) , com estas ressalvas:
-> A comunicação entre desenvolvimento e testes é ruim — não necessariamente.
-> Não há planejamento dos testes — o planejamento acontece durante os testes, não antes.
-> O testador age de forma reativa — ele pode proativamente se preparar para ser um bom testador de “testa aí” 🙂
O que muda não é a situação ou as condições. O que muda é a atitude :).
Em minha opinião, essas situações são momentos em que o testador pode adicionar valor ao produto assim como outras. Mas concordo que não é fácil.
Já o Jorge Diz tem uma visão diferente sobre “Testa aí” e disse:
“Testa aí” me parece diferente de “Estamos nos 45 do segundo tempo e precisamos testar: vamos fazer o melhor dadas as circunstâncias”. No primeiro caso, o gestor não tem noção. No segundo, não tem opção.
Teste exploratório tem técnica, não é a mesma coisa que testar de qualquer jeito. Estamos falando aqui de teste exploratório sob condições extremas de prazo e recursos. Falta de tempo não é desculpa para falta de planejamento: atividades curtas e críticas são mais eficazes se feitas sem afobação. Mesmo que tenhamos uma hora de prazo, precisamos pensar como fazer o melhor uso possível desse tempo.
O papel dos testes é apontar riscos. Nessas circunstâncias, a capacidade de comunicação do profissional de testes com o gestor é colocada à prova. O resultado de uma atividade de testes nessas circunstâncias deve ser apresentado com clareza e sem a pretensão de ser um parecer bem fundamentado: o risco para o negócio vai ser grande de qualquer maneira.
Para encerrar o “resumo” segue um comentário bem legal feito pelo Edwagney Luz sobre o “Testa aí”:
Esse tal do “Testa aí”, é uma maneira clara de dizer: “Não tô nem aí pro que vai acontecer, quero embolsar a grana desse projeto e a equipe pós-projeto que se dane pra resolver a parada depois.” Sejamos lúcidos e francos. Quem usa “metodologia” do “Testa aí”, não está muito preocupado com qualidade. Se estivesse, daria mais atenção a alguns procedimentos antes da elaboração do termo de abertura do projeto. O erro vem lá de trás. O erro vem do planejamento e para mim, alguém chegar dizendo que o projeto não tem tempo hábil para um teste planejado, é porque não dá a mínima para qualidade. Desculpem-me a sinceridade, mas melhor doer de uma vez do que ficar sofrendo aos poucos. 🙂
Outra fator decisivo, é o fato de querermos dizer que estamos fazendo engenharia de software, sem usar procedimentos de engenharia. De novo, me desculpem as empresas desenvolvedoras que dizem fazer engenharia de software e não reservam tempo para teste, procedimentos de garantia de qualidade e etc. Elas estão apenas programando algum tipo de produto, mas fazendo engenharia não. Peguem qualquer livro de qualquer autor sobre engenharia de software e verão claramente todos os pontos da construção de um software usando conceitos de engenharia de software. Se não fossem necessários, não estariam ali. O fato é que alguém, um dia, disse que não precisava de qualidade, teste, e pulou toda essa parte e tudo bem… Hoje sofremos com isso e nossos clientes ainda mais.
Uma equipe de teste e qualidade deveria questionar sempre é: Se é pra usar o “testa aí”, o que “EU tô fazendo aqui?”
Bem pessoal é isso. Continuem de olho na lista do DFTestes, pois sempre há assuntos bem interessantes lá, e poderão haver novas respostas nessa mesa redonda.
Fique por dentro das novidades, assine o feed do QualidadeBR.
Pró-atividade.

Enquanto a pessoa que passa a maior parte do tempo no “testa aí” não gritar “Processo de teste ou morte” ela vai continuar no “testa aí”. Claro que não mudamos o mundo do dia para a noite, mas se gastar um pouco mais de energia desenvolvendo um processo, criando casos de teste, pesquisando e mostrando resultados, com certeza um dia os gerentes que diziam “testa aí” vão dizer “Quanto tempo precisa para testar?”. Outra coisa importante. Quando essa oportunidade aparecer, se for desperdiçada, existem poucas chances de uma nova oportunidade de mostrar o valor do teste novamente. O velho ditado: “Você não tem uma segunda chance de deixar uma boa primeira impressão”.
Sobre os bons resultados, se você for um excelente testador, pode conseguir resultados satisfatórios em projetos de pequeno porte (CRUDs e relatórios), mas na maioria das vezes é quase impossível, ainda porque, não existe forma de provar que teve um bom resultado com o “testa aí”.

O melhor da semana 07/02 a 13/02

Pessoal,

Segue abaixo, a lista com o melhor da semana, espero que gostem:

Você leu algo interessante, relacionado a área de Teste e Qualidade de Software, e quer compartilhar? Sinta-se à vontade em colocar nos comentários. 🙂

Abraços! E tenham uma ótima semana!

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

Testando em vários IEs com o IETester

No melhor da semana dos dias 13/12 a 19/12, eu compartilhei o link de uma ferramenta bem interessante e que pode ser bem útil para quem faz testes de sistemas Web.

Hoje vou falar um pouco mais sobre ela, mas antes disso é bom entender o porquê da existência dela e do seu uso.

O problema

Aliás, um grande problema para quem desenvolve sistemas Web, é garantir que ele tenha o mesmo comportamento, independente do navegador que o usuário esteja utilizando. E implementar isso é muito difícil, pois cada navegador tem características diferentes, por utilizarem Layout engines e JavaScript engines diferentes.

Como eu disse, esse é um grande problema, porém quando você pensa que as coisas não podem piorar, a lei de Murphy se mostra presente. E podemos resumir isso em duas palavras: Internet Explorer.

E além do Internet Explorer ser um navegador problemático, por usar (e só ele usar) o Trident, como layout engine, e o JScript, como JavaScript engine, os seus usuários não tem a mesma cultura de atualização do navegador como a dos usuários de outros navegadores, o que é um dos motivos por ainda termos que nos preocupar com o IE6 (argh!) e o IE7, além é claro da versão atual, o IE8.

E cada versão do Internet Explorer tem características diferentes e a mais horrível problemática é a 6, que até o Google já desistiu dela.

E se desenvolver já é um problema, imagina só testar!

E nós somos os responsáveis por realizar os testes de portabilidade (a portabilidade é um dos atributos de qualidade da ISO/IEC 9126), que tem como objetivo verificar o comportamento do sistema em navegadores diferentes, ou seja, a capacidade do sistema ser transferido de um ambiente para outro.

As soluções

Há várias formas de contornar esse problema desde a utilização de virtualização até ferramentas que emulam as diferentes versões do Internet Explorer (há até um site que abre a sua página em vários navegadores com diferentes SOs, o BrowserShots).

Eu sempre que precisei realizar testes de portabilidade , optei por usar máquinas virtuais, pois acho mais confiável e precisava testar até usando o Windows XP em japonês. 🙂

O IETester

O IETester é uma das ferramentas  que emulam o Internet Explorer (há também o MultipleIEs). Ele é um navegador que permite a mesma renderização e processamento de JavaScript do IE5.5, IE6, IE7 e o IE8, utilizando as várias versões da engine Trident e JScript.

O IETester é bem intuitivo e simples, é só escolher uma das versões do Internet Explorer, disponíveis na Ribbon (Faixa de Opções), e informar a URL, ou ainda você pode abrir uma URL em todos os IEs (do 5.5 ao 8).

Ele está em versão alpha, e pode ser baixado gratuitamente no site da DebugBar:

http://www.my-debugbar.com/wiki/IETester/HomePage

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

O melhor da semana 31/01 a 06/02

Pessoal,

Segue abaixo, a lista com o melhor da semana, espero que gostem:

Você leu algo interessante, relacionado a área de Teste e Qualidade de Software, e quer compartilhar? Sinta-se à vontade em colocar nos comentários. 🙂

Abraços! E tenham uma ótima semana!

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

Qual o futuro do Teste de Software?

Na 11ª Mesa Redonda DFTestes o tema discutido foi “Qual o futuro do Teste de Software?”, e teve 13 respostas e 8 participantes, sendo eles: eu, Sarah Pimentel, Shmuel Gershon, Talita de Oliveira, Felipe Silva, Marcelo Andrade, Elson Oliveira, Eduardo Gomes e o Aderson Bastos.

A discussão foi bem interessante e todos que participaram, fizeram boas colocações sobre o assunto. Mas não pense que utilizamos bolas de cristais e afins, todas as “previsões” foram baseadas no feeling de cada um, experiências vividas e opiniões próprias. Afinal, não somos da área esotérica, e sim da de Teste de Software. 🙂

A seguir segue a discussão íntegra, isso mesmo, dessa vez estou colocando a discussão na íntegra. Boa leitura! 🙂

Qual o futuro do Teste de Software?

O Shmuel Gershon fez o seguinte “horóscopo” para a próxima década do Teste de Software:

O alinhamento dos planetas mostra muitas boas oportunidades a sua frente. Todas elas são boas, mas saiba escolher — lembre-se de escolher a que melhor encaixa no seu contexto. Seus amigos são uma ótima fonte de conhecimento e experiência, use e abuse, e também retribua com sua própria contribuição.

Cuidado com poções mágicas, que são muitas e normalmente são falsas promessas ou a mesma água com açúcar. Cuidado também com soluções padronizadas, pois o que funciona em um lugar pode não funcionar para você. Não deixe ninguém trivializar seu valor e seu trabalho.

Mantenha sempre seu bom humor e boa vontade, mesmo que o príncipe encantado não venha com sua bala de prata (e não vai vir). Na falta de príncipe encantado, faça de seus colegas, supervisores e clientes seus melhores parceiros.

A Talita teme que o futuro possa não existe:

Temo que o futuro dos testes de software sejam desenvolvedores com função de analista de testes, ainda sem ter o conhecimento de um tester. Digo isso porque as empresas estão cada vez mais querendo programadores para entitular como analistas de testes.

A Sarah comentou sobre a preocupação da Talita dizendo:

Na minha opinião tem e vai continuar tendo espaço pros dois. Como o Jorge Diz profetizou nas respostas da última mesa redonda de automação, os agilistas estão reconhecendo a importância dos testes context-driven.

Segundo a evolução da história em qualquer âmbito, a primeira fase da história define padrões. A segunda nega esses padrões. E a terceira tende a tentar conciliar os padrões. Temos empresas em todas as fases. Acredito que a tendência seja um equilíbrio entre testes manuais e automatizados.

O Marcelo Andrade deu a sua opinião dizendo:

Se previsões fossem boas, Mãe Diná seria presidente da república, mas não custa nada. Vamos lá.

Tentando ser o mais objetivo possível:

– Crescimento de técnicas de desenvolvimento dirigidas por testes até a total indistinção entre estas e as tarefas de codificação.

– Aumento da importância de testes de usabilidade, acessibilidade, etc.

– Fim dos diversos papeis de testers. Busca cada vez maior por especialistas-generalistas.

Tentando dar um pano de fundo, lembro-me de uma excelente palestra do prof. Silvio Meira no SBQS 2007 sobre o futuro do software em que ele apontava a necessidade que há de se superar a questão da qualidade.

A pergunta se “o software funciona” estará ultrapassada. O software DEVE funcionar E ser confiável, robusto, extensível, etc. Será um pré-requisito. Tende-se a enxergar software não mais como produto intangível mas como serviço. As pessoas manipularão software, interagirão com ele, o utilizarão como insumo para criar software de mais valor, como uma cadeia produtiva (o exemplo que ele citava era do café -me foge a palavra agora- impensável se fazer um bom drinque de café de qualidade se não havia qualidade lá no grão, na planta, ou mesmo no solo).

Numa linha mais tecnocrata, não lembro se foi aqui que alguém citou as “vacinas contra bugs”. O tal do Dimmunix[1]. Talvez seja até uma aposta para o futuro também. Mas hoje acho muito difícil fazer previsão quanto a isto no momento.

[1] http://sitefrost.com/showthread.php?tid=18212&pid=148022#pid148022

A Sarah Pimentel fez um comentário bem interessante e com bom humor dizendo:

Mãe Sarah diz “Eu vejo… Eu vejo claramente!!!! Está muito nítido!!! 😀 O profissional que investir em si, investir em conhecimento seja em cursos ou em certificações, aquele que valorizar suas experiências, buscar enriquecer suas experiências.. Esse SEMPRE terá seu lugar” — agora cansei… esse negócio de prever o futuro é muito cansativo. Mas se você gostou da minha previsão pode depositar 1,00 na minha conta 😀

O Eduardo Gomes também deu a sua opinião sobre o futuro do Teste de Software:

Vejo o mercado de testes de software crescendo com muita velocidade nos últimos anos.
Há 3 ou 4 anos atrás, poucas empresas tinham equipes de teste independentes bem estruturadas. Hoje vemos essa estrutura se multiplicar, tanto em empresas que trabalham com desenvolvimento, como naquelas que utilizam os serviços de fábricas de teste para validar as aplicações desenvolvidas por terceiros.

A terceirização de serviços de teste é uma forte tendência, complementando a capacidade de teste interna das organizações. A especialização conseguida com as estruturas de fábrica trazem muitos benefícios para o contratante, principalmente na escalabilidade no atendimento de suas demandas e na independência dos testes em relação ao desenvolvimento.
Com esse mercado aquecido, as empresas investirão maior esforço na seleção de seus times, pois aquelas que estiverem melhor estruturadas, vencerão a corrida pelos melhores contratos.

Por outro lado, os profissionais de teste também deverão investir mais em sua empregabilidade. Nesse aspecto, as certificações serão um grande diferencial, principalmente aquelas que conseguirem distinguir profissionais com maior conhecimento e experiência.

Venho comentando há tempos com alguns colegas, que o teste é o carro chefe para a melhoria de muitos processos. É um processo que catalisa uma mudança cultural nas organizações, na direção de uma busca contínua pela qualidade.
É bonito ver isso acontecendo com a nossa área e saber que fazemos parte desse movimento!

Os centros de teste devem aumentar? Deve haver mais empresas focadas apenas no teste? As empresas vão contratar uma empresa pra desenvolver e outra pra testar?

O Felipe Silva pensa que:

Devido ao crescente número de empresas que estão se formando, que sim, haverá mais empresas focadas apenas no teste ou que terão um setor/departamento só para vender serviços de testes, o mercado já está pedindo isso, e sim o mercado diante dessa situação vai procurar uma empresa para desenvolver e outra para testar (isso já acontece com meu cliente), pois muito clientes pensam que se você contrata uma empresa diferente para testar é mais confiável do que um teste feito por quem desenvolve.

Essa é uma excelente pergunta e bem difícil de ser respondida, mas como o intuito das respostas é trazer impressões e previsões pessoais e não profecias, me arrisco a dizer que:

Os centros de teste devem aumentar?

Eu arriscaria a dizer que com certeza 🙂

Pois estamos a cada dia aprendendo a fazer software de uma forma melhor, e os clientes a cada dia que passa, exigem mais, portanto ter um “centro de teste” será fundamental para manter a competitividade das empresas.

Deve haver mais empresas focadas apenas no teste?
Sim, devem aumentar as empresas especializadas em Teste de Software, já que esse é um nicho de mercado que ainda não é muito bem explorado.

Embora eu tenha algumas opiniões contra a terceirização do Teste de Software (mas vou deixar pra falar mais sobre isso, em uma próxima mesa redonda 🙂 )

As empresas vão contratar uma empresa pra desenvolver e outra pra testar?
Isso depende muito do produto que está sendo desenvolvido, e do foco da empresa de desenvolvimento.

Mas com o crescimento do número de empresas especializadas em Teste de Software, isso pode se tornar uma tendência.

A Sarah Pimentel acredita que:

Não acredito tanto em um grande crescimento dos centros de teste, isso porque o papel do teste tem estado muito próximo ao do desenvolvedor e não vejo o cenário de alguém contratar uma fábrica de testes pra eles se “infiltrarem” 😛 nas empresas de desenvolvimento para acompanhar os desenvolvedores. Acredito que esse papel vai passar a ser mais desenvolvido dentro das próprias empresas de desenvolvimento. Isso para testes de sistemas. Já para homologação e projeto de teste de aceitação (após os testes de sistema das empresas desenvolvedoras), vejo uma tendência de envolver testes externos.

O Elson Oliveira acredita que:

Os centros de testes vão aumentar pois, como já foi dito aqui, a exigência por qualidade tende a aumentar junto com a complexidade dos sistemas. Portanto, vão aumentar e as fábricas de testes vão se segmentar em subáreas. Teremos especialistas em testes de segurança, especialistas em usabilidade/acessibilidade, especialistas em negócio/funcionalidade, automação, performance etc. As dimensões de qualidade definirão novas equipes e o  software terá que levar o carimbo de todas essas equipes pra entrar em produção.

As empresas vão aprender a selecionar profissionais de teste?

O Felipe Silva respondeu dizendo:

Não, acho que 10 anos é pouco para mudar isso, e como tudo está mudando muito em questão de processos e metodologias creio que muitas empresas vão tentar não só mudar o modo de seleção de profissionais de testes, mas também de outras áreas.

Eu acredito que sim, pois hoje mesmo, já vemos vagas com uma boa descrição, e com o amadurecimento das áreas de Teste de Software irá exigir profissionais mais qualificados. Além disso, o processo seletivo será cada vez mais seletivo (rs) e a participação de pessoas da área de Teste de Software no mesmo, irá contribuir para uma seleção mais eficiente.

Segundo a Sarah Pimentel:

Fé amigos! 😀 Mas acho que vão sim. É que o tema da outra mesa redonda “testar é tão fácil que ate a minha mãe testaria”, ainda está na cabeça de leigos. Mas tenho visto empresas melhorando sua seleção justamente porque antes achou que podia contratar “qualquer um” e tá colhendo os frutos disso. Agora estão melhorando sua seleção. Também os grandes centros já tem formas fantásticas de avaliar criatividade e conhecimento.

Para o Elson Oliveira:

Sim e já estão aprendendo. Muitas empresas já fazem provas de seleção visando contratar profissionais – inclusive tal assunto já foi discutido aqui –  que já possuam conhecimentos teóricos específicos na área de testes. Atualmente somos mais respeitados no mundo corporativo e os “aventureiros” na área entrarão em extinção.

Para o Shmuel Gershon:

Sim, mas para isso as empresas antes vão entender o que os testers fazem, e o que elas querem deles.

O espaço para testers que não sabem programar vai diminuir?

Para o Felipe Silva:

Sim, creio que sim, com o avanço da necessidade por automação nos processos, será necessário saber programar em todos as funções, umas menos outras mais (isso já está acontecendo e tende a expandir para as outras empresas)

Na minha opinião comparando com o presente momento, acredito que sim, mas mesmo assim irão existir vagas para testers que não sabem programar, assim como ainda hoje, há espaço para programadores que não sabem programar (acho que foi desnecessário esse último comentário rs).

Para a Sarah Pimentel:

Não vai sumir. Mas vai diminuir sim. Entretanto o papel de analista (que também pode ser feito por alguém que sabe programar) sempre será essencial.

Segundo o Elson Oliveira:

Quase certo que sim. Os profissionais  que gostam de programar não terão necessariamente que fazer parte de uma equipe de desenvolvimento. E estes se tornarão peças importantes para um equipe de teste e por possuírem esse skill poderão e serão mais valorizados. A habilidade de programação de um tester será sempre bem vinda nos ambientes de testes onde precisamos a todo instante testar com mais rapidez e com níveis cada vez maiores de  cobertura. Em outras palavras, a habilidade de se fazer um computador trabalhar pra você, ao menos naquelas tarefas repetitivas, onde se gasta muito tempo e pouco intelecto, com certeza é e será de grande valia, seja no contexto do teste ou em qualquer outro. Entretanto, os testes manuais obviamente nunca terão fim. O profissional criativo com excelente perfil investigativo sempre terá seu espaço.

As instituições certificadoras de profissionais vão convergir para um BOK único? Ou vamos continuar com definições variadas de termos?

Segundo o Felipe Silva:

Talvez, acredito que vamos ter uma melhoria, mas não que teremos termos únicos de uma vez por todas, são muitas instituições à nível mundial, o que dificulta tudo isso, mas é possível se quiserem.

Eu acho muito difícil, o que acho possível é os profissionais tentarem focar em só uma instituição certificadora.

A Sarah Pimentel deu a sua opinião dizendo que:

Gostaria, mas também acho improvável que isso um dia aconteça.

Na opinião do Elson Oliveira:

Provavelmente. Acredito que uma instituição vai se destacar no mercado, tendo dessa maneira maior aceitação e consequentemente maior procura. Mas ainda vai ter muita briga!!

Para o Shmuel Gershon:

1) Imagino que não, pois a BOK de cada certificação é parte de sua política e tem bastante ego envolvido.
2) Espero que não, pois uma das falhas das instituições certificadoras é acreditar que existe um BOK único que deve ser seguido por todos. Ao menos ao ter diferentes BOK por diferentes escolas, fica fácil entender que existem vários métodos descrever uma mesma coisa.
Essa ambiguidade é boa pois nos da flexibilidade de adaptar nossa pratica a realidade de cada empresa.

As faculdades vão incorporar a cadeira de Testes nos seus currículos?

O Felipe Silva disse:

Sim, vejo as faculdades sempre mudando sua grade de cursos de acordo com a necessidade do mercado também, muda até de cidade para cidade, acho que teremos duas situações nesta década, faculdades oferecendo pós em testes de software e outras faculdades incluindo a disciplina de testes dentro de suas grades no cursos base (sistemas de informações/engenharia da computação/ciências da computação, etc)

Na minha opinião sim, o mercado de Teste de Software a cada ano cresce mais, e isso demanda de profissionais qualificados, e ações como a feita pelos diretores adjuntos da ALATS-SP, por exemplo, que visitam faculdades e instituições para palestrar sobre Teste de Software, irão ajudar o meio acadêmico a enxergar a nossa área, e que entender a importante de haver matérias sobre a área na grade curricular dos cursos.

Além disso, novos cursos de pós-graduação devem surgir para a nossa área. 🙂

Segundo a Sarah Pimentel:

Certamente. Varias ações estão sendo realizadas nesse sentido e a faculdade também precisa de clientes. Para atender seus clientes eles tem que se adaptar.

Para o Elson Oliveira:

Ainda não incluíram?? Pois já deviam ter incluído na graduação. De qualquer forma, já existem bons trabalhos no nível de pós-graduação em nossa área.

O Shmuel Gershon imagina que:

Imagino que sim.
Mas não tenho certeza de que é uma boa notícia, pois a maior parte currículos voltados para testes que eu vi são baseados nos syllabus de certificações, o que trivializa um pouco nosso trabalho. 🙂

Quais evoluções poderemos ver no processo de Teste de Software?

Levando em consideração que o processo de Teste de Software, precisa ir na “balada” do processo de desenvolvimento.

Eu vejo que o processo de Teste de Software irá cada vez está focado na prevenção de defeitos.

Com o crescimento das metodologias ágeis iremos atuar muito mais próximo do desenvolvimento do produto e precisaremos nos adaptar a essa mudança, pois não haverá o time de desenvolvimento e o time de testes, haverá só um time (embora, eu ache que em alguns cenários é necessário a presença de um time de validação fora do time de desenvolvimento).

A garantia da qualidade não será uma responsabilidade apenas da área de Teste de Software, e sim de todos os envolvidos no projeto, e o teste será uma atividade enraizada no processo de desenvolvimento.

Com a automação dos testes unitários e de integração, iremos poder dedicar mais tempo a testes mais complexos e avaliar melhor outras características do software como usabilidade e segurança.

Resumindo, o processo de Teste de Software será menos reativo e mais pró-ativo, irá participar fortemente do desenvolvimento do software e terá maior contato com o cliente/analistas de negócios.

Para a Sarah Pimentel:

O teste faz parte do ciclo de desenvolvimento, então acompanha as tendências das metodologias seguidas. Com a moda agile agora, há mais interesse em automação e o modelo V tem sido praticado melhor, com os testes acontecendo junto com o desenvolvimento do projeto. A tendência é continuar acompanhando os modelos de desenvolvimento. Pro teste a tendência é ir se adaptando cada vez melhor ao entendimento que as pessoas vão tendo do agile.

Como será o profissional de Teste de Software do futuro? Quais conhecimentos ele precisará ter, a sua atuação irá ser concentrada aonde, etc?

O profissional de Teste de Software será um profissional generalista, terá que ter bons conhecimentos programação, banco de dados, arquitetura, metodologias de desenvolvimento. O profissional poderá ir mais para o lado técnico, o que irá exigir os conhecimentos citados, mas também poderá atuar mais no lado do negócio, e neste caso necessitará ter excelentes conhecimentos do negócio e boas características pessoais e de negociação.

A sua atuação será mais próxima ao time de desenvolvimento, e com isso ele irá aprender melhor sobre essa área e as tecnologias utilizadas.

Segundo a Sarah Pimentel:

Corroborando com o que falei na outra pergunta, o foco em prevenção tende a ser cada vez maior. Quanto melhor a sua criatividade e lógica para acompanhar o desenvolvimento do software, melhor.

O Felipe Silva ainda adicionou duas novas questões, e respondeu-as.

E o mercado de trabalho, estará como para a geração de vagas na área de testes?

O mercado estará faminto, muitas vagas em abertas, porém este mercado também estará mais exigente, certificações, experiências com ferramentas, conhecimento em programação, qualidade, processos, vai ser mais trabalhoso para alguém que é de fora da área entrar para área e pra quem já é de dentro será necessário se adequar para não sair dele, vejo também um boa oportunidade para nascimento de novas empresas de testes e treinamento.

E as empresas já existentes que desenvolvem e testam seus próprios sistema, haverá alguma alteração?

Sim, inicialmente as empresas que trabalham para o setor público já estão tendo que separar os times de desenvolvimento e testes, pois algumas licitações já pedem estes serviços separados fazendo um edital para da time, as outras empresas também devem seguir a onda, pois se verem que a terra é fértil iram tentar plantar suas sementes também, com oportunidades de trazer projetos de testes para dentro de suas empresas irão treinar seus profissionais para qualificá-los para este tipo de serviço, nesse rumo muitas empresas vão rever a automação como diferencial (que em breve vai deixar de ser diferencial) na venda de seu serviço de teste à um novo cliente, vejo também processos sendo revistos, pendendo à metodologia ágil, empresas mudaram o que for preciso para se mostrarem mais rápidos, confiáveis e baratos em relação à seus concorrentes.

Saiba mais:

Segue abaixo, algumas publicações que foram referenciadas sobre o assunto, durante a mesa redonda:

Artigo do Aderson Bastos – Potencial do mercado de testes de software

Sistema imunológico para computadores

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

Qual o futuro do Teste de Software?