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

в итоге из тестировщика в лиды и теперь в менеджеры проекта пролетела)

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

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

ну так это же не совсем QA работа ;)

общий опыт по лидерству (не люблю слово руководство) - около 3 лет

ну зависит от компании)

Как раз таки QA :)

коммуникация и релиз-менеджмент?

ну и подняла качество продукта) крашфрии и тому подобное

ну часто где тестировщики решают что идет в релиз и когда этот релиз будет)

Построение процессов разработки - QA

Построение процессов разработки - QA

Вот под этим тезисом сейчас разразится холивар

ну естественно построение процессов в qa и меры по улучшению качества за апределами отдела тестирования

А QC?

не процессов в целом

QC как основная деятельность отдела естестенно)

и как тестировщик тоже работаю) на критичных релизах и платформах)

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

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

опыт не возьмется ни откуда)

Вот под этим тезисом сейчас разразится холивар

Ну ты почитай интернеты) и холиварить не будешь)

Dmitry спасибо за комментарий, читал ;)

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

плюс защита команды от внешнего воздействия так сказать)

все это можно назвать - лидом? )

От QA ждут знаний о процессах, о том как внедрить тестирование в существующий цикл

Какие использовать инструменты итд

ну и часто ждут, чтобы мы все автоматизировали)))

+

От QA ждут знаний о процессах, о том как внедрить тестирование в существующий цикл

+ :)

ну и часто ждут, чтобы мы все автоматизировали)))

Это не всегда оправдано, как бы не хотели

это правда) потом переубеждаешь и продолжаешь строить процессы так, чтобы и компании на пользу и команде не в убыток)

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

+

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

Это да

и анализ требований не проведёшь

особенно, если требования косвенные все)

:)

и документации нет)

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

а вообще есть люди, кому университет помог? ) и не пришлось копать самому?

графы выражающиеся в майндмэпах, вот это всё - математика по сути

Мне помогло.

а вообще есть люди, кому университет помог? ) и не пришлось копать самому?

Мне, хотя ещё учусь

ооо теорию графов учила вообще с мужем) у нас даже не было этой дисциплины)

а вообще есть люди, кому университет помог? ) и не пришлось копать самому?

конечно есть! Я научился готовиться за 2-3 дня ко всему что только можно )

конечно есть! Я научился готовиться за 2-3 дня ко всему что только можно )

++++

ооо! ну это точно) забыла про такой важный навык)

в целом же - математика, всякие там основы, комбинаторика, графы, общее представление о разных областях.

конечно есть! Я научился готовиться за 2-3 дня ко всему что только можно )

+1, кстати)) Ещё универ помог научиться быстро искать необходимую информацию и фильтровать "воду" в текстах

в целом же - математика, всякие там основы, комбинаторика, графы, общее представление о разных областях.

+

Хотя в нашем универе дают сильную мат.базу с углублённым матаном и этим вот всем. Плюс программерские предметы помогают в работе.

а чем именно вам помогли эти знания? Где использовали? Можно подробный ответ?

Уменее найти подход к задаче, для которой не знаешь решения.

Я думаю, что никто не будет спорить, что понимаение, как работает продукт, делает тестирование более эффективным? Так вот, когда ты знаешь такие вещи, как "стек экранов может привести к крэшу из-за недостатка памяти", на iOS 8 слабые места - переходы между экранами и все в таком духе, очень помогают протестировать продукт более качественно, чем без этих знаний

Это лишь несколько примеров

Я думаю, что никто не будет спорить, что понимаение, как работает продукт, делает тестирование более эффективным? Так вот, когда ты знаешь такие вещи, как "стек экранов может привести к крэшу из-за недостатка памяти", на iOS 8 слабые места - переходы между экранами и все в таком духе, очень помогают протестировать продукт более качественно, чем без этих знаний

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

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

Абсолютно согласна

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

угу

Я на эту тему тоже готовлю доклад

Очень хочу высказаться по этому поводу :)

Как говориться, есть нюанс...

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

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

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

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

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

ERROR: S client not available

не может в скрипт/батник/повершелл/баш - начерта тогда такой тестировщик?

Я думаю, что никто не будет спорить, что понимаение, как работает продукт, делает тестирование более эффективным? Так вот, когда ты знаешь такие вещи, как "стек экранов может привести к крэшу из-за недостатка памяти", на iOS 8 слабые места - переходы между экранами и все в таком духе, очень помогают протестировать продукт более качественно, чем без этих знаний

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

я не увидел выше определение QA-Lead-а

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

Я говорила про программерские предметы

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

внутренности любого програмного обеспечения - чистейшая математика

Меня попросили, я ответила

расскажите, кто что подразумевает под этой позицией?

внутренности любого програмного обеспечения - чистейшая математика

И это верно

расскажите, кто что подразумевает под этой позицией?

это чувак, к которому придут с вопросом "а кто может быстренько затестить мой чекин в девфорке?" или "а хуле вы 3 бага на прод провтыкали?"

пока расплывчато

давайте как-то формально опишем компетенции и зоны ответственности

расскажите, кто что подразумевает под этой позицией?

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

Тоже интересно послушать, кто что скажет

а ты либо "йоу, у меня все заняты суперкритичными тасками, но я вижу, что через 4,5 часа будет окно и вот этот вася сможет" либо "ой, да ладно, зырьте, мы вам 23 письма написали, в таске отчитались, вы резалты аппрувнули, команда не при делах, мы красавы, девы лохи, мгмт гогно" )))

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

внутренности любого програмного обеспечения - чистейшая математика

Веб сервис на рельсах. Црм система. Где мне там математика чистейшая понадобится, не считая формул подсчета kpi?

поэтому предлагаю накидать в кучу по пунктам, а из этой кучи уже сформулировать хоть что-то

Давайте без мата всё же.

а ты либо "йоу, у меня все заняты суперкритичными тасками, но я вижу, что через 4,5 часа будет окно и вот этот вася сможет" либо "ой, да ладно, зырьте, мы вам 23 письма написали, в таске отчитались, вы резалты аппрувнули, команда не при делах, мы красавы, девы лохи, мгмт гогно" )))

выглядит как описание тест-менеджера? (хотя определение и этой роли - тоже отдельный вопрос)

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

Знание веб технологий - нужно. Знание ux/ui нужно. Знание проекта в целом нужно. Где там математика?

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

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

А при чем тут скриптование? Я писал про то что человеку надо выключить голову и сделать дело, если он не выключит ее, то все станет гораздо труднее и больше..

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

+

А при чем тут скриптование? Я писал про то что человеку надо выключить голову и сделать дело, если он не выключит ее, то все станет гораздо труднее и больше..

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

Комп не заменит человека

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

лучше всегда быть сложнее, тогда от тебя отвалятся те, кто попроще

Он не выскажет впечатления

Комп не заменит человека

легко и без напрягов

Он не поделиться

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

А перед этим к этому надо придти, выключив голову.