Александр Александров про тренды и технологии тестирования, про влияние Covid19 на рынок QA

Сильные сотрудники – большое преимущество для компании.

Интервью, с Александром Александровым – экспертом компании Performance Lab, членом коллегии RSTQB – Российской ветви международной организация по сертификации тестировщиков программного обеспечения.

Эксперт компании Перфоманс Лаб

– Вы занимаетесь тестированием почти 50 лет, Вас называют «дедушкой русского тестирования». В чем вы видите современную роль QA? Чем является для Вас тестирование сейчас? – Как изменилось тестирование за последний год?

До сих пор многие по-прежнему считают, что:

Тестировщики отвечают за качество, хотя цель тестирования – дать объективную оценку качества разрабатываемого и поставляемого продукта
Тестировать надо против требований, хотя есть неявные требования, а в требованиях бывают ошибки
Серьезность дефекта можно устанавливать «по договоренности», а не на основании согласованной всеми классификации
Метрики тестирования, статическое тестирование, модульное тестирование – без всего этого можно обойтись
Если каждую функцию можно протестировать отдельно, они прекрасно будут работать вместе
Документацию тестировать не надо, главное – протестировать систему
Никаких рисков в тестировании нет и быть не может
Любой может работать тестировщиком – знать и уметь для этого ничего не надо
Тестовые сценарии – это излишество, в крайнем случае, используются чек-листы
Если все тестовые сценарии перестали обнаруживать дефекты, тестирование закончено
Тестовые сценарии должны быть понятны только их авторам
Автоматизация всех ручных тестовых сценариев – это круто!
А автоматизация вообще без тестовых сценариев – это супер-пупер-круто!
Если автоматизировать регрессионное тестирование, можно найти гораздо больше дефектов

– Как Вы относитесь к автоматизации тестирования?

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

Есть ситуации, где автоматизация вряд ли заменит опытного специалиста. Прежде всего, это тестдизайн – самая творческая и самая трудная часть процесса тестирования. Затем поиск дефектов «вокруг» найденного – ведь дефекты как грибы – в одиночку не появляются. Назовите хоть одну систему автоматизированного тестирования, которая умеет это делать? Можно еще много ситуаций привести, когда ручное тестирование выгодней автоматизированного. Конечно, обязательно надо иметь в виду возврат инвестиций, экономическую составляющую процесса тестирования.

– А к гибким (Agile) методологиям? – Известно, что пандемия Covid-19 повлияла и на отечественный рынок тестирования. В связи с этим у многих компаний обострились экономические проблемы. Выше Вы упомянули экономическую составляющую процесса тестирования. Что это такое и как это связано с экономикой вообще?

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

Разработчики могут ответить на вопрос «Сколько нужно времени, чтобы всё запрограммировать?» – например, два с половиной месяца. А почему? А потому, что там 18 функций, и в среднем на одну понадобится 3 дня. А сколько времени нужно тестировщику, чтобы найти все дефекты? А сколько времени нужно тестировщику, чтобы написать все тестовые сценарии? А скольковремени нужно тестировщику, чтобы проверить всю функциональность? Ведь исчерпывающее тестирование невозможно. Значит, мы должны говорить о том, когда мы прекращаем тестирование и почему мы его прекращаем. И эти критерии должны быть как технологическими, так и экономическими.

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

Инвестиции в трудозатраты должны возвращаться (ROI) качеством объекта тестирования. Мы знаем, на что мы должны потратить время и деньги – мы должны привлечь в проект людей определённой квалификации, платить за инструменты автоматизации и так далее. Мы должны инвестировать в тестирование, в том числе и в трудозатраты. Но любой инвестор спросит, что он получит взамен. А что мы можем предоставить взамен? Только качество.

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

– Конечно, легко. Вопрос в том, каким тестировщиком.

