как тестировать вёрстку
1. Уточнить какие именно браузеры (и под какими ОС) нужны. Также, возможно, понадобятся виртуальные / физичекие доп. машины.
2. Нужны макеты.

Фактически выходит проверка макетов под браузерами + разные разрешения (если это необходимо).

Тестирование солонки, карандашей и прочея, спрашивают людей без опыта (во всяком случае это логично), кто ещё не пробовал себя в тестировании. Чтобы кандидату было проще, и смотрят в какую сторону его "ведёт". Когда он наберётся опыта, он уже взгянет на эти "упражнения" иначе. Кого-то бросает на юзабилити, многоие сразу в негатив тестинг ломятся (у них такое понятие, тестирование = поломать), план как вообще он будет это делать, мало кто пытается составить из новичков. Поэтому и мнение, что проверяется нестандартное мышление.
Для людей с опытом, эти задачки бессмысленны, намного результативнее будет спросить о том, что они тестировали на прошлой работе, как и вот тут уже можно привести конкретный пример ПО, раскажите как вы будите его тестировать (и это в том случае, если что-то не понравилось в его рассказе про прошлую работу).

P.S: Предвижу, очередные наезды на форум и его участников.. так что воздержусь от дальнейшего диалога с TC_Noob ;)

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

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

Какое ж оскорбление, я ж бисером людей назвал, исключительно из уважения!

Так не вопрос, начните собеседовать тестировщиков и задавай те вопросы, какие считаете нужными )
Те ж кто собеседуют ничего не понимают в принципах тестирования ПО, карандашей и прочих вещей, как они не поймут никак, что это абсолютно разные вещи? Но Вы-то им объясните? Кто-то же должен ;)
Только по полочкам разложите, вот как тестируется ПО.. вот здесь выделены основные фазы, а вот как карандаш.. видите - абсолютно, кардинально разные подходы!
И на форуме отпишитесь, чтобы мы тоже наконец-то хоть что-то поняли в тестировании

Метать свиней перед бисером слишком накладно, а тем более на форуме.
Когда я провожу собеседование, по крайней мере, мне интересно логика человека за конкретным примером: БЕРУ конкретное ПО и смотрю как новобранец будет тестировать, вот это я понимаю под нормальным экзаменом на собеседовании.

Ребята, которые проходят именно по таким задача, говорят, что их раньше проверяли на всяких странных тестах, что это не задачи были, а больные фантазии экзаменатора

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

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

сервис вконтакте "Аудио" - это послушать музыку, значит подразумевает умение использования плеером на компьютере
интернет-магазин - можно выполнить покупку, с определёнными ограничениями

Примеры не корректны

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

Я что-то не вижу необходимости давать такой непрофильный вопрос тестировщику, хм, это тоже самое, что спросить женщину, а какой ваш возрост?

Принципы не отличаются от тестирования ПО

Принцип разработки ПО равнозначен принципу разработки солонки?

У меня вопрос к тем, кто такие вопросы задаёт на собеседовании (тестирование солонки, карандаша, гвоздя и тому подобных предметов):
Почему вы считаете, априори, что ответ на данный вопрос является проверкой не стандартного мышления тестировщика, м?

Из моего примера, у нас головных пунктов - 10 штук

В каждом пункте по 30 функциональных пунктов-проверок

1.1
1.2
...
1.30

2.1
2.2
...
2.30
....
10.30


Предлагается каждый раз скроллировать к нужному пункту в таком случае, для шага 9.27 Выполнить шаг 3.10, правильно я понял?

Всем доброго времени суток!

Вопрос в следующем, Стоит ли описывать повторяемые шаги не ссылками?

Раскрою вопрос:

Представим вполне реальную ситуацию, в системе 10 функциональных блоков, в каждом из которых есть функции, которые повторяются в остальных,

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

Например


Как показано из примера, мы, дабы, сократить описание пишем, Выполнен шаг и номер шага

Какой я вижу плюс: Сокращение описания, сокращение самого плана тестирования

Какие я вижу минусы:
1. Нужно постоянно искать по плану тестирования тот самый шаг, т.е. представим, вы на шаге номер 100 и вам говориться, выполнить шаг 15, представляете, вам НАДО скроллировать план тестирования на шаг номер 15, ПОТОМ обратно на шаг номер 100 - это не удобно.
2. Не подготовленный человек, порой, запутывается с нумерацией, и тратит намного больше времени с проверкой, а если ему указать повторяющиеся шаги, то он, во-первых, проверит без всяких вопрос, типа, а что тут имелось ввиду, во-вторых, проверить быстрее.

Вот, собственно, и камень преткновения, как поступить правильно?

Ура, товарищи!

There are two big things in 8.7:
Support for Google Chrome browser (no Flex/Flash/Silverlight yet)
Support for testing WCF Web Services

http://smartbear.com...f6-61ba80fdc6bc

Я поднимал данную проблему на их оф сайте, поддержка умного медведя предложила решение - полный epic fail - каждый алиас привязать на переменную проекта, и через неё менять динамически мапу, охренеть =/