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

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

Вопросы таковы (все относительно testlink):
1. Насколько это некорректно?
2. Чем это чревато?
3. Могут ли у меня возникнуть проблемы при формировании тест-плана?

• Зависит от разнородности тестов и их сложности.
• Чревато следующим:
  
  • суть теста не отражается в его заголовке
  • у нескольких тестов будет один результат выполнения: Пройден/Непройден/Блокирован
  • трудоёмкость выполнения нужно будет указывать общую
  • при повторном тестировании нужно будет долго вчитываться, чтобы понять какому тесту соотвествует прикреплённое замечание
• При назначении исполнителей теста проблем не возникнет. При выполнении тестов сложность будет только в том, что в примечании к результату выполнения, а в самом статусе результата выполнения будет отражаться информация какой из тестов пройдён, а какой нет. При анализе результатов и повторном тестировании также будет путаница.

Но если тесты очень похожи - то можно так сделать. Также часто делают "параметризированные" тесты вида:
Шаг 1. Выполните просмотр объекта, на который у пользователя права доступа {Нет прав, Просмотр, Изменение, Полные}.
Ожидаемый результат 1: Если {Нет прав} - сообщение об ошибке. Если {Просмотр, Изменение, Полные} - корректный просмотр, без сообщений об ошибках.

Ещё бывает когда шаги теста отражены в заголовке или описании теста.
А в самом тесте есть только список ожидаемых результатов для разных ситуаций (а шаги опущены) вида:
Ожидаемый результат 1: Если {условие 1}, то {результат 1}
Ожидаемый результат N: Если {условие N}, то {результат N}

Здравствуйте. Да достаточно. Возможно, даже излишне достаточно, ведь можно обойтись меньшим.

