Сегодня утром я получила письмо, которое, в частности, гласило:
У меня появилась возможность попробовать себя в роли тест-тренера намоем нынешнем рабочем месте (6-7 команд из 4-5 разработчиков).
У меня состоялась встреча с руководителем разработки, и она хочет, чтобы я стал практически тест-консультантом. Она ожидает от меня создания системы, в которой я задаю командам вопросы, вскрывающие ключевые проблемы тестирования. Она также хочет иметь ключевые метрики, которыми можно измерять успех.
Мой вопрос в том, есть ли у вас набор вопросов или подход, позволяющий командам открыть для себя свои крупнейшие проблемы тестирования? Можете ли вы подсказать, что почитать на эту тему, или какой-либо подход?
Вот лично мой подход к старту карьеры в роли тест-тренера.
Пишу тестовый проект для наших Silverlight-приложений (Silverlight 5, VS 2015). За основу взяты библиотеки семейства TestTools, в частности UITesting с ее UITestControl. Однако, зачастую в проектах использованы библиотеки DevExpress. Особенность элементов из них в том, что Coded UITest Builder часто вылетает при попытке добавить такой элемент в UI карту, иногда вылет происходит при обращении к соседнему ЭУ или при обходе стандартных ЭУ средствами навигации билдера, если в одном уровне с ними есть такой DevExpress элемент.
Однако часть этих проблемных контролов хорошо управляется через библиотеку UI Atomation. Но вот в чем проблема: по моему опыту, перейти из одной иерархии в другую (мне интересен переход от UITestControl к AutomationElement) легко можно только через AutomationElement.FromHandle(), причем Handle в дереве UITestContol-ов можно доступен в двух местах: UITestControl.Desctop и UITestControl.WindowHandle. На мой взгляд - это довольно далекие узлы иерархии. Получаем окно - это окно браузера и начинаем спускаться по AutomationId до нужного элемента. Хотелось бы что-то более однозначное.
У UITestControl есть свойство NativeElement. В случае UITestControl.TopParent (окно браузера) - это массив из двух элементов. Первый элемент можно привести к IAccessible, и это работает. Но это уж совсем старая технология, как я понял и она содержит наименьшее количество свойство и методов и подобных. Второй элемент число, как правило 0. Получить из этой связки AutomationElement у меня не получилось. Я пробовал по-разному, например: (win.NativeElement as object[])[0] as AutomationElement или AutomationElement.FromIAccessible(acc, 0), где acc - это приведенный к IAccessible 1-й элемент массива - не работает. Но по крайней мере, я смог получить объект из другого фреймворка, пускай и ненужного в данном случае.
Я решил попробовать то же самое для конкретного UITestControl - для SilverlightCheckBox. В результате NativeElement представлял собой массив уже из трех элементов: 2, 636627633619708604, "CheckBox". Здесь только простые типы и явно это уже не IAccessible элемент. Но я так же не смог получить AutomationElement из данного набора. Пробовал AutomationElement.FromHandle(<подставлял большое число и пытался из него получить IntPtr>) - не помогло, IntPrt из него не получается :)
Объясните пожалуйста, как правильно работать и для чего вообще нужно свойство NativeElement? Его физический смысл, откуда оно вообще взялось, и из чего состоит?
Можно ли как-то точно получить AutomationElement из UITestControl если NativeElement заполнено?
PS
Пока писал, вспомнил про программный поиск ЭУ через FindMatchingControls или просто Find. Как там это работало - надо освежать в памяти, какие-то DX ЭУ можно было так получить, но все равно проблемы были. Вспомню, отпишусь об этом обязательно дальше в этой теме.