Иногда кажется, что вместо "Здравствуй" я слышу:
— Хвала вечности, в Найклосте нет новостей.
пятница, 24 января 2014 г.
четверг, 23 января 2014 г.
Рутина
Ни славы, и ни коровы, ни тяжкой короны земной
Пошли мне, Господь, второго, чтоб вытянул петь co мной
Прошу не любви ворованной, ни радостей на денек
Пошли мне, Господь, второго, чтоб не был так одинок.
Чтоб было c кем пасоваться, аукаться через степь
Для сердца, не для оваций, на два голоса спеть
Чтоб кто-нибудь меня понял, не часто, ну хоть разок
Из раненных губ моих поднял царапнутый пулей рожок
И пусть мой товарищ певчий, забыв, что мы сила вдвоем
Меня, побледнев от соперничества, прирежет за общим столом
Прости ему, он до гроба одиночеством окружен
Пошли ему бог второго, такого, как я и он.
На стихи А. Вознесенского.
Высоцкий:
А вот это исполнение мне даже больше нравится.
Пошли мне, Господь, второго, чтоб вытянул петь co мной
Прошу не любви ворованной, ни радостей на денек
Пошли мне, Господь, второго, чтоб не был так одинок.
Чтоб было c кем пасоваться, аукаться через степь
Для сердца, не для оваций, на два голоса спеть
Чтоб кто-нибудь меня понял, не часто, ну хоть разок
Из раненных губ моих поднял царапнутый пулей рожок
И пусть мой товарищ певчий, забыв, что мы сила вдвоем
Меня, побледнев от соперничества, прирежет за общим столом
Прости ему, он до гроба одиночеством окружен
Пошли ему бог второго, такого, как я и он.
На стихи А. Вознесенского.
Высоцкий:
А вот это исполнение мне даже больше нравится.
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 мы представили и объяснили эти идеи тестирования, но не поместили этот список в единую структуру. Мы думаем, что это распространённая проблема. Многие авторы описывают технику, но не исследуют весь ее процесс. Они останавливаются после описания того, что, на их взгляд, было самой важной частью.
Прочтения - да. Поэтому только начало книги:
Секция 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 мы представили и объяснили эти идеи тестирования, но не поместили этот список в единую структуру. Мы думаем, что это распространённая проблема. Многие авторы описывают технику, но не исследуют весь ее процесс. Они останавливаются после описания того, что, на их взгляд, было самой важной частью.
Книги пост
Ништяк, приехала книга. Уверен, что на выходных дочитаю и расскажу, что да как.
На днях приедет еще одна, про ATDD. Вообще, удивительная неделя, список покупок примерно такой:
Kahlúa, Kaner, Bailey’s, Gärtner, Cointreau, Whittaker.
 |
