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

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

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

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

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

было очень забавно уже после этого на него смотреть.

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

наглая ли я? нет, я очень friendly. но уверенность во мне есть. а желание "расшатать" цепь рассуждений соискателя приводит чаще к негативному отношению с его стороны к потенциальному работодателю. и кто при этом больше теряет?? :)

Нет black box testing не бесполезным занятие, а наоборот необходимое ...а не благодарное дело это потому как нечего показать кроме как результата (нормально работающего продукта), а главное что меня беспокоит что все-таки чтоб команда ..как бы правильнее высказаться .. прогрессировала хотелось бы внедрить хотя бы "чуточку" автоматизации..не не во вред срокам, дополнительным деньгам, и ресурсам...
Спасибо.

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

прогрессировать нужно с умом. делайте "умные тесты". устройте ревью. c ними прогрессирует команда целиком и каждый человек в отдельности. попробуйте, и вы увидите, как много всего еще надо сделать, прежде чем браться за автоматизацию :) часто люди думают, что ручное тестирование - это совсем неинтересно и стремятся найти fun в автоматизации, не подходя к этому серьезно. не повторяйте их ошибок.

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

будет интересно и полезно очень. и зачастую бесплатно. но это и есть частичная автоматизация. мы именно с этого и начинали (купили WAPT c начали анализировать данные, которые стали получать).

про black box testing это совсем было не к вам :) no personal offence.
сам факт, что вы думаете о развитии тестеров - уже большое дело. удачи вам!

не благодарное ето дело manual testing

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

Ваша фраза напомнила фразу о том, что многие считают black box testing бесполезным занятием. Глупость. и только.

Все выше сказанное - моя точка зрения.

У нас сейчас тоже можно пройти сертификацию.
Сдавать на английском конечно, тоже немецкая компания проводит сертификацию и книжка есть.

Нам вообще компания будет оплачивать сам сертификат, но скажите мне плиз, сколько он стоит и как обстоят дальше, не Foundation Level.

На чем построена сертификация - это вопрос ответ?
Что конкретно нужно.

Я тестер уже 4 года и материалов куча перелопатила в теории и практике, что нового дает этот сертификат Foundation?
И что интересного Надежда Вы нашли для себя при подготовки следующего?

Ой, если вы уже 4 года в тестировании, то зачем вам Foundation? Идите на Practitioner. Вот это будет вам реальный challenge. Там придется не знания по теории показывать, а практические навыки и опыт свой демонстрировать. Foundation хорош для тех кто от 1 года в тестировании. Для Practitioner надо как минимум 2. и то, если честно, не все тестеры за два года доходят до понятия рисков и оценки затрат.

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

У меня есть друг. он из всех книжек по тестированию понял одно, как правильно нанимать тестеров. И что вы думаете? он талантливый ресурс менеджер в отделе тестирования. и компания очень счастлива с ним. да, после позиции сениор тестре он не стал тест менеджером. он стал отличным ресурс менеджером. польза для компании?? очевидная..

читайте и применяйте. даже если только одну фразу

Автоматизация тестирования - это прежде всего поиск выгоды (т.е. экономии затрат).

Прежде чем убеждать клиентов, подумайте и убедите себя. сейчас вам надо 200 рублей на ручной тест низкой сложности, автоматизировать его вам будет стоить 2000 рублей. плюс на переделку и отдалку понадобится еще 2000 рублей, так как первые тесты никогда не бывают удачными.
итого, 4000 рублей на автоматизацию одного простого теста. т.е. 20 тестов ручных за это время можно было бы прогнать. автоматизация одного теста стоит пропущенных 19 тестов и багов вместе с ними?

посчитайте свои потери, перед тем как начнете все автоматизировать.

автоматизировать надо так, чтобы тесты находили баги. на дизайн такого теста и его автоматизацию требуется больше ресурсов, чем 1:10.
действительно ли это выгодно вам и вашим клиентам?

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

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

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

удачи вам в любом случае!

Я сама из Беларуси, но сейчас представляю Великобританию.

Беларусь сейчас ищет ИТ ресурсы по университетам и по колледжамию. ИТ компании готовы брать сейчас для "воспитания" тех, кого в 2001 бы не взяли. Рынок был очень неустойчив, кадров надо было не так много, да и брали в основном опытных. После .com краха (который отразился на ЕРАМ в том числе) в 2003 Белорусский оффшорный рынок начал оживать. Посмотрите, сколько компаний появилось новых начиная с 2003 года!

Сейчас берут 4 курсников на обучение и дальнейшую работу. Объявляют ярмарки вакансий, HR-менеджеры ходят по университетам. Сейчас ИТ-студентом быть в Беларуси очень хорошо и легче, чем в 2001. Практически не надо беспокоиться о работе.

И все равно не хватает ИТ-инженеров в Беларуси. К сожалению, количество так и не решило проблему качества.

Более того, 4 курсник поработав на большую оффшорную компанию, вложвшую деньги в его развитие, уходит из нее, как только получил возможность получить на 200 долларов больше. Странно, но откуда молодые специалисти думают, что если им через 2 года не предложили менеджерскую позицию, то надо уходить. И уходят.

