Тогда мы говорим о разных документах, только и всего. В тест плане тестов нет.
В тестплане вполне может быть перечисление тестов или их групп. Я об этом
QUOTE(Case @ May 17 2007, 12:41 AM)
А дальше пошёл скорее ряд предположений, чем алгоритм генерации тест плана, в часности стратегии тестирования.
Такие вещи обычно генерируются по составляющим, а не всем скопом. Соответственно, алгоритм представляет собой набор решений частных подзадач.
QUOTE(Case @ May 17 2007, 12:41 AM)
И что это даёт? Как по описанию приложения обычными словами автоматически понять какому типу принадлежит приложение? Средства EntityExtraction в целом кое-как справляются с базовыми задачами распознавания Person, Location и ещё некоторых более продвинутых вещей типа Fact - но не более. Вы говорите об автоматическом чтении документа решением генерации тест плана. Я повторюсь, хочу сказать что автоматически генерировать его нереально, ибо нет решений понимающих текст.
Зато есть решения, которые позволяют выделять подстроки А это задача на порядки проще "компилятора английского языка".
QUOTE(Case @ May 17 2007, 12:41 AM)
QUOTE(KaNoN @ May 15 2007, 08:20 AM)
Тот же перечень тестируемых и нетестируемых модулей (Test Coverage/Scope) можно получить по следующему принципу. В тесткейсах где-то в заголовке завести (если не было) поле вроде Component, которое описывает ту часть приложения, которая затрагивается данным тесткейсом. На генератор ставится фильтр по компонентам. Соответственно, компоненты, которые по фильтру проходят в план, ставятся в перечень тестируемых компонентов, остальные - в перечень нетестируемых.
Всё бы хорошо, но вы предлагаете по имеющимся тестам генери ровать статистику и просто показать что не покрыто тестами. То есть после того как тесты были написаны. А к пониманию тестируемых и нетестируемых требований это отношения не имеет, потом что выделить нетестируемые требования надо до того как мы начали писать тесты.
Ну не совсем это статистика. Это перечень компонентов, которые будут тестироваться и которые нет. То же самое и для требований. А насчет очередности выделения требований и написания тестов см. ниже.
QUOTE(Case @ May 17 2007, 12:41 AM)
QUOTE(KaNoN @ May 15 2007, 08:20 AM)
Далее, если брать приведенную вами ссылку на эссе Алексея Баранцева (а я иду сейчас по данной работе), то там следует пункт "Подход к тестированию". Тип тестирования можно либо зафиксировать, либо отразить определенной структурой каталогов (например, в отдельной папке хранить системные тесты, отдельно юнит, интеграционные и т.д.). Задав фильтр, мы можем определить, какие тесткейсы попали в тестплан. На основании этих данных можно все тесткейсы сгруппировать по типу тестирования.
Погодите, коллега. :)
Вы приводите техническое описание системы контроля процесса тестирования и описываете тест план просто как один из отчётов, который по тому что есть в системе просто покажет что есть и чего нет. Папки надо создать, чтобы их создать надо понять какие типы тестов будут - это и есть та часть работы которая в данный момент неавтоматизируема - то есть никто кроме человека её не сделает.
Загвоздка только в том, что тест план пишется до того как созданы тесты, как созданы папки отвечающие типам тестом - пишется ровно для того, чтобы всё это и понять и зафиксировать.
Дальше вы приводите техническое описание системы управления процессом тестирования, которая позволяет создавая элемекнты системы (по сути и планируя тестирования) получить потом документ, который можно назвать тест планом. Подход скажу честно интересный - для меня наверное, даже неочевидный и заставляющий подумать-покопаться, но вопрос лежит уровнем выше.
Есть разные подходы к созданию тестплана. В частности можно все приложение (его функциональность) представить в виде таблицы, в которой указываются все (или основные) компоненты тестируемой системы, а также трассировка по тесткейсам и требованиям. То есть тестплана как такового еще нет, но есть документ, описывающий весь предполагаемый объем работ. Эта схема применялась для автоматизиции тестирования одного приложения, соответственно, на той стадии, когда такая таблица разрабатывалась, тестплан не играл ключевой роли, так как начальная стадия автоматизации - это разработка. То есть по этой схему вначале разрабатывались тесты, потом определялось, что из этого всего можно автоматизировать, а что только вручную. Также снимались дополнительные данные. На основании всего этого составлялся тестплан. Я вполне могу согласиться с тем, что тестплан составляется изначально, но в описываемом мною случае проект поставлялся удаленному заказчику и ему главное было, чтобы вся необходимая документация имела место. То есть он уже получал полностью готовый пакет для тестирования своего приложения. А нам для автоматизации тестов тестплан особо не был нужен, так как заказчиком уже было определено покрытие, которое надо обеспечить, типы тестов и прочее.
QUOTE(Case @ May 17 2007, 12:41 AM)
Мой поинт прост:
QUOTE
Планирование тестирования как активность по выявлению подходов к тестированию на основе понимания и анализа существующих проектных артефактов - суть задача выполняемая только человеком, всё остальное вторично и может быть автоматизировано. Решение принимается человеком, фиксируется инструментом - тут и спорить нечего.
[right][snapback]42260[/snapback][/right]
Естественно, что решение принимают люди. Когда решения начнут принимать машины, то мы получим Терминатора или Матрицу.
QTP9:Доступ к JavaScript переменным (Hewlett-Packard (Mercury) - Quality Center)
2007-05-18 10:53 Luceus
К дополнению 2 пункта от Mike. Я написал удобную функцию, что бы по сто раз не объявлять описание тех или иных объектов. При необходимости, она вызывается следующим образом: .ChildObjects (xc_description_get ("micclass: WebList, name: List1"))
CODE
Function xc_description_get (ByVal object_description) Set el_description = Description.Create()
А нельзя ли как-то это совместить -- в начале вставить просто набор ссылок, как было раньше, а потом тот же набор, но в развернутом виде, с текстом. [right][snapback]42321[/snapback][/right]
Поддерживаю. Набор ссылок должен быть уникальным, т.е. не должно повторяться если несколько постов из одной темы.
Есть еще идея - сделать двух-уровневое дерево, на первом уровне - тема, на втором - лист топиков. И чтобы было как в Outlooke - жмешь на +, раскрывается сгруппированная тема.
Но честно говоря, я подобного не видел в рассылках. Скорее всего нереализуемо..
Если идею генератора предложить человеку, который обычно это все руками делает, то он только будет рад. [right][snapback]42195[/snapback][/right]
Я делаю. Мне этот инструмент даже не бесполезен, а вреден.
Возможно это даже вопрос религии. Хотя проблемы могут быть и в генераторе. Зачастую плохой генератор еще хуже, чем никакого. Но ведь можно сделать и хороший генератор.
QUOTE(SALar @ May 17 2007, 03:46 PM)
QUOTE(KaNoN @ May 15 2007, 06:34 PM)
Плюс ко всему, наличие различных генераторов будь то кода или документации вообще является оптимизацией процессов, эффект которой заметен при многократном повторении. [right][snapback]42195[/snapback][/right]
Не будет заметен.
Смотря как применять. У меня уже есть достаточно успешный опыт применения генераторов кода, а также генераторов различной сопроводительной документации. Какой от этого был эффект:
1) Програмный код имел очень строгий формат, который позволял достаточно хорошо читать этот самый код и понимать, что на какой стадии происходит
2) Некоторые рутинные радачи делались считанные секунды вместо 1-2 часов, что опять же позволяло поддерживать приемлемое качество кода при минимальных временных затратах.
3) Шаблонность структур, наличие жестких стандартов оформления кода позволило выработать алгоритм считывания атрибутов того или иного компонента. Это в свою очередь позволило генерировать справочную информацию по разработанному фреймворку за считанные секунды. Причем, для того, чтобы обновить справку исходя из новых изменений во фреймворке достаточно было перезапустить генератор
4) Наличие строгих спецификаций форматов файлов позволило создать генераторы, собирающие различные данные и группирующие в нужные структуры. Это позволило значительную часть документов создавать автоматически.
Автоматизиция подобных процессов позволит не концентрировать свое внимание на каких-то однотипных вещах, а заниматься наиболее наукоемкими задачами не отвлекаясь по сторонам. Так я могу заниматься непосредственно кодированием скриптов, зная, что нужный формат уже сгенерирован до меня. Мне не нужно тратить длительное время на набивку документов (особенно отчетного характера), когда я могу нажать на кнопку и он у меня уже есть. И времени тратится на порядки меньше и эффект ощущается при многократном использовании генератора
вот если бы не было слов "vX.Y она же vKKKK RL" то было бы все нормально
Этому ходу было вполне здоровое объяснение. Segue была поглощена компанией Borland, соответственно версии продуктов Segue уже стали формироваться по стандартам Borland. Вот и вся фишка.
QUOTE(vass @ May 17 2007, 10:21 AM)
PS: у меня 7.5 . Пока что его более чем хватает [right][snapback]42275[/snapback][/right]
Эх, тестировать бы стандартные ГУИ-приложения без всяких наворотов. Там и старых версий с головой хватает. Так нет же, находятся какие-то гады, которые пишут на .NET с использованием библиотек сторонних производителей, тут еще смеют заикаться про тестирование веб-приложений под FireFox или IE 7, хотя всем известно, что единственный правильный браузер, который когда-либо создавало человечество - это Internet Explorer 6.0
Какую среднесуточную нагрузку выдержит новый интернет-сервис Яндекса?
К каким всплескам посещаемости он должен быть готов, чтобы пользователь ничего не заметил?
Через сколько месяцев (или кварталов) нужно менять архитектуру сервиса при текущем росте посещаемости?
Если сервис выдерживает нагрузку N на одном лабораторном сервере, сколько он выдержит на боевом кластере, где <крутится> ещё десятком других сервисов?
На такие вопросы мы в группе нагрузочного тестирования Яндекса отвечаем каждый день - но, как всегда, задач сильно больше, чем людей.
Даже если вы никогда не занимались ничем подобным, но хорошо себе представляете, как внутри устроены web-приложения, и уверенно работаете в unix-консоли - присылайте резюме.
Перспектива тоже есть: с самого начала нужна большая инициатива и самодвижимость; через 1-1.5 года вполне реально возглавить собственную группу.
Начальная зарплата: 50 тыс. руб для начинающего/стажёра; 58 тыс. для хорошего специалиста; 68 тыс. руб для действительно сильного кандидата (суммы до вычета налогов). Зарплата может пересматриваться хоть каждый квартал. Квартальная премия платится по результатам работы (в случае запусков проектов может достигать до 1 месячного оклада в квартал).
Прочие блага: оплата технической литературы; рабочее место -- десктоп с двумя 19" TFT-мониторами, либо ноутбук + 19" монитор.
Корпоративная жилищная программа; медстраховка; бесплатные обеды; корп. условия в фитнесс-центре рядом с офисом.
Работа в московском офисе (м. Курская, http://company.yandex.ru/inside/contacts.xml) на полный день, график работы в разумных пределах свободный. Удаленная работа невозможна. Испытательный срок 3 месяца, оклад тот же. Иногородним кандидатам оплатим приезд на собеседование и можем помочь с переездом. Оформление иностранцев в принципе возможно; детали нужно обсуждать индивидуально.
Учимся работать в условиях кадрового голода (Новости IT-отрасли)
2007-05-18 11:54 SALar
Я просто плакал. Надо же, топ менеджмент, вдруг, совершенно случайно, осознал, что работать некому. Да не может быть! Проблема наступающего кадрового голода в IT была очевидна еще в 2001-2003 году любому мало мальски грамотному аналитику. И решать ее надо было тогда. А сейчас паравоз тю-тю. Прыгая в лодку давно отошедшую от берега, нужно понимать, что так и утонуть недолго. Начиная с 2003 года я предлагал решать кадровые вопросы многим фирмам. Я разговаривал с менеджерами, кадровиками, владельцами компаний. В сухом остатке усредненый разговор выглядел так: - За четыре месяца могу сделать до +Х сотрудников вот таким то образом. вот план, вот ключевые сотрудники, вот программа адаптации. - Неинтересно. (Думая просебя: "Ты же на этом заработаешь"). - Хорошо, тогда можно пойти таким путем: "...". - Не надо. - Еще можно сделать так: "...". - Не. Мы крупная солидная фирма. Мы не будем прогибаться под сотрудников. Позовем - прибегут.
Не прибежали. А, скорее, убежали.
Из моих ста-а-арых знакомых, начинавших как разработчики и хотевшими стать разработчиками, процентов 80 слиняло в другие области. Не были востребованы. Пример недавнего времени. Девушка, работавшая в ... (крупной, солидной, известной фирме), ушла оттуда со словами "не хочу быть программистом". Да, она больше не работает в IT. Не хочет.
"На рынке мало специалистов и они низкого качества". Правильно. А вы чего хотели? Посмотрите на свою кадровую политику. Неужели непонятно, что она хромает на обе ноги?
Вопрос таков: есть ли общепринятые критерии на производительность с точки зрения юзера, скажем, на время реакции от щелчка на объект до момента появления контекстного меню. Или от момента нажатия ссылки на сайте до открытия соответствующей вкладки. Интересует как для сайтов, так и для win32 приложений. [right][snapback]42228[/snapback][/right]
QUOTE(Green @ May 17 2007, 09:43 AM)
Отклик системы менее 1 сек пользователь воспринимает как интерактивное общение. До 8-10 с (по разным источникам) - пользователь замечает задержку, но не успевает переключить внимание на что-нибудь другое. Более 10 с - пользователь считает, что может успеть сделать еще что-то в то время, как система "думает".
[right][snapback]42272[/snapback][/right]
Не помню где, встречал Такие цифры: * до 0,1 сек - комфортная работа * 0,1 - 1 сек - работать можно * 1 - 10 сек - работать тяжело * 10 фокус внимания теряется безвозвратно. Работать практически невозможно В остальнов согласен с Сергеем.
Исходя из этих цифр в чтастности можно сделсть следующие выводы: * win приложение почти всегда лучше веб, т.к. последнее попадает в третью категорию * Работать под dos на 486 (P-I) в чем-то комфортнее, чем под XP на P-III. Программы стартовали чуть быстрее.
Зачем нужен тест-план? (Управление тестированием ПО: тест менеджмент)
2007-05-18 12:28 vass
мнэээ.. в качестве IMHO: такие генераторы больше используются для анализа "что мы сейчас сделали/несделали" (т.е. хелп разработчика, отчеты менеджера и т.д.), и конечно возможно их использовать для создания части тестплана "снизу вверх". Это в принципе неплохо для случаев малых/неформальных проектов, когда тестсет(ы) уже есть, а тут понадобился формальный тестплан - ну и чтобы меньше было рутины, кое-что автоматически сделать. Но в сложных/формальных случаях - просто неоткуда будет брать тесткейсы ДО того, как будет написан тестплан.
ГЛЮК SilkTest'a (Borland и Segue)
2007-05-18 12:33 vass
1) Ну блин .. когда все жостко зашито в какой-нить agent.dll, конечно придется каждый раз ждать новой версии :( 2) про браузеры -- лучче промочать, во избежание мегафлейма 3) по теме : ну надеюсь они в дальнейшем будут придерживаться одной системе версий и перестанут вносить баги в уже работающие места (да, я мечтатель! )
- Цель * Изменить систему QA таким образом, чтобы она стала отражать новый формат взаимодействия Г и М: заказчик - поставщик решений (Vendor). [right][snapback]42132[/snapback][/right]
Это не цель. Называйте как хотите: "мысли вслух", "неспешные размышления", "благие пожелания",- но это не цель.
Определение. Цель есть нормированное представление о достижимом результате.
Ключевое слово здесь "нормированное". Т.е. заданы критерии по которым можно однозначно определить достигнута цель или не достигнута.
"За три месяца снизить среднее время решения проблем заказчика в два раза." - Вот это более похоже на цель. Правда нужно еще проверить на достижимость...
QA-engineer (Работа для IT специалистов)
2007-05-18 12:50 Lentochka
В крупную международную компанию, требуется инженер по тестированию. Высшее образование, опыт автоматизированного тестирования. Навыки конфигурирования параметров работы видеокарт (установка и понимание настроек контрольной панели драйвера). Базовые знания 3d. Представление о процессе тестирования производительности приложений. Желательно начальный уровень Perl или C++, системы автоматизации тестирования. Разговорный английский язык. Обязанности: Тестирование приложений и видеокарт, автоматизация тестирования. Условия: з/п по договоренности с кандидатом (белая), соц. пакет. Уважаемые соискатели в случае вашей заинтересованности в нашем предложении просьба высылать резюме на e-mail с указанием Ваших зарплатных ожиданий и мы свяжемся с вами! Вопросы по вакансии можно задать по ICQ 478206688 Елена
QA-engineer (Работа/Москва)
2007-05-18 13:05 Lentochka
В крупную международную компанию, требуется инженер по тестированию. Высшее образование, опыт автоматизированного тестирования. Навыки конфигурирования параметров работы видеокарт (установка и понимание настроек контрольной панели драйвера). Базовые знания 3d. Представление о процессе тестирования производительности приложений. Желательно начальный уровень Perl или C++, системы автоматизации тестирования. Разговорный английский язык. Обязанности: Тестирование приложений и видеокарт, автоматизация тестирования. Условия: з/п по договоренности с кандидатом (белая), соц. пакет. Уважаемые соискатели в случае вашей заинтересованности в нашем предложении просьба высылать резюме на e-mail с указанием Ваших зарплатных ожиданий и мы свяжемся с вами! Вопросы по вакансии можно задать по ICQ 478206688 Елена
Представительство международной фармацевтической компании приглашает на работу системного администратора.
Требования к кандидату:
- Опыт работы системным администратором от 1 года - Опыт администрирования локальных сетей (от 30 машин); - Опыт администрирования почтовых серверов - Отличное знание офисного и ПК оборудования; - Хорошее знание английского языка (устный и письменный)
Основные обязанности: - Обслуживание серверов и рабочих станций компании локальных и удаленных - Поддержка телекоммуникаций (Интернет, почта, телефонная связь) - Обеспечение сетевой безопасности - Закупка нового оборудования и ПО - Проверка и визирование договоров, а также других документов - Координирования действия поставщиков и обслуживающих фирм;
Компания предлагает:
- ЗП $600-$800 - Официальное трудоустройство - Оплачиваемые обеды - Социальное страхование (медицинское и страхование жизни) - Оплачиваемый мобильный телефон
Если вы заинтересованы в данной вакансии просьба направлять свое резюме на E-mail: igor@venbesthire.com.ua дополнительная информация по телефону: 503-66-13/14 (Игорь)
Представительство международной клинико-исследовательской компании, приглашает на работу ИТ Менеджера.
Требования к кандидату: - От 2-х лет опыта работы на должности «Сетевой администратор»; - Хорошее знание английского языка (устный и письменный, опыт общения с носителями языка); - Опыт администрирования локальных сетей (от 30 машин, Terminal Server); - Опыт администрирования почтовых серверов (MS Exchange Server); - Отличное знание офисного и ПК оборудования; - Отличные знания пакета MS Office, продуктов Acrobat; - Желателен опыт работы с Oracle и SQL БД
Основные обязанности: - Разработка решений, консультирование и менеджмент; - Обучения персонала работе с пакетом MS Office, и другим программным обеспечением; - Поддержка web сайта компании (внесение поправок, защита, не графический дизайн); - Обслуживание серверов и рабочих станций компании локальных и удаленных; - Поддержка телекоммуникаций (Интернет, почта, телефонная связь); - Обеспечение сетевой безопасности; - Закупка нового оборудования и ПО
Компания предлагает: - ЗП $1000, официальное трудоустройство - Оплачиваемые отпуск, больничные - Оплачиваемый мобильный телефон
Если вы заинтересованы в данной вакансии просьба направлять свое резюме на E-mail: igor@venbesthire.com.ua дополнительная информация по телефону: 503-66-13/14 (Игорь)
Проблемы с записью скрипта (Hewlett-Packard (Mercury) - Performance Center)
2007-05-18 13:47 AlexLek
Была подобная история, с определённого момента скрипт не записывался и появлялось подобное сообщение ("...(Service=) NOT PROXIED!"...) всё оказалось из-за того, внутри домена машины перенаправлялись на другой внутренний прокси - поговорил с админами, и всё стало отлично
программист 1С (Работа для IT специалистов)
2007-05-18 14:09 frolkovataxcom
Обязанности: - Поддержка существующей конфигурации, разработка новых отчетов и процедур, поддержка пользователей Требования: - Знание основ бухгалтерского и управленческого учета, документооборота на предприятии. -Хорошее знание платформы 1С Предприятие 7.7, опыт программирования всех 3 компонент: оперативный учет, бухгалтерский учет, расчет – преимущественно первых двух, умение использовать методы внешних библиотек (1с++, rainbow и т.п.) - Работа с типовыми конфигурациями 1С Предприятие 7.7 «Комплексной», «Зарплата и кадры» - Практический опыт работы с MS SQL Server 2000 в рамках работы 1С Предприятия 7.7 SQL-версии. Условия: м. Цветной бульвар, з/п "белая" обсуждается", с 9.30-18.00 конт. тел. 739-07-96 Юлия frolkova@taxcom.ru
Системный программист (Работа для IT специалистов)
2007-05-18 14:57 Lentochka
В крупную международную компанию, требуется системный программист. Высшее образование, более 2 лет системного программирования, опыт программирования на С/С++, Perl, HTML, XML, SQL. Знание Unix/Linux. Разговорный английский язык.
Обязанности: Работа с функциональными и техническими спецификациями для разработки программных продуктов. Использование С/С++, Perl, SQL, Unix/Linux и различных веб - приложений, необходимых для создания программных инструментов, оптимизирующих процессы в лаборатории тестирования. Взаимодействие с Департаментами компании. Документирование разработанных и внедренных решений.
Условия: з/п по договоренности с кандидатом (белая), соц. пакет. Уважаемые соискатели в случае вашей заинтересованности в нашем предложении просьба высылать резюме на e-mail с указанием Ваших зарплатных ожиданий и мы свяжемся с вами! Вопросы по вакансии можно задать по ICQ 478206688 Елена
1. Довольно крупная контора. Я пообщалась с одной ПМ, она составила для себя представление о том, что я знаю, чего не знаю, и мы фактически договорились, что я у них буду работать. Но после того мне предстояло собеседование с нач. отдела и менеджером по кадрам. Эти у меня спрашивали, например, следующее: -почему вы решили работать в этой области; -как я себе представляю работу? что такое тест план? что мне, по-моему мнению, может понадобиться для тестирования? -есть ли у меня опыт организации чего бы то ни было, попросили привести пример (ну вот хоть в пионерском лагере отрядом руководить) -если возникнет вопрос, я попытаюсь найти ответ сама или спрошу скорее? что может помешать спросить в такой ситуации? -если я считаю, что в конкретном деле лучше сделать так, а не иначе, промолчу я, или проявлю инициативу? После того мне было предложено на английском рассказать о своем образовании. На английском же спросили, ставила ли я когда-нибудь SQL сервер. После собеседования сочли не брать человека без опыта.
2. Контора поменьше. Спросили -что такое URL -где я буду смотреть в Enterprise manager, связаны ли между собой таблицы? -попросили перевести прямо с экрана написанные по-англ. слова и предложения; -попросили решить пару логических задачек. -наконец, попросили протестировать страницу на голландском языке: т.е. нужно было задействовать исключительно логику и проверить на предмет адекватности переноса информации в бекенд.
Впечатление осталось самое приятное и в компанию меня взяли.
Теперь мои мысли об этом. Я не вижу вообще никакого смысла в вопросе "почему тестером"? Особенно у человека с опытом аналогичной работы. Тех, кто так упорно выше на этот момент указывал, попрошу перечислить, какие, на ваш взгляд,здесь могут быть ответы и что вам это даст? А вот выяснить, понимает ли человек, куда идет - более чем логично, но это нужно сделать по-другому.
Вопрос про управленческие способности и просьба привести пример меня поставили в тупик. Я молча сижу и думаю: что я здесь могу сказать? Примеры по выполнению заданий в группе в университете? Глупо. Что я играю в муз. группе и являюсь там организатором? - полный оффтоп, да и какое имеет значение? На предыдущих работах мне подобных организационных вопросов решать не приходилось, в итоге из этого вопроса они ничего не вынесли для себя, а я, в свою очередь, ответила что-то невнятное и обобщенное. Разговор на английском. Зачем? И пусть я могу поболтать ни о чем, но разве это свидетельствует о том, что я смогу с успехом понимать ТЗ на английском и разную документацию? Очевидно, нет. А если у меня и вовсе плохо с разговорным? На кой, спрашивается, нужно устраивать школьное собеседование типа "I'm a student of.. blablabla"? Наконец, зачем мне нужно уметь устанавливать сервер?
Нет, в чем-то, может, и адекватные вопросы, но в результате им они ничего не дали, и они сочли, что я не смогу работать там, хотя я смогла бы, думается - этот вывод сделала менеджер, которая говорила со мной до того куда более "по существу".
Зато собеседование во вторую компанию было совершенно другим. Здесь все четко - пару вопросов на общую грамотность, задача на сообразительность, причем мне дали время, чтобы подумать, плюс я не сразу решила правильно - спросили, как у меня это получилось - я рассказала - выяснилось, мыслила я правильно, но ошиблась в расчете. Остальное - перевод и пробное тестирование - точно также давали представление о том, смогу ли я реально работать здесь.
Таким образом, второе собеседование было менее формальным (=> я не напрягалась, что играет роль в поизведении того или иного впечатления) , зато более конкретным, и, что самое главное, позволило выяснить то, что действительно было нужно выяснить. А какие психологические мотивы мною движут, есть ли у меня прописка и не организовывала ли я чего в пионер-лагере - никого не должно волновать. Ибо я пришла устраиваться тестером, а не управленцем или сис. админом или еще кем.
1) Ну блин .. когда все жостко зашито в какой-нить agent.dll, конечно придется каждый раз ждать новой версии :(
Это ты о чем?
QUOTE(vass @ May 18 2007, 10:33 AM)
2) про браузеры -- лучче промочать, во избежание мегафлейма
Ну, браузеры - это не единственная болячка Силка.
QUOTE(vass @ May 18 2007, 10:33 AM)
3) по теме : ну надеюсь они в дальнейшем будут придерживаться одной системе версий и перестанут вносить баги в уже работающие места (да, я мечтатель! ) [right][snapback]42333[/snapback][/right]
Лучше бы поддержку нестандартных контролов наращивали, а то цена уже неслабая, а эффекта минимум. Более-менее нормально можно тестить разве что стандартный ГУИ и веб, а если дело дойдет до чего-то еще, а чаще всего и доходит, то тут начинаются неприятности. И получается, что со временем продукт просто зачахнет, а индусы со своим шедевральным кодированием на 4Test-е просто добьют Силк.
обратите внимание на, то что не требуется, что бы человек имел опыт руководства командой, есть возможность начать работу над одним проектом, после чего, постепенно взять на себя ответственность за все проекты в компании и занять должность Тест Менеджера.
А как насчет Xtrem-а? (Спорт)
2007-05-18 17:46 Mamonteshka
Вобщем так: 1) Доска - 1 штука - выдираешь дверцу от любимого маминого шкафа 2) Ролики - 4 штуки - любимое кресло на колёсиках (желательно шефа) 3) Склоачиваешь всё в скейт 4) Выбираешь горку покруче, желательно без пересечения с дорогами... 5) Заходишь на самый верх 6) Садишься на своё творение и отталкиваешься Вобщем после этого сможешь сам писать мануалы как научиться кататься
Таким образом, второе собеседование было менее формальным (=> я не напрягалась, что играет роль в поизведении того или иного впечатления) , зато более конкретным, и, что самое главное, позволило выяснить то, что действительно было нужно выяснить. А какие психологические мотивы мною движут, есть ли у меня прописка и не организовывала ли я чего в пионер-лагере - никого не должно волновать. Ибо я пришла устраиваться тестером, а не управленцем или сис. админом или еще кем. [right][snapback]42343[/snapback][/right]
Я тоже склоняюсь к мнению, что на собеседовании следует больше уделять внимание профессиональным вопросам. Тем не менее полностью отбрасывать психологические моменты, пожалуй, не стоит. Помимо знаний и умений у кандидата должны быть способности к "приживаемости" в коллективе. Все-таки сейчас в IT заправляют не психи-одиночки, а слаженные команды. Поэтому данному моменту все-таки стоит уделять внимание. Просто в разных конторах и приоритеты разные. Особенно это стоит учитывать небольшим компаниям, где ошибка с выбором сотрудника наносит достаточно ощутимый ущерб.
Тем не менее личностные характеристики лучше выявлять неявно. Просто наблюдать за кандидатом, перевести разговор в более спокойное русло, сделать так, чтобы человек психологически расслабился и вел себя естественно. Вот в этом случае можно выявить, как он себя будет вести в обычных условиях.
То есть:
человек пришел собеседоваться на должность тестировщика - проверяйте его знания как тестировщика, при этом присматривайтесь к нему, изучайте его как человека. Ведь если ошибетесь, то вам с ним придется все-таки определенное время промучаться
QA Engineer / Test Manager (Работа/Киев)
2007-05-18 21:42 Akeem
Мда придется мне немного подучится или ещё поработать. Тк я только тестер с полугодним стажем. Если не считать довольно приличную теоретическую базу.
Какую литературу почитать для ознакомления с QA? (Обеспечение качества ПО - QA)
2007-05-18 21:46 Akeem
Подскажите какую лиетратуру мне нудно почитать или опишите по пунктам какие знания должны быть у специалиста по QA? У меня есть базовые знания по методам зазработки, методам тестирования ПО, разрабатывал сам методы тестирования некоторых тонких частей ПО. Хотелось продвинутся в изучении такого предмета как обеспечения качества, но с чего начинать я не знаю. Подскажите.
Заранее благодарен!
Пакет навыков для начинающего тестера (Управление тестированием ПО: тест менеджмент)
2007-05-18 22:00 Akeem
Когда меня брали тестером мне задавали те же вопросы, что озвучила toftinoporo про то почему тестер и подобное. такде мены попросили пройти логический тест, который с известен в инете как "Если бы все улитки..". далее меня попросили составить тесткейсы для тестирования виртуальной программы "треугольник". Этот тест был взят с Канера с некоторыми модификациями. Также задавали вопросы о моих знаниях тестирования ПО, не упомянув о том какие методы тестирования я знаю. Это есть минус. В результате меня взяли на работу.
А вообще вопросы задаваемые на собеседованиях по вакансии тестировщик можно классифицировать как: 1) вопросы общего характера -- коротко о себе 2) вопросы о прошлой работе -- кем и сколько времени вы работали 3) ваши знания о тестировании -- уже по существу задаются вопросы как на англ так и на рус. спрашивают основы тестирования (тест план, методы тестирования) 4) психологические тесты -- тесты как на логику, так и на восприятие 5) практическое задание -- просят написать или рассказать как вы будете тестировать ту или иную программу (например, блокнот) 6) описать баг -- не обязательный пункт, задается только тем кто немного уже работал в сфере тестирования.
UPDATED! Яндекс:нагр.тестирование, Linux (Москва) (Работа/Москва)
2007-05-19 00:07 Case
Дёрнулся было скопировать задачку в форум, но тут же понял что придётся тогда менять задачку в вакансии, потому как тут же будет обсуждение и несколько вариантов решений в этой теме :)
Задачка хорошая, я такого типа но без привязки к компьютерной области, давал на собеседованиях старших тестеров: про сеть автозаправок в городе.
Если вы хотите по серьезному подойти к вопросам качества, то могу порекомендовать классиков: - J. Juran "Quality Control Handbook", есть в эл виде в инете. - P.Crosby "Quality is free". Кстати, недавно на русском вышла его книга "Качество и я...". Практики нет, но мне понравилась, ибо о философии качества на примере своей жизни рассказывает. - все очень рекомендуют Деминга, но я сам не читал пока что.
Из русских друзей: - Мне очень нравятся книги Вадислава Ильина. Написаны живо и практично, к тому же заточены именно под ИТ (в отличие от большинства других) Вот его книжки: ∙ Руководство качеством проектов. Практический опыт ∙ Моделирование бизнес-процессов. Практический опыт разработчика ∙ Проектный офис - Центр управления... проектами. Системный подход к управлению компанией
- Виталий Елиферов "Управление качеством". Хороша...
Также в нете есть отличный ресурс, посвященный вопросам качества: http://quality.eup.ru/ Тут вы найдете тонны информации.
Какие знания должны быть у специалиста QA. Отличный вопрос. Когда я узнал требования в США к специалисту, мне стыдно стало за страну нашу:-( Учиться нам и учиться:) См требования к Software Quality Engineer тут, также тут .
Это не цель. Называйте как хотите: "мысли вслух", "неспешные размышления", "благие пожелания",- но это не цель.
Определение. Цель есть нормированное представление о достижимом результате.
Хм. спасибо за хорошую идею. Наиболее близким видом деятельности из сферы разработки ПО, к тому чем я сейчас занимаюсь, является рефакторинг. И ведь действительно при принятии решения о начале рефакторинга проводится анализ того, для чего подобная работа нужна.
Однако у всех рефакторингов есть одна цель: сделать не хуже, а по возможности лучше чем было. А вод задачи этих работ уже совершенно различные. Так что позвольте мне оставить цель неизменной, а вот задачу на начальный этап работ сформулировать следующим образом: создание формального описания 60% процессов связанных с разработкой ПО в компании. Допущения: в сферу интереса начального этапа не попадают процессы связанные с наймом сотрудников, заказом отпусков/больничных и т.п. Должны быть описаны процессы в которых принимает участие более 1 человека или же которые встречаются более чем в одном проекте. Не рассматриваются процессы непосредственного заполнения форм - эти этапы описываются как факт, что форма должна быть заполнена.
Возможно я что-то упустил из допущений. Ну и конечно нет методики выбора тех самых 60% счастливчиков - я постараюсь придумать и дописать это позже.
В своих проектах я оцениваю количество обнарженных дефектов как отношение к количеству тестовых сценариев. При этом 3 параметр учитывается автоматически. Качество тестирования я принимаю за постоянное в разных проектах, т.к. обеспечиваю его я. А вот качество ПО бывает разным. Но обычно количество дефектов находится в пределах от 15% до 30% от числа сценариев.
Меня больше интересует, зачем оценивать количество дефектов в проекте? О чем скажет это магическое число?
Т.е. сначала мы по неким метрикам проекта оцениваем количестов дефектов. Потом по другим неким другим метрикам, оценивам время и ресурсы на баг-фиксинг (мне кажется, что цель именно в этом). Почему бы не оценивать риски проекта напрямую?
QUOTE(Clauster @ Sep 25 2006, 02:52 PM)
В общем, мне кажется, это нереально оценить без метрик. [right][snapback]33727[/snapback][/right]
[right][snapback]40741[/snapback][/right]
Количество дефектов необходимо оценивать для определения трудоемкости работ по регистрации, ведению и проверки исправления дефектов. В результате получаются довольно значительные затраты, сравнимые с затратами на проведение сценариев. Не думаю, что правильно было бы относить их к рискам.
имееется допустим некий набор тесткейсов, условно говоря покрывающий всю функциональность приложения. данный набор проверяется на каждом билде. собственно отсюда вопрос, зачем нужен тест-план? и для кого он делается? для тестировщика, босса, заказчика? или просто потому что так надо? :) интересуют как общие мысли на тему так и примеры из личной практики. Спасибо. [right][snapback]40477[/snapback][/right]
План тестирования нужен для следующих целей: 1. Помочь автору сформулировать условия тестирования и таким образом понять что, как (стратегически) и с какими ограничениями он будет тестировать. 2. Сформулировать условия тестирования на уровне абстракции понятном менеджменту проекта для их согласования. 3. Использование плана в качестве руководства к действию на всех этапах тестирования. 4. Использование плана для ввода в курс дел новых сотрудников на проекте.
К задаче можно подходить двояко: - снизу; - сверху.
Сверху. Решающую роль играет опыт предыдущих аналогичных проектов. В прошлый раз примерно такую же задачу мы тестировали 5 часов, выполнили 50 тестов, протестировали на 65% от общего списка требований.
Снизу. На проекте имеем 100 требований. Каждое требование тестируется одиним тестом. Количество прогонов теста - от 4 раз (минимум) до 8 раз (максимум) - зависит от количество наборов тестовых данных. В среднем тест занимает от 2 до 5 минут. Каждый третий тест падает (по предыдущему опыту), значит плюс 5 минут на занесение проблемы в базу дефектов. Все суммируем по минимуму - получаем самый оптимальный вариан. Затем суммируем время наихудшего варианта. Берем среднее. [right][snapback]15095[/snapback][/right]
Интересные оценки. Тесты автоматические? Дефекты у вас автоматически регистрируются? Что-то не верю я в такие оценки...
