×Закрыть

Вопросы по тестированию на собеседования (QA manual)

Всем привет, недавно начал ходить в IT Scool на курсы QA Manual. Хотелось бы спросить у людей которые проходили либо же проводили собеседование не так давно.
Актуальны ли данные вопросы:
alexeybulat.blogspot.ru/...​008/07/questionnaire.html

Предлагайте какие еще можно добавить. Спасибо

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

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

Тут не питання, ну будеш мати що почитати, зазвичай питають щось із цього по теорії.

dou.ua/forums/topic/13389
dou.ua/forums/topic/14015

Конечно, они не актуальны, ведь они были составлены больше 256-ти дней назад!

Можно получить от Вас, пожалуйста, актуальные ! Спасибо

Извольте: эти вопросы — про основы. Основы меняются редко, вам их до пенсии хватит.

Собеседование начинается с теории. В основном спрашивают основу, а потом переходят к практике в случае успешного ответа на вопрос. Пример: вопрос из теории — какие техники тест дизайна вы знаете? В случае успешного ответа последуюет практическая задача, начиная с простого поля для ввода. Я знаю только 1 компанию, где дотошно спрашивали теорию от А до Я (но у них были на то причины). В остальных случаях перейдут на практику, а ее предугадать невозможно. Нужно понимание.

какие техники тест дизайна вы знаете?

кто здес?)))
я надеюсь это только джунам такие вопросы задают, ибо я вообще не понимаю о чем этот вопрос)

Могут спросить верстку, тестирование API, SQL на базовом уровне, ООП, GET vs POST.

Сильно зависит от компании, куда вы идёте собеседоваться. Когда менял работу в крайний раз, то был на собеседованиях на позицию Senior QA Automation в Keep Solid и Oracle. В первом месте у меня спросили всю теорию тестирования, которую только смогли вспомнить, во втором — вообще ничего не спрашивали за тестирование.)

якщо питаєтесь про актуальність — хреновий вс студент

Блог с вопросами как видно был создан 9 лет назад.
Поэтому и интересуюсь, не утратили ли они актуальность по сей день.

і ? Базові концепції не змінюються
На курсах їх і викладають. Можна ще глянути на щось інше поза курсами. і з цього робити висновок

Ці питання лише мінімум. Питання залежать від самого проекта та компанії. І тому щось не запитають, а щось поза цим списком запитають. Одного зазубрення не достатньої, якщо хороший інтервювер, йому більше цікаво ваша думка, ваш хід думок, а не зазубренний текст. Також врахуйте, що інтервю — лотерея. Можете все знати і не попасти на позицію, знайдуть дешевшого. Або кращого. Можете мало знати, але з якоїсь причини вас візьмуть

Если вы сможете ответить на ВСЕ эти вопросы, Вас возьмут на работу.

або не візьмуть

разве что если после интервью разобьет стулом стекло митинг рума и уйдет в проем тихо матерясь себе под нос ))))

К сожалению, сейчас на очень многих проектах, где требуются джуны, лидами сидят деффачки, которых 3..4 года назад взяли по знакомству / из жалости / придумайте свою причину. Эти деффачки плохо приспособлены к IT вообще и к тестированию в частности. Умных книжек они не читали, а если и прочитали — ничего не поняли. Процессы им понять тяжело, теорию — вообще нереально. Их максимум — поддерживать то, что кто-то более одарённый сделал до них. Насколько я понимаю физику процесса, лидами их ставят, поскольку никого на проекте старше тупо не осталось. Обычно это проекты вида адекватный лид + 1 синьор + дофига джунов. Атришн у проекта бешеный, поскольку джуны, немного обучившись, уходят оттуда куда подальше, но никого это не парит, пока джунов больше, чем спрос на них. Проблемы начинаются, когда синьор и лид из проекта уходят. В таком случае зачастую лидом ставят самого долгоживущего. И это может оказаться такая вот деффачка, которая из проекта не свалила тупо потому, что миддлом её никуда не берут из-за полного непонимания теории. В этом случае ЧСВ этой деффачки достигает Олимпа и она переходит в режим «я самая умная», окончательно забивая на самообразование.
Самый цирк начинается, когда она пытается собеседовать.
Во-первых, вменяемых вопросов она придумать не способна, поскольку её знания остались на уровне слабого миддла, а залезть в гугель и найти хотя бы вопросы (я уже не говорю про ответы) ей мешает вышеупомянутое ЧСВ.
Во-вторых, правильный ответ на её вопрос бесполезно искать в книжках, на форумах и т.д. — это лотерея, поскольку не факт, что тот ответ, который написан в книжке, ISTQB или ещё где-нить совпадёт с её версией.
Из реальных кейсов жены, когда она искала работу джуном:
тестирование производительности — оказывается, это ревью документации;
тест кейсы — устаревшая технология, их больше никто не пишет;
юнит тесты — тоже никто не пишет по той же причине;
требования — туда же;
вообще, базировать тестирование на требованиях — это плохой тон, лучше всего — спросить у разработчика, как должна работать функциональность;
в случае конфликта мнений баг — не баг не нужно эскалировать, программист обидится, нужно с ним согласиться, ему виднее;
в случае наличия аппликухи с веб-мордой и SQL базой под капотом тестировать выполнением запросов в базу — низзя, патамуша можно её сломать (про несколько схем и права доступа юзера не слышали), это неправильно, правильно — вбивать всё руками через веб-морду;
если в скраме задачу не успели закончить за спринт — её надо вообще нафиг выбросить из бэклога )))))))))))))));
Ну и так далее. Притом эти шедевры говорились на полном серьёзе поучающим тоном ))))
И это не 1 и не 2 такие деффачки, их реально много, притом не только в рогах и копытах на 3 манагера и уборщицу, эти шедевры в том числе из контор, входящих в топ-5 в Украине.
Походу, явление становится массовым...

