O Caso Abu Dhabi – Usuário Negligenciado

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

 

Primeira Mesa Redonda DFTestes

Pessoal,

Hoje inicia a primeira Mesa Redonda do DFTestes. Para quem não acompanha o grupo, eu abri uma thread, há cerca de uma semana atrás, propondo a realização de uma mesa redonda, com o objetivo de discutir assuntos relevantes para a nossa área. E a escolha em fazer tal mesa redonda no DFTestes,  foi por ele ser o grupo com maior número de participantes e o mais ativo grupo de discussão brasileiro.

Acredito que será uma ótima oportunidade, tanto para os profissionais já experientes, quanto para aqueles que estão iniciando na área, para aprender mais sobre Teste e Qualidade de Software. E aprender de uma forma diferente, através de discussões abertas e online, onde profissionais de todo Brasil e até de fora, poderão participar e agregar valor a discussão.

mesa_redonda_dftestes

Então, fica aqui o meu convite para aqueles que já estão inscritos no DFTestes à participar das mesas redondas e para aqueles que não estão inscritos, fazer a inscrição no DFTestes e começar a participar. :D

O tema da primeira mesa redonda é “Testar é tão fácil, que até a minha mãe testaria!”, que obteve 20% dos votos, e já está aberta a discussão. ;)

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

O melhor da semana 25/10 a 31/10

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.

Encontro Internacional do ISTQB no Brasil em 2010

Muito boa a iniciativa do BSTQB,  o representante oficial do ISTQB no Brasil, de aproveitar a realização do encontro do Conselho do ISTQB, que ocorrerá no próximo ano no Rio de Janeiro, para também realizar um evento aberto em São Paulo, com duração de dois dias e voltado a área testes, contando com a participação ativa do Conselho brasileiro BSTQB.

Segue abaixo, maiores informações retiradas do site do BSTQB:

Em março de 2010 o Brasil sediará o encontro do Conselho do ISTQB (International Software Qualifications Board). Esse encontro contará com a presença dos Conselhos nacionais de cada país, onde o ISTQB é representado. Estarão presentes diversos nomes de destaque da área de testes de software, colocando o Brasil em foco. Será na cidade do Rio de Janeiro, no dia 19 de março. Essa é a primeira oportunidade do Brasil em sediar esse evento internacional, tendo disputado essa oportunidade com outros países.

Em conjunto com a reunião do ISTQB, teremos um evento aberto em São Paulo, com duração de dois dias e será voltado a área testes, contando com a participação ativa do Conselho brasileiro BSTQB. Esse evento terá a junção do público nacional e internacional, trazendo discussões atuais e relevantes sobre o tema ao nosso mercado. Diversos participantes do encontro do ISTQB estarão presentes nesse congresso, trazendo uma oportunidade única para o mercado brasileiro. Dados sobre esse evento serão divulgados pelo BSTQB.

O ISTQB é um Conselho internacional formado em 2002 e composto por representantes de mais de 40 países, os denominados conselhos membros. O número de Conselhos membros tem crescido a cada ano, demonstrando a importância e a abrangência do Conselho internacional. Esse Conselho é dedicado à disciplina de testes de software, e promove o profissionalismo na área através de um programa de certificações profissionais. O BSTQB é o Conselho membro brasileiro, formado em 2006 e com crescente aderência dos profissionais à suas atividades. Atualmente são mais de 120.000 certificados ISTQB no mundo, e mais de 500 certificados no Brasil, sendo a maior certificadora em testes de software no Brasil e no mundo. O ISTQB e seus Conselhos membros são entidades sem fins lucrativos. Essa estrutura traz transparência para suas ações, justificando seu sucesso e reconhecimento no mercado.

Três vezes ao ano, o ISTQB reúne seus membros dos Conselhos em uma reunião, o General Assembly Meeting, com diversas metas:

- Divulgação do status do programa de certificação;
- Tomada de decisões em relação a atividades do Conselho;
- Realização de votações relativas ao Conselho diretor; corpo de conhecimento, grupos de trabalhos, entre outros,
- Discussão e votação em relação à entrada de novos Conselhos membros.

Essa reunião tem uma grande importância para o encaminhamento das atividades do Conselho internacional. Também é de grande importância para o país que a sedia, visto que muitos nomes de destaque da área comparecem, contribuem com a comunidade, além de ser uma oportunidade de negócios e contatos.

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

P.S.: Agora é aguardar, maiores detalhes sobre o evento. :D

