Qaengineer

Если вы используете Maven, можно использовать свойство rerunFailingTestsCount в maven-surefire-plugin.

Настройка в pom.xml:

Этот способ позволяет контролировать количество перезапусков, используя интерфейс TestExecutionExceptionHandler, который перехватывает ошибки теста.

Реализация:

Логика повторного запуска:

Метод для повторного запуска теста:

Этот способ позволяет гибко управлять перезапусками.

Так же для реализации похожего способа можно использовать TestWatcher.testFailed() или механизм Launcher в JUnit 5 для перехвата ошибок и управления перезапусками.

Можно использовать AspectJ для автоматического перезапуска тестов в случае неудачи:

Каждый из перечисленных методов имеет свои плюсы и минусы и это только часть способов и инструментов, которые позволят перезапустить тест.
А какие способы перезапуска тестов используете вы? 😉

#testing #automatization #java #qa #qaengineer #qaинженер #Junit5

Если вы занимались написанием тестов, то наверняка сталкивались с ситуацией, когда в тест нужно передать какой-либо объект. JUnit 5 предоставляет механизм Extensions, который позволяет значительно расширить функциональность тестов. Одной из наиболее полезных возможностей этого механизма является ParameterResolver, который позволяет автоматически внедрять зависимости (объекты) в тестовые методы.

В этой статье мы разберем, как работает ParameterResolver, какие функции он предоставляет и как его использовать для упрощения тестирования.

ParameterResolver — это интерфейс, который позволяет JUnit 5 передавать объекты (параметры) в тестовые методы во время выполнения тестов. Это особенно полезно, если вы хотите:

JUnit 5 предоставляет встроенные объекты, которые можно внедрять в методы тестов:

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

Принцип работы ParameterResolver включает три основных шага:

Чтобы создать собственный ParameterResolver, нужно реализовать интерфейс ParameterResolver. Этот интерфейс требует реализации двух методов:

После этого ваш ParameterResolver нужно зарегистрировать, добавив аннотацию @ExtendWith к классу тестов.

Допустим, у нас есть класс User с полями, конструктором и методом toString. Мы хотим автоматизировать его создание для тестов.

Вывод в консоль:

ParameterResolver в JUnit 5 — это не просто удобный инструмент, а мощный механизм автоматизации. Он:

Теперь вы знаете, как использовать ParameterResolver для упрощения написания тестов. Попробуйте внедрить его в своих проектах, чтобы превратить рутинное тестирование в удобный и понятный процесс. 😊

#testing #automatization #java #qa #qaengineer #qaинженер #Junit5

Если вы хотите узнать, что такое аннотация @Slf4j из Lombok, тогда эта статья для вас.

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

Когда мы используем аннотацию @Slf4j, она сама по себе ничего особенного не делает. Она просто добавляет в ваш класс поле вида:

Этот код создаёт статическое поле log, которое является экземпляром интерфейса org.slf4j.Logger. Метод LoggerFactory.getLogger() возвращает логгер, связанный с текущим классом (Class.class).

Самое приятное: вам не нужно писать это руками! Lombok делает всё за вас. Это как суперспособность: \"я не пишу код, но он есть\".

Представьте: вы вызываете log.info(\"Привет, мир!\"), а Lombok автоматически создаёт объект логгера и отправляет сообщение туда, куда нужно. Однако SLF4J — это всего лишь фасад, и без конкретной реализации логгирования (например, Log4j или Logback) он не заработает.

SLF4J не является полноценной системой логирования — это лишь интерфейс, который перенаправляет вызовы в реальную систему логирования. Это похоже на мост через реку: без него вы никуда не доберётесь. Таким \"мостом\" является библиотека slf4j-log4j12. Он берёт ваши вызовы логгера и переправляет их в Log4j, который уже записывает их в консоль, файл или куда ещё вы захотите.

Чтобы аннотация @Slf4j была доступна для использования, так же нужно подключить библиотеку Lombok.
При использовании моста slf4j-log4j12 происходит следующее:

Вот самый простой пример log4j.properties:

Это самый простой файл используемый мной для вывода событий уровня info в консоль. Это говорит Log4j:

1. \"Пиши всё от уровня INFO и выше\". log4j.rootLogger=INFO: Задается глобальный уровень логирования и аппендеры (места вывода логов).

2. \"Выводи всё в консоль\". log4j.appender.console: Определяет аппендер для вывода в консоль.Используется класс org.apache.log4j.ConsoleAppender, который выводит сообщения логирования в стандартный поток вывода (консоль).

3. \"Форматируй красиво: дата, поток, уровень и сообщение\". log4j.appender.console.layout: Указывает, какой формат (layout) будет использоваться для логов в консоли.

patternLayout.4. log4j.appender.console.layout.ConversionPattern: Задает формат сообщений логов.

Аннотация @Slf4j — это удобный инструмент и ваш лучший друг, когда дело доходит до логгирования. Она избавляет вас от скучной работы, но без правильной реализации (например, Log4j) она бесполезна. Подключите всё, настройте, и пусть ваши логи сияют, как новогодняя гирлянда! 🎄

P.S. Если дочитали до конца — вы герой. Теперь вы знаете больше о логгировании :)

