Тестирование и жизнь
3.46K subscribers
86 photos
3 videos
6 files
733 links
Тестирование не то, чем кажется

Все про людей и их работу в этом вашем айти. И про жизнь вокруг

Поговорить в личку - @red_foks

Не размещаю рекламу.
Download Telegram
TeamLead Conf проводят митап про декрет и совмещение материнства и карьеры. И не так важно о чем конкретно будет говорить спикерка. Меня радует сам факт того, что это обсуждают в среде тимлидов в IT.

Глядишь и доживем до выступлений про онбординг сотрудников после декрета.

#diversity
#women_in_tech
Forwarded from Вычитала
В чатике показали статью про то, как корпорации пробуют казаться семьей, но выгодно по факту это только одной стороне:

I used to be a Google engineer. That often feels like the defining fact about my life. When I joined the company after college in 2015, it was at the start of a multiyear reign atop Forbes’s list of best workplaces.

I bought into the Google dream completely. In high school, I spent time homeless and in foster care, and was often ostracized for being nerdy. I longed for the prestige of a blue-chip job, the security it would bring and a collegial environment where I would work alongside people as driven as I was.

What I found was a surrogate family. During the week, I ate all my meals at the office. I went to the Google doctor and the Google gym. My colleagues and I piled into Airbnbs on business trips, played volleyball in Maui after a big product launch and even spent weekends together.

The company anticipated our every need — nap pods, massage chairs, Q-Tips in the bathroom, a shuttle system to compensate for the Bay Area’s dysfunctional public transportation — until the outside world began to seem hostile. Google was the Garden of Eden; I lived in fear of being cast out.

I’d structured my life around my job — exactly what they wanted me to do — but that only made the fallout worse when I learned that the workplace that I cherished considered me just an employee, one of many and disposable.

Now I see that my judgment was clouded, but after years of idolizing my workplace, I couldn’t imagine life beyond its walls.

After I quit, I promised myself to never love a job again. Not in the way I loved Google. Not with the devotion businesses wish to inspire when they provide for employees’ most basic needs like food and health care and belonging. No publicly traded company is a family. I fell for the fantasy that it could be.

So I took a role at a firm to which I felt no emotional attachment. I like my colleagues, but I’ve never met them in person. I found my own doctor; I cook my own food. When people ask me how I feel about my new position, I shrug: It’s a job.

https://www.nytimes.com/2021/04/07/opinion/google-job-harassment.html

#некниги
И в эту же тему выпуск подкаста Леночки.

Как работа мечты делает все, чтобы замкнуть сотрудника на себя. И становится важной частью идентичности.

#тлен_и_усталость
Тестирование и жизнь
В чатике показали статью про то, как корпорации пробуют казаться семьей, но выгодно по факту это только одной стороне: I used to be a Google engineer. That often feels like the defining fact about my life. When I joined the company after college in 2015,…
И если авторка искала в Google семью, то я в своей первой работе мечты искала принятия группы.

Всего того, что мне так отчаянно не хватало в школе, а потом и в студенчестве. Вместе делать интересное, вместе думать, чтобы меня видели и слышали. Чтобы принимали меня неидеальную. Чтобы ценили меня за то, что я делаю действительно хорошо и хочу делать еще лучше.

#тлен_и_усталость
"Мы все одна семья!"

И почему это не так.

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

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

Почему плохо быть семьёй на работе?

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

Люди, оперирующие метафорой семьи, будут приносить свой опыт дисфункциональной семьи в корпоративную структуру. Условный "батя" будет стучать кулаком по столу и орать "Будет так, как я сказал!", а условная "мама" будет стоять у тебя над душой и спрашивать раз в 10 минут "Ну что там, готово уже? Ну что ты такая растеряша, вон Петя уже всё сделал и сидит второе задание ждёт."

