Обновить
31
0
Сергей@Jeisooo

QA

Отправить сообщение

Буквально тем же самым баловался неделю назад с помощью Qoder.

После пары-тройки итераций правок тот потерял контекст и начал сильно увеличивать объем кода. Я нашел библиотечку бесплатную, которая троит карты ликвидности, скачивая данные с бинанс. Но иногда нейронки советуют coinglass, правда карты там стоят уже 700$ в месяц за про подписку.

Добавил еще средние и анализ объемов для вычисления тренда.

Но 5минутки это не интересно, там вы потив hft

Лечше бектестить на 12h. И тренды проще ловить

Почему не использовать уже готовые liquidation maps, а не давать расчитывать нейронке дно по свечам?

Спасибо, Павел! Было очень интересно прочитать такой развернутый анализ и детали, связанные с движением средств. Я действительно не докрутил детали, по причине недоступности отчетов. И попыток поговорить с реальными консультантами я не делал. Точнее, делал, но там был стандартный кейс продажи продукта.

Очень интересно вас иногда читать и я иногда сожалею, что писать про такие вещи у меня не хватает мотивации и времени.

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

За такое обычно подсвечниками бьют:)

У меня было смешно. Моя вилка была рыночная, а на собесе мне сказали, что вилка на 40% больше. Я сказал - ок.

А потом мне написали, что отказывают мне из-за того, что я слишком много денег прошу:D

Если вы пойдете работать в корпорат, то сразу увидите и кафку, и java стэк и любой другой брокер сообщений в составе работы с корпоративной шиной данных.

Собственно, kafka explorer иногда может быть нужен. То же самое и про рэббит

Contror ≠ Managment, а лишь одна из его функций, и она реактивная, в отличие от QA.

Но меня тоже смутила некоторая попытка в статье снять ответственность с QA, путая их с QC.

Цитата: реальность: "QA-инженеры не могут напрямую сократить количество ошибок, они их не исправляют".

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

О, опубликую свой пост из linkein про тиньков. Нюанс в том что 4 этапа интервью - это еще не самое сложное. Еще надо попасть в нормальную команду с нормальным тимлидом. А они мимикрируют.

Интервью там были долгие и не самые внятные. И лайфкодинг слишком долгий, как по мне. Но!

КАК Я (НЕ)ПРОШЕЛ ИСПЫТАЛКУ

Очень хочется поделится своим трехмесячным опытом по прохождению испытательного срока в одном известном большом желтом банке из РФ.

С этим банком у меня уже были попытки наладить трудовые отношения, когда я трудился еще в сфере поддержки, но они предлагали ЗП сильно ниже рынка и в 3 раза меньше, чем я получал на тот момент. Аргументируя это тем, что у нас "Все так начинают", зажав 100$. Ну да ладно..

В этот раз я повелся на трудовой договор вне РФ и полную удаленку. Сначала были ожидаемые для крупных компаний 4 круга собесов - скрининг, тех.интервью QA, тех.интервью программирование, интервью с тим.лидом. Заняло это в общей сложности пару недель и 4 часа чистого времени на созвоны. После согласования ЗП, получения техники и доступов, началось погружение в проект.

Проект был достаточно простой архитектурно(3 БД, шина, API с ломаной сваггер схемой) и, как мне показалось, не очень правильный с точки зрения организации качества. Но 3 месяца я упорно старался вникнуть в эту организацию, послушно подстраиваясь под командные процессы.

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

Но... Оказалось, что проблемы у меня все-таки были. Хотя я и закрыл задачи на ревью, со слов тим лида, я делал задачи недостаточно быстро(хоят в KPI не было метрик по времени выполнения), были просадки по трекеру рабочего времени на рабочем ноуте(да, да, такое еще существует в ИТ).

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

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

- оплата ментору за доп.нагрузку

- оплата интервьюверу за доп.нагрузку

- пустой круг hr за привлечение

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

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

Я пришел к выводу, что позицию освободили для кого-то "своего".

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

Спасибо за статью!

Расскажите, в какой момент у вас в команде к работе подключаются тестировщики и как происходит работа с вашими юнит-тестами? Трогают ли они их, или пишут потом свои интеграционные?

Еще интересно, проверяете ли вы потом юниты на тестовых данных(с переключением environment) или так и оставляете на моках?

Бесполезная статья без практических примеров

QA фулстак стоит на 50-100% дороже аналогичной позиции не фулстак)) зачем брать на себя ответственность за качество, если я могу за 40$/h просто писать код как automation?)

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

Я вам советую не переводить дословно, а рерайтить слишком сложные куски.

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

"Нам нужно изолировать функционал и убедится, что при масшабировании ничего не сломается"

Добрый день. Про вторую часть можно подробнее?)

Перевести деньги на счет в банке можно по номеру телефона через платежную систему Золотая Корона. Это для физ.лиц

Для Юр.лиц, наверно, тоже существует процедура в обход свифта

Согласен. Кондитерам на Камчатку. Да и вообще в те регионы, куда логистика свежих фруктов дороже

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

Это перевод. Все вопросы к авторам книги.

Мне, как практикующему QA, было интересно перевести для сообщества. Статья была вычитана и одобрена к публикации коллегами.

Жаль, что вам не интересно. Но такое бывает, да.

Методы API являются интерфейсами различных программных классов, которые взаимодействуют с бизнес-сущностями. Разработчики могут спокойно покрывать их юнит-тестами.

UI-тесты можно упоминать как часть e2e тестирования.

А вообще, в книге они описаны, чтобы ввести читателя в контекст всего процесса разработки

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

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

1
23 ...

Информация

В рейтинге
Не участвует
Откуда
Белгород, Белгородская обл., Россия
Работает в
Дата рождения
Зарегистрирован
Активность

Специализация

Инженер по автоматизации тестирования, Инженер по обеспечению качества
Старший
Git
SQL
Базы данных
ООП
Web
Enterprise
MySQL
Java
Python
REST