IT-встречи в Таллине (на русском)

Октябрьская встреча: QA

Уважаемые коллеги!

Октябрьская встреча клуба по сложившейся традиции состоится в четверг, 29 октября, в отеле Ору, чей конференц-зал любезно предоставлен спонсором клуба — фирмой Helmes — в наше распоряжение с 18:45 до 23 часов.

Нынешняя встреча посвящана всему тому, что на буржуйском диалекте скрывается за аббревиатурой QA: темам управления и обеспечения качества кода, тестированию софта и нелёгкой профессии тестера.

dilbert-on-qa

Своимы мыслями, примерами, опытом и идеями в этот раз с собравшимися будут делиться:

  1. Сергей Сергеев (WebQA / Skype) — «Что такое (web)тестирование и с чем его едят?» — (definition / стереотипы / что делает тестер? / зачем нужны тестеры? / когда тестируют? /как тестируют? / где учат тестированию? / модные тенденции / Eesti Testijate Liit)
  2. Антон Шишков (QA / Skype) — «Краткий обзор программ для автоматичесткого тестирования» (Hands-on: Selenium)
  3. Станислав Катков (QA Engineer / HireRight Estonia) — «Автоматическое тестирование для работающих проектов» — (задачи тест-отдела / что можно автоматизировать / выбор стратегии для автоматизации / критерии для выбора инструмента)
  4. Антон Литвиненко (CTO / Programeter) — «Термометер для управления проектом» — (что же такое метрика? / демо Programeter-а / социальный граф в команде разработчиков / измерение вклада в разработку ПО)

Начало первого доклада — ровно в 19 часов. После 2-го и 3-его докладов — добровольно-принудительный networking в компании одноклубников и напитков с плюшками.

Идя навстречу пожеланиям трудящихся, регистрация на эту встречу будет открыта дважды в разное время: в пятницу, 23 октября во второй половине дня (первая половина мест) и в понедельник, 26 октября в первой половине дня (остальные места). Следите за обновлениясм на сайте!

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

Назад

«Я и другие» Феликс Соболев (1971 г.)

Далее

Три.. два… один — поехали!

