Ciclo de Vida em QA Uma perspetiva complementar André Cristóvão Martins ALFRAPARK Edifício C Piso 2 Estrada do Seminário, 4 - Alfragide 2610-171 AMADORA (Portugal) Telemóvel: +351933223703 e-mail: acristovao@indracompany.com 9 de Junho de 2012 Resumo Pretende-se com este artigo dar a conhecer boas práticas circundantes ao processo de desenvolvimento de Software com vista a contribuir para o aumento de eficiência/eficácia e qualidade do produto final a desenvolver. Este artigo é também um testemunho pessoal com vista a que todos os leitores possam encarar a qualidade com outros olhos. Palavras-chave: Quality Assurance, Automatização, Integração Contínua, Autonomia de uma equipa de QA Onde Começa QA? É sabido que quanto mais cedo existirem tarefas de Quality Assurance no seio de um projeto, maior ganho de qualidade tem o produto final. O Modelo V (ilustrado na Figura 1) advoga isso mesmo, sendo um modelo que representa um processo de desenvolvimento de Software. Sucintamente, o Modelo V enfatiza a importância de considerar as atividades de testes durante o processo, ao invés de uma fase de testes após o término do processo. Deste modo, aquando levantamento dos requisitos e definição da especificação funcional, uma equipa de testes deve, paralelamente, elaborar o caderno de especificação de casos de teste de aceitação e o caderno de especificação de casos de teste funcionais. Posteriormente e, com a elaboração do caderno de especificação técnica, a equipa de testes deve conceber o caderno de especificação de casos de teste de integração. Na fase de implementação dos módulos de software são especificados os casos de teste unitários. Nesta fase, é atingido o vértice do V e começa a execução dos testes anteriormente especificados. Cronologicamente a execução dos testes inicia-se pelos testes unitários que é seguida depois pela execução dos testes funcionais e de integração e, por fim, a execução dos testes de aceitação, estes já executados pelo cliente delegando à equipa de testes um papel de acompanhamento/esclarecimento da execução dos testes. Ciclo de Vida em QA Uma perspetiva complementar Página 1
Figura 1 - Modelo V Esta abordagem traz a meu ver duas grandes vantagens: 1- Antecipar possíveis não-conformidades em qualquer ponto do projeto, reduzindo o custo de resolução e evitando a propagação de uma não-conformidade por outros módulos; 2- Antecipar a necessidade do conhecimento do negócio de uma equipa de testes permitindo a esta um aumento de eficácia e eficiência aquando início da execução dos testes; Com esta introdução processual, vamos agora descer um patamar e centralizarmo-nos na origem do Software propriamente dita. Procurarei abordar aplicações e boas práticas que servem de catalisadores para a qualidade do produto final. Aplicações de Controlo de Versões Para os menos familiarizados, uma aplicação de controlo de versões não é mais que um grande repositório centralizado onde são armazenados quaisquer artefactos produzidos pelas diversas equipas constituintes num projeto, sejam eles propostas, requisitos, especificações funcionais, especificações técnicas, cadernos de casos de teste, código, etc. e onde são controladas as alterações destes. Aplicações como Commit Monitor tornam possível saber em modo real quem, quando e o que foi alterado. Como sugestão, deixo a boa prática de condicionar a necessidade de introduzir comentários à ação de commit, isto é, impossibilitar commits sem qualquer comentário. Integração Contínua A ideia subjacente à integração contínua é, como o próprio nome indica, adotar mecanismos que integram continuadamente o código que vai sendo produzido. Deste modo, qualquer código novo é compilado com o código já existente oferecendo com isso um controlo de qualidade contínuo e contribuindo para um aumento de qualidade do Software e uma redução do tempo de disponibilização do mesmo nos ambientes. Desta forma, consegue-se antecipar possíveis conflitos entre os diversos Ciclo de Vida em QA Uma perspetiva complementar Página 2
módulos de Software. Subjacente a esta abordagem, um developer antes de fazer qualquer commit deve efetuar update para a sua máquina local do código existente no repositório. A grande vantagem é evitar integrações massivas e, sempre trabalhosas, do código produzido pelos vários developers evitando necessidade de rework. Complementarmente as aplicações de integração contínua (e.g. Hudson, Jenkins, etc) suportam (recorrendo a um só comando) o processo de criação e subida do Software para os ambientes existentes, bem como estão capacitados para despoletarem baterias de testes automáticos sempre que o servidor deteta um novo commit. Processo Automático Exemplo de uma arquitetura possível 1- A cada commit realizado o servidor de Controlo de Versões regista a alteração efetuada; 2- A cada commit realizado o servidor de integração contínua é notificado; 3- A cada commit realizado o servidor de integração contínua despoleta a bateria de Sanity Tests; 4- Caso o ponto 3 tenha sucesso, é dado início à disponibilização da nova versão de Software para os ambientes de teste; 5- A cada commit realizado o servidor de integração contínua despoleta a bateria de testes de regressão; 6- Criação automática de incidências quando a execução de um caso de teste falha; 7- Geração automática do relatório de execução da bateria com envio automático dos resultados para os membros da equipa do projeto por e-mail e instant messaging. Figura 2 - Processo Automático 1 Ciclo de Vida em QA Uma perspetiva complementar Página 3
Natureza da Aplicação a Desenvolver A equipa de desenvolvimento pode contribuir de forma preponderante como facilitadora aquando idealização da natureza da aplicação a desenvolver. Seguidamente, são apresentadas boas práticas que contribuem para a qualidade de Software. Registo de mensagens de integração É boa prática munir uma aplicação com ecrãs que permitem consultar a troca de mensagens entre a própria aplicação e as aplicações com que integram. Mensagens que costumam estar apenas presentes em tabelas de base de dados passam a estar facilmente acessíveis na própria aplicação, permitindo a qualquer momento efetuar uma análise de situações de erro mais detalhada. Indicadores de performance A importância de monitorizar os indicadores da memória que está a ser alocada, da percentagem de cpu, número de sessões ativas, tempos de resposta por cada chamada htlm, etc, ganha uma maior dimensão se estes indicadores estiverem acessíveis por um ecrã e associados a alarmísticas que avisam quando os indicadores estiverem a revelar uma degradação na aplicação. Processo de deployment ágil Cada vez mais é uma vantagem criar mecanismos que permitem com facilidade disponibilizar novas funcionalidades da aplicação, evitando recorrer à necessidade de criação de pacotes de Software e respetivo deployment para os ambientes. Processo este que acaba por ser algo moroso. Exemplos desses mecanismos são: o recurso a configurações xml que permitem, por exemplo, mudar todo um funcionamento de um ecrã recorrendo apenas a uma só intervenção; código protegido por funcionalidades que podem a qualquer momento, e através da própria aplicação, ser ativadas ou desativadas sem recurso a qualquer criação de pacotes de Software. Desta forma, evita-se a necessidade de ter várias linhas de desenvolvimento e passa-se a ter uma só linha; na realidade as novas funcionalidades estão sempre presentes, mesmo quando ainda inacabadas, mas devidamente desabilitadas. Gestão de Acessos É essencial e comum prever distintos perfis de acesso à aplicação. Temos, por exemplo, o perfil do utilizador final e o perfil administrador que habilita ao utilizador acesso total aos módulos da aplicação. Existem também perfis com base na própria organização da empresa cliente: uma direção x tem acesso a determinados módulos, os mesmos não são disponibilizados aos utilizadores da direção y. Isolamento O isolamento de uma aplicação é uma característica da testabilidade e traduz-se no grau em que o componente alvo de teste pode ser testado isoladamente. Garanti-lo permite criar funcionalidades configuradas às respostas das aplicações externas, isto é, com base no preenchimento de atributos de ecrã obtenho uma resposta x simulada, com base num preenchimento alternativo, obtenho uma resposta y simulada, e assim sucessivamente. Este isolamento deve também ser facilmente habilitado ou desabilitado a qualquer instante. Amiga da Automatização A idealização de uma aplicação deve desde logo prever que a mesma irá ter uma vertente de automatização de testes, pelo que o seu cariz deve prever a criação de facilitadores para a automatização. Exemplos destes são: a geração de TestIDs que se traduzem por identificadores unívocos de todos os elementos da aplicação; e a geração de ações de negócio com vista à automatização keyword driven. As vantagens inerentes a esta saudável amizade, passam por possibilitar Ciclo de Vida em QA Uma perspetiva complementar Página 4
usar uma ferramenta de automatização de testes integrada com a plataforma de desenvolvimento; desenho da automatização dos casos de negócio recorrendo a ações de negócio da aplicação e permitindo que a automatização esteja ao alcance de qualquer membro das equipas de projeto, tenham eles perfis de tester, funcional ou desenvolvimento. Indicação do número da revisão do código Um pormenor como disponibilizar a indicação do número da revisão do código na própria aplicação, faz muita diferença pois permite a uma equipa de QA saber a qualquer momento que revisão do código se encontra a testar. Deste modo, o ónus da decisão de subida de novo Software passa para a equipa de QA. Num processo de gestão de resolução de defeitos permite abolir a etapa de passar um incidente de resolvido para pronto a ser testado. A equipa de desenvolvimento deixa de ter a preocupação acrescida de subir correções. Amiga da abertura de incidentes Outro pormenor de grande eficiência é habilitar a aplicação, em ambiente de teste, com ecrãs munidos de links para abertura de incidentes com a automatização da ação de anexar a imagem do ecrã onde se detetou o incidente. Diversidade de ambientes Numa fase inicial ao projeto deve ser reconhecida e garantida a existência de vários ambientes, cada um com o seu propósito. Assim, recomendo como proposta minimalista a existência dos seguintes ambientes: 1- Ambiente local Tipicamente o ambiente de cada developer; 2- Ambiente de Desenvolvimento Usado pela equipa de desenvolvimento e tem como objetivo a realização dos primeiros testes de integração; 3- Ambiente de Testes Utilizado em exclusivo pela equipa de testes e com integração com outras aplicações externas; 4- Ambiente de Qualidade Evolutiva Usado pelo cliente com vista à aceitação do Software; 5- Ambiente de Qualidade Manutenção Usado para correções/validações de incidentes detetados em ambiente produtivo; 6- Ambiente Produtivo Utilizado pelo cliente final nas tarefas do dia-a-dia. Eventualmente pode haver necessidade de ter ainda um ambiente pré-produtivo e outro de formação. É boa prática garantir refrescamentos de dados periodicamente garantindo homogeneidade entre os diversos ambientes, diminuindo a degradação dos dados e salvaguardando o esforço da necessidade de reparação de dados aquando problemas de Software. A Autonomia de uma Equipa de QA Os pontos focados anteriormente permitem um incremento substancial na autonomia de uma equipa de QA. Esta equipa pode então gerir a subida de Software para os ambientes de testes e qualidade; Ativar ou desativar as diversas funcionalidades da aplicação, estando inerente a ativação em ambiente de qualidade apenas e só após ter certificado a mesma no ambiente de testes; Estar munida de ecrãs que lhe permitem um maior conhecimento na origem dos problemas que vai detetando, permitindolhes coletar informação com valor acrescentado aquando registo de incidências; etc. Sucintamente, uma equipa de QA autónoma é uma equipa com maior conhecimento e mais próxima da equipa técnica. A proximidade é conseguida quando a equipa técnica reconhece o valor acrescentado na Ciclo de Vida em QA Uma perspetiva complementar Página 5
informação do incidente e reconhece que o tempo necessário da análise ao problema diminui, estando a mesma focada única e exclusivamente na resolução do incidente. Onde Termina QA? Esta pergunta é de difícil resposta mas creio que as atividades de QA nunca terminam na realidade até o ciclo de vida da aplicação terminar. Vivemos atualmente numa era de constante mudança. As aplicações acompanham a mudança, seja ela económica ou social. A minha opinião muito pessoal é que o mindset de uma equipa de QA deve mudar e, enquanto recurso de uma equipa de QA que sou, só fico de consciência tranquila quando, depois de ter certificado uma funcionalidade de Software, garanto também que automatizo a funcionalidade que certifiquei, deste modo sei que o meu trabalho irá perpetuar a cada execução de bateria de testes automáticos, garantindo que a funcionalidade que certifiquei mantém-se estável e garantindo que problemas oriundos de regressão sejam rapidamente detetados. É também boa prática mudar a forma de encarar incidentes detetados em Produção, isto é, o objetivo será sempre de tentar garantir ao máximo um Software isento de incidentes, mas porque os há, cabe a uma equipa garantir também que a resolução dos mesmos seja também ela automatizada e diariamente verificada nas baterias de testes de regressão. Deste modo a qualidade deve ser assumida de forma proactiva e reativa ao longo do ciclo de vida de desenvolvimento da aplicação, nunca esquecendo a máxima que qualquer não-conformidade detetada numa fase inicial do projeto limita o impacto e o custo de resolução da mesma. Ciclo de Vida em QA Uma perspetiva complementar Página 6
Acerca do Autor André Martins tem 8 anos de experiência profissional na área de Software Testing e Quality Assurance tendo iniciado a sua carreira profissional como SW Tester em Setembro de 2004 no grupo IC R&D Mobile E2E Solutions da Siemens, tendo acumulado funções de Test Coordinator em 2005. Em 2006, integrou na empresa nacional de SW Testing WinTrust como consultor de Quality Assurance. Durante esta fase, desempenhou funções de desenho e execução de casos de teste funcionais em clientes como ITIJ, Vodafone, CelFocus, BPI, TIMw.e., Millennium BCP, Vodafone, através de parcerias com a Novabase e Critical SW. Ainda como consultor de QA da WinTrust esteve envolvido na conceção de uma arquitetura de testes automatizados no cliente OutSystems. Em 2008, passou pela Caixa Leasing e Factoring tendo como responsabilidade assegurar a passagem de conhecimento da metodologia de testes adotada pela WinTrust a colaboradores da Caixa Leasing e Factoring da DSI. Através de uma parceria com a Lógica foi responsável pela Automatização, Implementação e Execução dos cenários de teste de carga no âmbito da migração do sistema de base de dados de DB2 para Oracle das aplicações SAP SEAG e SGCC-SEP da EDP. No final de 2008 e até final de 2009, esteve no projeto Nova Plataforma de Balcões da CGD onde exerceu as funções de Arquiteto Chefe, Arquiteto Líder, Analista de Testes e Analista de Dados e onde teve papel preponderante na Automatização de Testes Funcionais. Em Dezembro de 2009 ingressou na INDRA onde é atualmente o responsável pela Equipa de Quality Assurance da aplicação SIT-e da PT Comunicações. Possui certificação ISTQB Foundation Level desde 2008 e é Licenciado em Engenharia de Telecomunicações e Informática pelo ISCTE. Ciclo de Vida em QA Uma perspetiva complementar Página 7