Глоссарий ISTQB: буква А

Коллеги!

В связи с тем, что не всем удобно использовать шару на Гугле Докс для обсуждения вариантов перевода терминов, попробуем проводить обсуждение прямо в форуме.

Этим сообщением открывается весенне-летний сезон споров.


Что бы сделать обсуждение максимально продуктивным прошу в одном посте обсуждать ТОЛЬКО один термин. Иначе ваши замечания в отношении второго, третьего и последующих терминов могут остаться незамеченными.

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

На старт!
Внимание!
Марш!

Буква А.

1. abstract test case - See high level test case. - Абстрактный тест кейс - СМ Верхнеуровневый тест кейс

2. acceptance - See acceptance testing. - Приемка - СМ Приемочное тестирование

3. acceptance criteria - The exit criteria that a component or system must satisfy in order to be accepted by a user, customer, or other authorized entity. [IEEE 610] -
Критерии приемки - Приемочные критерии - это условия, которым компонента или система в целом должна соответствовать для того, что бы она была принята пользователем, заказчиком, либо другим учолномоченным лицом.

4. acceptance testing - Formal testing with respect to user needs, requirements, and business processes conducted to determine whether or not a system satisfies the acceptance criteria and to enable the user, customers or other authorized entity to determine whether or not to accept the system. [After IEEE 610] -
Приемочное тестирование - Приемочное тестирование - формальное испытание системы, проводимое с целью определения соответствия реализованных требований, бизнес процессов, потребностей пользователя приемочным критериям. На основании резултатов приемочного тестирования пользователь, заказчик или другое уполномоченное лицо принимает решение о приемке системы в эксплуатацию.

5. accessibility testing - Testing to determine the ease by which users with disabilities can use a component or system. [Gerrard] -
Удобство использования - Тестирование, целью которого является определение удобства использования компоненты или системы в целом людьми с ограниченными физическими возможностями.

6. accuracy - The capability of the software product to provide the right or agreed results or effects with the needed degree of precision. [ISO 9126] See also functionality testing. -
Точность - Способность программного продукта предоставлять правильный, или согласованный результат, или проводить вычисления с заданной степенью точности. См. также функциональное тестирование

7. action word driven testing - See keyword driven testing - Тестирование через ключевые слова - СМ Тестирование через управляющие слова

8. actual outcome - See actual result. - Актуальный итог - СМ Актуальный результат

9. actual result - The behavior produced/observed when a component or system is tested. - Актуальный результат - Поведение компоненты или системы во время тестирования.

10. ad hoc review - See informal review. - Спонтанная проверка - СМ Неформальная проверка

11. ad hoc testing - Testing carried out informally; no formal test preparation takes place, no recognized test design technique is used, there are no expectations for results and arbitrariness guides the test execution activity. -
Неформальное тестирование - Тестирование, проводимое спонтанно, не на основании спроектированных тестов; тесты заранее не готовятся, для их проведения не используются специальные техники тестирования, проверочные результаты не определены, и тестовые операции выполняются произвольно.

12. adaptability - The capability of the software product to be adapted for different specified environments without applying actions or means other than those provided for this purpose for the software considered. [ISO 9126] See also portability. -
Приспособляемость - Способность программного продукта адаптироваться к различным специфичным окружениям без применения действий или методов отличных от предоставляемых для этой цели самим программным продуктом. СМ также Переносимость

13. agile testing - Testing practice for a project using agile methodologies, such as extreme programming (XP), treating development as the customer of testing and emphasizing the test-first design paradigm. See also test driven development. -
Гибкое тестирование - Практика тестирования, используемая в проектах с гибкой методологией разработки программных продуктов (например, экстремальное программирование - XP), рассматривающая разработку через написание тестов и использующая парадигму "вначале тесты, потом код". СМ также Разработка через тестирование

14. algorithm test [TMap] - See branch testing. - Алгоритм тестирования - СМ Ветвь тестирования

15. alpha testing - Simulated or actual operational testing by potential users/customers or an independent test team at the developers’ site, but outside the development organization. Alpha testing is often employed for off-the-shelf software as a form of internal acceptance testing. -
Альфа-тестирование - Моделирование или боевое тестирование потенциальными пользователями/клиентами или независимой командой тестирования в окружении разработчиков, но за пределами компании разработки. Альфа-тестирование часто применяется для коробочных продуктов как форма внутреннего приемочного тестирования

16. analyzability - The capability of the software product to be diagnosed for deficiencies or causes of failures in the software, or for the parts to be modified to be identified. [ISO 9126] See also maintainability. -
Анализируемость - Способность программного продукта к диагностированию на предмет наличия программных дефектов и причин программных сбоев, а так же на предмет идентификации внесенных в программу изменений.

