из-за отсутствия стоп-крана, дернув за который можно отключить себя от технологий, когда они не нужны
Это мне кажется интересный момент. С одной стороны глобализация подстегивает распространение технологий. Чем дальше, тем быстрее и прочнее новинки входят в нашу жизнь, особенно у людей, близких в IT. С другой, в короткой перспективе, если отказываться от этих технологий, то, как пишет автор статьи, могут отправить в лес жить. Потому что вот прям сейчас нет смысла бояться мобильные телефоны или VR очки, а в будущем тех же голосовых помощников продвинутых. И наоборот, не следование за какими-то технологиями может порождать проблемы при попытке жить в мире, где эти технологии на каждом шагу применяются. И получается в каком-то смысле как в той истории, где лягушку варят постепенно. Заметим ли мы, что прошли точку невозврата? Что, если мы уже перешли (о чем и говорит местами автор)?
Любопытно.
Я бы только добавил к тому, что автор пишет про «мы не привыкли думать про то, что будет через 60 лет». Мы в целом привыкли оптимистично думать «если и будет плохое, то не при мне». Но сказать уверенно, возможно ли что-то такое в мое время жизни или нет, у меня нет компетенций. Зато подспудная уверенность есть. Из разряда «меня никогда не собьет машина», несмотря на то, что в моем городе людей сбивают время от времени, и они тоже наверняка не примеряли такую вероятность на себя.
Видел подобное, только в тестировании. И отсутствие подготовки к встрече, задавание вопросов из готового списка, при чем в течение 2х и более часов. Бывало, что вместе с 2-3 командами одновременно искали примерно одного уровня кандидата и вместе делали ревью тестового задания. Формулировки отказа по заданию были всякой степени абсурдности, включая «вроде все ок, но оформление не очень». И по тому же тз «понимали» каков человек как личность. Я смотрел на это и видел преподов из универа, которым главное соблюсти все их стариковские стандарты, а не качество работы. Что забавно, ведь собеседующие — сами вчерашние студенты.
Так что согласен и про «завалить» и про «становимся теми, от кого настрадались».
Хорошо, если с опытом начинают глаза открываться, как у автора.
Задам наверное очень наивный вопрос — вот весь этот ваш труд начался с детского любопытства на отцовскую фразу про грузовик?)
Я в детстве и палеонтологией занимался в песочнице, и до курса физики строил теории почему изображение внутри столовой ложки переворачивается, а снаружи нет. Пытался найти новый свойства треугольников в начале школьной геометрии.
Но вот этот цикл статей просто монументален. Если все это идет из того детского любопытства, то я впечатлен настолько, насколько позволяют пружины.
если по одному и тому же бранчу запустить сборку дистрибутива, то результат может получится различным, т.к. зависимости между пакетами прописаны не жестко, и состояние репозиториев могло измениться
Не совсем понял по стилю повествования — это относится: к плюсам, к минусам, к непреложным фактам текущей реальности? Далее следуют выводы «Это позволило».
Хотелось бы прочитать, как обруливается данный момент, если он относится к минусам. Все таки нестабильное окружение и тестируемые сценарии вещь и злободневная, и интересная, а мало где можно почитать, как с таким справляются в сложных системах.
Начинал будучи стажером без опыта. Делал помимо технических задач (автотестов, ручного и т.д.) разные дела — и деплоить бэкенды доводилось, и факапы разгребать по качеству и по интеграциям общаться. Т.е. помимо технических задач имел разные зоны ответственности в проектах и команде в целом. Было дело — выстраивал процессы тестирования на новых проектах команды, ну и за релизы продуктов отвечал. В какой-то момент руководитель сказал, что я теперь сеньор.
Когда пришел, был единственным тестировщиком на 5х разработчиков и 3-4 проекта. Сейчас нас в соотношении 1 к 3 примерно, в команде на человек 18-20. Проекты — плюсовые и питонячьи бэкенды, плюсовые же библиотеки, которые потом интегрируются другими командами. Когда тестировщиков стало больше в команде, встал вопрос о руководителе группы тестирования, предложили мне, но внутренне я тогда не был к этому готов (по уровню квалификации был миддлом на тот момент). Позже, когда я дорос до сеньора, а руководитель решил заняться делами вне компании, вакансию снова предложили мне, и в этот раз я согласился (все это время наблюдал, чем занимается мой руководитель и какие задачи решает, и понял, что ничего сверхстрашного и неподъемного там нет).
По процессам — много тоже разного было. Не было общей тестовой документации — каждый писал где хотел и что хотел. Стандарты мы какие-то разрабатывать не стали, а стали писать все чек-листы и прочие штуки в одном общем источнике. Была проблема с кроссфункциональностью — когда один человек (и только он) мог знать, как тестируется целый один проект — автобусный фактор в чистом виде. Ввел практику, что все по кругу тестируем разные проекты, каждый погружается так или иначе во все. Ответственные есть все равно, но каждый может потестировать почти любой продукт. Были проблемы с интеграциями внутри команды (между нашими продуктами) и снаружи — договаривались, притирались. Плохо был построен процесс планирования — тестирование или не планировалось или планировалось по остаточному принципу — что разработка взяла в спринт, то и тестируем, — тестирование не говорило «нет, это не влазит, давайте дедлайны и приоритеты». Исправил этот момент — теперь и дедлайны от разработки есть всегда, и тестирование периодически говорит, что весь релиз не влазит, давайте думать, что будем релизить в следующий раз. Надо мной в иерархии стоит тимлид, он на все улучшения процессов смотрит адекватно, общаемся с ним, с разработчиками, учитываем фидбек. В общем, улучшать процессы никто не мешает, наоборот, ждут этого. На этом проблемы в процессах не кончились, работаем дальше, тем более что ресурса в тестировании на все проекты не хватает, а вакансии согласовываются дольше, чем появляется необходимость в них. Но свои сеньоры подрастают, что-то уже могу передавать им, где-то они фидбечат по процессам и предлагают решения. Растем понемногу)
Хорошая статья. Сейчас прохожу через похожие этапы. Что-то кажется более менее пройденным, что-то в процессе. Пока что часто поддаюсь соблазну «сделай сам», потому что «людей мало», вместо того, чтобы заняться аудитом и оптимизацией работы. Порой хочется сделать что-то дома, внеурочно, но понимаю, что это может для технического спеца — круто, а мне нужно стремиться к другим вещам — перераспределить работу, дать таски ребятам по этой проблеме. Не бежать решать технические проблемы, в общем, а выстраивать процессы вокруг этих проблем такие, чтобы в команде был ресурс их решать. В общем, зон роста много, ваша статья позволила по ним свериться.
Я до сих пор не понимаю этих терок между скриптовым и исследовательским тестированием. Неужели до сих пор жесткое следование детально прописанным сценариям широко распространено? Настолько, что это проблема, с которой надо бороться, продвигая исследовательское? Что вот тестировщики составили тест-кейсы и ни на шаг, не отступают от них.
Или это частный случай тренда «придумай проблему, а потом борись с ней», чтобы создавать движение в отрасли.
Это мне кажется интересный момент. С одной стороны глобализация подстегивает распространение технологий. Чем дальше, тем быстрее и прочнее новинки входят в нашу жизнь, особенно у людей, близких в IT. С другой, в короткой перспективе, если отказываться от этих технологий, то, как пишет автор статьи, могут отправить в лес жить. Потому что вот прям сейчас нет смысла бояться мобильные телефоны или VR очки, а в будущем тех же голосовых помощников продвинутых. И наоборот, не следование за какими-то технологиями может порождать проблемы при попытке жить в мире, где эти технологии на каждом шагу применяются. И получается в каком-то смысле как в той истории, где лягушку варят постепенно. Заметим ли мы, что прошли точку невозврата? Что, если мы уже перешли (о чем и говорит местами автор)?
Любопытно.
Я бы только добавил к тому, что автор пишет про «мы не привыкли думать про то, что будет через 60 лет». Мы в целом привыкли оптимистично думать «если и будет плохое, то не при мне». Но сказать уверенно, возможно ли что-то такое в мое время жизни или нет, у меня нет компетенций. Зато подспудная уверенность есть. Из разряда «меня никогда не собьет машина», несмотря на то, что в моем городе людей сбивают время от времени, и они тоже наверняка не примеряли такую вероятность на себя.
Так что согласен и про «завалить» и про «становимся теми, от кого настрадались».
Хорошо, если с опытом начинают глаза открываться, как у автора.
Я в детстве и палеонтологией занимался в песочнице, и до курса физики строил теории почему изображение внутри столовой ложки переворачивается, а снаружи нет. Пытался найти новый свойства треугольников в начале школьной геометрии.
Но вот этот цикл статей просто монументален. Если все это идет из того детского любопытства, то я впечатлен настолько, насколько позволяют пружины.
Я правильно понимаю — это в основном аффектит ручные тесты? Или автоматические тоже?
Не совсем понял по стилю повествования — это относится: к плюсам, к минусам, к непреложным фактам текущей реальности? Далее следуют выводы «Это позволило».
Хотелось бы прочитать, как обруливается данный момент, если он относится к минусам. Все таки нестабильное окружение и тестируемые сценарии вещь и злободневная, и интересная, а мало где можно почитать, как с таким справляются в сложных системах.
Когда пришел, был единственным тестировщиком на 5х разработчиков и 3-4 проекта. Сейчас нас в соотношении 1 к 3 примерно, в команде на человек 18-20. Проекты — плюсовые и питонячьи бэкенды, плюсовые же библиотеки, которые потом интегрируются другими командами. Когда тестировщиков стало больше в команде, встал вопрос о руководителе группы тестирования, предложили мне, но внутренне я тогда не был к этому готов (по уровню квалификации был миддлом на тот момент). Позже, когда я дорос до сеньора, а руководитель решил заняться делами вне компании, вакансию снова предложили мне, и в этот раз я согласился (все это время наблюдал, чем занимается мой руководитель и какие задачи решает, и понял, что ничего сверхстрашного и неподъемного там нет).
По процессам — много тоже разного было. Не было общей тестовой документации — каждый писал где хотел и что хотел. Стандарты мы какие-то разрабатывать не стали, а стали писать все чек-листы и прочие штуки в одном общем источнике. Была проблема с кроссфункциональностью — когда один человек (и только он) мог знать, как тестируется целый один проект — автобусный фактор в чистом виде. Ввел практику, что все по кругу тестируем разные проекты, каждый погружается так или иначе во все. Ответственные есть все равно, но каждый может потестировать почти любой продукт. Были проблемы с интеграциями внутри команды (между нашими продуктами) и снаружи — договаривались, притирались. Плохо был построен процесс планирования — тестирование или не планировалось или планировалось по остаточному принципу — что разработка взяла в спринт, то и тестируем, — тестирование не говорило «нет, это не влазит, давайте дедлайны и приоритеты». Исправил этот момент — теперь и дедлайны от разработки есть всегда, и тестирование периодически говорит, что весь релиз не влазит, давайте думать, что будем релизить в следующий раз. Надо мной в иерархии стоит тимлид, он на все улучшения процессов смотрит адекватно, общаемся с ним, с разработчиками, учитываем фидбек. В общем, улучшать процессы никто не мешает, наоборот, ждут этого. На этом проблемы в процессах не кончились, работаем дальше, тем более что ресурса в тестировании на все проекты не хватает, а вакансии согласовываются дольше, чем появляется необходимость в них. Но свои сеньоры подрастают, что-то уже могу передавать им, где-то они фидбечат по процессам и предлагают решения. Растем понемногу)
Тестирование головного мозга, прочитал как "в том, что бага нет".
Или это частный случай тренда «придумай проблему, а потом борись с ней», чтобы создавать движение в отрасли.