#testing #automatization #java #qa #qaengineer #qaинженер #Junit5

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

Предсказав результат, я была уверена, что вывод будет одинаковым для обеих строк, но к моему удивлению, оказалось, что это не так! Давайте разберёмся, что происходит и почему.

Ответ и его объяснение:
Запустив код, я получила следующий результат:

Первая строка System.out.println(a == b); вывела true, что вполне ожидаемо, если считать, что обе переменные ссылаются на один и тот же объект с числом 1. Однако вторая строка System.out.println(c == d); неожиданно вернула false, несмотря на то, что обе переменные, казалось бы, тоже содержат одно и то же значение – 325. В чем же дело?

Магия кэширования

Чтобы понять, почему это произошло, нужно углубиться во внутреннюю работу Java. Оператор \"==\" при сравнении объектов в Java проверяет, ссылаются ли обе переменные на один и тот же объект в памяти. В случае с Integer, Boolean, Character, и Long, чтобы улучшить производительность, Java применяет кэширование значений для некоторых диапазонов чисел.
Для Integer JVM кэширует значения в диапазоне от -128 до 127. Это означает, что при создании объекта Integer в этом диапазоне Java не создаёт новый объект, а использует уже существующий из пула кэшированных значений.

Почему a == b вернул true.
Когда мы присваиваем 1 переменным a и b, Java использует одно и то же значение из пула кэшированных объектов Integer. Поэтому обе переменные a и b ссылаются на один и тот же объект, и a == b возвращает true.

Почему c == d вернул false. Значение 325 находится за пределами кэшируемого диапазона, и каждый раз при присвоении такого значения создаётся новый объект Integer. Поэтому c и d ссылаются на разные объекты, даже если у них одинаковое значение, и результат c==d будет false.

Вывод.
С подобной ситуацией мы сталкиваемся при попытке сравнить два объекта String и знаем, что надо делать, чтобы сравнить значения, а не ссылки на объекты. В общем, чтобы избежать путаницы стоит использовать equals.
Попробуем использовать equals и мы получим то что и будем ожидать:

Спасибо, если прочитали :) Возможно, более опытные уже знают эти особенности, но для меня это стало настоящим открытием, и я была очень рада, что узнала о них.

#testing #automatization #java #qa #qaengineer #qaинженер #Junit5

Когда-то давно наш далёкий предок вылез из мирового океана и начал эволюционировать. Встал на четвереньки, потом на две ноги, взял палку — слово за слово, и вот вы получили персональный ноутбук, должность QA-лида и отправились работать на удалёнку в распределённой команде.

В условиях плотного графика мы столкнулись с проблемой ненормированной нагрузки QA-лидов на проектах. И начали разбираться в причинах. О том, что из этого вышло, рассказывает QA-инженер red_mad_robot Настя Корень.

Чтобы понять, на что уходит время QA-лида в компании, которая создаёт цифровые продукты и сервисы, сначала нужно разобраться с его обязанностями. Для этого мы:

Дисклеймер: тема нагрузки лидов довольно объёмая, а местами и вовсе бесконечная. В этой статье мы постарались рассказать о самом интересном и поделиться материалами, которые можно брать и сразу применять на практике.

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

Саму суть онбординга все определяют по-разному, поэтому прежде всего мы провели опрос, в котором каждый участник команды рассказал, что это для него значит. Но результаты опроса все тоже интерпретировали по-своему, поэтому случился рассинхрон. Решили сделать подсказки в двух чек-листах:

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

На этом этапе QA практически не принимают участие. Из-за этого мы:

слабо погружены в бизнес-процессы клиента,

должны самостоятельно разобраться в материалах и документах первых встреч,

не можем на первых этапах заложить время на тестирование.

Это стандартная ситуация, к которой просто нужно быть готовым. Чтобы минимизировать разрывы, можно:

пользоваться чек-листами,

выстроить и зафиксировать систему передачи информации от PM QA-лиду.

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

пообщаться с потенциальными пользователями,

консолидировать результаты исследования,

проработать чистый вариант тестирования,

зафиксировать представление о критичных функциях,

проработать риски движения сроков и возможные варианты, где время можно срезать.

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

Тут у QA начинает кипеть работа. Сборки вот-вот поступят на тестирование, в команде прибавление, PM обрывает Zoom, а To Do List уже до Луны и обратно. Самое время показать свою суперсилу и приступить к активным действиям: ниже подсказки, которые помогут в работе на этом этапе.