17. analyzer - See static analyzer. - Анализатор - СМ Статический анализатор

18. anomaly - Any condition that deviates from expectation based on requirements specifications, design documents, user documents, standards, etc. or from someone’s perception or experience. Anomalies may be found during, but not limited to, reviewing, testing, analysis, compilation, or use of software products or applicable documentation. [IEEE 1044] See also bug, defect, deviation, error, fault, failure, incident, problem. -
Отклонение - Любые отклонения полученных результатов от ожидаемых, основанных на техническом задании, спецификациях, пользовательской документации, требованиях стандартов и т.п., или от чьих-либо предположений или предыдущего опыта. Отклонения могут быь выявлены в результате процессов (но не ограничены ими) проверки, тестирования, анализа, компиляции, а так же в процессе эксплуатации программы или изучения сопутствующей документации. СМ также Баг, Программный дефект, Отклонение, Ошибка (error, fault), Отказ, Инцидент, Проблема

19. arc testing - See branch testing. - Дуга тестирования - СМ Ветвь тестирования

20. attack - Directed and focused attempt to evaluate the quality, especially reliability, of a test object by attempting to force specific failures to occur. -
Атака - Целенаправленная и сфокусированная попытка оценки различных аспектов качества, в особенности надежности, тестируемого объекта для вызова специфических программных сбоев.

21. attractiveness - The capability of the software product to be attractive to the user. [ISO 9126] See also usability. - Пользовательская привлекательность - Способность программного продукта выглядеть привлекательно в глазах конечного пользователя. СМ Удобство и простота использования

22. audit - An independent evaluation of software products or processes to ascertain compliance to standards, guidelines, specifications, and/or procedures based on objective criteria, including documents that specify: (1) the form or content of the products to be produced; (2) the process by which the products shall be produced; (3) how compliance to standards or guidelines shall be measured. [IEEE 1028] -
Аудит - Независимое испытание программного продукта или процесса для проверки степени соответствия стандартам, инструкциям, спецификациям и/или процедурам, основанным на объективных критериях, включая документы, определяющие: (1) форму или содержание продукта, подлежащую реализации; (2) процесс, посредством которого продукт должен быть реализован; (3) способ оценки соответствия стандартам или инструкциям.

23. audit trail - A path by which the original input to a process (e.g. data) can be traced back through the process, taking the process output as a starting point. This facilitates defect analysis and allows a process audit to be carried out. [After TMap] -
Аудит пути - Путь обработки данных, по которому входные данные преобразуются в выходные, пройденный в обратном порядке, где выходные данные становятся отправной точкой пути. Является стандартным механизмом определения причин сбоев и позволяет выполнять аудит процесса.

24. automated testware - Testware used in automated testing, such as tool scripts. -
Средство автоматизации тестирования - Программный продукт, применяемый для автоматизации тестирования, например средства программирования тестовых скриптов.

25. availability - The degree to which a component or system is operational and accessible when required for use. Often expressed as a percentage. [IEEE 610] -
Доступность - Величина, характеризующая доступность и работоспособность системы в течении заявленного времени работы. Часто определяется в процентах.

1. abstract test case - See high level test case. - Абстрактный тест кейс - СМ Верхнеуровневый тест кейс

Замечания:
- почему не переводим фразу «test case»? На букву “t” есть это словосочетание и его вполне можно перевести на русский язык. Мой вариант «тестовый случай».
- верхнеуровневый – слово не очень хорошее, а word вообще такого не знает. Предлагаю заменить его на фразу «верхнего уровня».

Вариант перевода:
abstract test case - See high level test case.
Абстрактный тестовый случай – См. так же Тестовый случай верхнего уровня.

Предлагаю отмечать как-то термины, которые должны быть одинаково переведены во всех определениях словаря. Хороший вариант такой проверки и одновременно полезного дела, в будущем, – в каждом определении ставить ссылки на используемые термины в переводе. Т.е. в вышеуказанном определении будут ссылки на определение тестового случая и определение тестового случая верхнего уровня.

3. acceptance criteria- The exit criteria that a component or system must satisfy in order to be accepted by a user, customer, or other authorized entity. [IEEE 610] -
Критерии приемки - Приемочные критерии - это условия, которым компонента или система в целом должна соответствовать для того, что бы она была принята пользователем, заказчиком, либо другим учолномоченным лицом.