Я много раз говорил и писал про «моду» и «пену», аналоги Курниковой, Волочковой и Баскова в тестировании, про то, что легче говорить о профессии, чем работать в ней. В качестве авторитетов могу сослаться на Рекса Блэка – специалиста мирового уровня.

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

К сожалению, можно встретить огромное количество публикаций об успешном построении процессов тестирования с нуля, руководстве проектами тестирования, группами тестирования, при этом инженерная квалификация авторов, мягко говоря, на уровне плинтуса.

Стать недотестировщиком и выдавать себя за тестировщика в кругу таких же недотестировшиков – просто.

Стать специалистом в любой области (не только тестировании) – сложно и долго.

– Что важнее для компании – человеческие ресурсы или процессы?

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

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

– На Ваш взгляд, слабость каких процессных компонентов типична в этом году?

– Я бы назвал две – unit (модульное) тестирование и статическое тестирование (рецензирование) требований и спецификаций. Они, безусловно, разные. Однако их, к сожалению, объединяет общая тенденция. Это позднее обнаружение (и, как следствие, исправление) дефектов.

Дефекты, которые могли бы быть обнаружены во время unit-тестирования, должны обнаруживаться во время системного тестирования. Представьте, что в сложной программе надо обнаружить утечку память в единственном модуле. Во время unit-тестирования такая задача решается гораздо проще и быстрее, чем во время системного тестирования.

Про дефекты в требованиях, обнаруживающиеся во время системного тестирования, я уже и не говорю – сколько копий на эту темы было сломано, а воз и ныне там.

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

Поделиться ссылкой:

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

Насколько безопасно ваше ПО? Легко ли его взломать? Это очень важный вопрос, если приложение работает с персональными данными или деньгами.

Периодически всплывают сайты из серии «введи свой емейл и мы скажем твой пароль, ведь мы взломали большую базу, аха-ха». Если ваш пароль и правда взломали — значит, злоумышленник обнаружил дыру в безопасности.

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

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

Способы взлома

Брутфорсинг

Полный перебор (или метод «грубой силы», англ. brute force) — это когда мы пытаемся подобрать данные, перебрав все возможные варианты.

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

Думаете, что это все фигня и от этого давно есть защита? Пожалуйста, недавняя статья.

В результате выявления уязвимости веб-ресурса ликвидированного Бинбанка персональные данные граждан, направляемые кредитной организации при запросе на выдачу кредита или карты, оказались в открытом доступе, сообщает «Коммерсант».

В понедельник компания DeviceLock сообщила о выявленной утечке данных клиентов-физлиц, подававших заявки на получение кредитной карты Бинбанка «Эlixir», которые не находятся в открытом доступе, однако извлечь их можно методом подбора буквенно-цифровых сочетаний, поясняется в сообщении компании.

По словам основателя DeviceLock Ашота Оганесяна, в настоящее время известно, что уже найдено более 1 тыс. анкет, однако при помощи автоматизированного перебора возможно получить все заявки, а их могут быть десятки или даже сотни тысяч. Также велика вероятность подобных проблем и в других банках, использовавших то же решение для системы безопасности.

Как напомнил вице-президент группы компаний InfoWatch Рустем Хайретдинов, схожая публичная история была в 2015 году с банком «Санкт-Петербург», когда злоумышленники также получили доступ к данным клиентов, после чего банк пересмотрел свой взгляд на безопасность. Руководитель группы исследований безопасности банковских систем Positive Technologies Ярослав Бабин сообщил, что очевидно также отсутствие защиты от атаки перебором.

Если говорить про линукс-сервер, то их пытаются взломать перебором IP-адресов. Ведь для IP-адресов есть какая-то определенная маска , и почти наверняка там будет root логин. А уж если IP известен, рута обязательно попробуют. Хотя бы «ламерским брутфорсом» — перебором типичных комбинаций типа:

root / root
root / admin
…

Ну а что, вполне может сработать, если админ не удосужился поставить нормальный пароль.

