Хм, оппоненты видимо не пришли спорить. Жаль.

Тому, кто предлагает мне тестировать ракету, отвечаю: я не говорил, что без требований можно работать всегда.

 

Тестовую программу с описанием. Могу дать ссылку на такую программу - если не хотите сами писать.

Любой реальный, известный сайт.

ИМХО, это более эффективно, чем гипотетическая программа и сотрясение воздуха.

Прямо в офисе? Или на дом?

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

А вы на собеседованиях людям что предоставляете потестировать, реальные программы, реальные требования, или всё-таки гипотетические программы?

В соседней теме разгорелся спор, можно ли тестировать фичу, если требований к ней не существует.

Я утверждаю, что не только можно, а иногда иначе никак. Готов объяснить свою позицию аргументированно, послушаю аргументы оппонентов.

Если нет спеки, нет программы, то смысл тестировать воздух? 

Ведь будет как в старом анекдоте: Послушай, Гиви, ты чей друг – мой или медведя?

Если что и тестируется данным воздухом то стрессоустойчивость.

Если есть программа, то уже другой разговор - уже можно провести тестирование.

О, ещё один человек считает, что без требований работать невозможно. Жаль, но это не соответствует действительности.

Если хотите - давайте не будем забивать эту тему оффтопиком, я создам новую про требования.

Забудьте вы про слово собеседование.Тут не важно, собеседование это или нет. Если спеки нету или она с "откровенным бредом" (БА на кол ?) или спека есть, но некоторые моменты не указаны, то спрашиваете, например, "Какие требования к полю "Пароль" ?" - ответ "должен быть не менее 8 символов, должен состоять из латинских букв и цифр. Длина не более 40 символов"

 

Конечно я  согласен, что надо думать собственной головой.

 

но не согласен с этим:

 

Это звучит как "я не хочу думать сам, пускай другой умный дядя придумает за меня, какие проверки мне надо провести".

Вы противоречите сам себе. Вместо того, чтобы подумать, что пароль должен быть от 8 до 40 символов, вы требуете этого ответа от аналитика.

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

А если это банковская система, вас не удивит требование только букв и цифр? Я бы настаивал на том, что спецсимволы надо позволять вводить в пароле.

А если у вас логин можно вводить на русском языке, то почему запрещать вводить русские буквы и в пароле?

 

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

Если тестировщик не может принять решение, что является багом, а что нет, без подключения аналитика, то грош ему цена.

 

И про собеседование. Это очень важно, потому что в моей компании на собеседовании при первом же упоминании кандидатом слова "требования" я отвечаю "требований нет". И если кандидат впадает в ступор - он нам не подходит.

Это не значит, что такой ответ не подойдёт на собеседовании в другой компании. Но новичку, который спрашивает про задачу с собеседования, важно понимать, что существуют разные варианты.

При чем здесь вообще собеседование ? В любом случае, если есть фича - вы обязаны спросить - "есть спека или нет". Имхо, это должен быть первый вопрос. Что вас так разозлило ? Ж)

При том, что автор темы указал, что это вопрос с собеседования.

Ну вот вы спросили, есть ли спека. Вам ответили - "нету". Ваши дальнейшие действия?

Или дали спеку с откровенным бредом.

 

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

В тестировании 1 пункта обратите внимание на то, что тестируете во 2м пункте. Большинство идей применимо и там.

 

Вообще, когда просят что-то протестировать, то нужна спека - хоть какая-нибудь

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

А есть спеки нет вообще? А если она есть, но состоит из одной строки "сделать стандартный логин диалог"?

А если в конце концов там написано, что пароль должен состоять только из цифр и быть не длиннее 3 символов?

 

Нечто, отдалённо напоминающее Continious Integration выполняется ~7 часов, это порядка 800 "тестов". Если поделить, получается 30 секунд, но это нечестное измерение, потому что тесты идут параллельно.

Десктопный продукт, самописная система, пару десятков виртуалок в работе.

 

Если параллельно, то надо просто это значение (30 секунд) умножить на количество потоков, и получится искомая цифра.

 

Не получится, потому что значение потоков не константное. Очень грубо можно считать, что параллельно выполняется 10-15 тестов, но в течение времени это значение сильно меняется.

Чтобы не забивать тред оффтопиком, давайте считать, что 7 минут.

Нечто, отдалённо напоминающее Continious Integration выполняется ~7 часов, это порядка 800 "тестов". Если поделить, получается 30 секунд, но это нечестное измерение, потому что тесты идут параллельно.

Десктопный продукт, самописная система, пару десятков виртуалок в работе.

С любым термином может быть такая двусмысленность. В частности, с интеграционным тестированием оба варианта имеют право на существование.

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

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

Ещё порадовало, что инженер от 50, а старший от 60. Вилка, видимо, не более 10ки? =)

Вообще все современные браузеры имеют Developer Tools (F12 чаще всего), которые в частности показывают скорость загрузки каждого элемента страницы.

Это то, что вам надо, или вы ищете что-то другое?

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

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

Всё зависит от того, какой подход работодатель хочет увидеть в дальнейшей работе потенциального коллеги.

Мне бы не понравился ответ BadMF, если бы он был категоричным, как в последних постах.

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

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

Например, так: (0, 1); (6,4); (9,9).

 

А идеальным с моей точки зрения было бы попробовать сначала уточнить все сомнения (насчёт наличия кнопки 0 и всё в таком духе), а потом выдать соответствующий ответ.

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

QA Team Lead, Санкт-Петербург, недавно взял ипотеку. Могу попробовать помочь. Пишите в личку при желании, обменяемся скайпами.

