SmartQA

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Те самые непонятные вопросы на собеседованиях: как на них отвечать - мой ответ

Заждались ответ на этот вопрос?
Хотя прочитав предыдущий пост, вы уже знаете главный секрет - единого правильного ответа нет 😉

Да и вы в комментариях давали отличные ответы!

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

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

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

Ну и конечно, делаем это, если так можно на проекте. Например, бывает, ваш программист работает на стороне заказчика или вообще в другой компании и на прямую с ним общаться нельзя( Будьте готовы и к такому повороту.
Если можно, тогда просим программиста воспроизвести баг, или сами показываем его. Также не забудьте про одинаковость среды - нужная ОС и браузер, один и тот же билд (то есть версия приложения) и другие настройки. Порой, это причина несовпадения.
Но у нас ситуация, когда программист говорит, что это фича, так что узнаём у него, почему он так считает.
И дальше по ситуации, идём либо к бизнес аналитику прояснять требования, к лидам (тест лиду как вашему начальнику и дев лиду как начальнику программиста). Дальше к ПМ (менеджеру проекта), но опять уточняем, а как устроено на проекте. Уточняем у вашего ментора или тест лида.

Третье, важное замечание.
Подумайте, какое впечатление вы хотите произвести на интервьюера. Какие требования указаны в вакансии.
Если нужен командный игрок, делайте упор на общение в команде (с программистом, если он с вами в одной проектной команде, с другими тестировщиками - с просьбами о совете, с тест лидом и БА).
Если же нужен самостоятельный человек, который будет работать одним тестировщиком, тогда покажите свою самостоятельность. Здесь также подходит идти сразу к программисту и решать все вопросы с ним. И в меньшей степени, идти сразу к лиду.
А вот если от вас хотят чёткую субординацию, когда выясните, как принято на проекте, в какой последовательности к кому идти, и так и делайте. Вероятнее всего, сначала нужно поставить в известность тест лида, затем вместе или под его контролем сходить в БА, затем к ПМ или дев лиду. В общем, варианты есть.

Какие моменты я ещё не освятила?
Давайте продолжим обсуждение в комментариях ⬇️

Те самые непонятные вопросы на собеседованиях: как на них отвечать - общие рекомендации

Прежде чем дать свой ответ на первый ситуационный вопрос ⬆️, дам несколько советов, как в целом отвечать на собеседованиях на такой тип вопросов

1. Самое главное - единого правильного ответа на такие вопросы нет! И быть не может!

Отсюда несколько важных выводов

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

Вывод второй ⬇️

3. Самая лучшая фраза при ответе на такого рода вопросы -
Все зависит от проекта

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

Поэтому ваша задача не скатываться до одного какого-то варианта, ваша задача ⬇️

4. Рассуждаете!
- и это главное, самое важное, что от вас ожидают при ответах на такие типы вопросов! И это главный секрет 🤫
Просто подумайте, а что можно сделать еще, а как можно по-другому?
Не ограничивайте себя какими-то стандартами, опытом вашим или тем, что вы прочитали в интернете)

Отсюда же ⬇️

5. Часто вопрос не будет звучать один.
Хороший интервьюер будет прощупывать ваш уровень мыслей и креатива:
На ваше - пойду к Лиду - он скажет - Лид в отпуске
- тогда к менеджеру проекта
- а он в командировке в Штатах, сейчас там ночь
И так далее

Здесь смотрят на вашу реакции и смекалку

➡️

6. Не останавливайтесь, пока вас не остановит сам интервьюер. Не теряйтесь, просто набрасывайте варианты.
Конечно, начинаете с простых, базовых.
Но когда они закончатся, не останавливайтесь, придумывайте варианты, вплоть до самых неожиданных (а это даже круче!), хоть инопланетян вспомните 🤣🤣🤣 шучу, но это не точно 😜

Вот такие вышли рекомендации 🔥
Как вам?

Те самые непонятные вопросы на собеседованиях 🫣

Ввожу новую рубрику 🔥

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

Вот как бы вы ответили на такой вопрос? Как в целом отвечать на такие вопросы?

Как раз в этой рубрике буду делиться своими мыслями и ответами на такие вопросы.

Пишите в комментариях, как бы вы ответили. Завтра я дам свой ответ)

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

Практическое задание по теме Тест дизайн

На этой неделе предлагаю попрактиковаться и выполните следующие практические задания:

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

В пятницу выложу подкаст с пояснениями 😘

И кстати, это была просьба от моих студентов, разобрать эту тему. Так что если у вас есть вопросы, пожелания, смело пишите в комментариях ⬇️