Когда я делала обучающие видосики и статьи по линуксу, то нашла облачный сервис, где можно взять в аренду линукс-сервер за 150р в месяц. И решила я для своей странички Test it купить такую машинку. Недорого же, почему бы и нет?

Оплатила сразу на несколько месяцев, создала тестового пользователя и радостно выставила в общий доступ. Потом, как ни зайду под рутом, вижу такого плана сообщения:

root@85.143.174.119's password:

Last failed login: Mon Jul 16 04:24:25 MSK 2018 from 198.98.48.103 on ssh:notty

There were 120 failed login attempts since the last successful login.

Last login: Sun Jul 15 11:33:27 2018 from 37.187.143.213

120 попыток взлома. Вот, казалось бы, зачем? А чтобы навредить. Потому что даже из-под открытого пользователя навредить умудрялись. Поработает сервер пару дней и мне приходит письма от админов «От вас идут попытки взлома, мы погасили машину».

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

Там админы какие-то вялые были, я им объясняю «это для открытого доступа, я сделала то и то, скажите как еще можно защититься», ноль эмоций. Сама думай. В итоге надоело и я перестала оплачивать сервер. Не знаю, может, снова подниму, но уже на другой платформе, где админы помогают, а не все на тебя перевешивают.

В любом случае, если вы где-то засветили IP-адрес, намеренно или нет, ждите атаки на рута, перебирать пароли для него в любом случае будут.

Перехват трафика

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

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

SQL-инъекции

Это когда вы передаете вместо нормального параметра SQL-запрос. Если приложение уязвимо, можно сделать много плохого.

Самая типичная инъекция — ввести в поле одинарную кавычку и за ней какой-то запрос. Вот как на рисунке, только с паролем. Логин админа то обычно стандартный — admin или administrator, а в пароле пишем любой пароль, а потом «ИЛИ 1=1». Пароль не подошел, но 1 = 1, возвращается true → и вот мы уже вошли в систему!

Или вот знаменитая картинка-мем про инъекции:

Межсайтовый скриптинг — это когда вы внедряете в код страницы вредоносный код.

Например, у вас есть поле ввода — имя в профиле. Разработчик не защитил это поле и позволил вводить все, что угодно.

И вот я могу туда ввести:

Маша <script>alert("Я ТЕБЯ СЛОМАЛ АХАХА")</script>

Что в итоге? Как только я сохраню изменения, то увижу поп-ап с текстом «Я ТЕБЯ СЛОМАЛ АХАХА»

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

Поэтому можете использовать лайт проверку из примера выше с алертом. Если алерт вызвался — бейте тревогу. Ну а как можно навредить такими атаками — изучите в гугле =)

Что-то более умное

Так как я не умею взламывать, то и научить этому не могу. Про простые атаки знаю, но наверняка есть что-то более сложное и изощренное. Если интересует эта область — идите в тестирование безопасности, копайте и развивайтесь.

Хороший тестировщик безопасности и получает много. Рынок, правда, невелик. По крайней мере, требуются такие люди реже, чем простые тестировщики или автоматизаторы. Но хорошего с руками оторвут.

Истории взлома

Все ваши анализы в открытом доступе

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

Этот автор не в первый раз пишет про уязвимость медицинских данных. Другие его статьи на эту тему:

Мошенники вывели через сервис переводов Mastercard 9 млн рублей из-за ошибки в настройках банкоматов

Операции проводили с 15 по 19 мая 2018 года в банкоматах на железнодорожных вокзалах в Москве. Участники схемы выбирали опцию перевода денег с карт «Сбербанка» на карты «Тинькофф банка», но в последний момент отменяли операцию.

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

Ошибка в настройках заключалась в том, что банк — владелец банкомата считал, что операцию все ещё можно отменить, а банк получателя — что перевод уже отозвать нельзя. Мошенники отменяли операцию: сумма восстанавливалась на карте отправителя и одновременно проходил перевод. По правилам Mastercard для операций MoneySend банк получателя может не согласиться с отменой операции.

