Язык шаблонов. Города. Здания. Строительство

Авторы книги:
Кристофер Александер, Сара Исикава, Мюррей Силверстайн.

Как выглядит:

Хорошее описание есть на сайте Артемия Лебедева.
Небольшая цитата оттуда:

«Язык шаблонов» — одна из самых значимых книг XX века, которая до сих пор не издавалась на русском, хотя оказала сильнейшее влияние на развитие дизайна, проектирования, архитектуры и компьютерных наук, в том числе объектно-ориентированного программирования.

Источник: https://www.artlebedev.ru/izdal/yazyk-shablonov/

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

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

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

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

Дальше - картинки.

Вторая часть эксперимента Да́ннинга — Крю́гера

Все в курсе про эффект. На всякий случай, вики:

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

В целом как-то так:

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

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

 Звучит, как неплохой тест - проверить, с кем ты работаешь и общаешься. И себя.
На способность изменить мнение, если ты умнее, чем думал. Или тупее.

Лекция Сергея Мартыненко

Спасибо Насте Ронжиной и проекту Контура "Гуру на Урале".

Тервер на службе менеджера:

ROI от автоматизации тестирования:

Следующий тренер - через год.

Бремя белого человека

 Оставлю здесь себе на память.

Вслух

Часто с удивлением слышу, о том что я больше не занимаюсь тестированием.
В связи с этим немедленно вспоминается анекдот: 

- Квентин, а вам не кажется, что вы так и не сняли ничего лучше "Криминального чтива"?
- А кто снял?

Прекрасное, из Вайнберга

Книга - огонь. Из 14 главы.

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

1. Менеджеры не видят разницы между тестированием, локализацией и отладкой.
2. Из-за того, что они не видят разницы, они верят, что тестирование было причиной большей части неприятностей, которые они испытали в проектах.
3. Из-за того, что они верили, что тестирование было причиной проблем, они имели склонность откладывать все формы тестирования настолько, насколько могли.
4. Из-за того, что они выбрали процессы, откладывающие тестирование, тестируя в первый раз они не могли притворяться, что все идет хорошо.
5. Или, может быть, если проект плохо управляем...
6. Из-за того, что они выбрали процессы, откладывающие тестирование, они страдают от информационного иммунитета и могут делать вид, что дела идут хорошо, даже после того, как они провели некоторые тесты.
7. Из-за того, что они страдают от информационного иммунитета, на ранних стадиях проекта кажется, что все будет идти "гладко" до завершения.
8. Из-за того, что менеджеры зашли в тупик, баги, многие из которых уже дремали в продукте со времен самых ранних требований, обнаруживаются при позднем тестировании.
9. Поскольку вся система теперь собрана воедино, многие из этих ошибок трудно локализовать, тем более, что разработчики не могут помочь, так как в настоящее время они бегают, как обезглавленные куры, пытающиеся справиться с внезапным избытком багов.
10. Так как разработчики, работающие под давлением дедлайнов, делают новые ошибки при попытке исправить недавно найденные, страсти накаляются, разум немеет,  крепнут прогулы, встречи размножаются и стратегия ведет к неприятным последствиям.
11. Поэтому участники заключают, что «у нас не было никаких проблем, пока мы не приступили к тестированию. Мы шли точно по графику. Тестирование испортило все."

Обремененные этим выводом, менеджеры начинают планировать следующий проект - очередную паническую катастрофу.

И да. Перевод - идет.

События этой весны в тестировании Екатеринбурга

• Тест-сессия для студентов
• Секция тестирования на Дампе
• Курсы по тестированию от Кати
• Курсы по тестированию от Ильи
• Гуру на Урале: Сергей Мартыненко, лекция для студентов (в разработке)
• Гуру на Урале: Сергей Мартыненко, лекция для сообщества тестировщиков (в разработке)
• Пятая городская сессия тестирования от Targem (в разработке)

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

SCRUM в картинках: роли и события

Хорошие картинки.
http://seljava.blogspot.ru/2017/02/scrum.html

Про то, куда иду

Ты "свет фар" своего проекта. (с)

Сэм Канер.

Про то, откуда иду, я уже писал. Теперь про то, куда.

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

 

Ты не программист

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

Но приложения создают именно программисты. И отчасти ты - программист.

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

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

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

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

