Довольно сомнительная вещь, основываться на чужом опыте в разрезе вопроса «какую пользу я действительно приношу компании», не замечаете? :)
Нельзя говорить, что опыта достаточно, если он не релевантен обсуждаемой проблеме. Wolonter говорил о 3 годах как о переломной точке, следовательно все выводы, сделанные до нее, могут поменяться.
Да и вообще, речь не столько о времени с последней записи в трудовой книжке, сколько о глубине погружения в проблему. Можно искупаться в большинстве ближайших озер, но это не откроет вам тайн океана.
«но у нас они просто не работают»
Скажу по секрету, но эти подходы в западных компаниях работают примерно с такой же долей успеха :)
Одна из самых важных вещей, которую опускают авторы книг «как сделать хорошо и правильно», что это требует значительных усилий для внедрения и адаптации.
И поэтому нет проблемы менталитета, в данном понимании. Есть проблема переизбытка различных «но», которые не дают взять и начать делать.
Пару раз в комментариях у вас проскакивал вопрос, что делать начинающему QA-lead'у.
Берете самую большую проблему и начинаете ее решать. Хочется теории? Берете книжки по управлению командой и те же пресловутые книжки по тестированию. И методично начинаете набивать шишки.
И я бы посоветовал больше не искать доклады и выступления «сегодня мне сказали, что я QA Lead, что дальше?». В них вы найдете какие методики сработали, но вряд ли найдете ответы о самом процессе поиска.
В ожидании серебряной пули вы упустите шанс действовать.
Ну и повысить средний уровень в отрасли можно не только подтягивая джуниоров, но и самому становясь лучше. Работать над собой гораздо эффективнее нежели бороться с призрачным легионом «свитчеров».
От того, что мир требует какой-то навык от новичков, новички не начнут «рождаться» с ним :) Да и речь идет не о владении конкретным прикладным инструментом или технологией, а о нанесении пользы — штуке значительно более сложной и неоднозначной.
И не переходя на личности, но возможно стоит приобрести опыт работы долгосрочной работы в одной компании, сравнить с краткосрочными проектами и провести ретроспективу. Просто это сильно похоже на ту ситуацию, когда единственным доказательством может стать лишь свой собственный опыт.
А можно хотя бы пару слов непосредственно об опыте использования на проекте? Кто пишет фичи, сложность сценариев (среднее кол-во шагов), частота изменений в продукте и как сильно они затрагивают тесты? Ну и «среднюю температуру» — сколько тестов, как долго используете?
Мне кажется вы путаете причину (найденные слишком поздно баги) и следствие (избыточная коммуникация). И, похоже, подразумеваете под «избыточной коммуникацией» нечто большее. Обсуждение погоды во время исследования бага — вот избыточное общение.
Еще стоило бы разнести проблему из статьи и приведенный пример. В статье говорится об ошибках, которые не были найдены вовремя (при первом проходе) — они вредят в основном тем, что разработчику приходится возвращаться к решенной, и скорее всего уже забытой, задаче, что требует дополнительных затрат на смену контекста.
Пример же из комментария отлично демонстрирует проблему локализации дефекта.
Но как мне показалось, и в том и другом случае, «избыточной коммуникацией» вы называете работу, которую пришлось сделать сверх того, чего хватило бы в случае «идеального» тестирования.
Так что не думаю, что исправление ошибок явным образом (само по себе) ухудшает качество продукта :)
Неплохо бы использовать вместо «катушки» адекватный перевод, а не то что нарисовано на картинке — дабы не терять смысл термина =]
И думаю стоит на всякий случай упомянуть, что зачастую при проблемах авторизации помогает установка у HTTP Cookie Manager параметра Cookie Policy в значение netscape.
Знаете, прошел год и на дипломную работу начинаю смотреть несколько по другому — «халтурщина» как отсутствие конкретных эпохальных результатов вытесняется осознанием процесса поиска. Надеюсь скоро исправить ошибки в магистерском дипломе(продолжаю работу) и получить больше результатов которые можно «пощупать» в итоге.
Да и кстати то что я считал постыдным «написанием реферата вместо диплома» стало некоторым подспорьем на работе =)
А вот и не передергиваем-с:
Под «хорошей и адекватной» компанией имелось ввиду наверно нечто поскромнее «не одной сотни сотрудников».
Найти _хороших, интересных и умеющих рассказывать_ докладчиков. А заодно скоординировать их.
И забыли утрировать такие аспекты как организационные заморочки, долгосрочная перспектива поддержки конференции — которые надо уложить в бюджет. И из этого получить выгоду в качестве конкретного и реального сотрудника. Несостыковочка?
«Рабочее место разработчика» и «ажиотаж вокруг рабочих мест» — абсолютно разный смысл имеют тут ключевые слова.
Это не отговорками называется, а конкретными факторами, которые влияют на выбор между единоразовой компенсацией и проведением «ивентов» в пользу первых.
Видать вам повезло и переход был осуществлен малой кровью?=)
Я не отрицаю выгоды, да и сам наслаждаюсь ей(=) ), но все же лучше заниматься автоматизацией процессов не одному тестировщику. Да и дело это трудозатратное, чтоб советы по его реализацию вносить в «правила тестировщика».
Непосредственно к тестированию относятся лишь последние три пункта, если уж быть совсем честным =)
Это скорей всего статья на тему «выживание тестировщика» +)
Я сам по этому пути прошел и даже подзавяз чуть дальше. А знаете во что это может вылиться и к чему надо быть готовым?
Первое, это то, что вскоре на вас могут свесить администрирование инфраструктуры. Дак что же тут сложно, можете ответить, я ведь её то и создал, тащил скрипты на своем горбу! А то, что сетевые конфликты, переполнение буфера пакетов, детали виртуализации и прочее требует большего, нежели вечер проведенный с поисковиками.
Отсюда и вторая опасность — времени собственно на самое тестирование будет становиться все меньше и меньше.
Ну и до кучи третий фактор, несколько раздражающий — это переключение между обязанностями. Более того, вас будут дергать для поднятия стенда именно в тот момент, когда вы будете в глубоком трансе написания теста, который должен находить все ошибки в системе +)
Но собственно какой в написанном выше смысл? Подобная инициатива очень похвальна и указывает на достаточную зрелость, но неплохо бы это координировать с начальством, потому что описанное автором немного большее нежели автоматизация собственного труда. Какие будут плюсы? Плоды автоматизации смогут пожинать все сотрудники, оставшееся после вас наследие не будет балластом для потомков, широкая общественность отдела будет знать своего героя +)
Ладно, допустим уложимся в бюджет, найдем докладчиков и организаторов.
Но как это явным образом повлияет на найм? Если компания хорошая и адекватная, то особо не повлияет на имидж — в том плане, что чем лучше компания, тем сложнее пропиарить сверх того, что имеется.
Компанию надо будет явно пиарить. Не рекламой и описанием плюшек в лоб, а докладами сотрудников скорей всего? Как организовать ход ивента, чтоб человек пришел работать в компанию, которая славится проводимыми событиями?=) Да, это повлияет на ажиотаж вокруг рабочих мест — но слишком уж косвенным образом… возможно.
Наверно организация подобных мероприятий слишком серьезный и неоднозначный(да и не профильный так сказать) подход для получения единоразовой выгоды — найма сотрудника. Проблема удержания — это уже немного другое.
Круто, итого на гостиницы для докладчиков уйдут все деньги. Мне одному кажется или этого маловато?
И что-то мне подсказывает, что некоторым готовым докладываться за гостиницу еще и билет оплатить придется? И уж абсолютно никаких проблем не возникнет с координированием расписания отличных(не бездельники наверно уж?) докладчиков, да? =)
Мне просто приходилось общаться с этими лентяями организаторами, которые не могут на $1500 организовать хорошую конференцию — все чуточку посложнее чем кажется +)
Конференция на 100 человек за $1500? Да еще и хорошая? Наверно вы знаете места без арендной платы и кучу хороших докладчиков работающих за еду. Ну и вообще вся организация на сплошном альтруизме должна бытьв идать. По-настоящему хорошая конференция выльется в значительно большие деньги если учитывать её организацию.
Тем более одна конференция не сделает погоды, это долгосрочное вложение, требущее не только денег, но и толковых людей, которые будут её «тащить».
$1500 — это в худшем случае месячая зарплата адекватного работника. Работника который потенциально останется надолго, ведь сумму выплачивают после испытательного срока.
А дельный сотрудник, увы, это проблема сегодняшнего дня, а не возможный профит в долгосрочной перспективе от затраного и ирскованного мероприятия.
Нельзя говорить, что опыта достаточно, если он не релевантен обсуждаемой проблеме. Wolonter говорил о 3 годах как о переломной точке, следовательно все выводы, сделанные до нее, могут поменяться.
Да и вообще, речь не столько о времени с последней записи в трудовой книжке, сколько о глубине погружения в проблему. Можно искупаться в большинстве ближайших озер, но это не откроет вам тайн океана.
Скажу по секрету, но эти подходы в западных компаниях работают примерно с такой же долей успеха :)
Одна из самых важных вещей, которую опускают авторы книг «как сделать хорошо и правильно», что это требует значительных усилий для внедрения и адаптации.
И поэтому нет проблемы менталитета, в данном понимании. Есть проблема переизбытка различных «но», которые не дают взять и начать делать.
Пару раз в комментариях у вас проскакивал вопрос, что делать начинающему QA-lead'у.
Берете самую большую проблему и начинаете ее решать. Хочется теории? Берете книжки по управлению командой и те же пресловутые книжки по тестированию. И методично начинаете набивать шишки.
И я бы посоветовал больше не искать доклады и выступления «сегодня мне сказали, что я QA Lead, что дальше?». В них вы найдете какие методики сработали, но вряд ли найдете ответы о самом процессе поиска.
В ожидании серебряной пули вы упустите шанс действовать.
Ну и повысить средний уровень в отрасли можно не только подтягивая джуниоров, но и самому становясь лучше. Работать над собой гораздо эффективнее нежели бороться с призрачным легионом «свитчеров».
И не переходя на личности, но возможно стоит приобрести опыт работы долгосрочной работы в одной компании, сравнить с краткосрочными проектами и провести ретроспективу. Просто это сильно похоже на ту ситуацию, когда единственным доказательством может стать лишь свой собственный опыт.
Еще стоило бы разнести проблему из статьи и приведенный пример. В статье говорится об ошибках, которые не были найдены вовремя (при первом проходе) — они вредят в основном тем, что разработчику приходится возвращаться к решенной, и скорее всего уже забытой, задаче, что требует дополнительных затрат на смену контекста.
Пример же из комментария отлично демонстрирует проблему локализации дефекта.
Но как мне показалось, и в том и другом случае, «избыточной коммуникацией» вы называете работу, которую пришлось сделать сверх того, чего хватило бы в случае «идеального» тестирования.
Так что не думаю, что исправление ошибок явным образом (само по себе) ухудшает качество продукта :)
В любом случае хотелось бы увидеть главу про load balancer.
И думаю стоит на всякий случай упомянуть, что зачастую при проблемах авторизации помогает установка у HTTP Cookie Manager параметра Cookie Policy в значение netscape.
Да и кстати то что я считал постыдным «написанием реферата вместо диплома» стало некоторым подспорьем на работе =)
Под «хорошей и адекватной» компанией имелось ввиду наверно нечто поскромнее «не одной сотни сотрудников».
Найти _хороших, интересных и умеющих рассказывать_ докладчиков. А заодно скоординировать их.
И забыли утрировать такие аспекты как организационные заморочки, долгосрочная перспектива поддержки конференции — которые надо уложить в бюджет. И из этого получить выгоду в качестве конкретного и реального сотрудника. Несостыковочка?
«Рабочее место разработчика» и «ажиотаж вокруг рабочих мест» — абсолютно разный смысл имеют тут ключевые слова.
Это не отговорками называется, а конкретными факторами, которые влияют на выбор между единоразовой компенсацией и проведением «ивентов» в пользу первых.
Я не отрицаю выгоды, да и сам наслаждаюсь ей(=) ), но все же лучше заниматься автоматизацией процессов не одному тестировщику. Да и дело это трудозатратное, чтоб советы по его реализацию вносить в «правила тестировщика».
Это скорей всего статья на тему «выживание тестировщика» +)
Я сам по этому пути прошел и даже подзавяз чуть дальше. А знаете во что это может вылиться и к чему надо быть готовым?
Первое, это то, что вскоре на вас могут свесить администрирование инфраструктуры. Дак что же тут сложно, можете ответить, я ведь её то и создал, тащил скрипты на своем горбу! А то, что сетевые конфликты, переполнение буфера пакетов, детали виртуализации и прочее требует большего, нежели вечер проведенный с поисковиками.
Отсюда и вторая опасность — времени собственно на самое тестирование будет становиться все меньше и меньше.
Ну и до кучи третий фактор, несколько раздражающий — это переключение между обязанностями. Более того, вас будут дергать для поднятия стенда именно в тот момент, когда вы будете в глубоком трансе написания теста, который должен находить все ошибки в системе +)
Но собственно какой в написанном выше смысл? Подобная инициатива очень похвальна и указывает на достаточную зрелость, но неплохо бы это координировать с начальством, потому что описанное автором немного большее нежели автоматизация собственного труда. Какие будут плюсы? Плоды автоматизации смогут пожинать все сотрудники, оставшееся после вас наследие не будет балластом для потомков, широкая общественность отдела будет знать своего героя +)
Но как это явным образом повлияет на найм? Если компания хорошая и адекватная, то особо не повлияет на имидж — в том плане, что чем лучше компания, тем сложнее пропиарить сверх того, что имеется.
Компанию надо будет явно пиарить. Не рекламой и описанием плюшек в лоб, а докладами сотрудников скорей всего? Как организовать ход ивента, чтоб человек пришел работать в компанию, которая славится проводимыми событиями?=) Да, это повлияет на ажиотаж вокруг рабочих мест — но слишком уж косвенным образом… возможно.
Наверно организация подобных мероприятий слишком серьезный и неоднозначный(да и не профильный так сказать) подход для получения единоразовой выгоды — найма сотрудника. Проблема удержания — это уже немного другое.
И что-то мне подсказывает, что некоторым готовым докладываться за гостиницу еще и билет оплатить придется? И уж абсолютно никаких проблем не возникнет с координированием расписания отличных(не бездельники наверно уж?) докладчиков, да? =)
Мне просто приходилось общаться с этими лентяями организаторами, которые не могут на $1500 организовать хорошую конференцию — все чуточку посложнее чем кажется +)
Тем более одна конференция не сделает погоды, это долгосрочное вложение, требущее не только денег, но и толковых людей, которые будут её «тащить».
$1500 — это в худшем случае месячая зарплата адекватного работника. Работника который потенциально останется надолго, ведь сумму выплачивают после испытательного срока.
А дельный сотрудник, увы, это проблема сегодняшнего дня, а не возможный профит в долгосрочной перспективе от затраного и ирскованного мероприятия.