Коллега тут написал про ВЫСОКОУРОВНЕВЫЕ (GUI) тесты

Хотел я этот текст обработать и "убрать местную специфику", но чувствую - пока сил на это нет.

Посему (с любезного разрешения коллеги) публикую текст "как есть" скажем так "в RAW-формате".

Мне есть что тут добавить и есть что "убавить", но мысли там изложенные - В ЦЕЛОМ совпадают с моим виденьем.

Посему публикую текст коллеги:

Продолжаю переписывать тесты (пока переписано больше 100 тестов с цепочкой TRY-FINALLY-END). В ходе работы, предложил проверить 2 «новых» сценария сотруднику группы качества с целью убедиться, что сценарий – понятен и воспроизводим.

Выяснилось следующее: 

1. Существует проблема с переводом пикселей в примерные размеры.
2. Сам сценарий, даже самый простой – вызывает дополнительные вопросы. Хотя, такой же сценарий из К (по тексту ошибки) – вопросов не вызывает. Связываю это с наличием картинок в К. Получил такой ответ:
«Если нужно точное воспроизведение – то лучше второй сценарий (старый). Если важно выполнение руками – тогда первый (новый вариант теста). Но большое количество тестов по старому сценарию вручную  – не воспроизвести».
К счастью, точное воспроизведение и не нужно. Его сделает тестовая машина. А человек руками сможет легко сделать примерный сценарий и увидеть в чем проблема.

Также, набросал несколько критериев подробности. Но их нужно еще дополнять.

Критерии подробности для написания тестов и заполнения словарей.

1) Заголовок теста всегда называется Тест K…; слова, которые ничего не оставляют после своего выполнения в стеке – PROCEDURE; слова, которые передают значения в стек для последующей работы – FUNCTION.
2) При написании теста использовать максимально простые и понятные фразы. Их толкование не должно вызывать дополнительных вопросов.
3) Словари делятся на высокоуровневые (прикладные) и низкоуровневые (технические) (они не должны ссылать на высокоуровневые).
4) Избегать дублирования кода.
5) Если мы пытаемся что-то “узнать” у контрола и при этом модифицируем его состояние – это плохо.
6) Если не хватает каких-то ручек для работы с контролами – нужно написать задачу на их создание.
7) Не переусложнять конструкций слов (использовать композицию и декомпозицию).
8) Не пропускать в описании мелочи, которые «известны всем», т.к. то, о чем думает и что известно «писателю», не всегда ясно и известно «читателю».
9) Обязательно! Обязательно при изменении умолчательных настроек, не зависимо от того, как пройдет тест, необходимо вернуть настройки!
10) Максимально приближать алгоритм теста к пользовательским действиям (например, требуется открыть любой список: нужно построить новый список, а не пытаться открыть ранее сохраненный, если это не указано явно).
11) Делать структуру теста плоской, т.е. избегать цепочек Если-то-иначе, TRY-FINALLY-END в тексте теста (нужно прятать их в словари). Тоже самое касается и выполнения определенных действий. Например, «Открыть оглавление и выполнить {(@ Действия)}» можно вызывать через WordWorker: «Открыть оглавление и выполнить» ( … ).
12) Стараться придерживаться единого стандарта при написании новых слов. Например, «Узнать что-то» - записать что-то в стек, «Сравнить с эталоном что-то» - записать что-то в эталон. Заголовки новых слов писать с заглавной буквы.
13) Избегать дублирующихся сценариев. Если они очень похожи – можно во втором тесте постараться добиться нужного результата с помощью с помощью других ручек. Например, отсортировать список, в первом случае, с помощью контекстного меню, во втором случае, с помощью команды главного меню.
14) Избегать использования в тесте английских слов и символов (исключения составляют название теста и названия клавиш).
15) Обязательно оставлять комментарии в местах, сложных для понимания и местах, где изменен исходный сценарий (почему изменен).
16) Не забывать расставлять ASSERTS в новых словах.
17) Не забывать расставлять отступы в коде, для наглядности иерархии.
18) ## - символы, которые несут справочную информацию для «читателя». Например, «## убедиться, что настройки в умолчательном состоянии».