O melhor da semana 18/10 a 24/10

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.

O melhor da semana 11/10 a 17/10

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.

Como testamos o Basix? – Contratação

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. :D

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.

Precisa sim, Fabricio aqui vou reproduzir o perfil que divulgamos no ultimo processo seletivo que fizemos para a àrea de qualidade:

Conhecimentos técnicos:

Boa base de informática
Raciocinio 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
Critíco
Pesquisador

Caracteristicas pessoais:

Boa auto estima
Extrovertido
Bom relacionamento interpessoal
Estar aberto a aprender
Pró atividade

Estar aberto a receber criticas

Impressões do 6º Encontro Mensal da ALATS São Paulo – parte 2

Ontem, às 19:00 teve início a segunda parte da palestra “Agile e Scrum – O Tsunami da Agilidade na Praia dos Testes: Novos Modelos, Novas Ferramentas”, feita pelo Jorge Diz, no 6º Encontro Mensal da ALATS. A primeira parte da palestra ocorreu no final do mês setembro (30/09/09), porém teve que ser encerrada, antes do seu término, por ter ultrapassado o tempo disponível.

Abaixo, compartilho as minhas impressões sobre o encontro.

Sprint 1

Como de costume (aliás, um mal costume) cheguei em cima da hora. Ao entrar no auditório percebi que público presente era menor do que da última palestra, totalizando 9 pessoas. E dentro do auditório tinha uma mesinha, com o coffee, o que me fez pensar que não haveria o break, fato que acabou se concretizando. Ou seja, o Jorge planejou passar todo conteúdo numa sprint única.

O início da palestra se deu com o palestrante falando sobre o novo modelo de testes, necessário ao se utilizar metodologias ágeis. Utilizando a excelente explicação do fluxo ponta-a-ponta (erro -> defeito -> falha -> diagnóstico -> correção), influenciado pela metodologias ágeis, onde:

  • O erro pode ser evitado utilizando o conceito de Poka-yoke, como por exemplo, usando linguagens de tipagem forte (ex. Ruby);
  • Outra maneira de utilizar uma ferramenta que execute automaticamente os testes, a cada mudança nos arquivos do projeto relacionados com a mudança, ou seja, uma ferramenta que faça um teste de regressão de acordo com a mudança realizada, para verificar se a mesma não quebrou nada. Exemplo de tal ferramenta é o Autotest (que faz parte do pacote ZenTest);
  • Para encontrar defeitos é necessário… testes :) ;
  • É possível facilitar a identificação do motivo da falha, analisando a pilha de execução, exceções, logs e utilizando predicados fluentes (uma maneira de torna mais legível o método);
  • Para realizar o diagnostico é necessário ter uma gestão de configuração e depois reportar utilizando uma ferramenta de gestão de incidentes, famoso bugtracking;
  • Após a correção, se faz necessário a realização dos testes de regressão.

Agora você pode está pensando: mas boa parte das coisas que foram citadas eu já realizo no meu dia-a-dia?

Porém, utilizando agile muita dessas tarefas são realizadas de forma automatizada, realizando integração contínua, que acaba minimizando a quantidade de defeitos que seriam encontrados pela pessoa que fosse realizar o teste. E o mais importante é que o foco das metodologias ágeis é que o feedback  possa ser o mais rápido possível (lembra do manifesto ágil: “Indivíduos e interação entre eles mais que processos e ferramentas”. Trazendo isso para a realidade de Teste de Software, significa que o fluxo ponta-a-ponta será mais ágil;) o desenvolvedor pode receber o feedback da existência do defeito em “tempo de programação”, utilizando uma ferramenta do tipo Autotest.

Um ponto interessante que o Jorge Diz levantou, foi a carência de fontes falando sobre Teste de Software em metodologias ágeis, porém há uma excelente fonte, o livro da Lisa Crispin e Janet Gregory chamado Agile Testing (eu tenho ele, e recomendo fortemente aos interessados, é sem dúvida, a melhor bibliografia sobre o assunto até o momento).

Em seguida, o palestrante apresentou novamente a pirâmide frágil, na qual a maioria dos testes executados são testes de interface e poucos testes de unidade e integração são realizados. E o modelo ágil propõe uma inversão dessa pirâmide, como pode ser visto na figura abaixo.

TestingPyramid