Кроме того, в реальной семье есть иерархия. И, если вы не учредители, вы автоматически попадаете в статус "детей" с соответствующим к вам отношением сверху вниз. Только ответственность у вас остаётся взрослая. Нужно ли упоминать чем грозит такой дисбаланс возможностей и ответственности? Можно сказать, что в реальной корпорации тоже есть иерархия, так и в чём же тогда отличие. Оно в том, что субординация не означает автоматически "отсутствие рычагов управления снизу". Здесь нормально требовать к себе уважительного отношения, вы можете 24/7 чувствовать себя взрослым дееспособным человеком. С вами, вон, и договор трудовой заключили, и что-то вам по нему оказались должны.

От корпоративных "родственников" также часто требуется, чтобы они не разделяли "своё" и "чужое", ведь у нас всё "общее". От них требуется регулярно забывать о том, что у них есть ещё своя реальная семья, своё реальное личное время. Есть одна светлая цель и мы к ней сообща движемся. Иногда движемся прямо по трупам "двоюродных тётушек" и "сестёр" с "братьями", они пали во имя цели, отчего она стала только более значимой. Их жертва не должна быть напрасной!

Как это проявляется в реальной жизни? Чаще всего вам постоянно про это говорят. Мы семья и поэтому мы то... мы семья и поэтому мы сё...
И вот вы уже пугаетесь, что вы не можете уйти в отпуск, потому что как же тут ваша "семья" без вас. Или боитесь задать вопрос, ведь "папа" может выйти из себя, а мы тут делаем то, что "папа" сказал. Кроме того, из "семьи" нельзя уволиться по тем же самым причинам. Поэтому градус неадеквата в корпорациях-семьях может расти практически неограниченно.

Самое интересное в метафоре семьи — это то как она попадает в сокровенную ценность почти каждого человека. Это такая ценность, которую не принято оспаривать, ей не принято даже задавать вопросы. "Семья — это святое" это, в общем, первое, что на ум приходит, когда думаешь про смысл понятия "семья". Поэтому так сложно бывает стряхнуть с себя это зачарование.

Так вот. Корпорация — это не семья. У корпорации есть на вас совершенно определённые планы. И как только вы перестанете приносить пользу, вы перестанете быть "родственницей", и вас заменят на другого человека. И это не хорошо и не плохо, это просто суть корпорации. То есть организации, которая создавалась для того, чтобы приносить учредителям прибыль. Это нужно просто всегда помнить, держать в уме на случай важных переговоров.

Когда вы слышите от учредителей "Мы сейчас должны все вместе поднажать, мы тут сами не спали неделю, чтобы мы шли в светлое будущее, мы ждём от вас того же самого, ведь мы одна семья". Посмотрите на учредителей, потом на свой банковский счёт, потом снова на учредителей, потом снова на банковский счёт. Если на счёте ни разу не появлялись проценты от прибыли вашей "семьи", если вы не можете позвонить ночью СЕО Марии Ивановне и сказать ей "Мама, мне нужна твоя помощь", то это не ваша семья.

#psy
Forwarded from Shoo and Endless Agony (Shoo)
Что такое "хорошо"?

Какое-то время назад я писал пост, главной мыслью которого было "сначала делай самое простое решение, потом улучшай".
Вопросы по этому поводу всплывали в ходе менторства и уже несколько раз мне писали в личку с вопросами про то,
зачем хорошим инженерам делать "плохие" решение и размышлениями о том, что костыль, воткнутный однажды в код останется там навсегда.
Поэтому держите немного моих размышлений на эту тему.

Первое - "простое" не значит "плохое".
Это далеко не всегда костыль, говнокод и некачественная работа.
Это просто самый примитивный способ решения поставленной задачи, без усложнений, оптимизации и всяческой красоты.
При выборе алгоритма для решения задач ты всегда начинаешь с "наивного" алгоритма - самого простого и очевидного способа решить задачу.
Затем, шаг за шагом, оптимизируешь его и усложняешь исходя из потребностей и условий задачи.
Самое важное в этом процессе то, что после каждого шага у тебя остается решение, которое работает.
У тебя всегда есть возможность сравнить, чем новая версия лучше предыдущей и возможность остановиться, если дальнейшие шаги не работают.
Если ты сразу берешься за создание "идеального" алгоритма - у тебя нет ни того, ни другого.

