As primeiras coisas que muitos pensam sobre quando considerar testes ágeis são ferramentas, automatização, quando e como fazer o teste, e o papel de testadores em uma equipe. Estes são todos temas muito dignos. Mas que estas coisas são necessárias para o sucesso e que são legais de se ter?
Craig Knighton escreveu em Não na minha descrição de trabalho quando discute como os times devem fazer a transição para o Ágil:
Como um time, e por isso quero dizer um time auto-organizado, time multifuncional que reconhece que a menos que você tenha este desafio dominado, seus produtos não terão a qualidade ou oportunidade que você deseja. A menos que a qualidade passe a ser responsabilidade de todos os membros do time, você não vai quebrar o ciclo de código-teste que está na raiz do problema. Regressão manual do software é equivalente a 100% de inspeção manual nas linhas de código. Neste mundo, eles entendem que os investimentos em inspeções automatizadas são a chave do processo de medição. No entanto, o produto pode precisar ser alterado para ser testado através de meios automatizados – esta modificação poderia ser tão dramática quanto uma mudança na arquitetura ou nas ferramentas de desenvolvimento. Investimentos em testes do desenvolvedor podem diminuir a dependência de inspeções manuais, mas isso significa mudanças em seus hábitos de trabalho. E, finalmente, os desenvolvedores podem precisar de ajuda para criar um framework de suíte de testes automatizados.
Isto combina muito do que é conhecido na comunidade. Para novas equipes que estão adotando Agile usando uma abordagem incremental, é adicionada a ênfase de times multifuncionais, auto-organizados, sendo uma obrigação assumir a responsabilidade pelo sucesso do produto, mantendo a distância da mentalidade "não é minha asa que está em chamas".
Ainda sobre o tema Testes Ágeis, seria negligente não mencionar a Agile Testing Conference que só teve lugar em Berlim. Gojko Adzic escreveu um breve sumário s apresentações da conferência. Um dos comentários de Gojko foi sobre o relato de Mary Poppendieck:
Poppendieck disse que "O maior defeito que temos agora [em desenvolvimento de software] é tolerar defeitos". Ela orientou tratar cada falha (defeitos que escaparam) como uma oportunidade de aprendizado. O caminho a seguir é determinar a causa raiz da falha e eliminá-la assim que o defeito se repetir no futuro.
A mentalidade do Lean de parar-e-corrigir está diretamente relacionada com um time auto-organizado, multifuncional e resposnsável. Se a equipe não está trabalhando em conjunto, então a equipe não vai parar, mas um membro do time sim (se você tiver sorte). E se eles não param, eles não vão aprender juntos. E o aprendizado é uma parte importante do desenvolvimento de software, na verdade, este repórter acredita que o gargalo é o aprendizado na engenharia de software.