A importância de uma estrutura de suporte

Eu costumo sempre dizer que o radicalismo é sempre burro. Para se trabalhar com qualquer coisa, é sempre bom ter bom senso, principalmente na nossa área onde a oferta de aplicações para dar suporte ao desenvolvimento é sempre grande.
O motivo pelo qual eu sempre bato de frente com os scrumaníacos é justamente pelo fato desse tipo de metodologia ser tão bom, que acabam achando que é a solução para todos os problemas, mas não é esse o foco da discussão.
Hoje estou fazendo um trabalho de consultoria e fábrica de software num órgão público e devo elogiar a equipe deste órgão e da fábrica pois todos estão dispostos a fazer um bom trabalho, independente dos objetivos e interesses.
O foco da questão é a estrutura de suporte dada aos Testes, achei bastante interessante a forma como chegamos ao resultado dessa consultoria. Basicamente eles possuem uma estrutura bastante organizada, baseada no Enterprise Architect. As fases de projeto são divididas em Concepção, Elaboração, Construção, Homologação e Implantação. Sendo que cada fase possui suas respectivas etapas, podendo citar: modelagem de casos de uso, plano de testes, diagramas de sequencia, diagramas de colaboração, protótipos de tela e afins.
Dificilmente chego numa empresa e digo o que eles devem fazer. Eu apresento as sugestões e juntos, chegamos ao resultado mais apropriado. Toda proposta é acompanhada de um: "está OK para vocês trabalharem dessa forma?" O mais interessante é que às vezes o cliente se empolga com a solução/proposta e eu tenho a preocupação de entrar no detalhe, mostrar como vai ser trabalhar de tal forma no dia-dia. Faço isso pois às vezes eles confundem o "simples" com o "fácil", e são abordagens COMPLETAMENTE diferentes. Por exemplo: em testes de regressão, para um sistema em funcionamento e homologado pelo cliente, criar um caso de teste baseado no sistema em funcionamento parece simples, mas ao se deparar com a quantidade de regras de negócio, requisitos funcionais e de interface, o cliente toma um "susto" com tal complexidade e solicita uma nova sugestão.
No caso desse órgão, utilizamos o Enterprise Architect para centralizar as informações referentes aos requisitos (ele é realmente muito completo nesse sentido), um repositório conjunto para formalização das atas de reunião (pois as entregas da fábrica devem estar alinhadas com o edital), uma planilha volátil com o checklist padrão e específico de cada caso de uso, o Testlink para formalização do repositório dos checklists e cenários, versionamento e execução dos testes e um servidor de integração contínua com Hudson e Maven.
Final do ano iremos confirmar o sucesso desse processo e farei um novo post relatando as alterações e ajustes no decorrer do processo.

Webinar - Pesquisa de Satisfação

Pessoal, gostaria da sua opinião para uma Pesquisa de Satisfação para os próximos Webinars, sua resposta é muito importante para melhoria dos próximos Webinars.

Segue o endereço: https://docs.google.com/spreadsheet/viewform?formkey=dGYzbGdheUJabTVhNXIwaXNlemJXQmc6MQ

 Fiquem à vontade para encaminhar aos seus colegas.

[NOVA DATA] Webinar GRATUITO de Testes de Software - Foundation (19/04/2012)

Pessoal, devido aos limites da ferramenta (Webex) só tivemos a oportunidade de obter 25 participantes no Webinar de ontem. Por este motivo, amanhã (19/04), no mesmo horário (às 18:00h) farei um novo Webinar sobre o mesmo assunto.

Provavelmente alguns dos colegas que participaram do primeiro Webinar, receberam também o convite do segundo Webinar pois não pude resgatar o email de todos os participantes que estiveram presentes.

Desta forma, o convite aos demais colegas que não participaram da primeira edição, fica aberto, gratuitamente, para amanhã no mesmo esquema.

Será um prazer conversar novamente com vocês!

Lembrando que os ainda interessados e que não receberam o convite por email, podem se cadastrar através do formulário disponível nesse link:
https://docs.google.com/spreadsheet/viewform?formkey=dEFRY0xBamxTdUh3VUc4a3UwdFZlTWc6MQ

Gostaria também de agradecer os participantes do primeiro Webinar que fizeram toda a diferença apoiando este projeto! Espero que tenham gostado!

