Сергей @Jeisooo
QA
Информация
- В рейтинге
- Не участвует
- Откуда
- Белгород, Белгородская обл., Россия
- Работает в
- Дата рождения
- Зарегистрирован
- Активность
Специализация
Test Automation Engineer, Quality Assurance Engineer
Senior
Git
SQL
Database
OOP
Web
Enterprise
MySQL
Java
Python
REST
У меня было смешно. Моя вилка была рыночная, а на собесе мне сказали, что вилка на 40% больше. Я сказал - ок.
А потом мне написали, что отказывают мне из-за того, что я слишком много денег прошу:D
Если вы пойдете работать в корпорат, то сразу увидите и кафку, и java стэк и любой другой брокер сообщений в составе работы с корпоративной шиной данных.
Собственно, kafka explorer иногда может быть нужен. То же самое и про рэббит
Contror ≠ Managment, а лишь одна из его функций, и она реактивная, в отличие от QA.
Но меня тоже смутила некоторая попытка в статье снять ответственность с QA, путая их с QC.
Цитата: реальность: "QA-инженеры не могут напрямую сократить количество ошибок, они их не исправляют".
QA как раз определяют риски, подсвечивают их и имеют влияние на релиз и на команду, запрещая выпускать дефектованый продукт. QC же борется с последствиями, подсчитывая количество дефектов и жалоб от пользователя.
О, опубликую свой пост из linkein про тиньков. Нюанс в том что 4 этапа интервью - это еще не самое сложное. Еще надо попасть в нормальную команду с нормальным тимлидом. А они мимикрируют.
Интервью там были долгие и не самые внятные. И лайфкодинг слишком долгий, как по мне. Но!
Спасибо за статью!
Расскажите, в какой момент у вас в команде к работе подключаются тестировщики и как происходит работа с вашими юнит-тестами? Трогают ли они их, или пишут потом свои интеграционные?
Еще интересно, проверяете ли вы потом юниты на тестовых данных(с переключением environment) или так и оставляете на моках?
Бесполезная статья без практических примеров
QA фулстак стоит на 50-100% дороже аналогичной позиции не фулстак)) зачем брать на себя ответственность за качество, если я могу за 40$/h просто писать код как automation?)
Кроме того, чтобы корректно перевести текст и не потеряться в проф.терминах, переводчик должен еще уметь в синтаксис. Иначе читать это все становится невозможно. Особенно в таком объеме.
Я вам советую не переводить дословно, а рерайтить слишком сложные куски.
"Нам нужно изолировать функционал и убедится, что при масшабировании ничего не сломается"
Добрый день. Про вторую часть можно подробнее?)
Перевести деньги на счет в банке можно по номеру телефона через платежную систему Золотая Корона. Это для физ.лиц
Для Юр.лиц, наверно, тоже существует процедура в обход свифта
Согласен. Кондитерам на Камчатку. Да и вообще в те регионы, куда логистика свежих фруктов дороже
Аренда участка под сельхоз направление в любом аграрном регионе даст намного больший объем клубники и прибыль при меньших затратах. Думаю, хобби в таком виде трудно будет масштабировать.
Я часто проезжаю мимо нескольких гектар теплиц с огурцами, и понимаю, что микробизнес в аграрном секторе это утопия.
Это перевод. Все вопросы к авторам книги.
Мне, как практикующему QA, было интересно перевести для сообщества. Статья была вычитана и одобрена к публикации коллегами.
Жаль, что вам не интересно. Но такое бывает, да.
Методы API являются интерфейсами различных программных классов, которые взаимодействуют с бизнес-сущностями. Разработчики могут спокойно покрывать их юнит-тестами.
UI-тесты можно упоминать как часть e2e тестирования.
А вообще, в книге они описаны, чтобы ввести читателя в контекст всего процесса разработки
Это, как обычно, про сферического коня в вакууме. В реальной жизни надо стремиться и обращать внимания на эти замечания, но скорее всего, полностью соответствовать не удастся.
В маленьких командах не получится соблюдать одни принципы, в крупных другие. В стартапах одни, в корпорате другие. Ну вы поняли.
Есть несколько вариантов:
Если словарный запас есть и разговорный блок снят, то есть preply, на котором можно найти учителя
Можно найти учителя из местных и маленькую группу айтишников, которая работает в этом направлении. У нас такая есть, если хотите присоедениться - напишите в личку. Уровень intermediate
Можно взять того же учителя и заниматься парой с кем-то, задавая друг другу вопросы.
Мое самое проблемное место - боязнь собеса на английском. Именно для международной компании
Усиленно психологически настраиваю себя на этот этап. Все остальные страхи уже развеяны и не страшны.
Собрать процесс выпуска карточки клиента кредитного продукта из 5 шагов
или
Собрать процесс скоринга из 50-ти тасков с несколькими интеграциями.
Понятно, что во втором случае придется тестить отдельно, мокировать сервисы. И метрики качества работы будут разные, потому как цена ошибки разная.
Для бизнеса будет важен сроки и бюджет.
Для пм - сроки тасок и бюджет в человеко\часах
Для лида кол-во дефектов на проде, которые влияют на процесс и бюджет
"За что ты конкретно отвечаешь при «вычленял методы из бизнес процесса и приоритизировал задачи»?"
Конекретно за качество выпущенного в итоге процеса. А не за качество отдельной таски. Что и было указанно у автора п.6.
Тестировщик еще не умеет в бизнес. QA уже должен вникать.
"Как QA влияет на именно процесс при TDD?" - Формирует общую политику тестирования, совместно с тимлидом. Симбиозом позиции будет SDET, который занимаются этим же на более высоком уровне.
"Приоритизация как раз и двигает сроки доставки полезности, как она может именно помочь ужаться, или там идет как раз-таки понижение требований" - Зависит от сложности процесс. Иногда есть возможность это сделать, иногда нет. Я не утвержаю, что надо всегда строить в тесте весь процесс. Но QA может указать на наличие возможности.
Если есть разница с какой позиции отвечать, то со всех позиций, пожалуйста. - Пожалуй, откажусь. Лень доказывать.
Изначально мой комментарий был на реплику "Задача QA — она на другом конце конвеера — после разрабов".
И вот это:
" Внезапно, открытая аргументированная дискуссия между реальными участниками процесса, которые будут выполнять работу, а не только контролировать качество — выявит больше нюансов как «до», так и «во время» разработки."
А QA не участник процесса что ли? Как будто на твоем проекте были не QA, а кто-то похожий на QA или просто тестировщик. Который никак и не должен влиять ни на процесс. И не должен иметь никаких компетенций по отношению к процессу разработки. А если на проекте TDD подход, QA тоже не влияет на процесс?
По срокам и приоритетам скорее PM, а не тимлид. Причем в разных проектах по разному. Твой опыт, скорее, относится к чему-то типа Scrum-команд, у меня больше опыт в корпоративных Waterfall + scrum. В них смещена ответственность на Senior-ов, и тимлид, конечно, отвечает тоже. Но за более масштабные этапы проекта.
"Как я, к примеру, смогу оценить качество работы такого специалиста по качеству" - С позиции кого отвечать на этот вопрос? PM? Тимлида? Бизнеса? Есть метрики, в чем проблема? Если приоритизация помогла доставить полезность в срок и уменьшила время на поиск тестовых данных, там сразу видно.