Uma boa metáfora existente para explicar a diferença entre os três níveis de teste apresentados na pirâmide, feita pelo Patrick Wilson-Welsh, citado no livro Agile Testing, é a do três porquinhos. A camada de baixo é feita de tijolos, os testes são sólidos, e não vulneráveis ao sopro do lobo mau. Já a camada do meio é feita de madeira, precisa ser modificada com uma frequência maior do que a camada de tijolos, para permanecer resistente ao sopro do lobo mau. Por fim, a camada do topo é feita de palha, é difícil ela ser mantida no seu lugar e o lobo pode facilmente derrubá-la. Ou seja, se temos muitos testes feitos de palha, iremos precisar gastar muito tempo colocando-os no lugar.

Logo após, a explicação sobre a pirâmide dos testes, Jorge Diz falou sobre as escolas de teste, e os consensos que existem em comum entre elas:

  • Não é possível testar tudo;
  • Quem testa deve ter atitude crítica;
  • Testes tem custo;
  • Testes informam sobre risco;
  • Áreas concentram defeitos (bug clusters).

Encerrada a parte dos consensos, chegou a hora de falar sobre automação de testes no contexto ágil. Parte na qual foi apresentada uma série de ferramentas, de acordo com cada nível de teste e também uma explicação de alguns conceitos.

Para iniciar o assunto, o Jorge Diz logo apresentou as vantagens e desvantagens da automação:

Vantagens

  • Menos sujeita a falhas humanas, desatenção;
  • Menos sujeita a interpretações;
  • Executar testes automatizados é muito mais barato que manualmente, quando repetidos;
  • Regressão torna-se mais abrangente.

Desvantagens/Dificuldades

  • Dependência de sistemas externos;
  • Dependência internas do sistemas;
  • Controle sobre o ambiente;
  • Lentidão em alguns tipos de teste;
  • Fragilidade da API/interface usuário;
  • Custo da automação pode ser alto;
  • Necessidades de pessoas especializadas, o que geralmente, gera um maior custo.

O Jorge explicou um paradoxo bem interessante, o do campo minado,  no qual ficou bem claro a necessidade de realizar variações de cenários/caminhos de teste. Afinal, o intuito testes é que as minas explodam. ;)

Continuando a explicação sobre automação de testes, foi a vez de falar sobre as ferramentas existentes para realizar testes de sistemas Web:

  • Simular o browser – htmlUnit, Webrat;
  • Executar in browser em javascript – Selenium;
  • Adicionar browser a partir de um programa em Java – Selenium RC;
  • Acionar browser a partir de um plugin do browser – Selenium IDE;
  • Acionar browser a partir de um wiki – StoryTest IQ (Selenium + FitNesse);
  • Acionar browser a partir de um editor de workflow – CubicTest (Selenium + plugin Eclipse).

E necessário ter conhecimento sobre o que estamos testando, com determinada ferramenta, e para explicar isso, o Jorge citou as seguintes ferramentas:

  • Xunit – Módulos, classes isoladamente;
  • FIT – regras de negócio;
  • Cactus – funcionalidades de componentes web;
  • Selenium- Interface usuário;
  • JMeter – Estresse/desempenho.

Depois foi a vez de falar sobre as ferramentas XUnit, onde o Jorge começou falando que o programador gosta de programa e não gosta de tarefas manuais e repetitivas e por isso devem investir na utilização de tais ferramentas, para realizar os testes de forma automática e aumentar a qualidade do código.

Com testes automatizados,  os programadores conseguem gostar de testes, e testar torna-se uma tarefa central do desenvolvimento.

Em um time focado em automação de testes, há algumas mudanças:

  • Testes passam a ser ferramentas de desenvolvimento;
  • Teste unitário ocorre paralelo à codificação;
  • Rede de segurança para refatoramento;
  • Exemplos de uso do código sendo desenvolvido;
  • Complementos à compilação passam a existir (testes unitários, por exemplo);
  • Especificação de comportamento;
  • Validação para a integração contínua;
  • Adoção de um ambiente comum;
  • Infraestrutura para outros tipos de teste.

É importante também salientar as premissas para os testes unitários:

  • Teste unitário centrado no desenvolvedor;
  • Resultado independente da ordem de execução;
  • Independência entre métodos de teste;
  • A suíte de testes deve ser executada em alguns segundos;
  • Todo recurso está sob controle do programador (não pode depender do link de internet, banco de dados, sistema legado, etc);
  • Não é testada a integração;
  • Testes na mesma linguagem que o código sob teste;
  • Resultado não sujeito a interpretação (ou passou ou não passou);
  • Não colocar if no método de teste, se tiver ele é suspeito.