Продолжу хвастаться статусом книги.

Её уже сверстали! Я не везде осталась довольна версткой, потому что хочется больше пустого места (но оно же и дорого стоит). Однако надо отдать ребятам должное — это огромная работа! 585 страниц, и на каждой есть картинки, которые надо вписать в текст.

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

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

Заменить цвет легко можно только в фотошопе, если исходники оттуда. Но у меня было 10 разных художников, так что половину картинок пришлось переделывать. Причем в авральном режиме, потому что без "правильного черного" работа над книгой просто встала. А простой мы себе позволить не можем, так как у меня в декабре выступление в Костроме и нужны книжечки.

В общем, срочно срочно дорабатывали картинки, потом верстали. И вот я отправила замечания по верстке (только самые критичные), и буквально пару дней назад заапрувила правки. Уф! Теперь книгу вычитают корректоры и будем печатать!

• Забавное совпадение: предложение купить обновленную версию продукта одновременно с новостью об уязвимости в старой версии.

• Почему хуки – это лучшее что произошло в развиии React?

• Качество кода как путь к благоденствию компании в целом.

• История о том как охотник, преследующий фазана, приостановил работу софтверного гиганта.

• Обзор архитектуры Twitter, позволяющей обрабатывать миллионы событий в секунду и петабайт данных в день.

• От джуна до сеньора: опыт – сын ошибок трудных.

• Если баг не удается воспроизвести, давайте вооружимся против него до зубов.

• Тайное становится явным: чем вызвано появление загадочных слов в интерфейсе Azure DevOps?

• Аутентификация и авторизация в REST: несколько полезных советов.

• Вредные советы: как проводить собеседование на позицию разработчика.

• Да, здесь есть поле для улучшения: ответ, помеченный как наиболее полезный в StackOverflow, может устареть.

• Хочешь как лучше, а получается как всегда.

• Кардинальный совет: если не хочешь исправлять баги, не создавай их.

• Шестичасовой сбой в работе Facebook, WhatsApp, Instagram: осознание хрупкости наших коммуникаций и скупое описание разбора полетов. Вот подробности. И еще немного лирики.

• Будет ли приложение работать иначе при полной луне?

У природы нет плохой погоды.

I’m sticking with “bug” rather than adopt another word such as “fault,” which is the current fad in publications because:

(1) everybody knows what “bug” means;

(2) the standards are inconsistent with one another and with themselves in the definition of “fault,” “error,” and “failure”;

(3) according to the Oxford English Dictionary, the usage of “bug” the way we use it, contrary to popular belief, predates its entomological use by centuries—the first written reference to “bug” = “goblin” is from 1388 , but its first use to mean a small, six-legged creature with a hard carapace dates from 1642;

(4) I prefer short, strong, Anglo-Saxon words to effete Norman words. The genesis of “bug” as a computer problem being derived from a moth fried on the power bus of an early computer, thus bringing the system down, is apocryphal. “Bug” is an ancient and honorable word (Welsh bwg) and not newly coined jargon peculiar to the computer industry.

Software Testing Techniques, Second Editionby Boris Beizer (1990)

ISBN: 1850328803

Apocryphal — это от слова апо́криф (от др.-греч. «скрытый, сокровенный, тайный») — произведение религиозной литературы (иудейской и христианской), преимущественно посвящённое событиям и лицам ветхо- и новозаветной и церковной истории, не включённое в канон. Апокрифы являются запрещёнными для чтения в церкви. Чертей Клириков, которые используют их для чтения в общественном месте, полагается лишать сана.

С одной, непонятно какой именно стороны, можно посчитать заявление Бейзера заносчивым и пафосным.

С непонятно какой другой стороны, он был (1934-2018 же!) прав чуть более, чем полностью.

