Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 30
×

Middle QA interview/ как построить процессы?

Усі статті, обговорення, новини про тестування — в одному місці. Підписуйтеся на DOU | QA!

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

Заранее извините за ламерские вопросы:)
Какие интересные вопросы вам задавали?)

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

1.

С чего начинать

Найти Сеньёр QA

2.

Стратегия тестирования. Что это отдельно от тест плана и зачем?

озадачить.

Миддл должен выполнять а не решать высокоуровневые вопросы.

Мне понятна мотивация вашего руководства (обойтись меньшими деньгами).

Но опыт даёт возможность сказать : «опа, отставить, так не пойдёт».
А неопытный сотрудник будет пытаться
выполнить невыполнимое, объять необъятное, выполнять любые приказы любого правительства.
Потом начнётся охота на ведьм, поиск виноватых, наказание невиновных итп.

****

Вот, например:
dou.ua/...​rums/topic/26295/#1507298
подозреваю, что там закончилось всё грустно.

я хочу научиться. а как?) а где? ) спасибо!!

Я бы не советовал собеседоваться в компанию в которой для позиции Middle QA задают вопросы, релевантные только для тест-менеджера. Это неадекватный подход. Либо кто-то повышает свое ЧСВ за Ваш счет, либо придется работать тест-менеджером за зарплату миддла.

Далеко не везде на каждую роль держат отдельного спеца. Или бюджета на «излишества» не дают ))

Конечно. Это может быть Lead QA или Test Manager / Test Engineer. Но в любом случае не миддл.

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

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

Вопрос «вы пришли на проект, что будете делать» весьма правильный. И для миддла на него существует вполне логичный набор ответов: Уточню ожидания от моей работы у непосредственного руководителя (KPI, если есть), ознакомлюсь с рабочими инструкциями, составлю рамп-ап/ноледж шэринг план, познакомлюсь с командой... Это все ОК. Но вот требовать от миддла строить тестовые процессы (особенно с нуля) это все равно, что от миддл девелопера в-одиночку разрабатывать архитектуру приложения.

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

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

Не всегда. Я вполне могу задавать миддлу такие вопросы на собесе с целью проверить, что он вообще понимает, чем QA отличается от QC. Если я набираю людей себе в команду, я должен быть уверен, что если я заболею / уйду в отпуск, я оставляю команду на человека, понимающего, зачем нужны процессы и что это вообще такое, а не на тупую абизяну, способную только клацать по кнопкам и поправить полтора тест кейса, которые ему укажут.
Естессно, если у меня 5+ человек в команде, то можно взять и пару абизян: их стоимость как минимум в 2 раза дешевле, что благотворно скажется на возможности райза для остальных ;)

«Цiкаве питання, будемо полемiзувати...»
Знать чем отличается test strategy от test plan (хотя бы в одном из вариантов) миддл должен. А вот уметь писать стратегию или сетапить все процессы тестирования с нуля — нет.
Нормально спрашивать вопросы, выходящие за пределы компетенции, чтобы понять профессиональный кругозор, но это не то, за что миддла стоит реджектить на собеседовании. Также обязательно проговаривать необязательность знания этого кандидату, чтобы не было дурных мыслей, что зареджектили именно за это.
Если Вы лид или Тест-Менеджер, так оставляйте за себя Синьора, который метит выше, а не миддла, который знает все тоже, что и синьор, но просто звучит дешевле.

«Цiкаве питання, будемо полемiзувати...»

Эт я с удовольствием! :)

вот уметь писать стратегию или сетапить все процессы тестирования с нуля — нет.

Я ничего не сказал про написание тестовой стратегии. Но вот, к примеру, задачку в стиле «есть продукт, к примеру, веб-магазин. Есть команда X разрабов. Твои мысли насчёт состава QA команды и как ты бы предложил тестировать данный продукт?» я предложу обязательно. Цель — понять, передо мной homo sapiens, способный думать или абизяна, способная только клацать. Интересно не книжное решение и не сколько там процессов расписано в CMMI III, а понимание кандидатом, что такое качество и как он собирается его обеспечивать. Самый смак в этой задаче — то, что её можно вывернуть как угодно и решение от этого будет кардинально меняться, к примеру, 1 из вариаций — проект уже полгода пишется, ты — 1-й тестировщик на проекте. Изменится ли твое решение и почему?
От миддла я не буду требовать идеального решения или управления рисками, но мысли кандидата при решении этой задачки я буду учитывать с намного большим весом, чем ответ на вопрос типа чем верификация отличается ли валидации.

