Cobertura CInTeQ 2010 – Dia 1 (parte 1)

Nesta segunda-feira teve início o CInTeQ (Congresso Internacional em Testes e Qualidade de Software), um dos principais eventos de Teste e Qualidade de Software, patrocinado nesta edição por Microsoft, RSI, Iterasys, IBM, Governo do Brasil e Caixa Econômica Federal e com o apoio do BSTQB.

A seguir, relato como foram  as primeiras palestras do primeiro dia do evento.

Abertura do evento – Osmar Higashi – Atuação do BSTQB e Panorama Atual dos Testes no Brasil

O paguá que vos escreve chegou atrasado… chegando só no fim da palestra de abertura do evento, que foi ministrada pelo diretor executivo da RSI Informática e BSTQB (Brazilian Software Testing Qualifications Board), Osmar Higashi.

O palestrante falou sobre a atuação do BSTQB no Brasil, as certificações avançadas, números de certificados e uma notícia bem importante: a aplicação da prova avançada para a área de gerência de testes (CTAL-TM: Advanced Level Test Manager) aqui no Brasil, que ocorrerá ainda nesse ano (atualização[24/03]: o César Chaves disse nos comentários que já houve a primeira prova CTAL-TM: Advanced Level Test Manager no Brasil, ela ocorreu em fevereiro/2010).

Além disso, o palestrante disse que os Syllabus das outras certificações avançadas já estão sendo traduzidos (alguns já estão até completamente traduzidos) e que o BSTQB está trabalhando para aplicar os outros exames avançados no Brasil.

Resumindo, parece que o BSTQB está querendo atuar mais fortemente no Brasil, prova disso é a própria realização do CInTeQ, o que é muito bom para o nosso mercado e para os profissionais.

Eduardo Habib – Teste de Segurança em Aplicações Web

O Eduardo é Gerente de Testes no SYNERGIA e mestre em Ciência da Computação pela UFMG. Sua apresentação foi sobre uma tema ainda não muito comentado na comunidade de Teste de Software Brasileira, testes de segurança.

A palestra do Eduardo teve como foco apresentar as falhas de segurança mais comuns em aplicações Web, alguns exemplos de como testá-las e ferramentas open source que auxiliam nesse tipo de teste.

O palestrante começou falando que antigamente a segurança não era uma preocupação no desenvolvimento de aplicações Web, pois o conteúdo era todo estático e não haviam informações confidenciais nos sites.

Porém, hoje em dia os sites possuem informações confidenciais de seus usuários, desde login e senha até o saldo da conta corrente. Portanto, a segurança passou a ser uma característica fundamental em vários sites, e são precisos testes para averiguar se a aplicação é realmente segura.

Algumas informações importantes passadas pelo Eduardo durante a palestra:

• Muitas pessoas não se importam com a segurança de determinada aplicação, porém esquecem que essa aplicação pode ser a porta de entrada para as aplicações que ele se preocupa;
• O uso de SSL – Secure Sockets Layer não impossibilita ataques, e  os ataques que mais ocorrem não são evitados com SSL. Porém, isso não que dizer que você não deva utilizar SSL, pois caso você faça isso, você abrirá outras “brechas” para os crackers;
• Há um aumento considerável no número de incidentes relacionados a segurança (figura abaixo), e esses números não estão dando sinais que vão diminuir. Por isso cada vez mais se faz necessário realizar testes de segurança;
• Houve um aumento de incidentes de 61% de 2008 para 2009;
• De 1999 até 2009 o aumento de incidentes foi de 11530%;
• 75% dos sites de bancos possuem falha grave, segundo a Universidade de Michigan (pesquisa não contemplava bancos brasileiros);
• 64% de 1364 sites corporativos possuem falhas graves de segurança, segundo o WhiteHat Security.

Total de Incidentes Reportados ao CERT.br por Ano (Fonte CERT.br)

A origens principais desses incidentes são devido aos seguintes problemas:

