Bom, mas indo ao que interessa, seguem as 5 regras básicas de comportamento que podemos extrair do Caratê:

1. O CARATECA deve treinar caratê com serieadade, pois apenas “mexer” os braços e pernas pode ser a mesma coisa que executar passos de dança.

   O bom testador precisa ter uma formação robusta em metodologias e ferramentas de testes de software. O método “tentativa e erro”, ou apenas mexer os braços e as pernas, não basta para testar corretamente um software.

2. O CARATECA deve entregar-se de corpo e alma ao treinamento sem se preocupar com as teorias. O que se aprende “com o corpo’ jamais se esquece.

   Não basta apenas treinar, toda técnica exige também prática. Exercer a experiência prática daquilo que se aprendeu faz com que o profissional fique hábil naquilo que faz e crie bons constumes na hora de aplicar as técnicas.

3. O CARATECA deve evitar a arrogância, pois não se vence um adversário com palavras

   É comum encontrarmos testadores que sentem um certo prazer em mostrar que um programador falhou. Este não deve ser um comportamento correto. No livro comenta o programador como Adversário, mas eu discordo… o adversário é sempre o software. De qualquer forma, todos comentem erros, inclusive um testador que deixa “passar” uma falha ou ao apontar um defeito inexistente (algo que parece um defeito mais não é).

4. O CARATECA deve ṕrocurar ver-se como ele realmente é e imitar apenas o que de mérito houver nos outros. Lembrando que cada um de nós tem boas e más qualidades.

   O mérito do desenvolvedor é criar o software e do testador é garantir que ele tenha qualidade. Cada um deve ser bom na execução de seu trabalho e devemos obter o máximo de conhecimento uns com os outros. Mesmo um colega menos experiente pode nos trazer aprendizado.

5. O CARETCA deve manter a ética em todos os momentos de sua vida privada ou pública. O caratê deve ser aprendido não apenas com os olhos da face, mas também com os olhos da alma.

   O princípio da ética deve ser seguido sempre. Um profissional sem ética é dificilmente aceito pelo grupo e tende a ser sempre marginalizado. Em outras palavras: é sempre melhor admitir um erro do que escondê-lo.

O que a ferramenta promete?

Twist é uma plataforma baseada em práticas ágeis de colaboração com o negócio, refatoração, reusabilidade e simplicidade. O objetivo é responder rapidamente com testes às mudanças dos requisitos de negócio. Ele alinha as prioridades do negócio com Suites de teste robustas que possibilitam maximizar a automação.

Com o Twist você pode:

• Alinhar os testes com o negócio da aplicação:

  Ótimos softwares requerem ótima colaboração. Ferramentas e processos rígidos e não colaborativos criam abismos entre QAs, Desenvolvedores, BAs, gerentes e clientes que diretamente impactam na qualidade da aplicação. Com o twits, os analistas de negócio escrevem requisitos que são usados diretamente como especificações de teste. A IDE permite alta visibilidade e colaboração através do processo de testes, e permite que seu time inteiro use isto para todas as suas necessidades de teste funcional. Isto garante que seu desenvolvimento e esforço de teste mantém-se real para o objetivo atual do negócio. Seus clientes não somente sabem exatamente o que eles querem, mas o alto valor de seu negócio.

• MudançasAccommodate changes:

  A responsabilidade nas mudanças dos requisitos é uma necessidade crítica para o sucesso de Projetos Ágeis. Suites de Teste em Twist mudam juntamento com os requisitos e não têm de ser descartados quando a funcionalidade muda. Com a abstração dos objetivos de teste desde a implementação e o suporte embutido para o Refactoring e Reusabilidade, as suites podem ser facilmente modificadas – economizando dinheiro e tempo.

• Automação de testes feitas da forma certa:

  Twist é uma solução acessível que pode ser usada pelo time inteiro. Twist é fácilmente adaptado bem como usa padrões de linguagens da indústria. Ele também elimina a necessidade de aprender linguagens de script proprietárias que geralmente exigem uma grande curva de aprendizado. Twist aumenta a produtividade dos testadores pela otimização da forma com que o time constrói os scripts de teste automatizado e também suporta testes exploratórios.

Fonte: http://www.thoughtworks-studios.com/agile-test-automation

Minha idéia agora é então apresentar algumas funcionalidades mais avançadas do JMeter e como realizar algumas coisas das quais ‘apanhei’ e também algumas dúvidas.

Bom… vamos às dúvidas em primeiro lugar…

Depois de gravar o script utilizando o componente de Proxy, precisamos ‘limpar’ o script de todo o ‘lixo’ que o JMeter gera ao gravar os requests/responses do usuário.
Pesquisei para saber o que eu devia ‘deletar’… não achei muita documentação. Então fui um pouco pela ‘lógica’ daquilo que eu precisava fazer.

Pesquisei sobre o JMeter carregar os javascript da página e eu vi que não tem necessidade desde que não exista nenhum .js que faça uma chamada a uma página.
Então os .js podem ser excluídos do script se a navegação estiver funcionando, mesmo porque ele executa no lado cliente e não no servidor.