| Альбом: office |
На днях приедет еще одна, про ATDD. Вообще, удивительная неделя, список покупок примерно такой:
Kahlúa, Kaner, Bailey’s, Gärtner, Cointreau, Whittaker.
среда, 22 января 2014 г.
Радости пост
Полтора года назад не срослось, а сейчас я работаю в одной компании с Юлей Нечаевой. Ы!
Прекрасное
Вот тут вот dibr цитирует:
- "протоколы коррекции ошибок на зашумлённых каналах"... а вот скажи - если тебе придётся писать обмен данными на очень сильно зашумлённом канале, что будешь делать? Скажем, если 99.99% битов приходят с ошибкой?
- ну, если мне удастся добиться 99.99% ошибок в битовом потоке, первое что я сделаю - это поставлю инвертор...
(с) переписка в каком-то технофоруме
- "протоколы коррекции ошибок на зашумлённых каналах"... а вот скажи - если тебе придётся писать обмен данными на очень сильно зашумлённом канале, что будешь делать? Скажем, если 99.99% битов приходят с ошибкой?
- ну, если мне удастся добиться 99.99% ошибок в битовом потоке, первое что я сделаю - это поставлю инвертор...
(с) переписка в каком-то технофоруме
вторник, 21 января 2014 г.
Из блога Баха
Оригинал статьи Баха.
RST методология: "Ответственный тестировщик"
В методологии Быстрого тестирования мы выделяем три основные роли: Лидер. Ответственный тестировщик и Помощник. Различия этих ролей ситуационны. Одно и то же лицо может быть помощником в одной ситуации, лидером в другой и ответственным тестировщиком в третьей.
Ответственный тестировщик
Быстрое тестирование - человекоцентрированная методология, так как тестирование это работа, которую может выполнять только человек. Таким образом, тестирование должно происходить под наблюдением людей, в противном случае это буквально и фигурально безответственно. Таким образом ответственный тестировщик - это тестировщик, который берет на себя ответственность за тестирование определенной вещи определенным образом для конкретного проекта. Ответственный тестировщик отвечает за качество теститрования, что значит, что он может оправдать и отстоять тестирования, а также сделать его лучше, если это необходимо. Ответственные тестировщики могут также запрашивать и контролировать помощников, если это необходимо (см. ниже).
Это контрастирует с заводским стилем тестирования, который опирается на инструменты и тексты, а не на людей. В заводской школе тестирования неважно, кто выполняет работу, так как люди взаимозаменяемы. Ответственность в таком мире не мантия на чьих-то плечах, а что-то вроде смога, которым стремятся много не дышать.
пример тестирования без ответственного тестировщика: Человек А пишет текст, называет его "тест-кейс", передает его Человеку Б. Этот человек читает текст и выполняет инструкции. Это может хорошо звучать, но что делать, если у Человека Б недостаточно квалификации, чтоб оценить, правильно ли он понял и провел тест, в то же время, как Человек А не наблюдает за ним, а значит не в состоянии оценить его работу. Это все равно, что машина без водителя. Никто не берет на себя ответственность. Никто не может сказать было ли тестирование проведено хорошо и никто не пример мер, если оно было плохим. Если проблема объявится позже, то каждый из этих людей может справедливо обвинить в ней другого.
такая ситуация является "грехом" в быстром тестировании. Чтоб практиковать RST, для каждой работы есть ответственный тестировщик, на которого опирается проект (конечно, студенты и непрофессиональные тестировщики могут работать без присмотра в надежде найти ошибку. Но они не будут опорой проекта).
Ответственный тестировщик подобен водителю автомобиля или командиру воздушного судна.
Помощник
помощник это тот, кто вносит свой вклад в тестирования, не принимая на себя ответственность за качество работы. другими словами, когда ответственный тестировщик просит кого-нибудь сделать что-то простое, нажать на кнопку, помощник может сделать это, не беспокоясь о том, что на самом деле выполняет миссию тестирования. Помощников не стоит путать с неопытными или неквалифицированными сотрудниками. они могут быть опытными или иметь полезные навыки. главному архитектору, который пришел потестировать, может быть предложено проверить часть продукта и найти интересные ошибки, не ожидая от него обоснования стратегии тестирования. Это работа ответственного тестировщика - наблюдение за людьми, которые предлагают помощь и оценка степени пригодности их работы.
Бета-тестирование происходит исключительно за счет помощников. Но без ответственного тестировщика невозможно глубоко оценить, что было достигнуто. Хороший способ использования бета-тестеров - их организация одним или несколькими ответственными тестировщиками.
Лидер
лидер, это тот, чьи обязанности заключаются в поддержании проекта в состоянии, в котором возможно тестирование, обучение, поддержка и оценка ответственных тестировщиков. Есть по крайней мере два вида лидеров, тест-лид и тест-менеджер. тест-менеджер это тест-лид с дополнительной ответственностью за найм, увольнение, аттестацию и , возможно, бюджет.
В некоторых ситуациях, когда лидер отвечает за тестирование, но у него еще нет ответственных тестировщиков в команде, он сам становится таковым. Лидер в окружении помощников и является ответственным тестировщиком команды.
RST методология: "Ответственный тестировщик"
В методологии Быстрого тестирования мы выделяем три основные роли: Лидер. Ответственный тестировщик и Помощник. Различия этих ролей ситуационны. Одно и то же лицо может быть помощником в одной ситуации, лидером в другой и ответственным тестировщиком в третьей.
Ответственный тестировщик
Быстрое тестирование - человекоцентрированная методология, так как тестирование это работа, которую может выполнять только человек. Таким образом, тестирование должно происходить под наблюдением людей, в противном случае это буквально и фигурально безответственно. Таким образом ответственный тестировщик - это тестировщик, который берет на себя ответственность за тестирование определенной вещи определенным образом для конкретного проекта. Ответственный тестировщик отвечает за качество теститрования, что значит, что он может оправдать и отстоять тестирования, а также сделать его лучше, если это необходимо. Ответственные тестировщики могут также запрашивать и контролировать помощников, если это необходимо (см. ниже).
Это контрастирует с заводским стилем тестирования, который опирается на инструменты и тексты, а не на людей. В заводской школе тестирования неважно, кто выполняет работу, так как люди взаимозаменяемы. Ответственность в таком мире не мантия на чьих-то плечах, а что-то вроде смога, которым стремятся много не дышать.
пример тестирования без ответственного тестировщика: Человек А пишет текст, называет его "тест-кейс", передает его Человеку Б. Этот человек читает текст и выполняет инструкции. Это может хорошо звучать, но что делать, если у Человека Б недостаточно квалификации, чтоб оценить, правильно ли он понял и провел тест, в то же время, как Человек А не наблюдает за ним, а значит не в состоянии оценить его работу. Это все равно, что машина без водителя. Никто не берет на себя ответственность. Никто не может сказать было ли тестирование проведено хорошо и никто не пример мер, если оно было плохим. Если проблема объявится позже, то каждый из этих людей может справедливо обвинить в ней другого.
такая ситуация является "грехом" в быстром тестировании. Чтоб практиковать RST, для каждой работы есть ответственный тестировщик, на которого опирается проект (конечно, студенты и непрофессиональные тестировщики могут работать без присмотра в надежде найти ошибку. Но они не будут опорой проекта).
Ответственный тестировщик подобен водителю автомобиля или командиру воздушного судна.
Помощник
помощник это тот, кто вносит свой вклад в тестирования, не принимая на себя ответственность за качество работы. другими словами, когда ответственный тестировщик просит кого-нибудь сделать что-то простое, нажать на кнопку, помощник может сделать это, не беспокоясь о том, что на самом деле выполняет миссию тестирования. Помощников не стоит путать с неопытными или неквалифицированными сотрудниками. они могут быть опытными или иметь полезные навыки. главному архитектору, который пришел потестировать, может быть предложено проверить часть продукта и найти интересные ошибки, не ожидая от него обоснования стратегии тестирования. Это работа ответственного тестировщика - наблюдение за людьми, которые предлагают помощь и оценка степени пригодности их работы.
Бета-тестирование происходит исключительно за счет помощников. Но без ответственного тестировщика невозможно глубоко оценить, что было достигнуто. Хороший способ использования бета-тестеров - их организация одним или несколькими ответственными тестировщиками.
Лидер
лидер, это тот, чьи обязанности заключаются в поддержании проекта в состоянии, в котором возможно тестирование, обучение, поддержка и оценка ответственных тестировщиков. Есть по крайней мере два вида лидеров, тест-лид и тест-менеджер. тест-менеджер это тест-лид с дополнительной ответственностью за найм, увольнение, аттестацию и , возможно, бюджет.
В некоторых ситуациях, когда лидер отвечает за тестирование, но у него еще нет ответственных тестировщиков в команде, он сам становится таковым. Лидер в окружении помощников и является ответственным тестировщиком команды.
О книгах
Заказал бумажную The Domain Testing Workbook by Cem Kaner.
На днях куплю электронную. Попробую перевести не за два с половиной года, как предыдущую, а справиться за год.
Это все под позитивным влиянием Наташи Руколь. Она берет количеством.
UPD: Купил электронную. Завтра прогляжу, стоит ли книга времени, если да - опубликую расписание, ну и посмотрим, буду ли придерживаться.
 |