Если ты пишешь тесты, то код тестов соответствует стандартам кода продукта. Тесты - часть продукта и их качество - качество продукта. Ты пишешь код системы тестов на нужном уровне. И проходишь стандартное ревью программистов.

Ты не проектировщик

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

Но твоим продуктом будут пользоваться люди. И отчасти ты - проектировщик.

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

Ты не аналитик

Ставить задачи программисту - не твоя работа. Решать как и зачем должно работать приложение - не твоя работа.
Ты не посредник между аналитиком и программистом. Если программист не знает, как должна вести себя система, отправляешь программиста к аналитику, помня о потерях на коммуникации.

Но аналитики определяют, что мы должны создать. И отчасти ты - аналитик.

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

Ты не менеджер

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

Но ты работаешь в команде. Будь менеджером.

Чтоб стать хорошим работником ты поработал руководителем.
Ты не мудак.
На выходе ты даешь качество.
Ты сообщаешь о проблемах.
Ты выполняешь приказы.
И все записываешь.

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

Ты тестировщик

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

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

Ты профессионал

Ты качественно и быстро выполняешь свою работу и у тебя нет конфликтов с коллективом.
Ты качественно и быстро выполняешь свою работу и команда не работает за тебя.

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

Самый ценный ресурс тестировщика - доверие. Тебе доверяют.

Одержимость

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

Финальная сцена, если лень, смотрите с 8:35
https://youtu.be/Tkh5I9w4ySY?t=8m35s

Видео полностью:

О ком этот фильм? О учителе или ученике?
Чья победа ярче в финальной сцене? Победа учителя или ученика?

Я уже больше сопереживаю учителю.
И да. Методы обучения - на отлично. Только так.

Про то, откуда иду

Главпроектировщик, Сергей, с коллегами создал манифест о хорошем, правильном проектировщике. А про тестеров у нас в компании такого нет.
Короче, я тоже захотел. Но не осилил.

Кто такой - отличный тестировщик?

Кого я называю отличным?
В чью группу хочу попасть?
Кто работает лучше меня?
На кого равняюсь?
У кого хочу учиться?

В мире? Виттакер, Канер, Бах, Болтон. Почему? Они профессора, программисты, авторы книг, евангелисты. Я читал их книги и статьи.
В стране? Руколь, Назина, Баранцев, Александров, Мартыненко, Мериин, Нечаева, Высоцкий. Почему? Они известные тренеры и докладчики. Я был на тренингах и слушал доклады.
В Екатеринбурге? Юра Р., Женя А., Илья В., Ната С.. Почему? Они умеют работать, у нас были совместные проекты.

- Можно ли стать отличным, не интересуясь, как работают другие?
- Нет.

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

Так и записал. Что еще?
Не знаю.

Не могу описать идеал, сам им не являясь.
Но я хочу стать хорошим тестировщиком десять лет и и надеюсь, что двигаюсь в правильном направлении.

Куда и откуда?
Прежде всего это история людей, с которыми работал.

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

Второй шаг - в Наумене удалось вместе работать с руководителем разработки SD, программистом А.Л..

Он тратил свое время на обучение и воспитание сотрудников.
Вместе с ним за пару лет прошли от "программисты пишут какой-то код без CI" до "релизим ежедневно с постоянно зеленых тестов". Первые в компании использовали скрам (по канону), перешли на git, ввели системное автоматизированное тестирование на всех уровнях, системное нагрузочное тестирование в CI.
Он садился и делал задачи вместе со мной.
Примером показывал, как использовать блокнот и хоткеи в IDE.
Показывал, как считает время и как складывает текстовые файлы у себя на компе.
Вникал в детали моих задач. После получаса совместной работы обычно оставалось ощущение "а почему я все это не сделал сам?".
Учил начинать с проблем, а не с решений.
Учил писать требования, контракты и письма.
Учил отличать полезную работу от бесполезной и признаваться, что делал бесполезную.

Третий шаг. В тот период я занялся переводом "lessons learned in software testing", книги, которая не столько о стандартах, техниках и методологиях, сколько о о ситуациях, в которые попал автор. Читая ее я чувствовал, что веду диалог с автором о том как жить и работать.
В ней есть понемногу обо всей жизни тестировщика. Попасть на работу, работать руками, что и зачем автоматизировать, на какие конференции ходить, какие подходы срабротали, какие нет. Как нанимать и как увольняться.
Иногда даже удавалось успешно применить какой-нибудь из 293 уроков.Рассылка о состоянии тестирования, посещение конференций, маркетинг своей деятельности и многое другое вышло со страниц этой книги.
Канеру в деле воспитания меня помогали Блэк, Виттакер, Криспин, Адизес и многие другие.

