Это первый эксперимент с задачками -- просьба не слишком критиковать ;-) [right][snapback]42348[/snapback][/right]
Кажется у Джоэла или Силивана в одной из глав посвещенных набору персонала, было про задание вопросов требующих размышления от кандидатов. Причем главное не результат, а желание и умение размышлять.
после прочтения этого Body of knowledge у моего отдела началась депрессия на тему: сколько же нам еще учить нужно J
QA Engineer (Работа для IT специалистов)
2007-05-21 10:50 Kristina
Международная компания Paragon Software Group/System Utilities открывает вакансию QA Engineer. Требования: Высшее или неоконченное высшее образование. Владение английским языком на уровне чтения документации. Знание принципов работы ОС Windows 9x/2000/XP/2003.Аккуратность, исполнительность, пунктуальность Желательно (рассматривается как большой плюс): Знание методологии и опыт тестирования ПО. Знание Linux на уровне пользователя. Обязанности: Проведение работ по тестированию продуктов, написание сопроводительной документации. Локализация и анализ найденных проблем. Рассматриваем резюме студентов старших курсов (начиная с 4-го). Для студентов возможен гибкий график работы, позволяющий совмещать работу и учебу. Условия: Заработная плата от 800$ - 1200$ и выше по результатам собеседования, в дальнейшем возможен рост. Оформление в соответствии с ТК РФ. Возможность повышения своего профессионального уровня. Курсы совершенствования англ. языка в рамках компании. Гибкий график работы. Присылайте резюме на hr@paragon-software.com с пометкой QA Engineer в теме письма.
Дело в том, что самое важное, чтобы самое важное оставалось важным. Суть не в приобретении знаний, а в том, чтобы по делу и вовремя применять их. Уверен, что большинство наших отечественных QA специалистов обладают вполне достаточным уровнем знаний, чтобы принести пользу и развитие компании на данном этапе.
Я не против образования. Напротив, считаю что это ключ. Просто пусть все будет в нужном порядке, и учитывая местный контекст. Сначала делаем дело, не забываем учебу также.
Я не вижу вообще никакого смысла в вопросе "почему тестером"? Особенно у человека с опытом аналогичной работы. Тех, кто так упорно выше на этот момент указывал, попрошу перечислить, какие, на ваш взгляд,здесь могут быть ответы и что вам это даст? А вот выяснить, понимает ли человек, куда идет - более чем логично, но это нужно сделать по-другому.
Для вас может смысла и нет, а для работодателя есть. Как минимум этот вопрос помогает выяснить ваши амбиции.
QUOTE(toftinoporo @ May 18 2007, 03:55 PM)
Вопрос про управленческие способности и просьба привести пример меня поставили в тупик. Я молча сижу и думаю: что я здесь могу сказать? Примеры по выполнению заданий в группе в университете? Глупо. Что я играю в муз. группе и являюсь там организатором? - полный оффтоп, да и какое имеет значение? На предыдущих работах мне подобных организационных вопросов решать не приходилось, в итоге из этого вопроса они ничего не вынесли для себя, а я, в свою очередь, ответила что-то невнятное и обобщенное.
Так не бывает, чтобы работодатель ничего не вынес для себя из вашего ответа. Отрицательный результат - тоже результат. По поводу невнятного и обобщенного.... лучше не уходить от ответа, отвечать надо правдиво и внятно.
Какую литературу почитать для ознакомления с QA? (Обеспечение качества ПО - QA)
2007-05-21 13:15 no1
Я когда начинал - мне посоветовали почитать Канера. Вот я нарыл и почитал - написано довольно просто и понятно. Мне понравилось. Еще можно поискать видеолекции, кстати, тоже по Канеру. Он там хорошо объясняет. Вобщем - этот автор пишет хорошо, по крайней мере мне понятно и просто читать.
Если интересно - напиши мне на мыло ( yad_cliff@mail.ru ). У меня дома книжечка валяется - скину. Она совсем не большая - но вроде интересная и полезная :)
Столкнулся с подобной проблемой. Мне надо в ListView надо посмотреть - установлена ли галочка слева от item.
Может кто-нибудь подсказать, как это делается?
QA Engineer (Работа/Москва)
2007-05-21 13:40 Kristina
Международная компания Paragon Software Group/System Utilities открывает вакансию QA Engineer. Требования: Высшее или неоконченное высшее образование. Владение английским языком на уровне чтения документации. Знание принципов работы ОС Windows 9x/2000/XP/2003.Аккуратность, исполнительность, пунктуальность Желательно (рассматривается как большой плюс): Знание методологии и опыт тестирования ПО. Знание Linux на уровне пользователя. Обязанности: Проведение работ по тестированию продуктов, написание сопроводительной документации. Локализация и анализ найденных проблем. Рассматриваем резюме студентов старших курсов (начиная с 4-го). Для студентов возможен гибкий график работы, позволяющий совмещать работу и учебу. Условия: Заработная плата от 800$ - 1200$ и выше по результатам собеседования, в дальнейшем возможен рост. Оформление в соответствии с ТК РФ. Возможность повышения своего профессионального уровня. Курсы совершенствования англ. языка в рамках компании. Гибкий график работы. Присылайте резюме на hr@paragon-software.com с пометкой QA Engineer в теме письма.
У Вас десятки-сотни гигов именно под Interbase??? Причём у каждого из Ваших клиентов? Да как же вы их бекапите и вообще обслуживаете? Или всё-таки какой-то клон, например, FB?
не у всех, но есть несколько "больших" клиентов и у них именно такие размеры. Работа с ними почти индивидуальна. Моя задача минимизировать проблемы, но, к сожалению, не убрать их полностью... сервер никто так и не хочет закупать:( выбрала также несколько (пока хватает 6) "боевых" баз разных размеров и ставлю все обновления на них - картинка в целом получается приближенная к реальной, по крайней мере можно увидеть когда стоит бить тревогу... если проблема в скрипте, то, конечно, ее можно заметить на мелкой базе. Но если скрипт верный, но не оптимизированный (н-р, последовательный перебор строк одной из таблиц), тогда на больших базах могут возникнуть сложности - перебрать 10 строк или, допустим, 1 000 000 займет разное время. Другое дело окажется ли среди моих тестовых баз база именно с этой большой таблицей... По крайней мере стралась выбирать среднестатистические базы.
...а убитые базы клиентов - это уже проблема сопроводагеров, в моем случае:)
IEEE 1012a-1998 IEEE Standard for Software Verification and Validation - Сontent Map to IEEE 12207.1
В общем, всё из ISO/IEC 12207 - если не жалко :)
У меня есть:
610-90 IEEE Standard Glossary of Software Engineering Terminology 730-98 IEEE Standard for Software Quality Assurance Plans 828-98 IEEE Standard for Software Configuration Management Plans 829-98 IEEE Standard for Software Test Documentation 830-98 IEEE Recommended Practice for Software Requirements Specifications 1058-98 IEEE Standard for Software Project Management Plans
Crystal Report Developer11 (рус) (IBM Rational - Functional Testing)
2007-05-21 14:38 nbv1
Подскажите пожалуйста. Использую Crystal Report Developer11 руссифицированную версию. Создаю отчет с использованием параметров. При запуске отчета открывается окно "Задание значений" (параметра), с предложением ввести значение на русском языке. Если сохранить отчет на сервере. Потом доступиться к отчету через web-браузер (Explorer) и запустить отчет, то окно "Задание значений" и сам текст с предложением ввести значение будут уже на английском языке ("Crystal Parameter Fields"). А надо чтобы был на русском. Почему так получается, как это можно исправить?
К задаче можно подходить двояко: - снизу; - сверху.
Сверху. Решающую роль играет опыт предыдущих аналогичных проектов. В прошлый раз примерно такую же задачу мы тестировали 5 часов, выполнили 50 тестов, протестировали на 65% от общего списка требований.
Снизу. На проекте имеем 100 требований. Каждое требование тестируется одиним тестом. Количество прогонов теста - от 4 раз (минимум) до 8 раз (максимум) - зависит от количество наборов тестовых данных. В среднем тест занимает от 2 до 5 минут. Каждый третий тест падает (по предыдущему опыту), значит плюс 5 минут на занесение проблемы в базу дефектов. Все суммируем по минимуму - получаем самый оптимальный вариан. Затем суммируем время наихудшего варианта. Берем среднее. [right][snapback]15095[/snapback][/right]
Интересные оценки. Тесты автоматические? Дефекты у вас автоматически регистрируются? Что-то не верю я в такие оценки... [right][snapback]42365[/snapback][/right]
Так что позвольте мне оставить цель неизменной, а вот задачу на начальный этап работ сформулировать следующим образом: создание формального описания 60% процессов связанных с разработкой ПО в компании.
Я бы написал, не 60%, а всех ключевых процессов разработки ПО. Их не так уж и много. К примеру в RUP выделено 6 ключевых и 3 вспомогательных.
Можно привязаться к RUP и взять их 6 ключевых. Описать алгоритм их применения в компании. Затем проанализировать (кажды этап каждого процесса) на вклад в обеспечения качества. Востараться выработать метрику, что бы отслеживать текущее состояние, контролировать и управлять процессом. Затем попробовать моделировать улечшения и отслеживать результат (через метрики).
Недавно пришлось немного поработать с Багзиллой. После мантиса очень неудобно. Сильно раздражал стандартный интерфейс. IMHO стандартной багзиллой пользоваться нельзя, надо самим дотачивать внешний вид.
В отдел тестирования приходят в основном два потока задач: 1) тестирование новых разроботок, которые должны пройти весь путь еще до появления их в продуктах 2) тесты продуктов, функционал которых уже проверен. Тут тестируется в основном компонентность продукта, локализация и прочее, что делает набор бинарников похожим на продукт для пользователя. Есть вопрос, а будет ли иметь смысл поделить отдел тестирования на две части и одна будет тестировать глубоко функционал и все новое, а часть будет проверять именно продукт перед его выходом. Вопрос сейчас именно в глобальном смысле, темы вроде "постоянно тестировать одну локализацию скучно" пока что в стороне.
Вопрос сейчас именно в глобальном смысле, темы вроде "постоянно тестировать одну локализацию скучно" пока что в стороне.
Вы сами ответили на свой вопрос. Через очень непродолжительное время у вас разбегуться все, кто делает "черную" работу - тестирует изменения.
Это и есть глобальный подход.
Работать нужно в рамках одного отдела. Если Вы считаете, что задачи по доработке продукта не требуют глубоких знаний и навыков, используйте для этого начинающих тестировщиков. Постройте на этих задачах "школу по подготовке к настоящей работе" ( ).
ВАКАНСИЯ: Эксперт по тестированию / QC Leading Eng (Работа/Москва)
2007-05-21 16:57 astraelena
Требования: Знание жизненного цикла разработки ПО. Опыт разработки ПО или тестирования (включая нагрузочное) - не менее2-х лет. Знание ОС Unix; Windows-server на уровне администратора - приветствуется. Знание БД Oracle, MS SQL, умение оптимизировать настройки серверов БД и приложений для цели увеличения производительности системы - значительный плюс. Знание аппаратных серверных средств приветствуется. Обязанности: Участие в проектах нагрузочного и функционального тестирования аппаратно-программных комплексов. з/п до 2000 у.е.(по итогам собеседования ) +соц. пакет + обучение и сертификация(за счет компании) М. Войковская т. 981-61-82 Елена eshevchenko@bellintegrator.ru (в теме письма указывать название вакансии)
Срочно! Вакансия: ТЕСТИРОВЩИК (Работа/Москва)
2007-05-21 17:00 astraelena
В компанию по производству программного обеспечения требуется тестировщик Требования: муж/жен, 20-45лет, Опыт автоматизированного тестирования от 1 года, опыт в нагрузочном тестировании приветствуется. Знание С++ приветствуется. з/п 1200-1800 у.е.(по итогам собеседования ) +соц. пакет + обучение и сертификация(за счет компании) М. Войковская т. 981-61-82 Елена eshevchenko@bellintegrator.ru (в теме письма указывать название вакансии)
QA о двух головах (Управление тестированием ПО: тест менеджмент)
2007-05-21 17:26 ichthys
Идея Vasiliy вполне здравая. Отдел наверно громко сказано, я бы выделил группу, которая отвечает за итоговую проверку релиза: комплектность поставки, наличие локализации, наличие библиотек под конкретную платформу и т.п. Обеспечил бы ротацию между теми, кто занимается функциональным тестированием, и теми, кто выполняет итоговую проверку продукта. Выделение этой новой группы, выделение руководителя группы, поднимет важность этого направления тестирования.
А на счет "черной" работы... не преподносите работу как "черную", и она такой не будет.
Тестировщик ПО - LG Electronics Inc. (Работа/Санкт-Петербург)
2007-05-21 17:28 Oxana_M Инженер по тестированию ПО в филиал корпорации LG Electronics Inc. (Санкт-Петербург), направление Mobile Solutions, Quality Engineering Group. Проекты: Разработка ПО для разработки, отладки и тестирования мобильных телефонов (Windows приложения), разработка Graphics Engine и игр.
Обязанности: - Тестирование программного обеспечения; - Составление методик и планов тестирования; - Анализ процесса и результатов тестирования.
Требования: - Знание теории тестирования ПО и понимание процесса разработки ПО; - Знание основ программирования; - Знание английского языка на уровне чтения и письма; - Опыт работы в области тестирования ПО от 1 года; - Опыт работы с системами поддержки тестирования (bug tracking, test-documentation management, requirements management); - Методичность, аккуратность; - Опыт работы в команде.
Приветствуется: - Опыт применения автоматизированного тестирования; - Опыт системного администрирования.
Зарплата - по результатам собеседования. Резюме присылайте на mikheeva@lge.com Контактное лицо - Михеева Оксана, QE Group Leader
матёрый специалист в нагрузочном тестировании web-приложений
Мне кажется, что справедливо было бы исключить одно из трёх выделенных италиком слов. :) "Чистые" массовые вёб-приложения с html-ным передом, с не особо транзакционным задом - это не та задача, на которой можно заматереть в нагрузочном тестировании, ИМХО. Просто хотя бы из-за достаточно популяризованного протокола и понятности предметной области.[right][snapback]42004[/snapback][/right]
А на счет "черной" работы... не преподносите работу как "черную", и она такой не будет.
Работа будет такой, какой она есть. Как бы вы ее не называли.
Если вы делите работу для продвинутых и не продвинутых (тем более разделяете сотрудников по отделам), то все будут хотеть быть продвинутыми и никто не захочет быть задвинутым. В итоге, работа в первом отделе будет престижна, а во втором - расцениваться как ссылка.
Мой вам совет. Не разделяйте людей (только если их количество не превышает критический уровень). Если людей уже много и один человек не может справиться с вопросами управления. Тогда стоит ввести разделение по проектному принципу. Есть проект - есть команда.
Кажется у Джоэла или Силивана в одной из глав посвещенных набору персонала, было про задание вопросов требующих размышления от кандидатов. Причем главное не результат, а желание и умение размышлять.[right][snapback]42366[/snapback][/right]
Такие задачки мы давно практикуем, особенно на разработческих вакансиях, где рынок позволяет довольно хорошо поднимать планку и по problem-solving-вообще в том числе.
Работа в Quest (Работа/Москва)
2007-05-21 18:39 Quest Moscow
Вопросы по интересующим Вас вакансиям задавайте на mskjob@quest.com
у нас в компании рассматривается вопрос о приглашении эксперта в области тестирования с мировым уровнем для проведения семинара или тренинга. Возможно вы знаете, недавно у нас в компании выступили Филип Кратчен (участвовал в разработке RUP, сейчас работает над OpenUP) и Дан Роусторн (эксперт по методологии Agile разработке).
Пока единственным условием является известность эксперта в России и странах СНГ, что бы его выступление могло собрать приличное количество заинтересованных лиц (думаю, что нужно человек 40 - 50).
Приглашаю высказывать свои пожелания. Но, пожалуйста, указывайте, почему тот или иной эксперт будет интересен широкой аудитории.
Если вы делите работу для продвинутых и не продвинутых (тем более разделяете сотрудников по отделам), то все будут хотеть быть продвинутыми и никто не захочет быть задвинутым. В итоге, работа в первом отделе будет престижна, а во втором - расцениваться как ссылка.
Создавать отдел для задвинутых (не продвинутых) никто не предлагал.
Вопрос сейчас именно в глобальном смысле, темы вроде "постоянно тестировать одну локализацию скучно" пока что в стороне.
Вы сами ответили на свой вопрос. Через очень непродолжительное время у вас разбегуться все, кто делает "черную" работу - тестирует изменения.
На самом деле я спрашивал о самой возможности. Понятное дело, что нужно обеспечивать ротацию людей и нельзя постоянно "крутить одну гайку".
QUOTE(Green @ May 21 2007, 02:43 PM)
Работать нужно в рамках одного отдела. Если Вы считаете, что задачи по доработке продукта не требуют глубоких знаний и навыков, используйте для этого начинающих тестировщиков. Постройте на этих задачах "школу по подготовке к настоящей работе" ( ).
Так из нее же потом уйдут из этой школы. А продукты все равно надо будет тестировать :) Новые люди появляются не так часто.
Мой вам совет. Не разделяйте людей (только если их количество не превышает критический уровень). Если людей уже много и один человек не может справиться с вопросами управления. Тогда стоит ввести разделение по проектному принципу. Есть проект - есть команда.
Спасибо за совет, Сергей. Проектые команды хороши на длительное время. При проверке комплектации обычно идет потокое производство.
возьмите ту же Goranka Bjedov [right][snapback]42389[/snapback][/right]
Я смотрел это выступление на видео раньше, и, насколько я помню, там упоминался предыдущий опыт в телекоме. Кроме того, мне показалось, я привёл агрументы в поддержку своего мнения о не особой перспективности специализации в нагрузочном тестировании решений базирующихся на LAMP, если смотреть с точки зрения профессионального роста. У меня есть и ещё, если хотите, я свои конкурентные преимущества буду отстаивать до конца. :)
Это первый эксперимент с задачками -- просьба не слишком критиковать ;-) [right][snapback]42348[/snapback][/right]
А со ссылками какой эксперимент? :)
Чисто для поинтересоваться, открываю ссылку в новом окне (я их все в новых окнах открываю) - нет тестового задания. Оказалось надо просто кликать.
И кстати, тоже предлагаю задачку: А и Б сидели на трубе (канале, информационном), А упало Б пропало, что осталось на трубе? (шуточные задачки тоже должны быть, потому как здоровое чувство юмора в требованиях)
возьмите ту же Goranka Bjedov [right][snapback]42389[/snapback][/right]
Я смотрел это выступление на видео раньше, и, насколько я помню, там упоминался предыдущий опыт в телекоме.[right][snapback]42398[/snapback][/right]
Горанка работала раньше в AT&T, но вся презентация про опыт Google'а. На AT&T ссылаются разве что короткие устные ремарки в одном месте, не более того. Все проблемы, о которых она рассказывает, есть и в Google, и в Яндексе -- тут телеком совсем ни при чём.
QUOTE(a66at @ May 21 2007, 09:19 PM)
Кроме того, мне показалось, я привёл агрументы в поддержку своего мнения о не особой перспективности специализации в нагрузочном тестировании решений базирующихся на LAMP[right][snapback]42398[/snapback][/right]
Ну какой, скажите на милость, LAMP в Веб-Почте Яндекса., где даже Oracle дохнет под нагрузкой даже на метаданных о письмах, не то что на хранении самих писем? Или на Маркете.. Или Карты . с их временем отрисовки и Маркет с глубокой переработкой данных. Упомянул бы ещё Фотки, но у тех пока аудитория далека от проектных цифр. Про кастомную морду, которая отрисовывается, если не ошибаюсь, вообще без хождений в базу, я не говорю.
QUOTE(a66at @ May 21 2007, 09:19 PM)
...если смотреть с точки зрения профессионального роста. У меня есть и ещё, если хотите, я свои конкурентные преимущества буду отстаивать до конца. :)[right][snapback]42398[/snapback][/right]
То есть строить тестовый стенд для кластера из сотен машин, где только разных типов машин (ролей) больше полудюжины -- для вас пройденный этап? И смасштабировать цифры по нагрузке от такого стенда до боевого кластера -- плёвое дело? И подготовить user-generated content боевых объёмов задолго до запуска социального сервиса не составляет никакого труда? Снимаю шляпу.
Да, если вы ещё с нами -- посмотрите вводный рассказ об XScript'е, он изрядно проясняет, в какой архитектуре мы живём на большинстве сервисов: http://www.rit2007.ru/images/1.5.obolenskiy.avi
Demonstrates a solid understanding of core concepts within this topic. Appears capable of working on most projects in this area with moderate assistance. May require some initial assistance with advanced concepts, however.
Strong Areas Testing Managing SQA Projects Processes Verification and Validation
Weak Areas Philosophy Behind SQA Standards and Metrics
вообще на брейн бенче в первый раз Некоторые вопросы показались достаточно муторными, ожидал более других :)
Еще улыбнуло "Scored higher than 74% of all previous test takers. "
Кстати а в чем прикол выбора в начале - None ,... Expert ну и как в конче это отражается на баллах? Т.е. можно пройти None (самый новичек) и поулчить там 100 % супер-пупер гуру чтоли?
