Ответы пользователя по тегу Тестирование ПО
  • Чем отличается функциональное тестирование от приемочного?

    @polarnik
    Тестировщик
    В теории функциональное и приёмочное - разные типы классификаций.

    Приёмочное - один из этапов тестирования в классификации "по времени выполнения" или "по хронологии", где есть разные виды:
    * Smoke-test - проверка, что приложение запускается, и что в нём работает основная функциональность
    * Приёмочное или входной тест - быстрая проверка того, что новая функциональность, которая отдаётся на тестирование вообще существует в приложении, и новую функциональность можно протестировать. На практике применяется только если разработчики и тестировщики находятся в разных отделах и разработчики выдают большой процент брака на тестирование, спешат и просто оттягивают время передавая на тестирование сырой продукт. А тестировщики, чтобы зря не тратить время на тестирование недоразработанных версий, придумали такой этап - приёмочное тестирование. Который по хронологии идёт перед основным
    * Основное тестирование - основные тесты на новую функциональность
    * Повторное тестирование - перепроверка, после исправления дефектов и более близкого знакомства с новой функциональностью
    * Регрессионное - перепроверка старой и новой функциональности, обычно тех блоков, которые могли сломаться при выводе новых фич

    А функциональное - это классификация по целям тестирования и тут на верхнем уровне всего два вида:
    * функциональное тестирование - проверка соответствия функциональным требованиям
    * нефункциональное тестирование - проверка соотвествия нефункциональным требованиям

    Классификация:
    https://github.com/polarnik/TypesOfTesting
    https://habr.com/company/npo-comp/blog/223833/

    Это в теории. А на практике, люди могут называть знакомыми словами знакомые действия. И приёмочное тестирование может означать что угодно.
    Ответ написан
  • Что бы подобрать для UI-тестирования десктопного приложения?

    @polarnik
    Тестировщик
    Использовал TestComplete. Инструмент хороший. Платный. Отладчик лучше всего работает, если язык проекта Delphi Script.

    1. Логику работы приложения отделите от форм. Чтобы в событиях форм лишь вызывались методы основного класса. В собственных разработках не всегда следую этому правилу, но следую. На форме есть текстовое поле, а в методе параметр типа string. На форме есть таблица на четыре колонки, в методе есть список классов (в классе четыре поля). И так далее.
    На основной класс уже пишутся модульные тесты.

    2. Используя такие инструменты как TestComplete, удобно писать регрессионные тесты на проверку правильности отображения заранее подготовленных данных. А проверять логику работы кликами - крайне тяжело.
    Советы:
    - после каждого действия проверяйте отсутствие диалогов с ошибками и отсутствие ошибок в логах;
    - выделите время на подготовку тестовых данных, хорошие тестовые данные в визуальных тестах крайне важны;
    - пишите короткие тесты (открыть, проверить, закрыть), не пишите тесты, которые длятся дольше 20-30-ти секунд.

    Вам придётся разработать API, хотя бы для таких частых действий как "открыть" и "закрыть" и API для проверки результатов (обращения к базе данных, файлам, логам). Визуальные тесты окупаются, если вы заявляете поддержку нескольких конфигураций (интерфейс единый, а окружение различное - операционные системы, базы данных, настройки, параметры шрифтов, ...). Если хотите тестировать только на одной конфигурации, то автоматизируйте самым минимум операций, не усложняйте.
    Ответ написан
    3 комментария
  • Реально ли стать тестировщиком ПО в 39 лет, учитывая то, что основная профессия далека от IT?

    @polarnik
    Тестировщик
    Обучаю коллегу, который старше меня. Он экономист, работал на телевидении, много где. Он, пока, молчит когда идёт обсуждение архитектуры, принципов DDD или вариантов реализации новой фичи. Но каждая минута, вложенная в его обучение, экономит мне две.

    По выбору места работы - выберите среднюю компанию, наиболее крупную коммерческую из средних. В таких компаниях есть отлаженный процесс обучения. Если хотите устроиться туда, откуда никогда не увольняют - устройтесь в государственную структуру, там тоже есть ИТ.

    Что касается литературы - читайте всё, литературу для разработчиков, аналитиков, архитекторов, руководителей. Так поймёте, что хотят от инженера по тестированию. Литературу для инженеров по тестированию тоже читайте, так научитесь говорить на одном языке с коллегами.

    Если прочтёте советы выше, между строк. То увидите, что в тестирование советуют идти студентам. Среди студентов, половина из которых сменит место работы при получении диплома, будете специалистом относительно высокого уровня. Также между строк прочтите и такой совет - запишитесь на курсы, станьте студентом. Могу сказать только по своей команде, постоянно обучаемся всему подряд. Новые продукты и библиотеки, внешние внутренние курсы, книги, журналы, онлайн-обучение, ... Когда учился в университете, учился меньше.

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

    @polarnik
    Тестировщик
    Selenium. Можно обращаться к элементу без id. Можно вообще все div на странице получать, выбирать из списка случайный. Кликать по нему. Выбирать можно, для простоты, по наименованию тега.
    Ссылки на документацию есть на странице https://code.google.com/p/selenium/
    Допустим, вы используете C# в качестве языка программирования, тогда описание выбора элементов по имени тега:
    selenium.googlecode.com/git/docs/api/dotnet/html/M...
    А именно: FindElementsByClassName
    Обычно помогает более гибкий метод: FindElementsByCssSelector
    Ответ написан
    Комментировать
  • Всегда ли модульные тесты должны быть независимыми друг от друга?

    @polarnik
    Тестировщик
    Раз в тегах есть bdd, то вы уже знаете, что такое Given, а что такое When.

    Так вот, два теста зависимы, если начало второго теста не возможно, без предварительного выполнения первого теста (корректного выполнения). Так по началу многие разрабатывают. Тест1 создаёт объект с наименованием objectName123, а Тест2 ищет объект objectName123 в Given и выполняет некие действия с ним в When, плюс десяток проверок успешности выполнения действий в Then.

    И так делать не надо по очевидным причинам.

    Независимый тест устроен так.
    Тест1 создаёт объект objectNameTest1_123 работает с ним, делает десяток проверок в Then.
    Тест2 в Given вызывает те же методы, что создают объект в тесте Тест1, создаёт объект objectNameTest2_123, но выполняет одну базовую проверку, или не выполняет никаких проверок на корректность создания вообще (вызывается только часть Given и When из Тест1).

    Тест2 предполагает, что Тест1 работает. И если Тест1 упадёт, то не выполняется предусловие начала тестирования для Тест1 (вызываются, ведь, одни и те же методы в одном случае, как основная логика теста, во втором как предусловия). И в отчёте будет видно, какие тесты были были провалены, а какие даже не начались (из-за того, что другие тесты были провалены).

    Независимость в том, что Тест2 сам создаёт для себя нужный контекст. Не надеясь, что этот контекст подготовлен во время выполнения предыдущих тестов (Тест1).
    Ответ написан
  • Какими технологиями должен владеть QA engineer в столице?

    @polarnik
    Тестировщик
    За 4 месяца сложно выучить новую технологию так, чтобы эти знания достойно оплачивались. Особенно, если технология изучается не для работы, а для дополнительного развития. Наверняка, уже есть сильная область знаний. Тот же Silktest. Или WebDriver. У этих продуктов столько особенностей, что на годы изучения хватит.

    Оговорка - работаю не в Москве, но в столице.

    Много знаний по Selenium WebDriver получил решая задачу - как в Continius Integration встроить тесты веб-клиента, использующие WebDriver. Научился поднимать программно тестовые стенды с агентами, работать с Selenium Grid, делать снимки экрана на удалённой машине во время ошибки, собирать ошибки JavaScript во время работы теста (для каждого браузера свой способ).
    Кажется, простая задача. Но если её не решить, ценность тестов нулевая, сколь бы красивым не был их код. А чтобы решить нужно много знаний и навыков. Есть целых пол года.

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

    Высокие нагрузки - очень интересная область. Если у вас есть пол года на чтение книг по реляционной алгебре, изучению того как формируются планы выполнения SQL-запросов, написанию собственного быстрого кода, умению писать мало кода (использовать фреймворки и эффективную декомпозицию). А также отладке, кодингу, анализу. То станете специалистом.
    JMeter, Graphite, Fiddler (или другой прокси) статут вашими помощниками.
    Ответ написан
    Комментировать