Есть популярная фраза «scratch your own itch»: если хочешь создать новый продукт, делай такой, которого тебе самому не хватает. В этом случае лучше всего понимаешь, как сделать его хорошо.
Адам Карми остро ощущал нехватку инструмента для визуального тестирования, который помог бы людям не ломать глаза в поисках поехавшей вёрстки. А в итоге он создал такой инструмент, приспособив для этого AI, и стал одним из сооснователей компании Applitools. Звучит как работа мечты: когда борешься со знакомой тебе болью, то ощущаешь, что меняешь мир к лучшему. Но с какими сложностями сталкивается айтишник, когда от него зависит судьба целой компании?
А поскольку сам инструмент Applitools тоже надо тестировать, Адам узнал многое о тестировании проектов с AI. Уже завтра на Heisenbug он расскажет о том, как это делать, и его доклад попадёт в открытую трансляцию — так что все желающие смогут посмотреть его в прямом эфире. А пока что мы расспросили его на обе темы: и о том, каково создавать компанию, и о вещах, связанных с тестированием и AI.
Стартаперская жизнь
Евгений Трифонов (phillennium): Вы много лет были наёмным сотрудником, а потом решили создать стартап. Как это случилось и что послужило толчком?
Адам: Моё предыдущее место работы — это компания, связанная с информационной безопасностью. Я работал там 8 лет. Думаю, вы можете себе представить, сколько UI в продукте для обеспечения безопасности. Огромное количество логов, диаграмм, графиков, запросов и оповещений. И вокруг всего этого было очень много неочевидного UI.
Всё усложнялось ещё и тем, что данный UI был переведён на 6 языков и поставлялся под пятью разными брендами. Чтобы протестировать его весь вручную от начала до конца во всех вариациях, требовалось что-то около недели. Там было 20 тестировщиков, которые занимались этим каждую итерацию. То есть, если для релиза надо провести несколько итераций, то это требует релизного цикла по меньшей мере в 2-3 месяца.
Поэтому в те годы, когда я там работал, мне недоставало решений для данной проблемы. Конечно, у нас занимались автоматизацией. Selenium тогда был ещё молодым продуктом, мы использовали его, но он не покрывал UI. Я постоянно объяснял проблему тогдашним вендорам (HP, Microsoft и IBM) и просил о её решении. Ответ всегда был один: это невозможно. Чтобы проверять, что интерфейс выглядит как должен (а не просто «функционирует как должен»), всегда нужны будут ручные тестировщики.
Годами слушая этот ответ, я решил в качестве стороннего проекта заняться таким инструментом для моей команды. Я с 10 лет пишу код, мне это очень нравится, у меня это получается. И поэтому, даже когда я руководил большой командой, у меня всегда были пет-проекты: я то писал игры для своих детей, то просто возился с интересными штуками. И мне очень захотелось решить эту проблему. Я сразу увидел, насколько она непростая, но это лишь подстегнуло меня работать усерднее и прийти к решению.
Примерно за год работы у меня получилось заложить основы. А к этому времени компания, где я работал, оказалась куплена другой. И я решил заняться собственным делом вместо того, чтобы переходить в другую.
В общем, моя мотивация была в работе над чем-то, что интересовало меня на технологическом уровне. У меня не было амбиций стать великим бизнесменом. Дело было просто в возможности работы над тем, что меня захватывало.
Евгений: Когда айтишники основывают компании, зачастую для них сложными оказываются не технологические проблемы, а бизнес-сторона. У вас был опыт работы на управляющих позициях — насколько он помог? Рекомендуете ли вы получить его, прежде чем создавать свою компанию?
Адам: Для начала хочу отметить, что не стоит путать опыт руководства с бизнесом. Это очень разные вещи.
Быть техлидом — это отдельный навык. Ты привлекаешь талантливых людей, вдохновляешь их на упорную работу, делаешь так, чтобы они оставались в твоей команде долгие годы и работа их увлекала. Я считаю, это во многом связано с тем, чтобы быть хорошим инженером, и не связано с бизнесом.
Есть люди, которые считают: раз я создаю стартап, то я и буду СЕО. Я сам всё знаю, никто мне не советчик. Многие так думают и проваливаются. Даже те, которые стали очень неплохими СЕО. На этом пути ошибиться можно в чём угодно.
Моя позиция была совершенно другой. Я сразу заявил, что понятия не имею, как быть CEO. Поэтому я сказал: давайте найдём кого-то, кто уже знает, что делать и у кого есть релевантный опыт в этом деле. И пусть он будет СЕО, а я буду отвечать за техническую составляющую.
Это совсем не гарантирует, что в этом случае всё получается, но я хотя бы не потрачу время на совершение ошибок, которых вполне можно избежать, если этим будет заниматься опытный человек.
Перед тем, как компанию, в которой я работал 8 лет, поглотили, наш СЕО пришёл ко мне сообщить об этом, мы начали думать о планах на будущее, и я рассказал ему, над чем к тому моменту уже работал. Он сразу заинтересовался, исследовал как следует ситуацию, решил примкнуть ко мне, и с тех пор мы оба трудимся в Applitools.
Повторюсь, я считаю, что инженер — не самый лучший вариант СЕО для стартапа. Шансы будут не на вашей стороне. Стоит найти того, кто знает, что делает. Это повысит шансы на успех, хотя ничего и не гарантирует.
Евгений: Понял. А в этой ситуации, когда сложные бизнес-задачи были на другом человеке, что сильнее всего попотеть вас?
Адам: Заставило попотеть… Не хочу подробно вдаваться в тему сложностей, специфичных для Applitools. Я думаю вот что: здорово, что начинающие предприниматели очень наивные. Конечно, это уже клише, которое все повторяют, но пока ты сам этим не занимаешься, даже не представляешь тех давления, неуверенности, психологических взлётов и падений, через которые проходишь с компанией. В один и тот же день может казаться и что вы завоюете мир, и что тебе придётся всех уволить. Нужно время, чтобы адаптироваться к этому и начать видеть вещи в перспективе. Это очень сложно.
Ну и есть обычные сложности — чтобы продукт как следует работал, разобраться с инженерной составляющей, усердно работая.
Михаил Дружинин (xomyakus): Звучит, как будто разработка — это простая часть. Она, по крайней мере, предсказуема.
Адам: Именно.
Во время первой части жизни стартапа, когда непонятно, выживет ли он, непросто оказываться в ситуации, когда вы обнаруживаете, что у вас больше нет денег. Вы уже залезаете в свои личные сбережения, чтобы выплатить зарплаты сотрудникам. Тем, которых вы ранее убедили с помощью своей харизмы уйти со своих мест и работать на вас за меньшую зарплату просто потому что они верят в вас.
Но даже когда вы вышли из режима выживания, у вас отличный продукт и клиенты, если вы привлекали средства — у вас есть инвесторы, которые будут ждать прибыли от своих вложений. Теперь есть постоянное давление расти и развиваться в очень высоком темпе, а это требует творческого подхода и большой работы, ведь вы должны справиться с этим ростом.
Допустим ваши продажи составили X миллионов за год, и вы радуетесь успеху. Но в следующем году вы должны продать вдвое больше, как это сделать?
Михаил: Вы сказали про творчество, что именно под этим понимается?
Адам: Обычно вы думаете: я сделал отличный продукт, теперь весь мир будет им пользоваться.
Реальность такова, что на самом деле мир очень занят. Мир понятия не имеет о вашем существовании. У мира всегда есть 10 разных дел, и вы не можете контролировать, где вы окажетесь в этом списке. А ещё у вас нет больших денег на то, чтобы о вас узнали. Деньги — это бюджет на рекламу, конференции, вебинары, личные продажи. Всё это стоит просто кучу денег.
И творчество здесь означает мыслить за пределами стереотипов и использовать подходы, которые потребуют мало денег и ресурсов. У Applitools получается так делать, это позволяет нам каждый год брать новую высоту. Но приходится каждый раз выходить за рамки.
Михаил: Точно, нужно мыслить шире. Я замечаю, что многие разработчики и тестировщики мыслят очень прямолинейно, видят только один вариант решения задачи. Требуются пять месяцев и много ресурсов для тестирования. Тут им говорят: знаете, остался всего месяц, а затем мы все умрём. Вот тут-то и начинается творчество!
Адам: Да, конечно. Есть ещё креативность, которая касается самого продукта: всегда нужно держать руку на пульсе, делать некоторые вещи быстрее и эффективнее. Это само собой разумеется.
Евгений: Возвращаясь к теме роста: сколько людей сегодня работает в Applitools, и насколько быстро это число растёт?
Адам: сегодня работают 110 человек. А на начало 2018 года нас было что-то около 20. Рост был стремительным, в пять раз за пару лет.
Евгений: Впечатляет, да. А сложно ли было при таких темпах роста, когда приходит множество новых людей, сохранять культуру компании?
Адам: Замечательный вопрос. На своём опыте я понял, как важна хорошо определённая культура компании. Кажется, я теперь мог бы сделать целый доклад на эту тему.
Начну с того, что понятие корпоративной культуры в Израиле не очень-то развито. Если кто-то пытается этим заниматься, у людей реакция «ой, это корпоративный булшит».
А для нас это стало стартовой точкой. Что я решил сделать с Applitools как управляющий R&D? Оглядываясь на свой опыт в других компаниях, я захотел провести эксперимент: вообще никак не позволять опускать планку при наборе людей, брать только отличных специалистов и всё. Никаких компромиссов. Было очень сложно.
Конечно, первые сотрудники — те, кого знаешь лично и кого убедил перейти к тебе. Но после этого становиться очень сложно расти. Иногда нам требуется 6-8 месяцев, чтобы найти подходящего сотрудника.
Но с течением времени становится легче, поскольку в твоей команде уже довольно много сильных специалистов, а они знают других талантливых ребят. И когда эти талантливые ребята начинают искать работу, они видят имена сотрудников твоей компании — а там сплошные спикеры международных конференций, хорошо известные в местном сообществе. И тогда становится легко: им интереснее пойти к тебе, чем в какую-то большую компанию.
Это позволило нам создать уникальный процесс разработки, который даже сложно назвать процессом. На каждом из наших разработчиков лежит ответственность за всё, что происходит. У нас нет спринтов, запланированных релизов, мы даже не требуем от продуктовой команды предоставления полной спецификации.
Достаточно того, что у тебя есть идея, и ты отвечаешь за её воплощение в жизнь. Сам ищешь нужную информацию, сам ищешь людей себе в помощь. Если ты не знаешь, как что-то делать, ты отвечаешь за то, чтобы научиться этому.
Так что у нас получилось создать нечто особенное. И когда мы привлекли большой объём инвестиций и знали, что будем расти, я был очень обеспокоен этим. Как сохранить эту нашу уникальность, а не разрушить её в ходе роста, когда инженерная команда утроится?
Решением стало зафиксировать этот процесс и чётко определить культуру.
Я начал с того, что нанял очень хорошего HR, которая работала в Dropbox. По сути, она собрала всю команду Dropbox, и теперь он считается одним из лучших мест для работы в мире. Она очень опытная. Мы просто сели и стали писать черновик нашей новой культуры.
Мы представили наши наработки тимлидам, которые полностью всё это отвергли. И очень разозлились. А затем начался диалог. В процессе обсуждений с большим количеством фидбека нам удалось-таки сформулировать, что значит работать в нашей компании. У нас получился список ценностей, с которыми все тимлиды были согласны.
Это заняло несколько месяцев, но в итоге, когда мы представили результат всей команде, люди его тут же подхватили. Они сразу ощутили, что слова выражают именно то, почему работать в нашей компании так увлекательно. В этот раз мы получили отличный фидбек.
Теперь мы религиозно охраняем эти ценности и следим за тем, чтобы при расширении штата не возникали противоречия с ними. Это помогает нам в принятии решений и поддерживать атмосферу, и надеюсь, в будущем продолжит помогать.
Евгений: Ещё одна любопытная деталь про Applitools: штаб-квартира у вас в Кремниевой долине, но R&D при этом в Израиле. Можете рассказать, почему так?
Адам: Прежде всего, когда вы основываете компанию, на первых порах вы работаете из дома, из кафе рядом с домом, или в путешествии.
Моя компания была основана и росла в Израиле, потому что здесь много IT. И просто благодаря нашей активности в Израиле нам удалось распространиться на остальной мир. Когда у какой-то большрй компании есть команда в Израиле, и в этой команде используют какой-то инструмент, в итоге другие команды в этой компании (в США, Великобритании, ещё где-то) видят это. И если этот инструмент делаете вы, у вашего продукта внезапно появляются зарубежные заказчики, хотя вы не занимались за рубежом ни маркетингом, ни продажами.
Но с какого-то момента вы хотите быть ближе к вашим клиентам. А ещё как компания, которая привлекает инвестиции, вы хотите быть ближе к инвесторам, у которых есть соответствующие суммы. Израильские фонды в основном работают со стартапами на ранних стадиях, поэтому у них сложнее получить большие суммы. Или от их инвестиций меньше пользы, потому что у них нет таких связей, как у венчурных фондов из США. Находиться рядом с этими людьми и поддерживать отношения с ними полезно. Хочется ведь быть в ситуации, где инвесторы хотят вкладывать в тебя и сами обращаются к тебе (и ты соглашаешься принять деньги или нет), а не ты бегаешь за ними.
Ещё хочется быть ближе к клиенту, а у нас уже десятки менеджеров по продажам. В каком регионе США у нас может активнее всего идти бизнес? Там-то у расположен наш офис для этих сотрудников, и ещё это штаб-квартира, находящаяся рядом с инвесторами.
А R&D, начавшись в Израиле, в нём и остаётся. Здесь есть отличные специалисты, и при этом держать здесь команду инженеров гораздо дешевле, чем в Кремниевой долине, а конкуренция за таланты не такая высокая. По всем этим причином я с удовольствием остаются здесь, в Израиле, возглавляя израильский офис. Это хорошо и для меня, и для компании. А двое моих партнёров уже почти четыре года в Сан-Франциско.
Михаил: А помимо упомянутой вами высокой планки при найме, используете ли вы ещё какие-то хитрости, чтобы при стремительном росте не падал уровень качества?
Адам: Могу рассказать, что делаю сейчас (возможно, в будущем это изменится).
Я свято верю в то, что хороший разработчик делает по-настоящему работающее ПО. Он не создаёт такой софт, с которым он уже закончил, но другим ещё надо его тестировать. Это его работа — сделать так, чтобы действительно работало. Мне не важно, как он это сделает. Не важно, тестирует он всё каждый раз вручную или автоматизирует тестирование. Мне реально всё равно. Но это его работа и его задача.
В целом, ребята, которые пишут алгоритмы и бэкенд, более довольны таким положением дел. А вот фронтендеры не очень рады, потому что тестировать UI гораздо сложнее, чем API с юнит-тестами.
Со всем этим есть одна проблема. Безусловно, у вас скорее всего может быть разработчик, который понимает, что должен тестировать всё, что пишет. Он знает, что это его работа, и согласился на это. Но когда вы спрашиваете «Всё хорошо протестировано?», а он отвечает «Да», это очень субъективный ответ. Что-то он сделал, но это может быть 50% того, что предполагалось, а в блокнот он себе записал «после релиза нужно будет вернуться к этому».
И даже код-ревью не даст нам полной картины происходящего, потому что сотрудник, который делал код-ревью, тоже был занят. Он говорит, что там были какие-то тесты, и некоторые из них он просмотрел — всё нормально, давайте двигаться дальше.
Именно поэтому у меня есть директор по качеству (а не QA).
У него есть своя команда. Его цель в компании — убедиться, что всё протестировано и разработчики действительно охватили всё. Проще говоря, всё, что касается качества, должно быть протестировано. У директора по качеству много полномочий и свободы. Если он говорит мне, что что-то недостаточно покрыто, мы не будем браться ни за что, пока не разберёмся с этим.
Его команда также помогает команде разработки восполнять пробелы. Порой проблемы обнаруживаются ретроспективно, когда соответствующая команда занята какой-нибудь фичей и у них нет времени переключиться — тогда команда директора по качеству может взять на себя эти задачи.
И ещё эта команда ответственна за end-to-end-тестирование, затрагивающее разные команды и продукты. Это та зона, которую инженерным командам сложно покрыть хорошо: они могут разбираться с тем, за что сами отвечают, но когда что-то затрагивает сразу несколько команд или продуктов, то сложно ожидать, что кто-то из них с этим справится и возьмётся отвечать за всё. Это так не работает. Поэтому за такие сложные тесты отвечает директор по качеству. Он может прийти и сказать мне «мне нужны инженерные ресурсы для того-то», потому что для какой-то части теста у него их может не быть.
Вот так это и работает в целом, хотя тут существуют аспекты. Когда работаешь в компании из пяти человек, они не имеют значения, но когда у вас офис в другой части планеты, и там поддержка, в связи с каждым релизом внезапно возникает много коммуникации. Если что-то не работает как должно или если появилось что-то новое, клиенты начинают задавать вопросы поддержке. И если там не знают достаточно хорошо, что поменялось, то не смогут хорошо отвечать.
Так что часть усилий брошена на создание коммуникации: очень информативные отчёты, которые отвечают на все главные вопросы об изменениях, а также показывают мне, что всё было протестировано. Если не всё, где тогда остались пробелы? И за такие общие отчёты тоже отвечает команда качества, удостоверяясь, что все знают, что происходят. Это обеспечивает в компании ощущение высокого качества — не только в отношении тестирования и покрытия.
Михаил: Вы делаете инструмент для тестирования, а как вы тестируете сам этот инструмент? Насколько Applitools применяется для тестирования Applitools?
Адам: И всё визуальное тестирование, и функциональное тестирование UI в Applitools делается с помощью Applitools. Конечно, есть и то, что тестируется вручную, и то, что нет смысла тестировать через UI и покрывается через API. Но с визуальной составляющей у нас сплошной догфудинг.
Мы релизим на прод несколько раз в день, но нам нельзя делать это так, чтобы пользователь видел изменения. Команда разработки не должна менять пользовательский интерфейс без прохождения должного процесса оповещения поддержки, чтобы там знали, как отвечать на вопросы.
Поэтому обычно происходит так: если меняется UI, эти изменения разрабатываются в отдельной ветке или маскируются флагом, а вот изменения бэкенда заливаются по несколько раз за день. У нас есть периодические релизы с большими фичами, заметными в UI. Ещё у нас есть roadmap, чтобы подготовить клиентов к изменениям, мы разворачиваем мапкетинговую кампанию и пишем документацию для всех изменений.
И часть этого процесса — перед большим релизом, помимо автотестом, мы немного тестируем всё вручную, а ещё активно прибегаем к исследовательскому тестированию. На неделе перед релизом отдаём финальную версию поддержке, их учат пользоваться изменениями. Когда они пробуют всё сами, то знают об изменениях все.
Вот и весь, так называемый процесс. Конечно, есть некоторые части, когда UI тестируется вручную, хотя в основном это всё автоматическое тестирование.
Мне очень нравится (и компании, думаю, тоже), что мы активно пользуемся собственным продуктом.Каждая наша команда может выбрать любую технологию, но всё равно предпочитают нашу собственную. А ещё здорово ощущать, что ты делаешь что-то, чем пользуется весь мир — компании вроде Apple, Netflix, Dropbox, IBM.
Тестирование и AI
Евгений: раз речь дошла до тестирования, перейдём к вашему докладу. Он называется «AI and testing», а это можно истолковать по-разному: и как «Давайте протестируем что-то с помощью AI», и как «Давайте протестируем сам AI». Давайте сначала расставим точки над AI: о чём доклад?
Адам: Основная его часть — о том, как тестировать AI. Если части вашего продукта недетерминированные и в каком-то роде содержат AI, как вам тестировать этот продукт? Есть разные методы и практики, которые стоит использовать — чтобы, скажем так, повысить вероятность качества.
Если останется время, то в финальной части доклада поговорю и о противоположном — том, где в тестировании уместно использовать AI. Но 80% доклада о том, как тестировать AI.
Евгений: Понятие «АI» не самое строго определённое, разные люди используют его для разных вещей. Как оно определяется в контексте вашего доклада?
Адам: Первый слайд там как раз об этом.
Мне вспоминается определение «машинные действия, которые в случае, если бы их выполнял человек или животное, мы назвали бы требующими интеллекта». В таком случае получается, что AI можно имплементировать всего лишь несколькими строчками кода. Если мы научим собаку лаять один раз на пересекающиеся треугольники и два раза на непересекающиеся, все согласятся, что она гениальна. А эту задачу можно детерминированно решить в четыре строчки кода.
Но затем я показываю, как по мере усложнения задачи алгоритмический подход перестаёт хорошо работать. Говорю про традиционное машинное обучение, его преимущества и недостатки.
А затем про то, где и его уже не хватает — и перехожу к глубинному обучению. Показываю, как это всё усложняет разработку. Людям это кажется магией, а магию сложно тестировать. И при том, что это даёт преимущества, это приносит и много сложностей.
И от разных способов имплементировать AI мы переходим к разным способам его тестировать. Так что для меня AI — это всё, что эмулирует интеллект, от простых алгоритмов и до глубинного обучения, но я в докладе углублюсь в глубинное.
Евгений: А применяется ли AI для тестирования AI?
Адам: Нет. Хотя мы и используем Applitools для тестирования Applitools, но тестируем так фронтенд, а не AI-часть. И я не слышал, чтобы кто-то другой тестировал AI с помощью AI.
Не хочу слишком влезть в детали и в процессе пересказать весь свой доклад, но главной проблемой статистических моделей является то, что это «чёрный ящик». И к тому же, когда вы переобучаете их, они превращаются уже в другие «чёрные ящики».
Цель тестирования — знать, что ты сделал. А если тестировать один чёрный ящик другим ящиком — непонятно, что произошло, тест мог пройти, но уверенности ни в чём нет.
Евгений: Помимо визуального тестирования, которым занимается Applitools, применим ли AI для ещё каких-то областей тестирования — например, безопасности?
Адам: Да. AI полезен для «конвейерных» задач. У меня сформулированы три общих критерия, когда AI применим для решения задачи. Они попадут в завершающую часть доклада, если на них останется время — но расскажу их уже сейчас:
- У вас есть достаточно данных для обучения AI. Это очень важно.
- Что бы вы с этой задачей сейчас без AI, получается настолько неэффективно, что даже неудачный AI уже улучшит ситуацию
- Если AI ошибётся, это не приведёт к чему-то слишком плохому
Давайте возьмем банальный пример — «self-healing tests». Идея в том, что при изменении UI тест может сам разобраться с этим, не «сломавшись», а самостоятельно выучив новые локаторы.
Почему это легко сделать с AI? Потому что данная ситуация подходит по всем трём критериям. Первый: у вас есть все данные, потому что это ваш тест.
Второй: ваш текущий процесс, где этой проблемой занимаются люди, оставляет желать лучшего. Там человек выбирает какой-то определённый локатор — лучший, но один. Но можно по этому локатору находить элемент и автоматически сохранять для него десять локаторов в базу данных. При последующих прогонах часть из них окажется какими-то динамическими данными, то есть ерундой, по которой элемент на самом деле не найти — но мы тогда можем их просто отбросить и оставить «выжившие». И затем, когда UI поменяется, вместо одного локатора у нас будет целый ряд, по которому можно найти элемент и обновить его локатор.
Третий критерий: в худшем случае, когда сделать это не получится, вы просто окажетесь в том состоянии, в котором были бы без всякого AI.
В общем, если все три критерия подходят, вы можете использовать AI. Если же они не подходят, даже не пытайтесь! Это будет кошмар.
Вот в нашем случае сложность в том, что компании, использующие наш продукт, ожидают, что вы найдём каждый баг до единого. Если что-то ускользает, винят нас. Но добиться уровня, когда не ускользает ничего, крайне сложно. Это требует многих лет работы, экспертизы и громадных объёмов данных.
Михаил: Это интересно. Часто в жизни я вижу, что какой-то процесс очень далёк от идеала, и его можно в некоторой степени улучшить. Но люди не хотят «в некоторой степени», они хотят из ничего сразу перейти к идеалу. И говорят «знаете, если точный результат не гарантировать, то в чём смысл, мы тогда будем по-прежнему делать всё вручную».
Адам: А смысл есть. Это может сэкономить кучу времени. Например, у вас есть логи об упавших тестах, где записаны все ошибки. Одни из ошибок важны, другие не очень. Но известно, как стоит читать эти логи, тут есть паттерны. В первую очередь стоит смотреть на то, что случается нечасто или выглядит неординарно. Это может не дать полностью точной картины, но вы увидите важную часть сразу же, а не спустя два часа изучения. Она может помочь, так?
А если не поможет, тогда уже можно изучать весь лог по порядку и в итоге найти. То есть вы тогда просто окажетесь в той точке, с которой начинали. И есть много таких примеров, повышающих продуктивность: не на 100%, но с экономией часов работы каждый день. Так что это явно того стоит. Есть много подобных возможностей везде, где встречается повторяющаяся работа.
Евгений: на Heisenbug будет ещё и кейноут Инго Филиппа о том, не украдут ли боты у тестировщиков работу. Но судя по сказанному выше, мы можем уже сейчас смело сказать, что не украдут?
Адам: Конечно. Я бы никогда не доверил машине полностью тестировать всё за меня, не понимая, что вообще она делает. Это не значит, что у ботов и тому подобных вещей нет ценности. Она есть, но ценность эта дополнительная к человеческой деятельности, а не заменяющая её.
И к этим методам прибегают в случаях, когда они не требуют дополнительных трудозатрат. Приведу пример. В принципе, конкретный проект можно довести до такого состояния, когда краулер, сделанный специально для этого проекта, сможет проходиться по всему приложению от начала до конца. Это даже не требует громадных ресурсов. Но никто так не делает. Зато все радуются, когда появляется какой-то универсальный бот для любого проекта, который можно просто подключить. Почему? Потому что не требуется ничего делать.
Михаил: У меня напоследок философский вопрос. А что для вас качество?
Адам: Ух. Глубокий вопрос, мне обычной такой не задают.
Думаю, в конечном счёте я хочу доставилять клиентам восторг моим продуктом. Когда я слышу, что кто-то при его использовании недоволен, меня это печалит. Я действительно ощущаю, что это — моё искусство, моё создание, и если опыт людей с ним оказывается не таким, как я задумал, то это недостаток качества.
Это главное, но есть и другие уровни. Есть также качество в самом коде. Как он выглядит, какие технологии использованы, насколько всё современно, уровень работающих над ним людей. И всё, что не соответствует моему утопическому представлению о компании и инженерной команде, в этом отношении не соответствует моим стандартам качества.
И что до уровня удовольствия клиентов, то это очень измеряемая штука. Если они пользуются продуктом всё активнее, то вы понимаете, что в конечном счёте справляетесь хорошо. Это главное.
Адам Карми выступит с докладом в первый день Heisenbug, 5 декабря. Сейчас все билеты на Heisenbug уже распроданы, однако доклад можно будет увидеть в открытой трансляции. А для тех, кто заинтересовался Heisenbug и не хочет ограничиваться этим, есть ещё и платная трансляция, в которой будут доступны все доклады (а не только первый зал в первый день, как у открытой).