• O usuário pode enviar QUALQUER dado;
• É necessário assumir que toda entrada pode ser maliciosa;
• Requisições podem ser feitas em qualquer sequência;
• Usuários não irão usar apenas um navegador para acessar a aplicação;
• Muitas aplicações não fazem verificação a cada requisição, ou seja, após o usuário estar logado, as requisições não são mais autenticadas.

O Eduardo ainda falou sobre as falhas que mais ocorrem, sendo elas:

• Falhas de injeção (ex. SQL injection);
• Cross Site Scripting (XSS);
• Falhas de autenticação e de gerenciamento de sessão;
• Referência insegura a objetos;
• Problemas de configuração;
• Falha ao restringir o acesso a alguma URL;
• Redirecionamento inválido;
• Problemas no armazenamento de informações confidenciais;
• Proteção na camada de transporte insuficiente;
  • Sem criptografia;
  • Certificados inválidos.

Mas então como podemos testar a segurança de uma aplicação Web?

Segundo o Eduardo a primeira coisa a ser feita quando for testar um software é pensar como que um cracker irá obter a informação, e para isso é preciso fazer um bom mapeamento, cuja melhor forma é a automática. Existem ferramentas open source que fazem esse mapeamento, e essas são chamadas de web spider.

Um ponto bem interessante da palestra foi a apresentação da ferramenta WebGoat, que já possui várias falhas de segurança e foi criada, justamente para ensinar as pessoas a como encontrar essas falhas e como funcionam as técnicas utilizadas pelos crackers, ou seja, é uma ferramenta obrigatória para quem quer começar a fazer testes de segurança.

O palestrante também mostrou uma lista de addons do Firefox e ferramentas que podem auxiliar durante os testes de segurança:

• Firefox
  • FoxyProxy
  • TamperData
  • Live HTTP Headers
  • AddNEditCookies
  • Cookie Watcher
  • XSS Me
  • SQL Inject Me
  • HackBar
• Scanner
  • Paros
• Outros
  • WebScarab
  • Burp Suite

Por fim, o Eduardo concluiu que:

• Todo sistema/aplicação é passível de invasão;
• Os usuários são potenciais invasores;
• É necessário otimização e cautela durante a programação,
• A análise de riscos pode ajudar no início da elaboração dos testes de segurança, fazendo você focar nas áreas chaves;
• Novas tecnologia irão criar novas “brechas”;
• Não há ferramentas open source tão boas, quanto as pagas.

Impressões da palestra

Eu achei a palestra do Eduardo bem interessante, talvez por não conhecer muito bem a área de Segurança de Informação e por nunca ainda ter feito testes de segurança.

O Eduardo atingiu com sucesso a proposta da palestra. Sem dúvidas quem participou da palestra saiu dela com uma visão muito melhor e já sabe por onde começar a fazes os testes de segurança, que cada vez são mais necessários e que cujas falhas costumam gerar um prejuízo muito grande para as organizações.

Rex Black – Dealing with the Testing Challenges of Agile Methodologies

A expectativa para essa palestra era muito alta, afinal o palestrante era nada mais nada menos, do que a lenda, o mito, o “monstro”, o “dinossauro”, o “megaboga”, o gigante … Rex Black, presidente da RBCS e autor de excelentes artigos e livros, que fazem juz aos adjetivos colocados, e o tema da sua apresentação “Lidando com os Desafios do Teste para as Metodologias Ágeis”, o mais interessante da agenda dos dois dias de evento, pelo menos para mim, que estou lidando com esses desafios ultimamente.

Bem, agora vamos ao que interessa, a palestra.

O Rex Black (RB) iniciou a sua apresentação dizendo que os desafios que serão comentados são inerentes a forma ágil de desenvolvimento de software, e basicamente esses desafios possuem duas origens:

• Do próprio agile;
• Interpretações das pessoas.

Após esse breve e importante esclarecimento, o RB perguntou para a platéia quem utiliza metodologias ágeis, e um bom número de profissionais levantaram a mão. E isso mostra como é verdadeira a afirmação feita na sequência, de que ciclos de vida ágeis estão se tornando comum.

Alguns pontos importantes levantados pelo Rex foi:

• Todas metodologias afetam o teste de software (isso parece até óbvio, mas muitas pessoas não percebem isso ou percebem da pior maneira);
• No contexto ágil é necessário saber quais estratégias de teste funcionam bem. O RB citou três que funcionam bem:
  • Teste baseado em riscos (na minha opinião, teste baseado em riscos sempre funciona bem! [quando bem aplicado é claro]);
  • Automação de teste, incluindo teste de regressão funcional;
  • Teste reativo, cujos principais representantes são os famosos testes exploratórios.

E mesmo utilizando essas estratégias, elas não irão aliviar todos os desafios de teste com projetos ágeis. Por isso é muito importante entender os desafios, identificar os caminhos e saber como lidar com eles.

Volume e velocidade da mudança

No mundo ágil mudanças ocorrem toda hora, e elas não são encaradas como problemas e sim como oportunidades, por isso deve-se dar as boas-vindas a elas.

Bonito isso!  Mas como nós, profissionais de teste, podemos lidar com essas mudanças, uma vez que geralmente, elas costumam gerar grande retrabalho para nós:

• Utilizando testes baseado em riscos, pois eles podem acomodar as mudanças;
• Testes automatizados também ajudam a acomodar as mudanças: testes unitários e até de GUI (mesmo o último sendo mais “quebrável”);
• O testadores devem ser manter atualizados para evitar ter falsos positivos.

Nos projetos agéis o tempo é muito curto

Em projetos agéis você não terá muito tempo para manter os testes, o tempo é muito limitado. Então ao automatizar você precisa saber que testes no banco de dados, são mais estáveis que testes na GUI. Além disso, o teste baseado em risco vai mais uma vez te ajudar, pois irá fazer você ser mais focado no que é mais importante. Lembre-se, no mundo ágil é preciso ter foco!

Testes unitários inadequados e inconsistentes

Uma das coisas em agile que o Rex Black mais gosta são os testes unitários, mas como o Fred Brooks disse “não existe a bala de prata” (isso em 1987, eu nem era nascido rs).

Mas antes de comentar sobre testes unitários o RB fez uma interessante analogia para explicar dois tipos de complexidades:

• Complexidade acidental: tentar colocar o sapato do pé direito no pé esquerdo;
• Complexidade essencial: você está no avião retira os seus sapatos para ficar mais à vontade, depois quando o voo já está chegando no seu destino, você vai colocar os sapatos, mas tem dificuldade, pois os pés estão inchados.

Ou seja, há uma complexidade causada por nós mesmos e outra causada por uma série de fatores do nosso contexto.

E assim sendo, os testes unitários precisam ser consistentes com a nossa aplicação, que por sua vez precisa ser adequada para que seja possível realizar testes unitários (ex.: problemas de testabilidade).

Mas testes unitários possuem dois problemas:

• Eles têm um limite de “alcance” de bugs, de 25% a 30%, enquanto bons testes de sistemas tem média de 85%;
• Nem todos os programadores fazem testes unitários.

O Rex Black frisou que os testes de unidade precisam acontecer, mas você precisa de ciência das suas limitações, pois não vamos fingir que agora tendo testes unitários não será preciso fazer mais outros testes.

Alguns outros pontos interessantes levantados pelo RB:

• “Em agile não é preciso escrever nenhuma documentação”, essa é uma interpretação errada do manifesto;
• Relatórios inválidos de bugs (com falso positivos) são um desperdiço de tempo, por isso é necessário os testadores estarem em constante interação com os desenvolvedores;
• Todas equipes precisam encontrar o equilíbrio entre documentação e reuniões;
• É preciso tomar cuidado para não espremer os testes, por exemplo: o projeto tem sprint de quatro semanas, e sempre há novos commits, os testes acabam sendo espremidos na última semana de todo sprint, ou seja, acabamos fazendo “cascatinhas”;
• Os clientes da RBCS adotam agile utilizando equipes independentes de teste;
• Não é necessário equipes totalmente independentes do time e nem totalmente dentro dos sprints, e sim um meio termo;
• Sprint para o teste e outro para desenvolvimento não funciona;
• Em agile tudo que você faz é um conjunto de coisas que você não faz (profunda essa frase rsrs);

O que aconteceu com a nossa base!?