Следующий шаг и следующий человек - Ю.З., аналитик, менеджер разработки.

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

А еще показала как по-разному можно решать задачи.
Автор 500 постановок к одному продукту - показала, как вести продукт с 5 аналитиками и практически без ТЗ - в привычном нам виде. Менеджер, собравший топовую команду тестирования - показала, как жить без багтрекера и без открытых багов. Мне, тестировщику показала.

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

- Что дальше?
- Не знаю. Наверное, опять ищу человека.

- Пост точно про тестирование?
- Нет. Про жизнь.

Репост старой записи о проценте нахождения багов разными техниками

Ссылка:
https://kev.inburke.com/kevin/the-best-ways-to-find-bugs-in-your-code/

Вам не нужно больше тестировщиков

Я все еще под впечатлениям от нетленки Болтона девятилетней давности.

Менеджеры и тимлиды:
У вас в командах уже есть тестировщики, но вы хотите ещё, потому, что:

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

Вам не нужно больше тестировщиков:

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

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

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

• Вам нужно уйти из бизнеса по разработке программного обеспечения.

Специализация

Роберт А. Хайнлайн

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

У меня уже дважды менялось отношение к этой цитате.
На данный момент - согласен.

Письма римскому другу

Бродский. На память мне.

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

Дева тешит до известного предела -
Дальше локтя не пойдешь или колена.
Сколь же радостней прекрасное вне тела:
Ни объятья невозможны, ни измена!

Посылаю тебе, Постум, эти книги.
Что в столице? Мягко стелют? Спать не жестко?
Как там Цезарь? Чем он занят? Все интриги?
Все интриги, вероятно, да обжорство.

Я сижу в своем саду, горит светильник.
Ни подруги, ни прислуги, ни знакомых.
Вместо слабых мира этого и сильных -
Лишь согласное гуденье насекомых.

Здесь лежит купец из Азии. Толковым
Был купцом он - деловит, но незаметен.
Умер быстро - лихорадка. По торговым
Он делам сюда приплыл, а не за этим.

Рядом с ним - легионер под грубым кварцем.
Он в сражениях империю прославил.
Сколько раз могли убить! А умер старцем.
Даже здесь не существует, Постум, правил.

Пусть и вправду, Постум, курица не птица,
Но с куриными мозгами хватишь горя.
Если выпало в империи родиться,
Лучше жить в глухой провинции у моря.

И от Цезаря далеко и от вьюги,
Лебезить не нужно, трусить, торопиться.
Говорят, что все наместники - ворюги,
Но ворюга мне милей, чем кровопийца.

Этот ливень переждать с тобой, гетера,
Я согласен, но давай-ка без торговли:
Брать сестерций с покрывающего тела -
Все равно что дранку требовать у кровли.

Протекаю, говоришь? Но где же лужа?
Чтобы лужу оставлял я - не бывало.
Вот найдешь себе какого-нибудь мужа,
Он и будет протекать на покрывало.

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

Был в горах. Теперь вожусь с большим букетом.
Разыщу большой кувшин, воды налью им...
Как там в Ливии, мой Постум, или где там?
Неужели до сих пор еще воюем?

Помнишь, Постум, у наместника сестрица?
Худощавая, но с полными ногами.
Ты с ней спал еще... Недавно стала жрица.
Жрица, Постум, и общается с богами.

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

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

Поезжай на вороной своей кобыле
В дом гетер под городскую нашу стену.
Дай им цену, за которую любили,
Чтоб за ту же и оплакивали цену.

Зелень лавра, доходящая до дрожи,
Дверь распахнутая, низкое оконце,
Стол покинутый, оставленное ложе,
Ткань, впитавшая полуденное солнце.

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

Творчество

Коллективное бессознательное коллег:

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

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

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

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

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

aldragon

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

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

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

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

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

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

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

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

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

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

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

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

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

Повествование о взаимодействии человека с системой.

1. Лица
2. Цели
3. Успех
4. Расширения
5. Обработка
6. Данные
7. Валидация

Особенности

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

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

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



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

Каждый новый шаг в выбранной вами профессии стоит дороже.

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

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

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

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

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

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

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


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

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

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

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

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