Фреймворк для регрессионного тестирования на основе WebDriver, Бордюг Иван
В этом докладе слушатели услышат об идее автоматизации для людей с разным уровнем знаний в этой области. Также слушатель увидит, как быстро могут создавать тестовые сценарии по технологии BDD, которые в будущем станут тестами для регрессионного тестирования. Доклад будет построен на уже существующей разработке докладчика, будут высветлены все позитивные и негативные стороны данного подхода, а также проблемы, которые удалось решить в процессе автоматизации и проблемы, с которыми столкнулась команда в процессе использования данного подхода.
Проблемы автоматизации крупных проектов: TestComplete, Дмитрий Марков
Дмитрий в своем докладе рассмотрит следующие вопросы:
Инструмент TestComplete. В чем сила?
Чем отличается автоматизация мелкого, среднего, крупного проекта?
Нужно ли что-то дополнительно делать при автоматизации крупного проекта?
Ошибки на начальных стадиях автоматизации
Раз говорим об ошибках, то также поговорим о том, как можно построить все так, чтобы этих ошибок избежать
Практические набитые шишки автоматизатора
“Обезьянье тестирование” в мобильных проектах, Роман Подолян
Хотите уйти от проторённых путей, проверить приложение самыми разнообразными, случайными последовательностями действий? Задать ему встряску чтобы проверить его на выносливость? Сделать с ним то, что даже не собирались? Отдайте его “обезьяне”.
Совершенный тестовый фреймворк, Андрей Иваровский
Идеальный тестовый фреймворк – миф или реальность? Поиск “философского камня”.
Расширяемость – как впихнуть “невпихуемое” и объять необъятное?
Кейворд-дривен, дата-дривен – извращения или путь к совершенству?
Многопоточность – мультиплексор или “каждой твари по паре”?
Обо всем этом, а также о кое-чем еще я расскажу в своем докладе.
The most common mistakes in the first game session and how to avoid themDevGAMM Conference
Vera Karpova, Analyst, devtodev
Vasiliy is going to give you some insights on the importance of the first game session. He’ll share some examples of mistakes that game developers usually make. You’ll learn how to avoid the same mistakes and increase efficiency of your first game session.
Курс молодого бойца-автоматизатора – как стать ветераном и остаться в живыхautomated-testing.info
Курс молодого бойца-автоматизатора – как стать ветераном и остаться в живых, Андрей Ребров
Сейчас, когда интерес к автоматизации более чем велик, многие команды задумываются над вопросом – нужна ли автоматизация им самим? Нужно ли TDD? Какой CI сервер поставить? Какую автоматизацию применить? Да и вообще, какой первый шаг сделать?
В своем докладе я постараюсь рассказать основные приемы внедрения автоматизации:
- постановка цели автоматизации
- первые шаги
- анализ и метрики
- коммуникации
Конечной темой доклада будет переход к DevOps.
Как мы админа увольняли, или тонкости организации корпоративной безопасности ...Ontico
Через пару недель после увольнения админа нам показалось, что пароли наших клиентов утекли.
Неприятная ситуация, которая требует оперативных и слаженных действий.
В этом докладе я расскажу подробности этой истории, и мы обсудим:
+ Как отработали с клиентами, утечка паролей к которым была установлена достоверно.
+ Работа с отделом К. Чего ждать, а чего не стоит.
+ Как отработали с клиентами, пароли которых потенциально утекли.
+ Как изменили внутреннюю структуру доступов и политики безопасности.
+ Какие организационные выводы были сделаны.
У всех на виду: нюансы Open Source разработкиCUSTIS
Открытый семинар для студентов в компании CUSTIS (20 марта 2014 года).
Лектор: Виталий Филиппов, ведущий веб-разработчик.
Аннотация: Главное в свободном ПО — это всеобщее сотрудничество. Но правильно его организовать может быть нелегко: и люди, и компании часто не понимают смысл открытости и те преимущества, которые она дает. Это приводит к проблемам взаимодействия — между проектом и пользователями, внутри проекта, между разными проектами... Как с ними справиться? Что нужно для успешности «открытого» проекта? Как организовать разработку с технической точки зрения? Какую лицензию выбрать? И как вообще устроен мир разработки свободного ПО, какие есть интересные Open Source проекты и зачем их создавать? Обо всем этом и пойдет речь на семинаре.
Видеозапись семинара: https://vimeo.com/90127303.
В поисках магической кнопки или как приручить SOAP UI, Михаил Дырда
Жил да был проект – чудище многосервисное. Многие тестировщики пытались одолеть его тестом умелым да скриптом надежным. Да только на месте каждого протестированного сервиса вырастало два новых, еще асинхроннее предыдущего. Пригорюнились богатыри-тестеры, поняли, что не одолеть им зверя коварного копипастом булатным. И решили открыть они рукописи древние – мануалы-священные. И познали они тайну заветную – тайну кнопки магической… Это только присказка, а доклад будет о том, какими средствами располагает SOAP UI для расширения функциональности и как знания об этом могут облегчить жизнь Вам и Вашим коллегам.
Фреймворк для регрессионного тестирования на основе WebDriver, Бордюг Иван
В этом докладе слушатели услышат об идее автоматизации для людей с разным уровнем знаний в этой области. Также слушатель увидит, как быстро могут создавать тестовые сценарии по технологии BDD, которые в будущем станут тестами для регрессионного тестирования. Доклад будет построен на уже существующей разработке докладчика, будут высветлены все позитивные и негативные стороны данного подхода, а также проблемы, которые удалось решить в процессе автоматизации и проблемы, с которыми столкнулась команда в процессе использования данного подхода.
Проблемы автоматизации крупных проектов: TestComplete, Дмитрий Марков
Дмитрий в своем докладе рассмотрит следующие вопросы:
Инструмент TestComplete. В чем сила?
Чем отличается автоматизация мелкого, среднего, крупного проекта?
Нужно ли что-то дополнительно делать при автоматизации крупного проекта?
Ошибки на начальных стадиях автоматизации
Раз говорим об ошибках, то также поговорим о том, как можно построить все так, чтобы этих ошибок избежать
Практические набитые шишки автоматизатора
“Обезьянье тестирование” в мобильных проектах, Роман Подолян
Хотите уйти от проторённых путей, проверить приложение самыми разнообразными, случайными последовательностями действий? Задать ему встряску чтобы проверить его на выносливость? Сделать с ним то, что даже не собирались? Отдайте его “обезьяне”.
Совершенный тестовый фреймворк, Андрей Иваровский
Идеальный тестовый фреймворк – миф или реальность? Поиск “философского камня”.
Расширяемость – как впихнуть “невпихуемое” и объять необъятное?
Кейворд-дривен, дата-дривен – извращения или путь к совершенству?
Многопоточность – мультиплексор или “каждой твари по паре”?
Обо всем этом, а также о кое-чем еще я расскажу в своем докладе.
The most common mistakes in the first game session and how to avoid themDevGAMM Conference
Vera Karpova, Analyst, devtodev
Vasiliy is going to give you some insights on the importance of the first game session. He’ll share some examples of mistakes that game developers usually make. You’ll learn how to avoid the same mistakes and increase efficiency of your first game session.
Курс молодого бойца-автоматизатора – как стать ветераном и остаться в живыхautomated-testing.info
Курс молодого бойца-автоматизатора – как стать ветераном и остаться в живых, Андрей Ребров
Сейчас, когда интерес к автоматизации более чем велик, многие команды задумываются над вопросом – нужна ли автоматизация им самим? Нужно ли TDD? Какой CI сервер поставить? Какую автоматизацию применить? Да и вообще, какой первый шаг сделать?
В своем докладе я постараюсь рассказать основные приемы внедрения автоматизации:
- постановка цели автоматизации
- первые шаги
- анализ и метрики
- коммуникации
Конечной темой доклада будет переход к DevOps.
Как мы админа увольняли, или тонкости организации корпоративной безопасности ...Ontico
Через пару недель после увольнения админа нам показалось, что пароли наших клиентов утекли.
Неприятная ситуация, которая требует оперативных и слаженных действий.
В этом докладе я расскажу подробности этой истории, и мы обсудим:
+ Как отработали с клиентами, утечка паролей к которым была установлена достоверно.
+ Работа с отделом К. Чего ждать, а чего не стоит.
+ Как отработали с клиентами, пароли которых потенциально утекли.
+ Как изменили внутреннюю структуру доступов и политики безопасности.
+ Какие организационные выводы были сделаны.
У всех на виду: нюансы Open Source разработкиCUSTIS
Открытый семинар для студентов в компании CUSTIS (20 марта 2014 года).
Лектор: Виталий Филиппов, ведущий веб-разработчик.
Аннотация: Главное в свободном ПО — это всеобщее сотрудничество. Но правильно его организовать может быть нелегко: и люди, и компании часто не понимают смысл открытости и те преимущества, которые она дает. Это приводит к проблемам взаимодействия — между проектом и пользователями, внутри проекта, между разными проектами... Как с ними справиться? Что нужно для успешности «открытого» проекта? Как организовать разработку с технической точки зрения? Какую лицензию выбрать? И как вообще устроен мир разработки свободного ПО, какие есть интересные Open Source проекты и зачем их создавать? Обо всем этом и пойдет речь на семинаре.
Видеозапись семинара: https://vimeo.com/90127303.
В поисках магической кнопки или как приручить SOAP UI, Михаил Дырда
Жил да был проект – чудище многосервисное. Многие тестировщики пытались одолеть его тестом умелым да скриптом надежным. Да только на месте каждого протестированного сервиса вырастало два новых, еще асинхроннее предыдущего. Пригорюнились богатыри-тестеры, поняли, что не одолеть им зверя коварного копипастом булатным. И решили открыть они рукописи древние – мануалы-священные. И познали они тайну заветную – тайну кнопки магической… Это только присказка, а доклад будет о том, какими средствами располагает SOAP UI для расширения функциональности и как знания об этом могут облегчить жизнь Вам и Вашим коллегам.
Опыт разработки SEO софта на примере FastTrust и ComparseRАлександр Алаев
Рассказываю про свой непростой опыт разработки десктопных программ на примере FastTurst и ComparseR. Всем, кто собирается заняться разработкой инди приложения или сервиса рекомендую.
Презентация делалась для JuJa конференции - Java конференции для (пре) Juniors: https://juja.com.ua/materials/jujacon-2017/
В ней
- описываются основные темы-вопросы, которые часто спрашивают на собеседовании на позицию Junior Java Developer;
- советы, что спросить собеседующего;
- как себя позиционировать, как относиться к собеседованию, как не бояться и как понять, что вам "туда".
16 HappyDev-lite'14 Серик Бейсенов. Введение в тестирование ПО
How to Put Automation Engineers Down
1.
2. ЧАСТО ЗАДАВАЕМЫЕ ВОПРОСЫ
Меня часто спрашивают:
• Как мне удалось достичь таких
высоких профессиональных
высот?
• Что нужно для того, чтобы шагнуть
на следующую ступень дао
автоматизации?
• Как грамотно и аргументированно
отказать человеку, просящему о
повышении?
• Как технично убедить кандидата в
сотрудники, что он ноль без
палочки, а потому должен быть
готов работать за копейки?
3. ТАК ВОТ…
Так вот, эти вопросы мы здесь обсуждать
НЕ БУДЕМ
Лучше поговорим о том, как гнобить
автоматизаторов.
4. ЗАЧЕМ?
Господи, мою презентацию
кто-нибудь
вообще
читает?
А ну-ка, быстренько отлистали на два слайда
назад!
5. КОГДА ГНОБИТЬ?
Перед тем, как ответить на вопрос, КАК гнобить автоматизаторов,
разберемся, КОГДА это лучше делать.
Ответ очевиден: когда они наиболее уязвимы. То есть на
собеседовании, или при аттестации, или на тренинге. При желании
можно это также делать во время code review или когда
консультируешь проектную команду.
6. КОГДА НЕ ГНОБИТЬ?
Не стоит гнобить автоматизатора, когда он занимается
своими прямыми обязанностями, то есть
автоматизирует что-нибудь.
Почему?
Да потому, что он в это время и так огорчен и пребывает
в подавленном настроении. Вероятнее всего, ему опять
подсунули отвратительно написанное и нетестируемое
приложение на тормозящем энвайронменте, а тесты
постоянно валятся по непонятным причинам или же
никто не хочет их запускать. Гнобление в такой момент
не принесет вам никакого морального удовлетворения:
от вас просто отмахнутся.
7. ВСЕ ЕЩЕ СОМНЕВАЕТЕСЬ?
«Но… я… не хочу никого гнобить», может
возразить кто-то. Все верно! Если не
считать клинических дебилов, средний
автоматизатор выглядит примерно как на
картинке справа. Это добрый, доверчивый
и бесконфликтный человек – примерно
как я – которому хоть бери да и
проставляй пиво, причем без какого-либо
повода, просто так.
Но как только начинаешь размышлять, тут
же задаешься вопросом: «А где же, блядь,
тогда МОЕ пиво? Автоматизатор я или
кто?». А отсюда всего один шаг до «Ах ты
ж сволочь, и ты туда же? Ну так получай!»
А в остальном автоматизаторов, конечно,
гнобить ни к чему.
8. AD HOC ЧМЫРЕНИЕ
Первый и самый очевидный способ –
так называемое ad hoc или спонтанно-
бытовое чмырение. Рассматривать его
в деталях мы здесь не будем, так как
оно не специфично для профессии
автоматизатора. Перечислим лишь
несколько базовых примеров.
9. AD HOC ЧМЫРЕНИЕ
• «Э-э, епта, иссуа-на! Деньги
есть?»
• «Что ты тошнишь? Водить
научись, мудила!»
• «Вон, Лидке муж норковое
манто купил, а ты чего добился,
неудачник?»
• «У Вас не хватает двух справок
и одной печати. Зайдите в
следующий четверг между 11 и
11:30».
10. ПРОФЕССИОНАЛЬНОЕ ГНОБЛЕНИЕ
Профессиональное гнобление – не
обязательно то занятие, за которое вам будут
платить деньги; скорее это гнобление по
профессиональному признаку. Но это не
означает, что профессиональным гноблением
можно заниматься спустя рукава и как попало.
И, естественно, если вы желаете загнобить
кого-то профессионально, вам необходимо
учитывать всю специфику избранной
профессии. В противном случае вы рискуете
получить закономерный ответ «Ну и что?»
11. ТЕХНИЧЕСКИЕ ПРИЕМЫ
Итак, перейдем к обсуждению чисто
технических моментов, которые могут вам
пригодиться на собеседованиях вне
зависимости от того, по какую сторону стола
вы сидите.
Многие из этих приемов можно применять и к
представителям других, менее полезных IT-
профессий, но мы будем рассматривать их
через призму автоматизации.
12. ПРИЕМ «ПОДУЧИ ПАТТЕРНЫ»
Описание
Этот прием прост, универсален и безотказен, так как по
итогам его применения всегда можно похлопать
собеседника по плечу со словами «Расти тебе еще надо,
парень, расти».
Нужно отметить, что автоматизаторы особенно падки на
паттерны – видимо, потому, что большинство лишь
недавно о них узнало. При этом дальше теоретических
рассуждений дело заходит редко, и на реальных
проектах 80% не использует ничего кроме синглтона, а
еще 10% не используют и его, потому что уже давно
стали менеджерами и код больше не пишут.
13. ПРИЕМ «ПОДУЧИ ПАТТЕРНЫ»
Как применять
• Спросите собеседника, какие паттерны проектирования он
знает. Ответ «Синглтон» не засчитывайте.
• Попросите описать отличия между двумя малоизвестными
паттернами, названия которых вы незадолго до этого
подсмотрели в книжке. Независимо от ответа снисходительно
хмыкните и скажите «Хорошо».
• Даже если собеседник перечислил все 23 канонических + еще
пару десятков паттернов, нарисовал диаграммы и написал на
бумажке примеры кода, спросите «А еще какие знаете?»
Независимо от ответа снисходительно хмыкните и скажите
«Хорошо».
• По итогам беседы порекомендуйте к изучению список из не
менее десяти паттернов. Паттерн «Синглтон» не указывайте.
14. ПРИЕМ «ПОДУЧИ ПАТТЕРНЫ»
Опасность
Отсутствует.
Даже если ваш собеседник по той или иной причине
ухитрился не облажаться, вы-то все равно смогли
показать, что знаете паттерны как минимум не хуже, а
на самом деле значительно лучше него.
Важно понимать, что реальное знание хотя бы одного
паттерна от вас вообще не требуется, нужно лишь
заучить их названия, чтобы потом умело вворачивать
в свою речь.
15. ПРИЕМ «ИНВЕРСИЯ»
Описание
Суть данного приема заключается в том, чтобы узнать, с каким
инструментарием человек работал, а затем раскритиковать, за
отсутствие опыта работы с другими инструментами той же группы.
Для убедительности запишем это в виде математической
формулы:
∀푨 ∈ 푵 найдется 푩 = ¬푨 такое, что 푨 ∪ 푩 = 푵 ^푨 ∩ 푩 = ∅,
где A – множество знакомых человеку вещей, B – множество
незнакомых, а N – общая их совокупность.
Прием построен на предпосылке, что от автоматизаторов
ожидается намного большая широта кругозора, нежели, к примеру,
от девелоперов. Закоренелого Java-программиста мало кому
придет в голову укорять за то, что он не знает Ruby или C#; с
автоматизаторами же это происходит сплошь и рядом.
16. ПРИЕМ «ИНВЕРСИЯ»
Как применять
Совершенно неважно, о какого рода инструментах или технологиях идет
речь. Самое главное – подробно расспросив, объяснить оппоненту,
какой он лошара:
• если работал на проектах с SVN и Perforce – мало опыта с более
современными системами типа Git;
• если с Git на «ты» – подтянуть коммерческие системы контроля
версий;
• если специализируется на UI-автоматизации – слабые знания в
области тестирования веб-сервисов;
• если знает WebDriver – побольше поработать с QTP, SoapUI, тулами
для нативных мобильных приложений и распознаванием образов;
• если являлся членом большой команды – был простым
пользователем фреймворка вместо того, чтобы разрабатывать
архитектуру;
• если в основном работал в одиночку – не командный игрок
Список можно продолжать. Идею, думаю, все поняли.
17. ПРИЕМ «ИНВЕРСИЯ»
Опасность
Если вам попался реально крутой спец, который знает и
пробовал все, что бы вы ни упомянули, существует
определенный риск того, что этот раунд гнобления
сведется к ничьей. Не унывайте, негодяй обязательно
сядет в лужу на чем-нибудь другом. Важно не давать
здесь слабины, потому что, если этот умник таки
преодолеет все заслоны, то гнобить вскоре будут уже
вас. Вам это надо?
Впрочем, риск этот представляет чисто академический
интерес. Автоматизатора, который знает ВСЕ, просто не
существует. Уж мэйнфреймы через терминальный
эмулятор он точно не автоматил!
18. ПРИЕМ «ПОКАЖИ КОД»
Описание
Собственно, названием приема все сказано. Запомните:
автоматизатора ВСЕГДА можно подловить на написании
говнокода или хаков. Одни искренне хотят, но не могут.
Другие могут, но искренне не хотят. Третьи и могут, и
хотят, но не получается по причине того, что:
• там уже и так наговнокожено;
• сама тестируемая система спроектирована через
жопу;
• нужно поддерживать всякую пакость типа IE 7;
• и так далее.
19. ПРИЕМ «ПОКАЖИ КОД»
Как применять
• Потребуйте у противника продемонстрировать примеры своего кода,
которые он считает особенно удачными.
• Если он начинает мямлить что-то про NDA, пригрозите, что будет хуже и
код придется писать на бумажке, а то и на доске.
• Спросите, почему вот здесь избран именно этот подход и какие могли
быть альтернативы. Необходимо задать вопрос таким тоном, чтобы
собеседник заволновался и начал думать, будто упустил из виду какую-то
элементарную деталь.
• Поинтересуйтесь, что та или иная конструкция представляет собой
синтаксически. Вы не поверите, сколько пишущих код людей даже не
задумывается, является ли то или иное слово ключевым в используемом
языке, или же это, скажем, вызов какой-то функции. Разочарованно
протяните: «Ну-у, это же самые основы».
• Высший пилотаж – это зачмырить за неверную (как вам кажется)
расстановку отступов или фигурных скобок, но так, чтобы человек и
впрямь почувствовал себя невеждой, а не подумал, будто вы
придираетесь по пустякам.
20. ПРИЕМ «ПОКАЖИ КОД»
Опасность
Их здесь две. Во-первых, разбирать чужой код – это
уныло, в особенности, если он действительно отстоен.
Тут уже вообще теряется какой бы-то ни было
спортивный интерес, и от гнобления перестаешь
испытывать всякое удовольствие.
Во-вторых, некоторые люди (очевидно, посетившие
слишком много тренингов по коммуникации) умеют
дистанцироваться и не воспринимать критику своего
кода как критику себя лично. Но мы ведь добиваемся
вовсе не этого! Гнобить код бессмысленно: он все равно
ничего не почувствует.
Так или иначе, применяя данный прием, следует помнить
одно простое правило: ад – это код других.
21. ПРИЕМ «ОЦЕНКА АНГЛИЙСКОГО»
Описание
Ни одно интервью не может считаться полным, если в нем
не будет предпринято попытки загнобить собеседника за
уровень владения английским. Ваш собственный уровень и
компетентность как экзаменатора не играют никакой роли.
Это тот случай, когда гнобить можно, даже заметно уступая
собеседнику в данной области. Уместно добавить сюда же
толику психологии – опять же, вне зависимости от вашей
компетентности в этой сфере.
Разумеется, если у вас на проекте/в компании приоритет
отдается, скажем, венгерскому, то методику необходимо
скорректировать под этот язык.
22. ПРИЕМ «ОЦЕНКА АНГЛИЙСКОГО»
Как применять
• Предложите собеседнику переключиться на английский язык, даже если
он у него (или у вас) на откровенно низком уровне. Попросите его
рассказать о себе/своих проектах/своих сильных и слабых сторонах.
Самых желторотых можно будет поставить на место уже на этой стадии,
так как многие и по-русски-то на подобные темы связно говорить не
умеют.
• Поставьте его в тупик каким-нибудь хитроумным вопросом с
подковыркой, например: «Why are you feel yourself as a senior
automatization engineer?»
• Отметьте, что словарный запас собеседника выдает неуверенность в себе
и слабость познаний в автоматизации, что и само-то по себе
непростительно, а для той позиции, на которую он претендует - и подавно.
• Безапелляционно изреките, что заявленного уровня языка вы здесь не
слышите, и максимум, на что может рассчитывать ваш оппонент – какое-
нибудь худосочное A2. От такого клейма он уже не отмоется никаким
ИЕЛТСом.
23. ПРИЕМ «ОЦЕНКА АНГЛИЙСКОГО»
Опасность
Бывают случаи, когда человек в принципе не владеет
иностранным языком, о чем сразу прямо и заявляет.
Можно, конечно, слегка пожурить его: «Ну что же Вы,
батенька, как же в наше-то время без языка?», но едва ли
он из-за этого почувствует себя по-настоящему
униженным. Что ж, чувствовать он может что угодно, но
промоушна ему при таком раскладе все равно не видать,
хе-хе-хе!
Еще одна опасность состоит в том, что сейчас в
тестировщики, и в автоматизаторы в частности, прут все
кому не лень, и всегда есть шанс нарваться на какую-
нибудь выпускницу иняза. За английский ее не
загнобишь, но зато у нее наверняка с паттернами беда.
Тут-то вы и развернетесь!
24. ПРИЕМ «БЕСКОНЕЧНОСТЬ»
Описание
Иногда попадаются особо настырные типы, к которым на кривой
козе не подъедешь: и паттерны-то они знают, и Оксфорд-то они
заканчивали, и технологии-то все изучили вдоль и поперек. Здесь-
то и приходит на помощь рассматриваемый прием.
Заключается он в том, чтобы задать собеседнику какой-нибудь
изощренный вопрос, а затем на каждой итерации уточнять условия
задачи, давая понять, что вы хотите услышать немного не то. При
этом иметь в виду какой-то конкретный ответ вовсе не
обязательно; главное – продолжать допытываться и создавать
видимость, будто вы пытаетесь подвести собеседника к какому-то
решению, а он все никак не допетрит, чего от него хотят.
Некоторые утверждают, будто подобные вопросы позволяют
посмотреть, как человек будет решать проблему, но на самом деле
их цель – запутать собеседника и продемонстрировать, какой он
на самом деле недотепа.
25. ПРИЕМ «БЕСКОНЕЧНОСТЬ»
Как применять
Простор для фантазии здесь на самом деле безграничен – не зря же прием
так называется! Приведем здесь лишь один из миллионов возможных
вариантов развития беседы.
А: Допустим, вы – тимлид, и заказчик просит вас срочно сделать POC
фреймворка по автоматизации их продукта с каким-нибудь необычным
интерфейсом. Ваши действия?
Б: Ну-у, я исследую рынок тулов автоматизации для данного интерфейса.
А: А допустим, есть только один подходящий тул, и тот коммерческий.
Б: Ну-у, я посчитаю затраты и экономию и выкачу цифры заказчику.
А: А допустим, заказчик наотрез отказывается платить за коммерческий тул.
Б: Ну-у, я рассмотрю возможность встраивания в интерфейс каких-нибудь
хуков для автоматических тестов.
26. ПРИЕМ «БЕСКОНЕЧНОСТЬ»
А: А допустим, девелоперы утверждают, что хуки встроить невозможно.
Б: Ну-у, тогда я попытаюсь использовать какое-нибудь низкоуровневое API
самого приложения.
А: А допустим, никакого API наружу не выставляется.
или
А: Ну хорошо, а вот допустим, объем работы слишком большой, чтобы
сделать все в одиночку, а уже вечер пятницы, и вся команда ушла домой.
Б: Ну-у, я обговорю с заказчиком перенос сроков сдачи.
А: А допустим, заказчик требует, чтобы все было сделано ASAP.
Б: Ну-у…
Как вы понимаете, этот обмен репликами можно продолжать до
бесконечности. Рано или поздно оппонент окончательно утратит нить ваших
рассуждений и перестанет понимать, чего вы от него добиваетесь. Вы же
потом можете сказать, что он недостаточно гибко мыслит в техническом
плане, да к тому же склонен уходить от ответственности и не умеет работать
с командой.
27. ПРИЕМ «БЕСКОНЕЧНОСТЬ»
Опасность
Данный прием следует с осторожностью применять
на юных и неопытных автоматизаторах, так как они
ломаются и уходят в ступор довольно быстро, так и
не позволив вам в полной мере продемонстрировать
собственное превосходство.
Если же ваш собеседник – тертый калач, он может
просто послать вас нахуй с такими вопросами, и
будет прав. Плюсов ему это, конечно, не прибавит, но
и загнобленным он себя опять-таки не почувствует, а
это никуда не годится.
28. МИКРОГНОБЛЕНИЕ
Помимо масштабных и многоходовых приемов унижения
соперника существует еще так называемое
микрогнобление. Оно включает в себя мелкие вопросы и
придирки, перемигивание с другими собеседующими,
гнусное хихиканье, обмен записками или сообщениями в
скайпе, пренебрежительный взгляд, перебивание и
многое другое.
Микрогнобление помогает заполнить паузы в разговоре
и не позволяет сопернику расслабиться. Также оно
может использоваться, чтобы сменить тему беседы и
перейти к следующему макроприему. Более того, один
удачно проведенный микрогнобительный выпад может
обернуть в вашу пользу уже, казалось бы, проигранную
схватку.
29. МИКРОГНОБЛЕНИЕ: ПРИМЕРЫ
Все эти приемы, опять же, никак не привязаны к профессии
автоматизатора, но если вам удастся ввернуть сюда
автоматизационную специфику, это пойдет вам только в плюс.
• Можете спросить, умеет ли оппонент считать ROI или метрики по
автоматизации. Их никто считать не умеет – а вернее, все делают это
по-разному, так что всегда остается возможность для маневра.
• Поинтересуйтесь, сколько фреймворков по автоматизации оппонент
нафигачил с нуля, или, как вариант, почему в его проекте
используется технология A, а не B. Очень многим приходится
заниматься поддержкой легаси-кода или же работать в составе
крупной команды – вы же сможете обвинить оппонента в
неопытности и архитектурной безграмотности.
• Время от времени отпускайте комментарии типа «Нда, жиденько» или
«А что ж архитектуру WebDriver не доучили?» Если подадите это с
правильной интонацией, человек заволнуется, даже если регулярно
контрибьютит в проект Selenium.
30. ПОБЕДА?
И вот, враг повержен, унижен, раздавлен и позорно бежит,
размазывая по щекам слезы, а вы стоите, гордо вскинув голову, и
пьете вино из его черепа. Но не стоит почивать на лаврах: рано или
поздно он обязательно вернется – если только не произойдет самое
страшное, что может случиться с автоматизатором, и он не станет
бизнес-аналитиком.
31. В ЗАКЛЮЧЕНИЕ
У кого-то может сложиться ощущение будто бы я призываю
гнобить автоматизаторов или даже сам этим занимаюсь.
Ничто не может быть дальше от
истины!
Однако отнюдь не все столь же добры и бесконфликтны, и
обязательно найдется мерзавец, которому захочется вас
загнобить.
Но теперь, когда вы вооружены ЗНАНИЯМИ, вы сможете
распознать все его гаденькие ПРИЕМЧИКИ, а в идеале и
обратить их против него самого – естественно, исключительно
с благими намерениями.