Второе - это глобальный вопрос про то, что же такое "хорошее" решение и чем оно отличается от "плохого".
Есть люди, которым нравится думать, что программирование - это искусство.
Они хотят писать чистый, красивый и оптимизированный код, использовать интересные и элегантные решения и делать "правильно".
Потому что могут. Потому что это "правильно", красиво, классно.
Но проблема в том, что разработка ПО - не про это. Она про то, что бы используя инженерные навыки решать задачи и потребности бизнеса.
И это, на самом деле, гораздо сложнее.
Искусство существует вне ограничений.
Ты можешь двигать дедлайны, переписывать всё с нуля,
использовать какой хочешь стэк технологий, забить на документацию и писать красивый код ради красивого кода.
Инженерные задачи, в свою очередь, существуют в пространстве ограничений.
Вот тут у тебя - куча легаси в продакшене, эта задача нужна ещё вчера, а ещё тебе надо будет потом нанимать людей на поддержку всего этого, так что лучше всё таки не использовать Nim, даже если он тебе очень нравится.
Хорошим решением становится то, которое позволяет потратить меньше всего ресурсов, максимально эффективно при этом закрыв потребность бизнеса.
Писать красивый, оптимизированный и расширяемый код, когда ни одно из этих качеств не нужно - настолько же плохое решение, как и выкатывать хреново оптимизированный код, когда от него требуется производительность.

Третье - про костыли, антипаттерны и следование best practices.
Костыли, хардкод и god-object'ы не являются злом сами по себе.
Они могут генерировать риски и технический долг.
Этот код может работать менее стабильно, его может быть сложнее расширять и поддерживать.
Всё это сводится к тому, что потом тебе может понадобиться потратить больше времени на рефакторинг, разработку последующих фичей и ночные хотфиксы.
Ну, или в то, что баг в продакшене будет стоить компании кучу денег.
При этом выбор между "правильно" и "костыльно" всегда является решением о том, нужно ли тратить ресурсы на то, что бы закрыть эти риски и технический долг сейчас,
или лучше отложить это на потом.
Здесь и проявляется то, что отличает действительно хорошего специалиста.
Способность адекватно оценить последствия каждого из вариантов, донести их до команды и бизнеса и способность вместе принять взвешенное решение.
Перекос в любую сторону, будь то "всегда втыкать костыли" или "всегда писать чистый код" - одинаково вредны.

В общем, будьте молодцами, решайте задачи бизнеса, учитесь доносить информацию до коллег, вместе принимать взвешенные решения и помните, что техническая реализация - это инструмент, а не цель.
Forwarded from Olena Kirichok's tech
Все мы привыкли, что до недавнего времени всех программисты в фильмах и сериалах, это интроверты, которые знают ту самую истину, и через консоль могут починить серверы пентагона, или сломать.

И я счастлива замечать как эти стериотипы меняются, или хотя бы немного подстраиваются под современные реалии. Будь это стартап, или продуктовая компания с большим опытом, техническая команда уже будет отличаться по составу, чем 5-10 лет назад. И для этого делается колосальная работа.

Так вот, я пришла к вам с сериалом "Необыкновенный плейлист Зои", который мне посоветовала моя сестра, и он про жизнь американской разработчицы Зои Кларк, и ее суперспособность. Это мюзикл, поэтому на любителей (знаю, что не все любят их), при этом и комедия и драма. В течении двух сезонов Зои растет по карьерной лестнице в своей компании, сталкивается с разными трудностями на пути, как профессиональными так и личными.

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

Если вам все подходит по описанию, очень рекомендую посмотреть.