Ещё на этом этапе важно выбрать и обсудить с командой релизный цикл. Какие есть варианты, их плюсы и минусы:

На этом этапе проводится подготовка к регрессу или оценка регресса заранее с QA. Мы даём оценку, исходя из процента своего участия в регрессе или от времени разработки. Есть нюанс — при такой оценке можно не учесть скорости и опасения других участников команды. А ещё оценка тестирования в процентах не всегда работает — бывают задачи, которые тестируются дольше, чем разрабатываются.

Подготовка и проведение демо-показа дают прозрачность в работе с клиентом и позволяют взглянуть на продукт со стороны. А ещё это возможность для дополнительного тестирования. Главное — составить сценарий показа и подготовить тестовые данные или видеоматериал.

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

Отдельный вопрос — как и когда готовить тестовую документацию. Договоритесь с клиентом о нужной тестовой документации и о сроках её сдачи (каждый спринт или к концу проекта). Если у клиента нет предпочтений, выбирайте документацию сами, но не забудьте согласовать. Учтите — если это произойдёт к концу проекта, то на QA упадёт большой объём работы, а именно этого мы и пытаемся избежать.

QA здесь задействованы в трёх основных активностях. Давайте чуть подробнее.

Оформление метрик по проекту

Определить метрики и формат их сбора нужно сразу же по приходу на проект: договориться с клиентом о метриках качества, количестве багов и т. д. А на этапе финализации остаётся только оформить их в таблицу, график или документ. Часто бывает так, что мы торопимся и забываем всё обговорить, а потом клиент хочет, например, отчёт на 100 страниц. Пахнет работой.

Работа с фидбэком от пользователя и клиента

Важно определиться с тем, кто собирает фидбэк, где вы будете его собирать (в Jira, Slack или Telegram) и какая информация передаётся QA: версия ОС, ID пользователя и т. д. При работе с фидбэком есть риски:

размытия ответственности, особенно если вы работаете в интеграционной команде;

увеличения нагрузки на QA-лида, если процесс передачи фидбэка не урегулирован.

Актуализация документации (ПСИ)

Стоит заранее обсудить формат проведения приёмо-сдаточных испытаний и зафиксировать результаты. Если не оговорить детали по ПСИ, есть риск, что придётся делать всё в последний момент. Помните: качественная документация — это хороший тон и плюс в карму.

Работа занимает много времени, но созвоны тоже — это факт, с которым трудно спорить. Достаточно просто заглянуть в календарь. Но, помимо времени, встречи забирают ещё и силы. А в условиях ненормированной загрузки QA-специалистов разбрасываться ресурсами не стоит. Поэтому к вопросу созвонов стоит отнестись внимательно. Например, определиться, каким составом на них ходить.

Договоримся сразу: мы рассматриваем встречи, которые подразумевают присутствие QA, — груминги, технические синки, демо и т. д. Созвоны вроде совещаний по согласованию бюджета и прочие встречи, где специалисты QA не требуются, выносим за скобки.

Есть три подхода к посещению созвонов при условии, что на проекте работает больше одного QA. Показываем в картинках.

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

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

Подход стоит применять в работе:

большой команды — в этом случае он скорее обязателен,

в условиях стабильности процессов на проекте,

при организации работы с разграничением зон ответственности сотрудников.

Чтобы повысить уровень взаимозаменяемости сотрудников, можно либо брать на встречу двух QA-инженеров, чтобы дальше они страховали друг друга, либо организовывать процесс погружения других QA в набор задач сотрудника, когда он, например, уходит в отпуск.

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

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

QA-лиды, как там с нагрузкой в вашей компании?

Над материалом работали:

текст — Настя Корень, Оля Никитина, Ксюша Сергеева,

редактура — Алина Ладыгина, Виталик Балашов,

иллюстрации — Юля Ефимова.

Чтобы ничего не пропустить, следи за развитием цифры вместе с нами:

Да пребудет с тобой сила роботов! 🤖

#red_mad_robot #qa #qaengineer

Сентябрь 2023 года на Stepik имеет символическое значение. Для нас это был не только первый месяц нового времени года или начало учёбы для школьников и студентов, а в первую очередь дата, когда нашей платформе исполнилось 10 лет! Это не просто юбилей, это повод взглянуть на долгий путь, который преодолел маркетплейс знаний. Поэтому сегодня хотим поделиться теми числами и историями, которые делают Stepik таким особенным.

Рождение и первые шаги

Задолго до того, как Stepik стал известной образовательной платформой, он начал свой путь конструктором открытых онлайн-курсов. Тогда ресурс носил немного другое название (Stepic до 2016 года), но уже на период открытия выделялся своей основной фишкой — «шагами» (steps).

