RunAs чем не устраивает?

Ну и второй вариант - править авто-логон и через ребут.

Помогите выбрать между самокатом и велосипедом :-)

В этой паре мы выбрали TestLink.

Версионность продукта обеспечивается билдовой системой. Какое отношение это имеет к тест-планам?

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

Не вдаваясь в глубокие рассуждения, разницу между просто менеджером и призванным менеджером я бы оценил процентов в 30-40.

даже не знаю с чего начинать...

Предлагаю начать отсюда:
http://www.ozon.ru/c...ail/id/2816263/

Статья интересна, как отображение собственного опыта. Некоторые могут на ней поучится. В связи с этим я бы назвал ее, с вашего позволения, с небольшой коррекцией ("Как УСПЕШНО пройти собеседование на тестировщика у Натальи Руколь")

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

У Вас есть опыт собеседования 300+ человек? Поделитесь :-)

Можно еще посмотреть, какие функции оно зовет для печати на экран.

В принципе, такая возможность есть, но я попробовала уже проверить для дескрипторов с номерами от 3 до 9 (включительно) и итог везде получился одинаковый :(

Оба ответа неправильные :-)
Не бывает лифтов с таким количеством кнопок :-)
Они или пропускают часть этажей или для подъема на более высокие нужно пересаживаться.

Берём нью-йорксую 80-этажку. 80*79=6320. Тест от 0,5 до 4 минут. 210 часов, 27 рабочих дней, 5 недель :)

80*80 будет правильнее.

И в самом деле, должно быть 2>&1
в файл оно аппендит правильно (>>)

Для перенаправления вывода команд из окна командной строки в файл надо применять оператор «>».
У вас же используется оператор «<».

Могу предположить только одно - .exe не пишет в stdout, поэтому и не перенаправляется.

В результате файл test.txt создается, но никакие данные в него записываются :(
Для обычных cmd-команд, описанных в help'е (например, xcopy, more и проч.) это перенаправление работает...
Не сталкивался ли кто-нибудь с подобной проблемой?

Здесь Вы можете найти вариант таблички: http://quality-lab.r...I-Calculations/

Табличка сильно упрощенная :-)
Не учитываются расходы на поддержку авто-тестов (в частности, внесение изменений вслед за продуктом) - при нестабильных интерфейсах они становятся существенным факотором.
И не учитываются разница в зарплатах исполнителей.

Опять же, при отсутствии авто-тестов количество прогонов резко сокращается :-)

Но в целом подход верный - при нестабильных интерфейсах результаты тестов будут появляться позже и обходиться дороже.

на fail можно придумать тысячи кейсов :)

кейсов да, но классов эквивалетности все-таки меньше...

Маловато, маловато будет :-)

Еще могу предложить
procedure void Name(int i
procedure void Name ()(int i)
procedure void Name(,int i)
procedure void Name (int i,)
procedure void Name((int i))
procedure void int Name(int i)

ответ предполагается примерно такой:

тесты, на которых должно проходить:
procedure void Name()
procedure void Name(int i)
procedure void Name(long l)
procedure void Name(int i, long l)
+ аналогично для <return type> = int

тесты, на которых должно выдавать ошибку:
procedure void ()
procedure Name()
procedure long Name()
procedure int Name(string s)
procedure int Name(int i long l)
...

также проверить "<name>, <param name> - идентификаторы, соответствующие требованиям java" - попробовать начать с цифры, например. я требования java уже точно не помню.

мне новый дизайн домашней странички тоже не нравится :-)

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

Есть 2 этапа - выкачивание дерева и работа в нем.
Второй зависит больше от браузера.

Добрый день
Мне поставили задачу о внедрение TestLinka в нашей конторе. И сделать это надо централизованно на одном серваке. Проблема в том, что фирма большая, много подразделений и продуктов, и наработанных тестов много, за 100 000 штук в общем по фирме и кол-во будет продолжать расти. Соответственно возникают сомнения, а потянет mySQL такое кол-во тестов при единовременной работе от 10 до 30 человек?

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

