Что такое Shift-Left Approach, то есть сдвиг влево

Вероятно, вы знаете, что в тестировании трендсеттер уже какое-то время - это международная организация ISTQB.
И как мы жили без неё раньше?))
Я в IT и в тестировании с 2009 года, если что, я знаю, что не просто жили, а работали и нормально даже.

И это не просто слова. Я с конкретным примером.

В прошлом году вышла свежая версия 4.0 базового силлабуса с обновлениями и последними тенденциями.
Все “новинки” обсуждать в этом посте не будем, поговорим об одной. Обсудим, что же такое шифт лефт апроч (Shift-Left Approach), или по-русски, сдвиг тестирования влево.
Потому что прям началось - все стали писать на эту тему, рассказывая, как она важна и нужно её внедрять.
А я такая - в смысле?

Но обо всём по порядку.

Для начала есть принципы тестирования. Их семь. И они были описаны и в предыдущих версиях силлабуса, здесь ничего нового.
Один из них, точнее третий нам говорит следующее (далее копи-паст из силлабуса):
3. Раннее тестирование сохраняет время и деньги
Для нахождения дефектов на ранних стадиях, как статические, так и динамические активности по тестированию должны быть начаты как можно раньше в жизненном цикле разработки программного обеспечения.

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

В силлабусе 4.0 появляется в дополнении к принципу ещё и отдельная секция “Сдвиг влево” (по-русски, в английской версии Shift-Left Approach)
О чём там?
В принципе, о том же. И снова копи-паст из силлабуса 4.0:
Принцип раннего тестирования иногда называется сдвигом влево, потому что в этом подходе тестирование выполняется на ранних этапах жизненного цикла разработки программного обеспечения. Как правило сдвиг влево предполагает, что тестирование должно быть выполнено на ранних этапах (например, не ожидая появления кода или интеграции компонентов), но это не значит, что нужно пренебречь тестированием на более поздних этапах жизненного цикла разработки программного обеспечения.

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

Лучшие практики, поясняющие как достигнуть сдвига влево в тестировании, включают следующие:
● Рецензирование спецификации с точки зрения тестирования.
● Написание тестовых сценариев до написания кода и запуск кода в тестовой обвязке во время его написания
● Использование непрерывной интеграции, а еще лучше непрерывной поставки, так как они включают быструю обратную связь и автоматизированные компонентные тесты, сопровождающие код при его добавлении в репозиторий (т.е. CI\CD)
● Выполнение статического анализа исходного кода до начала динамического тестирования как часть процесса автоматизации (то есть юнит-тесты)
● Выполнение нефункционального тестирования, начиная с уровня компонентного тестирования там, где это возможно.

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

И я такая всё это вижу, и думаю, я ушла с прода, с проектов в обучение начинающих тестировщиков в 2017 году, но
(продолжение в следующем посте ⬇️)

(продолжение, начало в предыдущем посте ⬆️)

Даже за долго до этого мы уже на разных проектах, с разными командами работали по принципу раннего тестирования и сдвига влево. Почему про это пишут, как про что-то новое в 2024 году?

Что мы реально делали на проектах, где я работала?
Проводили митинги по обсуждению требований с БА, девелоперами и командой тестировщиков. Это же рефанемент-миты (refinement) (или по-старому грумминги).
Когда программисты писали код, то есть разрабатывали новую фичу, мы тестировщики, в это время писали чек-листы или тест кейсы по ней, чтобы когда билд с новой фичей выкатят в тестирование, мы делали не эксплоратори (исследовательское), а тестирование на основе тест-кейсов (или чек листов), написанных по утвержденным и понятным всей команде требованиям.
Наши программисты писали юнит-тесты, автоматизаторы автоматизировали важные тесты (смоук, регрессию).
И всё это запускалось при авто сборке билда, то есть CI\CD процессы уже работали и использовались в 2017 и даже ранее.

Так и где революция?

И главное, а что кто-то сейчас ещё работает не так?)

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

Вот так получается, что не всегда что-то описанное как новое и революционное в ISTQB на самом деле является таким.

Как вам статья в таком стиле?))
Пишите ваше мнение в комментариях!
И если остались вопросы, задавайте обсудим! ⏬

Всем привет!
На этой неделе устроим тестирование 🔥

В смысле предложу вам пройти тесты 🤣🤣🤣

Готовы ответить на вопросы?

А ещё хочу поближе с вами познакомиться!

Раз дошли до этого моменты, ответьте, пожалуйста, ещё на несколько вопросов ❤️

(А то статистика в телеграмме недостаточно подробна)

Заранее спасибо ❤️

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

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

Спасибо большое ❤️❤️❤️

Всем привет!
Неожиданная статистика получается))
Спасибо всем проголосовавшим ❤️
Неголосовавшие, пожалуйста, поучаствуйте 🫶

Собеседования

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

Отдельно оговорюсь, что сегодня поговорим про структуру так называемых технических собеседований. А какие вообще собеседования бывает, обсудим отдельно, если эта тема интересна. Интересна?)

Структура

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

2. Вопросы по теории
Чем ниже ваш уровень, там таких вопросов будет больше. То есть у джуна это основа собеседования, а у сеньора таких вопросов может и не быть)
Вопросы очень зависят от вакансии, поэтому внимательно читайте описание.

3. Практические задания
По мимо (или вместо) чистых вопросов по теории, например, что такое тест кейс, на собеседовании у вас могут попросить их написать) Будьте готовы!

4. Технические темы
Отдельно вынесу этот блок.
Опять же темы зависят от требований к позиции. Могут быть как вопросы по теории, хотя чаще будут задания. Например, написать SQL запрос )

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

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

Ну и это, конечно, общий совет - к собеседованиям нужно готовится!
Чем мы с вами по сути в этом канале и занимаемся) Классно же, да?

Остались вопросы, появились идеи и комментарии, пишите ⬇️

#interview #собеседования

Всем привет!
Совсем замоталась и на прошлой неделе не выложила никакой пост.
На этой постараюсь выложить 2, но это не точно, декабрь такой декабрь 🫣

А как вы? Устали к концу года? Или полны сил? Или много дел нужно переделать в конце года?

У меня все вместе🤯