Спустя столько лет это и сейчас очень ценная особенность платформы. Благодаря шагам вместо длительных лекций, пользователи могли проходить курс по подтемам урока, которые занимают от 5 секунд до 10-15 минут. Это было настоящей революцией, и те, кто помнят те далекие времена, наверняка вспоминают их с ностальгией. И хотя первая версия Stepik была далека от современной, она уже тогда несла в себе идею доступного образования. Но давайте немного отойдём от истории и вернёмся к настоящему.

Важные цифры и достижения

Десять лет – это долгий срок, и за это время Stepik сумел достичь внушительных результатов. Вот мы и решили посчитать и представить в цифрах всё, что успели сделать за это время. Небольшой спойлер — оказалось немало полезного и впечатляющего! Поэтому делимся с вами личными рекордами, чтобы показать, какой большой путь был проделан и как важно, что всё это мы совершили совместно.

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

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

Программирование на Python: классика Stepik, взрастившая и вдохновившая тысячи и тысячи программистов на работу в IT (а ещё обучила питону половину сотрудников самого Stepik).

Основы программирования: идеальное начало для тех, кто хочет освоить С#, курс заставляет много думать. И даже если вы давно его прошли, проверьте задачи, их список постоянно обновляется.

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

Программирование на Golang: курс, созданный лучшими учащимися Stepik.

СОТОЧКА ПО РУССКОМУ: один из самых лучших курсов по русскому языку для подготовки к ЕГЭ, если вы, конечно, хотите сдать на 100 баллов.

Пакет SQL курсов: первая на Stepik и одна из лучших специализаций по SQL в интернете.

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

Сертификаты теперь и на английском: Эта фича относится к рубрике «вы просили, мы сделали». Теперь, независимо от того, где вы находитесь, все наши курсы поддерживают выдачу сертификата на как на русском, так и на английском. Язык можно выбрать на странице сертификата. Напомним, что получить его могут все зарегистрированные пользователи, набравшие необходимое количество баллов в онлайн-курсе с выдачей сертификатов. Проверить выдается сертификат Stepik в выбранном вами обучении можно на его промо странице.

Страница автора: Мы обновили профиль автора курсов. Теперь он отличается от профиля учащегося, и каждый преподаватель может его кастомизировать под тематику своих курсов, загрузить обложку. Для того чтобы проверить, как выглядит страница автора сейчас, можно перейти в меню в правом верхнем углу нажать на аватар — «Профиль» и на кнопку «Преподавание».

Ответы на отзывы: А ещё некоторое время назад у авторов появилась другая классная возможность — отвечать на отзывы на курс.

Рейтинги: Мы вернули рейтинг пользователей, который вас так мотивировал двигаться вперёд. При желании вы можете узнать действующий ТОП по знаниям и по репутации и, возможно, даже найти там своё имя, если вы входите в список 1000 самых активных пользователей :)

Новое отображение стриков: Отличная новость для всех, кто любит ставить перед собой вызовы — теперь отслеживание своих достижений в обучении стало ещё удобнее. Новое отображение стриков на навбаре позволяет легко проверить статистику недельных стриков. Просто наведите курсор в правый верхний угол на иконку возле аватарки в хедере сайта и узнайте свой прогресс. Ранее вся статистика обучения была доступна только в профиле учащегося и только за последний год. Однако теперь вы можете наблюдать собственный прогресс на протяжении нескольких лет! Это открывает возможности для более детального анализа и сравнения своих достижений в разные периоды времени.

Курсы с историей

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

Вот так, например, озаглавил свои первые шаги в качестве преподавателя, Александра Куликова, автор таких курсов, как: Алгоритмические задачи с собеседований, Алгоритмы: теория и практика. Методы, и Алгоритмы: теория и практика. Структуры данных:

«Первый блин комом» — это очень мягкое описание того, что у меня в итоге получилось. Я наступил на все грабли, на которые можно было наступить.

Некоторые видосы у меня были двадцатиминутными. Чуть ли не во всех моя рожа занимала весь экран. К теоретическим задачам пришлось прикрутить peer review проверку (было понятно, что слушателей на курсе будет много и что я физически не смогу сам у всех проверить решения). И это совсем не работало: слушатели с самой разной математической подготовкой сдавали решения и проверяли их друг у друга; в комментариях было очень много недовольства.

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

Так, например, Пётр Михалевский, автор Легкого старта в Java. Вводный курс для чайников, создавал свой курс:

Штош. Как говорится, лучший способ изучить что-нибудь – объяснить это другим. Решено – я создал курс “Лёгкий старт в Java. Вводный курс для чайников”, ориентируясь на высокий стандарты, заданные Тимуром Гуевым и его «Поколением Python».

И курс выстрелил. Больше года он входил в десятку самых популярных курсов на Степике, а всего на него записалось более 40 тысяч студентов. Такого успеха я не ожидал, и был весьма горд собой. Более того, в процессе создания курса я понял, что Java мне нравится гораздо больше, чем Python.

