среда, 30 ноября 2016 г.

Теория ограничений Голдратта

Эта книга - справочник по теории ограничений - системному, научному мышлению и подходу к управлению проектами и процессами любого размера - от поездки в отпуск до трубопрокатного цеха.

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

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

Книга - именно справочник, в ней очень мало объяснений, почему все работает именно так. Перед тем, как приступить к ней - рекомендую прочесть основной цикл Голдратта - Цель1, Цель-2, Цель-3.

вторник, 15 ноября 2016 г.

aldragon

Чтоб я так думал и так формулировал.

…Алиса приходит в себя; Страна Чудес была сном, воздух ревёт, падение в кроличью нору длится четвёртые сутки, очень, очень хочется пить.

«…канарейка выжила, но годами ходила к терапевту».

«…а теперь давай жёстко. Как будто я – концепт гиперзвукового пассажирского лайнера, а ты – законы физики и экономическая целесообразность»

Почитайте, там много: https://twitter.com/aldragon_net

четверг, 10 ноября 2016 г.

Про аналитику

Текстовая версия моего рассказа на летучке от 9 декабря.

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



Часть первая. О чем?

До сего времени я был знаком с шаблоном  юзкейса

Я как {роль} хочу {что-то}, чтобы {цель}

Казалось бы, где тут писать книгу на 250 страниц? Как выяснилось - юзкейсы, как и все остальное - с большим удовольствием можно делать неправильно.

Итак, что такое юзкейс?

Повествование о взаимодействии человека с системой.
  1. Лица
  2. Цели
  3. Успех
  4. Расширения
  5. Обработка
  6. Данные
  7. Валидация
Особенности
  • Для удобства чтения разбитое на абзацы.
  • Уровни взаимодействия. Море, птицы, рыбы.
    • На каком уровне должна находиться цель.
    • На каком уровне должен находиться юзкейс.
  • Определить, кто такой человек. Действующее лицо.
  • Определить его цель.
  • Ветвлений нет. Есть исключения.
    • Записываются отдельно от основного повествования.
    • Минимальные гарантии.
    • Удобства отдельной записи - расширение без перенумерации и т.п.
  • Если ветвления есть, то это 2 истории, а не одна. И стоит подумать, что их надо разделить.
  • О читаемости историй.
    • Каждый пункт истории должен приближать пользователя к цели. Не "пользователь ввел логин и пароль", а "система подтвердила правильность логина и пароля" (еще примеры)
  • Триггеры

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

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



Часть вторая. Зачем?

Каждый новый шаг в выбранной вами профессии стоит дороже.
  • Сперва нужно знать как чем отличается гет от пост, делить на классы эквивалентности, писать чеклисты и делать что говорят.
  • Затем - разбираться в стеке OSI, писать скрипты bash, пользоваться фидлером, рисовать карты памяти и приоритезировать свои задачи.
  • Идем дальше - и мы уже чуем слабые места layer'ной архитектуры, программируем на любом скриптовом языке, оцениваем узкие места коммуникативвных средств и понимаем, зачем в реальной жизни нужны ТОС и ТАУ.

Обращаю внимание, что я перечислял развитие одних и тех же навыков.

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

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

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

Это профессия аналитика.
Я делю знания аналитика на две части -
Первая это инженерия систем, проектирование систем, создание моделей - все вот это. Описание и создание неких ментальных конструкций.
Вторая - коммуникация. Представление этих конструкуций в понятной форме.

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


Как они мне могли бы пригодиться?
Менеджеры не звери и программисты не сволочи. И часто могут хотеть помочь нам. Зачастую - в случайный момент времени нам выдается значительный ресурс программиста. И я ставлю 5 к 9, что если каждому из вас выдать программиста на неделю, то вы не придумаете ничего полезней чем "чини старые баги". и 7 к 9, что даже если придумаете, то это будет абстрактное желание в виде устного творчества.

К чему я? Тестировщики часто ставят задачи. Множество микрорешений на уровне продукта. Задания на доработку тестирующей системы, создание заглушек, инструменты сопутствующей автоматизации.
А теперь попробуйте вспомнить, из за чего программисты делают добрую часть ошибок? Из за некачественного задания.
Автотесты - большой продукт. Сотни тысяч строк. Сколько у них постановок? А почему? Я видел у 2 команд. Удивите меня.
А можно ли назвать задания которые ставят тестировщики качественными?

воскресенье, 6 ноября 2016 г.

Когда уходят люди

Из Брига. Когда уходят люди. Навеяло.

    - Я тебе нужен?, - спросил я.
        Костя опять сел в кресло, покачался на нем и заговорил:
    - Я тебе вот что, Бриг, скажу... Нужен, не нужен - это все лирика. Вполне может быть, что и не нужен. Вот и Серега тебя заменит. А вот... выйди я сейчас в соседнюю комнату - тишина, все работают, слова лишнего не скажут, разъеби я кого - утрутся молча, неправ я буду - все равно промолчат, сидеть будут, очереди своей ждать... Что, трудно им людьми остаться? Не дрожать, не лизать жопу, глаза не опускать? Из, блядь, ста или - сколько там сейчас? - людей, не людей - не знаю, единиц, в общем - из этих ста кто мне в ебало правду скажет? Ну, Петрович, да Гена, да ты вот... Из ста! Сколько раз было - рушится все, боятся признаться, пока, блядь, сам говна не увижу... А уж как вкладывают друг друга! Пока я в силе - так и будет. А представь, развалится завтра "Циклон", все на улице окажемся - банкротство там, или еще какая хуйня. Да элементарно - каждый мне в морду плюнет и детям своим накажет. Эксплуататор, блядь, трудового народа. А я пешка, Бригадир. Просто - пешка. Надо мной такие люди, что лучше бы тебе не знать...
    "Нужен"... Да не нужен ты мне, как работник, до хуя таких, извини, блядь, сисадминов... Просто... Ты уйдешь, и уже останется двое. Двое, с кем я могу человеком себя почувствовать... А потом, например, один. А там уже.., - он махнул рукой, - ... эх, да что, блядь, говорить!