Смотрели уже этот сериал? Поделитесь какие вы рекомендуете сериалы на около айти тематику в комментариях?
Посмотрела первый сезон на одном дыхании. И он больше все-таки о жизни, чем о работе. Особенно меня пробрала тема про умирающего отца и работу горя.

Хотя про работу тоже есть интересное - и как программистка становится тимлидкой, и как она пытается наладить контакт с командой, и про отношения и границы с собственной начальницей. Мне было о чем подумать.

Ну и музыку я люблю)

#менеджерское
#diversity
#women_in_tech
Я и не подозревал о существовании такой штуки, как Руководство по стилю SQL от Саймона Холивелла https://www.sqlstyle.guide/ - странице, объединяющей различные рекомендации по именованию таблиц, столбцов, хранимых процедур, алиасов и оформлению SQL-запросов

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

В пятницу послушала доклад Наталии Савастюк Как формулировать вопросы, чтобы оценивать глубину знания на SQA Days. Он был посвящен тому, как на основе таксономии Блума строить вопросы на собеседованиях.

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

⁃ Есть два подхода к обучению: Higher-Order Thinking Skills и Low-Order Thinking Skills. Первые — это навыки мышления высшего порядка, такие как анализ, синтез, оценка и критическое мышление. Считается, что учащиеся должны овладеть навыками более низкого уровня, прежде чем они смогут заниматься навыками более высокого порядка.
⁃ В основе подхода лежит таксономия Блума. Он разбил все знания на уровни глубины освоения.
⁃ На первом уровне есть только фактические знания. На втором понимание, на третьем превращение в практический опыт, применение, далее идёт анализ, когда знание распадается на составляющие, и на самом высоком уровне идут анализ, оценка и создание нового.

Как применить это при собеседовании в тестирование? Любой вопрос можно углубить в зависимости от целей.
Например, есть уровни:
⁃ Могу рассказать, что это;
⁃ Могу рассказать своими словами и привести пример;
⁃ Могу спроектировать и выполнить, использовать на практике в новых условиях;
⁃ Понимаю причинно-следственные связи, как связаны одно действие и другое, могу систематизировать проблемы;
⁃ Могу комбинировать знания между собой и придумывать автоматические проверки;
⁃ Могу обучать других.

Далее в докладе разбирались конкретные вопросы с собеседований и как можно их перевести на другой уровень.

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

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

Ссылка на слайды
Документ достижений и хвастовства

Пару месяцев назад я услышала в подкасте devzen про brag document.

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

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

Раньше я не понимала, зачем мне это делать. Ведь эти достижения я и так признаю в моменте и праздную. Но потом я поняла, что забываю — и сами факты, и детали. Так, я весьма смутно помню баг, который я локализовала пару недель и очень гордилась, что нашла. Это было несколько лет назад и сейчас у меня остались скорее впечатления, чем факты.

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

#тлен_и_усталость
#менеджерское
Лену я знаю еще со старших классов школы и делюсь ее интервью.

Она рассказывает про свой путь в программирование и затем в менеджмент. Ну и про технические вещи - GO и Кубернетис.

Отдельно мне отзывается история Лены про ее менеджерский фейл.

#women_in_tech
#diversity
Forwarded from Протестировал (Sergey Bronnikov)
Считается, что дочь английского поэта и лорда Джорджа Байрона Ада Лавлейс была первым программистом. В 1842 – 1843 годах, Ада занималась переводом с французского лекции Бэббиджа об аналитической машине. К переводу прилагались заметки Лавлейс, причем они были в 3 раза больше статьи. Один из комментариев Ады подробно описывал алгоритм, по которому на аналитической машине можно было вычислить числа Бернулли. В дальнейшем эту работу признали первой программой, возможной к воспроизведению на компьютере, несмотря на то, что машина Бэббиджа так и не была сконструирована при жизни Ады. На приаттаченной картинке изображена диаграмма для вычисления числа Бернулли. И в это диаграмме есть баг, который заключается в том, что перепутаны местами делимое и делитель (v4/v5 -> v5/v4). Если это не опечатка, которую сделали в типографии, то это самый старый баг в истории вычислительной техники. Нагуглить рукописные заметки Ады , чтобы это проверить, сходу не получилось.

