Если вы пойдете работать в корпорат, то сразу увидите и кафку, и java стэк и любой другой брокер сообщений в составе работы с корпоративной шиной данных.
Собственно, kafka explorer иногда может быть нужен. То же самое и про рэббит
Contror ≠ Managment, а лишь одна из его функций, и она реактивная, в отличие от QA.
Но меня тоже смутила некоторая попытка в статье снять ответственность с QA, путая их с QC.
Цитата: реальность: "QA-инженеры не могут напрямую сократить количество ошибок, они их не исправляют".
QA как раз определяют риски, подсвечивают их и имеют влияние на релиз и на команду, запрещая выпускать дефектованый продукт. QC же борется с последствиями, подсчитывая количество дефектов и жалоб от пользователя.
О, опубликую свой пост из linkein про тиньков. Нюанс в том что 4 этапа интервью - это еще не самое сложное. Еще надо попасть в нормальную команду с нормальным тимлидом. А они мимикрируют.
Интервью там были долгие и не самые внятные. И лайфкодинг слишком долгий, как по мне. Но!
КАК Я (НЕ)ПРОШЕЛ ИСПЫТАЛКУ
Очень хочется поделится своим трехмесячным опытом по прохождению испытательного срока в одном известном большом желтом банке из РФ.
С этим банком у меня уже были попытки наладить трудовые отношения, когда я трудился еще в сфере поддержки, но они предлагали ЗП сильно ниже рынка и в 3 раза меньше, чем я получал на тот момент. Аргументируя это тем, что у нас "Все так начинают", зажав 100$. Ну да ладно..
В этот раз я повелся на трудовой договор вне РФ и полную удаленку. Сначала были ожидаемые для крупных компаний 4 круга собесов - скрининг, тех.интервью QA, тех.интервью программирование, интервью с тим.лидом. Заняло это в общей сложности пару недель и 4 часа чистого времени на созвоны. После согласования ЗП, получения техники и доступов, началось погружение в проект.
Проект был достаточно простой архитектурно(3 БД, шина, API с ломаной сваггер схемой) и, как мне показалось, не очень правильный с точки зрения организации качества. Но 3 месяца я упорно старался вникнуть в эту организацию, послушно подстраиваясь под командные процессы.
В банке существовало ревью для прохождения испыталки. Задачи были согласованы с тим лидом и ментором. Под конец срока я начал закрывать самостоятельно задачи на доске, учавствуя в дейликах и 3амиго уже как полноценная единица.
Но... Оказалось, что проблемы у меня все-таки были. Хотя я и закрыл задачи на ревью, со слов тим лида, я делал задачи недостаточно быстро(хоят в KPI не было метрик по времени выполнения), были просадки по трекеру рабочего времени на рабочем ноуте(да, да, такое еще существует в ИТ).
Кажется, меня подвели под формальное увольнение под предлогом. Проблема только в том, что сделали они это уже после окончания испытательного срока - опоздали на 3 дня. Компании пришлось заплатить за это несколько тысяч долларов. На конечных переговорах руководитель департамента описала этот случай как "неправильно дали фидбек". И можно посчитать, во сколько компании обошелся этот "фидбек":
- моя зп. Первый месяц я почти все задачи закрывал с ментором. И половину второго тоже. Т.к. всегда надо было координировать процесс.
- оплата ментору за доп.нагрузку
- оплата интервьюверу за доп.нагрузку
- пустой круг hr за привлечение
- согласованная сумма выходного пособия для меня, т.к. я не соглашался добровольно писать заявление, аппелируя к факапу компании. И я был прав. Ошибка тим.лида привела к потерям компании.
Функционально я для позиции полностью подходил, а вот для комфортной работы с тим.лидом - нет. Это был тот тип менеджеров, которые любят видеть в сотруднике жажду переработки и нацеленность на процесс, а не на результат. И я уже вырос из такой стартапской психологии к своим 15 годам опыта в ИТ.
Я пришел к выводу, что позицию освободили для кого-то "своего".
А и еще... несмотря на такой сложный и дорогой цикл подбора кадров, в компании нет внутреннего процесса смены команды на этапе испыталки. Несмотря на то, что внутри всегда нехватка спецов.
Расскажите, в какой момент у вас в команде к работе подключаются тестировщики и как происходит работа с вашими юнит-тестами? Трогают ли они их, или пишут потом свои интеграционные?
Еще интересно, проверяете ли вы потом юниты на тестовых данных(с переключением environment) или так и оставляете на моках?
QA фулстак стоит на 50-100% дороже аналогичной позиции не фулстак)) зачем брать на себя ответственность за качество, если я могу за 40$/h просто писать код как automation?)
Кроме того, чтобы корректно перевести текст и не потеряться в проф.терминах, переводчик должен еще уметь в синтаксис. Иначе читать это все становится невозможно. Особенно в таком объеме.
Я вам советую не переводить дословно, а рерайтить слишком сложные куски.
"Нам нужно изолировать фрагменты и убедиться, что все функционирует достаточно хорошо при масштабировании
"Нам нужно изолировать функционал и убедится, что при масшабировании ничего не сломается"
Аренда участка под сельхоз направление в любом аграрном регионе даст намного больший объем клубники и прибыль при меньших затратах. Думаю, хобби в таком виде трудно будет масштабировать. Я часто проезжаю мимо нескольких гектар теплиц с огурцами, и понимаю, что микробизнес в аграрном секторе это утопия.
Методы API являются интерфейсами различных программных классов, которые взаимодействуют с бизнес-сущностями. Разработчики могут спокойно покрывать их юнит-тестами.
UI-тесты можно упоминать как часть e2e тестирования.
А вообще, в книге они описаны, чтобы ввести читателя в контекст всего процесса разработки
Это, как обычно, про сферического коня в вакууме. В реальной жизни надо стремиться и обращать внимания на эти замечания, но скорее всего, полностью соответствовать не удастся.
В маленьких командах не получится соблюдать одни принципы, в крупных другие. В стартапах одни, в корпорате другие. Ну вы поняли.
Если словарный запас есть и разговорный блок снят, то есть preply, на котором можно найти учителя
Можно найти учителя из местных и маленькую группу айтишников, которая работает в этом направлении. У нас такая есть, если хотите присоедениться - напишите в личку. Уровень intermediate
Можно взять того же учителя и заниматься парой с кем-то, задавая друг другу вопросы.
Собрать процесс выпуска карточки клиента кредитного продукта из 5 шагов или Собрать процесс скоринга из 50-ти тасков с несколькими интеграциями.
Понятно, что во втором случае придется тестить отдельно, мокировать сервисы. И метрики качества работы будут разные, потому как цена ошибки разная.
Для бизнеса будет важен сроки и бюджет. Для пм - сроки тасок и бюджет в человеко\часах Для лида кол-во дефектов на проде, которые влияют на процесс и бюджет
"За что ты конкретно отвечаешь при «вычленял методы из бизнес процесса и приоритизировал задачи»?" Конекретно за качество выпущенного в итоге процеса. А не за качество отдельной таски. Что и было указанно у автора п.6. Тестировщик еще не умеет в бизнес. QA уже должен вникать.
"Как QA влияет на именно процесс при TDD?" - Формирует общую политику тестирования, совместно с тимлидом. Симбиозом позиции будет SDET, который занимаются этим же на более высоком уровне.
"Приоритизация как раз и двигает сроки доставки полезности, как она может именно помочь ужаться, или там идет как раз-таки понижение требований" - Зависит от сложности процесс. Иногда есть возможность это сделать, иногда нет. Я не утвержаю, что надо всегда строить в тесте весь процесс. Но QA может указать на наличие возможности.
Если есть разница с какой позиции отвечать, то со всех позиций, пожалуйста. - Пожалуй, откажусь. Лень доказывать.
Изначально мой комментарий был на реплику "Задача QA — она на другом конце конвеера — после разрабов". И вот это: " Внезапно, открытая аргументированная дискуссия между реальными участниками процесса, которые будут выполнять работу, а не только контролировать качество — выявит больше нюансов как «до», так и «во время» разработки."
А QA не участник процесса что ли? Как будто на твоем проекте были не QA, а кто-то похожий на QA или просто тестировщик. Который никак и не должен влиять ни на процесс. И не должен иметь никаких компетенций по отношению к процессу разработки. А если на проекте TDD подход, QA тоже не влияет на процесс?
По срокам и приоритетам скорее PM, а не тимлид. Причем в разных проектах по разному. Твой опыт, скорее, относится к чему-то типа Scrum-команд, у меня больше опыт в корпоративных Waterfall + scrum. В них смещена ответственность на Senior-ов, и тимлид, конечно, отвечает тоже. Но за более масштабные этапы проекта.
"Как я, к примеру, смогу оценить качество работы такого специалиста по качеству" - С позиции кого отвечать на этот вопрос? PM? Тимлида? Бизнеса? Есть метрики, в чем проблема? Если приоритизация помогла доставить полезность в срок и уменьшила время на поиск тестовых данных, там сразу видно.
У меня было смешно. Моя вилка была рыночная, а на собесе мне сказали, что вилка на 40% больше. Я сказал - ок.
А потом мне написали, что отказывают мне из-за того, что я слишком много денег прошу:D
Если вы пойдете работать в корпорат, то сразу увидите и кафку, и java стэк и любой другой брокер сообщений в составе работы с корпоративной шиной данных.
Собственно, kafka explorer иногда может быть нужен. То же самое и про рэббит
Contror ≠ Managment, а лишь одна из его функций, и она реактивная, в отличие от QA.
Но меня тоже смутила некоторая попытка в статье снять ответственность с QA, путая их с QC.
Цитата: реальность: "QA-инженеры не могут напрямую сократить количество ошибок, они их не исправляют".
QA как раз определяют риски, подсвечивают их и имеют влияние на релиз и на команду, запрещая выпускать дефектованый продукт. QC же борется с последствиями, подсчитывая количество дефектов и жалоб от пользователя.
О, опубликую свой пост из linkein про тиньков. Нюанс в том что 4 этапа интервью - это еще не самое сложное. Еще надо попасть в нормальную команду с нормальным тимлидом. А они мимикрируют.
Интервью там были долгие и не самые внятные. И лайфкодинг слишком долгий, как по мне. Но!
Спасибо за статью!
Расскажите, в какой момент у вас в команде к работе подключаются тестировщики и как происходит работа с вашими юнит-тестами? Трогают ли они их, или пишут потом свои интеграционные?
Еще интересно, проверяете ли вы потом юниты на тестовых данных(с переключением environment) или так и оставляете на моках?
Бесполезная статья без практических примеров
QA фулстак стоит на 50-100% дороже аналогичной позиции не фулстак)) зачем брать на себя ответственность за качество, если я могу за 40$/h просто писать код как automation?)
Кроме того, чтобы корректно перевести текст и не потеряться в проф.терминах, переводчик должен еще уметь в синтаксис. Иначе читать это все становится невозможно. Особенно в таком объеме.
Я вам советую не переводить дословно, а рерайтить слишком сложные куски.
"Нам нужно изолировать функционал и убедится, что при масшабировании ничего не сломается"
Добрый день. Про вторую часть можно подробнее?)
Перевести деньги на счет в банке можно по номеру телефона через платежную систему Золотая Корона. Это для физ.лиц
Для Юр.лиц, наверно, тоже существует процедура в обход свифта
Согласен. Кондитерам на Камчатку. Да и вообще в те регионы, куда логистика свежих фруктов дороже
Аренда участка под сельхоз направление в любом аграрном регионе даст намного больший объем клубники и прибыль при меньших затратах. Думаю, хобби в таком виде трудно будет масштабировать.
Я часто проезжаю мимо нескольких гектар теплиц с огурцами, и понимаю, что микробизнес в аграрном секторе это утопия.
Это перевод. Все вопросы к авторам книги.
Мне, как практикующему QA, было интересно перевести для сообщества. Статья была вычитана и одобрена к публикации коллегами.
Жаль, что вам не интересно. Но такое бывает, да.
Методы API являются интерфейсами различных программных классов, которые взаимодействуют с бизнес-сущностями. Разработчики могут спокойно покрывать их юнит-тестами.
UI-тесты можно упоминать как часть e2e тестирования.
А вообще, в книге они описаны, чтобы ввести читателя в контекст всего процесса разработки
Это, как обычно, про сферического коня в вакууме. В реальной жизни надо стремиться и обращать внимания на эти замечания, но скорее всего, полностью соответствовать не удастся.
В маленьких командах не получится соблюдать одни принципы, в крупных другие. В стартапах одни, в корпорате другие. Ну вы поняли.
Есть несколько вариантов:
Если словарный запас есть и разговорный блок снят, то есть preply, на котором можно найти учителя
Можно найти учителя из местных и маленькую группу айтишников, которая работает в этом направлении. У нас такая есть, если хотите присоедениться - напишите в личку. Уровень intermediate
Можно взять того же учителя и заниматься парой с кем-то, задавая друг другу вопросы.
Мое самое проблемное место - боязнь собеса на английском. Именно для международной компании
Усиленно психологически настраиваю себя на этот этап. Все остальные страхи уже развеяны и не страшны.
Собрать процесс выпуска карточки клиента кредитного продукта из 5 шагов
или
Собрать процесс скоринга из 50-ти тасков с несколькими интеграциями.
Понятно, что во втором случае придется тестить отдельно, мокировать сервисы. И метрики качества работы будут разные, потому как цена ошибки разная.
Для бизнеса будет важен сроки и бюджет.
Для пм - сроки тасок и бюджет в человеко\часах
Для лида кол-во дефектов на проде, которые влияют на процесс и бюджет
"За что ты конкретно отвечаешь при «вычленял методы из бизнес процесса и приоритизировал задачи»?"
Конекретно за качество выпущенного в итоге процеса. А не за качество отдельной таски. Что и было указанно у автора п.6.
Тестировщик еще не умеет в бизнес. QA уже должен вникать.
"Как QA влияет на именно процесс при TDD?" - Формирует общую политику тестирования, совместно с тимлидом. Симбиозом позиции будет SDET, который занимаются этим же на более высоком уровне.
"Приоритизация как раз и двигает сроки доставки полезности, как она может именно помочь ужаться, или там идет как раз-таки понижение требований" - Зависит от сложности процесс. Иногда есть возможность это сделать, иногда нет. Я не утвержаю, что надо всегда строить в тесте весь процесс. Но QA может указать на наличие возможности.
Если есть разница с какой позиции отвечать, то со всех позиций, пожалуйста. - Пожалуй, откажусь. Лень доказывать.
Изначально мой комментарий был на реплику "Задача QA — она на другом конце конвеера — после разрабов".
И вот это:
" Внезапно, открытая аргументированная дискуссия между реальными участниками процесса, которые будут выполнять работу, а не только контролировать качество — выявит больше нюансов как «до», так и «во время» разработки."
А QA не участник процесса что ли? Как будто на твоем проекте были не QA, а кто-то похожий на QA или просто тестировщик. Который никак и не должен влиять ни на процесс. И не должен иметь никаких компетенций по отношению к процессу разработки. А если на проекте TDD подход, QA тоже не влияет на процесс?
По срокам и приоритетам скорее PM, а не тимлид. Причем в разных проектах по разному. Твой опыт, скорее, относится к чему-то типа Scrum-команд, у меня больше опыт в корпоративных Waterfall + scrum. В них смещена ответственность на Senior-ов, и тимлид, конечно, отвечает тоже. Но за более масштабные этапы проекта.
"Как я, к примеру, смогу оценить качество работы такого специалиста по качеству" - С позиции кого отвечать на этот вопрос? PM? Тимлида? Бизнеса? Есть метрики, в чем проблема? Если приоритизация помогла доставить полезность в срок и уменьшила время на поиск тестовых данных, там сразу видно.