Еще стоит уделить внимание оптимальной организации проектов (скажем, 100K тест-кейсов в одном проекте - это плохое решение, т.к. они все будут в одном дереве).

У TestLink есть импорт и экспорт тест-кейзов.
Нагенерить данные нужного объема для тестирования производительности несложно :-)

Есть ли возможность прикрутить TestLink к Оракловой базе?

Это же опен соурс :-)
Про простой способ перехода на новый бэкенд не знаю.
Можно спросит на http://www.teamst.org/phpBB2/

В таком случае, как понять руководителю кто хорошо работает?! :)

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

Писать автотесты по тест-дизайну, а не по багам :-)

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

А вывод какой? Не писать автотесты?

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

Не правда. Если это так, то моя текущая эффективность (как автоматизатора) или оценка (как принявшего решение) = 0. Я, в данный момент, пишу автотесты для верификации ранее найденых багов. Количество дефектов которое было ими найдено, пока 1 (дефект был не до конца починен - нашелся случай пропущенный при описании бага, при котором проблема всё ещё есть). Новых багов, найденых тестами 0.

Не учитываются расходы на анализ результатов и поддержку автотестов.

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

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

Оценивайте в деньгах.
Простейшая оценка:
{Время прогона ручных теста/тестов в часах} * {стоимость часа работы ручного тестера}* {N} - {стоимость на создание автотеста/автотестов}

{N} - число итераций;

Да, количество выявленных багов - это показатель эффективности автоматизации как процесса.

Правда для оценки работы группы автоматизации слабо подходит :-)
Скорее это оценка того, кто принял решение, что данные тесты требуют автоматизации :-)

Стоит ли смотреть на кол-во найденных автотестами багов?!

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

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

И для того, чтобы заробатывать деньги им достаточно 2-х статусов в JIRA.

Разрешить конфликт можно было бы созданием отчета в JIRA, который все статсы сведет к этим 2-м.

Это как раз исключения :-)

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

Править методику испытаний я бы посадил человека с опытом работы в тестировании не менее 3-х лет.

Фрося,

Знаю одного человека, который в статусе "студент" руководил отделом тестирования в количестве 30 человек в не самой последней российской софтверной компании. Знаю другого "студента", который за месяц заработал свой первый миллион рублей, будучи ведущим разработчиком одной поулярной онлайн-игры. Знаю еще двух "cтудентов", которые так и не доучившись, предпочли "студенчеству" довольно заманчивые вакансии в Редмонде во славу дядюшек Билла и Стива. Знаю еще много таких....

Или под словом "cтудент" вы подразумеваете просто "человека без опыта работы по нашей специальности"? Так бы и написали ;)

Не надо использовать стандарты или общепринятые практики как аргументы.

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

Например, у нас есть правило не переоткрывать заверифаенные баги, и это прошито в трекере (при этом ошибочные переводы resolved -> verified можно откатить). Т.е. если в какой-то сборке код работал, значит баг пофикшен.
А если баг вернулся, то это какая-то новая проблема.

Постарайтесь понять смысл вводимых изменений.

извените не буду рисовать диаграмму, были такие степы:

Open
In Progress
Reopened
Resolved
Tested on dev
Closed
Canceled
Delay


теперь:

Open
Resolved
Tested on dev
Closed

без возможности reopen from Closed

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

Добрый день!

Может кто сталкивался: необходимо проверить корректность путей в работе тонкого клиента при условии, что apache установлен на Unix-системе. Проблема в том, что она регистрозависима и иногда мы на этом попадемся, т.к. apache установлен на Windows.

Может можно как-нибудь обойтись без создания сервера на Unix?

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

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

Заявление о том, что TDD тормозит разработку, мягко говоря, не очень корректно. Проекты разные, люди разные. Я лично вполне представляю себе ситуацию, когда TDD разработку ускоряет.