Так

http://bormor.livejournal.com/713165.html

ЧСХ, бгг.
И да, моя бабушка рассказывала сказки о шайтане.

Рутина

Открыл для себя git rebase и git merge --squash.

Из минусов - история коммитов стала унылой.

Альбом: office

Lesson 132

Чтоб оценить, насколько яростно у нас все происходит — из последнего:

Выставили на всех серверах непрерывной интеграции в /etc/postgresql/9.1/main/postgresql.conf параметр
fsync=off

Слово Канеру

Автоматизируйте тесты используя программные интерфейсы.

В настоящее время многие продукты имеют программные интерфейсы (публичное API), которое может быть использовано для тестирования. Другие продукты, могут иметь скрытые API, которые могут быть открыты, если вы попросите. Просите.

Открытый API документируется как часть продукта. Они сильно не меняются и эта стабильность делает их привлекательными для автоматизации тестирования. Закрытый API может быть очень полезен, но необходимо выяснить, насколько он подвержен изменениям.

Не зная о подобных альтернативах, многие автоматизаторы фокусируются на видимой части ПО — на GUI. С сожалению, часто это самый сложный интерфейс для автоматизации. Практически любой программный интерфейс проще, надежней и стабильней. В предыдущих лекциях мы обсуждали некоторые проблемы, связанные с автоматизацией через GUI и предлагали стратегии борьбы с ними. Но лучший выход — избежать их вообще. Программные интерфейсы, как правило, обеспечивают стабильность. Также они способствуют обнаружению и изоляции дефектов.

Когда мы смотрим на усилия тестировщиков во многих программных продуктах, мы наблюдаем корреляцию между наличием программного интерфейса и сложностью тестовых наборов. Программные интерфейсы включают API, интерфейс командной строки, COM интерфейс, HTTP и другие. Вам нужно знать жаргон и технологии. Не ожидайте, что ваши программисты предоставят вам учебник. Чем дольше вы ждете, тем меньше времени. Если вы всерьез занимаетесь автоматизацией, вы изучите это сами или найдете кого-нибудь, кто сможет помочь.

Часто автоматизаторы GUI тестирования считают, что должны изучить в деталях технологии GUI. С технической точки зрения GUI сложнее других интерфейсов. Так или иначе, вам придется изучить технологии GUI по мере использования тестов. Это ваш выбор, а мы считаем, что GUI должен быть последним в списке.