Замечания:
- «exit criteria» - термин, описанный в словаре. Думаю, его надо точнее перевести, чем просто «условия». Можно дождаться перевода буквы «e» :)
- component, на мой взгляд, лучше переводить как «компонент», а не «компонентА»
- учолномоченным – опечатка :) Вообще, опечатки есть и дальше, не буду в каждом определении их выделять :)

4. acceptance testing - Formal testing with respect to user needs, requirements, and business processes conducted to determine whether or not a system satisfies the acceptance criteria and to enable the user, customers or other authorized entity to determine whether or not to accept the system. [After IEEE 610] -
Приемочное тестирование - Приемочное тестирование - формальное испытание системы, проводимое с целью определения соответствия реализованных требований, бизнес процессов, потребностей пользователя приемочным критериям. На основании резултатов приемочного тестирования пользователь, заказчик или другое уполномоченное лицо принимает решение о приемке системы в эксплуатацию.

смущает слово «приемка», все время режет слух %-) Не исключаю, что это просто мой таракан. Предлагаю писать «о приеме системы в эксплуатацию» вместо «о приемке системы в эксплуатацию».

5. accessibility testing - Testing to determine the ease by which users with disabilities can use a component or system. [Gerrard] -
Удобство использования - Тестирование, целью которого является определение удобства использования компоненты или системы в целом людьми с ограниченными физическими возможностями.

Предлагаю переименовать термин. Удобство использования – это usability. Если по сети порыться, очень часто переводят «accessability» как «доступность».

Надо использовать хотя-бы примитивную разметку.
Предлагаю термины глоссария выделять жирным шрифтом. И в заголовке определения, и в тексте (при ссылке на термин).
Это позволит избежать неоднозначных переводов.

1. abstract test case - See high level test case. - Абстрактный тест кейс - СМ Верхнеуровневый тест кейс

Замечания:
- почему не переводим фразу «test case»? На букву “t” есть это словосочетание и его вполне можно перевести на русский язык. Мой вариант «тестовый случай».
- верхнеуровневый – слово не очень хорошее, а word вообще такого не знает. Предлагаю заменить его на фразу «верхнего уровня».

Вариант перевода:
abstract test case - See high level test case.
Абстрактный тестовый случай – См. так же Тестовый случай верхнего уровня.

Предлагаю отмечать как-то термины, которые должны быть одинаково переведены во всех определениях словаря. Хороший вариант такой проверки и одновременно полезного дела, в будущем, – в каждом определении ставить ссылки на используемые термины в переводе. Т.е. в вышеуказанном определении будут ссылки на определение тестового случая и определение тестового случая верхнего уровня.

Хотелось бы отметить, что в словаре встречается два вида ссылок на другие термины. See и See also. Первый значит, что это слово синоним, второй - что ссылка идет на близкий по смыслу термин. Поэтому, в данном случае надо писать не "см. также", а просто "см.".

4. acceptance testing - Formal testing with respect to user needs, requirements, and business processes conducted to determine whether or not a system satisfies the acceptance criteria and to enable the user, customers or other authorized entity to determine whether or not to accept the system. [After IEEE 610] -
Приемочное тестирование - Приемочное тестирование - формальное испытание системы, проводимое с целью определения соответствия реализованных требований, бизнес процессов, потребностей пользователя приемочным критериям. На основании резултатов приемочного тестирования пользователь, заказчик или другое уполномоченное лицо принимает решение о приемке системы в эксплуатацию.

смущает слово «приемка», все время режет слух %-) Не исключаю, что это просто мой таракан. Предлагаю писать «о приеме системы в эксплуатацию» вместо «о приемке системы в эксплуатацию».

С точки зрения русского языка - все ОК. Вполне допустимо и употребляется по жизни. Хотя, приходится слышать не просто приемочное тестирование, а чаще приемо-стадочное тестирование.
Это кстати пример того, что иногда английский термин , вполне себе хорошо переводится на русский несколькими правильными словосочетаниями. Предлагаю их все оставлять. Т.е. для acceptance criteria , можно иметь два русских термина Приемочное тестирование - .... и приемо-стадочное тестирование - см. Приемочное тестирование
Как и наоборот - бывает, что два английских термина (синонима) на русский переводятся единственным образом. В этих случаях предлагаю не пытаться перевести оба разными способами.

5. accessibility testing - Testing to determine the ease by which users with disabilities can use a component or system. [Gerrard] -
Удобство использования - Тестирование, целью которого является определение удобства использования компоненты или системы в целом людьми с ограниченными физическими возможностями.

Предлагаю переименовать термин. Удобство использования – это usability. Если по сети порыться, очень часто переводят «accessability» как «доступность».

