Меняем привычки. М.Дж. Райан

Ссылка на OZON

Интересная получилась книга! Хотя вначале я была настроена скептически, устала уже читать всякие мотивашечки, сводящиеся к «сядь и сделай!».

В первую очередь восхитило оформление. В книге всего 81 совет. Слева цитата, которую надо говорить себе, справа небольшое описание: откуда цитата взялась, как она поменяла чью-то жизнь...

Плюс куча разделов, а это еще 2 практически пустые страницы. Классное оформление! Кто-то может сказать, что проще было написать 1-2 статьи, чем книгу. Но книгу можно продать, она повышает авторитет (а автор занимается консультированием, ей это на руку!). В общем, книга небольшая. Но мне понравилось оформление, и читается быстро.

Фишка в чем? Читаешь книгу, выбираешь фразу, которая может помочь тебе в жизни. Например, улучшить отношения в семье, смириться с неудачами на выбранном пути, подавлять вспышки агрессии... И начинаешь эту фразу повторять. Потому что многократное повторение позволяет ей закрепиться в мозгу и исправить поведение.

Привычка достигать. Бернард Рос

Ссылка на OZON

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

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

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

Ну вот, например, упражнение. Сказать «это для меня не важно» о том, что реально важно. Легко? А теперь попробуйте сказать «моя дочь для меня не важна». А ведь Рос уговорил свою коллегу на такое упражнение, и у той даже отношения с дочкой потом лучше стали!

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

Хотя пара интересных мыслей тоже есть.

Как описывать навыки в резюме

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

• базовые знания sql
• базовые знания тест-дизайна
• ...

А что значит «базовые знания»? Для вас это «прочитал 2 статьи», а я буду ожидать join трех таблиц... Будет печально, если это выяснится уже на собеседовании. Поэтому не пишите непонятных фраз. При описании навыков используйте правило:

НЕ НАДО ПИСАТЬ «БАЗОВЫЕ ЗНАНИЯ»!

Это говорит о реальных навыках «ничего». Пишите самое сложное, что умеете делать.

Пишите о том, что реально умеете делать. Если вы прочитали 1 статью о том, как в JIRA можно создать проект и настроить его под себя — это не значит, что у вас есть навык администрирования джиры!

Посмотрел бесплатное видео про создание первого автотеста и просто повторил за тренером? Это не значит, что вы умеете писать автотесты. Подключился к линукс-машине через WinSCP? Это не значит, что есть базовые знания Linux.


Конечно, написать в резюме можно все, что угодно. И вы даже можете пройти отсев по резюме — работодатель увидит список того, что вы умеете, впечатлится и позовет на собеседование! Но достаточно будет 5 минут, чтобы понять реальный уровень ваших знаний.

Собеседую синьор-тестировщика. У него в резюме 3+ года нагрузочного тестирования. Ух ты! А мы на тот момент нагрузкой еще не занимались. Круто же, интересно. Начинаю уточнять: 

— А тут написано, что 3 года нагрузочное проводите...
— Ну да.
— Расскажите, пожалуйста, как это происходит?
— Ну... (замялся). Там уже все написано было до меня. Так что я просто нажимал «Запустить» и смотрел на графики.

Вот сразу и виден реальный уровень. А как гордо звучит резюме! Несколько лет нагрузочного тестирования, это ж мега-спец! А на деле такое тестирование может и джун проводить... 

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

Теперь главный вопрос — а как написать то? Вот если книгу по sql прочитал, это уже «базовые знания sql»? Или еще нет? А если 3 упражнения на sql-ex  выполнил? А если первый join смастрячил?

Опиши и приложи (правила оформления бага)

На что обращаться внимание, когда вы пишете шаги бага? Есть несколько разных правил, одно из которых — «опиши и приложи». Не забывайте про скриншоты и примеры!

Скриншоты

Почему в моей книге столько картинок? Потому что они привлекают внимание! Это первое, за что цепляется взгляд.

Хорошо оформленный баг — это когда разработчик прочитал название, посмотрел на скриншот и все. Ему больше ничего не нужно, он понял, где ошибка. А шаги... Шаги остаются тестировщику для перепроверки задачи.

Примеры

Пример — это не только какое-то значение, которые мы вводим в строку: «Например, 6,9»

Классы эквивалентности для населенных пунктов в адресах

У студентов в моей школе для начинающих тестировщиков есть задание — написать чек-лист на функционал своего проекта.

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

