пятница, 31 января 2014 г.

Мысли

Приходится отвечать на до поры до времени гипотетический вопрос: какой язык выбрать для написания автотестов:
Python или java?

Аргументы за python:
- Мои программисты пишут на python - и в случае выбора этого языка готовы помочь
- Мой продукт написан на python
- Мне полезно изучить python
- У меня сложилось мнение, что python предпочтительней для небольших проектов и для скорости

Аргументы за java:
- Существующая инфраструктура тестирования (CI, selenium grid итпх) и ее автотестеры используют java.
- На java есть откуда копипастить куда обращаться за решениями по кодированию именно автотестов (пользуясь случаем, передаю привет)
- Я уже писал автотесты на java
- WebDriver первыми выпускает обновления для java и вообще лучше работает с этим языком (тут я могу и ошибаться)
- Лично мне больше нравится java (а тут я могу и передумать)

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

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

Мое слово - не последнее, но кино будет именно моим, хотелось бы запастись аргументами.

Рутина

Офисное:
Программист frontend: Привет, у тебя сегодня был English speaking club?
Программист backend: Скорее English skipping club...

И легкая разминка:
Альбом: randompics4lj

четверг, 30 января 2014 г.

Рутина

К предыдущему:
Альбом: bug

Это пЕар

http://dump-it.ru/

Там на вкладке Люди есть я.

Ненависти пост.

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

How Google Tests Software

Напоследок, три цитаты.

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

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

Три. Что будет потом:

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

Музыка



Прошёл насквозь через день как нож,
Теперь беги через ночь как мышь.
Не делал вида, что днём живёшь,
Так и не надо, что ночью спишь.

Закрой на кухне певучий кран,
Достань из мойки пустой стакан,
Сотри с него меловой налёт,
Вложи в него желтоватый лёд.

И поскорей вискаря, поскорей вискаря,
Поскорей, да, да, да, да, до дна!
Ты научился бухать втихаря, вглухаря,
Тебя уже не греет
Ржавая вода…

Сидишь на кухне один как перст,
Кругом гулянка на тыщу вёрст.
И чтоб услышать благую весть
Таблетки сыплешь в сухую горсть.

В колонках булькает Judas Priest,
В руке опавший газетный лист…
Какие бабки сулят за смерть —
Таких не сделаешь за всю жисть.

Кого хотел — тех осеменил:
Жена и дети, казалось бы.
Но стоит вспомнить что семьянин —
И ты конкретно летишь с резьбы.

Так допивай, коль попутал бес,
Швырни пустую в окно, в кусты.
Мы все гордимся тобой с небес,
Все, кто при жизни бухал как ты.

Так поскорей вискаря, поскорей вискаря,
Поскорей, да, да, да, да, до дна.
Ты очень скоро уйдешь втихаря, вглухаря,
Зато пребудет вечно
Ржавая вода.

среда, 29 января 2014 г.

How Google Tests Software

Еще пара цитат.

Первая:
Если ваш план не привел к созданию тестов, значит вы потратили время зря.

Вторая:
Я поступил по-гугловски: сказал, что поставлю эксперимент на паузу, но делать этого не стал

How Google Tests Software

Курсивом цитата, мои комментарии нет.

Вот общий список того, в чем тестировщик должен однозначно разбираться :
- планирование тестирования и анализ рисков

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

вторник, 28 января 2014 г.

How Google Tests Software

Еще пара цитат из книги.

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

Цель инженера по тестированию (Test Engineer TE) не искать ошибки в приложении, чтоб исправить их - этим занимаются разработчики, но искать ошибки, чтоб выявить их причину и помочь разработчику самостоятельно или с помощью разработчика в тестировании (Software Engineer in Test SET) - устранить эти помехи.
Я так понял, баги как таковые тестера вообще не очень интересуют, они являются инструментом выявления проблем, их признаком. Как-то так.

Цитата два:
Simon Stewart: Я пользовался процессом DDD (Defect-Driven-Development). Я объявлял WebDriver бездефектным, а когда пользователь находил баг я его исправлял и снова объявлял продукт бездефектным. так я исправлял по-настоящему значимые для людей баги. Этот процесс идеален для доработки существующего продукта. Вы исправляете только важные баги, а не возитесь с дефектами, до которых никому нет дела.

Панорамы Сочи

Налево пойдешь - в лето попадешь. Направо пойдешь - в осень попадешь. Прямо пойдешь - в зиму попадешь.

понедельник, 27 января 2014 г.

Так

Настольный теннис это весело. Смотрите полностью, там в середине ролика игрокам целой площадки становится мало.

How Google Tests Software

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

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

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

Я выписал несколько цитат, на неделе буду постить.
Первая:

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

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

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

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

пятница, 24 января 2014 г.

Рутина

Иногда кажется, что вместо "Здравствуй" я слышу:
— Хвала вечности, в Найклосте нет новостей.

четверг, 23 января 2014 г.

Рутина

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

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

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


На стихи А. Вознесенского.