Ну а теперь от программирования перейдём к тестированию. За последние два года количество курсов по QA на Stepik значительно возросло. Но как уверяет Давид Согоян, автор Тестирование REST API в Postman – легкий старт в автоматизацию. Его вдохновило на создание собственного курса как раз отсутствие такого обучающего материала на платформе, который полноценно и последовательно раскрывал бы про API, HTTP, REST, JSON, JSON-Schema, авторизацию и аутентификацию. Давид взялся за дело и вот каких результатов он достиг:

На момент написания рассказа у курса 49 отзывов, и все из них — на 5 звезд. Благодарю каждого за добрые слова и отзывы. Этот успех на ряду со следующим особенно ценен. В отзывах к курсу, в телеграм-группе, по почте студенты неоднократно делились своими историями успешного трудоустройства. Это — мой главный успех. Только вкусные хинкали и новость о помощи в успешном собеседовании могут заставить меня улыбнуться от уха до уха минут на 10. В этом году хинкали я не ел, но до ушей улыбался не менее полутора часов.

Как мы не раз повторяли, есть много вещей, которые вдохновляют наших авторов создавать обучение на Stepik. Это и желание поделиться своей экспертизой, и ваши отклики. И Екатерина Закусова, автор курса Активный Английский для продолжающих (А2), не исключение. Она рассказала, как вполне обычные вещи помогают преодолеть трудности на пути к преподаванию, а иногда даже привнести что-то новое в свои уроки:

Я обожаю сидеть на кухне. Можно сказать, что кухня — это мой второй дом, как бы дом внутри дома. Здесь я принимаю гостей, здесь я рыдаю, если что-то не получается, здесь я смотрю в окно, говоря знаменитое «Вот такие дела, ребята…»

Поэтому нет ничего удивительного в том, что свои авторские курсы английского языка я начала писать здесь, на кухне. Из доступного оборудования был только телефон и 2 кастрюли, поставленные друг на друга. Конструкция эта была неустойчивая и мне требовалось несколько дублей, чтобы снять видеоурок целиком. С одной стороны сижу я и объясняю на камеру Complex Object, а с другой стороны врубается холодильник «дррррр» и видео опять идёт в утиль. В том числе поэтому мои уроки построены так, чтобы дать максимум информации за 2, а то и за 1,5 минуты. В ход объяснений шло всё: чашки, ложки, даже молоток для отбивных засветился в уроке про Past Modals.

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

#онлайнкурсы #онлайнобучение #программирование #python #java #образование #алгоритмы #английский #qaengineer #sql #haskell #статистика

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

В 2023 году каталог Stepik радует разнообразием платных курсов на любой вкус. Здесь можно подтянуть школьные предметы, освоить языки программирования или обучиться иностранным языкам. Платформа предлагает как обширные обучающие программы, так и экспресс-курсы, которые можно пройти за несколько часов. Пользователи получают возможность выбирать, что подходит именно им, и за какой материал они готовы заплатить. Хотя так было не всегда.

В 2019 году Stepik впервые подошёл к идее платных курсов. На тот момент платформа уже завоевала внимание широкого круга пользователей с различными интересами и потребностями, а запрос на качественный образовательный контент стал заметно расти. Эта эволюция происходила сразу по ряду причин, включая интеграцию технологий в образование, актуальность принципа lifelong learning и стремление обеспечить равные образовательные возможности для всех. Поэтому одно из решений Stepik для поиска новой мотивации авторам заключалось в помощи создания платных онлайн-курсов. Так курсы, помимо основной своей цели — формирования необходимых знаний и умений — стали источником дополнительного дохода для тех, кто создаёт.

Если вы ещё не читали первую часть, то здесь уже был представлен обзор самых популярных бесплатных курсов. А сегодня мы отобрали для вас новый ТОП 10 из наиболее востребованных платных курсов:

\"Поколение Python\": курс для профессионалов — победитель конкурса Stepik Awards 2022 в номинации «Лучший платный курс».

СОТОЧКА ПО РУССКОМУ: помощник в подготовке к ЕГЭ 2024 — лучший помощник в подготовке к ЕГЭ по русскому языку.

АА - Активный Английский от Екатерины Зак для продолжающих (А2) — представьте, что сидите вы на кухне и говорите «Катюха, а объясни-ка мне английский!», и Екатерина Закусова объясняет доступно, просто и легко.

Как и в прошлый раз, этот чарт не может начинаться ни с какого другого курса, кроме как нашего главного бестселлера — победителя конкурса Stepik Awards 2022 в номинации «Лучший платный курс» поколения Python. А вообще, если вдруг вы пропустили, то это целая серия курсов про один из самых популярных и востребованных языков программирования!

АВТОРЫ: преподаватели онлайн-школы по математике и информатике BEEGEEK.

