Há algumas semanas atrás, estávamos fazendo uma reunião de projeto e o Gerente do Projeto fez um comentário que 100% dos participantes (time de desenvolvimento e teste) ficaram sem entender nada no primeiro momento. Sabe qual foi o comentário? Foi o seguinte: “Bem, agora que o time de desenvolvimento concluiu o desenvolvimento e a execução dos testes unitários do release, e disponibilizarão o mesmo para o time de teste iniciar a execução dos testes, vou pegar a minha CADEIRA DE RODAS para andar pelo sistema!”. Nossa! Essa frase deixou um ponto de interrogação (?) na “testa” de cada pessoa que estava participando da reunião. Ninguém entendeu nada.
E ai, entendeu? Não, vamos lá então...
Vamos utilizar a Arquitetura Inclusiva para “traduzir” este vídeo para a área de teste e qualidade de software.
A falta de acessibilidade é a principal barreira enfrentada por pessoas que convivem com algum tipo de deficiência nas grandes cidades brasileiras. E a inclusão desta importante parcela da população – 24,6 milhões de pessoas em todo o país, segundo o Instituto Brasileiro de Geografia e Estatística (IBGE), é um desafio cada vez maior para arquitetos, engenheiros e responsáveis pela definição e implantação de políticas públicas que permitam aos que têm mobilidade reduzida se locomoverem com autonomia e independência.
Essa falta de “acessibilidade” é totalmente aplicada a nossa área de teste e qualidade de software. Na maioria das vezes os desenvolvedores de software não pensam nas possíveis falhas que podem ocorrer nos sistemas que estão desenvolvendo. Quantas vezes você já fez a pergunta “E se eu fizer isso ou aquilo, o que vai acontecer?” e o time de desenvolvimento respondeu “Xiiiii, isso eu não sei o que vai acontecer não. Não tem requisito pra isso”. Ou aquela velha frase que já conhecemos quando reportamos uma falha quando não existe um requisito específico associado a ela “Isso não é uma falha, é Work as Design” :-P !
Tudo isso é para incentivar os desenvolvedores de software a passearem de “cadeira de rodas” pelo sistema antes de disponibilizar um release para o time de teste, afinal, muitas vezes existem falhas que basta você acessar a segunda tela do sistema que elas aparecem.
Só lembrando que não estou criticando os desenvolvedores de software, que fique bem claro isso! Eu já fui desenvolvedor de software e ainda hoje gosto de brincar de ser desenvolvedor.
O mundo pertence aqueles que pensam em novos caminhos!!! Fica ai a dica!
Até+,
Quezada
Muito bom esse insight!
ResponderExcluirConfesso, que só fui entender após ver o vídeo. :)
E precisamos sim, está sempre pensando em novos caminhos, isso é fundamental para os profissionais da nossa área.
Parabéns pelo post!
Fabrício Ferrari de Campos
Abraços!
Sem Dúvida, o ato de "andar de cadeiras de rodas" no sistema faz com que a equipe que desenvolveu, ou o "cara que pediu" (Leia-se Product Owner)faça a auto-crítica... e de certa forma se prepare para o que virá durante a entrega... Estas auto-críticas ajudam ao desenvolvedor criar um espírito mais crítico, e deixar de ser um simples gerador de código, se tornando um profissional melhor... no fundo, o que é necessário, no meu ver, é resgatar um certo espírito da "ancienne ecole" de desenvolvimento... quando em tempos que nossas atividades não eram tão compartimentalizadas o desenvolvedor era mais crítico, e opinava diretamente nos projetos...
ResponderExcluir