Brasil Campeão da Copa do Mundo de Testes de Software

Uma semana se passou após a divulgação do resultado das finais, e talvez nesse momento eu já consiga compartilhar com vocês, de maneira mais precisa, como foi essa experiência.

Após o anúncio de nossa vitória na etapa continental, começamos uma série de preparativos, que consistiram desde a parte logística da viagem (passagens, hotel, documentos…), as demandas da organização (fotos, vídeos, entrevista…) e a preparação técnica para a organização.

Na parte técnica, analisamos o nosso desempenho na fase continental, destacando os pontos fortes que precisavam ser mantidos e os pontos de melhoria, onde precisaríamos realizar ajustes. A partir dessa análise nos dividimos, de modo a realizar as tarefas, que consistiam desde ajustes na estratégia de testes, test report e principalmente atividades de estudo e seleção de ferramentas para áreas como acessibilidade, segurança e usabilidade.

A competição:

A etapa final seguiu o mesmo modelo da continental, tivemos 3 horas para validar a aplicação (Comércio Eletrônico) e enviar um Test Report, que deveria abranger a estratégia utilizada, findings, recomendações e análise do produto. O grande diferencial nessa fase, foi que os jurados, equipe de reportagem e platéia podiam nos interromper com perguntas durante as três horas, o que aconteceu algumas vezes e exigiu jogo de cintura para responder e retomar o trabalho sem perder a concentração.

Este slideshow necessita de JavaScript.

Durante a prova final, utilizamos diversas ferramentas de apoio, abaixo aponto algumas:

  • Google Docs: Colaborativamente alimentávamos o test report, durante a execução, adicionando os defeitos encontrados e informações relevantes.
  • Trello: Antes da competição preparamos um quadro virtual, onde listamos as áreas de teste, e pudemos nos organizar, com o objetivo de evitar duplicação de trabalho e assegurar uma melhor cobertura.
  • MindMeister: Ferramenta para criação de mapas mentais, utilizada para descrevermos nossa estratégia de maneira mais visual.
  • HP Pronq Agile Manager: Ferramenta oficial da competição para gerenciamento dos defeitos.
  • Acessibilidade: Utilizamos ferramentas online, como Wave e daSilva, com o objetivo de apontar falhas de acessibilidade na estrutura do código.
  • Segurança: O Firebug foi uma das ferramentas que utilizamos para identificar potenciais falhas de segurança.

Placar com contagem de bugsAo final das três horas de trabalho intenso, ficou claro para nós ao conversarmos com alguns dos jurados e organizadores, que além das capacidades técnicas em testes, eles também estavam avaliando aspectos relacionados às metodologias ágeis, como a organização da equipe e comunicação interna e com o cliente.

Divulgação do resultado:

No dia seguinte, durante o Keynote de abertura da conferência, recebemos a premiação da etapa continental.

premiacao_etapaContinentalEnquanto, que a divulgação do resultado final aconteceu apenas a noite, durante a festa temática, organizada pelo evento. E claro, que ficamos muito felizes com o resultado final, representando o Brasil e elevando a nossa comunidade de testadores a uma posição de destaque.

Brasil Campeão

Por fim, um agradecimento especial a toda a organização do evento, toda estrutura e apoio fornecido antes, durante e após o evento foram impecáveis. Além da competição, pudemos aproveitar os 3 dias da conferência, que também foram excelentes e em breve compartilharei com vocês um pouco das palestras e workshops que pude assistir.

S.O.L.I.D – Coisas que todo programador deveria saber

Esse post é mais um da série “Coisas que todo programador deveria saber” (talvez o primeiro do BytesDontBite [BdB] com esse título na verdade :P).