ПРОДОЛЖИТЕЛЬНОСТЬ КУРСА: в курсе — 75 уроков, 786 тестов и 397 интерактивных задач. Наш алгоритм подсчитывает, что всё это можно пройти за 156 часов, а сам автор предлагает выделить 10 часов в неделю для полного погружения в языковую среду. Готовьтесь, будет много математики.

КОМУ ПОДОЙДЁТ: школьникам и всем, кому интересно программирование на Python, то есть для всех желающих познакомиться с дополнительными возможностями языка. Для успешного освоения нужно пройти предыдущие курсы серии.

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

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

АВТОР: Ляйсан Хутова, профессиональный репетитор по русскому языку

ПРОДОЛЖИТЕЛЬНОСТЬ КУРСА: 303 урока, 26 часов 37 минут видео и 2 458 тестов. Самый быстрый ученик прошёл его 54 часа, но лучше закладывать ещё больше времени.

КОМУ ПОДОЙДЁТ: одиннадцатиклассникам и всем желающим сдавать ЕГЭ по русскому языку в ближайшее время. Курс адаптируется и обновляется к каждому сезону ЕГЭ.

Вы можете проходить его сколько угодно раз: можно растянуть на год, а можно на две недели. Каждый урок записан в видеоформате, но дополняется большим объёмом практических заданий. Их проверка проводится автоматически, однако если в процессе прохождения возникает вопрос, его всегда можно задать преподавателю в комментариях. Ляйсан старается оперативно отвечать, приводя дополнительные примеры.

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

АВТОР: Екатерина Закусова, профессиональный лингвист со степенью MBAE High Business School in Bodo

ПРОДОЛЖИТЕЛЬНОСТЬ КУРСА: 15 уроков, более 2 часов видео и 80 тестов.

КОМУ ПОДОЙДЁТ: взрослым, студентам и школьникам

Это идеальный выбор для тех, кто уже имеет начальный уровень английского, примерно А2, и хочет преодолеть языковой барьер. С ним вы не только углубите свои грамматические и лексические знания, но и сможете активно использовать их в разговорной практике. Так что, если вы давно хотите «левелапнуться» в английском, попробуйте курс «АА - Активный Английский от Екатерины Зак».

Вам стоит обратить внимание на этот курс, если вы планируете сменить профессию и начать свою карьеру в IT или ищете качественный материал для обучения по профессии QA Engineer.

АВТОР: Алекс Смит, опытный тестировщик крупных финансовых компаний с навыками ручного тестирования, работы с базами данных и тестированием API, а также построением собственных проектов по автоматизации UI и API.

ПРОДОЛЖИТЕЛЬНОСТЬ КУРСА: 83 урока, более 16 часов видео, 108 тестов и 9 интерактивных задач.

КОМУ ПОДОЙДЁТ: тем, кто очень хочет быстро освоить профессию тестировщика ПО (QA Engineer).

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

Курс по одной из самых популярных программ для визуализации и анализа данных — Excel. Для многих он также является отправной точкой в мир аналитики, ведь там можно собирать, преобразовывать, автоматизировать вычисления и выполнять ещё ряд других полезных и необходимых в работе задач, которым вы и научитесь с «Базовыми навыками Excel».

АВТОР: SF Education — онлайн-университет профессий и навыков в области финансов, аналитики, бизнеса и IT.

ПРОДОЛЖИТЕЛЬНОСТЬ КУРСА: 29 уроков, 5 часов видео, 18 тестов.

КОМУ ПОДОЙДЁТ: абсолютно каждому, ведь Excel нужен как студентам и новичкам, так и бухгалтерам, экономистам, маркетологам и аналитикам.

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

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

АВТОР: Татьяна Овчинникова, преподаватель IT-курсов для детей и взрослых по направлениям: «HTML и CSS», «Теория тестирование ПО» и «Компьютерные сети».

ПРОДОЛЖИТЕЛЬНОСТЬ КУРСА: 34 урока, 152 теста. Нагрузка рассчитана на ежедневное обучение не менее 1-го часа в день.

КОМУ ПОДОЙДЁТ: новичкам, которые только знакомятся с тестированием или уже что-то знают о тестировании ПО, но не понимают, как свои знания применять.

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

Этот курс является победителем премии Stepik Awards 2019 в номинации «Лучший курс». Представляет собой полный путеводитель в мир программирования, где вы познакомитесь с основополагающими концепциями. Здесь будут раскрываться все нюансы работы с типами данных, операторами, переменными и другими важными элементами кодинга на языке C#. Этот путь подходит всем, кто только начинает своё знакомство с программированием.

АВТОР: Иосиф Дзеранов, программист, основатель и преподаватель онлайн-школы BEEGEEK.

ПРОДОЛЖИТЕЛЬНОСТЬ КУРСА: 38 уроков, около 2-х часов видео, 123 теста и целых 217 интерактивных задач.

