fraylina

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

немного прокомментировала по тексту:

1) Для чего нужно тестирование? Чем полезно тестирование и тестировщики заказчику? (ведь и программисты могут протестировать и кто угодно)

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

 2) У меня на работе есть чашка горячего кофе, но я должен донести его до дома таким же теплым (а дом находится далеко)+любые законы природы, науки и тд. не действуют. Я смог дать такие варианты ответа: 

• В термоемкость поместить и донести до места назначения;

• использовать телепорт; 

• использовать машину времени;

И больше идей в голову не приходило

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

3) Для чего тестировщику нужен"белый ящик"? Ведь он просто тестировщик, а не программист

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

4) Что такое "покрытие кода" (я так и не смог понять читая в интернете) и чем оно отличается от тестирования компонентов? Как я понимаю "покрытие кода" это "Покрытие кода (code coverage) — это метод анализа, определяющий, какие части ПО были проверены (покрыты) набором тестов, а какие нет". Но ведь тестирование отдельных компонентов ПО и есть 'покрытие кода" или нет?

== не встречалась в работе, но ответ по сути верный. И скорей всего тут нужно загуглить про модульное тестирование.

5) Почему используют Salesforce-платформу, а не например SQL? Т.к. их компания работает с этой платформой и является аутсорсинговой

== не понятно.

6) В чем самые важные отличия QA, QE, QC?

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

7) Например у компании 1000 тестов и при помощи автоматизации они будут проходить 4 суток, а нам надо отчет к сегодняшему вечеру? Что можно сделать кроме выбора приоритета?

== согласие всей релизной команды (тестирование, разработка, приемка, заказчик), что они не против ускорения сроков и жертвой каких-то тестов. Как говорится, вам быстро или качественно? В тестировании постоянно этот вопрос стоит ребром, заказчикам нужны доработки еще вчера, разработка выкатывает их за 1 день, а то что тестированию требуются как минимум неделя, никого не колышит. И здесь решение только совместным консилиум делается: собираются все, озвучиваются реальные сроки, если они их не устраивают - уменьшается тестовая модель, либо увеличивает число тестировщиков. Как вариант - распараллелить выполнение автотестов на разных машинах. Запросить у заказчика мощности  (тестировщики или виртуальные машины)