Hoje vou falar um pouco sobre o S.O.L.I.D, que é na verdade um acrônimo onde cada letra representa um “princípio” de design de orientação a objetos.  A importância desses princípios é imensa. Então vamos lá:

  • S (Single Resposability Principle) – Toda classe deve ter uma única responsabilidade, e essa responsabilidade deve ser completamente encapsulada por essa classe. Parece uma coisa simples, mas a grande maioria dos problemas que vejo por aí, acontecem pelo simples motivo de termos classes (e métodos) gigantes que fazem tudo o que você pode imaginar. Talvez esse seja, ao meu ver, o mais importante (e o mais simples) desses princípios. Obviamente ele é muito relacionado aos conceitos de (alta) coesão e (baixo) acoplamento, e também é bem descrito e detalhado pelos princípios do GRASP (tópico para o próximo post dessa série)

    Arquitetando…
  • O (Open/Closed Principle) – Todas as entidades do software (classes. módulos, métodos, …) deveriam ser abertas  (open) para extensão e fechadas (closed) para modificação. Isso significa que essas entidades do software tem que permitir uma mudança de comportamento sem a alteração do seu próprio código fonte. Em uma conclusão bem óbvia e simplista, estamos falando de usar mais interfaces e classes/métodos abstratos, que podem facilitar a mudança não dolorosa de comportamento de algumas entidades.
  • L (Liskov Substitution Principle) – Qualquer objeto do tipo X (que é subtipo Y) deveria poder substituir um objeto de tipo Y sem alterar as propriedades básicas do sistema (corretude, etc).
  • I (Interface Segregation Principle) – Prega que as interfaces tenham somente os métodos que serão usados por quem vai implementar essa interface. Ou seja, separar (segregar) interfaces que contenham muitos métodos, em interfaces menores, de forma que, quem implemente a interface, não seja forçado a implementar métodos que não são usados naquele contexto.
  • D (Dependency Inversion Principle) – Esse princípio prega uma forma de desacoplamento, aonde os módulos tem que depender de abstrações (leia-se interfaces) ao invés de depender de classes concretas. Isso se aplica principalmente quando falamos das dependências entre as camadas arquiteturais de um determinado sistema. Uma forma de inversão de dependência é a Injeção de dependência.

Como você pode notar, todos esses princípios meio que se completam de forma a atingir o objetivo que é um design flexível e de fácil manutenção. Espero que tenha sido útil, e até o próximo post dessa série, onde falaremos sobre o GRASP 😉

Estatisticas do BdB no ano de 2013 (Antes tarde do que nunca :P)

Se você está curioso por algumas estatisticas sobre o ano de 2013, aqui está, basta clicar na figura abaixo e seguir o link 😉

Estatisticas do BdB no ano de 2013 (Antes tarde do que nunca :P)

Pedacinho de texto das estatisticas:

The concert hall at the Sydney Opera House holds 2,700 people. This blog was viewed about 22,000 times in 2013. If it were a concert at Sydney Opera House, it would take about 8 sold-out performances for that many people to see it.

Click here to see the complete report.

Agilidade é Ritmo!

Assitir palestras de alguns gurus é sempre interessante! Mesmo quando a palestra não está legal, em algum momento você pode escutar alguma frase ou alguma explicação que pode mudar sua vida. Eu diria que é mais ou menos como um atacante de futebol que é artilheiro, mas está jogando uma péssima partida, mas o técnico o deixa em campo pois a qualquer momento ele pode fazer um gol!

Dito isto, eu estava em uma longa palestra com um artilheiro, mas a palestra não estava tão interessante. Mas em determinado momento, falando sobre agilidade,  ele disse: “Agile is about rhythm!” Essa frase então chamou minha atenção e fiquei atento a explicação do que isso significava, e fez sentido pra mim.

Se você participa de um projeto que tem um determinado ritmo como por exemplo entregar um release do software a cada 6 meses, você tem “muito tempo” para pensar/fazer/detalhar requisitos, “muito tempo” pra implementar e por aí vai. É óbvio que você vai terminar fazendo mais do que o necessário para o momento e talvez não consiga finalizar tudo, além de colher o feedback muito tarde (em 6 meses tudo pode mudar).

No entanto, se você tem um ritmo de fazer um release por mês, você tem menos tempo pra focar em vários requisitos, por isso você só seleciona alguns deles (os mais importantes do ponto de visto do cliente), você nao tem tanto tempo pra discutir requisitos em um nível de detalhes muito aprofundado (a  não ser que realmente seja preciso) e você não tem tempo para perder tempo com reuniões sem sentido e etc, então você foca em desenvolver aquilo que tem pra ser desenvolvido de forma a receber feedback o mais rápido possível e mudar o mais rápido possível (antes que o custo da mudança seja muito caro ou inviável).

Ah, acho que tem um cenário pior do que os dois que apresentei, que é o caso de você não ter ritmo nenhum!

E você o que acha? Qual o ritmo que faz mais sentido para você ou para sua empresa?

O fator ônibus *

