BornInUSSR.ca

удалено

Me:

Я не совсем с «нуля», конечно, скорее с «0,00001» . Диплом у меня “Computer Science” – опыта работы года 2 (из 19 возможных на момент поиска работы) и то очень и очень давно. Я из тех, кто потратила деньги государства в пустую  (образование же было бесплатое): закончила вуз, вышла замуж, а потом ребенок и т.д. и т.п. До Канады перерыв был лет 10, ну и в Канаде 5 лет работала в retail. Кстати этот опыт тоже мне помог.
Немного об этом – может кому помогут эти факты. На тот момент у меня был другой сертификат из Ryerson “Retail and Service Management”, по которой я прошла 8 курсов за 3 года. Начала с sales associate и последние два года работала store manager. В резюме я указывала этот опыт, российский диплом и QA certificate (про Ryrson я ничего не писала, поскольку мы посчитали, что это не work related). На интервью в банке разговор зашел о support и работе с людьми. Программами пользуется бизнес пиплы и соответственно у них возникают постоянные вопросы, требования к доработкам и т.д. Обсудили, какие бывают трудные люди, и как с ними трудно иметь дело. Обсудили мой опыт работы с людьми, и тут я им призналась, что у меня еще есть “Retail and Service Management” из Ryerson. На что в ответ я услышала “О-о-о!” и такое ощущение было, что этот рояль в кустах решил мой вопрос положительно. Так что "Люди разные нужны, профессии всякие важны".

В колледже на тот момент и на QA tester (entry level) программе преподавала Наташа – замечательный и доброжелательный человечек. Про качество обучения, я писала.
Вопрос про сертификат я чего-то не поняла. Я была рада, что его получила, и поскольку я шла через Career Edge program - то он там мне как раз и пригодился. Поскольку эта программа для recent graduates, каковым я и была на тот момент, т.к. получила сертификат.

Резюме.. Тут надо сказать огромное спасибо моему мужу (он у меня ITишник). Он мне сразу сказал, что написать резюме для себя – это очень трудная задача. И взял ее на себя. Нахваливать самого себя достаточно трудно, особенно при отсутствии опыта и наличии страха, что на интервью тебя «расколят». Свое резюме после его очередных корректировок я брала в руки с содроганием и умоляла вычеркнуть хоть какие-то совершенно ничего не говорящие мне термины. Где-то он поддавался, где-то был неумолим и убеждал меня, что это так надо. Психологическая ломка была тоже очень трудной.
Но еще раз повторюсь: все преодолимо.
Спасибо всем за добрые слова! Мне тоже чертовски приятно, что есть возможность похвастаться (YES! I DID IT!) и кто-то тебе скажет, какая ты молодец.

MrsPerkins wrote:Вопрос про сертификат я чего-то не поняла. Я была рада, что его получила, и поскольку я шла через Career Edge program - то он там мне как раз и пригодился. Поскольку эта программа для recent graduates, каковым я и была на тот момент, т.к. получила сертификат.

Вот. Вот это - какое-то ноу хау. Очень интересный вариант.
Поясню. Курсы тестеров обычно берутся не для сертификата, а для того, чтобы получить какие-то начальные знания. Сертификат просто прячется обычно под подушку, и криэйтится резюме с N лет экспириенса. Только что полученный сертификат вызывал бы в этой картинке лишние вопросы. Далее ищется работа и все.

Но Вы пошли другим путем - Career Edge program, и это интересно. Там как раз нужен сертификат, если я правильно понимаю. А можете рассказать подробнее про эту программу? Это не для меня , это для тех, кому это может пригодиться .

MrsPerkins wrote: Чем отличается waterfall от agile? Что из них лучше?

А вот кстати, что вы думаете по этому поводу? Интересно услышать альтернативное мнение, потому как нам на курсах женщина говорит, что в 90% компаний всегда используется waterfall, а agile вообще только тестеров-девелоперов и по ее мнению он неэффективен и неудобен.
Сказала, что во всех крупных компаниях Канады используют вотерфол - роджерс,все банки, белл и тд, и только в IBM говорит agile.
Как с этим дело у вас?

MrsPerkins wrote: С чего бы начала при получении задания от бизнеса? Тест план, тест cases? How are you going to handle founded defects? Но тоже помните, что я нанималась на позицию manual tester и entry level. А так технических вопросов по интервью в Интернете полно.

Я думаю, что на что-то больше чем black box testing поначалу никто нас и не возьмет.
Вообще, местами такие вопросы начальные совсем. Кто ж будет с тест cases начинать сразу, если это конечная ветка в плане, да и founded defects, само собой, просто создаются bug reports. Либо я чего-то не понимаю.

