Если бы вы повнимательнее посмотреи на форум, то заметили бы, что есть отдельные ветки для инструментов автоматизации тестирования.
А у Вас даже в самом тексте ничеге не сказано об окружающей среде.
Представьте: Вы регистрируете ошибку о работе программы. Вопрос сюда имеет смысл писать примерно в таком же виде. Иначе это просто неуважение к остальным посетителям. "Попробуйте догадайтесь, о чем я думаю..."
MS VS 2005 и средства тестирования (Выбор инструментов)
2007-05-30 10:04 Darkus
В обсчим закачал я последнюю версию ТестКомплита и могу сказать, что ничего нового для себя не обнаружил. Да, для тестов ГУИ - он подходит. Можно встраивать его тесты в студию и даже программно через делегаты выполнять нужные тесты. А вот, чтобы сделать модульные тесты в полную силу используя C#... Я то думал, что они наконец-то написали оболочку свою над C#, а у них как всегда фантазии более, чем на C#Script не хватило, а он ещё от Java растёт... Эх, если бы это был полноценный C#, мы возможно бы подружились с ТС... Как использовать возможности С# 3.0? Просто получилась довинченная 4-я версия. К тому же, сразу подозрительно начался юзаться проц и кушаться память. Хотя я просто открыл Unit1.scs и ничего ещё не делал особенного. ... Может быть я просто не знаю всех возможностей 5-го ТС, подскажите плиз.
Подскажите литературу по автоматизации (Автоматизированное тестирование: Knowledge Base)
2007-05-30 10:14 Artem Rudenko
На данный момент я пользуюсь ТС 5.12(С#Script) для тестирования клиентского ПО написанного на .Net, но также хотелось бы иметь сведения по применению тех или иных подходов при использовании HP/Mercury и как вариант ёщё какого-нибудь тула. По существу, для чего мне нужны эти книги - чтобы основываясь на теоретических сведениях(некоторое количество подходов), выбрать свой подход к реализации автоматизированных тестов, определиться с достаточностью покрытия тестов, с качеством их покрытия, научится осуществять контроль качества непосредственно самих скриптов как таковых, изучить набор метрик используемых для автоматизации, проводить грамотною декомпозицию разрабатываемых функций, модулей, проектов для возможности их как можно более длительного применения, а также потенциально возможности последующего управления автоматизацией на уровне управленца. Вот, приблизительно для этого я и хочу найти книги,чтобы основываться не на том, что мне кажется правильно, а на том, что действительно правильно.
Немного общих фраз (пишу без воды, просто иначе будет совсем длинно): Качество продукта зависит от качества процесса. Процесс вещь вполне измеряемая и управляемая. Для каждого процесса существует набор метрик и формальных признаков, по которым можно судить что процесс выполняется. Процесс как некое подмножество практик и рекомендаций Методологии, является эффективным только в случае успешной адаптации и постоянного поддержания в актуальном состоянии для условий конкретного проекта. Условия не константны, соотв. и Процесс не есть нечто высеченное в камне.
Инженер по качеству - роль контроллирующая и обслуживающая Процесс. О том, что Процесс нуждается в обслуживании почему-то часто забывают, сводя роль QA к контролю, хотя даже прямой перевод роли Quality Assurance говорит о том, что роль включает активности по обеспечению и гарантии качества.
Активности Инженера по качеству включают работы направленные на выявление наиболее оптимального Процесса, работы по адаптации Процессных практик к реалиям Проекта, понимание какими инструментами можно измерять эффективность Процесса (набор метрик и мероприятий типа ревью, etc), контроль Метрик Процесса.
Переводя на человеческий язык: понять что для условий проекта будет лучше (частота релизов, наличие и детализация артефактов, основные правила коммуникаций и т.д.), определить каким образом можно применить практики существующих/признанных методологий или их частей (некоторые методологии говорят, что Процесс не работает, если внедрены не все Процессные практики, но по отдельности практикки и подходы вполне могут работать в рамках другого, кастомного процесса), внедрить использование подходов на проектном уровне, внедрить контроль использования подходов (что измеряем и как трактуем полученную информацию), проводить контроль (непосредственно измерять и проверять, ставить галочки и пр.), информировать участников Процесса об эффективности текущего Проецесса и планировать активности по улучшению текущего процесса (в планирование входит не только выставление более высоких показателей, но и список активностей по достижению этих показателей). Практические шаги тут могут быть самые разные, но в целом это переговоры и фиксация договорённостей по Процессу между руководством проекта, заказчиком и участниками проекта, а также активная помощь всем в понимании как надо работать проще и вместе с тем эффективнее.
Простые идеи, которые я хотел бы донести: Наличие артефактов является одним из, но не единственным и не обязательным признаком работающего Процесса. Гибкие методологии не фокусируются на артефактах, к примеру - однако я бы не стал говорить, что ХР или Scrum от этого хуже и перестают быть методологиями в принципе. Просто в том же Scrum как я его понимаю, роль инженера по качеству смещена в зону отвественности Scrum-мастера: коллеги работающие в Scrum меня поправят если я промахнулся.
Я в разное время для общего развития изучал документацию по СМК нескольких фирм, в которых работал (питаю слабость к таким документам). Сведения о качестве их (и многих подобных) продукции и услуг у меня тоже не из вторых рук. На основе этого опыта считаю, что в ИТ улучшением одних только процессов многого не добьёшься.
Наличие документов регламентирующих СМК и качество продуктов никак не связано. Как говорил Ломоносов "А я знаю 1000 богатых людей, но богаче от этого не стал".
Я тоже работал в компании где была и формально функционировала внутреняя процессная группа, даже постулировалось наличие и результаты аудитов - но за два года работы я не видел ни одного аудитора или процессника, который банально спросил бы меня "что у тебя болит". На вопрос к ПМ-у "А что будет когда придёт аудит?", он только улыбался (опытный дядька, с ПМ-ом нам тогда повезло) и отвечал что когда командование компании видит движение по счёту нашего аккаунта вопросы и претензи снимаются сами собой. Приходилось спасать утопающих руками самих утопающих - силами тех.лида (Слава - привет!) и ведущих разработчиков: ребята отлично понимали что все эти "бантики" не для меня и не для тех.лида, а для того чтобы мы все могли нормально работать. КОгда я выходил из проекта, туда начали искать выделенного человека на роль QA, интересно нашли или нет - я таких на рынке не встречал.
Поэтому вопрос к цитате: "у нас", это где имелось в виду? Это с понтами, что где-то у кого-то уже получилось, и теперь нас дураков надо научить, как правильно? :)
С вашей позицией вечно обиженного на меня "бюргера" я уже устал возиться (что в личной переписке, что в форуме) - понимайте слова как вам угодно, но не все в этом мире хотят вас уколоть или подначить :)
Вы достаточно странно асоциируете QMS ISO 9000 9001 с качеством и процессами - кто сказал что если не ISO то фигня? Любой процесс хороший если он работает. Что бы он работал нужны определённые активности - они не заканчиваются (впрочем и не начинаются) на словах "артефакт, документ, ISO". Если консультант, к примеру, оперирует только ими то он теоретик: им тоже найдётся применение, но не везде. У нас в последней проекте в течении 2 лет шла работа по построению наиболее удобного для нас и заказчика процесса - силами энтузиастов проектной команды. В итоге получилась солянка из RUP и гибких методологий. При этом могу сказать что никаких ISO рядом не было, но уверен что по многим аспектам эффективности пройесса мы могли бы дать фору и проекту по которому компания получала свой СММ3.
Обязанности: Функциональное тестирование ПО Разработка тест-кейсов и скриптов автоматизированного функционального тестирования (QTP)
Всё бы хорошо, только вакансия говорит что нужен тест-дизайнер, а внутри 3 вакансии: тест дизайн, тестировщик и автоматизатор. Так не бывает или всё в одном флаконе но частично.
Может быть я просто не знаю всех возможностей 5-го ТС, подскажите плиз
мне кажется, что вы не совсем понимаете назначение средств автоматизации тестирования, и дело тут вовсе не в ТестКомплите
Ни одно средство не затачивается под определенную платформу. В вашем случае под .NET.
Обычно средства автоматизации имеют свой язык, на котором и надо писать скрипты. В случае с ТестКомплитом таких языков 5 (ну, 2 из них - это фактически вариации JScript, но не в этом суть).
Вы пытаетесь найти в средстве автоматизации тестирования нечто специфичное для вас. К сожалению, вряд ли вы такое найдете. Разве что кто-то сделал это до вас с такой же целью.
QUOTE
Да, для тестов ГУИ - он подходит
Ну в этом-то и есть его основное назначение (как и других подобных продуктов).
А если серьезно, то уж очень общий вопрос. Начиная с терминологии. Что Вы подразумеваете под тестовым сценарием? И какой вариант из имеющихся UML-диаграмм вас интересует?
Потом можно детализировать: вопрос у Вас чисто теоретический или в применении к какому-то инструменту?
Ну и т.д. [right][snapback]42708[/snapback][/right]
Меня интересует реализованно это сейчас в каком-либо инструменте или нет? Тестовый сценарий - то, что сейчас мы пишем руками (скрипты).
MS VS 2005 и средства тестирования (Выбор инструментов)
2007-05-30 11:58 Artem Rudenko
Я конечно могу ошибаться, но то ,о чем говорил уважаемый даркус больше всего походит на Unit testing, а это уже немного другое нежели большинство тулов для автоматизации тестирования, преимущественно предназначеные для реализации регрессионного(или околорегрессионного зависит от реализации) тестирования.
MS VS 2005 и кастомизация workflow (Выбор инструментов)
2007-05-30 12:12 Esh
Подскажите, пожалуйста, есть ли в MS VS 2005 редактор форм с возможностью добавления /удаления полей для описания дефектов и возможность редактирования состояний и переходов? Поставила триальную версию, и у меня сложилось ощущение что этого сделать нельзя, это так?
мне кажется, что вы не совсем понимаете назначение средств автоматизации тестирования, и дело тут вовсе не в ТестКомплите
Хм... :) Конечно же не понимаю :) Для этого мы и общаемся здесь.
Посмотрите по ходу обсуждения на вопрос, тогда мы поймём друг друга.
QUOTE
3) Возможно мне вообще стоит забить на средства тестирования MS VS и спрыгнуть на что-то другое? (но при этом должна быть очень хорошая интеграция в саму VS + поддержка покрытия кода, как это сделано в VS, manual тесты, ну и другие вкусности в полном объеме).
И на ответ.
QUOTE
3) мы переползли на TestComplete - в связи с наличием интеграции - переползание произошло достаточно безболезнено. Берите демо версию - пробуйте. Поддержка Manual и Unit Test'ы имеется. Если нужен CodeCoverage - то дополнительно нужен будет AQtime (TC его использует для получения данных о Coverage).
Поэтому меня и заинтересовало, как я могу В ПОЛНОМ ОБЪЁМЕ отказаться от VS и перейти на TestComplete. Я серъёзно подумал, что в ТС сделали наконец-то поддержку C# и что я могу писать юнит тесты на нём также, как я делаю это в студии.
QUOTE
Обычно средства автоматизации имеют свой язык, на котором и надо писать скрипты.
Одно дело, когда усекают язык, как в случае с DelphiScript, а другое, когда говорят С#, подразумевая Java.
QUOTE
(ну, 2 из них - это фактически вариации JScript, но не в этом суть).
Как раз в этом и суть. Возможности C# очень большие и я хочу пользоваться ими, а не JScript.
Я конечно могу ошибаться, но то ,о чем говорил уважаемый даркус больше всего походит на Unit testing, а это уже немного другое нежели большинство тулов для автоматизации тестирования, преимущественно предназначеные для реализации регрессионного(или околорегрессионного зависит от реализации) тестирования.
Меня интересует на данный момент Unit тестирование. Кстати, а почему вы считаете, что юнит тесты не могут быть использованы(предназначены) для регрессионного тестирования? Просто в частности, мне было интересно, как именно в ТС сделана
Меня интересует реализованно это сейчас в каком-либо инструменте или нет? Тестовый сценарий - то, что сейчас мы пишем руками (скрипты). [right][snapback]42742[/snapback][/right]
А смысл?
Куда интереснее иметь UML модель тестируемого приложения и на основании ее генерить кейсы (последовательности кейсов) ...
Собственно, статья писалась для моих коллег, чтобы объяснить, как устроены наши тесты. [right][snapback]31834[/snapback][/right]
Привет!
За почти год что-нибудь поменялось в устройстве тестов? И есть что нового? Извени, но ты кажется единственный (на форуме) кто двигается в этом интереснейшем направлении ....
MS VS 2005 и средства тестирования (Выбор инструментов)
2007-05-30 12:49 Artem Rudenko
К сожалению, вы меня не так поняли. Я абсолютно не отрицал того, что юнит тесты могут быть использованы для регрессионного тестирования, я просто хотел немного разделить - большинство средств автоматизации(по крайней мере те, с которыми мне удалось пообщаться) не поддерживали Unit тестирование(либо поддерживали, но ограниченно, далеко не так, как можно было бы реализовать тоже самое из среды разработки непосредственно самого приложения, имея перед собой собственно не скомпилированную апликацию, а ёё "сырое" представление), и, как сказал Генадий, имеют свой язык с как правило си/VB/Delphi подобным синтаксисом и возможностями. Не использование в чистом виде того или иного конкретного языка программирования обусловлено, как мне кажется чисто экономическими соображениями разработчика тулов для автоматизации.
Меня интересует реализованно это сейчас в каком-либо инструменте или нет? Тестовый сценарий - то, что сейчас мы пишем руками (скрипты). [right][snapback]42742[/snapback][/right]
А смысл?
Куда интереснее иметь UML модель тестируемого приложения и на основании ее генерить кейсы (последовательности кейсов) ... [right][snapback]42747[/snapback][/right]
Ну или кейсов. Это так - идея для аспирантуры. Если сейчас это никак не реализованно, то можно защищать данную идею :)
Ну если другого способа нет, то http://blog.shumoos.com/archives/108 Не хотел я ее публиковать до рецензирования и корректуры. [right][snapback]42682[/snapback][/right]
Можно было мне на мыло кинуть. Читаю. Вы просите, насколько я понял рецензии. За скорую рецензию не ручаюсь, но долго тянуть, так же не буду. :-)
- смысл менять шило на мыло (ну или на +100 у.е к з/плате). - кто-то с опытом ищет позицию с повышением до сеньора QA или там нач. отдела или еще что-то аналогичное.[right][snapback]42719[/snapback][/right]
Да, я не проговорил это явно -- разумеется, с того момента, как человек встаёт во главе группы, его оклад растёт дальше -- начиная с 68-80 (зависит от его собственного и его подопечных уровня), и дальше в зависимости от величины фронта, который его группа закрывает.
QUOTE(ksm @ May 29 2007, 09:38 PM)
- ну а люди в регионах просто вычитают аренду квартиры в Москве (~700?) и грустнеют.[right][snapback]42719[/snapback][/right]
Единственное, что мы тут пока можем поделать -- оплатить приезд на собеседование, а если оно успешное -- помочь с переездом в Москву. Вести нагрузочное тестирование полностью из другого города в теории возможно, но к этому нужен сильный пробивной "человек-моторчик" (в Москве или в этом другом городе), который наладит такой процесс, и я почти уверен, что первые полгода-год этому "моторчику" нужно будет регулярно приезжать в Москву -- например, провести в Мск первые 3 месяца, после чего раз в 1-2 месяца приезжать на неделю для решения текущих вопросов.
Unix Tester (Работа/Москва)
2007-05-30 14:36 Анастасия
Компании Аурига (www.auriga.com) на постоянную работу требуется Инженер-тестировщик для работы в оффшорном проекте на западного заказчика на полный рабочий день. Мы предлагаем Вам отличный профессиональный коллектив, хорошую зарплату, возможности профессионального роста.
Обязанности: ∙ручное и автоматическое тестирование ПО ∙написание технической документации
Требования к кандидатам: Обязательно: ∙опыт работы, связанный с тестированием ПО обязателен (можно неофициальный) ∙опыт работы с Unix/Linux ∙хороший письменный англ. язык (intermediate и выше) Желательно: ∙знание C/C++/Java и/или других языков программирования – большой плюс ∙высшее образование со специализацией в ИТ Условия: Место работы – гор. Москва, метро Университет Зарплата по результатам собеседования + социальный пакет. Испытательный срок 2 месяца. Просьба присылать резюме по адресу anastasiya.lashkova@auriga.ru Subject: UT ICQ: 305597514
Я уже пыталась устроиться тестером, меня охотно берут. Помню вопрос будущего потенциального работодателя «сколько времени приходилось занимать монотонной работой ?» Это меня несколько напугало. Насколько я знаю, тестирование ПО может длиться около года. Под готовностью изменить себя Вы имеете ввиду способность заниматься монотонной работой? [right][snapback]42702[/snapback][/right]
Прислушайтесь к мнению настрадавшихся людей :-) Если у вас всего год работы, и при этом, очевидно, разочарование в выбранной сфере деятельности -- не надо бросаться в тестирование только от безысходности.
Существует много-много интересных профессий; работа же в тестировании порой ничуть не легче, чем в разработке, кроме того, с этой деятельностью связан особый характер. У профессионального разработчика, пожалуй, больше шансов уехать за границу (если уж это - цель жизни), а у тестировщика - устроиться здесь в оффшор.
Но к такому выбору нужно подходить очень осторожно, потому что "бегство" разработчика в тестирование - очень распространенная ошибка, и представляет собой весьма печальное зрелище.
Можно было мне на мыло кинуть. Читаю. Вы просите, насколько я понял рецензии. За скорую рецензию не ручаюсь, но долго тянуть, так же не буду. :-) [right][snapback]42753[/snapback][/right]
Адрес? Или аську. Или Скайп? Личные то сообщения отвалились.
Я думаю здесь все хуже. Наши статьи не чтобы находятся в конфронтации. Они говорят, что авторы друг друга не уважают. Это проблема. Может нужно переписать обе, может написать еще одну. Посмотреть надо.
1. Моя статья про людей, которые начинают идти или недавно идут по профессиональной лестнице. Ваша про менеджера. Наши статьи в принципе о людях разного уровня. Это даже из названия видно. 2. Полностью согласен с вашим видением менеджера. Руководитель всегда должен быть на шаг впереди, на голову выше и т.п. "Он предлагает другие виды деятельности до того момента, когда его сотрудника окончательно заест текучка. Он проводит тренинг до того, как станет очевидной потребность в обучении. Он выбивает хорошие рабочие места потому что так надо, а не потому что об этом просили." Бесспорно отличный менеджер.
Только я пытаюсь быть более реалистичнее. На мой взгляд у вас описание идеального коня в вакууме. Таких менеджеров, а скорее обстановок, в которых менеджер так сможет себя вести (люди хорошие есть и немало), крайне мало. А на просторах СНГ и вовсе редкие случаи. Чаще всего менеджер либо зажат сроками либо результатами, а иногда и то и другое. В таких ситуациях тоже надо уметь работать профессионально. Было бы неплохо в статье осветить эту сторону работы менеджера. На мой взгляд таких ситуаций гораздо больше чем описанных у вас. Тут, на мой взгляд, на первый план выходит умение менеджера увлечь людей и работать не обращая внимания на мелкие неурядицы. Они всегда сплошь и рядом, как бы вы не огораживались. Это часть нашей жизни.
Мои комменты: "отфутболил подчиненного" - указал на белые пятна в профессиональном развитии специалиста; указал на узкий кругозор специалиста; указал на отсутствие профессионального подхода у специалиста.
Можно еще пяток вариантов написать. Это зависит ровно от того, что вы поняли под предложением идти и разбираться дальше.
Далее описана одна из множества возможных ситуаций после диалога руководителя с подчиненным. Я вполне с ней согласен. И если человек воспримет это как указано у вас, то пусть идет - от этого все только выиграют, если так как пытаюсь объяснить и показать я, то большая вероятность того, что этот человек станет хорошим специалистом и в конечном итоге профессионалом своего дела.
В целом статья имеет право на жизнь, так как она отлично раскрывает еще одну сторону восприятия человеком указаний на недоработки.
Я думаю здесь все хуже. Наши статьи не чтобы находятся в конфронтации. Они говорят, что авторы друг друга не уважают. Это проблема. Может нужно переписать обе, может написать еще одну. Посмотреть надо. [right][snapback]42757[/snapback][/right]
Оба-на. Что бы мне вас не уважать, надо хотя бы, как-то общаться и знать вас не только по форуму. "Иначе зачем же?" (с) Не понял про не уважение. Тут по подробнее, пожалуйста.
На счет переписать статью, я в предыдущем комменте уже написал, что я думаю про вашу статью. Вполне имеет право на жизнь равно как и моя. Вы хотите вывести формулу профессионализма? За что боремся в данном случае?
Вам вся моя статья не понравилась или конкретный диалог?
MS VS 2005 и кастомизация workflow (Выбор инструментов)
2007-05-30 15:58 JimR
1. Надо понимать разницу между продуктом VS Team System (Вы кстати не уточнили какую версию из VS пробовали. Т.к. про Express или Pofessional в данном случае даже можно и не говорить) и TFS. Соответственно Вас должен интересовать в плане кастомизации Workflow именно TFS. 2. Надо понимать, что в изначальной версии какая-либо кастомизация предполагалась только на уровне ручного редактирования xml-файлов. Только после установки сервис-пака можно говорить о какой-то визуальной кастомизации. Более того, туда же желательно поставить powerr tools и ещё какую-то утилиту. Точнее не скажу, так как раскопками всего этого у нас занимался релиз-менеджер, а не я сам. Но на соответствующих форумах, да и в MS кажется тоже об этом достаточно много написано.
P.S. 2Case: не пора ли завести отдельную ветку для Visual Studio for Testers? Продукт появился, развивается, и вопросы по нему начинают активно появлятся...
возникла проблема с форматированием. В частности с простым переносом строк. Контрол,выводящий записанный текст в поле. по всей видимости, съедает все служебные символы внедренные в строку. То есть "\r\n" или просто "\n" не показываются, но и переноса строки не происходит. Как бороться?
Запуск скриптов из среды Delphy7 (Обеспечение качества ПО - QA)
2007-05-30 17:01 Виктория
Всем здравствуйте! Возникла следующая проблема: пишу скрипт в TestComplite5 на DelphtScript. Все работает нормально. Затем копирую этот скрипт в Delphy7, запускаю. Все работает кроме одного - текст, ввод которого эмулирую как ввод с клавиатуры, не вводится, поля на форме остаются пустыми. Подскажите пожалуйста, как это можно исправить. Буду очень признательна!
Запуск скриптов из среды Delphy7 (AutomatedQA - Functional Testing)
2007-05-30 17:01 Виктория
Всем здравствуйте! Возникла следующая проблема: пишу скрипт в TestComplite5 на DelphtScript. Все работает нормально. Затем копирую этот скрипт в Delphy7, запускаю. Все работает кроме одного - текст, ввод которого эмулирую как ввод с клавиатуры, не вводится, поля на форме остаются пустыми. Подскажите пожалуйста, как это можно исправить. Буду очень признательна!
Компания специализируется на внедрении ПО для крупных банков, страховых агентств и холдинговых структур, базирующихся в Москве. Плюсами компании являются профессиональный подход и современность.
Основные направления деятельности компании:
* консалтинговые услуги в сфере IT (разработка IT-стратегии, разработка бизнес – требований, * разработка технических требований к программному обеспечению, организация и проведение тендеров по выбору поставщиков программного обеспечения и IT-услуг), внедрение автоматизированных систем для управления взаимоотношениями с клиентами (CRM), * внедрение и сопровождение комплексных систем автоматизации банковской деятельности * разработку заказного программного обеспечения.
Месторасположение: м. Преображенская площадь / м. Электрозаводская (часть проектов осуществляется на территории заказчика, в большинстве случаев внутри Садового кольца)
Обязанности:
Разработка Java (J2EE) приложений, разработка интеграционных приложений.
Основные требования:
* общий опыт работы программистом не менее 1 года. * высшее образование(техническое будет плюсом) * опыт разработки J2EE-приложений, * знание и практическое применение EJB, JMS, WebServices, * опыт работы с СУБД (MS SQL Server, Oracle), * приветствуется опыт работы с WebSphere Application Server, WebSphere MQ и знание UML, BPEL. * технический английский.
Дополнительные требования: Личные качества: коммуникабельность, ответственность, умение и желание работать с людьми.
Условия:
* ЗП по результатам собеседования + бонусы по успешному завершению проектов. * График с 9:00 до 18:00. * Перспективы роста. * Социальный пакет: оплата больничных, отпуска, обучение, корп. мероприятия.
Успешного кандидата ждет интересная, динамичная, перспективная работа в дружном коллективе высококвалифицированных специалистов.
Если Вас заинтересовала вакансия, то пожалуйста присылайте свои резюме по ниже указанным реквизитам с пометкой «java_n1». Также можете обратиться к нам и узнать, что за компания открыла эту позицию и задать любые вопросы, не отправляя при этом своё резюме.
Ведущий производитель ПО в области автоматизации хостинга и технологий виртуализации серверов, приглашает на работу талантливых и опытных Web программистов.
Опыт работы/требуемые навыки:
* Умение производить оптимальную и эффективную верстку: DHTML, CSS. * Хорошее знание web-технологий: XML/XSLT, JavaScript, Ajax * Опыт работы с bugtracking и системами контроля версий * Технический английский
Желательно:
* XML-based protocols (Schema, SOAP, XSLT, XML RPC) * Would be a plus also knowledge of scripting languages (PHP, Perl), WMI, Internet and communication protocols, Web Services development.
* Возможен гибкий график работы * Высокая заработная плата (от $1200 до $2200+, в зависимости от квалификации) * Дружный молодой коллектив * Бесплатное питание в компании * 100% оформление по ТК * Медицинская cтраховка
Если Вас заинтересовала вакансия, то пожалуйста присылайте свои резюме по ниже указанным реквизитам с пометкой «xmlJSW». Также можете обратиться к нам и узнать, что за компания открыла эту позицию и задать любые вопросы, не отправляя при этом своё резюме.
Ведущий производитель ПО в области автоматизации хостинга и технологий виртуализации серверов, приглашает на работу талантливых и опытных технических писателей.
Опыт работы/требуемые навыки:
* Владение письменным английским языком на уровне near-native * Опыт работы техническим писателем не менее 1-го года * Интерес к глубокому освоению информационных технологий
Желательно:
* Опыт написания программ на любом современном языке программирования высокого уровня * Высшее техническое образование
Обязанности:
* Создание, перевод с русского и сопровождение существующей англоязычной документации инструментальной платформы для разработки ПО администрирования и автоматизации предоставления услуг хостинга
Условия работы:
* Возможен гибкий график работы * Высокая заработная плата (от $1000 до $2200+, в зависимости от квалификации) * Дружный молодой коллектив * Бесплатное питание в компании * 100% оформление по ТК РФ * Медицинская cтраховка
Если Вас заинтересовала вакансия, то пожалуйста присылайте свои резюме по ниже указанным реквизитам с пометкой «TechWriter». Также можете обратиться к нам и узнать, что за компания открыла эту позицию и задать любые вопросы, не отправляя при этом своё резюме.
Как по мне, вопросы супер идиотские и не раскрывают навыки специалиста. Зачем он вообще нужен?! [right][snapback]42767[/snapback][/right]
Честно говоря, первоначально создалось такое же впечатление, ёщё когда этот тест был бета. Но теперь, когда стал проходить, вопросы не показались такими уж и идиотскими(ну по крайней мере не все из них), а польза - для меня по крайней мере такая, что я перечитал заново некоторые теоретические сведения о том, чем и для чего я занимаюсь(таким образом сам тест дал толчок и направление для просмотра сведений), хотя многие и многие тесты конечно же не отличаются особым качеством, но для того на бенче и есть множество вопросов(повлеться запрос на фидбек по пройденному тесту) о качестве опросов и тд и тп - просто большая часть людей не туда пишет свои притензии, а вот так вот обсуждает их где угодно, но не там где того ожидают создатели брейнбенча. Да и насколько мне кажется проблема в пригодности/непригодности теста тоже относительна, так как большинство бенчевсих тестов ориентировано на то, что их проходить скажем так будут "американцы".
Хотелось бы узнать, есть ли тут пользователи SilkPerformer software. Продукт от компании Borland(Segue). Просто по SilkTest на форуме можно хорошо пообщаться, а вот по SilkPerformer-у что-то не нашла раздела. Проводил ли кто-то исследования по поводу его возможностей, может кто подскажет плюсы и минусы (кроме выской стоимости в качестве минуса :-)
Хотелось бы узнать, есть ли тут пользователи SilkPerformer software. Продукт от компании Borland(Segue). Просто по SilkTest на форуме можно хорошо пообщаться, а вот по SilkPerformer-у что-то не нашла раздела. Проводил ли кто-то исследования по поводу его возможностей, может кто подскажет плюсы и минусы (кроме выской стоимости в качестве минуса :-)
Спасибо.
SilkPerformer (Borland и Segue)
2007-05-30 19:42 Case
Я перенёс вашу тему в соотв. форум - думаю ответ на ваш вопрос это сам форум и есть :)
Стандарт - это инструмент организации производственного процесса и не более. Это не самоцель и не панацея от всех бед.
В описанном куске указывается, имхо , не проблема стандартизации а отсутствие какого-либо четкого понимания цели деятельности. В результате процветает миф что одно только наличие инструмента ( в данном случае стандартизации) может привести к успеху. При этом не определены условия успеха, цели деятельности, бизнес-модель деятельности. Обычно такая ситуация связана с низким уровнем бизнес-компетенции высшего менеджмента.
В противоположность написанному выше - возможно непонимание пишущими целей поставленных перед указанными в примере компаниями.
Подскажите как улучшить процесс взаимосвязи работы программистов и тестировщиков.
Суть проблемы такова: Во время моего тестирования программисты исправляют ошибки и дорабатывают некоторые компоненты, и сразу же подкладывают изминения в программу. Потом получаеться так, что мне необходимо все тестить заново, так как вылазят ошибки уже в протестированных компонентах. И это занимает колоссальное количество времени, так как программный продукт большой. [right][snapback]34285[/snapback][/right]
Это нормально. Только надо научиться планировать тестирование. Разделять верификацию, регрессионное тестирование, тестирование новой функциональности и т.д. [right][snapback]34290[/snapback][/right]
Это ненормально, т.к. программа одна разрабатывается и взаимодействие отделов для достижения результата должно присутствовать, иначе это басня Крылова будет. Да и существует множество программ по контролю версий, приложений для управления разработкой. К тому же множество бесплатных. Только чаще всего программистам просто не охота написать две строчки об изменениях в комментариях. Вот и приходится перерывать весь программный код и указывать, что данные изменения генерят новый баг :) На это прогеры реагируют в основном "дико". Другого слова не получилось найти:))) Поэтому до внедрения процесса разработки желательно прочитать пару глав по психологии взаимотношений на рабочем месте и дать почитать или провести двух часовой трениг с разработчиками :))) А вот как строить "дипломатию процесса" с прогерами, которые в своей служебной жизни не встречались с тестеровщиками?!... Это и для меня осталось загадкой на сегодня:) Но думаю тут решения возможны только через высшее руководство... после протоколирования затрат на исправления одних и тех же ошибок в течении недели, месяца. Больно, но проект нужно выпускать все таки. И тестировщик "подписывается" под очередной сборкой и релизом тоже. И в случае пропущенного бага является перед руководством не в лучшем свете. Спасибо за внимание:)
Действительно ли QA в смысле ISO 9000 широко применяется
Софистика в вопросе. QA <> ISO только и всего. [right][snapback]42738[/snapback][/right]
Ну не знаю уж, насколько это относится к современным версиям, но вот читаю в энциклопедии: стандарт ISO 9001:1987 назывался Model for quality assurance in design, development, production, installation, and servicing.
И снова о работе (Круглый стол о работе в тестировании ПО)
2007-05-30 23:13 Olen'ka
Добрый вечер, rlabs. Вы мне профессию предлагаете сменить или область деятельности ? Я тестирование для себя рассматриваю не от безысходности. Может быть – эта та область, в которой я смогу реализоваться. Год работы в программировании, к сожалению, не позволяет мне называть себя разработчиком. Так что ни о какой переквалификации («бегстве») речь не идет. Я только хочу понять, насколько интересна, перспективна область тестирования.
Действительно ли QA в смысле ISO 9000 широко применяется
Софистика в вопросе. QA <> ISO только и всего.
Ну не знаю уж, насколько это относится к современным версиям, но вот читаю в энциклопедии: стандарт ISO 9001:1987 назывался Model for quality assurance in design, development, production, installation, and servicing.
a66at, вы или специально флеймите или правда считаете что описание чего-бы то ни было равняется активностям по достижению целей зафиксированных в описании? Хотя после слов про СМК и качество продуктов в компании похоже что у вас как-то так и получается...
ISO - стандарт, суть - бумага в которой написано как можно достичь чего-то, именно модель, которая говорит как можно делать определённые работы. Распечатайте её и положите на полку - в компании станет больше порядка? QA это активность, а не стандарт, которому можно соотвествовать или нет. Набор действий, а не предписаний - я уже просто не знаю как ещё сказать.
Если оторваться от слов про QA и переформулировать ваш вопрос насколько широко применяются Стандарты для достижения Качества продуктов - вопрос становиться совершенно другим и тут мой ответ как у большинства в топике: "зависит от...".
Кажется название даже после изменения не совсем соответствует последним веяниям темы, ибо предлагается встреча вживую, а в теме топика "Идея организовать встречу онлайн" :)
Это для тех кто живёт в онлайне :)
Спасибо - исправил заголовок!
Недостатки TestComplete (AutomatedQA - Functional Testing)
2007-05-31 00:33 serpent
Выскажусь и я. Применяю TC в автоматизации тестирования вот уже почти два года, начиная еще с 3й версии (сейчас пользуем последнюю - 5.12). Все это время продукт находится в стабильно глючном состоянии, причем с увеличением масштабов системы тестирования (количество машин, объем скриптов, время их выполнения, объем задействованной функциональности ТС) это начинает становиться проблемой - все больше времени уходит на поиск методов обхода багов, на которые натыкаемся. Поэтому хочется увеличения качества самого продукта. На мой взгляд, от средства автоматизации, в первую очередь, нужен хороший специализированный язык програмирования, работающий быстро и безглючно. Все мулечки типа namemapping (его аналогов), поддержки нестандартных контролов и т.п. достаточно легко программируются в самой среде TC. Сейчас же ситуация такова, что акцент в продукте делается на развитие богатства возможностей (красиво выглядит в пресс-релизах), которые к сожалению из-за нестабильной базы оказываются малополезными с практической точки зрения.
SilkPerformer (Borland и Segue)
2007-05-31 00:56 Dmitry_NJ
Слава, если решено было разделить продукты по функциональному и нагрузочному тестированию на разные подфорумы, то тогда стоит сделать это и для Borland. Иначе каша получается - по одним вендорам разделение есть, а по другим все в одной куче.
Я только хочу понять, насколько интересна, перспективна область тестирования.
С точки зрения уехать работать на хорошие деньги в хорошую страну область тестирования ни чем не лучше того, чем вы занимаетесь сейчас. Если именно это ваш основной движущий мотив, то не советую менять шило на мыло. Год опыта еще слишком мало, чтобы вы представляли реальный интерес для зарубежного работодателя. Наберитесь терпения, всему свое время.
Если же хочется попробовать заняться чем-то другим потому, что не нравится то, чем вы заниметесь сейчас, то это совсем другое дело.
Программы автоматического тестирования для WEB (Выбор инструментов)
2007-05-31 03:07 Estrella
Всем доброго времени суток. Прошу помочь советом. Сейчас тестирую web-приложение с огромным количеством функционала. Для автоматизированного тестирования использовала Watir, но на мой взгляд он мне особо не помог. Нужно сидеть и прописывать каждое действие, мне быстрее сделать это руками. Но так как функционала очень много все проверить я не успеваю, посоветуйте какое средство для автоматизации мне можно использовать.
Переводя на человеческий язык: понять что для условий проекта будет лучше (частота релизов, наличие и детализация артефактов, основные правила коммуникаций и т.д.), определить каким образом можно применить практики существующих/признанных методологий или их частей (некоторые методологии говорят, что Процесс не работает, если внедрены не все Процессные практики, но по отдельности практикки и подходы вполне могут работать в рамках другого, кастомного процесса), внедрить использование подходов на проектном уровне, внедрить контроль использования подходов (что измеряем и как трактуем полученную информацию), проводить контроль (непосредственно измерять и проверять, ставить галочки и пр.), информировать участников Процесса об эффективности текущего Проецесса и планировать активности по улучшению текущего процесса (в планирование входит не только выставление более высоких показателей, но и список активностей по достижению этих показателей).
Я извиняюсь, но чем-же занимается руководство этого проекта, если практически всё за него делает "Инженер по качеству"?
