Тоже хочу кружку! так и запишите +1

И еще покажите мне, плиз, кнопочку "Напечатать программу конференции", чтобы она так красиво сразу и на принтер ушла.

Программу в данный момент печатать еще рано. Для печати будет сделана специальная версия, скорее всего в PDF формате. По крайней мере сейчас планируется сделать именно так.

Добрый день!
Во-первых, хочу поддержать ребят, которые говорят о том, что тестовое задание надо давать хотя бы после интервью, а не до него. Причин несколько, думаю они будут понятны из написанного ниже. Я бы предложил такую схему:
Изучение резюме и телефонный скрининг (для определения того, что человек хочет выполнять предлагаемую работу в принципе) -> техническое собеседование (лучше когда несколько человек, всей командой не обязательно, не все любят) -> тестовое задание (опционально, в них есть несомненные плюсы) -> второе интервью для определения условий итд (желательно с руководством) -> офер (для победителя).

Во-вторых, можете посмотреть видео моего недавнего выступления о том как я работу менял. Взгляд соискателя:

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

Вопрос актуальный в контексте собеседования тестировщика.
Я придерживаюсь такой позиции, что не важно как называть эти вещи, главное, чтобы человек умел их применять.
Но иногда сталкиваюсь с ситуацией, когда нужно просто знать точное определение.
Какой, например, должен быть ответ на вопрос "Перечислите методы тестирования, которые вы знаете?"
На сколько я понимаю, методы - это более широкое понятие. Типа метод "белого" и "черного ящика". Техники - это подходы в рамках какого-то метода. Типа Equivalence partitioning и Boundary-value analysis. Технологии - просто слово из рефератов и резюме.
Поправьте, если я ошибаюсь.

Похожего вопроса касались вот тут: http://software-test...9272#entry49272

Да и кроме главного направления тестирования в каких еще направлениях смотреть - HTML, sql, Java? Я просматривал чужие резюме и заметил, что много чего мелькает, но что подучить, не сильно отвлекаясь от основной темы ТЕСТИРОВАНИЕ?

Одним из возможных преимуществ для работодателя может быть знание предметной области.

Еще хотел спросить, входит ли в обязанности тестировщика исправление ошибки, на уровне исходников программы, в моем случае или это зависит от организации и предъявляемым требованиям?

з.ы. вроде осознал, Тестировщик должен найти проблему и передать в вышестоящие инстанции(н-р прогерам), а они уже будут решать проблему...

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

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

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

Интересно, сколько раз надо написать одно и тоже...
RFC - стандарт. Если вы пишете почтовый сервер - будьте добры, соблюдать все это.
Если ваша веб-програмулька не понимает всех возможных вариантов почтовых адресов - то это ХОРОШО!
В этом случае ваша программа не протеворечит этому стандарту. Но в ней будет меньше кода, и меньше ошибок, от исправления которых не станет лучше ни одному живому существу на планете.

Да и это нафиг никому не нужно, поддерживать все эти возможные адреса. И если найдется идиот с ненормальным адресом в 64 символа (или сколько их там) на домене второго уровня - то пусть он идет лесом мимо вашей программы со своим адресом.

Если вы не тестируете почтовый сервер (ну и возможно клиент тоже) - то использование всяких экзотических емэйлов - (а) трата времени и (б) создание ненужных записей в трэкере. Если бы я был программистом и ко мне бы пришли и сказали "first.(")middle.last(")@[IPv6:::12.34.56.78]" - не работает, согласно RFC, давай чинить. Я бы послал куда подальше.

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

PS: кстати [IPv6:::12.34.56.78] - нихрена невалидный Ipv6 адрес - очередной булшит