Сразу видно продвинутого тестераGatchinskiy писал(а):... с "юнит тестинга" может и не доходят, а вот когда "интегрейшн тестинг" начинается их уже не остановить, идут потоком ...Alusya писал(а): Да будет вам известно в некоторых нормальных тимах принята практика "юнит тестинг", когда баги просто не доходят до тест тима. Надеюсь эта практика - не исключение, иначе грустно...
Интересно, а в "нормальных тимах" тестеры есть, и чем они занимается, если баги до них не доходят и все исполняемые модули идеально работают? Тестируют требования и пользовательскую документацию?Alusya писал(а): Да будет вам известно в некоторых нормальных тимах принята практика "юнит тестинг", когда баги просто не доходят до тест тима. Надеюсь эта практика - не исключение, иначе грустно...
Никто не спорит, тестеры нужны, но перекладывать на них всю работу по тестированию нельзя, а некоторые этого не понимают (были у нас такие кадры на интервью). У нас тест тим относительно небольшой, 7 человек на 50 девелоперов, поэтому если не делать девелопер тестинг, то им придется очень туго.Meadie писал(а): Юнит тестирование - это всего лишь самое начало процесса тестирования. Даже в команде с идеальными девелоперами (а таких не бывает!!!), QA должно заниматься тестированием разрабатываемого модуля - функциональным тестированием (если девелопер допустил ошибку в коде, например, из-за недопонимания требований, то он мог сделать аналогичную ошибку и в соответствующем юнит-тесте), негативным тестированием (попытка сломать программу путем поиска корнер кейсов - девелоперы это в юнит тестах не делают), а также тестированием пользовательского интерфейса и юзабилити.
Я не касаюсь интеграционного и регрессионного тестирования, а также нагрузочного тестирования, включая симуляцию продакшн энвайронмента. Для большого количества ошибок (классический пример - ошибки связанные с синхронизацией выполнения потоков в многопользовательской системе, когда сто конкаррент юзеров работают без проблем, а на тысяче все падает) юнит тестированием в принципе нельзя ничего сделать.
Безусловно, все зависит от самого продукта, степени его зрелости, сложности и требований к его качеству. Также важен используемый SDLC, как часто выпускаются новые версии - раз в неделю и раз в месяц - это две большие разницы. Но вообще говоря, отношение 7 девелоперов на 1 тестера - это очень большое отношение. Мне доводилось работать только в компаниях с отношением от 1:1 до 4:1.Alusya писал(а): Никто не спорит, тестеры нужны, но перекладывать на них всю работу по тестированию нельзя, а некоторые этого не понимают (были у нас такие кадры на интервью). У нас тест тим относительно небольшой, 7 человек на 50 девелоперов, поэтому если не делать девелопер тестинг, то им придется очень туго.
Могу похвастаться - у меня в тиме из 10 ПРов только один является багом (остальные фитчи) и я лично работала на проекте, где багов просто не было обнаружено когда продукт попал в умелые руки тестеров, правда это скорее исключение, но это к тому, что идеальные девелоперы таки встречаются
И кто вам сказал, что корнер кейсы не являются частью унит тестинга?
Пишется тест код для всех кейсов, включая выбрасывание эксепшенс.
Количество строк в юнит тестах порой превышает количество строк в программе.
Так что единственное, что остается для тест тима - это интегрейшн тестинг, ведь увы не все тимы идеальные
Насчет UI согласна, там юнит тестинг практически не возможен...
И еще, о недопонимании требований - это извините какой должен быть менеджмент, что нормально задачу поставить не может? Я вообще о таком не слышала. Что, действительно такое встречается здесь?
User Acceptance Tests делают тестеры в тех компаниях, где баги уровня unitest не выпускаются девелоперами. Например, протестировать несколько сложных топологий (заранее согласованных с заказчиком) и сдать результаты в виде имеджей проложенного трафика + логи + репорты Телусу на audit. Это этап за который компания получает хорошие деньги. Кстати это тесты, которые я делала как "тим плеер", хотя и вполне девелопер в другое время. В одиночку такие тесты просто не сделаешь. Найденные баги при этом - это побочный продукт и чинятся только critical. Результат - это имеджи построенного трафика, как я уже тут писала. Типа не протестировал (with success) топологию - систему заказчик не принял - деньги не заплатил.Meadie писал(а):Интересно, а в "нормальных тимах" тестеры есть, и чем они занимается, если баги до них не доходят и все исполняемые модули идеально работают? Тестируют требования и пользовательскую документацию?Alusya писал(а): Да будет вам известно в некоторых нормальных тимах принята практика "юнит тестинг", когда баги просто не доходят до тест тима. Надеюсь эта практика - не исключение, иначе грустно...
Она сама слово Израиль произносила или вы упоминали Израиль в своем рассказе? Когда я на курсах по поиску работы училась, нам всячески рекомендовали напрямую другие страны из резюме на интервью не упоминать, если только о них впрямую не спрашивают. Т.е. вместо того, чтобы сказать - когда я работала в России, Израиле, Индии... применять обороты типа - на моей предыдущей работе, когда я работала в фирме ABC...bella писал(а): И вообще, у меня даже по телефону сложилось впечатление, что от слова "Israel" ее передергивало.
Это я вообще не поняла... В оисании обязанностей в этом конкретном проекте у вас в резюме было только описание тестерских обязанностей или и девелоперских тоже? Если только тестерских, то о девелоперских точно заикаться не стоило вообще.bella писал(а): И вообще, старалась меня на чистую воду вывести: написано тесты делала, а говоришь "девелопила".
Тут действительно некоторые менеджеры не понимают такого совмещения обязанностей. Особенно в больших компаниях с хорошо налаженным процессом QA. Значит надо играть по их правилам - если подаешься на тестерскую позицию, то и не надо им рассказывать о том, какой ты швец и жнец. И резюме подготовить соответственно. Исключение делать только для тех позиций, где от тестера требуются какие-то девелоперские навыки.bella писал(а): Т.е. попытка обьяснить, что эта конкретная строчка в резюме (из большого другого количества строк) относилась к израильской компании, где программистов всего-то было 15 штук и все делали все, была явно встречена как попытка запудрить мозги.
откуда вы это взяли? у вас же телефонное интервью былоbella писал(а):"Israel" сказала я. Это когда рассказывала, что приезжала в Канаду, а потом возвращалась обратно в Израиль на год закрыть дела.
Я думаю, если человека передергивает от слова "Israel", то не важно, сказала я его или нет, оно все равно написано во всех остальных местах работы, кроме последних двух лет.
Если пакистанская дама - будущая начальница, то в этом случае лучше было сразу просить прекратить интервью. Вежливо или не очень - отдельный вопрос. Если эта дама так себя ведет на интервью, то представьте себе, как она будет относиться к вам, если вам посчастливится попасть к ней под начало. Да и вообще, людей, которые откровенно неуважительно относятся к людям другой национальности или гражданства - нужно сразу ставить на место. Надеюсь, что это не единственное место в Большом Ванкувере, где есть интересная для вас работа.bella писал(а): по-поводу интервью - пакистанская дама-таки говорила с очень трудно понимаемым акцентом. Увы, пришлось переспрашивать, что ей явно не понравилось. А это начальница. И вообще, у меня даже по телефону сложилось впечатление, что от слова "Israel" ее передергивало. И вообще, старалась меня на чистую воду вывести: написано тесты делала, а говоришь "девелопила". ...
Так шта...
На мой взгляд, прекращать интервью - не очень хороший совет.Meadie писал(а): Если пакистанская дама - будущая начальница, то в этом случае лучше было сразу просить прекратить интервью. Вежливо или не очень - отдельный вопрос. Если эта дама так себя ведет на интервью, то представьте себе, как она будет относиться к вам, если вам посчастливится попасть к ней под начало. Да и вообще, людей, которые откровенно неуважительно относятся к людям другой национальности или гражданства - нужно сразу ставить на место.
Особенно в применении к конкретной ситуации, когда у Беллы не очень много канадского опыта, крутым спецом в QA она не является и на интервью себя не очень уверенно чувствует... На интервью опять же она попала через агента. Вряд ли ему бы понравилось, если его кандидат просто прекращает интервью.Я бы написала Software tester/developer и в резюме в описании этой работы четко бы разграничила девелоперские и тестерские обязанности. В легенде бы сказала, что сначала была девелопером, а потом начальство осознало, как плохо без организованного процесса QA, и я оказалась идеальным кандидатом на эту роль (объяснить почему). И дальше уже напирать на чисто тестерские обязанности.bella писал(а): Кстати, там где совмещение тестерских и девелопмент обязанностей, мне посоветовали писать S/W specialist. Рассказ, что в компании, где было 15 S/W people исключительно писал test plan & test cases, мне кажется будет выглядеть сильно неправдоподобно.
У вас довольно часто мелькает мысль - не понятно, почему меня позвали на интервью... Не надо все overanalyze. Вас позвали, потому что у вас есть опыт QA. Часто гораздо проще найти опытного QA и он научится предметной области на месте, чем искать узкого спеца с опытом именно в биллинге, банкинге и пр. И это уже ваша задача убедить интервьюеров, что вы сможете быстро освоиться.bella писал(а): И если мое резюме взяли рассматривать, то явно не из-за опыта в этой конкретной компании, а по каким-то другим соображениям, которые мне не удалось понять из интервью.
Ну а если взяли просто как статиста, чтобы обеспечить количество и симуляцию активити, то тут уже говори/не говори, все определено заранее.
Согласна. С той разницай, что я в Торонто, а не в Ванкувере.Maple писал(а): На мой взгляд, прекращать интервью - не очень хороший совет.
Да и рынок QA в Ванкувере существенно уже, чем в Москве.
Цель интервью - получение job offer-а. А уже потом можно выбирать - устраивает он тебя или нет.
Т.е. надо к месту употреблять КЛЮЧЕВЫЕ СЛОВА, которые от меня ожидаются. А вот тут-то я и не понимаю, какие слова? Из предметной области?Maple писал(а): У вас довольно часто мелькает мысль - не понятно, почему меня позвали на интервью... Не надо все overanalyze. Вас позвали, потому что у вас есть опыт QA. Часто гораздо проще найти опытного QA и он научится предметной области на месте, чем искать узкого спеца с опытом именно в биллинге, банкинге и пр. И это уже ваша задача убедить интервьюеров, что вы сможете быстро освоиться.
Говорить надо то, что они хотят услышать, а не то, что было на самом деле. В разумных пределах, конечно.