| Альбом: bug |
На днях куплю электронную. Попробую перевести не за два с половиной года, как предыдущую, а справиться за год.
Это все под позитивным влиянием Наташи Руколь. Она берет количеством.
UPD: Купил электронную. Завтра прогляжу, стоит ли книга времени, если да - опубликую расписание, ну и посмотрим, буду ли придерживаться.
Рутина
Древняя китайская мудрость гласит: «НИ СЫ!», что означает: «Будь безмятежен, словно цветок лотоса у подножия храма истины».
Весь перевод текста под названием "The Tao Of Programming", Geoffrey James лежит тут:
http://infostart.ru/public/197250/
Рекомендую.
Странный период жизни. Остро чувствуется нехватка пулемета снаружи и дисциплины внутри меня. Хм.
Весь перевод текста под названием "The Tao Of Programming", Geoffrey James лежит тут:
http://infostart.ru/public/197250/
Рекомендую.
Странный период жизни. Остро чувствуется нехватка пулемета снаружи и дисциплины внутри меня. Хм.
суббота, 18 января 2014 г.
Есть вопрос
Ваше мнение очень важно для нас.
Для зануд и умников: Что означает для вас слово Лучше выберете сами. Успешней, качественней, больше нравится лично вам, нужно миру.
Продуктами, которые создавали программисты для программистов я считаю (могу и ошибаться) большинство консольных и не только утилит *nix, nginx, тетрис, арканоид, башорг, тотал коммандер, гит, дварф фортресс, пиджин, майнкрафт.
Продуктами, которые создавались аналитиками для людей я считаю большинство того, что связано с Apple, скайп, варкрафт, весь YOBA геймдев, браузер хром, гта5, фейсбук и инстаграмм
Для зануд и умников: Что означает для вас слово Лучше выберете сами. Успешней, качественней, больше нравится лично вам, нужно миру.
Продуктами, которые создавали программисты для программистов я считаю (могу и ошибаться) большинство консольных и не только утилит *nix, nginx, тетрис, арканоид, башорг, тотал коммандер, гит, дварф фортресс, пиджин, майнкрафт.
Продуктами, которые создавались аналитиками для людей я считаю большинство того, что связано с Apple, скайп, варкрафт, весь YOBA геймдев, браузер хром, гта5, фейсбук и инстаграмм
вторник, 14 января 2014 г.
Рутина
Я считаю, ребята жгут. Но в услуги надо добавить комплексный уход за телом.
 |