Uma das respostas clássicas quando se pergunta qual é o objetivo do Teste de Software, é dizer que é garantir que a aplicação tenha sido implementada de acordo com os requisitos. E assim, os requisitos acabam sendo a principal fonte de informação e torna-se a base para os nossos testes.

Mas segundo o Rex Black, isso é um problema no contexto ágil, pois os requisitos podem mudar e então, os testes baseados em requisitos podem ser não efetivos, afinal estaremos atirando em alvos que estão sempre em movimento.

Ou seja, basear os seus testes em requisitos é muito difícil, quase impossível a longo prazo, caso você siga só essa estratégia.

O Rex Black ainda falou sobre as vantagens e desvantagens do testador atuar dentro da sprint:

• Vantagens:
  • Foca nas tarefas relacionadas com aquela sprint;
  • Aloca e realoca o tempo baseado nos objetivos da sprint.
• Desvantagens:
  • Perde a liberdade, ele passa a ser “liderado” pelo Scrum Master e não pelo Gerente Teste;
  • Tem uma visão reduzida do sistema.

Foi comentado durante a apresentação que há expectativas muito altas para o agile, principalmente por parte da gerência, e isso é um grande risco na implantação de agile, pois agile vai trazer benefícios no longo prazo e haverão muitos desafios.

Na conclusão da sua palestra o Rex Black fez as seguintes considerações:

• É preciso ser muito cuidadoso na escolha das estratégias de testes;
• É necessário manter os testes automatizados e realizar os teste de regressão baseados em riscos;
• Testes reativos permitem os testadores explorar áreas que os testes baseados em risco e os automatizados não cobriram;
• Tente ficar a frente dos desafios, espere por eles, seja pró-ativo ao lidar com os desafios, além disso seja realista perante a essa nova metodologia e o tempo que levará para ser tornar ágil, isso se você se tornar ágil;
• Sempre teremos trabalho a fazer, nada virá pronto.

Ainda houve perguntas bem legais para o Rex Black, que abordaram a resistência de analisar os riscos, teste de performance durante as sprints e tempo da implantação do agile, gerando as seguintes respostas:

• A Engenharia de Software é uma das principais atividades do ser humano. Se as pontes, prédios, escritórios quebrassem tanto quanto software seria inaceitável. Desta forma o primeiro passo para analisar os riscos é reconhecer a existência deles;
• Problemas de desempenho geralmente são de design, e tem custos caros, portanto não espere até o fim, dessa forma, faça uma boa análise estática e teste em nível de unidade. E durante a sprint o software tem que  continuar funcionando (integração contínua);
• Nem todo mundo precisa ser ágil e algumas pessoas levam mais tempo, isso até mesmo dentro de uma mesma organização. A implantação precisa ser democrática.

Impressões da palestra

A palestra do Rex Black foi excelente! Conseguiu falar com propriedade sobre uma temática recente, isso graças as experiências e vasto conhecimento em Teste de Software que ele possui. Um único ponto negativo, foi o excesso de texto nos slides (aliás, pelo que eu me lembre, quase todos os palestrantes colocaram muito texto nos slides).

No mais, foi muito interessante ouvir a experiência e opiniões do Rex Black sobre testes ágeis, realmente são uma série de desafios que enfrentamos quando iniciamos a implantação de práticas ágeis, e é muito difícil você encontrar literatura ou pessoas que falam sobre o assunto.

A conclusão que tirei da palestra foi que o Teste de Software pode sim ser ágil, e ele precisa ser ágil, logicamente que não é fácil, mas utilizando estratégias adequadas e pessoas preparadas podemos enfrentar de forma mais efetiva os desafios. E por fim, a realização de testes baseados em risco é fundamental, pois o tempo é bem curto, e não é possível fazer todos os testes, por isso precisamos estar sempre priorizando quais testes precisam ser feitos e os que não precisam, em suma: é preciso ter foco!

Bem pessoal, aqui encerro a primeira parte da cobertura do primeiro dia do CInTeQ 2010, até a segunda parte! 😀

Cobertura CInTeQ 2010 – Dia 1 (parte 2)

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