Сообщений в теме: 28

[clipsa]

 

Подготовка среды для Windows-приложения, DOS- или Linux- слегка отличается.. И это именно реальные действия на проекте.

А для чего админы нужны?
 

 

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

Ольга! Красавица вы моя, я ж говорю что я знаю на чем написано, и я знаю весь функционал на изусь. Я просто тупо не понимаю нафига это справшивать? НАФИГА это в резюмехах пишут? Просто так, что бы чем-то там померяться?

 

Потому что те, кто спрашивают не знают знаете вы или нет. Спрашивают чтобы это узнать...логично же нет? :)

[clipsa]

 

Подготовка среды для Windows-приложения, DOS- или Linux- слегка отличается.. И это именно реальные действия на проекте.

А для чего админы нужны?

На небольших проектах нет админов тестовых сред. Администрированием тестовых сред занимаются, как правило, тестировщики.

[urururka]

Фак! Логично! Чет я затупил с этой точки зрения. Большое мерси всем!

[urururka]

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

[Little_CJIOH]

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

А это от вас зависит. Например на прошлом месте работы эпик был: пользователю недоступен свежезагруженый ресурс. Начали дебажить.

1) маршрутизатор не знает где лежит ресурс.

2) менеджер ресурсов знает где лежит ресурс.

3) в логах маршрутизатора есть нотификация об изменении статуса ресурса и запрос к менеджеру ресурсов.

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

А вот тут уже начинаются детали, в которых, как известно дьявол.

Менеджер ресурсов не один, их 3, но смотрят все в одну базу.

База чуть более чем база, она replica-set, то есть отказоустойчивый кластер, в нашем случае из 3-х нод.

Запись в базу идет в мастер, подтверждение с ожиданием majority, то есть запись считается выполненной, когда хранение подтвердили большинство нод. но большинство - это не все. А на какую ноду базы пойдет менеджер ресурсов? разумеется на ближайшую, внезапно, это localhost.

То есть, на момент отправки нотификации об изменении статуса ресурса возможна ситуация, когда 1 из 3-х менеджеров ресурсов еще не имеет свежей информации о маршрутах. Добро пожаловать в чудный мир асинхронных систем и неконсистентных данных.

 

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

[urururka]

@#$% чувак, ты огонь! Кланюсь в пол =))))

Но это же единичный случай, не? Большинство задач же на уровне интерфейса? Или это большинство задач только для джунов и мидлов, а крутые тестеры все подряд могут?

[Little_CJIOH]

@#$% чувак, ты огонь! Кланюсь в пол =))))

Но это же единичный случай, не? Большинство задач же на уровне интерфейса? Или это большинство задач только для джунов и мидлов, а крутые тестеры все подряд могут?

Что такое интерфейс? это то, во что пользователь мышкой тыкает? Не, не видел.

У меня это специализация, я всю "жизнь" тестирую бэкенд, сервисы, железо. Теперь вот добрался до распределенных высоконагруженных систем, наслаждаюсь, мечтаю поработать с проектом на hadoop построенном.

И да, в интерфейсы я не лезу, там много ньюансов которые я не знаю, и высокая конкуренция. А я на зарплату даже миддла не согласен, даже на время, и не люблю тесноту.

[Petrov.Sergey]

@#$% чувак, ты огонь! Кланюсь в пол =))))

Но это же единичный случай, не? Большинство задач же на уровне интерфейса? Или это большинство задач только для джунов и мидлов, а крутые тестеры все подряд могут?

Нет, это не единичный случай.

Я тоже на 80-90% бэкендщик. И у меня тоже случаются различные детективчики.

 

А вопрос "на чём было написано тестируемое Вами приложение", например, может иметь такой подтекст: сумеешь ли ты читать код, чтобы получше разобраться в ошибке?

Или: Если знаешь, на чём было написано ПО, значит можешь знать тонкости языка => сможешь бить по "больным местам".

 

Например, РНР нетипизированный, в котором '' == null == 0 == false. И я своих коллег поначалу не раз на этом ловил.

Любой вопрос, даже если Вы не понимаете его смысла или "зачем его задали" имеет свою какую-то подоплёку.

[VinnieJohns]

Помимо всего вышесказанного, вопрос "а на чём было написано приложение" может быть задан для "просто поговорить". Small talk. Познакомиться с кандидатом, начать общение. Всё-таки, в контексте собеседования, не о собаках же с кандидатом говорить! 

 

Ответ может показать ваш кругозор.

Описание одного из продуктов, с которым мне довелось работать, выглядело бы так:

- движок написан на С(++), он платформонезависим и позволяет работать в Windows, DOS, Linux;

- интерфейс Windows-части написан на Qt, данная библиотека крайне удобна для локализаций, потому что там есть функция автоматического растягивания границ элементов;

- интерфейс для DOS и Linux написан на Allegro.

 

Чувствуете разницу?)

 

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