O JMeter também grava o download das imagens… ficamos em meio à discussão se elas deviam ser deletadas ou não.
Acredito que é importante acessar a funcionalidade do sistema que tenha mais carregamento de imagens e vale a pena dar uma olhada em como o sistema se comporta.
Mas, dependendo do foco do Teste de Performance, se ele tiver como objetivo procurar falhas de performance no código em si… não vejo porquê mantermos nos scripts todos os downloads das imagens.

Também é altamente recomendável que sejam deletados requests desnecessários, por isso ao gravar o script usando o Proxy, é essencial prestar atenção nos requests importantes para que a aplicação funcione. Eu particularmente fui acompanhando com o JMeter a cada requisição e colocando nos comentários que tipo de chamada era aquela, assim pude excluir chamadas redundantes, quando há.

Eu estava lá com o Luiz Gustavo, no CInTeQ 2011, quando o Bernard Homès fez este comentário um tanto quando ‘bombástico’… olhei perplexa e segui o reciocíonio dele. Concordo que, em partes muito se fala sobre metodologia ágil como ausência de documentação forma. Mas com certeza não ausência de informação para testes.

Trabalhei em uma empresa que utilizava como metodologia a AUP: Agile Unified Process, que é uma versão simplificada do RUP para uma forma de desenvolvimento mais ágil.

E o processo era constituído de um backlog que incluíam as tarefas de teste inclusive. Cada funcionalidade da Sprint a ser entregue era coberto por testes manuais detalhadamente especificados e com cobertura de 98% dos fluxos especificados. Todos os métodos entregues naquela Sprint também eram cobertos por testes automatizados. A cobertura era avaliada por uma ferramenta de análise estática do código que nos mostrava os fluxos dos métodos que não haviam sido cobertos com testes.

Além disso também existiam os testes automatizados de integração e de sistema que faziam parte de outro Backlog, senão o da entrega dos componentes.

Então na minha opinião o que importa na realidade não é se a metodologia é Ágil ou não. O que importa é se são planejadas na Sprint e aplicadas técnicas de teste compatíveis com o nível de criticidade do sistema.

O Luiz Gustavo comentou sobre Pairwise Testing, porque esta técnica não poderia ser planejada no Backlog e aplicada da Sprint?

Talvez neste caso, não se tornaria necessário outro Backlog?

- Um backlog de testes e controle da qualidade das entregas
- Outro backlog para aplicação das técnicas necessárias para garantir a qualidade da entrega do ‘produto’.

Será que isto tornaria o processo menos ágil?

Essa é uma questão que eu gostaria que fosse respondida pelo pessoal que defende as metodologias ágeis… Ter uma visão de como eles organizariam as atividades de teste nessa situação.

Mas quando este produto não está mais atendendo o cliente de forma satisfatória, seja em termos de bugs encontrados no sistema em produção ou até mesmo a solução não estar direcionar ao negócio do cliente, apela-se a um profissional da área de Testes e/ou qualidade.

Mas tudo isto fica meio que… confuso!
E então o profissional segue com as famosas perguntas: tudo bem… mas o foco que a empresa quer dar é na qualidade do processo ou na qualidade do produto?

E, diga-se de passagem, são áreas extremamentes distintas!
Mesmo porque uma melhoria no processo subentende-se como uma melhoria na qualidade do produto, mas nem sempre é assim que funciona.

No CInTeQ 2011, o palestrante Erik Van Veenendal apresentou Testes Baseadas em Risco (Risk-based Testing). E sugeriu que uma abordagem baseada nos possíveis problemas que podem acontecer durante a entrega de um lote de funcionalidades e os possíveis impactos para o cliente e para a organização, pode ser um ótimo começo e uma forma de iniciar um processo que vai começar na análise de risco e terminar na derivação de cenários de testes para a cobertura e mitigação completas destes risco.

A questão é como fazer isto funcionar na prática e ter resultados em termos de melhoria de qualidade no produto! Que é o que mais dá retorno financeiro e agrega valor à empresa.

Vamos pensando…

A grosso modo, muitas empresas criam datawarehouses para servir de base para o BI (Business Intelligence) da empresa. Segue uma apresentação que fala sobre BI:

Por ter um baixo custo, muitas empresas estão migrando ou adquirindo essa ferramenta, tendo em vista da facilidade de lidar com ela.

Tem suporte para a automação de sistema desenvolvidos em várias tecnologias, tais como: .NET, Java, Visual Basic, Borland Delphi, WEB, PowerBuilder, FoxPro, entre outros. Além disso, o TestComplete oferece recursos para a realização de testes de desempenho para aplicações WEB e testes funcionais de WEB Services.

Em cada post vou adicionar o que fui descobrindo nos primeiros passos com esta ferramenta.

Para baixar, usei a versão trial. Mas tem um segredinho… para instalar tem que seguir os passos que estão no site da AutomatedQa: http://www.automatedqa.com/products/testcomplete/how-to-activate-trial-licenses/

http://www.slideshare.net/pauloperes2009/testes-de-software-uma-viso-geral