Работа тестером (собеседование)

Сорцы будут?

> Сорцы будут?

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

Эээ... на работу тестером есть собеседование? Это что за компания, если не секрет? :)

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

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

Не секрет - какая-то прокачанная голландская контора с филиалом в Киеве, занимается web'ом :).

А что обычно в тестеры людей ловят сетями по городу?

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

Опыта не имею, но попробывал бы:
0)Деление но ноль.
1)Внесение заведомо ложных переменных(будь то Ф.И.О. или другие даные). 2)Сохранение/открытие.
3)Спросит ли "Сохранить?" перед закрытием.
4)Как считает(если считает).

А дальше хз. Ни разу тестером не приходилось быть.

P.S. Завтра отпишись.

гуглить по словам "black box testing" "тестирование методом черного ящика"

почитать можно http://opensource.com.ua/contents/978594723698p.html тестировать - это ой как непросто =) полтора года проработал - ушел в программисты. Была книга очень хорошая, но я совершенно забыл название

> А что обычно в тестеры людей ловят сетями по городу?

Некоторые нанимают толпу ничего не сображающих студентов. Скоро студентам надоедат и они уходят, тогда нанимают новых :)

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

Иди лучше тостером поработай:)

Если это предложение мне адресовано, то спасибо, у меня проблем с поиском работы не было никогда :)

> у меня проблем с поиском работы не было никогда :)

ещё школу не закончил или родители - олигархи?

>Опишите где могут быть самые вероятные баги

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

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

Может под словом "умышленно" подразумевается умышленный наём индуса на пол. ставки?

Было бы хорошо, если бы действительно так :) Но вряд ли кто будет так морочиться :)

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

Во-вторых протестируй программу на предмет краевых значений, переполнений, неправильных значений и т.д. Например если программа ожидает положительное число >= 0, введи сначала 0, потом -1, 0.1, потом 99999999999999999999999, потом abc.

В-третьих протестируй программу на предмет работы в непредвиденных условиях. Например если программа рассчитана на работу в сети, попробуй выдернуть сеть во время какой-нибудь операции. Проставь read-only атрибуты туда, где программа будет что-нибудь писать. Попробуй удалить файл настроек, поудалять ветки реестра. Можно даже попробовать поудалять системные файлы программы, но с этим осторожно, программисты могут тебя побить за это :) Если это linux, запусти программу с разными ulimit-ами, например с жёстким ограничением памяти. Программа всегда должна падать культурно, без всяких Segmentation Fault-ов.

Составляй отчёты, в которых есть максимум информации о том, как воспроизвести баг. Не надо своих домыслов на предмет того, откуда этот баг мог взяться. Просто скриншот, последовательность действий, приводящая к багу (причём начинающаяся с пункта «запускаем программу»), и нестандартные условия, в которых была запущенна программа, если таковые имелись.

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

> задокуменьтировать

> стесьняйтесь

ну, ты понял, да?

fifajan, у меня есть опыт работы тестировщиком как раз web-приложений, стучи на vitel@jabber.ru

через год в москве за две штуки будут дворники работать

http://rspec.info

> Эээ... на работу тестером есть собеседование? Это что за компания, если не секрет? :)

Любая приличная девелоперская контора (начиная с монстров вроде epam-а, и заканчивая маленькими локальными конторками).

>Если знаете статьи или примеры по теме, не стесьняйтесь.

Защита от "дурака" в программах на языке Python http://gazette.linux.ru.net/lg83/evans.html

"Законы" программирования :) http://optimism.chat.ru/page_pr.htm

> Опишите где могут быть самые вероятные баги, как их документировать, и прочие комментарии.

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

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

По программной части проверяется каждый контрол, каждое поле ввода. В поля вводится как минимум корректное и некорректное значение. Если допустим диапазон, то вводится корректное, и два за разными границами. Можно граничные значения проверить. Для вещественных чисел полезно проверять как программер реализовал декодирование, понимает ли оно локаль? ;-)

В файлах проверяются пробелы в именах, нелатиница в именах (если актуально), нестандартные расширения. Проверяется спросит ли программа, если попытаться перезаписать существующий файл.

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

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

Вобще, это сложно так всё рассказать. =)

> как их документировать

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

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

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

+много, в Харькове есть тоже одна прокачанная фирма, аутсорсит в америку. Там сидит армия студентов-тестеров, за 200$ в месяц клепают формочки на задротнете.

> Вот приеду через год в Москву, буду хотеть две тысячи баксов, чувствую, это будет интересно :-)

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

Как все прошло?

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

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

"Надо" ? Если тебе "надо", то увольняй :) А вообще в продакшене, когда интервал между релизами составляет по 5-6 дней и не такое бывает.

>когда интервал между релизами составляет по 5-6 дней и не такое бывает

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

Спасибо всем за комменты, собеседование будет завтра.

Я обязательно отпишусь о результатах завтра вечером.

> В логике, может быть Но в гуе?

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

Прошел!

Была прожка, обычная бессмысленная форма, с возможностью редактирования и сохранения/открытия нелепых списков. Я нашел 35 багов за 2.5 часа, засчитали 24 из них, короче меня взяли!

Ваши советы очень пригодились, а баг который мне больше всего понравился (защитаный): в мануале написана версия 1.98, а в About'e 1.89. :)

Теперь пройти 2х недельную стажирофку (эффективные методы тестирования, тестовые скрипты и т. п.) и буду работать.