Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 70
Наш QA тимлид порадовал вопросом который он всегда задаёт на собеседованиях: Представте ситуацию, вам дали 2 одинаковых проекта, т.е с одинаковым приоритетом, одинаковые по сложности и т.п., с какого проекта вы начнёте?
ИМХО. С любого из этих двух. Если нет дополнительных условий.
Каких ответов я жду на собеседовании по тестированию
другой вариант 'правильного' ответа
На последней картинке уволили тест менеджера, который дает сразу два одинаковых проекта не уточняя с какого начать?
Ну что ж… Если все решает тест — менеджер, то наверное и правда до-свидания :) при том, что решать предоставили абстрактному «мне». А в целом:
Пост так и называется, каких ответов Я жду.
Пост так и называется, каких ответов Я жду.
Фу, отстой. Где одинаковый приоритет, если приоритет определяет менеджер? Брехня и ловушка.
Какой больше вдохновляет, если нет, как уже сказали, дополнительных условий.
Как-то вы сильно напряглись на "я жду". Коммент-то чуть отвлечённый, как дополнительная пища для размышлений. А вопрос сводится к тому, что если работаешь в команде не надо боятся спрашивать если что-то не знашь или не понимаешь. Этот навык тоже полезный, таже порой полезней некоторых технических навыков.
а когда мне давали два проекта, то кто определил, что они одинаковые по признакам приоритет/сложность/прочее? если это было мне озвучено, то да, я определяю с какого начать — тут хоть монетку кидай, если иначе никак. А если постановщик проектов, то с какого фига я виноват оказался? А если два проекта поступили от разных людей, то должен быть кто-то, кто разрулит конфликтную ситуацию с проектами — например мой непосредственный руководитель либо же они между собой разберутся и выставят мне для более критичного проекта приоритет выше
Вы заморачиваетесь, а вопрос-то простой. Это то же самое, что начинать рассуждать на тему насколько форма и содержание лампочки соответствует груше из известной загадки.
разве тестировщик не должен, как вы выразились, заморачиваться?
Есть хорошее выражение: не делать из мухи слона, оно подходит и для тестировщика и для слесаря и вообще для всех. А уменее правильно оценить задачу одно из самых важных, а то так можно заморачиваться на тестирование поведение софта во время солнечных затмений и разных фаз луны, но ведь это уже перебор, согласитеьсь.
На мой взгляд абсолютно фиалетово одинаковы или нет проекты. Есть у проекта Product-owner. Те кто ближе к нему те и решают какой проект в первую очередь, а какой во вторую. От тестировщика не требуется решать судьбу проекта, он лишь может высказать мнение «Я вот тут нашел ошибку и мне кажется это ...», но не более!
Так что самый правильный ответ на этот вопрос, на мой взгляд, это спросить у своего руководителя\его зама\руководителя проекта и т.д. и т.п.
Так что самый правильный ответ на этот вопрос, на мой взгляд, это спросить у своего руководителя\его зама\руководителя проекта и т.д. и т.п.
Если перефразировать «проект» -> «задача» (task), то вопрос собственно каждодневный:
приходит две задачи по одному проекту — реализованный функционал передали в тестирование. Приоритеты, критичность, сроки и прочая одинаковые, пометок ПМ в комментариях о срочности нет. Какую делать?
1. Спросить у тест лида.
2. Я сам тест лид. Спросить у ПМ.
3. Я тест лид. ПМу фиолетово. Любую.
4. Я тест лид. ПМу не фиолетово, он обозначает. Вставить ему «люлей» за то, что тратит чужое время.
5. Я тест лид. Решаю сам, ибо никаких отметок о срочности нет.
6. Я тест лид. Отдаю команде тестирования в разработку обе одновременно, разным людям.
Я так думаю, что холивары можно прекратить?
приходит две задачи по одному проекту — реализованный функционал передали в тестирование. Приоритеты, критичность, сроки и прочая одинаковые, пометок ПМ в комментариях о срочности нет. Какую делать?
1. Спросить у тест лида.
2. Я сам тест лид. Спросить у ПМ.
3. Я тест лид. ПМу фиолетово. Любую.
4. Я тест лид. ПМу не фиолетово, он обозначает. Вставить ему «люлей» за то, что тратит чужое время.
5. Я тест лид. Решаю сам, ибо никаких отметок о срочности нет.
6. Я тест лид. Отдаю команде тестирования в разработку обе одновременно, разным людям.
Я так думаю, что холивары можно прекратить?
С проекта, имеющего бОльшую стратегическую ценность для существования компании. Если один проект — очередной договор с крупным постоянным заказчиком, а второй — полуслучайный, то начинать надо с первого.
Спасибо!
Я пока не представляю где есть централизованное хранилище методик воспитания такого специалиста и его рабочего цикла.
Можно надеяться, на то, что вы дадите хабровцам своё целостное видение?
Можете чуток прояснить разницу между тестовым сценарием и тестовым комплектом, состоящим их тестовых случаев?
Я пока не представляю где есть централизованное хранилище методик воспитания такого специалиста и его рабочего цикла.
Можно надеяться, на то, что вы дадите хабровцам своё целостное видение?
Можете чуток прояснить разницу между тестовым сценарием и тестовым комплектом, состоящим их тестовых случаев?
В тестовый комплект собираются тестовые случаи по какому — то общему признаку: например «Комплект по проверке текстовых полей» — т.е. туда войдут те кейсы, которые проверяют различные поля на различных формах системы с различными входными данными. Эти кейсы заведомо не будут зависеть друг от друга, скорее всего будут покрывать части совершенно разных пунктов требований (пунктов ТЗ, мокапов и т.д.) и никак не увяжутся в единый БП использования системы. Тем не менее, появись такая надобность — вот они — в комплекте.
Тестовый сценарий — все же проверки увязанные с БП использования системы, например «БП управление доступом», в рамках которого производится и проверяется CRUD на учетной записи… Я бы не сказал, что в сценарий попадают кейсы в чистом виде: там именно набор действий пользователя, разделенный вехами проверок, что все идет как надо. И все шаги сценария зависят один от успешности другого.
Тестовый сценарий — все же проверки увязанные с БП использования системы, например «БП управление доступом», в рамках которого производится и проверяется CRUD на учетной записи… Я бы не сказал, что в сценарий попадают кейсы в чистом виде: там именно набор действий пользователя, разделенный вехами проверок, что все идет как надо. И все шаги сценария зависят один от успешности другого.
Должен ли, по Вашему, тестировщик знать, что такое OWASP Top 10 и делать какой-то минимальный набор проверок базового функционала перед каждым релизом?
Тут вопрос скорее политический. Правильно их делать, но!.. тестировщик как лицо наемное не может диктовать свое видение лицам ответственным за продукт. Сиречь: надо предложить ПМу, тех. директору, owner`у проводить эти проверки, хотя бы с определенной периодичностью, обосновать эту необходимость. Далее решение за ними. Отвечая на вопрос:
1. Он должен суметь найти информацию по OWASP в случае возникновения необходимости и понять ее.
2. Перед каждым релизом… Нет. Скорее раз в определенной время. (период не обязательно должен быть привязан к релизам).
Любая проверка — деньги компании и задача сотрудников — экономить, но не забывая о функциональных обязанностях.
1. Он должен суметь найти информацию по OWASP в случае возникновения необходимости и понять ее.
2. Перед каждым релизом… Нет. Скорее раз в определенной время. (период не обязательно должен быть привязан к релизам).
Любая проверка — деньги компании и задача сотрудников — экономить, но не забывая о функциональных обязанностях.
Хорошая статья! Но возникает сразу вопрос: а что делать, если есть продукт, который кажется, полностью готов, но по нему нет ни одного документированного требования? В чем будет состоять тестирование в этом случае? В чем будет заключаться его цель? Ведь требований нет, проверять на соответствие, — если рассуждать формально, — нечего.
Ну как же нечего? Если нет прямых требований, то всегда ВСЕГДА есть косвенные. На соответствие им и проверять. И не забывать, что «здравый смысл» — тоже источник косвенных требований :)
Это же страшно неформально. Мне кажется, что если человек собирается самостоятельно тут понапридумывать требования, то надо его остановить. Как Вы сами сказали, есть заказчик. Правильнее будет того формализовать сначала требования, а потом уже тестировать. Верно ведь?
Где? Где тот злодей, что хочет придумывать требования? Выявлять! Батенька, и только выявлять. Грань действительно очень тонкая, но ведь в этом и заключается квалификация — выявить существенное и отбросить несущественное. Хороший пример: есть движок карт ArcGis. Там по умолчанию настройка на работу с роликом мыши «реверсивная» (от себя — отдаление от подложки, на себя — приближение). Если Вы откроете публичные ресурсы с картами (Yandex, Google и пр.), то увидите, что «средний» пользователь в РФ «привык» к обратному. Ни одно ТЗ (кроме написанного военным в пятом поколении) не будет содержать прямого требования о направлении вращения ролика мыши и соотносить его с изменением масштаба. Что получается? Требование косвенное. Ухудшит отношение пользователей к приложению на этом движке, если вовремя не выявить и не исправить? Да. получается, что никто ничего не «придумал», а профит хороший.
Ну и есть такие люди, которые говорят — «пользователь привыкнет»… Думаю, что не надо объяснять почему это неправильно.
Ну и есть такие люди, которые говорят — «пользователь привыкнет»… Думаю, что не надо объяснять почему это неправильно.
Тут дело не в формальности процесса, а в выпуске качественного решения. Тестирование одних косвенных требований не закроет риск того, что в прямых дыра.
Мое мнение здесь совпадает с вашим: целью тестирования должно быть в этом случае восстановление требований. Лучше сразу подключать к процессу аналитика и тестировщика, чтобы они работали в паре.
Вообще, случай для практики тестировщика наверное не самый типичный, поскольку команды, практикующие разработку без спецификаций, обычно стараются обходиться и без формального тестирования.
Мое мнение здесь совпадает с вашим: целью тестирования должно быть в этом случае восстановление требований. Лучше сразу подключать к процессу аналитика и тестировщика, чтобы они работали в паре.
Вообще, случай для практики тестировщика наверное не самый типичный, поскольку команды, практикующие разработку без спецификаций, обычно стараются обходиться и без формального тестирования.
Продукт реализует какие либо БП, к БП предъявляются определённые требования и собственно эти самые требования предъявляются и к продукту реализующему процессы, а так-же есть косвенные требования.
Ощущение от сообщения такое, будто это был итеративный процесс, и в данный момент он успел пройти несколько внедрений у Заказчика.
В таком случае я понимаю, что все протоколы встреч с Заказчиком, где он просил развить/исправить/добавить функции, по каким-то причинам сожжены.
Другим безумным вариантом такой ситуации является авторская разработка без персонализированного Заказчика — например, попытка толкнуть на рынок коробочный продукт.
Но даже в таком случае должен был существовать дизайн-замысел «стартапера» в письменном виде, хотя бы и без свистелок и перделок, добавленных в реализации.
В отсутствии спецификации требований программистам всё равно придётся описать словами то, что они пытались реализовать, то есть написать спецификацию для существующего софта. Что, в общем, тоже не поздно — тестировщику как раз удобно присутствовать при создании или «создании» спецификаций.
В таком случае я понимаю, что все протоколы встреч с Заказчиком, где он просил развить/исправить/добавить функции, по каким-то причинам сожжены.
Другим безумным вариантом такой ситуации является авторская разработка без персонализированного Заказчика — например, попытка толкнуть на рынок коробочный продукт.
Но даже в таком случае должен был существовать дизайн-замысел «стартапера» в письменном виде, хотя бы и без свистелок и перделок, добавленных в реализации.
В отсутствии спецификации требований программистам всё равно придётся описать словами то, что они пытались реализовать, то есть написать спецификацию для существующего софта. Что, в общем, тоже не поздно — тестировщику как раз удобно присутствовать при создании или «создании» спецификаций.
не боишься, что теперь соискатели будут тебе отвечать заученными вопросами из твоей статьи? :)
Возможно, что-то вроде: «потому что без тестирования невозможно выявить истинное состояние производимого продукта, и насколько он соответствует ожиданиям потребителя».
По-моему, это не ответ на вопрос. Мало ли что без чего невозможно, но выбирает человек что-то одно, почему именно тестирование-то?
Ошибка – несоответствие производимого продукта требованиям, прямым или косвенным.
Ну так с учётом этого, «поиск ошибок» раскрывается в «поиск несоответствия производимого продукта требованиям, прямым или косвенным».
Чем это отличается от «комплекс мероприятий, направленный на проведение проверок на соответствие производимого продукта требованиям, к нему предъявляемым (прямым и косвенным).»?
Поиск несоответствия и проверка на соответствие абсолютно разные, с точки зрения анализа результата, процессы…
>Почему вы решили стать тестировщиком?
…
Возможно, что-то вроде: «потому что без тестирования невозможно выявить истинное состояние производимого продукта, и насколько он соответствует ожиданиям потребителя».
Вы отлично описали зачем необходимо тестирование, но на вопрос не ответили, т.к. верного ответа как вы и сказали здесь нет.
Скорее вопрос на отсеивание неправильных… да и посмотреть на реакции человека, попытаться установить контакт с ним…
Вопрос из серии «а почему хотите работать»? Или «почему вы любите яблоки, а не груши»? Я считаю такие вопросы некорректными. Если вы хотите отсеять «заблудившихся», то так и говорите, что есть требования по усидчивости, внимательности, способности к монотонному труду, и спрашивайте — готов ли соискатель с этому. Если человек понимает на что подписывается, то и проблем с этим будет меньше.
Кстати, среди вопросов вы совсем не озвучивали владение инструментарием.
Вы интересуетесь чем тестировщики уже умеют пользоваться (напр. питон, selenium, git, etc)?
Как опыт работы с ПО влияет на собеседование?
Вы интересуетесь чем тестировщики уже умеют пользоваться (напр. питон, selenium, git, etc)?
Как опыт работы с ПО влияет на собеседование?
Я — немного идеалист в этом плане. Я верю, что при возникновении необходимости любой адекватный человек сумеет освоить инструмент за обозримое время. В рамках собеседования интересуюсь, но решения на основе этих данных не принимаю. Причины две:
1. Заявить, что умею пользоваться «вот этим вот всем» может каждый, а на деле умения не ушли дальше двух кликов по меню оснастки.
2. Это выясняется в процессе работы на испытательном сроке. И осваивается тоже: элементарные навыки за три месяца адекватный человек приобретет.
1. Заявить, что умею пользоваться «вот этим вот всем» может каждый, а на деле умения не ушли дальше двух кликов по меню оснастки.
2. Это выясняется в процессе работы на испытательном сроке. И осваивается тоже: элементарные навыки за три месяца адекватный человек приобретет.
«Соискатель, который доходит за полтора часа беседы до восьмого вопроса, – редкость, такого я возьму на работу юниором. » — а зачем юниору знать что-то больше, чем ответ на первый вопрос?
Второй по частоте ответ: «потому что я хочу работать в IT и тестирование – самый простой путь» (читай: у IT специалистов высокая зп, а в тестировании не нужно ни знаний, ни навыков, но зп тоже достаточно высокая!).
…
Единственно правильного ответа нет, но вот указанные три и их производные – точно неправильные
Почему Вы не хотите, чтобы будущий тестировщик был честным?
Если человек может выполнять некое множество видов деятельности, а хочет работать там, где больше заплатят, то что в этом зазорного?
Последний год вместо собеседований у меня получаются импровизированные лекции
Немного настораживает, так как это вряд ли помогает понять, стоит ли брать человека на работу.
Складывается впечатление, что у вас есть сложившееся и чёткое представление о том как должен быть построен процесс тестирования, и вы способны определять политику тестирования в компании. Но зачем же узнавать насколько близко человек уже соответствует этой политике? Не важнее ли то, насколько человек хочет работать, может и готов меняться, понимает ли основы, чтобы потом его немного доучить.
Интересно, вы не пробовали задавать вопрос: кто такой тестировщик? Мне кажется, что ответы будут очень разными, и скажут много о кандидате.
Дзен-интервью:
— Почему вы решили стать тестировщиком?
— Воротник застегните, пожалуйста.
— Почему вы решили стать тестировщиком?
— Воротник застегните, пожалуйста.
Я думаю первый вопрос нужно переформулировать.
Например, я стал тестировщиком, совершенно случайно — брату понадобилась помощь в проекте, где он был программистом, а мне нечего делать было на летних выходных. Другое дело, почему я после этого опыта все еще остался в тестировании — вот тут да, это интересно.
Может потому, что я делать ничего не умею, кроме этого; может потому, что это очень легко, а платят много; как-то мне встретился потрясающий ответ: «потому что мне нравится указывать другим на их недостатки».
В общем, причина стать тестировщиком может быть любой и даже вполне глупой и той, которая сразу же вешает неприятный ярлык. Но если речь не про первую работу у человека, а человека с опытом, гораздо интереснее, почему он все еще работает и ищет работу тестировщиком.
Например, я стал тестировщиком, совершенно случайно — брату понадобилась помощь в проекте, где он был программистом, а мне нечего делать было на летних выходных. Другое дело, почему я после этого опыта все еще остался в тестировании — вот тут да, это интересно.
Может потому, что я делать ничего не умею, кроме этого; может потому, что это очень легко, а платят много; как-то мне встретился потрясающий ответ: «потому что мне нравится указывать другим на их недостатки».
В общем, причина стать тестировщиком может быть любой и даже вполне глупой и той, которая сразу же вешает неприятный ярлык. Но если речь не про первую работу у человека, а человека с опытом, гораздо интереснее, почему он все еще работает и ищет работу тестировщиком.
Что бы я хотел услышать? Возможно, что-то вроде: «потому что без тестирования невозможно выявить истинное состояние производимого продукта, и насколько он соответствует ожиданиям потребителя».
это ответ на вопрос зачем вообще нужно тестирование.
а вы спрашиваете, почему кто-то решил стать тестировщиком. имхо, вы не то ожидаете.
ответ на вопрос, почему выбрана та или иная профессия никогда не будет привязан к отрасли. это всегда личный опыт по жизни или личные взгляды.
это ответ на вопрос зачем вообще нужно тестирование.
а вы спрашиваете, почему кто-то решил стать тестировщиком. имхо, вы не то ожидаете.
ответ на вопрос, почему выбрана та или иная профессия никогда не будет привязан к отрасли. это всегда личный опыт по жизни или личные взгляды.
Соискатель, который доходит за полтора часа беседы до восьмого вопроса, – редкость, такого я возьму на работу юниором. Доходящий за то же время до 11 вопроса может быть принят на должность ведущего тестировщика, однако за 240 проведенных собеседований таких оказалось только 5 человек!
Может, я слишком требователен к ответам?
Скорее всего, вы просто давно или маловато были собеседуемым :)
Вы учитываете факторы ниже или ищете чуть ли не идеальных кандидатов?
• Человек может волноваться, особенно в условиях ограниченного времени.
• Человек может плохо владеть речью, плохо излагать свои мысли. Некоторые хорошо делают, но плохо объясняют.
• Области его и ваших знаний могут плохо пересекаться.
• Вы одни и те же вопросы постоянно спрашиваете, что означает, что вы их хорошо разобрали и хорошо помните данную часть предметной области, но это не значит, что другие сделали акцент на этом.
• Как давно человек работал с технологией, о которой вы его спрашиваете. Может он когда-то был в ней экспертом, но забыл ее, так как не приходилось ей пользоваться последние несколько лет.
Большинство это не учитывают, а потом ходят сказки о том, что пришел чувак с опытом 10 лет на собеседование, а его знания и на джуниора не тянут. Конечно, и такое бывает, но гораздо чаще бывает, что собеседующий не смог увидеть реальный уровень собеседуемого.
Ниже конечно, только мое мнение, но может и другие будут с ним согласны.
Попробуйте предложить собеседуемым выбирать – устно или письменно отвечать на вопросы. В случае письменного варианта предоставить им час-полтора времени без вашего присутствия, оставив возможность обратиться к вам в случае непонимания, о чем спрашивается в вопросе. А также в случае кандидатов с опытом, сначала задавать вопросы 7-11, потом 5-6, а потом остальные. 3-ий вопрос и из него вытекающее я бы вообще убрал или оставил на последок, т.к. только из кольи выбьете подобными вопросами.
Глядишь, и на поиск 5 человек на должность ведущего тестировщика, нужно будет опросить 50 человек, а не 240.
Доброго дня!
Возможно Вы невнимательно читали статью. Я поясню:
Время никто не ограничивает, более того полтора часа — это лично моя метрика. Если у соискателя на вакансию тестировщика базовые вещи вызывают такое количество затруднений, значит он не особо готовился. Хотя знал о том, что пойдет на собеседование не с HR, а с будущим руководителем. И у него есть зп ожидания, которые надо оправдать.
Этому человеку придется владеть речью и формализовать свои мысли в той форме, в которой его поймут разработчики, ПМ и прочие. Это проблема, которую должно было решить среднее образование. Я денег за обучение юниоров, опытных и прочих не беру. Я набираю людей, которые с первого дня работы начинают получать зарплату, в том числе и юниоры — среднюю по СПб, а то и выше.
Это абсолютно точно так, но я и не требую от него четкого знания буква в букву. Тоже писал об этом. Я согласен брать людей с другим набором знаний, но вот они не согласны работать на правах и зарплате стажера. Поэтому я жду, что они проведут хотя бы минимальную подготовку по той области, в которой собираются работать.
Хм, по моему все вопросы относятся к весьма и весьма базовым по тестированию. Я не спрашиваю устройство сетей, особенности картографических проекций, знания API google карт или еще какую-то специфику… Я спрашиваю, а чем Вы, собственно, пришли сюда заниматься?
Что мешало освежить свои знания и навыки перед собеседованием?
Вообще, я благодарен за Ваш ответ, он действительно конструктивен и вопросы, которые Вы в нем поднимаете — бич собеседований в IT. Отвечая на Ваше утверждение: я каждые полгода обязательно хожу на пару — тройку собеседований — это хорошо дает понять в какую сторону развивается рынок труда, что интересует работодателей. И стараюсь избегать общих ошибок, которые вижу на этих собеседованиях. И форма собеседования именно поэтому и построена в форме беседы, а не экзамена. Именно поэтому я стараюсь объяснять свою точку зрения и слежу за «откликом» на нее. А самое главное — я не считаю, что те, кто не прошел собеседование — плохие или ничего не знают, я считаю, что мы не сработаемся, вот и все. «Нет плохих специалистов, есть не на своем месте» (с) Вот и я стараюсь избежать людей не на своем месте, так как это принесет проблемы не только мне, но и им самим.
Возможно Вы невнимательно читали статью. Я поясню:
• Человек может волноваться, особенно в условиях ограниченного времени.
Время никто не ограничивает, более того полтора часа — это лично моя метрика. Если у соискателя на вакансию тестировщика базовые вещи вызывают такое количество затруднений, значит он не особо готовился. Хотя знал о том, что пойдет на собеседование не с HR, а с будущим руководителем. И у него есть зп ожидания, которые надо оправдать.
• Человек может плохо владеть речью, плохо излагать свои мысли. Некоторые хорошо делают, но плохо объясняют.
Этому человеку придется владеть речью и формализовать свои мысли в той форме, в которой его поймут разработчики, ПМ и прочие. Это проблема, которую должно было решить среднее образование. Я денег за обучение юниоров, опытных и прочих не беру. Я набираю людей, которые с первого дня работы начинают получать зарплату, в том числе и юниоры — среднюю по СПб, а то и выше.
• Области его и ваших знаний могут плохо пересекаться.
Это абсолютно точно так, но я и не требую от него четкого знания буква в букву. Тоже писал об этом. Я согласен брать людей с другим набором знаний, но вот они не согласны работать на правах и зарплате стажера. Поэтому я жду, что они проведут хотя бы минимальную подготовку по той области, в которой собираются работать.
• Вы одни и те же вопросы постоянно спрашиваете, что означает, что вы их хорошо разобрали и хорошо помните данную часть предметной области, но это не значит, что другие сделали акцент на этом.
Хм, по моему все вопросы относятся к весьма и весьма базовым по тестированию. Я не спрашиваю устройство сетей, особенности картографических проекций, знания API google карт или еще какую-то специфику… Я спрашиваю, а чем Вы, собственно, пришли сюда заниматься?
• Как давно человек работал с технологией, о которой вы его спрашиваете. Может он когда-то был в ней экспертом, но забыл ее, так как не приходилось ей пользоваться последние несколько лет.
Что мешало освежить свои знания и навыки перед собеседованием?
Вообще, я благодарен за Ваш ответ, он действительно конструктивен и вопросы, которые Вы в нем поднимаете — бич собеседований в IT. Отвечая на Ваше утверждение: я каждые полгода обязательно хожу на пару — тройку собеседований — это хорошо дает понять в какую сторону развивается рынок труда, что интересует работодателей. И стараюсь избегать общих ошибок, которые вижу на этих собеседованиях. И форма собеседования именно поэтому и построена в форме беседы, а не экзамена. Именно поэтому я стараюсь объяснять свою точку зрения и слежу за «откликом» на нее. А самое главное — я не считаю, что те, кто не прошел собеседование — плохие или ничего не знают, я считаю, что мы не сработаемся, вот и все. «Нет плохих специалистов, есть не на своем месте» (с) Вот и я стараюсь избежать людей не на своем месте, так как это принесет проблемы не только мне, но и им самим.
Доброго времени суток!
Я уточню, что не в области тестирования работаю.
Так что, я здесь многие вещи пишу с точки зрения программиста.
Конкретно по Вашим вопросам – я ничего не скажу, т.к. не разбираюсь в данной области.
А так вполне могут быть и другие причины, часть из которых я и перечислил в первом посту.
Имхо, этот уровень на порядок ниже, чем необходимый для прохождения собеседования.
И с каких это пор образование решает психологические проблемы?
И скорее всего правильно делают. Вы им на данном этапе делаете встречное предложение платить соответствующую зарплату, если их знания окажутся выше ожидаемых вами, или выдавать им премию если на испытательном сроке от них будет пользы больше ожидаемой вами? Я ни разу не слышал подобного предложения, а хотелось бы.
Допустим в Вашем направлении стало неперспективно работать (направление устарело или зарплаты стали низкими). Но у вас есть неплохая финансовая подушка. Вы согласитесь устроиться джуниором на длительный срок в соседнем направлении, где немалая часть ваших знаний вполне актуальна, но вам скажут, что им чихать на ваш опыт в соседнем направлении?
Лично я – нет. Либо устроюсь временно и сбегу сразу, как найду компанию, где меня устроят условия работы. Хотят – пусть ищут дальше или набирут студентов, потратят года 3 на их обучение тому, что человек из соседней области за полгода освоит на том же уровне.
Скажу на примере программистов — senior в одной области примерно равен midle в той, с которой он не работал. Переобучиться под другую область программирования обычно не занимает слишком много времени. Так как хоть и технологии другие, многие вещи пересекаются, да и есть понимание, как надо работать, что от тебя хотят, как решать проблемы.
Время, объем знаний, работа на которой приходится колбасить по 12 часов в сутки, пятеро детей :)
Освежите за недельку-две перед собеседованием все то, на что вы потратили десяток лет жизни. Кто знает, что собеседующему придет спросить в голову.
Я уточню, что не в области тестирования работаю.
Так что, я здесь многие вещи пишу с точки зрения программиста.
Если у соискателя на вакансию тестировщика базовые вещи вызывают такое количество затруднений, значит он не особо готовился.
Конкретно по Вашим вопросам – я ничего не скажу, т.к. не разбираюсь в данной области.
А так вполне могут быть и другие причины, часть из которых я и перечислил в первом посту.
Этому человеку придется владеть речью и формализовать свои мысли в той форме, в которой его поймут разработчики, ПМ и прочие. Это проблема, которую должно было решить среднее образование.
Имхо, этот уровень на порядок ниже, чем необходимый для прохождения собеседования.
И с каких это пор образование решает психологические проблемы?
Я согласен брать людей с другим набором знаний, но вот они не согласны работать на правах и зарплате стажера.
И скорее всего правильно делают. Вы им на данном этапе делаете встречное предложение платить соответствующую зарплату, если их знания окажутся выше ожидаемых вами, или выдавать им премию если на испытательном сроке от них будет пользы больше ожидаемой вами? Я ни разу не слышал подобного предложения, а хотелось бы.
Допустим в Вашем направлении стало неперспективно работать (направление устарело или зарплаты стали низкими). Но у вас есть неплохая финансовая подушка. Вы согласитесь устроиться джуниором на длительный срок в соседнем направлении, где немалая часть ваших знаний вполне актуальна, но вам скажут, что им чихать на ваш опыт в соседнем направлении?
Лично я – нет. Либо устроюсь временно и сбегу сразу, как найду компанию, где меня устроят условия работы. Хотят – пусть ищут дальше или набирут студентов, потратят года 3 на их обучение тому, что человек из соседней области за полгода освоит на том же уровне.
Скажу на примере программистов — senior в одной области примерно равен midle в той, с которой он не работал. Переобучиться под другую область программирования обычно не занимает слишком много времени. Так как хоть и технологии другие, многие вещи пересекаются, да и есть понимание, как надо работать, что от тебя хотят, как решать проблемы.
Что мешало освежить свои знания и навыки перед собеседованием?
Время, объем знаний, работа на которой приходится колбасить по 12 часов в сутки, пятеро детей :)
Освежите за недельку-две перед собеседованием все то, на что вы потратили десяток лет жизни. Кто знает, что собеседующему придет спросить в голову.
Больше похоже, что вам не люди в отдел нужны, а просто на желание поднять свое ЧСВ. И вопросы больше похожи на вопросы препода из бурсы какой-нить, оторванного от реальности того-же тестирования в реальности. Знаете, я не мало в жизни повидал теоретиков с подвешенным языком, но вот ни одного из них не могу припомнить как продуктивного сотрудника. Зато обратных ситуаций пруд пруди.
+100500, маладца, наш чувачок.
Мой фильтр тестироващика (ДА/нет)
1. Тесты надо ПИСАТЬ на основе TDD и существующего API
2. Исходный код вам НЕ ДАДУТ
3. Готов писать один и тот же тест и выполнять его же сто раз БЕЗ использования средств АВТОМАТИЗАЦИИ
1. Тесты надо ПИСАТЬ на основе TDD и существующего API
2. Исходный код вам НЕ ДАДУТ
3. Готов писать один и тот же тест и выполнять его же сто раз БЕЗ использования средств АВТОМАТИЗАЦИИ
Разница только в том, что я практикую :)
И должность руководителя получил не за то, что сын директора. Вообще не родственник (ни на прошлом месте, ни на этом). Более того руководителя первый раз увидел на собеседовании. И он (мой непосредственный руководитель) вырос из разработчиков и неплохих, так как его софтом для внутреннего назначения вовсю пользуются до сих пор. А начинал в одиночку. Более того, можно много высказываться в общем смысле, но мой отдел из 4 человек (включая меня) справляется с 9 проектами разного направления, без задержек сроков и срыва метрик по уровням качества. В то время, как многие компании вынуждены нанимать по 7-9 человек на один такой проект. Так что позволю все таки себе заметить, что ЧСВ у меня обосновано. А людей я на собеседованиях не унижаю, а пытаюсь вытянуть до нужного уровня. И даже те, кого я не взял к себе работать, в конечном итоге говорят: «спасибо».
И должность руководителя получил не за то, что сын директора. Вообще не родственник (ни на прошлом месте, ни на этом). Более того руководителя первый раз увидел на собеседовании. И он (мой непосредственный руководитель) вырос из разработчиков и неплохих, так как его софтом для внутреннего назначения вовсю пользуются до сих пор. А начинал в одиночку. Более того, можно много высказываться в общем смысле, но мой отдел из 4 человек (включая меня) справляется с 9 проектами разного направления, без задержек сроков и срыва метрик по уровням качества. В то время, как многие компании вынуждены нанимать по 7-9 человек на один такой проект. Так что позволю все таки себе заметить, что ЧСВ у меня обосновано. А людей я на собеседованиях не унижаю, а пытаюсь вытянуть до нужного уровня. И даже те, кого я не взял к себе работать, в конечном итоге говорят: «спасибо».
тестировщик, выпей йаду и успокойся.
программист со стажем 25 лет
программист со стажем 25 лет
Рискну не согласиться сразу по нескольким пунктам. Для начала, с определений.
Определений в сфере тестирования масса, и куча противоречит друг другу. Ввиду отсутствия общепринятого стандарта (хотя есть и ISO, ГОСТ и ISQTB), к примеру, понятие тестирование/специалист по тестированию может отличаться от одной компании/проекта, как боинг от москвич 412.
Начнем с определения тестирования.
Тот же ISQTB, де факто стандарт в Заходней Европе, считает что тестирование — процесс как определения соответствию требований, так и по поиску дефектов. Гост (основан на ISO) — указывает, что тестирование, это операция, которая заключается в определении одной или нескольких характеристик продукта (пруфлинк: testrussia.ru/doc/12119_2000.pdf)
Так что, в определении тестирования, понятно лишь одно — это процесс (ну или, комплекс мероприятий, если вам угодно). Цель — неизвестна, т.к. не указан тип тестирования. В процессе тестирования мы можем как определять соответствия требованиям, так и просто выяснять реальное поведение системы — и это тоже будет тестированием.
К примеру, мы можем не знать ожидаемую нагрузку на сетевое приложение, но это не мешает нам провести нагрузочные и стресс тесты — чтобы знать(задокументировать) пределы возможностей. Мы не знаем, сколько будет пользователей (ну стартап у нас, ща модно). Но мы знаем, что если больше чем Х, то нужно срочно бежать за новым сервером. Пример преувеличенный, для наглядности.
С целью тестирования — все вообще не просто. И по хорошему, я бы не выяснял про сферическую цель тестирования в вакууме. Цель тестирования должны сказать заказчики тестирования (проектный менеджер, разработчик, в общем тот, кто это тестирование просит. Заказчик программы, на худой конец).
И если специалист грамотный, он знает — что целей тестирования может быть тыщи. Но в основном — что-то да выяснить. Количество багов, или что-то еще — покажетвскрытие ретроспектива.
Виды тестовой документации… Опять же, сферические в вакууме? Или все, известные в отрасли?
В одной веселой зарубежной компании, Тест план — это огромный документ, описывающий в основном стратегию, видение, цели, риски. И ни слова про сами тесты! В другой — тест план представляет собой набор тестовых сценариев, планируемых выполнить в определенную итерацию. Одну компанию закрыть, а штат тестировщиков — уволить? Или в джуниоры перевести?
Тестирование ПО, это, все еще, молодая и динамично развивающаяся отрасль. Одни люди тестируют веб формы мышкой, другие производят автоматическое тестирование электрочайника ассемблером (ну, наверное :) ). Есть определенный базис, и с опытом появляется видение общей картины.
Каких ответов жду я на собеседовании по тестированию? Не сферических в вакууме, а дающих понять, соответствует ли конкретный кандидат на конкретную позицию, и как у нас с бюджетом. И как он вольется в команду. А какую книжку он читал — Канера, или учебное издание «Теоретические основы тестирования программных продуктов» — не важно, в общем. Во многих компаниях до старшего тестировщика вообще не требуется понимать что-либо кроме бизнес-домена и умения работать с баг-треккером и тестируемым приложением. И главное, ловить, таки, баги.
Есть, таки есть! спецы, которые книжек не читали. И не хотят. Но ловят баги, собаки, а рядом сидят дипломированные тестеры, и пишут грамотные тест планы, которые ничего не дают. Но это уже лирика.
Сумбурно как-то вышло, простите :)
Определений в сфере тестирования масса, и куча противоречит друг другу. Ввиду отсутствия общепринятого стандарта (хотя есть и ISO, ГОСТ и ISQTB), к примеру, понятие тестирование/специалист по тестированию может отличаться от одной компании/проекта, как боинг от москвич 412.
Начнем с определения тестирования.
Тот же ISQTB, де факто стандарт в Заходней Европе, считает что тестирование — процесс как определения соответствию требований, так и по поиску дефектов. Гост (основан на ISO) — указывает, что тестирование, это операция, которая заключается в определении одной или нескольких характеристик продукта (пруфлинк: testrussia.ru/doc/12119_2000.pdf)
Так что, в определении тестирования, понятно лишь одно — это процесс (ну или, комплекс мероприятий, если вам угодно). Цель — неизвестна, т.к. не указан тип тестирования. В процессе тестирования мы можем как определять соответствия требованиям, так и просто выяснять реальное поведение системы — и это тоже будет тестированием.
К примеру, мы можем не знать ожидаемую нагрузку на сетевое приложение, но это не мешает нам провести нагрузочные и стресс тесты — чтобы знать(задокументировать) пределы возможностей. Мы не знаем, сколько будет пользователей (ну стартап у нас, ща модно). Но мы знаем, что если больше чем Х, то нужно срочно бежать за новым сервером. Пример преувеличенный, для наглядности.
С целью тестирования — все вообще не просто. И по хорошему, я бы не выяснял про сферическую цель тестирования в вакууме. Цель тестирования должны сказать заказчики тестирования (проектный менеджер, разработчик, в общем тот, кто это тестирование просит. Заказчик программы, на худой конец).
И если специалист грамотный, он знает — что целей тестирования может быть тыщи. Но в основном — что-то да выяснить. Количество багов, или что-то еще — покажет
Виды тестовой документации… Опять же, сферические в вакууме? Или все, известные в отрасли?
В одной веселой зарубежной компании, Тест план — это огромный документ, описывающий в основном стратегию, видение, цели, риски. И ни слова про сами тесты! В другой — тест план представляет собой набор тестовых сценариев, планируемых выполнить в определенную итерацию. Одну компанию закрыть, а штат тестировщиков — уволить? Или в джуниоры перевести?
Тестирование ПО, это, все еще, молодая и динамично развивающаяся отрасль. Одни люди тестируют веб формы мышкой, другие производят автоматическое тестирование электрочайника ассемблером (ну, наверное :) ). Есть определенный базис, и с опытом появляется видение общей картины.
Каких ответов жду я на собеседовании по тестированию? Не сферических в вакууме, а дающих понять, соответствует ли конкретный кандидат на конкретную позицию, и как у нас с бюджетом. И как он вольется в команду. А какую книжку он читал — Канера, или учебное издание «Теоретические основы тестирования программных продуктов» — не важно, в общем. Во многих компаниях до старшего тестировщика вообще не требуется понимать что-либо кроме бизнес-домена и умения работать с баг-треккером и тестируемым приложением. И главное, ловить, таки, баги.
Есть, таки есть! спецы, которые книжек не читали. И не хотят. Но ловят баги, собаки, а рядом сидят дипломированные тестеры, и пишут грамотные тест планы, которые ничего не дают. Но это уже лирика.
Сумбурно как-то вышло, простите :)
Тест план — это огромный документ, описывающий в основном стратегию, видение, цели, риски.
И в той же (или очень похожей на ту) компании тест-кейс — это сценарий использования приложения конечным потребителем ранжированный по частоте использования.
До сих пор стыдно, как я на собеседовании в нормальную компанию пытался вспомнить эту формулировку и разочарование на лицах собеседовавших когда после минуты вспоминания я выдал ЭТО.
К сожалению, Вы бы не прошли собеседование на тестировщика с Вашими знаниями…
По сути — верно. Только вот и статья-то написана о том, чего именно мне и нужно. А по факту: тот же ISQTB — сам себе противоречит в терминах и является, по сути своей, просто компиляцией всех терминов и их определений, сводкой методологий. Я же пытаюсь предложить то, что построено самим на основе опыта работы в данной профессии и применимо к 95% проектов, как по тестированию ПО, так и по тестированию любой предметной области, в том числе бизнес- процессов. Для меня в итоге важно, чтобы человек понимал куда пришел — для этого беседа и вопросы. Важно, чтобы я понимал насколько мы с человеком будем говорить на одном языке и одними терминами. Как-то так.
После первого пункта не читал. Такую неадекватность на главной давно не видел.
Разработчик с пятнадцатилетним стажем.
Многие моменты крайне спорны. Пожалуй, соглашусь с другими комментаторами в том, что первый же вопрос отбивает желание читать дальше, поскольку совершенно нелогичен.
Автор перепутал мотивацию кандидата с причиной организации собеседования. Выявление качества продукта — это не причина почему человек решил стать тестировщиком, это причина наличия вакансии тестировщика. Это необходимо разработчику.
А тестировщику как раз должен быть интересен сам процесс тестирования. Мозги у него должны быть так устроены. Ему должно быть интересно раз за разом тыкать одну и ту же кнопку, раз за разом начинать все тесткейсы сначала и не сойти при этом с ума.
Многие моменты крайне спорны. Пожалуй, соглашусь с другими комментаторами в том, что первый же вопрос отбивает желание читать дальше, поскольку совершенно нелогичен.
— Почему вы решили стать тестировщиком?
— «потому что без тестирования невозможно выявить истинное состояние производимого продукта, и насколько он соответствует ожиданиям потребителя»
Автор перепутал мотивацию кандидата с причиной организации собеседования. Выявление качества продукта — это не причина почему человек решил стать тестировщиком, это причина наличия вакансии тестировщика. Это необходимо разработчику.
А тестировщику как раз должен быть интересен сам процесс тестирования. Мозги у него должны быть так устроены. Ему должно быть интересно раз за разом тыкать одну и ту же кнопку, раз за разом начинать все тесткейсы сначала и не сойти при этом с ума.
korvinriner
А можете прояснить в чем отличие «тестового сценария» от «тестового случая»? На первый взгляд, из Вашего описания выше, они одинаковы!
А можете прояснить в чем отличие «тестового сценария» от «тестового случая»? На первый взгляд, из Вашего описания выше, они одинаковы!
Кратко: сценарий проверяет набор идей и содержит много ожидаемых результатов, каждый из которых критичен для реализации одного завершенного БП пользователя (например ЖЦ учетной записи пользователя).
Тестовый случай — проверяет только одну идею и содержит один ожидаемый результат, т.к. проверяет только одну функцию продукта (например работу валидатора на поле в форме).
Тестовый случай — проверяет только одну идею и содержит один ожидаемый результат, т.к. проверяет только одну функцию продукта (например работу валидатора на поле в форме).
судя по первому вопросу, лучшим ответом на должность программиста будет «потому что без программирования невозможно разработать качественный продукт, выполняющий все условия, представленные заказчиком»
если вы хотели бы услышать это, а не «мне просто это нравится», то хороших специалистов найти будет сложно
если вы хотели бы услышать это, а не «мне просто это нравится», то хороших специалистов найти будет сложно
Добрый день!
Очень жду продолжения статьи.
Очень жду продолжения статьи.
Прочитал... Вам в аналитики надо. Вам там хорошо будет...
P.S. Статья о том, почему Вы классный тестеровщик, а все остальные ничтожны :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Каких ответов я жду на собеседовании по тестированию