Беларусь -кузница ИТ кадров. насление университетского образования, опыта в оффшорной разработке и "русского" мышления позволяет претендовать на работу зарубежом. Поэтому из Беларуси многие ИТ-специалисты уезжают.

Вот такая ситуация

За последнее время всю литературу мне пришлось читать на английском, если не считать художественной, так что вопрос о невозможности чтения на англиском не стоит. Просто на русском все же я читаю и вникаю в суть вопроса быстрее, а так как время в наш век на вес золота, вот и поинтересовался, в друг есть.... ? А нет так нет)

не в обиду перводчикам будет сказано, очень часто смысл теряется при переводе материалов. читайте в оригинале и вникайте.
а так вообще вы-молодец, если в последнее время читаете на английском.
книжки по ИТ теметике надо читать в оригинале.
к тому же, что сложного вы нашли в ISEB Syllabus? Я не согласна с мнение одного из форумчан, что там очень плохой английский язык. возможно, изложение не идеальное, особенно если учесть, что это начальный уровень подготовки тестеров. но с языком там все в порядке.

Хотя у меня с английским вполне нормально, но существует ли русская версия силабуса, что-то мне подсказывает, что нет? Может кто сталкивался...На счет самого экзамена, как я понял, то его сдают на локальном языке, те на русском сдать можно.  Поправьте меня, если я не прав.

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

В любом случае- удачи!

Смотря , что включаете в "прогон одного цикла тестирования программного продукта". Планирование? Разработку тестов? Развертываение и поддержку тест окружения (простите, не знаю какой термин употребляется environment)? стресс тестинг включаете? объем тестинг включаете?

Эстимация -один из самых сложных аспектов тест-менеджемента и тестирования вообще. Главная проблема - надо знать, что вы будете тестировать, чтобы сказать с высокой точностью, сколько всего вам понадобиться (людей, человеко-часов :) , денег и пр.). Узнать это очень сложно, пока вы не знаете качество продукта, документации, которые идут на тестирование (динамическое и статическое). И более того, не узнаете в большинстве случаев, пока не начнете тестировать.

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

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

если юз-кейсов нет, используем разбивку функциональности на тест-объекты. уровень глубины определяем сами. мы не пользуемся Functional Point Analysis о котором писал Green как мне кажется.

Ошибаемся ли мы? да, но стараемся.

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

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

литература любая хороша, надо все через себя пропустить. я училась на статьях, в основном. и вы попробуйте. берите силабус - его бесплатно можно скачать здесь ISEB FOUNDATION Syllabus и строго следуйте ему. что не понятно - ищите в интернете или тут, будем помогать, чем сможем ;)

Надя

+1 за Баха

Раз уж начали читать Канера "Тестирование программного обеспечения", то оторвитесь и прочтите их "Уроки вынесенные из опыта". в оригинале "Lessons Learned". на мой взгляд - это лучшая книга для начала. написана очень просто, понятно и вовлекает в тестирование.

кстати, читайте Баха - удивительно пишет про exploratory testing. Читайте Петтихорда, когда дойдете до автоматизации. Не читайте ВеенДала пока не наберетесь опыта (пусть меня простит этот умнейший человек, но его книжка по Practitioner из разряда непонятно написанных о таком интересном, как тестирование)

Пишите сами. самый лучший способ понять - писать самой. даже если это будет выглядеть так: "Наконецто поняла как правильно считать branch coverage и stetement coverage. Делается это так..... " напишите самой себе рассказ о том, как правильно что-то тестировать. очень помогает.
Удачи

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

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

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

В плохой практике план написали раз и забыли. в хорошей практике - получили информацию-пересмотрели планы, пересмотрели эстимацию.

тест кейсы расписываются в тест планах низкого уровня.

и еще: не держите планы и тест кейсы в секрете! люди должны их видеть обсуждать и использовать.

скажу вам как человек, имеющий такой сертификат.
сама постановка цели для человека в виде "Хочу сдать на ISEB Foundation" подразумевает работу. Да, Foundation - очень легкий экзамен, но он заставляет вас думать и работать. читать много книг и слушать умных людей.

экзамен можно легко сдать, но понимание основ тестирования (ISEB Foundation- самый базовый сертификат в тестировании) не приходит порой с сертификатом. это важно понимать.

по своему опыту знаю, что понимание материала по Foundation пришло только при подготовке к Practitioner.

лично мне очень помогло наличие ISEB Foundation. но я работаю на западную компанию, куда одним из первых требований было не наличие диплома, а именно профессиональной сертификации. трудно сказать, что происходит в России.

Если хотите знать, надо ли сдавать? надо. и в первую очередь, для себя.
все материалы очень легко купить на ebay. они стоят копейки. подготовиться очень просто. сдать - мне обошлось в 100 фунтов. наверное, в Москве чуть дешевле. моя дневная зарплата сейчас превышает затраты на материалы по ISEB, поэтому выгода затрат- очевидна.
но это все из личного опыта. не берусь судить тех, кто считает, что это пустая трата времени и денег.

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

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

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

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

за комментарий- спасибо :)

Мне нравится спрашивать, есть ли разница между тест-архитектором и тестером, тест- аналитиком и специалистом по тест-автоматизации.

Как ни странно, но есть соискатели, которые не видят разницы в этих направлениях деятельности тестера.

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