Высоцкий:


А вот это исполнение мне даже больше нравится.

Рутина

Вы серьезно?
Альбом: randompics4lj


Пост до сих пор не проплачен.

The Domain Testing Workbook

Жаль, но не думаю, что эта книга стоит времени на перевод.
Прочтения - да. Поэтому только начало книги:

Секция 1: Что такое тестирование доменов?

Секция состоит из 2 глав:
- Введение в тестирование доменов
- резюме ключевых технических концепций

Мы предлагаем вам прочесть введение перед чтением остальной книги. После этого вы могли бы продолжить читать:
- Следующую главу, которая представляет собой короткое обсуждение ключевых терминов и концепций этой книги.
- Секцию 2, которая детально описывает схему тестирования доменов (одна глава на задачу).
- секцию 3, которая содержит список примеров.

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

Секция 1. Часть 1: Введение в тестирование доменов

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

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

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

пример серии испытаний

Уже давно мы начали книгу Testing Computer Software (kaner, 1988) ч простого примера, иллюстрирующего эту технику. начнем работу с этого примера и сейчас:
Вам дали программу с таким описанием:
Программа создана для сложения двух чисел, которые вы введете. каждое число должно состоять из одной или двух цифр. программа отображает то, что вы ввели и сумму. Нажмите после каждого числа. Для запуска программы наберите ADDER.

В книге описан такой пример:
- Начните с простых тестов, раскрывающих, как программа работает с разными переменными:

2 + 3 Программа вообще работает?
99 + 99 99 действительно верхняя граница?
-9 + -99 Допустимы ли отрицательные значения?

- Дошли до проверки простых, очевидных рисков:

0+0 Программа работает с нулями?
-99 + -99 Обрабатывает ли программа двузначные числа из трех символов?
100 + 100 Как будут обработаны трехзначные числа за границей?
-100 + -100
+
Что будет, если ничего не ввести?
123456 + 0 Как много цифр она воспримет?

- Проверьте входной фильтр, гарантирующий, что программа принимает только легитимные числа. Примеры:
1.2 + 5 Разделитель точка? Если она отклонит это, как насчет 1.0 или 1.?
A + b Буквы?
/ + 1
или
1+ : ASCII соды цифр начинаются от 48(0) до 57(0). ASCII 47 это / а ASCII 58 это :

1 Попробуйте ввести произвольное количество пробелов в начале и в конце.

- Рассмотрите обработку пользовательских действий во время ввода чисел, такую как:
- Время ожидания между цифрами. Это таймаут?
- Повторное редактирование чисел после перед вводом. У вас есть возможность переполнить строку ввода, если программа хранит все, что вы вводите до нажатия (Сейчас мы должны называть эту входную строку, как буфер ввода и считаем этот тест слишком простым для переполнения буфера).
- Рассмотрите возможные значения результатирующей переменной:
- Если программа держит входные значения в виде byte, то их размерность может быть от -128 до + 12. Тесты, сумма в которых выходит за эти границы, может вызвать переполнение.

Следующий пример ставит несколько точек, с которыми, вы, вероятно, знакомы:
- Когда тестируется часть программы, которая хранит и обрабатывает данные, вы должны учитывать:
- Пользовательский интерфейс: По, которое поддерживает получение и ввод данных от пользователя и отображает результаты.
- Хранилище: как программа хранит данные?
- Вычисление и результатирующие переменные: Вычисления, которые производятся с данными и переменные, которые хранят результат вычислений.
- последствия: Как данные будут использованы и как это использование повлияет на них.

Большинство (а может и все) спецификации (или требования или пользовательские истории) двусмысленны и неполны. Для получения большего количества информации вы, вероятно, должны понять это и прибегнуть к стратегиям активного изучения:
- Задавать вопросы.
- Читать внешние материалы.
- Проводить тесты, выходящие за рамки спецификаций

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

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

Книги пост

Ништяк, приехала книга. Уверен, что на выходных дочитаю и расскажу, что да как.
Альбом: office


На днях приедет еще одна, про ATDD. Вообще, удивительная неделя, список покупок примерно такой:
Kahlúa, Kaner, Bailey’s, Gärtner, Cointreau, Whittaker.

среда, 22 января 2014 г.

Радости пост

Полтора года назад не срослось, а сейчас я работаю в одной компании с Юлей Нечаевой. Ы!

Прекрасное

Вот тут вот dibr цитирует:

- "протоколы коррекции ошибок на зашумлённых каналах"... а вот скажи - если тебе придётся писать обмен данными на очень сильно зашумлённом канале, что будешь делать? Скажем, если 99.99% битов приходят с ошибкой?
- ну, если мне удастся добиться 99.99% ошибок в битовом потоке, первое что я сделаю - это поставлю инвертор...

(с) переписка в каком-то технофоруме

вторник, 21 января 2014 г.

Из блога Баха

Оригинал статьи Баха.

RST методология: "Ответственный тестировщик"

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

Ответственный тестировщик

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

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

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

