Esta semana experimentei usar o Google Docs como War Room para testes e foi super produtivo. Alem disso, foi um bom insight para tirar o po aqui do blog que ja nao via um post ha bue da tempo. Bue da tempo ? Ok, expressao portuguesa. Traducao: ha muito tempo. Nesse tempo que o blog ficou as tracas muita coisa aconteceu, inclusive minha mudanca para Lisboa! :) Mas bem, vamos voltar ao assunto central.Primeiro, que ideia e essa de Testing War Room?War roomAcredito que por volta do ano 2000 algumas empresas de TI comecaram a experimentar colocar o time de desenvolvimento em ambientes como salas de reunioes onde a comunicacao fosse aumentada e as acoes fossem tomadas mais rapida e acertivamente.Ainda era muito comum os desenvolvedores ficarem um tanto isolados uns dos outros (que dira da equipe de testes), com divisorias na mesa e pouca comunicacao, o que fez dessa pratica algo inovador na epoca. Um bom exemplo da aplicacao dessas war room eram as crises, problemas criticos em producao que precisavam de atencao imediata e esforco conjunto coordenado.Com o tempo, o conceito de war room comecou a ficar um pouco descabido ja que empresas/pessoas que praticam agilidade ja promovem naturalmente um ambiente com menos obstaculos para comunicacao.A motivacaoNao foi uma crise, mas a necessidade de focar os testes em uma funcionalidade que precisava ser entregue rapidamente que motivou a recuperacao desse conceito, ainda que de uma forma adaptada a nossa realidade.Bem, na minha empresa as mesas nao tem divisorias e o time encontra-se todo na mesma sala. Alem disso, anteriormente ja tive a experiencia de sentar com meu notebook ao lado do desenvolvedor e ir testando, reportando, ele corrigindo, eu re-testando e testando outras coisas na sequencia. Mas o trabalho ficava muito ping pong e precisavamos de mais agilidade.A ferramenta e o processoResolvemos experimentar o google docs como virtualizacao desse conceito de war room. Funcionou assim:Eu ia testando, escrevendo no google docs os problemas encontrados, incluindo prints quando necessario. Ao lado de cada problema, eu colocava um comentario. Os comentarios tem opcao de Reply e de Resolve. E ainda ha a opcao do chat para comunicacao.Quando o desenvolvedor interagia com o meu comentario, eu recebia e-mail comunicando da alteracao e o ponto que foi corrigido. Isso claro, fora o aviso verbal.Alem disso, por concentrarmos o essencial da comunicacao no documento, no caso de precisarmos desviar o nosso foco para outra tarefa momentaneamente, nao perdiamos a sequencia do que estavamos fazendo.Exemplos:Email com issue solved:Comentarios, reply e alteracoes:VantagemEu podia testar todo um aspecto da feature e ir apontando os problemas, sem precisar interromper meu teste para comunicar ao desenvolvedor de um problema intermediario e sem ter que esperar terminar todo o fluxo pretendido para entao reportar o problema. Tambem, o desenvolvedor nao precisava esperar que eu revalidasse uma correcao para fazer a proxima correcao.Final felizE depois de muitos git pull, problemas resolvidos e feature entregue! :)DisclaimerA utilizacao de uma ferramenta colaborativa nao exclui a necessidade de comunicacao verbal, de levantar-se e ir a mesa do seu colega de trabalho. Essa comunicacao pessoal e