При написании модульных тестов использую NUnit (см. http://www.nunit.org/). Атрибуты, Assert-ы, обработку исключений использую от NUnit, а не от Microsoft. Это позволяет разрабатывать тесты, например, в SharpDevelop или Visual Studio Express. Основная причина, почему отказался от Microsoft Unit Testing:

• Сложно параметризировать модульные тесты, а нужна была именно параметризация. NUnit позволяет задавать списки параметров через явное определение (Values, см. http://www.nunit.org...=values&r=2.6.2 ), что гораздо удобнее чем CSV или Datasource (таблица или представление базы данных).
• Тесты нужно выполнять на нескольких конфигурациях. При использовании mstest на машине где запускаются тесты нужно иметь Visual Studio. Это несложно, количество имеющихся лицензий позволяет поставить. Но NUnit гораздо меньше Visual Studio, подготовить стенды было проще.

Конечно, результаты NUnit не сохраняются автоматически в TFS, в отличие от использования mstest (использование фреймворка Microsoft), и это недостаток. Но так как не было требований со стороны разработчиков, отображать результаты тестов в TFS, то всё нормально,

Что касается Microsoft Test Manager, не имею опыта работы с этим продуктом. Но если это большой продукт, то думаю он не нужен для выполнения модульных тестов. Вам стоит стремиться к автоматизации их выполнения. А значит тесты нужно выполнять одной командой, используя nunit или mstest. А если требуется более сложный анализ, например, анализ логов по завершении теста, и автоматическая рассылка результатов, то можно использовать сценарии nant, powershell или даже bat (или функционал TFS, раз у вас используется TFS).

Уважаемый, зашел на перевод, покопался немного и возникли следующие вопросы:
1. В версии 1.9.4 лежит несколько более полный по количеству строк, большей частью переведенный, почему бы его не допилить до конца?
2. Зачем дважды переводить часть файла?
3. В файле \testlink\locale\ru_RU\string.txt в моем testlink 1.9.4 в разделе // ----- gui/templates/execNavigator.tpl ----- 22 строки, в файле для перевода всего 4. В чем причина расхождения?

Здравствуйте.

>> 1. В версии 1.9.4 лежит несколько более полный по количеству строк, большей частью переведенный, почему бы его не допилить до конца?
У меня имеется добротный перевод для 1.9.3. Сейчас допиливаю его до конца.
Добавил имеющийся файл в качестве вложения - custom_strings.txt.

Если есть возможности уделить время улучшению локализации testlink, то можете открыть файл custom_strings.txt и скопировать те разделы, что в нём уже переведены в соотвествующие поля абзацев на сайте http://translatedby..../into-ru/trans/
Там, где все строки раздела переведены надо поставить - Готово (будет оранжервый раздел).
Там, где не всё переведено или нет уверенности в корректности перевода, Готово ставить не надо - абзац будет светло-оранжевым.
Заранее спасибо, за уделённое время.

>>2. Зачем дважды переводить часть файла?
Имеющийся перевод - для 1.9.3, для синхронизации с 1.9.5 по большей части переносится имеющийся текст + вычитывается. Ответ - для синхронизации (перевод с 0-ля не выполняется).

>>3. В файле \testlink\locale\ru_RU\string.txt в моем testlink 1.9.4 в разделе // ----- gui/templates/execNavigator.tpl ----- 22 строки, в файле для перевода всего 4. В чем причина расхождения?
Считается, что актуальная локализация находится в файле локализации en_GB. Другие локализации являются переводом этого файла и синхронизируются с ним.
См. файл http://gitorious.org..._RU/strings.txt строку 6:

Russian (ru_RU) strings (en_GB is default development language)

Ответ на вопрос, куда делись строки локализации такой - строк для фильтров стало больше. Для фильтров сделали отдельный шаблон, а строки локализации этого шаблона вынесены в новый раздел "gui/templates/inc_filter_panel.tpl".

Старый раздел русской локализации http://gitorious.org..._RU/strings.txt
22 строки (563-585):

// ----- gui/templates/execNavigator.tpl -----
$TLS_TestPlan = "Тест-план";
$TLS_btn_apply_filter = "Применить фильтр";
$TLS_btn_update_menu = "Обновить дерево";
$TLS_caption_nav_filter_settings = "Параметры выборки";
$TLS_caption_nav_filters = "Фильтры";
$TLS_caption_nav_settings = "Настройки";
$TLS_current_build = "Текущая версия";
$TLS_filter_owner = "Отбор по владельцу";
$TLS_filter_result = "Отбор по результатам прогона";
$TLS_filter_on = "на";
$TLS_filter_tcID = "Отбор по номеру теста";
$TLS_include_unassigned_testcases = " - включая неназначенные тесты";
$TLS_test_status_all_status = "Все";
$TLS_filter_result_all_builds = "ВСЕ сборки";
$TLS_filter_result_any_build = "ЛЮБАЯ сборка";
$TLS_filter_result_specific_build = "особая сборка";
$TLS_filter_result_latest_execution = "последнее выполнение";
$TLS_filter_result_current_build = "Сборка, выбранная для исполнения";
$TLS_filter_somebody = "Некто";
$TLS_exec_build = "Сборка для выполнения";
$TLS_filter_result_all_prev_builds = "Результат по ЛЮБЫМ предыдущим сборкам";
$TLS_filter_result_any_prev_build = "ЛЮБАЯ предыдущая сборка";

Был разделён на два в текущий момент http://gitorious.org..._GB/strings.txt :
Тут 4 строки (712-716):

// ----- gui/templates/execNavigator.tpl -----
$TLS_TestPlan = $TLS_testplan;
$TLS_btn_update_menu = "Update menu";
$TLS_caption_nav_filter_settings = "Filters & Settings";
$TLS_test_status_all_status = $TLS_test_status_all;

Тут старые и новые строки:

// ----- gui/templates/inc_filter_panel.tpl -----
$TLS_logical_and = "And";
$TLS_logical_or = "Or";
$TLS_btn_apply_filter = $TLS_btn_apply;
$TLS_btn_reset_filters = "Reset Filters";
$TLS_caption_nav_filters = "Filters";
$TLS_caption_nav_settings = "Settings";
$TLS_current_build = "Current build";
$TLS_filter_owner = "Assigned to";
$TLS_filter_result = "Result";
$TLS_filter_on = "on";
$TLS_filter_tcID = "Test Case ID";
$TLS_include_unassigned_testcases = "include unassigned Test Cases";
$TLS_filter_result_all_builds = "ALL Builds";
$TLS_filter_result_any_build = "ANY Build";
$TLS_filter_result_specific_build = "specific Build";
$TLS_filter_result_latest_execution = "latest execution";
$TLS_filter_result_current_build = "Build chosen for execution";
$TLS_filter_somebody = "Somebody";
$TLS_exec_build = "Build to execute";
$TLS_assign_build = "Build to assign";
$TLS_filter_result_all_prev_builds = "ALL Previous Builds";
$TLS_filter_result_any_prev_build = "ANY Previous Build";
$TLS_document_id = "Document ID";
$TLS_req_type = "Requirement Type";
$TLS_req_spec_type = "Req. Spec. Type";
$TLS_btn_hide_cf = "Hide Custom Fields";
$TLS_btn_show_cf = "Show Custom Fields";
$TLS_btn_export_testplan_tree = 'Export Test Plan';
$TLS_expand_tree = "Expand tree";
$TLS_collapse_tree = "Collapse tree";
$TLS_filter_active_inactive = "Active/Inactive";
$TLS_show_only_active_testcases = "At least ONE version is ACTIVE";
$TLS_show_only_inactive_testcases = "ALL versions are INACTIVE";

В текущем файле русской локализации (в том, что используется у вас) нового раздела нет. И суммарное количество строк локализации в имеющемся у вас файле - меньше, чем нужно.
Сейчас на http://translatedby..../into-ru/trans/ выполняется перевод локализации en_GB (как основной), поэтому в соотвествующем абзаце результата перевода - 4 строки.