В 20-м веке жизнь и работа людей шли по плану. На работе (упрощая — можно представить завод) у людей имелся четкий план на неделю, на месяц, на год вперед. Упрощая: тебе надо выпилить 20 деталей. Никто не придет и не скажет, что деталей теперь надо выпилить 37, а кроме того, написать статью с размышлениями о том, почему форма этих деталей именно такая — и желательно вчера.

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

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

Как с этим жить — чтобы оставалось время на жизнь вне работы? И можно ли применить какие-то рабочие алгоритмы менеджмента в повседневной, бытовой жизни? 3 месяца назад я кардинальным образом поменял всю систему постановки задач и контроля за ними. Хочу рассказать, как я к этому пришёл и что в итоге получилось. Пьеса будет в 2 частях: в первой — немножко про, если так можно выразиться, идеологию. А вторая — целиком про практику.

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

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

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

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

Поэтому пройдусь по своим “итерациям”, и, может быть, в таком же виде это пригодится и вам. В конце концов, чем не повод использовать майские каникулы, чтобы выйти на работу, используя новую (относительно) парадигму?

А как я к этому пришёл, можно прочитать здесь.

Кадр из заставки сериала «Грань»

Предисловие

На Geektimes и Habrahabr уже были статьи со списком Sci-Fi сериалов (Фантастические сериалы — обзор от фаната, Фантастические сериалы и др.). Но все они либо содержали достаточно мало сериалов и/или поверхностную информацию о них самих, либо были предвзяты в отношении тех или иных сериалов.

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

Профессор Эндрю Траскот и студент Роман Хакимов отважно заглядывают в квантовый мир

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

Этот принцип — один из фундаментальных законов, который мало кто оспаривает. Хотя многие физические величины и явления не меняются, если мы обратим время вспять (являются Т-чётными), существует фундаментальный эмпирически установленный принцип: событие А может влиять на событие Б, только если событие Б произошло позже. С точки зрения классической физики — просто позже, с точки зрения СТО — позже в любой системе отсчёта, т.е., находится в световом конусе с вершиной в А.

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

Кроме одного момента — квантовой физики. Там вообще много странного. Вот, например, классический эксперимент с двумя щелями. Если мы поместим препятствие со щелью на пути источника частиц (например, фотонов), а за ним поставим экран, то на экране мы увидим полоску. Логично. Но если мы сделаем в препятствии две щели, то на экране мы увидим не две полоски, а картину интерференции. Частицы, проходя сквозь щели, начинают вести себя, как волны, и интерферируют друг с другом.

1. Эту кружку

25 сентября в 22:00 состоялся выпуск второго сборника мобильных игр Humble Mobile Bundle.

Все игры после покупки будут доступны для загрузки на Android прямо с сайта Humble Bundle и являются DRM-free. На этот раз максимальная экономия может составить до 300 рублей.

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

Итак попробую ответить на вопрос: какие артефакты необходимы для обеспечения процесса тестирования (имеется ввиду разрабатываемые самим тестировщиком).

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

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

Однако начну несколько издалека — с рассказа про огненные сморчки.

Не нашёл на хабре — спешу поделиться. Восхитительное выступление Александра Соловьёва ingspree на конференции JavaScript Frameworks Day 2013. На видео ниже просто набор отрывков из него, желающим посмотреть полностью — сюда.

Disclaimer

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

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

Cтандартные в таких случаях советы: объясняйте, мирите, аргументируйте, — выглядят, как будто перед программистами оправдывают существование тестировщиков. Постфактум решать такую проблему (а это очень критичная проблема) очень трудно. Нужно закладывать правильную атмосферу при построении команды и носить это правильное отношение к работе за собой из команды в команду, из компании в компанию.

Знаете, в чем на самом деле фишка? В разности целей!

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

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

