Достаточно спорного качества статья с технической точки зрения. Кроме того, местами пробивается неуважение к коллегам по цеху, что в наше время расценивается в профессиональном мире как "no-go".
1) Статья из разряда "популярное творчество". Даются общие рекомендации без погружения в детали, нет плана на интервью, нет матрицы тематик, в рамках которого идет assessment QA-специалиста, приводимые live coding задания идут под маркой "Hello World!".
В статье контент для HR-специалистов и социологов, а не инженеров.
2) Автор спрашивает почему во фреймворках "UIAutomator, XCTest и Espresso" не указаны языки. Да потому что указывать, например, на чем пишутся тесты под Espresso - Kotlin или Java - смысла особо не имеет, ибо индустрия уже давно смотрит не знание конкретного языка программирования, а на общий уровень алгоритмической и инженерной подготовки специалиста. Язык программирования идет следом, и за карьеру software engineer может меняться много раз. Кроме того, этот пункт легко проверяется через ряд простейших заданий на интервью.
3) Автор ссылается на несоответствие в мелочах в CV - модульное тестирование, "переделал с нуля", ищет связи в копипастах между проектами в части выполняемых обязанностей. Моя личная практика показывает, что даже "бледные" CV на входе не являются критерием профессионализма соискателя или индикатором отсутствия квалификации в этой области. Более того, были случаи, когда люди присылали очень посредственные CV, а потом отлично проходили собеседования и становились локомотивами целых направлений в компании.
Работает и наоборот - соискатели с великолепным CV c треском проваливались на собеседовании.
4) Автор пишет, что "мне прислали резюме senior QA инженера с опытом работы 5 лет. Работает на «галере»."
Посмотрел, где работает автор, и последние 5 мест его работы. Улыбнуло про "галеры".
Summary: За сим откланиваюсь с надеждой, что автор будет менее щепетилен к форме, и более внимателен к содержанию, что позволит ему не пропустить кандидатов, которые могли бы усилить его компанию.
Хранение скриптов сборки в репозитории – хорошее решение.
Опять-таки, как писал выше – для каждого проекта получается индивидуально.
Как правило, скрипты по разворачиванию сложных проектов (в контексте архитектуры) находятся в репозитории. В статье скрипт внутри build definition показан для наглядности.
1. В разных системах CI по-разному, но в TFS именно так. В ней самой созданы описания сборок, которые имеют историю. Зачастую бывает, что код передается Заказчику или предполагается совместная работа с ним. Соответственно, переносить в репозиторий избыточные данные – не лучшая практика в таком ключе. Опять-таки, есть проекты, где скрипты написаны разработчиками (или для них) и пригодны для использования вне CI (сборки Sharepoint и проч.) и тогда комбинируем. В-общем, все индивидуально получается.
2. В рамках одного проекта создаем дополнительное описание сборки с добавлением особенностей (к примеру для dev/stage).
3. Есть проблемы с запуском MySQL-кластера (не рекомендуем для Заказчиков), PostgreSQL работает в кластере, но и с ним есть определенные нюансы. Если нет требования отказоустойчивости или некритична временная недоступность сервиса, то хорошее решение.
Слово «классический» подразумевает, что этот пример часто встречается в материалах на тему согласованности. Странно, что вы ни разу не видели его в подобных статьях.
Пример абстрактный и лишь объясняет «на пальцах» что такое согласованность. При этом не утверждается, что реальные банковские системы работают именно так.
Есть ли у вас реальные примеры, где требуется согласованность, кроме кэша процессора и оперативной памяти?
Реальные примеры вы можете увидеть в данной статье, в разделе (не угадаете!) «Область применения и примеры применения».
Достаточно спорного качества статья с технической точки зрения. Кроме того, местами пробивается неуважение к коллегам по цеху, что в наше время расценивается в профессиональном мире как "no-go".
1) Статья из разряда "популярное творчество". Даются общие рекомендации без погружения в детали, нет плана на интервью, нет матрицы тематик, в рамках которого идет assessment QA-специалиста, приводимые live coding задания идут под маркой "Hello World!".
В статье контент для HR-специалистов и социологов, а не инженеров.
2) Автор спрашивает почему во фреймворках "UIAutomator, XCTest и Espresso" не указаны языки. Да потому что указывать, например, на чем пишутся тесты под Espresso - Kotlin или Java - смысла особо не имеет, ибо индустрия уже давно смотрит не знание конкретного языка программирования, а на общий уровень алгоритмической и инженерной подготовки специалиста. Язык программирования идет следом, и за карьеру software engineer может меняться много раз. Кроме того, этот пункт легко проверяется через ряд простейших заданий на интервью.
3) Автор ссылается на несоответствие в мелочах в CV - модульное тестирование, "переделал с нуля", ищет связи в копипастах между проектами в части выполняемых обязанностей. Моя личная практика показывает, что даже "бледные" CV на входе не являются критерием профессионализма соискателя или индикатором отсутствия квалификации в этой области. Более того, были случаи, когда люди присылали очень посредственные CV, а потом отлично проходили собеседования и становились локомотивами целых направлений в компании.
Работает и наоборот - соискатели с великолепным CV c треском проваливались на собеседовании.
4) Автор пишет, что "мне прислали резюме senior QA инженера с опытом работы 5 лет. Работает на «галере»."
Посмотрел, где работает автор, и последние 5 мест его работы. Улыбнуло про "галеры".
Summary: За сим откланиваюсь с надеждой, что автор будет менее щепетилен к форме, и более внимателен к содержанию, что позволит ему не пропустить кандидатов, которые могли бы усилить его компанию.
Опять-таки, как писал выше – для каждого проекта получается индивидуально.
Как правило, скрипты по разворачиванию сложных проектов (в контексте архитектуры) находятся в репозитории. В статье скрипт внутри build definition показан для наглядности.
2. В рамках одного проекта создаем дополнительное описание сборки с добавлением особенностей (к примеру для dev/stage).
3. Есть проблемы с запуском MySQL-кластера (не рекомендуем для Заказчиков), PostgreSQL работает в кластере, но и с ним есть определенные нюансы. Если нет требования отказоустойчивости или некритична временная недоступность сервиса, то хорошее решение.
Пример абстрактный и лишь объясняет «на пальцах» что такое согласованность. При этом не утверждается, что реальные банковские системы работают именно так.
Реальные примеры вы можете увидеть в данной статье, в разделе (не угадаете!) «Область применения и примеры применения».