O post de hoje é simples e curto mas apresenta um conceito que é muito importante no dia-a-dia das empresas e dos projetos (principalmente de software, mas não necessariamente se limita a software).

Já participou de algum projeto onde uma ou talvez duas pessoas possuiam todo o conhecimento sobre o projeto? Acho que não é muito difícil isso acontecer, eu mesmo já participei de alguns. Alguns onde outra pessoa tinha todo o conhecimento acerca de um projeto, e outros onde eu mesmo tinha o conhecimento “concentrado” em mim (não porque eu queria, mas por conta das circunstâncias).

O fator ônibus * (do inglês bus factor), significa a quantidade de pessoas, que se forem atropeladas por um ônibus, farão o projeto desandar, ou até mesmo inviabilizar a continuidade do projeto. É óbvio que quanto maior essa medida melhor, pois dificilmente 10 pessoas são atropeladas por um ônibus no mesmo momento.

Moral da história: Se o seu projeto tem o fator ônibus igual a 1 ou 2, você corre sérios perigos! Então corra atrás, compartilhe o conhecimento, treine as pessoas, sugue o que puder sugar dos que tem mais conhecimentos, pergunte, leia, converse e se informe para o bem do seu projeto e da sua equipe!

* Observação: Vale a pena lembrar que o fator ônibus não significa ser literalmente atropelado por um ônibus. Ser atropelado por um ônibus pode significar: Algum membro da equipe conseguir um outro emprego, alguém sair de licença maternidade, alguém decide mudar o estilo de vida, alguém pedir demissão, alguém simplesmente sair de férias por 1 mês (parece absurdo né?), ou realmente alguém for atropelado mesmo por um ônibus 😛

Aprenda as funções do Scrum Master em 5 minutos

O Scrum é uma das metodologias ágeis mais utilizadas pelas empresas de TI, porém diversos pontos ainda geram dúvidas: Papéis, práticas, ferramentas, etc. Nesse contexto, cada equipe acaba realizando seus ajustes baseados na própria experiência e na natureza do projeto.

O Vídeo, abaixo, faz uma representação divertida do papel do Scrum Master na equipe. São apenas 5 minutos, que de maneira divertida traduzem os principais aspectos da atuação desse profissional.

As principais funções do Scrum Master destacadas pelo vídeo são:

– Assegurar a eficiência e comprometimento de todos ao Daily Meeting.

Evitar que o cliente interfira diretamente no trabalho da equipe durante a Sprint.

– Assegurar que a definição de “Pronto” esteja clara para toda a equipe. “Qualidade é chave!”.

Gerenciar o Quadro de Atividades do Scrum.

Remover impedimentos, permitindo a produtividade máxima da equipe.

Proteger e Liderar o time.

Consulte nossa seção de agilidade, e confira outros posts relacionados a Scrum.

Agora você já pode acompanhar as novidades do BdB pelo Facebook, acesse e curta nossa página.

Já conhece o eXtreme Go Horse Programming?

Você conhece o eXtreme Go Horse (XGH) Programming? Não?? Então não perca tempo e veja aqui essa maravilhoso processo 🙂 Será que a vida de desenvolvimento de software fica mais fácil depois das dicas desse processo? 😀

1- Pensou, não é XGH.

XGH não pensa, faz a primeira coisa que vem à mente. Não existe segunda opção, a única opção é a mais rápida.

2- Existem 3 formas de se resolver um problema, a correta, a errada e a XGH, que é igual à errada, só que mais rápida.

XGH é mais rápido que qualquer metodologia de desenvolvimento de software que você conhece (Vide Axioma 14).

3- Quanto mais XGH você faz, mais precisará fazer.

Para cada problema resolvido usando XGH, mais uns 7 são criados. Mas todos eles serão resolvidos da forma XGH.

XGH tende ao infinito.

4- XGH é totalmente reativo.

Os erros só existem quando aparecem.

5- XGH vale tudo, só não vale dar o toba.

Resolveu o problema? Compilou? Commit e era isso.

6- Commit sempre antes de update.

Se der merda, a sua parte estará sempre correta.. e seus colegas que se fodam.

7- XGH não tem prazo.

Os prazos passados pelo seu cliente são meros detalhes.

Você SEMPRE conseguirá implementar TUDO no tempo necessário (nem que isso implique em acessar o BD por um script maluco).