Оффлайн-конференция про автоматизацию для тестировщиков и им сочувствующих. Обсудим экономику CI, веб-тесты для интерфейсов со спиннерами, E2E-тестирование React-приложений, особенности тестирования платежей методом белого ящика и то, куда уходит время при организации тестирования.

Опытные тестировщики и разработчики из Контура, JetBrains, Qameta Software, Badoo и других компаний поделятся сложными кейсами, реальными историями, выработанными подходами и лучшими практиками.

Артем Ерошенко, Qameta Software
Женя Тихонов, Контур
Алексей Виноградов, Vinogradov IT-Beratung
Сергей Пак, JetBrains
Илья Кудинов, Badoo

Кроме докладчиков подготовлены движухи и в них всё как положено, от споров о том, кто должен писать тесты до непосредственно их озеленения.

Когда: в субботу 30 октября, 10:30, на весь день.

Конференция бесплатная, но количество мест ограничено.Зарегистрироваться.

Чтобы не пропустить новости и принимать участие в обсуждениях, подписывайтесь на канал.

По-дефолту звуки, которые издает Teams на смартфоне раздражают даже мëртвого Имхотепа — имхо, конечно, да кабы у него был смартфон, коий ему не дадут.

Их можно отключить ВООБЩЕ, но иногда таки надо получать сообщения из этой навязанной корпорациями шняжки, поэтому еë не заткнуть.

Но как тут поменять звук-то.

Очень неочевидное место и решение, но job is done, и пусть я не томат, но я очень рад.

Понравился текстовый редактор Sublime Text.

Раньше-то Eclipse был нашим всем, но на днях произошло неприятное: Eclipse падает всякий раз при копи/пэйст. Открыт соответствующий баг, решения пока нет, а между тем работать в Eclipse стало и решительно, и нерешительно невозможно. Вероятно, можно откатиться на более старые версии, но не факт, бо тогда и окружающие его пакеты тоже надо даунгрейдить, а это не тру.

Но под Linux есть много всяких IDE для разработки, даже есть почти нативное KDevelop. Из кроссплатформенных на слуху:

PyCharm от JetBrains — выглядит адекватно, но от него завыли кулеры и памяти поуменьшилось изрядно, при этом проект внутри ещё не создан. Нет.
Atom от GitHub, которое сегодня тоже от Microsoft. Построен на электроне, а это нет!
VS Code (он же Visual Studio Code) от Microsoft. Нет. от кого-то из гугла (Джон Скиннер). Слово sublime переводится как «возвышенный, величественный, высокий, грандиозный».

Тут и остановимся.

В основе своей Sublime Text разочаровывающе примитивный и требуется время на его освоение и настройку, но это и хорошо. Можно подключать к простой основе только те расширения, которые понадобятся в работе, а это unix way. У него много документации (unix way!)? Он в принципе хочет каких-то денег (not a unix way!), но не настойчиво да и не особо много, поэтому всё норм.

1Установка Sublime Text в Debian

Install the GPG key:

Ensure apt is set up to work with https sources:

Select the Stable channel to use:

Update apt sources and install Sublime Text

1.1Основная настройка Sublime Text

Для управления пакетами надо включить Package Control (инструкция):

Tools > Install Package Control…

1.2Расширение возможностей Sublime Text

Tools > Command Palette… (Ctrl+Shift+P)
Начать набор команды «install» > появятся подсказки > Выбрать «Package Control: Install package»
начать набор названия пакета, который надо установить > появятся подсказки > выбрать нужный и даблклик или Enter.

Restart Sublime Text.

1.3Тонкая настройка

каждого плагина Sublime Text по-отдельности займет некоторое время, но оно того стоит.

1.3.1Настройка темы

Пусть будет Adaptive.

Preferences > Customize Theme

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

Иногда эти файлы открываются поодиночке.

Например, впишем это.

1.3.2Настройка Anaconda