MrsPerkins wrote: Теперь мысли про позицию тестера. На сколько я понимаю, есть ручное тестирование и там, где требуются тестеры-девелоперы. На вторую я никогда не претендовала и вряд ли буду. По первой, не смотря на автоматизацию процесса тестирования, финансовые организации вряд ли когда-нибудь будут использовать только компьютеры. Уж очень много различных business rules у них в аппликациях. Бизнес логика очень сложна и динамична, и запрограммировать ее просто нет подчас времени и смысла (меняется она очень быстро). Это направление для тех, у кого нет достаточного технического опыта.

Вы хотите сказать, что кроме логики работы программы еще надо понимать некую бизнес логику?
Как нам женщина объясняет, тестеры-девелоперы нужны либо на agile либо на что-то серьезное, когда от них требуется глубокое знания программинга, но это редкость, мол.
А так обычно manual testing, automation tools и все такое... это с ее слов как я понял.

MrsPerkins wrote: Так что желаю удачи, настойчивости и веры, что будет все хорошо.

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

Me wrote:

MrsPerkins wrote:Вопрос про сертификат я чего-то не поняла. Я была рада, что его получила, и поскольку я шла через Career Edge program - то он там мне как раз и пригодился. Поскольку эта программа для recent graduates, каковым я и была на тот момент, т.к. получила сертификат.

Вот. Вот это - какое-то ноу хау. Очень интересный вариант.
Поясню. Курсы тестеров обычно берутся не для сертификата, а для того, чтобы получить какие-то начальные знания. Сертификат просто прячется обычно под подушку, и криэйтится резюме с N лет экспириенса. Только что полученный сертификат вызывал бы в этой картинке лишние вопросы. Далее ищется работа и все.

Но Вы пошли другим путем - Career Edge program, и это интересно. Там как раз нужен сертификат, если я правильно понимаю. А можете рассказать подробнее про эту программу? Это не для меня , это для тех, кому это может пригодиться .

Да, опыт и референс гораздо важнее корочки, как мне кажется, в данном вопросе.
ПОэтому и правда очень интересно, особенно касательно Career Bridge.

MrsPerkins wrote: Диплом у меня “Computer Science” – опыта работы года 2 (из 19 возможных на момент поиска работы) и то очень и очень давно. Я из тех, кто потратила деньги государства в пустую  (образование же было бесплатое): закончила вуз, вышла замуж, а потом ребенок и т.д. и т.п. До Канады перерыв был лет 10, ну и в Канаде 5 лет работала в retail. Кстати этот опыт тоже мне помог.

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

MrsPerkins wrote: Обсудили мой опыт работы с людьми, и тут я им призналась, что у меня еще есть “Retail and Service Management” из Ryerson. На что в ответ я услышала “О-о-о!” и такое ощущение было, что этот рояль в кустах решил мой вопрос положительно. Так что "Люди разные нужны, профессии всякие важны".

Действительно интересно. Может быть, как-то может сыграть моя нехитрая корка менеджера на таких вот работодателях.
Или может мне поискать работа тестера в крупных игровых компаниях типа Electronic Arts, может там им обрадует мой бэкграунд web design & 3D artist...

MrsPerkins wrote: Резюме.. Тут надо сказать огромное спасибо моему мужу (он у меня ITишник). Он мне сразу сказал, что написать резюме для себя – это очень трудная задача. И взял ее на себя. Нахваливать самого себя достаточно трудно, особенно при отсутствии опыта и наличии страха, что на интервью тебя «расколят». Свое резюме после его очередных корректировок я брала в руки с содроганием и умоляла вычеркнуть хоть какие-то совершенно ничего не говорящие мне термины. Где-то он поддавался, где-то был неумолим и убеждал меня, что это так надо. Психологическая ломка была тоже очень трудной.

Да, резюме действительно важно. Тут надо примеры видеть успешные.

Me:
Моя легенда была такова: в России у меня был большой опыт работы, по приезде в Канаду были трудности с поиском работы, нужны были деньги, пошла работать в retail, потом решила, что все таки это не мое и надо возращаться в свою среду, пошла на курсы, чтобы refresh my memory. И вот.
Голову над резюме ломали долго: трудно спрятать 5 лет проживания в Канаде, липовые референсы не придумали откуда брать, за исключением одного знакомого free lancer. Да и потом банк это все проверял и не хотелось попадаться на этом.

