Existe uma frase popular “coça sua própria coceira”: se você deseja criar um novo produto, faça um que você não tenha. Nesse caso, você entende melhor como fazê-lo bem.
Adam Carmi estava ciente da falta de uma ferramenta de teste visual que ajudaria as pessoas a não quebrar os olhos em busca de um layout de viagem. E, no final, ele criou uma ferramenta, adaptando a IA para isso, e se tornou um dos co-fundadores da Applitools. Parece um emprego dos sonhos: quando você luta com a dor que conhece, sente que está mudando o mundo para melhor. Mas que dificuldades um especialista em TI enfrenta quando o destino de uma empresa inteira depende dele?
E como a própria ferramenta Applitools também precisa ser testada, Adam aprendeu muito sobre o teste de projetos com IA. Amanhã em Heisenbug, ele falará sobre como fazer isso, e seu relatório será transmitido ao vivo - para que todos possam assistir ao vivo. Enquanto isso, perguntamos a ele sobre os dois tópicos: como é criar uma empresa e coisas relacionadas a testes e IA.
Vida de inicialização
Evgeny Trifonov ( phillennium ): Você trabalhou por muitos anos e decidiu criar uma startup. Como isso aconteceu e qual foi o ímpeto?
Adam: Meu trabalho anterior era uma empresa de segurança da informação. Eu trabalhei lá por 8 anos. Eu acho que você pode imaginar quantas UIs existem em um produto de segurança. Um grande número de registros, tabelas, gráficos, consultas e alertas. E em torno de tudo isso havia muita interface do usuário não óbvia.
Tudo foi complicado pelo fato de essa interface ter sido traduzida para 6 idiomas e fornecida sob cinco marcas diferentes. Para testar tudo manualmente do início ao fim em todas as variações, demorou cerca de uma semana. Havia 20 testadores que faziam isso a cada iteração. Ou seja, se uma liberação exigir várias iterações, isso requer um ciclo de liberação de pelo menos 2-3 meses.
Portanto, naqueles anos em que trabalhei lá, faltavam soluções para esse problema. Obviamente, estávamos envolvidos em automação. O Selenium ainda era um produto jovem, nós o usamos, mas não cobria a interface do usuário. Expliquei constantemente o problema aos fornecedores da época (HP, Microsoft e IBM) e pedi uma solução. A resposta sempre foi uma: é impossível. Para verificar se a interface tem a aparência que deveria (em vez de apenas "funcionar como deveria"), sempre serão necessários testadores manuais.
Ouvindo essa resposta por anos, decidi me envolver em um instrumento desse tipo para minha equipe como um projeto paralelo. Eu escrevo código desde os 10 anos, eu realmente gosto, posso fazer. E, portanto, mesmo quando liderava uma equipe grande, sempre tinha projetos para animais de estimação: escrevia jogos para os meus filhos e depois brincava com coisas interessantes. E eu realmente queria resolver esse problema. Imediatamente vi como era difícil, mas isso apenas me estimulou a trabalhar mais e a tomar uma decisão.
Em cerca de um ano de trabalho, consegui estabelecer as bases. E nessa época, a empresa onde eu trabalhava foi comprada por outra. E decidi seguir meu próprio negócio em vez de mudar para outro.
Em geral, minha motivação era trabalhar em algo que me interessasse no nível tecnológico. Eu não tinha ambição de me tornar um grande empresário. Era apenas uma questão de poder trabalhar no que me fascinava.
Eugene: Quando as pessoas de TI fundam empresas, geralmente não são os problemas tecnológicos que são o problema, mas o lado dos negócios. Você tinha experiência em cargos gerenciais - quanto isso ajudou? Você recomenda obtê-lo antes de configurar sua empresa?
Adam: Para começar, quero observar que não se deve confundir experiência de gerenciamento com negócios. Essas são coisas muito diferentes.
Ser um técnico é uma habilidade separada. Você atrai pessoas talentosas, as inspira a trabalhar duro, garante que elas permaneçam na sua equipe por muitos anos e o trabalho as cativa. Acredito que isso se deva principalmente a ser um bom engenheiro, e não relacionado a negócios.
Há pessoas que acreditam: desde que eu estou criando uma startup, eu serei CEO. Eu mesmo sei tudo, ninguém é meu conselheiro. Muitas pessoas pensam e falham. Mesmo aqueles que se tornaram CEOs muito bons. Você pode cometer qualquer erro dessa maneira.
Minha posição era completamente diferente. Eu imediatamente afirmei que não tinha ideia de como ser um CEO. Portanto, eu disse: vamos encontrar alguém que já saiba o que fazer e que tenha experiência relevante nesse assunto. E que ele seja CEO, e eu serei responsável pelo componente técnico.
Isso não garante que, nesse caso, tudo acabe, mas pelo menos não perco tempo cometendo erros que podem ser completamente evitados se uma pessoa experiente lidar com isso.
Antes que a empresa em que trabalhei por 8 anos fosse engolida, nosso CEO veio me contar sobre isso, começamos a pensar em planos para o futuro, e eu disse a ele no que já estava trabalhando naquele momento. Ele imediatamente se interessou, investigou a situação adequadamente, decidiu se juntar a mim e, desde então, nós dois trabalhamos na Applitools.
Repito, acredito que um engenheiro não é a melhor opção para uma startup. As chances não estão do seu lado. Vale a pena encontrar alguém que saiba o que está fazendo. Isso aumentará as chances de sucesso, embora não garanta nada.
Eugene: Entendi. E nessa situação, quando tarefas comerciais complexas estavam em outra pessoa, qual é a coisa mais suada para você?
Adam: Me fez suar ... Não quero entrar em detalhes sobre as dificuldades específicas do Applitools. Penso o seguinte: é ótimo que empreendedores iniciantes sejam muito ingênuos. Claro, esse é um clichê que todo mundo repete, mas até você fazer isso, você nem imagina a pressão, a incerteza, os altos e baixos psicológicos que você enfrenta na empresa. No mesmo dia, pode parecer que você conquistará o mundo e terá que despedir todos. Leva tempo para se adaptar a isso e começar a ver as coisas em perspectiva. Isso é muito difícil.
Bem, existem as dificuldades usuais - para o produto funcionar corretamente, para lidar com o componente de engenharia, trabalhando duro.
Mikhail Druzhinin ( xomyakus ): Parece que o desenvolvimento é uma parte simples. Ela é pelo menos previsível.
Adam: Exatamente.
Durante a primeira parte da vida de uma startup, quando não está claro se ele sobreviverá, não é fácil se encontrar em uma situação em que você acha que não tem mais dinheiro. Você já economiza pessoal para pagar salários aos funcionários. Aqueles a quem você convenceu anteriormente, com a ajuda de seu carisma, a deixar seus lugares e trabalhar para você por um salário mais baixo, simplesmente porque acreditam em você.
Mas mesmo quando você saiu do modo de sobrevivência, você tem um excelente produto e clientes; se você levantou fundos, tem investidores que aguardam o lucro de seus investimentos. Agora, há uma pressão constante para crescer e se desenvolver em um ritmo muito alto, e isso requer uma abordagem criativa e muito trabalho, porque você precisa lidar com esse crescimento.
Digamos que suas vendas totalizem X milhões por ano, e você se alegra com sucesso. Mas no próximo ano você tem que vender o dobro, como fazer?
Michael: Você disse sobre criatividade, o que exatamente se entende por isso?
Adam: Geralmente você pensa: eu fiz um ótimo produto, agora o mundo inteiro o usará.
A realidade é que o mundo está realmente muito ocupado. O mundo não tem idéia da sua existência. O mundo sempre tem 10 coisas diferentes para fazer e você não pode controlar onde estará nesta lista. E você não tem muito dinheiro para conhecer você. Dinheiro é o orçamento para publicidade, conferências, webinars, vendas pessoais. Tudo isso custa apenas uma tonelada de dinheiro.
E criatividade aqui significa pensar além dos estereótipos e usar abordagens que exigem pouco dinheiro e recursos. Applitools pode fazer isso, nos permite ganhar uma nova altura a cada ano. Mas toda vez que temos que ir além.
Michael: Exatamente, você precisa pensar mais amplamente. Percebo que muitos desenvolvedores e testadores pensam diretamente, eles veem apenas uma solução para o problema. Demora cinco meses e muitos recursos para teste. Eles são informados: você sabe, resta apenas um mês e todos nós vamos morrer. É aqui que a criatividade começa!
Adam: Sim, claro. Também há criatividade, que diz respeito ao produto em si: você sempre precisa se manter atualizado, fazer algumas coisas com mais rapidez e eficiência. Isso é desnecessário.
Eugene: Voltando ao tópico do crescimento: quantas pessoas hoje trabalham em Applitools e com que rapidez esse número está crescendo?
Adam: 110 pessoas trabalham hoje. E no início de 2018, éramos cerca de 20. O crescimento foi rápido, cinco vezes em alguns anos.
Eugene: Impressionante, sim. Mas foi difícil a esse ritmo de crescimento, quando muitas pessoas novas vierem, manter a cultura da empresa?
Adam: Ótima pergunta. Por experiência própria, percebi o quão importante é uma cultura empresarial bem definida. Parece que agora eu poderia fazer um relatório completo sobre esse tópico.
Para começar, o conceito de cultura corporativa em Israel não é muito desenvolvido. Se alguém está tentando fazer isso, a reação das pessoas é "oh, isso é besteira corporativa".
E para nós tornou-se um ponto de partida. O que eu decidi fazer com a Applitools como gerente de P&D? Olhando para a minha experiência em outras empresas, eu queria realizar um experimento: em geral, não posso diminuir o nível ao recrutar pessoas, basta ter excelentes especialistas e isso é tudo. Sem compromissos. Foi muito difícil.
Obviamente, os primeiros funcionários são aqueles que você conhece pessoalmente e que convenceu a ir até você. Mas depois disso, torna-se muito difícil crescer. Às vezes, leva de 6 a 8 meses para encontrar o funcionário certo.
Mas com o tempo, fica mais fácil, porque sua equipe já possui muitos especialistas fortes e conhece outros caras talentosos. E quando esses caras talentosos começam a procurar trabalho, eles veem os nomes dos funcionários da sua empresa - e há palestrantes sólidos de conferências internacionais, bem conhecidos na comunidade local. E então fica fácil: eles estão mais interessados em ir até você do que em alguma grande empresa.
Isso nos permitiu criar um processo de desenvolvimento exclusivo, que é até difícil de chamar de processo. Cada um de nossos desenvolvedores é responsável por tudo o que acontece. Não temos sprints, lançamentos planejados, nem exigimos que a equipe do produto forneça uma especificação completa.
Basta que você tenha uma idéia e seja responsável por sua implementação. Você mesmo está procurando as informações necessárias, você mesmo está procurando pessoas para ajudá-lo. Se você não sabe fazer algo, é responsável por aprender como fazê-lo.
Então, conseguimos criar algo especial. E quando atraímos uma grande quantidade de investimento e sabíamos que iríamos crescer, fiquei muito preocupado com isso. Como preservar nossa singularidade e não destruí-la durante o crescimento, quando a equipe de engenharia triplica?
A decisão foi consertar esse processo e definir claramente a cultura.
Comecei contratando um RH muito bom que trabalhava no Dropbox. De fato, ela reuniu toda a equipe do Dropbox e agora é considerado um dos melhores lugares para se trabalhar no mundo. Ela é muito experiente. Apenas nos sentamos e começamos a escrever um rascunho de nossa nova cultura.
Apresentamos nossas realizações aos Timlids, que rejeitaram completamente tudo isso. E eles ficaram com muita raiva. E então o diálogo começou. No processo de discussões com um grande número de comentários, fomos capazes de formular o que significa trabalhar em nossa empresa. Temos uma lista de valores com os quais todos os líderes de equipe concordaram.
Demorou vários meses, mas no final, quando apresentamos o resultado para toda a equipe, as pessoas o captaram imediatamente. Eles imediatamente sentiram que as palavras expressam exatamente por que trabalhar em nossa empresa é tão empolgante. Desta vez, recebemos um ótimo feedback.
Agora, religiosamente salvaguardamos esses valores e garantimos que, ao expandir o estado, não haja conflitos com eles. Isso nos ajuda a tomar decisões e manter a atmosfera, e espero que no futuro continue ajudando.
Eugene: Outro detalhe interessante sobre a Applitools: sua sede fica no Vale do Silício, mas a P&D está em Israel. Você pode dizer por que?
Adam: Antes de tudo, quando você inicia uma empresa, primeiro trabalha em casa, em um café perto de sua casa ou em viagem.
Minha empresa foi fundada e cresceu em Israel, porque há muita TI. E apenas por causa de nossa atividade em Israel, conseguimos nos espalhar para o resto do mundo. Quando uma grande empresa tem uma equipe em Israel, e eles usam algum tipo de ferramenta nessa equipe, como resultado, outras equipes nesta empresa (nos EUA, Grã-Bretanha, em outros lugares) veem isso. E se você usar essa ferramenta, seu produto terá repentinamente clientes estrangeiros, embora você não tenha se envolvido em marketing ou vendas no exterior.
Mas, a partir de algum ponto, você deseja estar mais próximo dos seus clientes. E, como uma empresa que atrai investimentos, você deseja estar mais perto dos investidores que possuem o valor apropriado. Os fundos israelenses trabalham principalmente com startups nos estágios iniciais, por isso é mais difícil obter grandes quantias delas. Ou seu investimento é menos útil, porque eles não têm conexões como fundos de risco dos Estados Unidos. Estar perto dessas pessoas e manter um relacionamento com elas é útil. Afinal, eu quero estar em uma situação em que os investidores querem investir em você e se voltar para você (e você concorda em aceitar dinheiro ou não), e não correr atrás deles.
Eu também quero estar mais perto do cliente e já temos dezenas de gerentes de vendas. Em que região dos EUA os negócios podem ser mais ativos conosco? Nosso escritório para esses funcionários está localizado lá, e esta também é a sede localizada ao lado dos investidores.
E a P&D, começando em Israel, permanece nela. Existem excelentes especialistas aqui e, ao mesmo tempo, manter uma equipe de engenheiros aqui é muito mais barato do que no Vale do Silício, e a competição por talentos não é tão alta. Por todas essas razões, tenho o prazer de permanecer aqui em Israel, chefiando o escritório de Israel. Isso é bom para mim e para a empresa. E meus dois parceiros estão em São Francisco há quase quatro anos.
Michael: E além da nota alta que você mencionou ao contratar, você usa outros truques para impedir que o nível de qualidade caia com um crescimento rápido?
Adam: Posso lhe dizer o que estou fazendo agora (talvez isso mude no futuro).
Eu acredito firmemente que um bom desenvolvedor cria software realmente funcional. Ele não cria esse software com o qual ele já terminou, mas outros ainda precisam testá-lo. É seu trabalho fazê-lo realmente funcionar. Eu não ligo como ele faz isso. Não importa se ele testa tudo manualmente a cada vez ou automatiza o teste. Eu realmente não ligo. Mas este é seu trabalho e sua tarefa.
Em geral, os caras que escrevem os algoritmos e o back-end estão mais satisfeitos com esse estado de coisas. Mas o front-end não é muito feliz, porque testar a interface do usuário é muito mais difícil do que a API com testes de unidade.
Há um problema com tudo isso. Obviamente, você provavelmente deve ter um desenvolvedor que entenda que ele deve testar tudo o que escreve. Ele sabe que esse é o trabalho dele e concordou. Mas quando você pergunta: "Está tudo bem testado?" E ele responde "Sim", essa é uma resposta muito subjetiva. Ele fez alguma coisa, mas pode ser 50% do que era suposto, e ele escreveu para si mesmo em um caderno "após o lançamento, será necessário voltar a isso".
E mesmo uma revisão de código não nos dará uma imagem completa do que está acontecendo, porque o funcionário que fez a revisão de código também estava ocupado. Ele diz que houve alguns testes e olhou para alguns deles - está tudo bem, vamos seguir em frente.
É por isso que tenho um diretor de qualidade (não o controle de qualidade).
Ele tem seu próprio time. Seu objetivo na empresa é garantir que tudo seja testado e que os desenvolvedores realmente cubram tudo. Simplificando, tudo sobre a qualidade deve ser testado. O diretor de qualidade tem muita autoridade e liberdade. Se ele me disser que algo não está coberto o suficiente, não empreenderemos nada até descobrirmos.
Sua equipe também ajuda a equipe de desenvolvimento a preencher as lacunas. Às vezes, os problemas são descobertos retrospectivamente quando a equipe correspondente está ocupada com alguns recursos e não tem tempo para trocar - a equipe do diretor de qualidade pode assumir essas tarefas.
E, no entanto, essa equipe é responsável pelos testes de ponta a ponta, afetando diferentes equipes e produtos. Essa é uma zona difícil para as equipes de engenharia cobrirem bem: elas podem descobrir o que são responsáveis por elas mesmas, mas quando algo afeta várias equipes ou produtos ao mesmo tempo, é difícil esperar que um deles lide com isso e se comprometa a responder por tudo. Não funciona assim. Portanto, o diretor de qualidade é responsável por esses testes complexos. Ele pode vir e me dizer: "Eu preciso de recursos de engenharia para isso", porque, em alguma parte do teste, ele pode não os ter.
É assim que funciona em geral, embora haja aspectos. Quando você trabalha em uma empresa de cinco pessoas, isso não importa, mas quando você tem um escritório em outra parte do mundo e há suporte, muitas comunicações surgem repentinamente em relação a cada versão. Se algo não funcionar como deveria, ou se algo novo aparecer, os clientes começarão a fazer perguntas de suporte. E se eles não souberem o suficiente o que mudou, não poderão responder bem.
Assim, parte do esforço foi dedicado à criação da comunicação: relatórios muito informativos que respondem a todas as principais perguntas sobre as mudanças e também me mostram que tudo foi testado. Se não tudo, então onde estão as lacunas? E para esses relatórios gerais, a equipe de qualidade também é responsável, garantindo que todos saibam o que está acontecendo. Isso proporciona à empresa uma sensação de alta qualidade - não apenas em termos de testes e cobertura.
Michael: Você faz uma ferramenta de teste, mas como você testa essa ferramenta? Como o Applitools é usado para testar o Applitools?
Adam: Todos os testes visuais e testes funcionais da interface do usuário no Applitools são feitos usando o Applitools. Obviamente, há algo que é testado manualmente e que não faz sentido testar pela interface do usuário e é coberto pela API. Mas com o componente visual, temos alimentos sólidos para cães.
O lançaremos várias vezes ao dia, mas não podemos fazê-lo para que o usuário veja as alterações. A equipe de desenvolvimento não deve alterar a interface do usuário sem passar pelo processo de notificação de suporte adequado, para que saiba responder a perguntas.
Portanto, geralmente acontece assim: se a interface do usuário for alterada, essas alterações serão desenvolvidas em um ramo separado ou mascaradas por um sinalizador, mas as alterações de back-end serão derramadas várias vezes ao dia. Temos lançamentos periódicos com grandes recursos visíveis na interface do usuário. Também temos um roteiro para preparar os clientes para as mudanças, estamos desenvolvendo uma campanha de mapeamento e escrevendo documentação para todas as alterações.
E parte desse processo - antes do grande lançamento, além do autoteste, testamos um pouco de tudo manualmente e também recorremos ativamente a testes de pesquisa. Na semana anterior ao lançamento, damos a versão final para o suporte, eles são ensinados a usar as alterações. Quando eles tentam tudo sozinhos, sabem tudo sobre as mudanças.
Esse é todo o chamado processo. Obviamente, existem algumas partes em que a interface do usuário é testada manualmente, embora basicamente sejam todos testes automáticos.
Eu realmente gosto (e também das empresas) de usarmos ativamente nosso próprio produto.Todos os membros da nossa equipe podem escolher qualquer tecnologia, mas ainda preferem a nossa. Também é ótimo sentir que você está fazendo algo que o mundo inteiro usa - empresas como Apple, Netflix, Dropbox, IBM.
Teste e IA
Eugene: desde que foi testado, vamos ao seu relatório. É chamado de "IA e teste", e isso pode ser interpretado de diferentes maneiras: tanto como "Vamos testar algo com a ajuda da IA", quanto como "Vamos testar a própria IA". Vamos primeiro destacar a IA: sobre o que se fala?
: — , AI. - AI, ? , — , , .
, — , AI. 80% , AI.
: «I» , . ?
: .
« , , , ». , AI . , , . .
, . , .
, — . , . , . , , .
AI . AI — , , , .
: AI AI?
: . Applitools Applitools, , AI-. , - AI AI.
, , « ». , , « ».
— , . — , , , .
: , Applitools, AI - — , ?
: . AI «» . , AI . , — :
- AI. Isso é muito importante.
- AI, , AI
- AI , -
— «self-healing tests». , UI , «», .
AI? . : , .
: , , . - — , . . - , , — «». , UI , , .
: , , , AI.
, , AI. , ! .
, , , , . - , . , , . , .
: . , - , . « », . «, , , - ».
: . . , , . , . , , . , . , , . , ?
, . , . , : 100%, . . , .
: Heisenbug , . , , ?
: . , , . , . , , .
, . . , , , , . . . , - , . Porque .
: . ?
: . , .
, . , - , . , — , , , , .
, . . , , , . , , .
, . , , . .
Heisenbug, 5 . Heisenbug , . , Heisenbug , , ( , ).