Да, это важная мысль! Мне кажется тут простой принцип, разовое ручное вмешательство - ничего менять не надо, регулярное - правило уже не отражает реальность и его надо менять.
Тимлиды у нас есть, и в статье это описано. Более того нет ни слова о 30 прямых подчиненных, что, впрочем, не делает нас менее единой командой.
Но наличие тимлидов не означает, что рост команды не влияет на мою роль и способ работы.
Специфика нашего домена не позволяет командам быть полностью автономными. У нас единые инструменты, общие подходы, механизм принятия решений и общий фреймворк. Не из любви к централизации, а потому что без этого мы просто не вывезем нагрузку и комбинаторику.
Поэтому задача не сводится к «раздать людей тимлидам и забыть». Простое дробление команды на полкоманды - это зачастую не стратегия, а реакция на рост, при котором старая модель перестала работать, а новая ещё не выстроена.
Рост команды меняет систему целиком, включая то, чем именно я занимаюсь каждый день и об этом, собственно, статья.
Спасибо за кейс! В подобной ситуации, я бы задал себе вопрос: "Кто больше потеряет от смены места работы?". Предполагаю, что речь идёт про сферу, в которой просто найти работу - уже не простая задача, но в разрезе IT сферы - ответ однозначный)
Вы уходите из компании приобретя какой-то опыт, возможно даже пару строчек в резюме. Плюс, вы попали в такую компанию, споткнулись и на следующем собеседовании будете стараться вычислить такого работодателя. В то же время компания теряет специалиста "с головой", который готов был улучшать процессы и самостоятельно продвигать свои решения.
Найдёте ли вы новую работу с такими исходными данными? Безусловно. Будет ли преуспевать компания, в которой инициативы душатся коллективом и хед-менеджментом, а процессы выстроены по принципу "работает - не трогай"? Ну возможно, но очень сомнительно.
Так какая лично для вас мотивация оставаться в такой компании и биться головой об стену? Даже если предположить, что вы эту стену пробьете, будет ли для вас эта игра, в итоге, стоить свеч?
Вы говорите абсолютно правильные вещи!) Целью статьи не было указать на то, что в больших компаниях не надо думать и нет изменений. Возможно некорректно сформулировал некоторые мысли.
Я попытался поразмышлять с точки зрения среднестатистического тестировщика с большого проекта. Когда ты приходишь в сферу через большую компанию, многое на проекте уже сделано и "подумано" за тебя. У начинающего тестировщика просто нет острой необходимости залезать в каждый процесс компании и разбираться что/зачем/почему.
Изменения в больших компаниях, естественно, происходят, но:
Это происходит достаточно плавно
Все изменения в процессе работы, как правило, документируются
Изменения являются результатом работы многих людей
Конечно, в идеале, такое мышление должно быть у каждого QA, но в большой компании - это возможность для изменений в работе компании и своей карьере, а в стартапе - необходимость для нормальной работы.
Спасибо! В этой статье действительно попытался сделать упор именно на перестройку мышления, так как мне кажется эта тема недостаточно раскрытой) Буду только рад написать статью более приближенную к практике
Чек-листы не могут заменить полноценное тестирование продукта
Очень спорное заявление на мой взгляд) Для чек-лист с прописанным ОР закрывает 90% потребностей тестировщика, который находится в контексте проекта.
В этом как бы и суть, чек-лист - это не просто дополнение тест-кейса, а в какой-то мере его альтернатива.
Возьмем ту же абстрактную регистрацию.
Регистрация пользователя
1. Регистрация по email, которого нет в системе.
ОР: Пользователь зарегистрирован
2. Регистрация по email, который есть в системе.
ОР: Валидация в поле email, регистрация не проходит
… (дальше полет фантазии)
1 шаг - 1 сценарий
Эта логика с гораздо меньшей вероятностью поменяется, чем в вашем примере, например: сообщение о регистрации сменится на редирект на какую-то страницу и придется актуализировать проверку. Хорошо если проект небольшой и кейсов немного, а если их несколько тысяч, то скоро вы обнаружите, что всё ваше время уходит на их поддержку…
Спасибо за комментарий!) Если пойму, что есть необходимость, постараюсь написать несколько статей про старт автоматизации web. Но на данный момент, мне кажется, что информации в интернете по этой теме достаточно много) По подсказкам постараюсь помочь с направлением, не уверен насколько легитимно скидывать сюда ссылки, но думаю можно обойтись и без них:
Надо для себя понять чего вы ждёте от автоматизации и разделить в голове ручное и автоматизированное тестирование. В интернете куча статей на тему "признаки хороших автотестов" и чем кейсы для автотестов отличаются от ручных (например, схема AAA, принцип атомарности или условное правило один тест - одна проверка)
Надо базово изучить/осознать язык программирования, на котором вы будете писать и присмотреть инструменты, с помощью которых вы будете автоматизировать (классика на Python - pytest/selenium, если мы говорим о UI)
По тому же самому Selenium очень много материалов, правда часть из них прилично устарела, так что не забудьте сверяться с официальной документацией (она сейчас очень хорошая и с примерами кода на разных ЯП)
Если попали в тупик в процессе изучения - StackOverflow и ChatGPT в 95% случаев помогут вам разобраться.
Главное не сдаваться из-за ошибок и не ждать быстрого результата! Более-менее нормальную автоматизацию для небольшого проекта я смог запустить только с третьего раза и всё это было очень не быстро. А сколько трудностей ещё впереди мне даже страшно думать)
Спасибо за статью! Может местами не очень точно, но определенно на человеческом языке)
Всё таки наверное правильнее было бы поставить scope в другом порядке по важности:
function - инициализируем предусловия для конкретного теста, выдаем специфические тестовые данные и т.д. В идеале, если стремиться к атомарности тестов, для каждого теста можно бы и браузер отдельный запускать средствами, например selenoid
session - привести стенд в исходное состояние, создать тестовые данные, подключиться к БД и очень много других действий, которые не имеет смысла выполнять больше одного раза за прогон
class - для каких-то специфических операций для конкретного тест-сьюита
Да, это важная мысль! Мне кажется тут простой принцип, разовое ручное вмешательство - ничего менять не надо, регулярное - правило уже не отражает реальность и его надо менять.
Именно так. Это описание точки, в которой стало ясно, что старая модель «лид прямых подчиненных» больше не работает.
Тимлиды у нас есть, и в статье это описано. Более того нет ни слова о 30 прямых подчиненных, что, впрочем, не делает нас менее единой командой.
Но наличие тимлидов не означает, что рост команды не влияет на мою роль и способ работы.
Специфика нашего домена не позволяет командам быть полностью автономными. У нас единые инструменты, общие подходы, механизм принятия решений и общий фреймворк. Не из любви к централизации, а потому что без этого мы просто не вывезем нагрузку и комбинаторику.
Поэтому задача не сводится к «раздать людей тимлидам и забыть». Простое дробление команды на полкоманды - это зачастую не стратегия, а реакция на рост, при котором старая модель перестала работать, а новая ещё не выстроена.
Рост команды меняет систему целиком, включая то, чем именно я занимаюсь каждый день и об этом, собственно, статья.
Спасибо за кейс! В подобной ситуации, я бы задал себе вопрос: "Кто больше потеряет от смены места работы?". Предполагаю, что речь идёт про сферу, в которой просто найти работу - уже не простая задача, но в разрезе IT сферы - ответ однозначный)
Вы уходите из компании приобретя какой-то опыт, возможно даже пару строчек в резюме. Плюс, вы попали в такую компанию, споткнулись и на следующем собеседовании будете стараться вычислить такого работодателя. В то же время компания теряет специалиста "с головой", который готов был улучшать процессы и самостоятельно продвигать свои решения.
Найдёте ли вы новую работу с такими исходными данными? Безусловно. Будет ли преуспевать компания, в которой инициативы душатся коллективом и хед-менеджментом, а процессы выстроены по принципу "работает - не трогай"? Ну возможно, но очень сомнительно.
Так какая лично для вас мотивация оставаться в такой компании и биться головой об стену? Даже если предположить, что вы эту стену пробьете, будет ли для вас эта игра, в итоге, стоить свеч?
Вы говорите абсолютно правильные вещи!)
Целью статьи не было указать на то, что в больших компаниях не надо думать и нет изменений. Возможно некорректно сформулировал некоторые мысли.
Я попытался поразмышлять с точки зрения среднестатистического тестировщика с большого проекта. Когда ты приходишь в сферу через большую компанию, многое на проекте уже сделано и "подумано" за тебя. У начинающего тестировщика просто нет острой необходимости залезать в каждый процесс компании и разбираться что/зачем/почему.
Изменения в больших компаниях, естественно, происходят, но:
Это происходит достаточно плавно
Все изменения в процессе работы, как правило, документируются
Изменения являются результатом работы многих людей
Конечно, в идеале, такое мышление должно быть у каждого QA, но в большой компании - это возможность для изменений в работе компании и своей карьере, а в стартапе - необходимость для нормальной работы.
Выложил пример на GitHub https://github.com/dikobra4/TelegramTestingBotExample
Спасибо! В этой статье действительно попытался сделать упор именно на перестройку мышления, так как мне кажется эта тема недостаточно раскрытой)
Буду только рад написать статью более приближенную к практике
Спасибо за статью!
Очень спорное заявление на мой взгляд) Для чек-лист с прописанным ОР закрывает 90% потребностей тестировщика, который находится в контексте проекта.
В этом как бы и суть, чек-лист - это не просто дополнение тест-кейса, а в какой-то мере его альтернатива.
Возьмем ту же абстрактную регистрацию.
1 шаг - 1 сценарий
Эта логика с гораздо меньшей вероятностью поменяется, чем в вашем примере, например: сообщение о регистрации сменится на редирект на какую-то страницу и придется актуализировать проверку. Хорошо если проект небольшой и кейсов немного, а если их несколько тысяч, то скоро вы обнаружите, что всё ваше время уходит на их поддержку…
Спасибо за комментарий!) Если пойму, что есть необходимость, постараюсь написать несколько статей про старт автоматизации web. Но на данный момент, мне кажется, что информации в интернете по этой теме достаточно много)
По подсказкам постараюсь помочь с направлением, не уверен насколько легитимно скидывать сюда ссылки, но думаю можно обойтись и без них:
Надо для себя понять чего вы ждёте от автоматизации и разделить в голове ручное и автоматизированное тестирование. В интернете куча статей на тему "признаки хороших автотестов" и чем кейсы для автотестов отличаются от ручных (например, схема AAA, принцип атомарности или условное правило один тест - одна проверка)
Надо базово изучить/осознать язык программирования, на котором вы будете писать и присмотреть инструменты, с помощью которых вы будете автоматизировать (классика на Python - pytest/selenium, если мы говорим о UI)
По тому же самому Selenium очень много материалов, правда часть из них прилично устарела, так что не забудьте сверяться с официальной документацией (она сейчас очень хорошая и с примерами кода на разных ЯП)
Если попали в тупик в процессе изучения - StackOverflow и ChatGPT в 95% случаев помогут вам разобраться.
Главное не сдаваться из-за ошибок и не ждать быстрого результата! Более-менее нормальную автоматизацию для небольшого проекта я смог запустить только с третьего раза и всё это было очень не быстро. А сколько трудностей ещё впереди мне даже страшно думать)
Спасибо за статью! Может местами не очень точно, но определенно на человеческом языке)
Всё таки наверное правильнее было бы поставить scope в другом порядке по важности:
function - инициализируем предусловия для конкретного теста, выдаем специфические тестовые данные и т.д. В идеале, если стремиться к атомарности тестов, для каждого теста можно бы и браузер отдельный запускать средствами, например selenoid
session - привести стенд в исходное состояние, создать тестовые данные, подключиться к БД и очень много других действий, которые не имеет смысла выполнять больше одного раза за прогон
class - для каких-то специфических операций для конкретного тест-сьюита
Буду рад узнать, если я вдруг не прав)