Тэг: мнение

Тестирование начали ценить(бонус в конце статьи).

Большую часть времени работы в сфере тестирования на пространстве СНГ не очень то ценились навыки специалистов по тестированию.

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

Но системы начали усложняться, а именно их логика и те процессы, которые происходят под капотом.

Поэтому тестирование наконец-то начали ценить:


Сейчас, чтобы качественно протестировать такое ПО нужна: 

 -определенная доля погружения в предметную область;

 -понимание взаимодействия компонентов ПО друг с другом;

 -понимание каналов, по которым двигаются данные;

 -учет и понимание критериев качества, таких как:

  •     функциональная пригодность;
  •     производительность;
  •     совместимость со средой эксплуатации;
  •     удобство;
  •     надежность;
  •     защищенность;
  •     сопровождаемость;
  •     переносимость.


Тестировщик сейчас решает задачи не только непосредственного тестирования, но и :


  • Разворачивание среды окружения(эта задача настолько серьезна, что иногда ее отдают отдельным devops специалистам )
  • Подготовка к релизу(документация, сбор и аккумулирование информации со всех участников процесса разработки)
  • Отслеживание метрик качества ПО(количество перекрытия задач, количество багов  на ПРОМе, количество критичных багов на регрессе и т.д.)



Наряду с привычными видами тестирования на первый план начали выходить: безопасность и нагрузочное тестирование.

Особенно актуально для web mobile продуктов с доступом для любого пользователя в интернете.


Поэтому даже начинающим нужны азы тестирования безопасности и нагрузки.

Про самодисциплину, умение объяснять, договариваться и другие личностные качества специалистов я уже молчу. Это считается само собой разумеющимся.


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


Какие базовые знания важны на первом этапе, чтобы начать?

Для каждой компании это будет немного своя вариация.


Для примера, составленная мной карта развития для начинающего джуна(может называться в компании "младший тестировщик" или как-то по другому) может помочь вам понять какой примерный объем знаний и навыков от вас могут ожидать:

Уверенный джун:

*В графе "Тестирование производительности"  "Введение" означает, понимание основ тестирования производительности: для чего, какие возможные кейсы и т.д.



Данные таблицы можно рассматривать как карта развития сотрудника.

Т.е. смОтрите, что есть на следующем уровне и изучайте данную тему. При изучении необходимого пула можно с большей уверенностью просить пересмотр контракта=)

Предложенные карты развития тестировщика всегда будут несколько специфичны для каждой компании.

Кто-то делает больший упор на инструментарий и написание различных скриптов, элементы автоматизации, кому-то важнее качественный тест-дизайн. Вобщем каждому свое.


Любите то, что делаете и развивайтесь!


Как лучше начать изучать автоматизацию?

Краткое содержание статьи(перевод):  https://clck.ru/32C2y5

Автор: Bas Dijkstra


Ниже будет представлено краткое содержание статьи, отвечающее на вопрос как лучше начать изучать автоматизацию?


В основном, почему-то, большинство начинает изучать UI-автоматизацию.


В какой-то степени понятно, что люди начинают свой путь по автоматизации именно с этого. 


Причины по которым начинают именно с автоматизации  UI:


1. Это то, что люди знают. Как тестировщики, мы привыкли взаимодействовать с приложением через графический интерфейс пользователя. Поэтому вполне логично начинать наши усилия по автоматизации именно с этого, не так ли?


2. Команды часто начинают свои усилия по автоматизации с «автоматизации регрессионных тестов». Поскольку они обычно пишутся с точки зрения конечного пользователя, они часто ссылаются на UI.


3. Поскольку, к сожалению, большая часть автоматизации все еще часто пишется (намного) позже кода приложения, не всегда много внимания уделяется тестируемости. В результате пользовательский интерфейс часто является единственным интерфейсом, доступным для автоматизации.


Однако автоматизация графического интерфейса является сложной задачей. На самом деле, это, безусловно, самая сложная форма автоматизации.

Основная причина этого, и ее, по мнению автора, не так часто обсуждают, заключается в том, что графический пользовательский интерфейс является единственным интерфейсом в приложении, который явно написан для использования людьми.


Все другие интерфейсы в приложении (будь то база данных, API или сам код) используются компьютерными процессами или взаимодействуют с ними (клиент базы данных, клиент API, другой код и т. д.). Сам факт того, что эти интерфейсы предназначены для использования машинами, упрощает их автоматизацию.


Например, автор статьи поклонник тестирования пользовательского интерфейса с помощью модульных тестов.

Такие фреймворки, как React, позволяют, например, тестировать логику и компоненты пользовательского интерфейса изолированно от остального кода. 


В качестве альтернативы можно рассмотреть API тесты.

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


Это снова приводит к тому, что многие относительно неопытные инженеры по автоматизации отчаянно пытаются автоматизировать все самым трудным из возможных способов: путем написания тестов с полным стеком через графический пользовательский интерфейс приложения. 


Автор статьи выступает за более целостный способ обучения автоматизации. Автоматизация пользовательского интерфейса может (должна быть) частью этого, но она определенно не должна быть отправной точкой и даже не должна быть очень большой частью пути обучения автоматизации.