вторник, 28 сентября 2010 г.

Test Automation Framework: Basics

Шняжка:
У меня таких много. Тысячи их. И все разной степени хреновости. Ну да не об этом речь.


Собственно зачем оно вообще нужно?
Для того чтобы было проще поддерживать ваши красивые автоматизированные тестики.


Цели (как завещала Элизабет Хэндриксон):

  1. Задать формат для описания тестов (тестовые базы, эксельки, текстовые файлики и прочая бла бла бла)
  2. Задать формат для общения с тестируемым приложением (собственно инструменты тестирования - Selenium, WatiR, JMeter, HQ QTP и прочая бла бла бла)
  3. Запускать тесты
  4. Получать результаты
Более или менее стандартные подходы, озвученные лет так семь назад, позволяют нам получить довольно разный уровень абстракции (бери и жри что нравится!). Вплоть до того, что для написания автоматических тестов не нужно будет писать код вообще. То есть какое-то базовое понимание происходящего иметь нужно будет, но не более того. Для расширения возможностей и фиксов да, нужно будет писать код, но для этого понадобится существенно меньше людей. С другой стороны дизайном тестов человеку занимающемуся расширением фреймворка тоже заниматься не нужно. И любой из вариантов будет в сотни раз лучше и гибче record/playback, при этом не сильно сложнее для конечного пользователя.

А что же вижу я?
Обычно я вижу что у нас садят человека писать именно тесты. Кодить, блджад. Каждый отдельно взятый тест кодить. И это вместо того чтобы создать нормальную среду для того чтобы абстрагироваться от конкретно процесса написания кода и перейти к тестовым сценариям и просто тест кейсам.
Придумыванием этого занимаются люди поедающие собак на тест менеджменте. То есть люди занимающиеся процессом оптимизации трудозатрат тупо просирают ресурсы. И ладно бы так...

Вторая проблема (вытекающая из первой) в том, что в том что я обычно вижу вокруг сами тесты порой довольно сложно отделить от окружения, вспомогательных библиотек и whatever you use. 

И ведь можно сделать все чтобы интегрироваться в TCM и прочий bug tracker безболезненно, но... who cares? Сначала всех хочется с разбегу долбануться лбом об стену, а потом уже думать как же ее обойти.


3 комментария:

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

    ОтветитьУдалить
  2. Зачем Вам создавать свое? Возьмите FitNesse или RSpec и пользуйтесь.

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

    А писать свое нужно часто потому что существующие решения не подходят по тем или иным причинам. FitNesse или RSpec покрывают далеко не все потребности которые требуются для автоматизированного фреймворка.

    ОтветитьУдалить