100% согласен. Сам бы перевел как-нибудь так. Тестирование доступности или даже лучше тестирование общедоступности - тестирование, целью которого является установить сепень свободы, с которой компонентом или системой могут пользоваться люди с ограниченными возможностями.

8. actual outcome - See actual result. - Актуальный итог - СМ Актуальный результат

9. actual result - The behavior produced/observed when a component or system is tested. - Актуальный результат - Поведение компоненты или системы во время тестирования.

Думаю, выделенное не совсем корректно. Вместо "актуальный" я бы использовал "фактический", так как по смыслу это больше соответствует. То есть, это такой результат, который мы наблюдаем по факту его появления.

У вот этого

14. algorithm test [TMap] - See branch testing. - Алгоритм тестирования - СМ Ветвь тестирования

перевод несколько подозрительный. Скорее это переводится ближе к "Тестированию алгоритма" и "Тестирование ветви", но для уточнения надо рассмотреть branch testing

Предлагаю писать «о приеме системы в эксплуатацию» вместо «о приемке системы в эксплуатацию».

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

Буква А.
...
6. accuracy - The capability of the software product to provide the right or agreed results or effects with the needed degree of precision. [ISO 9126] See also functionality testing. -
Точность - Способность программного продукта предоставлять правильный, или согласованный результат, или проводить вычисления с заданной степенью точности. См. также функциональное тестирование
...

Предлагаю:
"Точность - Способность программного продукта предоставлять правильный, или согласованный результат, или проводить вычисления с необходимой степенью точности. См. также функциональное тестирование."
Заданная - значит кем-то или чем-то, но заранее и независимо от продукта. А необходимая (needed) - может определяться и самим продуктом (программой) в зависимости от того, какие цели должны быть достигнуты.

Буква А.
...
3. acceptance criteria - The exit criteria that a component or system must satisfy in order to be accepted by a user, customer, or other authorized entity. [IEEE 610] -
Критерии приемки - Приемочные критерии - это условия, которым компонента или система в целом должна соответствовать для того, что бы она была принята пользователем, заказчиком, либо другим уполномоченным лицом.
...

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

Предлагается:

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

Предлагаю писать «о приеме системы в эксплуатацию» вместо «о приемке системы в эксплуатацию».

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

совершенно согласна.
меня это слово тоже смутило, но потом мысль потеряла, похоже... :)

У вот этого

14. algorithm test [TMap] - See branch testing. - Алгоритм тестирования - СМ Ветвь тестирования

перевод несколько подозрительный. Скорее это переводится ближе к "Тестированию алгоритма" и "Тестирование ветви", но для уточнения надо рассмотреть branch testing

branch testing я предложил перевести или как Тестирование переходов или как Тестирование ветвлений

У вот этого

14. algorithm test [TMap] - See branch testing. - Алгоритм тестирования - СМ Ветвь тестирования

перевод несколько подозрительный. Скорее это переводится ближе к "Тестированию алгоритма" и "Тестирование ветви", но для уточнения надо рассмотреть branch testing

branch testing я предложил перевести или как Тестирование переходов или как Тестирование ветвлений

Тестирование ветвлений мне больше нравится. И к оригиналу ближе и смысл примерно сохраняется

Коллеги!

Большое спасибо за комментарии. Там, где я был полностью согласен с ними, я сразу же заменил в тексте. Те, которые, на мой взгляд, требуют дополнительного осмысления, я добавил как варианты перевода.

Теперь все могут видеть этот документ (букву А), так как я расшарил его для просмотра. Идти нужно по следующему линку:
http://spreadsheets....5suIX3_hNKF3yLA

Просьба.
Все комментарии по букве А писать в эту тему (ветку) форума. Давайте закончим с этой буквой (и оставим дальнейшее обсуждение остальным) и перейдем к следующей букве.

10. ad hoc review - See informal review. - Спонтанная проверка - СМ Неформальная проверка

11. ad hoc testing - Testing carried out informally; no formal test preparation takes place, no recognized test design technique is used, there are no expectations for results and arbitrariness guides the test execution activity. -
Неформальное тестирование - Тестирование, проводимое спонтанно, не на основании спроектированных тестов; тесты заранее не готовятся, для их проведения не используются специальные техники тестирования, проверочные результаты не определены, и тестовые операции выполняются произвольно.
----
Роман Савин, "В тестирование дот.ком". Перевёл ad hoc testing - как интуитивное тестирование, мне кажеться по смыслу больше подходит. //(!) не 100%, приду домой уточню.
p.s. Товарищь Green! я решительно негодую, активно вас спамлю на мыло и в личные сообщения, и все не могу выложить букву e.
отпишите пожалуйсто на AnthonyMarchenko at gmail.com