via
Поиск бага как поиск носка - занятная метафора от Кристин Джеквони. В каких случаях стоит локализовывать проблему сразу, а когда можно отложить это на потом.

#записная_книжка
#база_тестирования
Languishing, Corona-Erschöpfung или дать имя чувству

В ноябре прошлого года я прочитала статью в Krautreporter про усталость от пандемии. Особенно в Германии с их локдаунами и ограничениями.

Я помню как себя чувствовала прошлой весной и летом — тягостное ощущение того, что время остановилось и тянется. Вроде и силы есть, но сложно сконцентрироваться на чем-то. Особенно, когда нельзя было свободно гулять.

Для меня это чувство было - «тлен».

А сейчас в NY пишут про это как Languishing. Что-то среднее между депрессией и выгоранием. Как антидот этого состояния автор предлагает поток — что-то, что увлечет и на чем можно будет сконцентрироваться.

Но уже признание этого чувства помогает.

#тлен_и_усталость
#deutsch
Forwarded from Olena Kirichok's tech
Супер познавательное и мотивирующее интервью с Ларисой Агарковой Staff Software Engineer в Google вышло на канале АйтиБорода.
Я знаю про Ларису уже год, с интервью с ней на канале Виктории Бородиной, но в этом интервью я узнала еще больше информации о ней.

Лариса родом с Беларуси, училась в Чехии, и начала работу в Google cо стажировки, которая к слову была ее не первой стажировкой.
Она делится тем, что делает Staff Software Engineer в Google и почему эта должность так называется, как она проходила интервью и как переходила на уровни.

Мне близко то, что Лариса еще с времен лицея искала то, что ей ближе, химия или математика, программирование или маркетинг, ее взгляды на жизнь и на Кремниевую Долину.

В начале видео есть фраза: “Если девочка, которая первые два года пекла мальчикам в университете пирожки, смогла попасть в Google, то и вы сможете”, для меня крутая тем, что все возможно, несмотря на ваш предыдущий опыт. Это и показывает Лариса на своем примере.

Я посмотрела интервью на одном дыхании и надеюсь, что большие технические блоги все таки будут приглашать больше женщин на интревью, и мы будем больше узнавать о крутых айтишницах.
This media is not supported in your browser
VIEW IN TELEGRAM
Эту картинку я утащил из заметки Gregor Hohpe Thinking Like An Architect Part 2: Architects See More Dimensions и вспоминаю её всякий раз во время жарких дискуссий в соц.сетях.

Смотрите какая штука. В средневековье приверженцев гелиоцентрической системы принято было жечь на кострах. Но это не значит, что гелиоцентрическая система на сегодня является единственно верной, а геоцентрическая ошибочной. Обе модели равноценны, даже если школьная физичка пыталась вас в этом разубедить. Большая, чем у Земли, масса Солнца не является окончательным и бесповоротным основанием прикрепить к нему систему координат. Вы, по-прежнему, можете использовать геоцентрическую модель совершенно не опасаясь никаких порицаний.

Если же ваш оппонент считает вас идиотом, из-за того, что вы не разделяете его истинное и научное убеждение о вращении Земли и других планет нашей системы вокруг Солнца, то это исключительно его проблема. (Кстати, можете упомянуть, что одна из планет солнечной системы вращается не вокруг Солнца)
Маскулинная организационная культура

Работа важнее личной жизни? На работе нельзя ошибаться? Везде и всегда соревнования? Нужно быть быстрее, выше, сильнее? Думаю, что многим, особенно в больших городах, чертовски знакома эта культура.