| Альбом: randompics4lj |
понедельник, 13 января 2014 г.
Рутина
- Интересно, под каким названием услуги этот массаж-салон маскирует шлюх?
- Вакуумное воздействие, очевидно.
- Вакуумное воздействие, очевидно.
суббота, 11 января 2014 г.
Намедни постил картинку, где напротив книги Г. Майерса Искусство тестирования программ было написано, что читаю.
Собственно, дочитал.
Книга - не откровение, не шедевр и не мастрид, но вполне себе заслуживает место на полке и времени для прочтения.
Плюсы - в очередной раз повторяет идеи, которые все знают, но которыми не пользуются, а также - подкидывает пару новых.
Из минусов - слишком много внимания тому, как найти классы эквивалентности и слишком мало - тому, что с ними потом делать, как правильно применять не в рамках сессии или теста, а в рамках стратегии.
Дальше - немного цитат и мыслей.
1. О критериях завершения тестирования
Майерс, в свою очередь, предлагает простой критерий - количество найденных ошибок. Первая мысль - фи-фи, на вкус и цвет все фломастеры и баги разные, нельзя же тупо числом. А потом делаешь следующий шаг и понимаешь, что точность остальных методов тоже - плюс-минус сто процентов, а этот вариант, в отличие от остальных, позволяет зря не тратить время на тестирование фичи полной багов, а сразу вернуть программисту.
2. Главный принцип локализации ошибок
3. О отладке, экспериментах и поиске багов
Да, черт возьми! Как по мне - самый шик: найти багу, а потом запустить приложение и удостовериться в том, что она есть. Современные средства разработки стирают грань между не тратить время на рутину и не думать.
4. О бранных алертах
Просто понравилось.
4. О том, что полезней всего, но что никто не делает.
Собственно, дочитал.
Книга - не откровение, не шедевр и не мастрид, но вполне себе заслуживает место на полке и времени для прочтения.
Плюсы - в очередной раз повторяет идеи, которые все знают, но которыми не пользуются, а также - подкидывает пару новых.
Из минусов - слишком много внимания тому, как найти классы эквивалентности и слишком мало - тому, что с ними потом делать, как правильно применять не в рамках сессии или теста, а в рамках стратегии.
Дальше - немного цитат и мыслей.
1. О критериях завершения тестирования
 |
| Альбом: bug |
Майерс, в свою очередь, предлагает простой критерий - количество найденных ошибок. Первая мысль - фи-фи, на вкус и цвет все фломастеры и баги разные, нельзя же тупо числом. А потом делаешь следующий шаг и понимаешь, что точность остальных методов тоже - плюс-минус сто процентов, а этот вариант, в отличие от остальных, позволяет зря не тратить время на тестирование фичи полной багов, а сразу вернуть программисту.
2. Главный принцип локализации ошибок
 |
| Альбом: bug |
3. О отладке, экспериментах и поиске багов
 |
| Альбом: bug |
Да, черт возьми! Как по мне - самый шик: найти багу, а потом запустить приложение и удостовериться в том, что она есть. Современные средства разработки стирают грань между не тратить время на рутину и не думать.
4. О бранных алертах
 |
| Альбом: bug |
Просто понравилось.
4. О том, что полезней всего, но что никто не делает.
 |