Моя коллега Ольга Алифанова привела такой пример:

********************************************************************

Какие можно выделить классы эквивалентности для адресов? Как разделить населенные пункты:

• по типу: столица, город, ПГТ, деревня...
• по названию: в одно слово, в два через пробел, в два через дефис, в три и более слов (Комсомольск-на-Амуре), с цифрами (все закрытые города, скажем, имеют цифру в названии), ...
• по населению: Москва, Петербург, миллионник/не миллионник, больше 12к жителей, исключение (Иннополис - десять жителей, но город)
• по административному положению: федерального значения (Мск и Спб уже были, значит, Севастополь остался), областной центр (Екат), не областной центр (Выборг)
• по степени закрытости: обычный (Псков), приграничная зона (Ивангород), совсем закрытый (Красноярск-26)
• по истории названия: переименовывались, не переименовывались, переименовывались неоднократно (Петроград-Ленинград-Петербург)

Дальше у меня идеи кончились, ну, кроме длины, поэтому я схожу в гугл. Но обратите внимание: в первую очередь мы думаем о строке не как о строке (символы русские, английские, смешал, длину проверил), а как о конкретном поле. И выделяем классы именно для этого поля. Не для абстрактного string.

********************************************************************

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

Как ни странно, студенты очень хвалят этот пример и говорят за него огромное спасибо. И идут переделывать свои чек-листы... То есть примера с именами явно недостаточно. Тогда вынесу этот пример в блог и книгу! Публикуется с согласия автора :)

См также:

Классы эквивалентности для имен — тоже идеи, но про имена

Классы эквивалентности: будни Золушки — подробнее о классах эквивалентности
Ивану кредит не давать! — история о баге, который пропускается, когда тесты абстрактные

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

Панбагон. AccessDenied при попытке увеличить картинку

Изучаю документацию postman-а, смотрю про переменные — https://learning.getpostman.com/docs/postman/environments_and_globals/variables_complete_reference

Кликаю на картинку«Variables-Chart»:

Увеличиваем картинку

Упс, ошибочка вышла!

Бизнес-процессы: как их описать, отладить и внедрить. Михаил Рыбаков

Ссылка на OZON

Прекрасная иллюстрация на тему того, что «если у тебя есть книжка — ты крут». У Рыбакова есть компания, которая занимает отладкой бизнес-процессов. Они консультанты. И вот на протяжении всей книги есть отсылки на то, что «пригласите нас — и сделаем все быстрее!».

И при этом реклама работает! Потому что в целом книга написана довольно интересно, поэтому когда встречаешь ненавязчивую рекламу, то к середине книги уже думаешь «А было бы неплохо его пригласить, посмотреть что как...».

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

***

А теперь по самой книге. Когда компания маленькая, она работает на энтузиазме основателя, иногда на энтузиазме нескольких «первых» людей. Но когда компания растет, часто начинается хаос. Как же так? Раньше ведь все так здорово работало, наняли еще людей, чтобы успевать больше, но что-то пошло не так...

Вообще очень знакомо это все, конечно. Когда у тебя 3 проекте, и когда 6 — разница несильная. А когда их становится 15, 20... Старые процессы перестают работать, а вот как внедрить новые, и какие? Непонятно!

Автор рассказывает, как это обычно делается:

1. Описываем бизнес-процессы «как есть сейчас» — это важно сделать, хотя некоторые и считают бюрократией. Но не менее важно в эту самую бюрократию не скатиться!
2. Выделяем самые важные бизнесс-процессы. 
3. Назначаем РП — руководителя процесса
4. Расписываем процессы чуть подробнее, обсуждаем в командой «чо-как». Рисуя «как есть сейчас», сразу накидываем идеи на улучшение.
5. Потихоньку внедряем.

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

Поэтому назначается не руководитель одного отдела, а руководитель всего процесса, сквозного. Только так можно с кого-то спросить за качество и это самое качество получить. 

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

Как именно нужно описывать процессы, выбирать роли и прочее? Это уже подробнее в книге) Плюсы книги — это книга-тренинг, то есть читаешь и сразу выполняешь «домашнее задание» на закрепление материала. Иначе читать бесполезно, хотя я попробовала, мне любопытно было))

Думаю, что книга полезная для собственников бизнеса. И автор смог продать идею бизнес-лагеря. Мне теперь кажется, что туда было бы полезно съездить )))

PS - Добавила книгу в общий список прочитанных мною книг.