Последние дни всё чаще натыкаюсь на сообщения в блогах и форумах про то, что тестирование — это либо очень скучно, либо тупая работа и т.д.
Что все эти люди делают в тестировании??

Позавчера я тестировала свой небольшой веб-проект.

За 4 часа я завела 25 дефектов.

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

«А что, если?...», «А как проверить?...», «А как бы?...» и т.д. заполняют мозг, который включается на полную мощность.

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

Это захватывает, и время пролетает очень быстро. Это творческая, непростая, ответственная работа, которая увлекает на 100%!

И я задумалась. Кто пишет про «скучно», «рутина» и «тупая работа»? Почему не всем нравится? Постаралась выписать всё, что пришло в голову.

Так получилось, что завершение перевода этой статьи Майкла Болтона удачно совпало с появлением на хабре заметки Натальи Руколь «Почему тестирование — это тупо и скучно?», которая вызвала достаточно бурное обсуждение. Эта статья призвана в какой-то степени объяснить, почему одним тестирование кажется скучным, а для других людей это самое интересное занятие в мире.

Когда мне было лет двадцать с небольшим, я решил быстро научиться вкусно готовить. Нашел книгу «Гурман за 60 минут» Пьера Фрейни, и пошел читать.

Выяснилось, что мистер Фрейни описывал не технику, а свою философию приготовления еды.

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

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

Как обычно строят процесс тестирования непросветлённые тест-менеджеры?

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

Релиз.

Не работает основной функционал.

Почему такое возможно?

1. Заведение всех подряд ошибок мешает разработке. Разработчики тратят своё время на исправление минорных ошибок и вносят новые, зачастую более серьёзные.

2. Потраченное на мелочи время не дало возможности проверить более серьёзные пользовательские сценарии и найти более критичные дефекты.

3. Обратная связь по статусу сборки предоставлялась разработчикам с запозданием: вместо критичных дефектов непрерывно сыпались миноры.

4. Проектный паттерн «дохлая рыба» сыграл своё дело: все участники команды прекрасно понимали, что протестировать всё нельзя, и это не могло не сказаться на качестве работы. А реалистичных целей им никто не поставил…

Что просветлённые тест-менеджеры делают по-другому?

Что они поменяют в первую очередь?

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

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

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

Итак, хотите знать, как положительным образом влиять на программистов?

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

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

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

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

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

Но экономия времени при написании — это ещё не всё. Едва ли не более важным фактором является то, что в многословных описаниях теряется смысл, который туда пытался заложить тест-дизайнер. Поэтому опытному тестировщику работать с короткими описаниями проще, чем с подробными длинными сценариями. И сегодня я хочу представить вашему вниманию перевод небольшой заметки Роба Лэмберта (Rob Lambert), в которой он описывает эксперимент объясняющий этот феномен.

Less Is More, или Меньше слов — больше смысла.

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

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

Если вы пользуетесь твиттером, вы представляете, как это происходит. Иногда приходится немало потрудиться, чтобы суметь выразить свою мысль, используя всего 140 символов, но зато результат получается впечатляющим. Это очень полезная практика, потому что краткость, как известно — сестра таланта.

Большинство моих текстов становятся существенно короче после того, как проходят этап «ужимания», хотя, если постараться, там можно найти ещё немало «ваты».

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

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

Области применения, цели и задачи тестирования ПО разнообразны, поэтому тестирование оценивается и объясняется по-разному. Иногда и самим тестировщикам бывает сложно объяснить, что такое тестирование ПО 'as is'. Возникает путаница.

Для распутывания этой путаницы Алексей Баранцев (практик, тренер и консалтер в тестировании ПО; выходец из Института системного программирования Российской академии наук) предваряет свои тренинги по тестированию вводным видео про основные положения тестирования.

Мне кажется, что в этом докладе лектор смог наиболее адекватно и взвешенно объяснить «что такое тестирование» с точки зрения ученого и программиста. Странно, что этот текст еще не появлялся на хабре.

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