| Альбом: bug |
пятница, 10 января 2014 г.
Хм.
Иногда у меня возникает ощущение, что я нахожу ошибки не потому, что я весь из себя такой тестировщик, а потому что я только и делаю что топчу продукт.
Рано или поздно я просто натыкаюсь на все более или менее серьезные ошибки. Просто по статистике. Потому что кроме меня в группе разработки этого никто не делает.
А платят мне за то, что я согласен заниматься этим.
Дискас?
Рано или поздно я просто натыкаюсь на все более или менее серьезные ошибки. Просто по статистике. Потому что кроме меня в группе разработки этого никто не делает.
А платят мне за то, что я согласен заниматься этим.
Дискас?
среда, 8 января 2014 г.
Так
Раньше при встрече приподнимали шляпу. Сейчас - достают из уха наушник. В знак особого уважения - достают два.
Все именно так.
Все именно так.
вторник, 7 января 2014 г.
Книг пост
В основном, для Даши avguosta пост.
Я серьезно отношусь к книгам, поэтому по твоему совету сходил в дом книги, что на валека 12. Кстати, тебя там запомнили. Попросил показать полку, с которой ты купила книгу, а потом попросил пустить меня в каталог.
К сожалению, ни на полке, ни в каталоге ничего нового и интересного для меня нет.
Пруфпик (поиск по *тестировани*, отсортировано по году издания):
По-моему, одна из немногих действительно новых - Как тестируют в Google Уиттакера. Но ее на прилавках нет, пришлось заказать.
P.S. Пост до сих пор не проплачен никем. Ни домом книги, ни гуглом..
Я серьезно отношусь к книгам, поэтому по твоему совету сходил в дом книги, что на валека 12. Кстати, тебя там запомнили. Попросил показать полку, с которой ты купила книгу, а потом попросил пустить меня в каталог.
К сожалению, ни на полке, ни в каталоге ничего нового и интересного для меня нет.
Пруфпик (поиск по *тестировани*, отсортировано по году издания):
 |
| Альбом: bug |
По-моему, одна из немногих действительно новых - Как тестируют в Google Уиттакера. Но ее на прилавках нет, пришлось заказать.
 |
| Альбом: bug |
P.S. Пост до сих пор не проплачен никем. Ни домом книги, ни гуглом..
суббота, 4 января 2014 г.
Год 2013
Я хуже всех, что ли? Чтоб было.
Январь
Провели городскую сессию тестирования. Да, мечта проводить раз хотя бы в полгода разбилась о мою лень.
Начал играть в ingress.
Из группы АТ ушел Даниил.
Февраль
Интенсивно ищу бойца.
Первый пост на хабре.
Из компании ушли хорошие люди, мда.
Март.
Все еще ищем бойца..
Апрель
Эпично выступили на Nau devel Camp. Съездил на SQA Days.
Май
Сменил номер телефона - ушел от опсоса мотив, который у меня был лет восемь.
Купил велосипед, хех. Чо так долго ждал - неясно.
Нашли бойца в группу АТ - наняли Украинца.
Июнь
Катаюсь на велике и больше не работаю по выходным.
Июль
Убился на велике. Купил шлем, наколенники, гг.
Август
Взяли в группу Ат Таньку. Полгода уговаривал, хех.
Сентябрь
Закончил перевод книги про тестирование.
Октябрь
Готовлюсь сделать еще один доклад на Nau Devel Camp - о том, что тестировщики не нужны.
Ноябрь
Ухожу из Naumen.
Декабрь
Выиграл футболку на питерской конференции тестеров, а вообще - какое-то радиомолчание.
То ли учусь, то ли вспоминаю то, что давно забыл.
Год
Ни денег, ни ума не нажил.
Оставил после себя группу - на взлете (со мной могло быть и болото), там самым обеспечил бойцам, а особенно Таньке - рост. Ушел из автоматизации в ручное тестирование.
Конец года поставил длинный ряд вопросов, ответы на которые предстоит дать именно мне, поэтому я надеюсь, что через год аналогичный пост будет намного интересней - там я озвучу и вопросы и ответы.
1. Просто так.
2. Подарок (не мой) одной тестировщице
3. Мотивационный рисунок подготовки к докладу
4. Рабочий стол тестировщика
5. Подарок сестры
6. Поезд в Самару на Рок на Волге
7. Поездка на великах
8. Собственно велик
9. Плакатик у одной тестировщицы
10. Все грамоты и сертификаты оставил на прошлом месте
11. Оленьи ручьи
12. Просто так
Январь
Провели городскую сессию тестирования. Да, мечта проводить раз хотя бы в полгода разбилась о мою лень.
Начал играть в 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 |
Подписаться на:
Сообщения (Atom)