8- Esteja preparado para pular fora quando o barco começar a afundar… ou coloque a culpa em alguém ou algo.

Pra quem usa XGH, um dia o barco afunda. Quanto mais o tempo passa, mais o sistema vira um monstro.

O dia que a casa cair, é melhor seu curriculum estar cadastrado na APInfo, ou ter algo pra colocar a culpa.

9- Seja autêntico, XGH não respeita padrões.

Escreva o código como você bem entender, se resolver o problema, commit e era isso.

10- Não existe refactoring, apenas rework.

Se der merda, refaça um XGH rápido que solucione o problema. O dia que o rework implicar em reescrever a aplicação toda, pule fora, o barco irá afundar (Vide Axioma 8).

11- XGH é totalmente anárquico.

A figura de um gerente de projeto é totalmente descartável. Não tem dono, cada um faz o que quiser na hora que os problemas e requisitos vão surgindo (Vide Axioma 4).

12- Se iluda sempre com promessas de melhorias.

Colocar TODO no código como uma promessa de melhoria ajuda o desenvolvedor XGH a não sentir remorso ou culpa pela cagada que fez. É claro que o refactoring nunca será feito (Vide Axioma 10).

13- XGH é absoluto, não se prende à coisas relativas.

Prazo e custo são absolutos, qualidade é totalmente relativa. Jamais pense na qualidade e sim no menor tempo que a solução será implementada, aliás… não pense, faça!

14- XGH é atemporal.

Scrum, XP… tudo isso é modinha. O XGH não se prende às modinhas do momento, isso é coisa de viado. XGH sempre foi e sempre será usado por aqueles que desprezam a qualidade.

15- XGH nem sempre é POG.

Muitas POG’s exigem um raciocínio muito elevado, XGH não raciocina (Vide Axioma 1).

16- Não tente remar contra a maré.

Caso seus colegas de trabalho usam XGH para programar e você é um coxinha que gosta de fazer as coisas certinhas, esqueça! Pra cada Design Pattern que você usa corretamente, seus colegas gerarão 10 vezes mais código podre usando XGH.

17- O XGH não é perigoso até surgir um pouco de ordem.

Este axioma é muito complexo, mas sugere que o projeto utilizando XGH está em meio ao caos. Não tente por ordem no XGH (Vide Axioma 16), é inútil e você pode jogar um tempo precioso no lixo. Isto fará com que o projeto afunde mais rápido ainda (Vide Axioma 8). Não tente gerenciar o XGH, ele é auto suficiente (Vide Axioma 11), assim como o caos.

18- O XGH é seu brother, mas é vingativo.

Enquanto você quiser, o XGH sempre estará do seu lado. Mas cuidado, não o abandone. Se começar um sistema utilizando XGH e abandoná-lo para utilizar uma metodologia da moda, você estará fudido. O XGH não permite refactoring (vide axioma 10), e seu novo sistema cheio de frescurites entrará em colapso. E nessa hora, somente o XGH poderá salvá-lo.

19- Se tiver funcionando, não rela a mão.

Nunca altere, e muito menos questione um código funcionando. Isso é perda de tempo, mesmo porque refactoring não existe (Vide Axioma 10). Tempo é a engrenagem que move o XGH e qualidade é um detalhe desprezível.

20- Teste é para os fracos.

Se você meteu a mão num sistema XGH, é melhor saber o que está fazendo. E se você sabe o que está fazendo, vai testar pra que? Testes são desperdício de tempo, se o código compilar, é o suficiente.

21- Acostume-se ao sentimento de fracasso iminente.

O fracasso e o sucesso andam sempre de mãos dadas, e no XGH não é diferente. As pessoas costumam achar que as chances do projeto fracassar utilizando XGH são sempre maiores do que ele ser bem sucedido. Mas sucesso e fracasso são uma questão de ponto de vista. O projeto foi por água abaixo mas você aprendeu algo? Então pra você foi um sucesso!

22- O problema só é seu quando seu nome está no Doc da classe.

Nunca ponha a mão numa classe cujo autor não é você. Caso um membro da equipe morra ou fique doente por muito tempo, o barco irá afundar! Nesse caso, utilize o Axioma 8.

Fonte: http://gohorseprocess.wordpress.com/extreme-go-horse-xgh/

Esse texto é uma brincadeira, você pode me xingar no twitter: @maribalbe