Webinar de Testes de Software - Foundation (17/04/2012)

Olá pessoal,


tenho uma ótima notícia: Pela alta procura por esta palestra, irei disponibilizar outros horários para que os participantes possam também assistir a este Webinar pois temos um limite de apenas 25 participantes por sessão no Webex.

A agenda deste primeiro Webinar será:
- Apresentação
- Conceitos e Desafios
- Importância dos Testes de Software
- Entidades Certificadoras
- Sete princípios dos Testes de Software
- Conceitos gerais sobre Gestão de Projetos de Testes

Lembrando que este Webinar será totalmente gratuito e fará parte de um curso online onde o usuário poderá seguir diversas carreiras, tais como:
- Testador
- Analista de Testes
- Automation Tester
- Coordenador de Testes
- Performance Tester (em desenvolvimento)
- Penetration Tester (em desenvolvimento)
- Processo de Testes

Lançaremos outros Webinars, gratuitamente, com o objetivo de alinhar os termos (que são muito diferentes mercado afora). Faremos outros e estes serão de cunho crítico.

Abaixo, segue informações sobre o Webinar.

Tópico: Testes de Software - Foundation
Data: Terça-feira, 17 de Abril de 2012
Hora: Horário de Brasília - 18:00-20:30
Número da reunião: 634 337 539
Senha da reunião: testavo1704

Os ainda interessados que não receberam o convite por email, podem se cadastrar através do formulário disponível nesse link:
https://docs.google.com/spreadsheet/viewform?formkey=dEFRY0xBamxTdUh3VUc4a3UwdFZlTWc6MQ


Obrigado!

Webinar de Testes de Software

Pessoal, conforme já avisado pessoalmente e em algumas listas de discussão, irei dar um Webinar sobre Testes de Software. É um ciclo de palestras online que estou preparando para disseminar o conhecimento de Testes de Software.

Nossos encontros serão às terças-feiras geralmente das 18h às 20h (nem todas). Limitei a apenas duas horas para torná-los produtivo. O conteúdo se encerra às 20h e estarei aberto mais 30 minutos para discussões.

Serão uma série de Webinars interativos categorizados em: Iniciante, Intermediário e Avançado. As palestras serão bastante práticas, ricas em exemplos e sempre levando em consideração a aplicabilidade das técnicas.

É o que eu sempre digo, saber os conceitos de Testes de Software é fácil. Saber como aplicá-los no dia-dia que é difícil. Falo isso pois vejo uma série de certificados em CTFL e CBTS (entre outros) que não sabem como utilizar esse conhecimento no dia-dia, mas também conheço muitas pessoas que trabalham com Testes há anos (e sabem muito) mas não conseguem falar uma língua comum com o mercado por ter sua bagagem muito voltada à sua experiência.

Então, iremos alinhar e confrontar essas duas experiências com o objetivo de tornar esse ciclo de palestras online mais proveitoso.

Espero que gostem!

Erro, defeito, falha...