O Jorge Diz falou que o grande problema de realizar testes unitários é lidar com dependências. Levantando os seguintes pontos:

  • Se não consigo instanciar facilmente, não consigo testar;
  • Dependências podem se manifestar apenas em tempo de execução;
  • Dependências problemáticas precisam ser eliminadas ou substituídas.

Então a dúvida que surgiu foi: como lidar com dependências?

E a resposta: é preciso eliminar ou substituir.

Eliminar

  • Mudança no design para melhorar a testabilidade (exemplo da “vareta” para verificar o nível de óleo do motor);
  • Código-alvo precisa mudar para poder ser testado.

Substituir

  • Colaboradores substitutos em tempo de testes;
  • Dependências configuráveis(injeção de dependência, instrumentação).

E o importante: Se não conseguir eliminar ou substituir, não é teste unitário!

Em seguida o Jorge fez uma bela explicação sobre os colaboradores:

  • Dummy (sub objeto) – esta aí apenas para cumprir tabela;
  • Stub (método) – retorna uma resposta pré-definida;
  • Mock (objeto)- define previamente o comportamento esperado das interações da classe-alvo com o colaborador (proativo se ver algo errado ele já avisa, pois ele já tem incorporado o que tem que ser feito no Play[quando executa o teste]);
  • Fake (serviço/objeto) – substitui um serviço por uma implementação mais apropriada para o testes;
  • Spy (método/objeto)- registra comportamento para verificação posterior.

E há duas maneiras de testar de forma unitária:

  • Teste de estado – Verifica o estado da classe-alvo depois de exercitar uma funcionalidade;
  • Teste de interação- Verifica a comunicação da classe alvo com seus colaboradores.

Logo após a explicação sobre testes unitários e o uso de Xunit, o Jorge começou a explicação sobre o Selenium, e suas variações, que é voltado para testes de interface Web. E na sequência o Jorge falou sobre o FitNesse, voltado para testes de aceite.

O FitNesse tem as seguintes características:

  • Ferramenta wiki, que pode ser utilizada por Analista de Teste e de negócios;
  • Especificação de requisitos em planilhas;
  • É possível utilizar o FitNess usando DSL (Domain specific language), que serve para que seja criada uma linguagem mais próxima do usuário, você cria um conjunto de frases que podem ser utilizados depois;
  • Codificação de fixtures pode ser feita por programadores.

Também é possível importar um arquivo do excel para html, que é interpretado pelo FIT (FiTNess = Fit + Wiki).

Depois o tema foi BDD (Behavior-driven development), no qual há um formalismo para escrita de testes de cenários de negócio, geralmente da seguinte maneira:

  • Parte explicativa: Sendo um <Papel>, eu quero <funcionalidade>, porque <motivação>;
  • Parte executável: Dado que <pré-condições>, quando <ação>, então <verificações>.

Por fim, o Jorge citou as ferramentas que podemos usar com BDD:

Após, o término da palestra começou uma sessão de perguntas, que logo se tornou numa “mesa” de discussão (muito boa por sinal), onde variados temas foram discutidos: CMMI e metodologias ágeis, RUP é ágil ou não, dificuldades de implantar agile, as mudanças que ocorrem na área de Teste de Software e a maneira que ser realiza os  testes e vários outros assuntos relacionados a palestra.

Conclusão

A segunda parte da palestra do Jorge Diz, foi muito boa. Ele começou já falando sobre metodologias ágeis, e a palestra fluiu muito bem, sobrando até um bom tempo para as perguntas, que acabaram gerando uma excelente discussão (não é todo dia que você consegue discutir sobre agile e Teste de Software). :)

Com a palestra do Jorge Diz, acredito que ficou claro para todos os presentes, que o tsunami da agilidade pode melhorar muito a maneira como realizamos os testes, tornando o processo muito mais efetivo, além disso, as metodologias ágeis já tem na sua essência a preocupação com a qualidade do software, e ela não é uma preocupação/responsabilidade de apenas uma área, e sim de todos comprometidos com o projeto. :D

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

O melhor da semana 04/10 a 10/10

Pessoal,

Segue abaixo, 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.

O melhor da semana 27/09 a 03/10

Pessoal,

Segue abaixo, os links para 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.

Próxima Página »


Adicione no Google

 

Novembro 2009
D S T Q Q S S
« Out    
1234567
891011121314
15161718192021
22232425262728
2930