Также обязательно проговаривать необязательность знания этого кандидату

 С чего бы? Миддл — это вполне самостоятельная единица, способная автономно вести небольшой проект или часть большого. Если миддл требует пинков и надзора — это джун. Если миддл не понимает, что необходимо сделать, чтобы обеспечить качество своей части проекта — это джун с максимальной перспективой миддла...лет через 5.

Если Вы лид или Тест-Менеджер, так оставляйте за себя Синьора,

А если в команде 2..3 QA? Так что мне, в отпуск не ходить, патамуша малыш требует присмотра? ;) Нет уж, лучше я выберу себе в команду миддла, который умеет думать и сможет самостоятельно приоретизировать задачи в соответствии с пониманием тестовой стратегии, чем абизяну, которой надо накидывать задач в бэклог перед отпуском и при этом надеяться, что не прилетит нежданчик :)

Цель — понять, передо мной homo sapiens, способный думать или абизяна, способная только клацать.

Это можно узнать значительно проще. Просто спроси, собирается ли кандидат голосовать за Зе во втором туре :-)
Соррян, не смог удержаться от политоты )

Просто спроси, собирается ли кандидат голосовать за Зе во втором туре :-)

А какой должен быть ответ? Я в сортах...кхм... кандидатов не разбираюсь... :)

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

Я ж не знаю, что конкретно Вас спрашивали и тем более не знаю, что ожидали услышать в ответ :)
Если Вы про мою задачку, то начало правильное. Дальше необходимо сделать выводы о приоритетах задач: написание тест кейсов (каких именно и как будем их приоретизировать?), проведении сессий регрессионного и функционального тестирования, как вариант — сессии exploratory тестирования, если у нас нет требований к системе, зато есть рабочая (ну или не совсем :) ) система, внедрению автоматизированного тестирования в случае большого размера регрессионных сьютов, сбору и актуализации требований, если на проекте нет выделенного BA ну и т.д. Эту задачку можно решать бесконечно, тут нет единственного возможного правильного ответа.

У кнопкодавов не было шансов уже лет 5 назад

Хехе, эт Вы не проводили интервью :)) Я могу с уверенностью заявить, что на 1 думающего тестировщика приходится 4..5 абизян.

а что делать не гениям но и не кнопкодавам? людям думающим, но возможно где-то недоучившимся или не отвечающим как гении сцены.

Надеюсь что повезет попасть к Вам на собеседование и порадовать ответами :)))

Хехе, Вы думаете, это единственная задачка, которую я могу придумать? Я Вас уверяю, Вы сильно ошибаетесь :))))))

Мы разве соревнуемся на собеседовании? тема и создана была для того, чтобы понять какие интересные есть задачи на подумать. В любом случае, спасибо за ответы.

Вам как, проверить умет ли человек думать и в какую сторону он думает или самоутвердиться? )

Задавать вопросы и давать работу — разные вещи

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

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

вообще странно, что на Middle QA interview спрашивают как строить процессы и про тест стратегию. Я бы сказал, это вопросы на лида\менеджера

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

а еще умел автоматизировать немножко, желательно и e2e и API, ну и юнит-тесты тоже, а то девелоперам лень писать. Ну и еще чтоб в докере было и на дженкинсе, чтоб сам мог засетапать, потому что девопсы заняты. Ну и конечно же все с нуля, процессы, автоматизацию и т.п. вилка по ЗП — 600 — 800 баксов, ты ж миддл

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

1. Для лучшего понимания best practices читай Блека. Будешь отвечать по ISTQB — меньше шансов посыпаться, а если в компании построены процессы не по нему — заранее правильного ответа, который удовлетворит их ты все равно знать не будешь.
2. Разные уровни документа — тест стратегия описывает высокоуровневые подходы на уровне проекта, тест план — более подробное описание активностей на уровне итерации, exit criteria, milestones и тд.
Все это опять же подробно расписано в книгах Рекса Блека.

Благодарю! Кстати в его книге насколько я помню не описана техника Pairwise, интересно почему

на википедии в статье про pairwise одним из двух источников указана книга Рекса Блека)
просто он не описывает методы настолько глубоко, как тот же Ли Коупленд, а на уровне достаточном для сертификации.

Это смотря что понимать под тест-планом. Тест-план по IEEE 829 это еще более общий документ, который включает в себя тестовую стратегию как один из пунктов. Т.е. отвечая на вопрос, я бы сначала согласовал интерфейс в отношении того что мы понимаем под тест-планом, а уже потому отвечал.

1) Почитать как изобретать велосипеды.
2) Не делать нихера из этого.
3) Скопипастить готовые решения.
4) Гонять лысого в настольный футбол.
5) PROFIT!!!!!!!!!!

Прям до мурашок пройняв.. істину говориш)

Последние 5 лет только так и работаю

Підписатись на коментарі