В Anaconda встроен довольно строгий линтер, он считает неправильными почти все строки любого кода (и он, конечно, прав), помечая их белыми прямоугольниками. Эту функциональность лучше передать отдельному плагину, бо лучше использовать линтер под свой язык программирования и строго под выбранные юзером правила правописания, которые под тот же Python бывают очень разные. Поэтому

Preferences > Package Settings > Anaconda > Setting — User

Этот файл пуст, можно прописать там и отключение линтера анаконды, и путь к рабочей версии Python:

Позже можно будет использовать возможности Anaconda для автоформатирования кода по CTRL-ALT-R (насколько это, конечно, применимо к тому же питону) в соответствии с правилами PEP8. Там тоже надо настраивать точнее, бо по-умолчанию эта шняга заменяет табы четырьмя пробелами.

View > Indentation > Tab Width: 4 //эту настройку в будущем уже не трогаем

View > Indentation > Convert Indentations to Tabs

В правом нижнем углу окна отображается эта же настройка ‘Tab Size: 4’.

Левомышечный клик по ней открывает то же самое меню, что из View. Остаётся кликнуть по последней команде: Convert Indentations to Tabs. Можно использовать каждый раз после CTRL-ALT-R.

Надо пореже использовать CTRL-ALT-R и воспитывать в пальцах изначально принудительное правописание и отступы, в Python этот аспект важнее, чем в других ЯП.

1.3.3Настройка SideBarEnhancements

Вызов или через View > Sidebar, или через последовательное нажатие «Ctrl+k, Ctrl+b».

Клавиши можно переназначить, например, на Ctrl+\: Preferences > Package Settings > Side Bar > Key Bindings — User

Один из моих выпускников недавно устроился на работу и поделился со своими сокурсниками лайфхаком по оформлению резюме на HH.ru:

Мне ещё hr из крупной it компании дали хороший совет, если искать работу через HH, может кому-то поможет.

На hh сначала идет информация о предыдущем месте работы, и только потом есть пункт «О себе», куда и я написал данные о том, что я хочу сменить профессию, что я умею из тестирования и т.д. Это не правильно, так как до конца резюме мало кто долистывает, времени на это ни у кого нет.

Поэтому мне посоветовали указать последним местом работы «Обучение тестированию» и туда уже вписать информацию по тому, что ты умеешь. Там образом нужная информация на hh будет на самом верху:

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

Но будем честны, через HH ищут работу очень многие люди. И ведь находят, даже новички! Поэтому там тоже нужно заполнить профиль. И если HR дают такие советы, то почему бы не попробовать? :)

PS: ссылочку на пост сохранила на Testbase в навыке составления резюме, теперь не потеряется (upd — чуть позже сохраню, пока технические проблемы)

• Беда нечаянно нагрянет, когда ее совсем не ждешь.

• Выборы в Государственную Думу: что не так с электронным голосованием, что и как следует изменить (1, 2, 3).

• Что есть наша жизнь? Реальное существование или симуляция для потехи высокоинтеллектуального разума?

• Data QA engineer: новое направление в широком спектре позиций, связанных с обеспечением качества.

• Двадцать паттернов разработки в JavaScript c примерами.

• Программирование в паре с искусственным интеллектом: не совершаешь свои ошибки, но получаешь ошибки своего “напарника“.

• Баги неизбежны, находи их быстро и вноси изменения оперативно.

• Команда Stack Overflow внимательно выслушала благодарных пользователей и больше не будет прикреплять принятый ответ вверху списка ответов. Сортировка ответов будет выполняться исключительно по количеству голосов за тот или иной ответ.

• Я эффективно двигаюсь вперед, а после меня хоть потоп.

• Если пытаться убить двух зайцев одним выстрелом, результат может оказаться плачевным.

• Использование API-схем для property-based тестирования.

• Raymond Chen раскрывает очередную загадку – на этот раз про пустой массив в C#/Win RT.

📎📎📎📎📎📎📎📎📎📎