На этой работе я первый раз сталкиваюсь с настоящими тестовыми стендами.
Это тебе не ветка с кодом и система, разворачивающася за три команды гита. Тут это ОС и программный комплекс, который еще нужно определенным образом настроить.
И здесь я особенно понимаю, как важно убраться за собой! Что-то поделать, добиться нужных ошибок и вернуть обратно в рабочее состояние.
Если этого не сделать - потом даже самой не вспомнить, а что я такое с этим стендом сотворила, что он сейчас не работает.
В детстве меня, кстати, очень бесила идея "Поработала, убери за собой", а вот в работе стараюсь так и делать)
#заметки_с_полей
Это тебе не ветка с кодом и система, разворачивающася за три команды гита. Тут это ОС и программный комплекс, который еще нужно определенным образом настроить.
И здесь я особенно понимаю, как важно убраться за собой! Что-то поделать, добиться нужных ошибок и вернуть обратно в рабочее состояние.
Если этого не сделать - потом даже самой не вспомнить, а что я такое с этим стендом сотворила, что он сейчас не работает.
В детстве меня, кстати, очень бесила идея "Поработала, убери за собой", а вот в работе стараюсь так и делать)
#заметки_с_полей
Продолжаю читать SRE Book и думаю про то, насколько важна безопасная среда.
В книге, помимо всего прочего, пишут о постмортемах без обвинений и упреков. Когда мы конценрируемся на системных причинах инцидента, а не на том, кто конкретно виноват. По этой теме вспомнила хороший перевод Сергея Высоцкого про схожую философию в Etsy - https://goblingame.blogspot.com/2012/07/blog-post_13.html
Если люди не чувствую себя безопасно - они не будут высказывать идеи, в которых не уверены, будут скрывать важные подробности и последствия инцидента, будут прикрываться бумагами и письмами.
Для меня важная часть безопасности, когда в компании не принят троллинг. Я слышала возражения, что это только шутки. Но шутки от троллинга отличаются, на мой взгляд, тем, что над шутками смеются все участники. В моем опыте шутки и остроумие были чаще направлены на процессы, а троллинг - это агрессивные нападки на конкретных людей.
#менеджерское
#книги
В книге, помимо всего прочего, пишут о постмортемах без обвинений и упреков. Когда мы конценрируемся на системных причинах инцидента, а не на том, кто конкретно виноват. По этой теме вспомнила хороший перевод Сергея Высоцкого про схожую философию в Etsy - https://goblingame.blogspot.com/2012/07/blog-post_13.html
Если люди не чувствую себя безопасно - они не будут высказывать идеи, в которых не уверены, будут скрывать важные подробности и последствия инцидента, будут прикрываться бумагами и письмами.
Для меня важная часть безопасности, когда в компании не принят троллинг. Я слышала возражения, что это только шутки. Но шутки от троллинга отличаются, на мой взгляд, тем, что над шутками смеются все участники. В моем опыте шутки и остроумие были чаще направлены на процессы, а троллинг - это агрессивные нападки на конкретных людей.
#менеджерское
#книги
Blogspot
Пост Мортемы Без Упреков и Культура Справедливости
В продолжение предыдущего поста: Перевод статьи Джона Оллспоу "Blamelless PostMortems and a Just Culture" На прошлой неделе Оуэн Томас...
Из нового для себя узнала, что в Badoo используют мутационное тестирование (я писала про это чуть больше года назад - https://news.1rj.ru/str/testing_and_life/200). Радует, что это реально применяют!
#записная_книжка
#записная_книжка
Telegram
Тестирование и жизнь
https://habrahabr.ru/post/334394/ - про то, как автоматизированно проверить, что ваши юнит-тесты проверяют то, что надо. Тесты на тесты, ага.
Ну и первый пример в этой статье еще и про то, зачем разработчикам учиться тест-дизайну.
#записная_книжка
Ну и первый пример в этой статье еще и про то, зачем разработчикам учиться тест-дизайну.
#записная_книжка
Forwarded from DocOps
Монолит для сотен версий клиентов: как мы пишем и поддерживаем тесты.
Владимир Янц, Badoo
Снова доклад-ликбез про организацию тестирования в Badoo. Думаю, что это можно показывать начинающим разработчикам и тестировщикам, чтобы донести до них ценность тестирования и понимание пирамиды тестирования.
В конце слайдов были полезные ссылки от докладчика, я их скопировал в конспект.
https://github.com/NickVolynkin/highload-2018/blob/master/2.2-testing-badoo.md
Владимир Янц, Badoo
Снова доклад-ликбез про организацию тестирования в Badoo. Думаю, что это можно показывать начинающим разработчикам и тестировщикам, чтобы донести до них ценность тестирования и понимание пирамиды тестирования.
В конце слайдов были полезные ссылки от докладчика, я их скопировал в конспект.
https://github.com/NickVolynkin/highload-2018/blob/master/2.2-testing-badoo.md
Forwarded from Knowledge and bacon - Управление знаниями в IT
Долг компетенций
Понятие технический долг уже плотно вошло в нашу жизнь, но оно предельно широкое, к нему относят множество аспектов разработки и по сути все, что не совпадает с представлением об идеальном техническом решении: архитектура, тесты, ресурсы, документация, навыки команды.
Мне бы хотелось поговорить об одном из аспектов технического долга, который как раз про "управление знаниями" – это долг компетенций.
Долг компетенций – это узкая специализация в процессе разработки, когда знания об архитектуре системы, о принятых решениях, о деталях реализации, сосредоточены у отдельных людей, подход к изменению такого кода или настроек может отнять у других участников команды намного больше времени, а может и вообще привести е неверным решениям.
Уход специалиста сразу превращает такой код в "legacy", "not invented here", "to rewrite", "так исторически сложилось" и прочие штампы. Усложняется поддержка и, как правило, ухудшается точность декомпозиции задач при работе с таким кодом, поскольку не влезая в детали сложно оценить реальный объем изменений.
К посту прикреплена иллюстрация типичного долга компенетций, где есть пересекающееся знание, а есть уникальное, с bus фактором – 1. Долг компетенций растет тем быстрее, чем чаще вы вносите изменения в код базу и чем меньше у вас общего кода и библиотек, которыми пользуется большинство в команде.
Что снижает долг компетенций
Парное программирование, перекрестные ревью кода, когда с одним и тем же кодом постоянно знакомы хотя бы два человека. Аналогично и с периодическим командным рефакторингом.
Также могут помочь автоматические тесты, юнит и функциональные, чтобы написать тест, как правило, нужно понимать работу системы или ее функциональной части более-менее хорошо, плюс документация в коде или рядом с ним. Причем, не требуется страниц текста, да и вообще текст, например, вы можете фиксировать каждый модуль в виде флоучарта или UML диаграммы последовательности, хранить их рядом с кодом в PlantUML с возможностью перед началом работы над модулем быстро сгенерить диаграмму в условный HTML.
Еще одна хорошая практика – фиксировать принятые архитектурные и технические решения с небольшим обоснованием, даже если они приняты на митинге или во время разговора на кухне.
Радикальные методы вроде взять и переписать все, заменить старый код на новый, обычно в условиях быстрой доставки функциональности – это роскошь, ведь у нас всегда есть дела поважнее, но есть положительный аспект, чтобы переписать хотя бы часть системы – нужно понять, как она работает.
Еще по теме
http://www.leanway.no/a-deeper-look-at-competence-debt/
http://www.julianbrowne.com/article/competence-debt
Понятие технический долг уже плотно вошло в нашу жизнь, но оно предельно широкое, к нему относят множество аспектов разработки и по сути все, что не совпадает с представлением об идеальном техническом решении: архитектура, тесты, ресурсы, документация, навыки команды.
Мне бы хотелось поговорить об одном из аспектов технического долга, который как раз про "управление знаниями" – это долг компетенций.
Долг компетенций – это узкая специализация в процессе разработки, когда знания об архитектуре системы, о принятых решениях, о деталях реализации, сосредоточены у отдельных людей, подход к изменению такого кода или настроек может отнять у других участников команды намного больше времени, а может и вообще привести е неверным решениям.
Уход специалиста сразу превращает такой код в "legacy", "not invented here", "to rewrite", "так исторически сложилось" и прочие штампы. Усложняется поддержка и, как правило, ухудшается точность декомпозиции задач при работе с таким кодом, поскольку не влезая в детали сложно оценить реальный объем изменений.
К посту прикреплена иллюстрация типичного долга компенетций, где есть пересекающееся знание, а есть уникальное, с bus фактором – 1. Долг компетенций растет тем быстрее, чем чаще вы вносите изменения в код базу и чем меньше у вас общего кода и библиотек, которыми пользуется большинство в команде.
Что снижает долг компетенций
Парное программирование, перекрестные ревью кода, когда с одним и тем же кодом постоянно знакомы хотя бы два человека. Аналогично и с периодическим командным рефакторингом.
Также могут помочь автоматические тесты, юнит и функциональные, чтобы написать тест, как правило, нужно понимать работу системы или ее функциональной части более-менее хорошо, плюс документация в коде или рядом с ним. Причем, не требуется страниц текста, да и вообще текст, например, вы можете фиксировать каждый модуль в виде флоучарта или UML диаграммы последовательности, хранить их рядом с кодом в PlantUML с возможностью перед началом работы над модулем быстро сгенерить диаграмму в условный HTML.
Еще одна хорошая практика – фиксировать принятые архитектурные и технические решения с небольшим обоснованием, даже если они приняты на митинге или во время разговора на кухне.
Радикальные методы вроде взять и переписать все, заменить старый код на новый, обычно в условиях быстрой доставки функциональности – это роскошь, ведь у нас всегда есть дела поважнее, но есть положительный аспект, чтобы переписать хотя бы часть системы – нужно понять, как она работает.
Еще по теме
http://www.leanway.no/a-deeper-look-at-competence-debt/
http://www.julianbrowne.com/article/competence-debt
Думаю про гендерное в тестировании. Я бы хотела написать про это статью или сделать подробный рассказ, но сил пока хватает только на заметки по ходу размышлений.
В большинстве дискуссий о женщинах в IT я слышу про программисток. Это действительно важные вопросы - и про STEM, и про то, как пробиваться в престижные области, которые считаются сейчас в обществе мужскими.
В тестировании много женщин и казалось бы, что тут особых проблем нет - если хочешь - приходи и становись тестировщицей. И я сталкивалась с тем, что даже программистки считали, что стать тестировщицей - это легкая дорога.
Но я считаю, что не все так просто. В тестировании в России явно выделяются разные сегменты работы - преимущественно ручное тестирование, автоматизированное и требующее других глубоких технических навыков тестирование, управление.
В моем опыте больше всего женщин в ручном тестировании и оно же ценится меньше всего. Мужчины тут тоже есть, но чаще они достаточно быстро уходят в то, что приносит больше денег и почета.
В IT в целом есть культура кода и технических навыков, которые первичны и престижны. И из этого мне кажется все эти разговоры про то "должны ли менеджеры/дизайнеры/тестировщики уметь программировать?".
Ручное тестирование же при этом - про социальное, про слушать и слышать людей, про строить гипотезы и их доказывать. И это все чаще всего происходит в голове тестировщика/тестировщицы. Это такая работа, которая не видна снаружи - виден только результат. Невидимая работа.
Нашу работу и не видят и не интересуются по-настоящему, что мы делаем и сколько это занимает времени и сил. И вопросы "да что тут тестировать?" мне кажутся близкими к "да что тут дома делать, с современной техникой-то?".
И как и с домашними делами, видно, только когда эта работа не сделана. И то далеко не всегда сразу. Если не протестировать или недостаточно протестировать пару раз может даже ничего страшного не случится, если не делать это значимое время - система будет деградировать.
А еще многие тестировщицы живут с ощущением того, что их не ценят. Они знают, что они делают важную работу, но эта невидимая работа. И мы думаем, что чем больше мы будем стараться и чем лучше мы ее будем делать, тем больше будут ценить.
В моем опыте признание получаешь от людей, которые работают с тобой бок о бок, которые видят как становится лучше - даже если не понимают, как мы это делаем. А вот уровнем выше - уже нет. Редко какой технический директор вспомнит про то, что у него есть ручные тестировщики и скажет про их достижения.
И это тоже попадает в опыт многих женщин - стараться, делать невидимую работу раз за разом и надеяться, что нас оценят по достоинству.
Продолжение следует...
#diversity
#women_in_tech
В большинстве дискуссий о женщинах в IT я слышу про программисток. Это действительно важные вопросы - и про STEM, и про то, как пробиваться в престижные области, которые считаются сейчас в обществе мужскими.
В тестировании много женщин и казалось бы, что тут особых проблем нет - если хочешь - приходи и становись тестировщицей. И я сталкивалась с тем, что даже программистки считали, что стать тестировщицей - это легкая дорога.
Но я считаю, что не все так просто. В тестировании в России явно выделяются разные сегменты работы - преимущественно ручное тестирование, автоматизированное и требующее других глубоких технических навыков тестирование, управление.
В моем опыте больше всего женщин в ручном тестировании и оно же ценится меньше всего. Мужчины тут тоже есть, но чаще они достаточно быстро уходят в то, что приносит больше денег и почета.
В IT в целом есть культура кода и технических навыков, которые первичны и престижны. И из этого мне кажется все эти разговоры про то "должны ли менеджеры/дизайнеры/тестировщики уметь программировать?".
Ручное тестирование же при этом - про социальное, про слушать и слышать людей, про строить гипотезы и их доказывать. И это все чаще всего происходит в голове тестировщика/тестировщицы. Это такая работа, которая не видна снаружи - виден только результат. Невидимая работа.
Нашу работу и не видят и не интересуются по-настоящему, что мы делаем и сколько это занимает времени и сил. И вопросы "да что тут тестировать?" мне кажутся близкими к "да что тут дома делать, с современной техникой-то?".
И как и с домашними делами, видно, только когда эта работа не сделана. И то далеко не всегда сразу. Если не протестировать или недостаточно протестировать пару раз может даже ничего страшного не случится, если не делать это значимое время - система будет деградировать.
А еще многие тестировщицы живут с ощущением того, что их не ценят. Они знают, что они делают важную работу, но эта невидимая работа. И мы думаем, что чем больше мы будем стараться и чем лучше мы ее будем делать, тем больше будут ценить.
В моем опыте признание получаешь от людей, которые работают с тобой бок о бок, которые видят как становится лучше - даже если не понимают, как мы это делаем. А вот уровнем выше - уже нет. Редко какой технический директор вспомнит про то, что у него есть ручные тестировщики и скажет про их достижения.
И это тоже попадает в опыт многих женщин - стараться, делать невидимую работу раз за разом и надеяться, что нас оценят по достоинству.
Продолжение следует...
#diversity
#women_in_tech
❤1
Про тестирование и гендерное часть два. Напоминаю, что это формат черновиков.
В моем опыте от тестировщиков те, кто их нанимает, ожидают кропотливости, внимательности, способности к длительному монотонному труду и ответственности. И это тоже попадает в гендерные ожидания. Невидимая, монотонная, кропотливая работа, с которой лучше справляются женщины.
На самом деле у нас может быть совсем другое тестирование, но даже если про это рассказывать другим людям - все равно не верят) Сколько разговоров про то, что ручное тестирование - это делать из раза в раз одно и тоже? И что разработчики не хотели бы тестировать - это скучно?
А еще от тестировщиков и особенно тестирировщиц окружающие коллеги ждут, что они будут заботиться о деле, будут отвественны и будут отвечать за конечный результат. Занятно, что люди, у которых меньше всего власти и влияния, отвечают за то, как все получится. На деле, понятно, что мы не можем за это отвечать, но часто от нас ждут именно этого.
И это приводит и к переработкам, и к попыткам успеть все и еще немного. Отвечать за все, контролировать, много работать и ждать, что нас оценят.
Зона нашей работы все время размывается. Раз уж это невидимая работа, то почему бы тестировщикам не делать еще что-нибудь? Как в том же домашнем хозяйств - дело перетекает в другое дело, мы начинаем делаем то, что кроме нас не сделает никто, а проекту без этого ощутимо плохо. Чаще всего это менеджерская и аналитическая работа. Мы латаем дыры, подхватываем расползающееся полотно и пытаемся его заштопать.
В лучшем случае - это признается, нам больше платят и ценят. В плохом - это проходит незамеченным или разумеется само собой.
А еще на нас скидывают разную монотонную работу, под девизом "надо же развиваться". Править селекторы в коде, править метки во фронтовых шаблонах - без системы это не дает ничего, забывается сразу, как прекращаешь это делать и занимает изрядно времени. А иногда мы предлагаем это сами - потому, что нам нужен результат, а уговорить это сделать тех, кто должен - не получается.
#diversity
#women_in_tech
В моем опыте от тестировщиков те, кто их нанимает, ожидают кропотливости, внимательности, способности к длительному монотонному труду и ответственности. И это тоже попадает в гендерные ожидания. Невидимая, монотонная, кропотливая работа, с которой лучше справляются женщины.
На самом деле у нас может быть совсем другое тестирование, но даже если про это рассказывать другим людям - все равно не верят) Сколько разговоров про то, что ручное тестирование - это делать из раза в раз одно и тоже? И что разработчики не хотели бы тестировать - это скучно?
А еще от тестировщиков и особенно тестирировщиц окружающие коллеги ждут, что они будут заботиться о деле, будут отвественны и будут отвечать за конечный результат. Занятно, что люди, у которых меньше всего власти и влияния, отвечают за то, как все получится. На деле, понятно, что мы не можем за это отвечать, но часто от нас ждут именно этого.
И это приводит и к переработкам, и к попыткам успеть все и еще немного. Отвечать за все, контролировать, много работать и ждать, что нас оценят.
Зона нашей работы все время размывается. Раз уж это невидимая работа, то почему бы тестировщикам не делать еще что-нибудь? Как в том же домашнем хозяйств - дело перетекает в другое дело, мы начинаем делаем то, что кроме нас не сделает никто, а проекту без этого ощутимо плохо. Чаще всего это менеджерская и аналитическая работа. Мы латаем дыры, подхватываем расползающееся полотно и пытаемся его заштопать.
В лучшем случае - это признается, нам больше платят и ценят. В плохом - это проходит незамеченным или разумеется само собой.
А еще на нас скидывают разную монотонную работу, под девизом "надо же развиваться". Править селекторы в коде, править метки во фронтовых шаблонах - без системы это не дает ничего, забывается сразу, как прекращаешь это делать и занимает изрядно времени. А иногда мы предлагаем это сами - потому, что нам нужен результат, а уговорить это сделать тех, кто должен - не получается.
#diversity
#women_in_tech
❤1
Про тестирование и гендерное часть три. И что со всем этим делать?
И сначала я хочу поговорить о том, что мы чувствуем.
Для меня было самым главным понять, что это не только моя проблема. Что это не я такая неправильная, что это вижу, чувствую и переживаю.
Я не видела про это выступлений на конференциях, но про это говорят в более неформальной и приватной обстановке - в барах и чатиках)
А еще мне помогли книги про социальное и работу - "Не бойся действовать" Шерил Сэндберг и Нелла Сковелла, "Хороши девочки отправляются на небеса, а плохие - куда захотят" Уте Эрхардт и "Третья волна" Элвина Тоффлера.
Когда мы начинаем про это говорить, пусть даже в узком кругу, мы получаем поддержку - с этим сталкиваются многие из нас, мы не одиноки. Я бы советовала искать и/или создавать безопасную группу, в которой вы могли бы говорить о том, что чувствуете в профессии.
Я думаю, что в нашей профессии много гендерной специфики и нам тоже нужны группы "Женщины, которые тестируют" также как и програмисткам.
Мне также помогло ходить с этим к психологу и говорить про то, что я чувствую и вижу. Про социальное и гендерное, про власть и иерархию и искать какие-то собственные выходы.
#diversity
#women_in_tech
И сначала я хочу поговорить о том, что мы чувствуем.
Для меня было самым главным понять, что это не только моя проблема. Что это не я такая неправильная, что это вижу, чувствую и переживаю.
Я не видела про это выступлений на конференциях, но про это говорят в более неформальной и приватной обстановке - в барах и чатиках)
А еще мне помогли книги про социальное и работу - "Не бойся действовать" Шерил Сэндберг и Нелла Сковелла, "Хороши девочки отправляются на небеса, а плохие - куда захотят" Уте Эрхардт и "Третья волна" Элвина Тоффлера.
Когда мы начинаем про это говорить, пусть даже в узком кругу, мы получаем поддержку - с этим сталкиваются многие из нас, мы не одиноки. Я бы советовала искать и/или создавать безопасную группу, в которой вы могли бы говорить о том, что чувствуете в профессии.
Я думаю, что в нашей профессии много гендерной специфики и нам тоже нужны группы "Женщины, которые тестируют" также как и програмисткам.
Мне также помогло ходить с этим к психологу и говорить про то, что я чувствую и вижу. Про социальное и гендерное, про власть и иерархию и искать какие-то собственные выходы.
#diversity
#women_in_tech
❤1
Про тестирование и гендерное, часть четыре.
Я думаю, что очень важно выбирать свои битвы.
С одной стороны сложно молчать и улыбаться, когда про тестирование говорят чушь. Или когда про тестирование говорят только в контексте автоматизированого или не упоминают вообще. И чем больше мы высказываем свою позицию, тем больше шансов, что нас услышат. Что мы выйдем из глубокой оппозиции и разговоров по чатам.
И начинать говорить бывает ужасно страшно. Ну по крайней мере мне было (да есть, временами). Потому, что это во многом перестать быть милой, внимательной и ответственной.
С другой стороны есть такая штука, как активисткое выгорание. Потому, что надоедает каждый раз объяснять с нуля, что такое тестирование и почему вот то, о чем вы говорите - это не оно. И каждый разговор начинать с того, что вы выясняете термины и понятия.
И тут стоит выбирать - где и как мы хотим говорить, сколько сейчас сил, насколько безопасная среда и насколько мы можем рисковать, говоря сильно необщепринятые вещи.
#diversity
#women_in_tech
Я думаю, что очень важно выбирать свои битвы.
С одной стороны сложно молчать и улыбаться, когда про тестирование говорят чушь. Или когда про тестирование говорят только в контексте автоматизированого или не упоминают вообще. И чем больше мы высказываем свою позицию, тем больше шансов, что нас услышат. Что мы выйдем из глубокой оппозиции и разговоров по чатам.
И начинать говорить бывает ужасно страшно. Ну по крайней мере мне было (да есть, временами). Потому, что это во многом перестать быть милой, внимательной и ответственной.
С другой стороны есть такая штука, как активисткое выгорание. Потому, что надоедает каждый раз объяснять с нуля, что такое тестирование и почему вот то, о чем вы говорите - это не оно. И каждый разговор начинать с того, что вы выясняете термины и понятия.
И тут стоит выбирать - где и как мы хотим говорить, сколько сейчас сил, насколько безопасная среда и насколько мы можем рисковать, говоря сильно необщепринятые вещи.
#diversity
#women_in_tech
Про тестирование и гендерное, часть пять
Еще одна сложная штука - это предъявлять то, что ты сделала или придумала. Делать это видимым. На работе, в отличие от института или школы, нет явных параметров, по которым тебя оценивают. И если ты что-то делаешь и молчишь, это все эти люди вокруг скорее всего этого не заметят.
Это тяжело, потому что многих из нас всю дорогу учили, что надо просто хорошо делать своё дело и стараться. Но этого оказывается, к сожалению, мало. Да, и тут против нас тоже действуют гендерные стереопиты - нас меньше слушают и слышат, чаще перебивают и нам сложнее говорить о своём.
Часто решения о том, как тебе развиваться дальше или что должны делать тестировщицы принимают люди, которые либо никогда не тестировали, либо тестировали давно и недолго. Нередко в тим-лиды и тест-лиды вырастают как раз тестировщики-автоматизаторы.
И если мы не будем говорить о том, как на самом деле обстоят дела - наш голос не будет услышан. И мы столкнемся уже с тем, что мы уже _должны_ делать. В последние несколько раз я выбирала работу по тому, насколько моё мировоззрение совпадает с мировоззрением моего/моей тимлида. И это сильно другое качество работы)
Кажется, что все мои рекомендации можно свести к следующему:
- собирать группу поддержки и все то, что дает ресурсы
- показывать свои мысли, идеи и результаты
- говорить о том, что думаешь и что тебе важно.
И первый пункт тут ключевой.
#diversity
#women_in_tech
Еще одна сложная штука - это предъявлять то, что ты сделала или придумала. Делать это видимым. На работе, в отличие от института или школы, нет явных параметров, по которым тебя оценивают. И если ты что-то делаешь и молчишь, это все эти люди вокруг скорее всего этого не заметят.
Это тяжело, потому что многих из нас всю дорогу учили, что надо просто хорошо делать своё дело и стараться. Но этого оказывается, к сожалению, мало. Да, и тут против нас тоже действуют гендерные стереопиты - нас меньше слушают и слышат, чаще перебивают и нам сложнее говорить о своём.
Часто решения о том, как тебе развиваться дальше или что должны делать тестировщицы принимают люди, которые либо никогда не тестировали, либо тестировали давно и недолго. Нередко в тим-лиды и тест-лиды вырастают как раз тестировщики-автоматизаторы.
И если мы не будем говорить о том, как на самом деле обстоят дела - наш голос не будет услышан. И мы столкнемся уже с тем, что мы уже _должны_ делать. В последние несколько раз я выбирала работу по тому, насколько моё мировоззрение совпадает с мировоззрением моего/моей тимлида. И это сильно другое качество работы)
Кажется, что все мои рекомендации можно свести к следующему:
- собирать группу поддержки и все то, что дает ресурсы
- показывать свои мысли, идеи и результаты
- говорить о том, что думаешь и что тебе важно.
И первый пункт тут ключевой.
#diversity
#women_in_tech
И P.S.
Все эти активности - это когда вам не хватает признания, гордости за свою работу, видимости и карьеры.
Если у вас небезопасная среда и вы никуда не можете из нее сейчас деться. Если у вас нет подушки безопасности и нет уверенности, что вы быстро найдете работу. Если у вас на руках люди и звери, которые от вас и вашей зарплаты критично зависят. Если у вас стоит задача выжить - затаиться и просто делать то, что скажут - годная, правильная идея.
Выживание очень плохо совмещается с развитием.
#diversity
#women_in_tech
Все эти активности - это когда вам не хватает признания, гордости за свою работу, видимости и карьеры.
Если у вас небезопасная среда и вы никуда не можете из нее сейчас деться. Если у вас нет подушки безопасности и нет уверенности, что вы быстро найдете работу. Если у вас на руках люди и звери, которые от вас и вашей зарплаты критично зависят. Если у вас стоит задача выжить - затаиться и просто делать то, что скажут - годная, правильная идея.
Выживание очень плохо совмещается с развитием.
#diversity
#women_in_tech
И еще кусок про социальное и тестирование.
Меня бесит, когда ко мне приходят с карьерными советами без моего запроса. Когда люди, которые даже не тестировщики начинают рассказывать мне, куда мне надо стремиться и чем заниматься - автотестированием, за ним будущее. Или идти в управление. Или еще что-то делать, что им кажется правильным. При этом люди мало что знают о тестировании, моей работе и мне.
И это ведь происходит сплошь и рядом. Когда ты говоришь, что ты тестировшица - многие люди из IT пытаются высказать своё ценное мнение.
При этом есть бережная обратная связь, от людей которые меня знают. Они говорят мне, что у меня хорошо выходит вот это или вон то и возможно мне интересно будет идти в том направлении? И я это слышу совсем иначе и благодарна за это.
#подпольный_евангелизм
Меня бесит, когда ко мне приходят с карьерными советами без моего запроса. Когда люди, которые даже не тестировщики начинают рассказывать мне, куда мне надо стремиться и чем заниматься - автотестированием, за ним будущее. Или идти в управление. Или еще что-то делать, что им кажется правильным. При этом люди мало что знают о тестировании, моей работе и мне.
И это ведь происходит сплошь и рядом. Когда ты говоришь, что ты тестировшица - многие люди из IT пытаются высказать своё ценное мнение.
При этом есть бережная обратная связь, от людей которые меня знают. Они говорят мне, что у меня хорошо выходит вот это или вон то и возможно мне интересно будет идти в том направлении? И я это слышу совсем иначе и благодарна за это.
#подпольный_евангелизм
Ещё пример про кодоцентричность IT.
Forwarded from Product channel fit Ӏ Камилла Самохина
Канал молчал, потому что было очень напряженное предрелизное время. Зато теперь в приложении iOS одного желто-черного банка можно купить билеты на концерты и спектакли, что и советую вам сделать. А пока хочу вернуться и с вопросом:
Должен ли аналитик уметь кодить, если ему не нужно это по работе?
Недавно с коллегой спорили, должен ли аналитик уметь писать код. Не трогаем вариант, когда это входит в обязанности аналитика (скрипты какие-нибудь там для обработки данных писать и т.п), здесь вопросов нет. Но, если не входит, то мнения делятся: кто-то считает, что без умения писать код аналитик не поймет разработчика, кто-то считает, что это лишнее.
Я обычно говорю так: умение писать код и знание основ программирования обычно является признаком, что человек умеет логически мыслить и понимает IT-специфику. Но здесь нередко случаются перекосы, когда аналитик начинает указывать разработчику, что ему сделать и иногда (где-то компании такое позволяют) порывается написать код за него. Или начинает писать ТЗ так, что оно понятно только разработчикам, но никому из коллег. Или получает доступ к коду, начинает сам в нем копаться и искать ответы на вопросы, что обычно приводит к огромным ошибкам а-ля "я посмотрел, тут вот так реализовано", что используется для дальнейших постановок задач, и запускает долгую цепочку ошибок.
В общем, считаю, что уметь кодить совсем не обязательно, но, если ты уж это умеешь, нужно уметь вовремя себя остановить и оставить работу с кодом людям, у которых это основная обязанность. И мне смешно и грустно за компании, которые в вакансиях пишут "уверенное знание С++, PHP, Scala" и на вопрос "зачем?" отвечают "чтобы понимать разработчиков лучше".
Вы как думаете?
✅согласен с постом
⛔️ должен уметь кодить, даже если ему это не нужно в работе
Должен ли аналитик уметь кодить, если ему не нужно это по работе?
Недавно с коллегой спорили, должен ли аналитик уметь писать код. Не трогаем вариант, когда это входит в обязанности аналитика (скрипты какие-нибудь там для обработки данных писать и т.п), здесь вопросов нет. Но, если не входит, то мнения делятся: кто-то считает, что без умения писать код аналитик не поймет разработчика, кто-то считает, что это лишнее.
Я обычно говорю так: умение писать код и знание основ программирования обычно является признаком, что человек умеет логически мыслить и понимает IT-специфику. Но здесь нередко случаются перекосы, когда аналитик начинает указывать разработчику, что ему сделать и иногда (где-то компании такое позволяют) порывается написать код за него. Или начинает писать ТЗ так, что оно понятно только разработчикам, но никому из коллег. Или получает доступ к коду, начинает сам в нем копаться и искать ответы на вопросы, что обычно приводит к огромным ошибкам а-ля "я посмотрел, тут вот так реализовано", что используется для дальнейших постановок задач, и запускает долгую цепочку ошибок.
В общем, считаю, что уметь кодить совсем не обязательно, но, если ты уж это умеешь, нужно уметь вовремя себя остановить и оставить работу с кодом людям, у которых это основная обязанность. И мне смешно и грустно за компании, которые в вакансиях пишут "уверенное знание С++, PHP, Scala" и на вопрос "зачем?" отвечают "чтобы понимать разработчиков лучше".
Вы как думаете?
✅согласен с постом
⛔️ должен уметь кодить, даже если ему это не нужно в работе
Я несколько раз тестировала в паре, чтобы ввести человека в новый проект. Сначала я вела пару сессий, объясняя что я делаю и откуда все взялось. Потом пару сессия была в качестве штурмана. Это был интересный опыт и я думаю, что он помог.
#заметки_с_полей
#заметки_с_полей
Forwarded from QA Календарь
А вы тестировали в паре? В статье ноября две Оли рассказывают о задачах, которые им помогает решить эта практика, и приводят пример её неудачного использования. Приятного прочтения :)
https://habr.com/company/skbkontur/blog/431460/
https://habr.com/company/skbkontur/blog/431460/
Хабр
«Календарь тестировщика» за ноябрь. Разумное парное тестирование
Авторами ноябрьского «Календаря тестировщика» стали Оля Фазулзянова, тестировщик Контур.Экстерна, и Оля Изюрьева, тестировщик Контур.Биллинга и организатор курса...
Полезная мнемоника от Джеймса Баха в переводе Ольги Назиной - http://okiseleva.blogspot.com/2018/11/sfpdo-san-francisco-depot-james-bach.html
#база_тестирования
#база_тестирования
Blogspot
SFPDO (San Francisco Depot) — мнемоника от James Bach
Оригинал статьи — http://www.satisfice.com/articles/sfdpo.shtml . Сразу оговорюсь, что не ставила себе цели точного перевода всей статьи...
http://wolonter.blogspot.com/2018/11/edi.html
Мне очень отзывается то, о чем пишет Макс. Все люди рано или поздно уходят из команды - и как сделать так, чтобы это не стало большой проблемой для команды. И как сохранить отношения с людьми.
#менеджерское
Мне очень отзывается то, о чем пишет Макс. Все люди рано или поздно уходят из команды - и как сделать так, чтобы это не стало большой проблемой для команды. И как сохранить отношения с людьми.
#менеджерское
Blogspot
Когда и как нужно уходить из команды
Блог о тестировании вообще и обо мне в частности. Хроники тестировщика.
Видела вчера вариант шутки "QA Engineer walks into a bar. Orders a beer. Orders 0 beers..."
QA Engineer walks into a bar. Orders a beer. Orders 0 beers. Orders 999999999 beers. Orders a lizard. Orders -1 beers. Orders a ueicbksjdhd.
First real customer walks in and asks where the bathroom is. The bar bursts into flames, killing everyone.
И если первая еще более-менее смешная и описывает одну из техних тест-анализа, то эта уже нет. Она сводит работу тестировщика только к поиску багов, в то время как реальные пользователи ведут себя по-разному.
На самом деле мы как тестировщики обычно начинаем с того, как пользователи будут применять наш продукт.
Я бы перефразировала этот анекдот на русском так.
Тестировщица заходит в бар. Заказывает 1 кружку пива. Заказывает 1 кружку безалкогольного пива. Заказывает 1 бутылку воды. Заказывает 1 стакан чая. Заказывает 1 стакан кофе. Заказывает еду здесь. Заказывает еду на вынос. Спрашивает, где находится туалет. Просит сделать музыку тише. Спрашивает бармена "за жизнь".
#подпольный_евангелизм
QA Engineer walks into a bar. Orders a beer. Orders 0 beers. Orders 999999999 beers. Orders a lizard. Orders -1 beers. Orders a ueicbksjdhd.
First real customer walks in and asks where the bathroom is. The bar bursts into flames, killing everyone.
И если первая еще более-менее смешная и описывает одну из техних тест-анализа, то эта уже нет. Она сводит работу тестировщика только к поиску багов, в то время как реальные пользователи ведут себя по-разному.
На самом деле мы как тестировщики обычно начинаем с того, как пользователи будут применять наш продукт.
Я бы перефразировала этот анекдот на русском так.
Тестировщица заходит в бар. Заказывает 1 кружку пива. Заказывает 1 кружку безалкогольного пива. Заказывает 1 бутылку воды. Заказывает 1 стакан чая. Заказывает 1 стакан кофе. Заказывает еду здесь. Заказывает еду на вынос. Спрашивает, где находится туалет. Просит сделать музыку тише. Спрашивает бармена "за жизнь".
#подпольный_евангелизм
Читатели дополняют, что надо еще добавить "соблазняет бармена", "напивается", "громит кабак" и "выходит из бара" )
#подпольный_евангелизм
#подпольный_евангелизм
И еще добавляют - "Для бара еще не помешает проверить "хватает денег заплатить", "не хватает денег" и оплату картой/наличкой". Сейчас мы коллективно составим идеальный сценарий проверки бара)
Я тут думаю, что я бы еще проверила оплату мобильными приложениями)
#подпольный_евангелизм
Я тут думаю, что я бы еще проверила оплату мобильными приложениями)
#подпольный_евангелизм