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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

+1 за Баха

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

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

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

Надя

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

скажем, если человек знает, чем отличается left join от right join. можно спросить, что происходит, когда в коде он встречает left outer join или что происходит, когда в коде он видет просто join.

если соискатель знает разницу и понимает, что в каких ситуациях применять, то он ответит очень уверенно.

хорошего дня!

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

даже в Лондоне, куда стекается огромный поток людей и, в частности, ИТ специалистов, хорошего тестера найти трудно.

"Хороший", "Инициативный" - вещи весьма субъективные. Да, есть риск выбрать не того или не выбрать того, кто нужен. Но опять же, выбирают те, кто имеет представление о том, каким должен быть кандидат на ту или иную должность.

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

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

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

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

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

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

http://www.citforum....th_per_project/
http://www.software-...really-need.htm
http://www.software-...lin/gone-if.htm

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

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

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

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

все высказанное является моей точкой зрения.

И вообще тут не подняли тему о том, что CMMI "чтит" процессы, и не "думает" о людях. Никто не сказал о том, что такие компании как Borland по рейтингу CMMI имеют 1 уровень и по всем "классификациям" СММI, уже должна была давно кануть в Лету.

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

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

СMMI ведет вас к чему-то. он дает вам надежду - из непонятно чего сделать что-то. но что?? что-то предсказуемое и управляемое. но не факт, что это будет успех. CMMI придуман для руководителей, которые, глядя на все, что творится в разработке, хотят как-то с этим справится.. Иллюзия контроля, как сказал Бах в одной из своих статей.

с уважением,
Надя

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

Зарплаты небольшие, хотя странно, ведь начали понимать, как тестирование важно. спрос растет. предложений мало. следовательно, зарплаты тестеров должны расти. а они по-прежнему что-то вроде 1/2 или 1/3 зарплаты программиста.

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

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

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

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

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

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

простите, но было и отчаянье и слезы и непонимание, как же так к людям можно относиться. но если биться, то можно что-то поменять.

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

Эх, не по теме.. но душа утром проснулась и улыбнулась. Дожди в Лондоне закончились. на целую неделю обещают солнце. И долгожданный отпуск... ура! Лечу в Беларусь, потом Питер и в Прагу. не спустить бы сейчас все деньги на распродажах :) я не заядлый шопер, но ведь первый день отпуска! вот вернусь и с новыми силами перебираюсь в Сити, а сейчас просто лето...

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

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

модераторы, если сочтете это сообщение флудом - удаляйте :) я не обижусь

всем солнца, света и хорошего дня!

Начнем с того, что понятие Smoke testing ближе к технике, чем к понятию фаз тестирования. Smoke testing подразумевает особые приемы тестирования - у кого это это открыть приложение и закрыть его. Если не задымилось - все в порядке. (откуда собственно и пошло название. правда не из тестирования рограммного обеспчения, а аппаратного). но очень смешно тут его перевели "дымовые тесты" :)

Фазы тестирования представлены следующим набором:
1. модульное тестирование (тестирование модулей, функций и пр.)
2. тестирование интергрированных модулей
все не перечисляю и так все знают..

5. Фаза приема- примемочное тестирование.
вот список существующих видов приемочного тестирования
а) user acceptance testing - т.е. либо наемные люди на стороне заказчика выполняют тесты, которые им вздумаются, либо сам заказчик.
b) contract acceptance testing - вы, как исполнитель демоснстрируете, что все условия контркта выполнены. этот вид тестирования может быть отдан кому угодно, даже в третьи руки.
c) alpha testing & beta testingю... не стану расписывать, думаю, и так знаете.

ну вот и смотрите.. user acceptance testing and contract acceptance testing в качестве одной из техник тестирования могут исользовать smoke testing.. но это вовсе не обязательно..

надеюсь, наглядно объяснила :)
удачи!

Коллеги, простите :)
А реально этот сертификат работодатели в глаза видели?

Работодатели видели. Российские коллеги трогали и тихо завидовали :)

Всем удачи на экзамене!!!!!!!

Сообщите потом результаты. Мы за вас порадуемся.

Лично сдавала 110 фунто вроде бы. Что примерно 190 долларов. Кто сказал что 650 долларов стоит экзамен? Это с билетом Москва-Лондон и обратно??