O conceito de erro, defeito e falha, qualquer um que estuda/decora um pouco sabe o que é (ver http://www.bstqb.org.br/?q=glossario). Mas não é sobre isso que escrevo, saber os conceitos é muito fácil, saber o motivo pelo qual dividem eles, poucos sabem. Na verdade não existe nenhum livro dizendo por qual motivo classificaram dessa forma, é preciso analisar com mais cuidado o dia-dia de uma empresa/equipe de Desenvolvimento de Software (e porque replicaram estes conceitos da Engenharia), para visualizar essa essência.

Quando essa questão vem à tona, o que vejo normalmente é: “ah, isso é fácil. Esse conceito veio lá da Engenharia Elétrica quando descobriram que uma falha ocorre quando acontece algo diferente do planejado”, e por aí vai. Normalmente, acabam por repetir o conceito, em outras palavras, contextualizando o fato e dando exemplos relacionados a estes. Nada contra.

A palavra da vez é: Gestão de Defeitos. Por que existe essa categorização? O motivo de fato, talvez não seja esse, mas faz todo o sentido. Pensem numa empresa cujos processos de Testes são imaturos, o que naturalmente acontece? Os testadores (muitas vezes os desenvolvedores ou até clientes) encontram uma FALHA no sistema. Passam a descrição de como encontraram aquela falha e então o analista responsável encontra o DEFEITO na aplicação, debuga e corrige. Isso é errado? Bom, errado não é pois isso acontece o tempo todo, mas com certeza não é a forma mais inteligente de gerenciar os Testes do seu projeto. Mas por quê?

Empresa inteligente PREVINE que os erros aconteçam e existem diversas formas para que isto aconteça. Nós estudamos incansavelmente para certificações e muitas vezes não sabemos como utilizá-los no seu dia-dia.

Empresa inteligente APRENDE com seus erros do passado. Por isso é importante analisar e estudar as métricas dos projetos anteriores, para não cometer novamente no futuro.

Empresa inteligente MONITORA suas atividades, dessa forma pode saber quando estão em desacordo com o planejado.

Empresa inteligente acompanha NOVAS TENDÊNCIAS e estuda a viabilidade de aplicá-las no seu dia-dia.

E como eu incansavelmente falo, empresa inteligente SABE o que faz e INVESTE, principalmente, em bons Analistas, Desenvolvedores e Testadores, pois são estes, que lá no final, fazem a diferença...

Teste de Performance, qual a REAL utilidade?

Muita gente que trabalha com Testes de Software, bem como na área de TI num geral, trata o Teste de Performance como uma "caixa preta". Parece que atividades como criar scripts com ferramentas para simulação de múltiplos usuários (apesar de simulação não ser o termo mais adequado quando falamos de Testes de Desempenho), monitorar o servidor de aplicação, banco de dados, CPU e memória, encontrar gargalos, ajustar queries no banco (de maneira geral, efetuar o famoso "application tuning"), parecem atividade de outro mundo. Mesmo porque esse tipo de atividade não faz muito parte do dia-dia de uma empresa de tecnologia, geralmente é terceirizada, pontualmente, com uma equipe especializada.

O motivo pelo qual decidi escrever esse post é justamente para comentar QUANDO Testes de Performance fazem parte de uma organização naturalmente corporativa. Antes de quaisquer comentários, gostaria de declarar que conheço instituições que possuem uma própria equipe/estrutura especializada em Testes de Performance para as aplicações internas, o que é muito interessante. Todavia, isso é exceção, OK?
Pela minha vivência com Testes de Performance, posso dizer que existem três situações as quais uma empresa geralmente procura por esse tipo de serviço:

- Quando existe uma real preocupação com o desempenho da aplicação, ou seja, geralmente se a aplicação é crítica e depende de um tempo de resposta adequado. Posso citar o exemplo da Nike, num projeto que participei da primeira etapa enquanto trabalhava na HP-EDS. Eles pretendiam lançar um site durante as Olimpíadas de Pequim, sendo assim, quem acessasse o site durante a abertura participaria de uma promoção deles. Seriam centenas de milhares de acessos do mundo inteiro num momento específico do dia e ano. Comercialmente era muito importante que esse site permanecesse 100% estável. Dessa forma, solicitaram que a aplicação suportasse 300.000 acessos simultâneos e durante a primeira etapa conseguimos atingir apenas, algo em torno de, 8000 usuários virtuais. Infelizmente, não pude acompanhar as etapas posteriores desse projeto...

- Ou, quando já aconteceu o problema, e, se acontecer novamente, pode dar resultados extremamente negativos para os responsáveis pela aplicação. Por exemplo, tivemos um cliente na LUGATI que precisava que a nova configuração de servidor dele atendesse, concorrentemente, 3500 usuários simultâneos em horário de pico. Caso contrário, perderia o contrato com uma grande instituição, o que resultaria numa diminuição drástica no faturamento da empresa. Após os Testes, utilizamos quatro controllers com o JMeter no seu limite (inclusive tivemos que expandir o uso da JVM para as versões 64 bits) e o site atingiu 4000 acessos simultâneos com uma taxa de erro baixíssima. Um sucesso.

- A última situação, acreditem, é também bastante comum. Normalmente, quando é necessário apresentar ao usuário potencial do sistema que este é confiável, através de um relatório de Testes de Performance. É algo como se respondesse, antecipadamente, que o sistema não é lento "como os seus concorrentes do mercado", mesmo que ele seja. Já presenciei a seguinte situação, por exemplo: "coloca qualquer informação aí no Relatório porque eu só preciso mostrar ao cliente que o sistema permanece estável após as alterações. Esses dados não precisam ser reais de fato..." Pasmem!