такая ситуация является "грехом" в быстром тестировании. Чтоб практиковать RST, для каждой работы есть ответственный тестировщик, на которого опирается проект (конечно, студенты и непрофессиональные тестировщики могут работать без присмотра в надежде найти ошибку. Но они не будут опорой проекта).

Ответственный тестировщик подобен водителю автомобиля или командиру воздушного судна.

Помощник

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

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

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

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

О книгах

Заказал бумажную The Domain Testing Workbook by Cem Kaner.
Альбом: bug

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

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

UPD: Купил электронную. Завтра прогляжу, стоит ли книга времени, если да - опубликую расписание, ну и посмотрим, буду ли придерживаться.

Рутина

Древняя китайская мудрость гласит: «НИ СЫ!», что означает: «Будь безмятежен, словно цветок лотоса у подножия храма истины».
Весь перевод текста под названием "The Tao Of Programming", Geoffrey James лежит тут:
http://infostart.ru/public/197250/
Рекомендую.

Странный период жизни. Остро чувствуется нехватка пулемета снаружи и дисциплины внутри меня. Хм.

суббота, 18 января 2014 г.

Есть вопрос

Ваше мнение очень важно для нас.


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

Продуктами, которые создавали программисты для программистов я считаю (могу и ошибаться) большинство консольных и не только утилит *nix, nginx, тетрис, арканоид, башорг, тотал коммандер, гит, дварф фортресс, пиджин, майнкрафт.

Продуктами, которые создавались аналитиками для людей я считаю большинство того, что связано с Apple, скайп, варкрафт, весь YOBA геймдев, браузер хром, гта5, фейсбук и инстаграмм

вторник, 14 января 2014 г.

Рутина

Я считаю, ребята жгут. Но в услуги надо добавить комплексный уход за телом.
Альбом: randompics4lj

понедельник, 13 января 2014 г.

Рутина

Философская подборка книг в правильном порядке.

Альбом: home

Рутина

- Интересно, под каким названием услуги этот массаж-салон маскирует шлюх?
- Вакуумное воздействие, очевидно.

суббота, 11 января 2014 г.

О книгах

Программистам, будущим архитекторам продуктов:

Прекратите читать это:
Альбом: bug


Читайте это:
Альбом: bug
Намедни постил картинку, где напротив книги Г. Майерса Искусство тестирования программ было написано, что читаю.
Собственно, дочитал.

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

Дальше - немного цитат и мыслей.

1. О критериях завершения тестирования
Альбом: bug

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

2. Главный принцип локализации ошибок
Альбом: bug


3. О отладке, экспериментах и поиске багов
Альбом: bug

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

4. О бранных алертах
Альбом: bug

Просто понравилось.

4. О том, что полезней всего, но что никто не делает.
Альбом: bug

пятница, 10 января 2014 г.

Хм.

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

А платят мне за то, что я согласен заниматься этим.
Дискас?

среда, 8 января 2014 г.

Так

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

вторник, 7 января 2014 г.

Книг пост

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

Пруфпик (поиск по *тестировани*, отсортировано по году издания):
Альбом: bug


По-моему, одна из немногих действительно новых - Как тестируют в Google Уиттакера. Но ее на прилавках нет, пришлось заказать.
Альбом: bug


P.S. Пост до сих пор не проплачен никем. Ни домом книги, ни гуглом..

суббота, 4 января 2014 г.

Год 2013

Я хуже всех, что ли? Чтоб было.

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

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

Март.
Все еще ищем бойца..

Апрель
Эпично выступили на Nau devel Camp. Съездил на SQA Days.

Май
Сменил номер телефона - ушел от опсоса мотив, который у меня был лет восемь.
Купил велосипед, хех. Чо так долго ждал - неясно.
Нашли бойца в группу АТ - наняли Украинца.

Июнь
Катаюсь на велике и больше не работаю по выходным.

Июль
Убился на велике. Купил шлем, наколенники, гг.

Август
Взяли в группу Ат Таньку. Полгода уговаривал, хех.

Сентябрь
Закончил перевод книги про тестирование.

Октябрь
Готовлюсь сделать еще один доклад на Nau Devel Camp - о том, что тестировщики не нужны.

Ноябрь
Ухожу из Naumen.

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

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


1. Просто так.
Альбом: 2013post

2. Подарок (не мой) одной тестировщице
Альбом: 2013post

3. Мотивационный рисунок подготовки к докладу
Альбом: 2013post

4. Рабочий стол тестировщика
Альбом: 2013post

5. Подарок сестры
Альбом: 2013post

6. Поезд в Самару на Рок на Волге
Альбом: 2013post

7. Поездка на великах
Альбом: 2013post

8. Собственно велик
Альбом: 2013post

9. Плакатик у одной тестировщицы
Альбом: 2013post

10. Все грамоты и сертификаты оставил на прошлом месте
Альбом: 2013post

11. Оленьи ручьи
Альбом: 2013post

12. Просто так
Альбом: 2013post