Комментарии 21
интересно, какой опыт был до перехода в it или это первая работа?
эта информация, как мне кажется, может помочь людям оценить свои силы перед марафоном в смене/освоении профессии)
Татьяна, поздравляю с выходом статьи, была очень рада работать с тобой. Мне кажется ты собрала фактически готовую инструкцию как попасть в Альфу и не только!
@tatyanagendinaКак бы мне помогла ваша статья в своё время. Замечательное полное руководство рабочей минимальной базы для трудоустройства. Думаю у новичков после прочтения будет четкий чек-лист в голове, что сделать и изучить, чтобы пытаться устроиться на работу QA, ещё и сразу со всеми ссылками и примерами!)
Отличная статья, все изложено понятным языком и распределено по тема. Вопрос по Postman,- многие отказываются сейчас от этого инструмента в силу "утраты доверия" к разработчику, видите ли для себя альтернативы, кроме терминала?
А что с ним случилось?
Да по сути с самим Postman ничего, только теперь на него многие смотрят как на ПО из не дружественных стран и опасаются что он может быть использован для слива данных. Некоторые финансовые организации и не только отказываются от него из-за этого, действуют по аналогии с тем как вводят запрет использовать iPhone внутри своих зданий.
спасибо большое за отзыв о статье.
Пока не слышала про отказ от Postman среди коллег и знакомых.
Можно побольше подробностей. Интересно)
Привет, крутая статья!!! (скинул брату) =)
Нам рекомендуют уйти с постмана из-за того, что запросы через из сервера чтоль идут.
Я выбрал Bruno - приятный интерфейс, можно импортировать коллекции постмана 1 кнопкой =)
@eusatenkoспасибо )
*ушла смотреть на Bruno и его возможности
Дополню немного по поводу переезда с Postman на Bruno из собственного опыта. Тесты с использованием pm не конвертируются, поэтому может потребоваться их переписать. Если надо валидировать схемы JSON, то будет сложнее, если нет, то код может не потребоваться писать вообще, есть простые ассёрты на проверки респонса, что удобно. И нет мока (что из моего опыта не так часто используют) и перехватчика запросов (который в постмане тоже относительно недавно). И нет возможности редактирования переменных, может потребоваться их читать-писать скриптом, но работа в этом направлении идет.
А так подтверждаю, Bruno очень неплохая, при этом легковесная замена, которая во многом лучше, и постепенно развивается.
раньше задачи в спринт брались только с названием, без описания
Меня зачастую очень удивляют "оригинальные" решения менеджмента в крупняке, но с этого я просто в шоке. Это, конечно, здорово, что спецификация требований готовности и качества всё-таки появилась, но подобное сильно ставит под сомнение компетентность менеджмента. Подобное не то что в scrum, в любой модели жизненного цикла ПО прописано как обязательный пункт. У меня, конечно, попроще, lean подход с каскадной разработкой оставляет пространство для манёвра, но у вас было совсем печально. Это только создавало дополнительную нагрузку на тестирование и доработку.
Думаю, что какое-то описание задач всё же было, просто не было описано в тасках, которые двигались по борде. Опять таки это же инструмент, если менеджер итак знает по заголовком тасок чем занимаются ребята, то какие вообще проблемы)
Привет, как правило не было (работал с автором в соседней команде).
Да, менеджер +- знает что в задаче, разработчик знает что делает.
НО потом задачу передают в тестирование и начинается квест "что конкретно сделали?". Идёшь дёргать разраба, потом дёргать аналитика (а то ли разраб вообще должен был сделать в рамках задачи" и т.д.
После того, как добились внятного описания задач - время на разработку+тестирование снизилось в разы, так как уменьшилось время на выяснение нюансов + возврат задач на доработку/переделку.
Плюсом ещё сильно помогает ускорить тестирование, когда разработчик в 1-2 предложение пишет что конкретно сделал в комментарии под задачей (сердечко таким)
П.с. разговор не про задачи типа "Перекрасить кнопку из синего в красный" или "Добавить поле в запрос такой-то"
Если в банк набежит много стажеров, буду знать кто виноват в этом)
Пробежался по диагонали и этого было достаточно, чтобы добавить в закладки)
Как будто это не только гайд для новичка, сколько даже для сеньора, а что ему не забыть из того, что вообще бывает из простых вещей. Разумеется, не отвечает на вопрос наличия опыта в решении проблем, но вот чисто шпаргалку вытащить вовремя поможет)
Спасибо за статью. Отдельное за ваше разделение QC и QA. Однако, в статье увидел, кто такой Fullstack QC, а вот про QA вы так ничего, кажется, и не сказали. Хотя называете себя Fullstack QA. Или я неправильно понял?
Спасибо за отвзыв и за вопрос.
Вероятно, мне не удалось глубоко раскрыть вопрос. Это было бы темой другой статьи. По сути, понимание роли QA как влияние на процессы разработки. Не тестирование в его прямом смысле. Но такая возможность в рабочих задачах у нас есть.
QA — обеспечение качества, это влияние на процессы разработки. Ничего не тестировал, а багов стало меньше. А без «официальщины» это значит, что насколько я могу, и насколько хватает моей текущей компетенции, подсвечиваю слабые стороны в существующих процессах лицам, принимающим решения. Пример: раньше задачи в спринт брались только с названием, без описания, сейчас мы заводим таски с конкретными DoR и DoD.
Евгений, сначала хотела порекомендовать вам статью
https://habr.com/ru/amp/publications/826152/
заметила, что вы в авторах:)
Отличная статья! в части понимания роли QA ориентировалась в том числе на неё.
Спасибо за большое количество ссылок на документацию и статьи!
Никогда не любил углубляться в голую теорию, но перечитывать базовые вещи нахожу крайне полезным, т.к. с каждым городом восприятие меняется, а мыслей становится больше)
Спасибо за большое количество ссылок на документацию и статьи!
Никогда не любил углубляться в голую теорию, но перечитывать базовые вещи нахожу крайне полезным, т.к. с каждым городом восприятие меняется, а мыслей становится больше)
Быстрый старт в QA Fullstack: чем вооружиться будущему стажеру в Альфа-Банке