Career Edge. Эта программа примерно с теми же условиями, что и Career Bridge. Регистрируешся и получаешь доступ к их вакансиям. По ней платят очень мало, но есть большой шанс получить full time. Как я уже писала, в TD эти две программы очень любят.
Возможно мой путь, это для тетенек в возрасте, кто хочет стабильный заработок с хорошими условиями труда: отпуск, бенефиты и т.д. Правда, иногда мне все это напоминает "болото", где все сидят и довольно квакают - это путь не для молодых и горячих. Но мне сейчас так уютно в этом болоте после сумасшедших лет без выходных в retail. С рамками по зарплатам, я согласна с Me.
потом доотвечаю про все остальное, надо успеть отдохнуть.

Почитал я career bridge (http://www.careerbridge.ca) программу.
Кажется, я в пролете. Если "Have a minimum of 3 years full-time international work experience in his/her professional field" еще можно подделать, то на "Possess a minimum of a bachelor's degree from Canada" мое образование точно не тянет.
Жалко...
Хотя я, честно говоря, как обычно их не очень пойму. Судя по тому что я вижу вокруг, ITшники, у которых есть минимум 3 года работы в их сфере, бэчелор на эту тему и прочие требования что они хотят, найдет работу скорее всего и так без их internship.

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

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

MrsPerkins, прекрасная история, спасибо!

malcolm wrote:

MrsPerkins wrote: Чем отличается waterfall от agile? Что из них лучше?

А вот кстати, что вы думаете по этому поводу? Интересно услышать альтернативное мнение, потому как нам на курсах женщина говорит, что в 90% компаний всегда используется waterfall, а agile вообще только тестеров-девелоперов и по ее мнению он неэффективен и неудобен.
Сказала, что во всех крупных компаниях Канады используют вотерфол - роджерс,все банки, белл и тд, и только в IBM говорит agile.
Как с этим дело у вас?

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

malcolm wrote:

MrsPerkins wrote: С чего бы начала при получении задания от бизнеса? Тест план, тест cases? How are you going to handle founded defects? Но тоже помните, что я нанималась на позицию manual tester и entry level. А так технических вопросов по интервью в Интернете полно.

Я думаю, что на что-то больше чем black box testing поначалу никто нас и не возьмет. Вообще, местами такие вопросы начальные совсем. Кто ж будет с тест cases начинать сразу, если это конечная ветка в плане, да и founded defects, само собой, просто создаются bug reports. Либо я чего-то не понимаю.

Так и black-box тестинга до фига во многих компаниях. А про начальные вопросы - во-первых их задают не всегда и не везде, во-вторых хотят проверить ваши общие знания. Вы только что неполно ответили на вопрос "How are you going to handle founded defects? " --> "просто создаются bug reports".

Есть понятие Defect life Cycle и именно про него надо тут рассказывать. Попробуйте ответить сейчас.

И, кстати, а с чего бы вы начали при получении задания от бизнеса?

malcolm wrote:
Вы хотите сказать, что кроме логики работы программы еще надо понимать некую бизнес логику?

Бизнес логика (requrements, rules etc) лежит в основе работы тестера. Вы проверяете не то, как хорошо программа написана, а насколько system mets busimess requirements.

malcolm wrote: Да, это точно, курсы курсами, а главное потом найти работу и за нормальные перспективы.

Главное найти первую QA работу. Если она сразу окажется перспективной - здорово. Нет, уже с реальным местным опытом можно продолжать искать работу своей мечты.

malcolm wrote:
Вот кстати, насколько они смотрят на образование?
Я смотрел вакансии, всегда практически пишут, мол, бэчелор компьютер сайнс.

Кто "они"? Hiring manager-у ваше образование обычно не так важно, если у вас есть достаточный QA опыт по резюме. В малентьких компаниях тоже не очень на это смотрят. Но, в больших организациях, если ваше резюме попадет в HR, оно может просто не пройти дальше, если у них есть куча однотипных QA резюме, то резюме с образованием в Computer Science получат преимущество. Поэтому networking важен, если ваше резюме напрямую к Hiring manager-у попадет, шансы резко увеличиваются.

MrsPerkins wrote: Действительно интересно. Может быть, как-то может сыграть моя нехитрая корка менеджера на таких вот работодателях.
Или может мне поискать работа тестера в крупных игровых компаниях типа Electronic Arts, может там им обрадует мой бэкграунд web design & 3D artist...

Ищите везде, где можно, рано или поздно что-то найдется.

MrsPerkins wrote: Резюме.. Свое резюме после его очередных корректировок я брала в руки с содроганием и умоляла вычеркнуть хоть какие-то совершенно ничего не говорящие мне термины.

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

Lark wrote: Я про свой опыт скажу. Сама я сталкивалась только с waterfall и большинство моих QA знакомых тоже. НО! Если вам задают такой вопрос на интервью важно показать, что вы знаете разницу. И ни в коем случае не говорить, что agile не эффективен. Наоборот, после того, как вы расскажете определения, спросить, а что используете вы? Если интервьюер скажет agile, то правильная реакция - здорово, мне всегда хотелось попробовать поработать с такой методологией! Если waterfall - у меня большой опыт именно с этой методологией!

Да, это разумно.
А вот знакомый, который работает QA в Штатах, говорит, что там agile довольно часто используется.
А наша тетенька говорит, что это в 99% случаев мол для тестеров-девелоперов.
На деле не могу ничего сказать, у меня лично нет опыта вообще пока на эту тему.

Lark wrote: Так и black-box тестинга до фига во многих компаниях. А про начальные вопросы - во-первых их задают не всегда и не везде, во-вторых хотят проверить ваши общие знания. Вы только что неполно ответили на вопрос "How are you going to handle founded defects? " --> "просто создаются bug reports".
Есть понятие Defect life Cycle и именно про него надо тут рассказывать. Попробуйте ответить сейчас.
И, кстати, а с чего бы вы начали при получении задания от бизнеса?

Ну я не ставил сейчас целью красиво и полно ответить на этот вопрос, как на собеседовании.
А вообще подобные теоретические вопросы надо будет почитать еще раз более конкретно, потому что нам на курсах дают только практику. Она объяснила 1 занятие теорию - что такое тестинг, какие виды тестов бывают и что есть два метода (вотерфол и эджайл), и рассматривать мы будем только первый. Все. А потом пошла практика мануал тестинга в HP Quality Center 10.
По вопросам если...
насчет Defect life Cycle я бы сказал что-то вроде: В случае если я нахожу дефект, то начинаю дефект лайф сайкл. Создаю баг репорт, делаю ему статус open посылаю его соответствующему лицу (обычно я так понимаю это developer или qa manager, наша тетка нам говорит посылать менеджеру, но наверное это от компании зависит), дальше это лицо смотрит баг репорт и реагирует, либо чинит баг и ставит статус fixed, либо говорит, что это не баг и ставит статус rejected. Если статус fixed, то я перепроверяю баг что он действительно пофиксен и закрываю баг репорт. (А вот в случае если он rejected, допустим, но как мы знаем девелопер не всегда прав, но я считаю, что это таки баг согласно FRS, то видимо логика подсказывает, что надо сделать note что типа согласно FRS это баг и послать уже qa managerу чтобы разбирался? либо как это делается?).
Про получение задание от бизнеса - я бы начал с изучения FRS. Скорее всего даже распечатал бы, если такое возможно. Так наглядней. Дальше постарался бы понять, что именно от меня хотят протестировать (я так понимаю, в реальности не всегда далеко дают тестировать все целиком и дают на это время) - basic functionality, полная проверка, или что-то еще. Хотя наша тетенька нам говорит, что первый QA cycle обычно идет проверка всего. Но если аппликация громадна, а дедлайны короткие, то видимо надо себя как-то ограничивать? Соответственно, я бы попытался составить тест план. По пунктам, что именно я собираюсь тестировать, сначала виды теста по пунктам что буду делать, потом в каждом виде тесты, какие будут делать, а потом тест кейсы уже про каждый случай писал бы. И поехали. Верно?

Lark wrote: Бизнес логика (requrements, rules etc) лежит в основе работы тестера. Вы проверяете не то, как хорошо программа написана, а насколько system mets busimess requirements.

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

Lark wrote: Кто "они"? Hiring manager-у ваше образование обычно не так важно, если у вас есть достаточный QA опыт по резюме. В малентьких компаниях тоже не очень на это смотрят. Но, в больших организациях, если ваше резюме попадет в HR, оно может просто не пройти дальше, если у них есть куча однотипных QA резюме, то резюме с образованием в Computer Science получат преимущество. Поэтому networking важен, если ваше резюме напрямую к Hiring manager-у попадет, шансы резко увеличиваются.

"Они" я имел в виду работодатели.
Да, жаль в таком случае, что у меня не computer science. Интересно, могу ли я как-то свой graphic design или manager приспособить поближе к тестингу по смыслу...

malcolm wrote:

Lark wrote: Есть понятие Defect life Cycle и именно про него надо тут рассказывать. Попробуйте ответить сейчас.
И, кстати, а с чего бы вы начали при получении задания от бизнеса?

насчет Defect life Cycle я бы сказал что-то вроде: В случае если я нахожу дефект, то начинаю дефект лайф сайкл. Создаю баг репорт, делаю ему статус open посылаю его соответствующему лицу (обычно я так понимаю это developer или qa manager, наша тетка нам говорит посылать менеджеру, но наверное это от компании зависит), дальше это лицо смотрит баг репорт и реагирует, либо чинит баг и ставит статус fixed, либо говорит, что это не баг и ставит статус rejected. Если статус fixed, то я перепроверяю баг что он действительно пофиксен и закрываю баг репорт. (А вот в случае если он rejected, допустим, но как мы знаем девелопер не всегда прав, но я считаю, что это таки баг согласно FRS, то видимо логика подсказывает, что надо сделать note что типа согласно FRS это баг и послать уже qa managerу чтобы разбирался? либо как это делается?).

Кому открытый дефект адресовать (assigned) действительно зависит от компании. В больших все дефекты сначала просматриваются QA lead-ом (QA менеджером или Тест Координаторм), который делает первоначальный отсев и может что-то rejected уже на этом этапе. Потом QA Lead assigned defect to Development Lead и тот уже re-assigned девелоперу, который кодировал этот кусок. В маленьких возможна связь напрямую - Тестер -> девелопер.

В случае если дефект пофиксен, то он действительно закрывается. Но на интервью тут еще полезно упомянуть, что помимо собственно re-testing-а был проведен regression testing, чтобы убедиться, что не поломалось что-то другое пока фиксили этот дефект. Это делается не всегда и не для всех дефектов, так что желательно понимать логику. Кстати, это один из классических вопросов на интервью – чем retesting отличается от regression testing-a.

Так же полезно сказать, что если проблема реально не пофиксена, то дефект – Re-open. Если проблема пофиксена, но появилась другая, то первоначальный дефект закрывается, а для новой проблемы открывается новый. При всей очевидности и логичности этого процесса я постоянно сталкиваюсь с тестерами, которые стремятся в первоначальный дефект впихнуть новые проблемы.

Насчет rejected. Еше один классический вопрос на интервью вы считаете, что нашли дефект, а девелопер нет. Ваши действия? Ответ: Берем business requirement на основании которой создавался тесткейз – все было понято правильно? Если есть сомнения и есть QA Lead (менеджер), то можно обсудить с ним. Если QA Lead c тестером согласен, то он assigned дефект to Business Analyst и просит его разобраться. Если QA Lead-a нет, тестер просит BA напрямую. Если BA согласен с девелопером и докажет это тестерам, то меняем тесткейз, чтобы в будущем тестировать правильно. Если BA согласен с тестером, то дефект re-open и девелоперы меняют код. Если requrement был настолько unclear, что допускал диаметральную трактовку, то обычно в серьезных организациях QA Lead требует от BA выпустить Change Request (CR), чтобы изменить requirement.

При наличии Quality Center все эти activities идут там в Comments.

В нормальных организацих, кстати, только QA lead может Reject дефект после расследования. Остальные могут только выдавать рекомендации

malcolm wrote: Про получение задание от бизнеса - я бы начал с изучения FRS. Скорее всего даже распечатал бы, если такое возможно. Так наглядней. Дальше постарался бы понять, что именно от меня хотят протестировать

У вас пропущен важный этап. В нормальных организациях анализ Business документации занимает большое время. И задача QA Analyst-а не просто изучить requirements, но и выдать бизнесу свои вопросы и рекомендации по ним. Иногда это называется Gap Analysis. Т.е. каждый requirement должен быть для тестера clear, consistent, complete, testable etc. Не должно быть missing и duplicate requirements. Так же хороший тестер следит за version control и чтобы все документы нормально выглядели в напечатанном виде – headers/footers/нумерация страниц и т.д.

Аналогично проводится анализ Technical Design документа, который представляют девелоперы. Там надо особо следить, чтобы в Дизайне были покрыты все requirements и думать, что из дизайна можно использовать для тесткейзов и каков будет scope of regression testing.

Еще один классический вопрос на интервью – чем отличается тестер от QA Analyst-a? Ответ: тестер просто поверяет уже готовую систему, а QA Analyst пытается предотвратить ошибки до того, как они появились. Из этого логично следует следующий вопрос – а как вы пытаетесь предотвратить ошибки? Вот как раз анализом бизнес и девелоперской документации.

malcolm wrote: (я так понимаю, в реальности не всегда далеко дают тестировать все целиком и дают на это время) - basic functionality, полная проверка, или что-то еще. Хотя наша тетенька нам говорит, что первый QA cycle обычно идет проверка всего. Соответственно, я бы попытался составить тест план. По пунктам, что именно я собираюсь тестировать, сначала виды теста по пунктам что буду делать, потом в каждом виде тесты, какие будут делать, а потом тест кейсы уже про каждый случай писал бы. И поехали. Верно?

Все зависит от конкретной системы. Если это будет большой веб-сайт с кучей разных форм на десятках страниц, то вполне возможно эти формы будут тестироваться поотдельности, по мере того, как девелоперы их закодируют, а потом будет System Integration testing (SIT) и Unit Acceptance testing (UAT). Небольшие системы или системы, где тестирование на уровне модулей невозможно, сразу тестируются в SIT.

Насчет тест-планов – в больших организациях Test Plan пишет QA Lead. Он же распределяет работу между тестерами, кто за какие модули отвечает. В маленьких могут и тестеры Тест планы писать.

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

malcolm wrote: Но если аппликация громадна, а дедлайны короткие, то видимо надо себя как-то ограничивать?

Еще один вопрос на интервью – у вас большая система из 10 модулей и недостаточно времени, чтобы ее протестировать всю в деталях к назначенному сроку. Что вы будете делать? Ответ предоставляю найти самостоятельно, а то что-то я тут расписалась сегодня.

Lark, спасибо за ответ, такая информация изнутри весьма сейчас полезна.
Звучит все заумно и сложно, сразу и не запомнишь, наверное это снаружи потому что...

Lark wrote: Кому открытый дефект адресовать (assigned) действительно зависит от компании. В больших все дефекты сначала просматриваются QA lead-ом (QA менеджером или Тест Координаторм), который делает первоначальный отсев и может что-то rejected уже на этом этапе. Потом QA Lead assigned defect to Development Lead и тот уже re-assigned девелоперу, который кодировал этот кусок. В маленьких возможна связь напрямую - Тестер -> девелопер.

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

Lark wrote: В случае если дефект пофиксен, то он действительно закрывается. Но на интервью тут еще полезно упомянуть, что помимо собственно re-testing-а был проведен regression testing, чтобы убедиться, что не поломалось что-то другое пока фиксили этот дефект. Это делается не всегда и не для всех дефектов, так что желательно понимать логику. Кстати, это один из классических вопросов на интервью – чем retesting отличается от regression testing-a.

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

Lark wrote: При наличии Quality Center все эти activities идут там в Comments.

Кстати насчет Quality Center, сижу вот вожусь никак найти не могу одну функцию, которая как мне кажется весьма часто нужна и полезна.
Наткнулся на эту проблему при последнем домашнем задании, спросил на последнем уроке у тетеньки, в результате все вместе искали это дело полчаса и так и не нашли.
Вопрос в чем: вот я например в QC создал тест, создал в нем 50 тест кейсов, сделал им manual testing.
На следующий день вспомнил, что не дописал еще десяток тест кейсов. Открываю, пишу тест кейсы. Потом иду в test lab, нажимаю continue manual testing - чтобы понятное дело не пропали мои сделвнные 50 тест кейсов - а он мне новые 10 сделанные в списке не показывает.
И вот как это дело обновить, чтобы он не стирал предыдущие результаты тестинга и добавлял новые в текущем цикле - не нашли.

Lark wrote: У вас пропущен важный этап. В нормальных организациях анализ Business документации занимает большое время. И задача QA Analyst-а не просто изучить requirements, но и выдать бизнесу свои вопросы и рекомендации по ним. Иногда это называется Gap Analysis. Т.е. каждый requirement должен быть для тестера clear, consistent, complete, testable etc. Не должно быть missing и duplicate requirements. Так же хороший тестер следит за version control и чтобы все документы нормально выглядели в напечатанном виде – headers/footers/нумерация страниц и т.д.

Аналогично проводится анализ Technical Design документа, который представляют девелоперы. Там надо особо следить, чтобы в Дизайне были покрыты все requirements и думать, что из дизайна можно использовать для тесткейзов и каков будет scope of regression testing.

Еще один классический вопрос на интервью – чем отличается тестер от QA Analyst-a? Ответ: тестер просто поверяет уже готовую систему, а QA Analyst пытается предотвратить ошибки до того, как они появились. Из этого логично следует следующий вопрос – а как вы пытаетесь предотвратить ошибки? Вот как раз анализом бизнес и девелоперской документации.

Вот тут я, признаться, не совсем пойму разницу. Разницу в анализе я понял, точнее. Но вот, скажем, в вакансиях интернета очень часто QA тестера пишут то analyst, то tester, то еще как-то обзывают. При этом часто требуемые вещи пишут примерно одинаковые. Поэтому я не совсем пойму, от чего тут зависит должность?
Просто по факту самопозиционирование типа "я не просто тестер, а аналист", либо это уже карьерный рост из тестера в аналисты происходит? Должен ли обычный blаck box тестер проводить анализ документации?
А scope of regression testing сложно конечно определить так сразу, я бы решил, пожалуй, что определять надо фактом какие смежные функции затрагивает данная фишка. Но баг все равно новый может вылезти где угодно, мне кажется, в теории.

Lark wrote: Вообще прелесть тестерской работы в том, что на интервью всегда можно сказать – я работал так-то. Главное, чтобы это хотя бы приблизительно было похоже на правду тестерской жизни. Так что если тетенька, которая вас учит, имеет реальный тестерский опыт, то представьте, что вы работали в компании с такой же методологией. Но бывает полезно пообщаться с друигими реально работающими тестерами из разных компаний.

Она вроде бы как лет 15 работает в одной компании Канады тестером.
Ну вот я ж говорю, общался с тестером из США, он сказал у них agile как раз распространен...

Lark wrote: Еще один вопрос на интервью – у вас большая система из 10 модулей и недостаточно времени, чтобы ее протестировать всю в деталях к назначенному сроку. Что вы будете делать? Ответ предоставляю найти самостоятельно, а то что-то я тут расписалась сегодня.

Видимо, в этом случае надо сделать тест на basic functionality, что все базовые функции работают. Normal walk through так сказать. Типа New, Open, Close, Send все такое... а детали типа принимает ли поле номера кредитной карты текст и спецсимволы - уже дело второе тогда.

И напоследок, наткнулся вот...

malcolm wrote: Я бы сказал так... что re-testing это ре-тест самого бага, который должкн был быть пофиксен. А regression testing это ре-тестинг тех элементов, которые непосредственно затрагивает исправленный баг, для проверки не поломалось ли что-то еще рядом. Как-то так, пожалуй.

Правильно. Главное помнить, что бывает еще и другой regression testing для проекта целиком в случае, если тестируется не новая система, а enhancements к уже существующей.

malcolm wrote: Кстати насчет Quality Center, сижу вот вожусь никак найти не могу одну функцию, которая как мне кажется весьма часто нужна и полезна.
Наткнулся на эту проблему при последнем домашнем задании, спросил на последнем уроке у тетеньки, в результате все вместе искали это дело полчаса и так и не нашли.
Вопрос в чем: вот я например в QC создал тест, создал в нем 50 тест кейсов, сделал им manual testing.
На следующий день вспомнил, что не дописал еще десяток тест кейсов. Открываю, пишу тест кейсы. Потом иду в test lab, нажимаю continue manual testing - чтобы понятное дело не пропали мои сделвнные 50 тест кейсов - а он мне новые 10 сделанные в списке не показывает.
И вот как это дело обновить, чтобы он не стирал предыдущие результаты тестинга и добавлял новые в текущем цикле - не нашли.

А как вы первоначальные 50 тесткейзов в Тест Лаб загрузили?
Я не знаю, как у вас настроен Quality Center, в разных организациях QC Admin-ы могут делать разные настройки. Я работаю с древовидной структурой и там это решается просто.

Например, вам надо протестировать Login Page, какого-то сайта.

В QС Test Plan-e вы создали фолдер Login Page и создали там свои 50 тесткейзов.

Чтобы их Run (execute) в QC Test Lab создан фолдер Cycle 1 и в нем Test set - Login Page. Чтобы загрузить туда тесткейзы помещаем на Test set курсор, на центральном тулбаре есть кнопка "Select tests", а в правом фрейме появляется дерево с фолдерами из Тест Плана. Выбираем нужный фолдер "Login Page" и кликаем на зеленую стрелку вверху тулбара правого фрейма "Add Tests to Test set". И все 50 тесткейзов загружены в Test Lab

Когда вы создали новые 10 тесткейзов в Тест плане в том же фолдере, то действия аналогичные - курсор в Тест Лабе на тест set -> select Tests -> только добавляем тесткейзы в тест set по одному - помещаем на него курсор и нажимаем зеленую стрелку.

malcolm wrote: Вот тут я, признаться, не совсем пойму разницу. Разницу в анализе я понял, точнее. Но вот, скажем, в вакансиях интернета очень часто QA тестера пишут то analyst, то tester, то еще как-то обзывают. При этом часто требуемые вещи пишут примерно одинаковые. Поэтому я не совсем пойму, от чего тут зависит должность?

В разных компаниях разные titles. Бывают и Test Analyst, QA Analyst, QC (Quality Control) analyst, Software tester, а обязанности примерно одинаковые. Я же говороила больше о фолрмальных определениях.

malcolm wrote: Просто по факту самопозиционирование типа "я не просто тестер, а аналист", либо это уже карьерный рост из тестера в аналисты происходит? Должен ли обычный blаck box тестер проводить анализ документации?

Позиционируйте себя как QA Analyst. Должен ли обычный blаck box тестер проводить анализ документации ответ - да, если он подключился на тот момент, когда обсуждаются requrements. Просто бывают случаи, когда опытные QA analyst-ы анализируют документацию и пишут тысячи тесткейзов, а на execution потом нанимают других тестеров.

Lark wrote:

malcolm wrote:
Еще один вопрос на интервью – у вас большая система из 10 модулей и недостаточно времени, чтобы ее протестировать всю в деталях к назначенному сроку.

Видимо, в этом случае надо сделать тест на basic functionality, что все базовые функции работают. Normal walk through так сказать. Типа New, Open, Close, Send все такое... а детали типа принимает ли поле номера кредитной карты текст и спецсимволы - уже дело второе тогда.

Примерно так. Так же важно подчеркнуть, что все sensitives areas должны быть протестированы полностью. Кстати, поле ввода номера кредитной карты - это sensitive area. Кроме того, если невозможно протестировать систему целиком, то обязательно должен задокументирован Risk Analysis. Но это уже больше QA Lead-а обязанность.

Mrs Perkins, спасибо большое за рассказ!!! Пошла смотреть лекции.

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

P.S. Жду 14 июля и буду писать свой отчет с длинным списком special thanks to...

Goldy, я не MrsPerkins, но в одном из постов выше уже все есть: и про образование, и про опыт. Я не наезжаю, просто зачем человеку два раза одно и то же повторять.
С нетерпением жду отчета. Не знаю, что должно произойти 14 июля, но надеюсь, что что-то очень хорошее.
P.S. Я вот завтра выйду на новую работу, освоюсь немного и тоже напишу отчет.

Во - у всех повалило!

Тов.Голди, небось, 14-го тоже на работу выходит?

Lark wrote: А как вы первоначальные 50 тесткейзов в Тест Лаб загрузили?
Я не знаю, как у вас настроен Quality Center, в разных организациях QC Admin-ы могут делать разные настройки. Я работаю с древовидной структурой и там это решается просто.
Например, вам надо протестировать Login Page, какого-то сайта.
В QС Test Plan-e вы создали фолдер Login Page и создали там свои 50 тесткейзов.
Чтобы их Run (execute) в QC Test Lab создан фолдер Cycle 1 и в нем Test set - Login Page. Чтобы загрузить туда тесткейзы помещаем на Test set курсор, на центральном тулбаре есть кнопка "Select tests", а в правом фрейме появляется дерево с фолдерами из Тест Плана. Выбираем нужный фолдер "Login Page" и кликаем на зеленую стрелку вверху тулбара правого фрейма "Add Tests to Test set". И все 50 тесткейзов загружены в Test Lab
Когда вы создали новые 10 тесткейзов в Тест плане в том же фолдере, то действия аналогичные - курсор в Тест Лабе на тест set -> select Tests -> только добавляем тесткейзы в тест set по одному - помещаем на него курсор и нажимаем зеленую стрелку.

Да, я все так и делаю, но как выбрать тест кейсы по одному и добавить их в текущий сет - вот что не получается!
Посмотрите, пожалуйста, вот эти два скрина
http://www.box.net/shared/2yfa1xc541
http://www.box.net/shared/cno3n0gi4q
Видите, у меня в test lab есть фолдер ver.1.00, в нем есть test set First QA cycle, и в нем 5 подпунктов. В центре видите подпункт 2.1.2.1 Purchase - там было внутри 100 test cases, я добавил еще 20, и хочу добавить их туда в уже имеющийся (видите там статус failed, я их уже сделал и сделал баг репорты, хочу только новые добавить).
Выбираю справа в test plan tree пункт 2.1.2.1 Purchase тест сет, жму стрелку зеленую влево, и он просто создает новый сет в центральном окне с таким же именем Purchase, в котором все тест кейсы непройденные (скрин 2).
А вот как добавить в уже существующий наполовину законченный тест сет еще внутрь тест кейсов - ума не приложу.

Lark wrote: Позиционируйте себя как QA Analyst. Должен ли обычный blаck box тестер проводить анализ документации ответ - да, если он подключился на тот момент, когда обсуждаются requrements. Просто бывают случаи, когда опытные QA analyst-ы анализируют документацию и пишут тысячи тесткейзов, а на execution потом нанимают других тестеров.

Понял, спасибо.

Lark wrote: Примерно так. Так же важно подчеркнуть, что все sensitives areas должны быть протестированы полностью. Кстати, поле ввода номера кредитной карты - это sensitive area. Кроме того, если невозможно протестировать систему целиком, то обязательно должен задокументирован Risk Analysis. Но это уже больше QA Lead-а обязанность.

Да, интересные детали, конечно.