Исследователи не остались в стороне, и начали изучать этот феномен в гендерном ключе – Masculinity contest culture (MCC). Под этим понимают набор организационных норм, практик и ценностей, которые вознаграждают бесконечную борьбу за власть, силу и статус. Эта культура включает четыре аспекта: (1) не проявлять слабости (прилагать усилия, чтобы выглядеть компетентным), (2) сила и выносливость (подчеркивая физическую силу и статус), (3) ставить работу на первое место (отдавать предпочтение работе над другими сферами жизни) и (4) человек человеку волк (яростно соревноваться с коллегами).

В 2018 году в Journal of Social Issues даже вышел интересный специальный выпуск, посвященный Work as Masculinity Contest. Исследования, включенные в этот специальный выпуск, показали следующее:

1. Желание утвердить свой маскулинный статус в ответ на prototypicality threat (угроза быть воспринятым как женщина) связано с сексуальным харассментом одних мужчин в сторону других (male-male sex-based harassment). И этот эффект оказался сильнее в masculinity contest culture.

2. Masculinity contest culture является почвой для toxic leadership (руководитель приписывает все заслуги себе, ведет себя агрессивно, и т.д.) в организации. Исследовали обнаружили сильную корреляцию, что чем выше сотрудники оценивали свое рабочее место по MCC, тем чаще они сообщали, что их непосредственный руководитель проявляет токсичное лидерское поведение. Кроме того, сотрудники в таких организациях с токсичными лидерами демонстрировали более высокий уровень стресса, конфликта между работой и личной жизнью и намерение искать работу наряду с более низким уровнем вовлеченности и восприятии смысла в работе. Интересно, что дополнительный анализ показал, что значительный рост восприятия смысла в работе и тенденция к увеличению вовлеченности произошли среди мужчин (но не женщин), которые рассматривали свое рабочее место как MCC и сообщали о токсичных лидерах.

3. Мужчины склонны поддерживать и участвовать в MCC не без помощи веры в игру с нулевой суммой, исходя из которой успешные женщины в такой среде рассматриваются как нарушители, стремящиеся завладеть ресурсами мужчин. Иными словами, культура “выиграй или умри” может хорошо соседствовать с верой в игру с нулевой суммой, где другие люди – соперники, которые хотят заполучить твои ресурсы.

4. Исследователи также обнаружили то, что называется Pluralistic Ignorance. Люди верят, что их коллеги поддерживают Masculinity contest culture в большей степени, чем они. Следовательно, желая вписаться в культуру, люди начинают преувеличивать свою собственную поддержку MCC как на словах, так и в действиях. В итоге, MCC, конечно, никуда не девается.

В более свежем исследовании, авторы показали, что MCC является барьером для удовлетворения одной из важных базовых потребностей людей – потребности в принадлежности. В результате, сотрудники реагируют путем сокращения степени своей идентификации с организацией. Это значит, что сотрудники будут в меньшей степени заинтересованы, чтобы работать на благо организации.

В качестве возможной альтернативы MCC предлагается Feminine nurturing culture (FNC). Она представляет собой рабочее место с противоположными качествами MCC, такими как ценность баланса между работой и личной жизнью, поощрение сотрудничества, демонстрация уязвимостей и признание слабостей. Но альтернатива пока только теоретическая, и авторы призывают протестировать, насколько она рабочая. Хотя пандемия, кажется, как раз уже показала, что сотрудничество, а не конкуренция, лучше помогает достигать результатов (по крайней мере, во время кризиса).

Я не сторонник жесткого противопоставления. Мол, давайте взамен MCC создаим FNC, и все будет чудесно. Мне в это слабо верится, потому что доведенная до предела забота может быть дисфункциональна ровно так же, как и соревновательность. Выход, думаю, в гибкости.
Комментарии в канале

Давным-давно я специально выбрала телеграм как площадку, где нет комментариев.

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

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

Поэтому с этого поста тут будут еще и комментарии.