Поздравляю коллег с профессиональным праздником!

Желаю всем найти компанию, которая будет вам подходить во всём, которой будете подходить вы, чтобы работа приносила много-много удовольствия.

Разбитие на классы эквивалентности должно происходить с точки зрения

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

Это верно с точки зрения опыта тестировщика в аналогичных проектах. Просто когда нам урезают количество тестов до 3х, особой возможности разгуляться с вариантами нет. Если бы она была, я бы обязательно проверял кейсы с суммой меньше 10, ровно 10, строго от 10 до 20, ровно 20. К сожалению, это уже 4 теста.
 

Но я к тому, что изначально можно детализировать классы эквивалентности, не прибегая к термину "граничные условия".

С этим соглашусь. Просто граничные условия именно в виде такого термина более понятны, чем "класс эквивалентности: граничное значение"

 

Есть тестирование классов эквивалентности и  граничных условий.

Я не хочу вас расстраивать, но... Любое закрытое множество может быть разбито как минимум на два класса эквивалентности - множество граничных точек и множество внутренних точек.

 

Хм, то есть вы утверждаете, что в любой реализации программы из первого поста 1 и 10 ведут себя одинаково, 2-9 тоже, но не так же, как 1 и 10?

Это мне кажется необоснованным предположением.

 

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

Виноват, перепутал вас с Сергеем Петровым.

Кстати, сегодня на свежую голову посмотрел свой предыдущий пост, упущен ещё интересный момент.

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

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

Я правильно понимаю, что есть всего три класса эквивалентности при тестировании чисел:

 

 

1. заданный по требованиям интервал;

2. всё, что меньше левой границы интервала;

3. всё, что больше правой границы интервала.

И границы отдельно тестировать не надо, это лишняя трата времени?

Есть тестирование классов эквивалентности и  граничных условий.

Эти две техники всегда идут рука об руку, хотя формально являются двумя разными техниками.

Так вот, давайте начнём с классов эквивалентности. В условиях задачи их три:

1. Допустимые значения. В математической нотации [1,10]

2. Недопустимые ниже минимального. (-infinity, 1) либо (-infinity, 0], как вам больше нравится.

3. Недопустимые выше максимального. (10, infinity)

 

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

 

С точки зрения граничных условий, мы должны проверить 1 и 10. Это граничные условия для набора допустимых значений (а не 2 и 9, как вы написали).

Также мы можем проверить 0 и 11, как граничные условия 1 и 3 классов соответственно.

 

А вообще, конечно, техника классов эквивалентности сильна в теории, на практике её не применяет почти никто. В том плане, чтобы применять осознанно, обоснованно и правильно. Я уже не раз советовал на этом форуме новую книгу Канера Domain Testing Workbook, в ней как раз отлично разбирается, как применять это на практике.

 

Спасибо за ответ. 

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

Предположим админы не дружелюбные (это не правда) и отправляют ..... в случае если нет конкретных данных...

 

Мой пример:

384-512mb of ram

1ghz

100mb ethernet

 

Достаточный минимум для начала испытаний ... 

Но ети данные вычитал на каком то форуме, не подтвержденные...

Есть разные сервера виртуализации. Например, есть VMware workstation и VMware Player, которые можно скачать в триальном режиме и установить непосредственно на свою рабочую машину.

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

Посмотрите в сторону виртуализации, это будет более экономичное и гибкое решение, чем делать 10 серверов (или 10/х серверов с х сетевыми картами каждый).

 

Куатор, а как у вас получилось, что входные данные из "от 1 до 10" превратились в "от 1 до 10 и от -1 до -10"?

Условие: "целых чисел от одного до десяти ", целые числа это и отрицательные тоже (пруф)

 

Отлично, что такое от 1 до 10? Подсказка, это либо 1<x<10, либо 1<=x<=10.

Про "от 1 до 10 по модулю" в условии не сказано ни слова.

 

Я не автор предлагаемого варианта, но в принципе понимаю ход мыслей при построении указанных множеств.

Все они преследуют следующие цели:

1) хотя бы в одном тесте первое слагаемое должно быть = 1

2) хотя бы в одном тесте второе слагаемое должно быть = 1

3) хотя бы в одном тесте первое слагаемое должно быть = 10

4) хотя бы в одном тесте второе слагаемое должно быть = 10

5) плюс надо проверить значения, близкие к границе (2 и 9)

6) надо проверить хотя бы одним тестом переполнение.

...вырезан кусок...

Собственно, сравнивая предложенную чуть выше абстрактную задачу и предложенное пользователем vmaximv решение, у меня возникает вопрос: зачем в тестах проверяются числа (А+1) и (В-1) ? Причём проверяются жёстко и безапелляционно. Они не являются граничными + они не являются "любыми внутри отрезка".

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

О-хо-хо. Во-первых, ваше утверждение, что надо проверять 2 и 9, абсолютно не имеет ничего общего с классами эквивалентности и граничными условиями. С этой точки зрения проверять 2, 5 или 9 - абсолютно всё равно.

Во-вторых, 0 и 11 - это элементы классов эквивалентности "меньше минимума" и "больше максимума". Если нет никаких дополнительных знаний о программе, этот вариант ничем не лучше и не хуже вариантов -256 и 1337.

Куатор, а как у вас получилось, что входные данные из "от 1 до 10" превратились в "от 1 до 10 и от -1 до -10"?

Зачем скрывать фамилию, если она светится в почте, в прилинкованном документе?

Линка на сертификат не работает.

Да и вообще, вставлять линки в резюме, имхо, неэффективно. Большой процент читающих резюме печатают его. На бумаге в линку не ткнёшь.

 

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