КОМУ ПОДОЙДЁТ: тем, кто хочет научиться программировать или хочет понять для себя, насколько это его, а ещё тем, кто решил сменить работу или найти интересную подработку.

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

Программа Autodesk Revit Architecture является ключом к освоению мощных возможностей BIM. А помочь разобраться и овладеть этим инструментом будущего архитектуры, сможет именно этот курс. В нём обучение начинается с основ: вы познакомитесь с интерфейсом программы, освоите создание элементов, научитесь работать с видами и разрезами, исследовать параметрический дизайн и многое другое.

АВТОРЫ: Альберт Сумин — архитектор, сертифицированный специалист Autodesk по программе Revit Architecture, Сергей Швыдко — архитектор, сотрудник Академии БИМ, Максим Степанников — архитектор, сотрудник Академии БИМ.

ПРОДОЛЖИТЕЛЬНОСТЬ КУРСА: 37 уроков, более 33-х часов видео, 96 тестов. Среднее время, затрачиваемое на прохождение курса, составляет 61 час.

КОМУ ПОДОЙДЁТ: студентам архитектурной и инженерных специальностей, практикующим специалистам в области архитектурного проектирования зданий.

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

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

АВТОР: Компания Shultais Education, основанная в 2015 году профессиональным разработчиком и преподавателем Никитой Шультайсом.

ПРОДОЛЖИТЕЛЬНОСТЬ КУРСА: 105 уроков, более 8 часов видео, 67 тестов и 308 интерактивных задач.

КОМУ ПОДОЙДЁТ: рассчитан на широкую аудиторию слушателей и не требует специализированных знаний ни в программировании, ни в базах данных. Будет полезен для начинающих разработчиков, маркетологов, аналитиков, продуктологов и экономистов.

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

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

АВТОР: Наталия Соломкина, лингвист, преподаватель и переводчик японского.

ПРОДОЛЖИТЕЛЬНОСТЬ КУРСА: 12 уроков, полчаса видео, 46 тестов и 8 интерактивных задач. Алгоритм считает, что средняя скорость прохождения курса составит 4 часа.

КОМУ ПОДОЙДЁТ: всем, кто давно мечтал выучить язык Страны восходящего солнца

Курс фокусируется на подробном объяснении о том, как работает японский язык. Благодаря ему, вы начнёте понимать хирагану, катакану и некоторые иероглифы. Главная цель программы — ознакомиться с фундаментальными аспектами японского языка, включая его структуру, чтение и письменность и соблюдении правил базовой грамматики.

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

Также не забывайте, что у Stepik есть очень удобное и комфортное для учёбы мобильное приложение. С ним вы можете учиться практически из любой точки мира! Тем более, что оно доступно сразу в 3 магазинах — Google Play, App Store и RuStore.

#stepik #программирование #онлайнкурсы #онлайнобучение #python #егэрусский #английскийязык #excel #тестирование #qaengineer #revit #sql #японскийязык

Метрики в тестировании — пустая трата времени или объективный показатель качества и скорости разработки? Когда применяются и что дают цифровому продукту? Вместе с начальником QA-отдела Fusion Tech постараемся разобраться в этих вопросах и выяснить, какие метрики и как влияют на процесс разработки.

QA-метрики — это инструменты, которые помогают в измерении качества программного продукта и в поиске проблемных мест в ходе реализации проекта.

КОГДА СТОИТ ИСПОЛЬЗОВАТЬ МЕТРИКИ?

Необходимость внедрения и применения метрик должна определяться каждой отдельной командой на конкретном проекте. Чтобы понять, нужен ли этот инструмент и какой именно, определитесь с результатом, который хочется получить в итоге. Часто в статьях на тему тестирования можно увидеть подобные фразы про метрики: “контролируют процесс QA”, “дают объективные показатели о готовности продукта”, “показывают эффективность команды и отдельного сотрудника” и так далее. Может сложиться впечатление, что метрика — это универсальная серебряная пуля от всех проблем, которая разве что не убивает вампиров и оборотней. Но так ли это на самом деле?

Задача метрики — увеличить скорость реализации проекта на всех этапах, налаживая процесс разработки и уменьшая количество и длительность исправления багов.

Представим такую ситуацию: в предыдущем месяце процент возвратов проекта (от разработчика к тестировщику и обратно) колебался в районе 3%, а в этом — увеличился до 15%. Можно подумать, что команда разработки стала работать в 5 раз хуже и пора доставать запылившийся кнут из кладовки. Но в реальной жизни может оказаться, что в предыдущем месяце были простые задачи по верстке, а в следующем — формируется компонент со сложной логикой или требования к задачам описаны не полностью. Это пример того, что конечный результат стоит рассматривать на основе анализа данных метрик, чтобы понимать, где случилась просадка и почему.

ЧЕМ МЕТРИКИ ПОМОГАЮТ ПРОЕКТУ?

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

Цели сбора метрик:

КАКИЕ ПРОБЛЕМЫ МОЖНО ЗАФИКСИРОВАТЬ С ПОМОЩЬЮ МЕТРИК?

1. Низкая пропускная способность*

* Пропускная способность — это количество задач, которое проходит через команду разработки за определенный промежуток времени от стадии требований до выхода продукта в релиз.

Допустим, разработчик способен решить 10 задач за 2 недели, тогда у команды тестирования должны быть возможности и ресурсы их обработать. Если QA недостаточно и один сотрудник может протестировать только 3 задачи из 10, то пропускная способность в релиз будет равна 3. И обратная ситуация — если QA способен протестировать 10 задач, а разработчик может закрыть только 3, то КПД (коэффициент полезного действия) останется также на отметке 3. Как в армии на марш-броске: время, за которое подразделение пробежало дистанцию, будут фиксировать по последнему солдату, то есть подразделение (как единая система) в целом будет бежать со скоростью самого медленного бойца.

В подобной ситуации метрики помогают нам зафиксировать тот факт, что у нас где-то образовалась \"пробка\" или, наоборот, есть избыточный ресурс, и по итогу прийти к системному равновесию: 10 задач мы получаем в рамках спринта (1 цикла разработки) и 10 задач поступают в конце в продакшн.

2. Большое количество возвратов задач

Возвраты проекта от тестировщика к разработчику из-за уточнения требований и найденных ошибок могут стать одной из причин недостаточной пропускной способности. Что будет, если QA вернет на предыдущий этап (создания продукта) слишком много задач с багами? Как минимум, увеличится нагрузка на отдел тестирования в дальнейшем, так как помимо новых задач придется просматривать переделанные.

Возьмем случай из нашей практики: на небольшом проекте QA-инженер перестал справляться с нагрузкой из-за большого количества задач. На проект добавили еще одного, но это облегчило ситуацию ненадолго. В скором времени проблема повторилась, снова появились “пробки”, так как уже два QA отдавали с усердием еще больше задач, которые после корректировки возвращались на тестирование. Стало ясно, что следует подумать над оптимизацией процессов, а не над расширением штата.

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

3. Слишком длинная петля возвратов

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

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

4. Отсутствие баланса между качеством и пропускной способностью

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

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

КАКИЕ БЫВАЮТ МЕТРИКИ?

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

Инструменты, которые чаще используются в нашей компании:

Помогает планировать ресурсы и предотвращать или убирать заторы на проекте.

Помогает понять, что требует наибольшего внимания при разработке.

Помогает выявить пробелы в QA и добавить дополнительные сценарии тестирования.

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

Позволяет понять, насколько стабильно работает продукт после релиза.

КОРОТКО О ГЛАВНОМ:

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

Новости из мира IT-технологий, о трендах индустрии, бизнес-сервисах и не только — в ТГ-канале или на сайте Fusion Tech.

Читайте также:

Тестирование ПО – важная составляющая любого процесса разработки, которая позволяет контролировать качество информационного продукта в процессе его создания. Чем раньше находятся и исправляются баги, тем меньше требуется денежных затрат заказчика, усилий разработчика и нервных клеток проектного менеджера. Мы во Fusion Tech советуем клиентам выбирать ручное и автоматизированное тестирование одновременно для последовательной проверки качества мобильных и веб-приложений (web UI, API, mobile UI). Такой подход быстрее и дешевле, а также позволяет глубже исследовать продукт в процессе разработки. В чем разница между этими видами тестирования, какие плюсы и минусы у каждого из них, а главное – на каких этапах реализации ПО они подключаются? Об этом и не только читайте в нашей статье.

#qa #qaengineer #тестирование #тестировщик #диджитал #digital #it #fusiontech #softwaredevelopment #testing #метрики

Про собесы на мобильного тестировщика когда нет опыта.

На старте карьеры каждый собес как событие. Чаще всего стрессовое событие. Ведь точно не знаешь что тебя ждёт и как пойдёт весь диалог с собеседующими. Опустим влияние стресса на то как себя показываешь и какой уровень знаний выдаёшь.

Ниже поделюсь тем что могут ждать от кандидата и как к этому подготовиться.

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

Хорошей стратегией будет поставить акцент на:

- Укрепление общей теории тестирования. Да-да, классическая база. Но не спроста так часто можно услышать, что у большинства кандидатов плохая подготовка. Учим SQTB, проходим мок-собесы что бы не быть ходящей википедией, а говорить что-то осмысленное, пусть и простое.

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

- Заучи чек-лист по мобильному тестированию. Если нет такого, то напиши мне.

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

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

- Помни, что сначала идёт позитивное тестирование, а потом негативное. Не перепутай.

Уверен, что материал был полезен и интересен. Подписывайся на мой телеграм
Удачи!

#qa #qaengineer #тестирование #тестировщик #мобильноетестирование