P.S. Дисклеймер:
1). «деффачки» — не признак сексизма, а потому, что мальчики, которые жене встречались на собесах, были более подкованы технически и таких шедевров не выдавали.
2). Адекватные и знающие девочки лиды — есть и обратного я нигде не утверждал ;)

тестирование производительности — оказывается, это ревью документации;
тест кейсы — устаревшая технология, их больше никто не пишет;
юнит тесты — тоже никто не пишет по той же причине;
требования — туда же;
вообще, базировать тестирование на требованиях — это плохой тон, лучше всего — спросить у разработчика, как должна работать функциональность;
в случае конфликта мнений баг — не баг не нужно эскалировать, программист обидится, нужно с ним согласиться, ему виднее;
в случае наличия аппликухи с веб-мордой и SQL базой под капотом тестировать выполнением запросов в базу — низзя, патамуша можно её сломать (про несколько схем и права доступа юзера не слышали), это неправильно, правильно — вбивать всё руками через веб-морду;
если в скраме задачу не успели закончить за спринт — её надо вообще нафиг выбросить из бэклога )))))))))))))));
Ну и так далее. Притом эти шедевры говорились на полном серьёзе поучающим тоном ))))
И это не 1 и не 2 такие деффачки, их реально много, притом не только в рогах и копытах на 3 манагера и уборщицу, эти шедевры в том числе из контор, входящих в топ-5 в Украине.
Походу, явление становится массовым...

я такое же ± слышал от совсем не «девочек» , люди с 10-15-20 лет опытом такую дичь несли, что встать и убежать с интервью , не позволяля элеметнарная вежливость)

зачем вставать и убегать если можно поставить их в тупик правильными вопросами?)
Конечно, если ты не джун, у джунов особого выбора нет

а смысл? после таких вопросов работать с ними желания никакого нет) разве что свое ЧСВ потешить)

что встать и убежать с интервью , не позволяля элеметнарная вежливость)

вот почему, все равно сидеть

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

в случае конфликта мнений баг — не баг не нужно эскалировать, программист обидится, нужно с ним согласиться, ему виднее;

Все правильно сделала, аналитикам так вообще кофе надо каждый день покупать что бы они помогли понять требования =D

так то qa вообще не должен к деву ходить, чтобы тот ему функциональность обяснял, а должен либо к продуктОунеру/аналитику/ документации/ в общем к тому, кто девелоперу задачу ставил
А то тестироваться будет фича, по критиериям как ее понял разработчик, а не как она была задумана

По сути это не тебе обяснение, это мое возмущение о вышенаписанном)))

Дык я-то это как раз знаю )))
И жена знает, поскольку я её этому учил ))))

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

не очікував, що буває аж настільки запущено. Але згідний, що такі кейси бувають. Благо, мені не попадились. В основному попадав на співбесіди з технарями

Так ты не понял — это типа технари ))) QA Lead, к примеру.

я зрозумів це. Я мав на увазі, що саме цю люди були з технічними знаннями хорошими

Когда ты начинал джуном — такого явления ещё не было, люди, которые тебя собеседовали — начинали, скорее всего, где-то в одно и то же время со мной, тогда термин «вайти в айти» ещё не придумали ))))

которых 3..4 года назад взяли по знакомству

Доречі знаю такий 1 приклад. І далі також по знайомству просували. Але уже інша людина, не та що взяла :)

Тарас, отправила Вам запрос в LinkedIn. Приймите, пожалуйста =)

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