16 комментариев

  1. Вопрос Станиславу и Антону Ш.

    Предположим есть приложение с UI. И тесты для него. Каким образом использовать один и тот же тест, чтобы сегодня прогонять его на localhost:8080, завтра — в тестовой среде, а послезавтра в live?

    Кикие трудности вы видите и как бы вы их решили.

  2. Anton Shishkov

    ну если ИД объектов нормально проставленны то просто меняется URL стартовой страницы:
    sel.open(«http://local…..»)

    а если ссылки и кнопки сильно привязаны к УРЛу, то надо base_url вывести как переменную и просто заменить везде ссылки на
    sel.click(base_url+»/my_page/action»)

    • ответ понятен. на самом деле я не имел в виду проблему с разными URLами. Такой подход очевиден если приложение не зависит от того, что лежит в базе данных.

      А если будет сильная завязка на данные,в dev, test и live системах, где эти данные заведомо разные?

      • Если говорить в общих чертах, то нельзя хранить в коде теста никаких hard coded данных. Для всего использовать параметры. Для разных env использовать разные конфиги. Если есть места, которые нужно обойти, то циклы в помощь 🙂

        Если говорить про Selenium, то можно самому изобрести свой фрэймворк, а можно использовать testNG. В последнем есть data provider и вся мощь Java/Jython

        • если не хранить в коде теста, то значит хранить где то в другом месте. должны же быть данные на которых проверять работу приложения (входные данные), и не суть где они лежат. пускай в отдельном «хранилище», и эталонные данные, с чем сравнивать результат.

          если просто автоматизировать кнопконажимательный процесс, и смотреть, появилась ли ссылка или div с таким то id то это немножко другое.

          я говорю о приложениях, где необязательно вообще UI есть.

          TestNG вроде был ближе JUnit-у, который вроде как предназначен для unit-тестов, но я посмотрю на всякий случай, спасибо 🙂

          • >если не хранить в коде теста, то значит хранить где то в другом месте
            именно. Данные можно хранить в .properties и .xml файлах. Зависит от того, что поддерживает язык програмированиечя/платформа. testNG также поддерживает базу данных и excel.

            Это будет выглядить приблизетельно так:
            1 записываем тест
            вместо
            open(«/login»);
            type(«pw», «superadminpwd»);
            click(«Login»);
            waitForPageToLoad(«30000»);
            verifyTrue(isTextPresent(«Welcome to test environment, user»));

            2 выводим данные из теста
            open(app_url);
            type(pass_field_name, password);
            click(login_button);
            waitForPageToLoad(timeout);
            verifyTrue(isTextPresent(welcome_text));

            3 и например делаем .properties файлы: для теста, лайва и независимых данных
            # test env properties
            app_url=internal.example.com/login
            password=superadminpwd
            welcome_text=Welcome to test environment, user

            # live env properties
            app_url=myclient.domain.com/login
            password=tarara
            welcome_text=Welcome to admin area, user

            # general properties
            pass_field_name=pw
            login_button=Login
            timeout=30000

            3 при запуске теста указываем какая среда нам нужна

            Маленький пример с testNG есть здесь http://keepcoding.blogspot.com/2009/02/running-selenium-with-testng.html

            Может быть Антон Шишков мог бы рассказать об этом подробнее во время доклада

            >если просто автоматизировать кнопконажимательный процесс, и смотреть, появилась ли ссылка или div с таким то id то это немножко другое.
            я говорю о приложениях, где необязательно вообще UI есть
            Я думаю что например для вебсервисов подойдёт указанный выше метод, просто вместо селениума использовать другой test driver — soapui

      • Станислав

        Вопрос слишком конкретный, поэтому решил ответить тут. Ничего не знаю про TestNG, но….

        я записываю все ключевые значения в enviroment.ini файл, в духе:
        [test01]
        url= http://www.devclub.eu
        db = ora.devclub.eu
        db_port = 1500
        db_sid = dc
        db_user = admin
        db_pass = admin

        [production]

        Когда запускаю автоматический скрипт указываю ENVIROMENT_ID, который должен обязательно ровняться названиям секций из ini файла (test01, production). Тогда автоматический скрипт будет проверять там где надо.

        Я надеюсь у меня получилось ответить на вопрос.

        • на самом деле пока что все ответы были на тему настроек тестового моторчика, а мой вопрос скорее о том как подготавливать 2 набора данных — а) входные данные для тестов, которые должны быть в БД, когда пробегают тесты, и б) данные для проверок правильности работы функционала.

          я лучше вас всех на встрече вопросами помучаю 🙂

  3. kaznachei

    Вопросы к Станиславу:
    — Как внедрять автоматическое тестирование на legacy проектах, где его небыло изначально?
    — Подготовка и синхронизация тестовой среды с девелоперской версией продукта.
    — Тестовая БД vs Mocking

    К Сергею и Антону Ш.:
    — тестирование SOAP и REST (веб)сервисов.
    — Автоматизация тестирования web UI для различных браузерных платформ(IE/FF/Safari/etc compatibility testing)

    Ко всем:
    — Инструментраий для performance-тестирования front и back-end

    • Станислав

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

      — Подготовка и синхронизация тестовой среды с девелоперской версией продукта.
      Отличный вопрос, но помоему немного не в тему. Подготовка среды обычно входит в задачи администратора.

      — Тестовая БД vs Mocking
      Отличный вопрос. Постараюсь ответить во время выступления.

      — тестирование SOAP и REST (веб)сервисов.
      http://www.soapui.org/

    • — тестирование SOAP и REST (веб)сервисов
      я знаю только о SoapUI, но сам этим никогда не занимался

      — Автоматизация тестирования web UI для различных браузерных платформ(IE/FF/Safari/etc compatibility testing)
      Selenium как раз был разработан с целью тестирования функциональности на разных браузерах. Один и тотже тест должен работать на IE, FF, Safari, Opera.
      Позже первые разработчики Selenium-а основали http://saucelabs.com/ — «a hosted online testing platform that provides you instant access across today’s 10 most popular browsers to ensure your web applications work flawlessly for all users»

      Остальные фрэймворки (Watir, SilkTest, IBM Rational Tester) поддерживают только IE и FF

      — Инструментраий для performance-тестирования front и back-end
      на своей практике в 1 проэкте, в уже незапамятные времена, пытались использовать OpenSTA, но он давно не обновлялся и не заработал в тестовой среде. В итоге тесты были переписаны (не мною) на JMeter и приложение в закрытом лайве успешно выдержало 50 человек как и требовалось.
      Ещё слышал о JPerf, но никогда им не пользовался

      Performance back-end’a в проэктах где я участвовал никогда не тестировали, но по результатм того же JMeter’a и по логам были выявлены и оптимизированы узкие места в базе.

    • Anton Shishkov

      К Сергею и Антону Ш.:
      — тестирование SOAP и REST (веб)сервисов.
      — Автоматизация тестирования web UI для различных браузерных платформ(IE/FF/Safari/etc compatibility testing)

      SOAP -> использовал soapui, он уже даже пару лет назад имел АПИ, которые можно было вызывать из Явы, очень удобно.

      — Автоматизация тестирования web UI для различных браузерных платформ -> Если ты хочешь сравнивать как отображается текст (с визуальной точки зрения), то тут мало что можно посоветовать, надо глазками смотреть 🙂

  4. Maxim

    Я что-то упустил или видео на эту встречу выложено не будет?

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

*

Работает на WordPress & Автор темы: Anders Norén