Вот небольшой пример. Многие люди просят у нас совета по автоматизации инсталлятора с использованием инструмента графического тестирования. Лучший подход, как правило, выбросить инструмент. Большинство инсталляторов имеют скриптовый интерфейс, обеспечивающий лучший доступ. InstallShield, например, популярная система установки, используемая в инсталляторах многих продуктов. Многие тестировщики не знают, что они могут работать с InstallShield с возможностью записи выбранных опций установки. Они сохраняются в файл. В дальнейшем возможна автоматическая установка с помощью этого файла указывающая все настройки. Это просто, это дешево, этот файл легко читать и редактировать. Это экономически эффективный способ автоматизации установки (см. «Создание скрытой инсталляции» http://support.installshield.com/kb/display.asp?documents_id=101901).

Но вы не тестируете GUI! Сфокусируйте свое внимание на том, где автоматизация может помочь в большей степени. Иногда можно эффективно автоматизировать тестирование GUI, иногда нет. Не допускайте предвзятого мнения о том, что автоматизация выглядит как ограничивающая вас.


Опыт Douglas Hoffman'а похож на наш. «Наиболее драматичный успех я имел, когда работал с исвестным пакетом настольных издательских систем. Его движок был скрыт и продукт воспринимался с точки зрения WYSIWYG GUI. Поскольку планировалась полная переработка пользовательского интерфейса, мы избежали автоматизации тестирования GUI. Вместо этого мы использовали public API для функционального тестирования и вручную тестировали GUI. Мы зарепортили много дефектов (в основном обнаруженных при автоматизации тестов) и смогли гораздо легче отделять проблемы с GUI от проблем с функциональностью»

Paul Szymkowiak не согласен. «Мой опыт отличается. Я обнаружил, что многие GUI более стабильны, чем программные интерфейсы, в контексте елей автоматизации тестирования. Это происходит потому, что GUI виден клиентам, использующим напечатанные учебные материалы и руководства. Таким образом, существуют расходы, связанные с изменениями GUI. Я работал с рядом руководителей проектов, которые просили «заморозить» пользовательский интерфейс задолго до заморозки программного интерфейса. Многие программные интерфейсы плохо документированы. Я также нашел много багов в программных интерфейсах с более низким порогом юзабилити, чем это обычно ожидается от пользовательского интерфейса».

Lesson 131

Слово Канеру

Используй стандартные скриптовые языки

Если ты тестировщик, который хочет узнать больше о программировании, мы предлагаем тебе изучить Perl, Visual Basic, TCL, JavaScript, Python или любой другой скриптовый язык, который, как ты знаешь, используют программисты вокруг тебя (Sweeney 2001). Некоторые скриптовые языки, такие как Unix shell или DOS batch files будут вокруг тебя еще долго. Скриптовые языки высокого уровня оптимизированы для удобства использования , а не производительности.


Многие программисты более продуктивны и совершают меньше ошибок, если они используют скриптовые языки программирования, а не системные языки, такие как C/C++ или Java.

Скриптовые языки подходят для большинства задач автоматизации тестирования. Ты можешь использовать их для генерации данных, доступа к интерфейсам программ, проверки результатов.

Многие инструменты тестирования имеют встроенный скриптовый язык. Другие разумно используют стандартные языки. Третьи создали свои проприетарные языки, которые мы называем vendorscripts. Мы не видим веских причин для их использования и отмечаем ряд проблем:

Они делают кодирование сложным Многие из них основаны на стандартном языке вроде С. Если ты можешь читать С, то ты, возможно, сможешь прочесть C-based vendorscript. Но ты потратишь чертовски много времени на написание правильного кода Эти vendorscripts не поддерживают многие стандартные идиомы языка и делают написание кода таким жи простым, как письмо на английском без использования буквы N.
Они сложны для изучения Сложность поиска тренинга или книги по vendorscripts делает их сложными для изучения. А если вы изучите такой язык, то все равно вы не сможете использовать его для чего-либо еще. Поэтому сложно мотивировать людей на изучение таких языков. А если вы ищете людей, то будет трудно найти людей, уже знающих этот vendorscripts.
Они мешают сотрудничеству тестировщиков и программистов Мы рекомендуем тестировщикам и программистам продукта сотрудничать с проектами по автоматизации тестирования. Это становится сложным, если вы используете разные языки.
Сложнее опираться на работу других Библиотеки, предоставляемые vendorscripts жалки по сравнению с теми, что доступны для стандартных языков. Это значит, что вы не сможете опереться на чужую работу, но будете тратить время на поддержку рудиментарных библиотек.
Мы рекомендуем избегать инструментов с vendorscripts. Больше и больше инструментов тестирования в настоящее время используют стандартные языки. Если вы вынуждены использовать инструмент с vendorscripts, постарайтесь уменьшить количество кода на этом языке и перенести столько обработки, сколько можно в отдельную языковую среду(Более подробно см. Pettichord, 2001a).

Ня!

Раз

Альбом: randompics4lj

Два

Альбом: randompics4lj

Три

Альбом: randompics4lj

Четыре

Альбом: randompics4lj

Lesson 130

Народ, кто-нибудь использорвал Robot Framework? Написал на нем пару сотен тестов? При этом делал русские алиасы?

Вы когда-нибудь просили программистов сделать ревью кода?
Если да, то были ли у них эмоции, отличные от бля, чо это за текст? Что с ним делать вообще?

Я к тому, что Robot Framework это все зашибись, но неплохо бы говорить с программистами на одном языке.

Ну то есть гораздо проще отдать программисту проект с mvn install verify, классами, интерфейсами и surefire, чем описание на корявом русском. Не?

Я понимаю, что алиасы для аналитики и прочих ПМов, но это все пока вы пишете первые тридцать тестов. А затем начинаются оптимизации, рефакторинги и тесты тянет показать какому-нибудь приличному программисту.
Обратно же, найденные баги править именно кодерам, а не аналитикам.

Слово Канеру

Отделите генерацию тестов от их выполнения.

Одна их стратегий, поддерживающая отделение тестовых данных от выполнения кода - data-driven автоматизация (Lesson 127). Это отделение облегчает генерацию тестов и имеет ряд преимуществ:

- Тесты будут простыми для понимания и просмотра
- Ты сможешь использовать разные инструменты тестирования или IDE для генерации и выполнения тестов.
- Отдельный генератор тестов легче проверить. Если вы используете случайные методы, вы должны знать, that random number algorithms packaged with programming environments are often weak. Данные могут быть не такими случайными, как вы ожидали. Проверьте их правильность(Park and Miller 1988). Kaner и Vokey (1984) обеспечили тщательное тестирование набора параметров из генератора случайных чисел, который легко запрограммировать в Java или любом другом языке, работающем с высокоточной целочисленной арифметикой (wtf?).
- Тесты легче воспроизвести, если данные сгенерированы предварительно. Мы видели тестовые скрипты, изменяющие тест каждый раз, когда они запускались. Если вы не можете генерировать данные предварительно, необходимо принять другие меры для обеспечения повторяемости, такие как логирование данных или использование зерен для генерации. Оснащение тестовых скриптов такими механизмами усложняет их.
- Вы сможете быстрее сообщать о найденных ошибках. Первая мысль программиста — поставить под сомнение ваш инструмент.
- Различные специалисты смогут сфокусироваться на разных аспектах автоматизированного тестирования с помощью любого инструмента или языка, который они считают подходящим.

Lesson 129

Аццкое нагрузочное тестирование.

Альбом: bug

Слово Канеру

Используй автоматизацию для генерации входных данных.

Общие методы программирования могут помочь в нескольких ситуациях:
Создание больших файлов
Создание большого количества входных данных
Создание тестовых стендов Проводя нагрузочное тестирование, нужно начать с предварительной загрузки базы данных реальным количеством данных. The amount of data available to be searched impacts database retrieval.
Генерация случайных данных Это часто используется в data-driven и keyword-driven тестах.
Охват всех комбинаций входных данных Используй алгоритмы для генерации перестановок и комбинаций.

Однако предыдущие методы, оставляют неопределенными ожидаемые результаты. Это может повлечь большие трудозатраты на их ручную проверку. Следующие техники являются особенно ценными, так как они уменьшают количество необходимых проверок, обеспечивая определенный уровень покрытия и указывают ожидаемые результаты.

Покрытие всех пар репрезентативных выборок и классов эквивалентности Мы видели исследование, предполагающее, что большую часть ошибок взаимодействия можно найти, если вы проверите все комбинации пар ключевых значений классов эквивалентности. Мы обсуждали комбинации пар в третьей части, «Техники тестирования», в секции How to Do Combination Testing используя тестирование пар."

Покрытие взаимодействия логических условий Когда переменные взаимосвязаны техника всех пар не работает. Рисуток причинно следственных связей является более надежным подходом (Elmendorf 1973 and Bender 1991). Мы не использовали эту технику, а только слышали о успехах и недостатках его применения.

Создание тестовых сценариев на основе модели состояний Техника модели состояний серьезно исследуется и дает значительные результаты. Модель состояний или граф переходов определяет состояния системы (документ изменен или не изменен; соединение с базой есть или его нет; транзакция прошла или нет) и возможные переходы между ними. Квалифицированные практики способны создавать интересные и полезные модели без большого количества состояний. Другие потратили большое количество усилий на эту технику, создали массивные модели, но так и не получили никакой пользы. Это называется проблемой взрыва состояний. Наиболее успешные практики часто видят успешные результаты использования такой модели в короткие сроки. Если вы используете этот метод, то мы предлагаем вам создать модель состояний для одной или двух функций, создать тесты, а затем пересмотреть модель. Если эта работа не окупится на этой же неделе, то, вероятно, этот подход не стоит дополнительных инвестиций (Robinson 1999 and Nyman 2000).

Доброты пост

Недавно Юлия рассказала, что тестирование должно добавлять ценность.

Но на ютуб видео заливали явно недоброжелатели, пруф:

Альбом: bug

Сам доклад настоятельно рекомендую к просмотру, особенно последнюю минуту:

Lesson 128

Ну нравятся мне красивые картинки, которые рисует git.
Вот это два автотестера нарисовали меньше чем за неделю.

Альбом: bug

Слово Канеру

Автоматизация тестирования основанная на ключевых словах делает создание тестов простым для не-программистов.


Этот вид автоматизации базируется на автоматизации, основанной на управлении входными данными, но только таблицы содержат директивы (ключевые слова), а не данные.

Во-первых, подход требует общего фреймворка, включающего поддержку запуска тестов, а также библиотеки для настройки, анализа результатов и отчетности. Эта информация будет использована для всех keyword-driven тестов.

Во-вторых, вам придется создать задачу, инкапсулирующую работу с функциональностью продукта. Определить для каждой фичи свою функцию, которая будет использована для тестирования и включить ее в библиотеку. Опишите стартовое состояние, в котором функция применима и конечное состояние, к которому приведет ее выполнение. Это позволит сказать, какие последовательности функций являются допустимыми и избежать ошибок.

В-третьих, добавьте поддержку работы с электронными таблицами. Используя декларации, интерпретируйте первую колонку как имя функции. Следующие колонки будут аргументами функции. Выполните функцию с аргументами, и перейдите к следующей строке.

Результат - keyword-driven автоматизация. Этот подход позволяет избежать сложной логики в тестах(Lesson 125). Так как тесты хранятся в таблицах, они легко читаются не-программистами. Because the tasks to be used and tested are all that the tester specifies, он сможет сконцентрироваться на тестах, а не на языке программирования.

В условиях, которые требуют большого количества не-программистов для создания автоматизированных тестов, мы считаем, что этот подход - одно из лучших решений.
Один из недостатков подхода в том, что вы не сможете написать тест, пока нет поддержки нужных директив. Их определение и реализация становится важной.

Рецензент Hans Buwalda сообщает: «Keyword driven подход может стать хорошей основой. Тем не менее, за много лет работы я узнал, что тестирование и автоматизация тестирования остается очень сложной областью, требующей привлечения опытных специалистов, чтоб сделать ее правильно»
Мы видели хорошие результаты работы с такой техникой. Она позволила существенно сократить время на автоматизацию. Также некоторые команды сообщали нам, что такой подход неустойчив и требует слишком много накладных расходов.
Более подробно у этой технике можно узнать у Pettichord (1996) и у Buwalda и Kasdorp (1999).

Самокопания пост

Пару дней назад мне провели "сеанс продвинутого психоанализа".


У меня спрашивали вопросы, я рассказывал, что по этому поводу думаю.
Основной вопрос звучал так:

- Чего ты, черт-побери, хочешь?
- Бабу рыжую! И пива ящик! Сотни нефти, пиццот респектов и уважуху в СНГ.
- А потом?
- А потом мы выйдем на европу!
- Давай сразу на европу, чо обламываццо?
- Да чей-та ссыкотно.
- Не ссы, боец. Понимаешь, ведь лучше взять лишь правый берег Влатвы, чем Бржези, Тегов и Семице (ну то есть половина большой цели это сильно круче, чем десять целых мелких). Мы же хотим захватить европу?
- Ну, да, хотим...

Я, до сих пор не избавившийся от школьной привычки, искал правильные ответы и пытался в них поверить.

Психоаналитиками это было замечено, сделаны соответствующие выводы.
Рассказали о целеполагании и целедостижении. Не сколько рассказали, сколько натолкнули на соответствующие мысли.

Озарение на меня, как водится, снизошло пост-фактум, хотя пару дней был серьезнейший кризис жанра в частности и экзистенцаильности вообще.

От меня упорно добивались наличия большой цели не просто так, а чтоб сделать очевидным выбор средств.

А ответ - не правильный, а мой ответ - я тогда подумал, и даже эфемистично высказал:
- Девушку-шатенку и десять литров алкоголя.

Надо было развить мысль, что мол не буквально, а в метафизическом смысле.

И что цель у меня таки есть, только она не может быть описана в терминах "достижения". Она, эта самая цель - не точка на карте и не место в рейтинге. А вполне себе состояние. Ощущение.

Но мне, блядь, хочется жить честно. Наверное, я идиот.
Я работаю там, где мне не в падлу прийти в шесть, а уехать последней лошадью.
Я живу там, где мне не серут на голову всякие пидарасы.

В этот момент понимаешь
Что живешь в мире, ортогональном ценностям психоаналитиков.
Что я не привязан к месту, но это вот конкретное мне вполне нравится.
Что я не ракета, чтоб меня нацеливать.
Что сэкономить 50Mb памяти firefox реально интересней, чем просто получить новый сервер.
Что на одном любопытстве можно уехать дальше, чем основательно нацелившись.
Последнее я лично проверю.

Тем не менее, специалистам человеческой души от меня огромнейший респект, вы заставили меня подумать.
Через пару месяцев у меня абонемент к штатным мозгоправам, сдается мне, предстоит большой разговор.

P.S. Если психоаналитики читают этот пост (что вряд ли), то большой привет Наташе.


Гм. Насчет сегодня.
Футбол я не люблю, но на крыше посидели славно.

Sir Terence David John Pratchett

Unseen Academicals ок.

I must not lie. I must gain worth. I must not lie. I must gain worth. - гребаный лейтмотив не только книги.

Lesson 127

Плоско мыслю.
Недавно меня спросили, ну если коротко, то "какой в тебе смысл?"
Я вот такую картинку нарисовал примерно:

Альбом: bug

То есть вроде как компенсирующий механизм супротив засилья багов.
На меня посмотрели, как на juniora, и нарисовали такое:

Альбом: bug

Как-то так.

Слово Канеру

Подход к автоматизации, ориентированный на управление входными данными облегчит проведение большого количества вариантов тестов.


Для тестирования различных входных данных и их комбинаций с общей процедурой используйте управление входными данными.

Организуйте входные и ожидаемые выходные данные в таблицу. Каждая строка представляет собой тест. Затем создайте тестовую процедуру, читающую строки из таблицы, вводящую данные и проверяющую результат. Таблицы удобны для хранения тестовых данных. Они делают простым создание тестовых данных. Многие инструменты тестирования и среды программирования позволяют получить доступ к табличным данным без особых проблем. Они могут получить доступ к данным в формате электронных таблиц или в формате текстового файла, который может быть легко экспортирован (.CSV files).

После того, как вы создали такую тестовую процедуру, вы сможете использовать ее снова и снова для выполнения новых тестов. Такая техника является мощным инструментом для тестирования продуктов, чей жизненный цикл подразумевает наличие большого количества различных входных данных. Используй более сложный вариант, keyword-driven авоматизацию для поддержки тестов, состоящих из различных последовательностей и путей.
Стратегия автоматизации, основанная управлении данными позволяет работать непрограммирующим тестировщикам. Автоматизаторы создают тестовую процедуру, тестировщики создают тестовые данные. В некоторых случаях сложно автоматизировать проверку результатов тестирования. Научите тестовую процедуру собирать результаты и представлять их в контексте входных данных, для дальнейшего анализа вручную.

Автоматизация основанная на управлении входными данными — обычное явление. Многие инструменты тестирования поддерживают эту технику (Dwyer and Freeburn 1999).

Lesson 126

Возможно, я потом оформлю пост на софтваре-тестинг, но ответьте сейчас.
Те, кто кто использует webdriver, сколько RAM у вас ест тестирующая система (если параллелите, то на каждый поток)?

У меня каждый поток:
firefox: 200m физической, 700m виртуальной.
Собственно ТС: 100m физической, 300m виртуальной

Использовал столбцы RES и VIRT команды top


Слово Канеру

Не создавайте тестовые библиотеки только для того, чтоб избежать повторения кода.


Стандартная мудрость программистов рекомендует избегать повторения кода с помощью размещения кода в функциях, которые вызываются из каждого места, где был повторяющийся код. В автоматизации такой подход часто приводит к проблемам. Противоположный подход, который оставляет код на месте, называется открытым кодированием.

По своей природе тесты содержат много повторений. Вы тестируете одну фичу в разных сценариях, в разном порядке или в комбинации с другими фичами.

Если вы просто переместите повторяющийся код, вы получите мешанину в библиотеках и функции, содержащие последовательности задач, следующих друг за другом, даже если они являются частями различных задач. Соглашения по именованию, анализ результатов, стратегия тестирования также могут оказаться в беспорядке. Функции сложно называть осмысленно, а в связи с этим сложно делать выводы о их назначении.
Тесты, использующие такие библиотеки, сложно просматривать, сложно отлаживать и сложно чинить. Мы просматривали тестовые наборы с мешаниной из библиотек несколько раз. Результаты никогда не были хорошими.
Автоматизация тестирования влечет за собой много повторяющегося кода. Полезные библиотеки требуют более строгих принципов проектирования, чем простое избегание повторяющегося кода. Задача полезной библиотеки состоит в инкапсуляции пользовательских задач, уделяя особое внимание начальному и конечному состоянию функции. Но и этот подход не всегда оправдан. В таких случаях следует придерживаться стандартов открытого кодирования.

Lesson 125

Бгг, Пеар.
Хорошая штука foursquare, просто замечательная.
Помогает заполнить несколько минут в кафе, пока не принесли заказ, стандартный юзкейс.

Или вот буквально только что коллеги метнулись до Самары и обратно, так мы прям все вместе по чекинам следили за движением паравоза, ага.

Слово Канеру

Избегайте сложной логики в ваших сценариях тестов

Условная логика в сценариях тестирования делает тесты сложными для понимания и повышает вероятность наличия в них ошибки. Еще более проблематичным становится изменение кода в throw catch блоках.

Возможно, вам понадобится сложная логика для настройки теста, для проверки вывода или для обработки управляющих элементов интерфейса. Вынесите эту логику в отдельные функции. Вы сможете протестировать эти функции отдельно (что есть хорошо) и ваши тесты будут простыми для просмотра (и это тоже хорошо).

Сохранение тестов линейными поможет сфокусироваться на цели теста (еще одна хорошая вещь), а не на поддержке автоматизации. Когда тесты слишком сложны, в них появляются ошибки. Сохраняйте тесты простыми. Сохраняйте тесты линейными.

Lesson 124

На курсе ТАУ, что вел сам Страшинин, помнится, он нам советовал вбить себе в голову, что между автоматизированной и автоматической системой есть огромнейшая разница.

Ну, и как водится, со временем все отчетливей понимаешь, как велика разница. И как жаль, что она есть. И как печально сейчас знать, что многие считают системы, мне подведомственные, автоматическими. В то время как они всего лишь автоматизированные, да.

Слово Канеру

Не скупитесь на проектирование автоматизированных тестов.

Представьте, что разумный и наблюдательный человек будет тестировать вручную. Представьте, что автоматизированных тестов нет вообще.
Вот список проблем, с которыми вам, возможно, придется столкнуться при разработке тестов:

- Обеспечьте корректную настройку тестов
- Опишите ожидаемый результат
- Опишите возможные ошибки и побочные эффекты
- Обеспечьте восстановление после потенциального сбоя
- Предотвратите взаимное влияние тестов

Документируйте дизайн тестов, чтоб другие люди, использующие ваши тесты, понимали, что вы имели в виду.

Интересно, ящетаю.
Раз: http://kholodova.livejournal.com/41478.html
И два: http://test-failed.blogspot.com/2012/06/re.html by Nikita Makarov

Процитирую пост полностью:

1. "Когда я стану менеджером, я буду все делать правильно, а не так как они".
А как делают они? А почему это неправильно ? А сколько проектов закрыл ты ? А сколько закрыл вовремя ? А они сколько закрыли ?
А может быть они все-таки все делают правильно? Или ты не видишь всей той картины исходя из которой они принимают непонятные тебе решения ?
В бизнесе нет границы между добром и злом, раз ты обслуживаешь бизнес - то привыкни переходить ее по 5 раз на дню, и не делай из этого трагедии.

2. "Незаменимых людей нет".
Зато есть временно незаменнимые и те проблемы которые эти люди закрывают в купе с экспертизой в их голове.
Это обычно выясняется после двух недель работы того человека, которого ты нащел на замену "незаменимого".

3. Кадровый фашизм.
Если ты на собеседовании не уверен в том, что этот человек тебе подходит - не бери.
Любой неправильный человека в команде или даже просто коллективе - влияет на нее гораздо хуже, чем не вовремя выплаченная зарплата.
Лучше 5 раз отфутболить правильных людей, чем 1 раз взять неправильного.

4. Прозрачность.
Быть прозрачным - выгодно. Будь прозрачным!!!

5. Делай сервис.
Люди не хотят думать о том, что ты делаешь и уж совсем мало народу хочет разбираться в технической части.
Люди хотят решения своих проблем. Просто стань человеком, который хотя бы даст надежду на то, что он их решит.
Если ты действительно будешь решать проблему предоставляя сервис - ты станешь "незамениым" (см. пункт 2) и скорее всего менеджером.

6. Мало кто понимает для чего нужно тестирование, еще меньше для чего нужна автоматизация, совсем единицы готовы дать ему действительно роль QA.
Печальный факт, но он стоит одним из столпов в нашей отрасли, и пока от него никуда не убежать.
Тестировщиков воспринимают как обезьян с клавиатурой, автоматизация - приходит на ум менеджерам только тогда, когда становится понятно, что пахать это поле дальше с помощью лошади и деревянного плуга - верный путь камикадзе.
А уж о том чтобы поставить где-то во всей цепочке поставки какуйю-то бригаду покемонов, которые будут давать контур отрицательной обратной связи чуть ли не весь процесс в целом - вообще разрыв шаблона.

7. Если ты QA, то свыкнись с тем, что в глазах остальных ты будешь выглядеть "мудаком, которому еще и зарплату платят".
Особенно если ты действительно QA, а не monkey tester которого назвали QA.

8. У тебя есть только те люди, которые есть.
Ситуации "выгоняй кого хочешь, нанимай кого зочешь" - бывают, но крайне редко. Учись работать с теми которые уже есть.

9. Лучшими инструментами разработки, тестирования, планирования, проектирования и всего чего угодно являются: ручка, бумага, голова.
С помощью них были сделаны все великие вещи, приняты самые главные решения.
Аутлуки, органайзеры, джиры, вики - это все мусор - если ты родил идею и способ ее реализации, то все это тебе вряд ли понадобится.

10. Учись, потому что ты вечный студент.
Твои знания будут дешеветь каждую единицу времени.
Извини, у нас такая отрасль. В ней нет экспертов как в бухгалтерском учете, юриспруденции и прочих отраслях.
Экспертом по какой-то технологии может быть только тот человек, который эту технологию создал.
Учись - это единственный способ избежать инфляции тебя как специалиста.

Как я провел лето

Я вернулся.
Гг, мало кто заметил, но я таки уезжал, на неделю.

И ближе к финалу моей прогулки меня позвали на экскурсию к тестировщикам Юлии.
Сказали, мол, когда-нибудь приходите посмотреть, то да се.
- А я уже неподалеку, может на днях забегу?
- А давай.
- А пажалуйста.


Офис нашел быстро, глубоко эшелонированную охрану из трех человек, двух вертушек и одного телефона прошел успешно.
Ко мне вышла Наталья и сказала, что скоро ко мне подойдет Наталья, которая уже тестировщик и будет рассказать.

Я присел на диванчике около ресепшена и радовался зачотнейшим ништякам:

Альбом: office

У меня один такой в детстве был, "веселый повар" назывался.

Подошла Наташа (ее вот тут можно найти, легко узнать, симпатичная такая), увела в чей-то свободный кабинет.

Спросила:
- А правда, что вы что-то там под селениум пишете? И как оно, работает?
- Работает, - сказал я, - что селениум, вот раньше мы под jwebunit писали, там браузер запускался сугубо в воображении, вот там интересно было, да. Дайте-ка листочек, я вам все нарисую!

А дальше мы час с лишним рисовали на листочках схемы и процессы, Наталья рассказывала мне, что мы живем не по заветам Баранцева и объясняла, как надо тестировать правильно, рисуя свою диаграммку. На что я отвечал, что и мы не лыком шиты, отбирал листок и карандаш и рисовал очередную порцию кубиков и стрелочек.

Чесно-чесно, если бы не мой поезд-через-час и не внезапно появившаяся Наташина Юлия Нечаева (мы вроде бы ее кабинет заняли) то мы б часа четыре разгоняли за подходы, процессы и прочие фреймворки. Приятно пообщаться с человеком, который любит свою работу. Огромный респектище Наташе ФамилиюКоторойЯТакНеУзнал.

Как уже сказал, подошла Юлия, спросила, надо ли мне чегой-нибудь рассказать.
- Нет? Тогда будем посмотреть.
И повела на пешую экскурсию по Иннове.

Красиво. Интересно. Из за углов выглядывают даркэльфы и гномы в натуральную величину. Из того, что запомнилось:
- зеленая комната. Реально, в ней можно полежать на газончике.
- большие мониторы. Не-е-ет, не так, Пиздец Какие Здоровенные Моники. Особенно у дизайнеров.
- плазма с дашбордом JIRA. Я начал смотреть, как оно настроено, но Юля мобильно шуганула меня, во избежание инсайда, видимо.

Иннова занимает целое четырехэтажное здание (в секретные подвальные казематы, где держат эльфов и гномов, с которых рисуют эскизы, меня не повели).

По моим ощущениям, маршрут был примерно такой:

Альбом: office

Хотя на самом деле, он был примерно такой:

Альбом: office

А все потому, что Юлия очень стремительная. Не, серьезно, прям совсем. На пятую секунду общения мне стало стыдно за каждый час последнего года, когда я не развивался, куда-нибудь не стремился и не рос над собой.

Тут мое свободное время, здание инновы и внутренний таймер Юлии подошли к концу и мы так же стремительно - как ходили по зданию - попрощались.

В целом было интересно и приятно. Прям в душе подъем какой-то. По итогам собираюсь нанести немало пользы своей конторе.

И да, если кто-то еще хочет провести для меня экскурсию - зовите, мне такая практика нравится.
Обратно же и у нас что-нибудь можно придумать.