De acordo com o Aurélio, “
Numa escala de valores, qualidade é o atributo ou condição das coisas, que nos permite avaliar e consequentemente, aprovar, aceitar ou recusar qualquer coisa”
Se substituirmos o termo “qualquer coisa” por sistema, aplicação ou produto de software, vemos que a definição é muito adequada para o contexto de desenvolvimento, implementação e implantação de software.
Assim, testes de software são realizados com a finalidade principal de avaliar diversas dimensões de qualidade do que foi implementado, tais como funcionalidade, usabilidade, performance, segurança e outras. Preferencialmente, antes que ele seja implantado em produção.
Há pouco mais de uma década, os usuários e patrocinadores finais dos sistemas pouco opinavam a respeito dos mesmos. Funcionalidades, usabilidade e outros requisitos eram definidos pelo time de especialistas que os desenvolviam e de certa forma determinavam como ele deveria funcionar e quando seriam liberados. Caberia ao usuário seguir o manual de utilização, quando este era disponibilizado.
Esse cenário mudou e os usuários agora têm muito poder: conhecem e querem tecnologia, sempre o que tiver de mais novo; querem as coisas sempre mais rápidas, melhores, baratas; aceitam riscos mas o produto precisa entregar valor; determinam o que domina o mercado e demandam nível cada vez mais alto de qualidade para o produto final .
Os processos de desenvolvimento se modernizaram para dar conta das novas demandas , das pressões crescentes por prazos de entregas cada vez menores e maior flexibilidade à mudanças. Os métodos ágeis passaram a ser amplamente adotados pelos times de desenvolvimento de software nesse contexto.
No entanto, se percebe que a maioria dos times de testes não incorporaram essas metodologias ágeis, continuam funcionando do mesma forma que funcionavam há décadas. Em outras palavras, não conseguem acompanhar o ritmo das equipes de desenvolvimento, havendo um descompasso entre eles.
São muitas as razões para que isso aconteça. Vejamos algumas: em todo treinamento sobre qualidade se ouve que todos são responsáveis pela qualidade do produto, não apenas os testadores. Em especial, a qualidade do próprio processo de desenvolvimento adotado contribui para a qualidade do produto final. No entanto, muitas vezes não existe uma definição clara de papéis e responsabilidades, de como cada pessoa no time deve contribuir para a qualidade, que atividades e artefatos e ferramentas estão sob sua responsabilidade e como compartilham os mesmos.
Fatores organizacionais também contribuem para esse distanciamento: comumente desenvolvedores e testadores estão organizados sob unidades distintas, com objetivos e métricas próprias. É comum ainda existir uma área de infra-estrutura, que também trabalha independentemente dos desenvolvedores e testadores, responsável pela disponibilização de toda infra-estrutura de hardware e software, para a montagem dos laboratórios
E tipicamente, na maioria das organizações, os testes de ponta a ponta, quando realizados, são feitos numa única vez, antes de serem liberados para produção.
“Para que se testar o sistema, quando ele não está pronto ainda?”. Além disso, os times de testes e de infraestrutura servem a diferentes times de projetos e os recursos, máquinas, pessoas, precisam ser compartilhados entre todos.” Isso dificulta a adesão a um modelo mais ágil, onde os testes são realizados de forma contínua e incremental.
Resultado: os times de testes, desenvolvedores e infraestrutura/operações trabalham apartados entre si e a existência desses silos, gera áreas de atrito e dificulta a colaboração entre os times e pessoas.
Por que tanta resistência a um modelo mais ágil para os testes? Primeiramente, porque é usual se esperar pela interface de usuário, esperar que ela fique pronta para então se realizar os testes. E também porque as aplicações atualmente são muito mais complexas do que eram no passado, não são mais monolíticas e o sistema em teste pode se integrar com diferentes aplicações para retornar o valor esperado pelo usuário. Então, a montagem do ambientes de testes também ficou mais complexa e custosa: é necessário a disponibilização de muitos recursos, não apenas sistemas, mas também máquinas, servidores e pessoal com conhecimento das várias aplicações envolvidas, com autorização para executá-las, para se validar o sistema em teste.
Esses pontos, desafiadores para qualquer time de projeto, ficam mais críticos quando se trata
metodologias ágeis. O que muitos times fazem para driblar esse descompasso entre desenvolvimento e testes é criar iterações ou sprints, no final do ciclo de desenvolvimento, dedicados exclusivamente para validação e testes. Mas isto foge à própria definição de métodos ágeis. Segundo um dos princípios constantes no
Manifesto Agile, o código executável deve ser a principal medida de progresso. Ou seja, o código executável, deve ser validado a cada iteração, para ajudar a diminuir os riscos dos projetos. Não de forma unitária apenas, mas as integrações, pontos críticos para a qualidade, também precisam ser validadas a cada iteração.
O ponto é: como o desenvolvedor vai conseguir realizar esses testes, quando as interfaces de usuários ainda não estão disponíveis? Ou outros componentes da mesma aplicação ainda não foram liberados para testes? Ou quando é necessário trocar informações com sistemas externos, muitas vezes pertencentes a terceiros, que só vão estar disponíveis durante um pequeno período, ao final do projeto? Ou quando o ambiente de testes só vai estar disponível no final do projeto?
Então, naturalmente, os desenvolvedores nas metodologias Agile delegam os testes de integração, por sua natureza, complexos, aos times de testes, para serem feitos numa etapa final, de homologação.A separação entre times de desenvolvimento, testes e infraestrutura/operações num projeto Agile aumenta os riscos dos projetos.
Como então promover essa integração entre esses times?A resposta não é simples, nem única. Mas passa por 2 componentes básicos:
processos e ferramentas.O primeiro ponto a se endereçar é colocar todos nos mesmos marcos, compartilhando os mesmos objetivos e informações do projeto. Também é necessário estabelecer um sincronismo entre eles, de forma que um não atrapalhe o trabalho por outro. Por exemplo: testador apontando erros numa story ainda em desenvolvimento. Por outro lado, o desenvolvedor precisa ter a seu dispor os recursos que lhe permitam ir além da realização dos habituais testes unitários: precisa contar com os tests cases, disponibilizados pelos testadores, para validar as integração, de forma contínua, em cada iteração.
Esse aspecto processual requer que testadores e desenvolvedores usem as mesmas ferramentas para gerenciamento e automação de testes. Também requer a implementação de um fluxo de aprovação, indicando quando um test case está disponível para testes. Ferramentas que suportem a colaboração entre os times e compartilhamento de informação, de preferência em tempo real, subsidiando coleta de métricas e tomada de decisões , são bem vindas.
Os desafios técnicos são enormes, em especial para que se possa realizar testes unitários e de integração a cada iteração, quando outros componentes ou interface de usuário ou sistemas não estão disponíveis. No entanto, o fato das aplicações hoje não serem mais grandes blocos monolíticos, mas componentizadas, permite o uso de ferramentas , que realizam os testes nas diferentes camadas da aplicação, como lógica de negócio, serviços técnicos e banco de dados, sem necessidade de se escrever uma linha de código para isso, apenas através de configurações. São as ferramentas de testes e de virtualização de aplicações e serviços.
As ferramentas de virtualização de aplicações simulam o comportamento de aplicações, componentes ou serviços indisponíveis para os testes. Esses elementos virtuais podem ser providos a partir de qualquer máquina na rede, ou de uma nuvem, pública ou privada. À medida que as aplicações e componentes e serviços são desenvolvidos ou disponibilizados, os elementos virtuais são substituídos pelos respectivos reais.
Só assim, os testes de integração a cada iteração se tornam possíveis. No início, existem muitas partes virtualizadas, que vão sendo substituídas aos poucos pelos reais. Esse teste antecipado, a partir de componentes virtuais, também permite que uma etapa de homologação, ao final do projeto, seja realizada de maneira mais rápida e menos custosa, pois a interface entre as partes já foi validada.
Um ponto importante, em termos de processo, é que esse tipo de ferramenta permite a criação de áreas de testes de integração, individuais, para cada desenvolvedor. O que significa numa mudança de papel para desenvolvedores e testadores: os desenvolvedores passam a ter autonomia para realizar testes de ponta a ponta e os testadores, podem ser os responsáveis pela disponibilização de elementos virtualizados, a serem compartilhados pelos times. Os desenvolvedores adquirem maior autonomia para realizarem os testes de seu código, pois não ficam dependendo de outros componentes, time, recursos ou da agenda de terceiros, para montarem a área de testes ou recursos : podem simular o que não está disponível e garantir maior qualidade no código liberado.
Assim, processos e virtualização, juntos, proporcionam
maior agilidade aos testadores e aos times. No entanto, ainda temos um ponto a considerar: não basta que os desenvolvedores e os testadores trabalhem integrados e sejam ágeis. O time de operações também precisara acompanhar o ritmo. Melhorando a integração entre desenvolvedores e testadores, o pressão recai sobre a interface entre desenvolvimento e operações, que é foco de atenção atualmente , de onde surge o termo
DevOps. Este passo também é necessário para dar agilidade a TI como um todo, gerando impacto significativo nos negócios. Falarei sobre isso num próximo artigo.
A
IBM Rational possui consultoria em processos e ferramentas para suportar o desenvolvimento e testes em metodologia ágeis, que implementam uma plataforma colaborativa de desenvolvimento e permitem integração entre desenvolvimento e operação.
Para uma visão geral:
www.ibm.com/software/rationalA própria IBM usa Rational para implementar seus produtos e está em constante transformação para deixar seus processos cada vez mais ágeis:
http://www.youtube.com/watch?v=PjE-XeJuV7Q&list=PLF491A0C598AF9E39&index=24 A IBM Rational também possui ferramentas para testes e Virtualização de Aplicações e Serviços.
Para saber mais a respeito do assunto de virtualização, especificamente:
http://www-01.ibm.com/software/rational/servicevirtualization/Ou se preferir, meu email
Ana Negrello
ananegre@br.ibm.com
25
0
Todas as sessões gerais abordaram o
DevOps com perspectivas diferentes, desde o benefício para os
executivos até os desenvolvedores. E é claro que o Brasil não
poderia ficar de for a disso, tivemos uma palestra sobre uma
referência brasileira no evento, onde compartilhamos com outros
usuáros do mundo a experiência de implementar uma solução deste
porte.
