O que um exército poderia ensinar a um testador? Quais são os dois extremos nas abordagens de teste? Como explicar que a dívida técnica é liquidada por pagamento? O que as perguntas anteriores têm em comum?
A coisa geral é que, apesar de toda a diferença, todos estão perto de uma pessoa.
Jim Holmes tem atrás de si várias décadas de experiência em TI, iniciada nos anos 80 na Força Aérea dos EUA - não é de surpreender que ele esteja pronto para contar muito. O conceito de "cultura de teste" é importante para ele, e fizemos perguntas que podem variar bastante, mas que, de alguma forma, estão relacionadas à cultura de teste.
- Pergunta introdutória: conte-nos sobre você.- Meu nome é Jim Holmes, sou consultor independente e proprietário de minha própria empresa, a Guidepost Systems. Sou especialista em qualidade de entrega de software e programa há cerca de 20 anos, antes disso eu servi no exército por um longo tempo. Fiquei seriamente interessado em qualidade há cerca de 15 anos, enquanto trabalhava em vários projetos de pouco sucesso. Em geral, fiz muita automação de testes, testes de unidade, testes de integração e, principalmente, testes funcionais, testes de interface do usuário. Em particular, trabalhei para uma empresa que escreveu a maravilhosa ferramenta Telerik Test Studio. Nos últimos 5 a 8 anos, comecei a lidar não apenas com aspectos puramente técnicos, mas também com a qualidade do suprimento como um todo - isto é, quão bem é a relação entre a equipe de suprimentos e os negócios. Mas, ao mesmo tempo, continuo depurando scripts do WebDriver por um longo tempo e resolvendo problemas como falhas periódicas devido a ações assíncronas incorretas. Eu moro na cidade de Ashland, no Oregon - lembre-se, não em Portland (quando nos EUA você diz "Oregon", geralmente todo mundo pensa em "Portland").
- Provavelmente, para o testador, a parte mais incomum da sua biografia é o serviço militar. O que exatamente você estava fazendo lá?- Servi na Força Aérea dos EUA porque sempre fui inspirado por aviões e meu pai era piloto. Ele me levou no meu primeiro vôo quando eu tinha apenas 4 anos de idade. Na Força Aérea, tive muita sorte, servi na equipe E-3 - este é um avião tão grande com um enorme disco no topo, onde fui responsável pela operação do radar e de alguns sistemas de comunicação. Por onze anos, venho administrando e depurando esse grande sistema eletrônico. E durante o tempo livre de vôos, administrei os computadores do nosso esquadrão. Naquela época, tornou-se possível criar redes no local de trabalho. Além disso, como eu era soldado, fui pago pela educação, então fui a uma escola noturna para desenvolver software.
Quanto à sua pergunta, a experiência do serviço militar é incomum não apenas para os testadores, mas também para muitas outras áreas. Posso dizer que pelo menos me ensinaram disciplina lá.
- Sim, no caso do exército, a primeira coisa que vem à mente é disciplina. E com isso, muitos testadores e desenvolvedores têm problemas. Você acha que eles têm algo a aprender com os militares?- Esta é uma pergunta muito interessante. O fato é que a disciplina que me ensinaram era um pouco diferente dos, digamos, dos pára-quedistas, ou seja, não havia gritos e punições constantes. Me ensinaram uma abordagem disciplinada para testar e, em geral, para resolver problemas. A disciplina no local de trabalho também foi importante - entender o que era uma hierarquia; Para aprender a trabalhar nele, você deve ser capaz de se comunicar com os superiores. Esse tipo de disciplina me ajudou muito.
Eu deixei o exército há 25 anos - sim, eu sou um homem velho - e o trabalho no setor civil contrastou muito interessante com a minha experiência anterior por causa das prioridades lá. No exército, servi em um avião, que deveria monitorar o inimigo em um grande território e garantir a minha segurança. Qualquer erro significava um risco para a vida de nossos soldados. Eu não quero exagerar, mas realmente era. Então, quando alguém na área de TI começa a entrar em pânico e exige que uma tarefa seja resolvida imediatamente, graças à minha disciplina e à minha experiência, sempre posso tranquilizar as pessoas - não estamos ameaçados de que alguém morra e não perdemos centenas de milhares de dólares por minuto (e já estive nessas situações). Freqüentemente entramos em pânico e deixamos os negócios ou acionistas nos intimidar desnecessariamente e criar uma tensão irracional que não faz nada de bom para ninguém. Talvez a melhor coisa que o exército tenha me ensinado seja a capacidade de pedir calma, avaliar a situação profundamente e planejar nossas ações com antecedência, e não correr para uma tarefa sem pensar por causa de um pânico criado artificialmente.
- Ou seja, você precisa de um tempo para pensar em uma estratégia.- Sim, e em TI esse problema já faz muito tempo: requisitos constantes para entregar o projeto exatamente neste segundo. O principal é fazer rapidamente, e o que exatamente está sendo feito é de importância secundária. Na maioria das vezes, essa pressão pode ser controlada se o diálogo for conduzido corretamente. Mas, para isso, é importante poder dizer que criaremos mais valor se gastarmos um pouco mais de tempo e abordarmos racionalmente o problema.
- Vamos continuar com suas atividades atuais. No trabalho, você está familiarizado com a forma como eles abordam os testes em diferentes empresas de maneiras diferentes. É claro que a abordagem pode depender, por exemplo, do tamanho da empresa. Mas provavelmente existem muitas diferenças menos óbvias - você pode falar sobre elas?- Esta é uma pergunta maravilhosa. Além do meu trabalho independente, também trabalho com a Pillar Technology de Columbus, Ohio. Conheço pessoas desta empresa há muito tempo. Agora, cerca de 250 pessoas trabalham lá, e quase todas trabalham no princípio da programação extrema (XP): eles têm muitos testes de unidade e o desenvolvimento é muito bem pensado. Quando fui contratado lá há três anos, eu era o único testador, e eles criaram um produto de alta qualidade. Eles abordaram o teste exclusivamente da posição do XP, da posição do desenvolvimento orientado a testes. Essa é uma ótima abordagem, e eles a aplicaram com sucesso, e eu, juntamente com outros funcionários, conseguimos alterar alguns aspectos da entrega de software.
E você pode comparar essa experiência com outra empresa em que tenho consultado nos últimos três anos. Esta é uma empresa industrial, está na lista dos dez melhores da Fortune e emprega cerca de 200 mil pessoas em todo o mundo. Eles têm um departamento de TI muito grande para as necessidades internas da empresa. Há muitas pessoas boas lá, mas seus testes ficaram presos às práticas das décadas de 1980 ou 1990. A empresa produz grandes lotes exatamente dos mesmos produtos e muitos estão acostumados ao fato de que, na produção de, por exemplo, rolamentos de esferas, é possível estimar o número de defeitos esperados. Mas o problema é que eles transferem esse tipo de pensamento para a TI.
Tive uma conversa com quatro, em geral, funcionários muito inteligentes que estavam envolvidos na coleta de relatórios de defeitos de vários projetos e tentando prever o número de possíveis defeitos no futuro. Eu disse a eles que isso é bastante razoável no setor, mas como eles distinguirão os indicadores calculados para um aplicativo móvel dos indicadores de, digamos, serviços da web? Eles responderam que não há diferença. Então, tive a sorte de ver pontos completamente opostos no espectro de diferentes abordagens e culturas de teste.
Além disso, trabalhei com algumas empresas que não conseguiram sair do estágio de inicialização, quando trabalham o tempo todo sem olhar para trás, sem tentar cobrir toda a situação. E então, depois de vários anos, em projetos complexos, os problemas que surgiram nesse estágio começam a ser sentidos de maneira acentuada, e tenho que convencer as pessoas de que essa abordagem está errada e que agora preciso parar e pensar adequadamente em minhas ações. Em geral, minha resposta foi um tanto extensa, espero não ter perdido completamente o contato com sua pergunta.
- E na sua prática de aconselhamento, há momentos em que, depois de concluir o trabalho com a empresa, eles lhe dizem "nada melhorou"?Vou lhe contar um segredo que é difícil para as pessoas, somos criaturas muito difíceis. Esta é uma das razões pelas quais tenho tantos cabelos grisalhos (a segunda é minha filha). Mudar uma pessoa é difícil; mudar pessoas em uma organização é ainda mais difícil. Então, sim, eu tenho essa situação com bastante frequência.
Sobre alguns consultores, dizemos até que ele "se esgotou". Isso se deve ao fato de estarmos envidando muitos esforços para mudar a cultura que se formou na organização e precisamos trabalhar muito com problemas em nível pessoal - as pessoas têm medo de mudanças, constantemente precisam se convencer de que isso é necessário e procure o caminho que melhor lhes convém. Não importa quão forte e alto eu seja, não posso simplesmente vir e dizer: faça isso e aquilo. Precisa chegar a um consenso. Esse trabalho precisa ser realizado por anos para conseguir algo e, quando parece que você resolveu o problema e sai para consultar outra organização, encontrará exatamente os mesmos problemas no local anterior. Mais uma vez, você gasta uma quantidade enorme de tempo e esforço e, então, na primeira empresa, tudo já voltou ao seu estado anterior.
As pessoas são tão organizadas, é difícil com a gente que muitas vezes voltamos aos nossos velhos hábitos. Mas, apesar disso, existem exemplos de trabalhos verdadeiramente bem-sucedidos. Existem organizações que conseguem consolidar o resultado alcançado com você. Em geral, eu diria que um equilibra o outro. Eu continuo fazendo esse trabalho porque esses casos de sucesso são imensamente satisfatórios.
- Em seu blog, você escreveu sobre seus princípios profissionais e falou sobre a necessidade de ser aberto, sempre aprender coisas novas, ouvir mais do que conversar, adaptar-se e ser gentil com as pessoas. Gostaria de saber se realmente ajuda uma boa atitude em relação às pessoas?Sim, isso ajuda. Eu disse que servia no exército, onde tínhamos disciplina estrita - mas devemos entender que disciplina e estrutura de forma alguma interferem em boas relações e empatia com outras pessoas. Você conhece o chef escocês Gordon Ramsay? Ele lidera o show da Hell's Kitchen. Eu o mencionei porque os chefs de restaurantes caros muitas vezes se comportam nojento com os funcionários - eles gritam e insultam. Eu odeio essa atitude em relação às pessoas. Para mim, uma boa atitude um com o outro é importante. Se você deseja obter alguma mudança, precisa entender por que as pessoas resistem a elas, ou seja, precisa de empatia. E isso permitirá que você faça a própria pessoa querer mudar. Essa abordagem é muito mais eficaz do que gritar com as pessoas e exigir que elas obedeçam e não façam perguntas. Cada pessoa tem sua própria mente, sua própria alma, sua própria experiência. Eu não gostaria de me aprofundar na filosofia, mas acredito que, a longo prazo, boa atitude e empatia permitirão alcançar ótimos resultados. Então sim, eles ajudam.
- Você realiza seminários e, em um deles, ensina pessoas que não sabem programar. Eu tenho duas perguntas Primeiro, que problemas geralmente impedem as pessoas de se auto-programarem? Em segundo lugar - você acha que no próximo ano os testes automatizados prevalecerão sobre os testes manuais?- Na minha experiência, as pessoas são frequentemente perturbadas não por dificuldades técnicas, mas pelo medo. Posso dar um exemplo da minha experiência em uma empresa da Fortune 10, sobre a qual eu já falei. Trabalhei com uma equipe de testadores que fazia testes manuais e precisávamos fazer automação usando o WebDriver. Destas, a maioria não conseguiu nem abrir o Eclipse para começar a escrever código. Eles tinham medo de escrever um script para automação, porque, no entendimento deles, isso não era muito diferente de escrever um serviço da Web ou banco de dados escalável com multithreading, ou seja, coisas que os desenvolvedores aprendem há anos. Esse medo os impedia de fazer coisas geralmente simples.
Atualmente, estou desenvolvendo um curso para o Ministério de Testes baseado em um workshop no qual explico que você não precisa de anos de prática para simplesmente abrir um script Java, C # ou Ruby, lê-lo e entender a estrutura geral ou escrever teste simples no WebDriver. Além disso, mesmo se você não entender completamente tudo o que está acontecendo no código, poderá fazer uma avaliação geral, porque você sabe, por exemplo, que um método não deve ocupar três telas, não deve haver quatro instruções aninhadas se - elas serão difíceis para testar, você não pode dar nomes de uma letra às variáveis e assim por diante. Na minha opinião, no estágio inicial, a principal dificuldade é superar o medo de que você tenha que resolver tarefas incrivelmente complexas. E eu sempre fiquei interessado em ver com que rapidez meus clientes se livram desse medo - você só precisa dar à pessoa um teste de unidade simples e pedir que ela escreva organizar, agir e afirmar. Eu acho que esse componente humano é muito importante.
A maioria das tecnologias com as quais trabalhamos não é tão complicada, poucas estão envolvidas em coisas como veículos não tripulados. Certa vez, realizei um seminário para um cliente na Índia e havia um gerente sem nenhuma experiência em programação. Esse gerente ficou muito zangado no começo, e o motivo foi justamente esse medo de que acabei de falar, e esse medo foi sobreposto à relutância em parecer estúpido. Mas no final da primeira lição, ele mergulhou tanto em escrever testes que eu tive que colocá-lo fora da platéia uma hora depois que a aula já havia terminado - ele sentou-se, enterrando-se no monitor, emparelhado com outro participante do seminário e escreveu testes simples para o algoritmo salarial placas. E o ponto aqui não está em minhas habilidades de ensino - apenas mostra o quão importante esse medo ou sua ausência são importantes. Aqui estamos falando de coisas inerentes à natureza humana.
Sua segunda pergunta relacionada à transição do teste manual para o teste automatizado. Tenho alguma experiência aqui, trabalhei por três anos em uma empresa envolvida em automação de testes. Acredito que a questão deve ser colocada de maneira diferente e se esforçar não para a automação de testes, mas para o desenvolvimento de testadores e a aquisição de muitas habilidades técnicas, uma das quais deve ser o teste automatizado. Gostaria de ver esses testadores que, com uma história de usuário, especificações e requisitos, poderiam livremente conduzir um diálogo com desenvolvedores sobre coisas bastante especializadas e procurar em conjunto soluções que serão incorporadas no código. Isso é um pouco diferente da abordagem na qual o testador ensina programação, apenas para poder escrever scripts do WebDriver. Essa habilidade, é claro, também é importante, mas, na minha opinião, não é a mais importante. A supertarefa, na minha opinião, é a capacidade de conduzir um diálogo com o desenvolvedor e garantir que ele tenha em mente o processo de teste ao escrever o código. Até o TDD já será um resultado significativo - acredito que todas as organizações devem ser capazes de escrever assim.
A conclusão é que o teste entregue corretamente está longe de ser reduzido a testes de unidade ou de integração. Muitas vezes, as pessoas estão satisfeitas com o teste de um caminho típico de execução de código - todos os testes são aprovados, as caixas de seleção estão em toda parte, é alcançada 100% de cobertura do código. Mas nada disso garante a qualidade do código, garante? Embora esses também sejam procedimentos necessários, é claro. Portanto, no meu entendimento, o testador não deve apenas escrever alguns testes funcionais no WebDriver, mas pensar em como ele pode estabelecer uma cooperação mais estreita com desenvolvedores e analistas de negócios. Você pode, por exemplo, experimentar a
programação mob . Em geral, acredito que a automação é uma ferramenta, não uma meta.
- As palavras “estreita cooperação com os desenvolvedores” estão muito próximas de nós, como organizadores da Heisenbug - até o slogan da conferência é “sobre testes, mas não apenas para testadores”. E em conexão com essa cooperação, eu gostaria de fazer a seguinte pergunta: o que, como pessoa com ampla experiência em testes, gostaria de dizer aos nossos leitores e programadores?"Que não somos todos maus!" Os testadores ganharam notoriedade com suas próprias ações. Eles encontram falhas nos mínimos detalhes nas reuniões, geralmente comunicam relatórios de erros, não palavras. O desenvolvedor vem trabalhar de manhã e vê 50 relatórios de erros que informam sobre erros gramaticais e páginas desalinhadas. Eu estive em ambos os papéis e sei como os programadores reagem a isso. Isso faz parte da velha escola de testes, e eu também já me comportei dessa maneira. Mas os testadores, que estão mais acostumados com a abordagem moderna, entendem que é mais fácil e melhor simplesmente conversar com ele do que bombardear um programador com relatórios de erros.
Na minha opinião, é importante que os desenvolvedores entendam que um bom testador pode ser muito valioso e, se você falar com ele com antecedência, poderá economizar muito tempo e nervosismo. É o que diz a teoria das restrições. Suponha que eu seja um desenvolvedor e vejo que o testador detectou algum problema. Se, em vez de escrever sobre isso no TFS ou em outro lugar, for até ele falar pessoalmente, essa conversa me ajudará a reduzir o número de defeitos no código que escrevo. Além disso, na comunicação pessoal, a maioria dos testadores, em regra, está longe de ser assustadora. , , , , — , , , .
, . , , , , — , . , .
, , : Heisenbug , Fortune 10. , ? 6-7 Heisenbug , .
— . «The leadership journey» . , : , , — . ?— , , IT: , , , , . , , , , . , , , . , , .
, . , , , . , : , , . , , , . , , , . . , , . , , - , . , , . , — .
— , . : , , , . — ?— 18 , , 13 14. . , — , , . , , . , .
, . , , . DevOps. , , . , . , Skype - , Skype for Business Google Hangouts, . . , . , , , Xbox — , .
, — . , . hangout Slack — . , , .
20 , , — . . , , , . , , , . . , — , . , , .
— «Technical debt: payment plan». « » , « » , . , , , , ?— . , , IT - , . (Trish Khoo), Twitter hogfish. — , . , , «Technical debt: payment plan». , , , , -, .
, , , , - . -, , , . , , . - X , Y , . , - . , , 30 - , . , -, . , , : - .
, 10 3 . 3 . , . . , , , , . , , , - , . , . , , IT, , . , . , . . , , - , , , .
, , . , , . , , , . , .
— , , , . , , , .— . , . , , , . , , — , . , , - . .
, . , , , , . , , , , , , . , , , .
— , — . , .— Fortune 10, , . , . , , , . , , , , , Acceptance Testing.
, , . , (, Sonar Cube), , . , , . , « », , , , . , , . , , - .
— . .— , . , : , .