суббота, 28 декабря 2013 г.
Лейтмотив этого дня
Он войдет никого не спросив,
Ты полюбишь его не сразу.
С первого взгляда он некрасив,
Со второго - безобразен.
Только речи его горячи,
Только прочь сомнения, прочь!
Самый звонкий крик - тишина,
Самый яркий свет - ночь.
Все бы было иначе когда бы
Можно было совсем не дышать.
Все бы было иначе когда бы
Он не знал бы как ты хороша.
Только речи его горячи,
Только прочь сомнения, прочь!
Самый звонкий крик - тишина,
Самый яркий свет - ночь.
Он озяб, его гонит луна,
Он во власти неведомых сил.
И теперь с него будет сполна:
Будь что будет, спаси-пронеси.
Ты не знаешь как сходят с ума,
Как вода разольется точь в точь.
Самый звонкий крик - тишина,
Самый яркий свет - ...
Хм.
четверг, 19 декабря 2013 г.
James Bach’s Blog - Justifying Real Acceptance Testing
Перевод статьи Баха
http://www.satisfice.com/blog/archives/973
Justifying Real Acceptance Testing
В защиту настоящего приемочного тестирования
Этот пост не том виде тестирования, о котором люди говорят, когда близится релиз и принимается решение о выпуске. Для этого у меня есть другое слово. Я называю это "тестирование" или что-то вроде финального тестирования или тестирования релиза. Во многих проектах такое тестирования проводится настолько поверхностным образом, что лучше описать его как проверку, в соответствии с отличиями проверок от тестирования, о которых я уже писал в этом блоге. как отмечает Майкл болтон, такие проверки можно лучше описать, как проверки на отказ, так как "fail" дает основания заявить, что продукт не будет готов, пока некоторое количество "passes" не покажет, что он готов.
Приемочное тестирование может быть определено несколькими способами. Этот пост о том, что я считаю настоящим приемочным тестированием, которое я определяю как тестирование потенциальным акцептором (заказчиком), выполняемое с целью получения информации для принятия (приобретения, возможности полагаться) продукта.
Нужно ли нам приемочное тестирование?
До тех пор, пока бизнес принимает решение полагаться на какой-либо компонент или сервис, существует опасность, что продукт сломается и бизнес пострадает. Один из подходов к решению этой проблемы - стадное принятие решения: следуй за большей частью роя, выбирай популярный продукт, который рекламируется, о котором известно, что он делает то, что вам нужно и у тебя все, скорее всего, будет в порядке. Я поступил так со смартфоном, защищенным ноутбуков, файлообменным сервисом и так далее - и получил хорошие результаты, хотя иногда и был разочарован.
У меня небольшой бизнес. Я шустрый по сравнению с почти любой другой компанией в мире. Мое приемочное тестирование обычно принимает форму подписки на обслуживание продукта, который я приобретаю или загрузки "базовой" версии продукта. Я работаю с ними и наблюдаю за тем, как я себя чувствую. Таким образом, я научился любить Dropbox, несмотря на тревожную ситуацию в области безопасности (я не могу заблокировать мои Dropbox файлы) или на значительную вероятность того, что большие файлы будут повреждены (я не доверяю ему ничего больше половины гига).
Но что, если бы я консультировал большую компанию по услуге или продукту, который будет использоваться и на который будут полагаться сотни и тысячи сотрудников? Что делать, если продукт создан по специальному заказу только для них? В таком случае приемочное тестирование становится важным.
Гарантирует ли соглашение об уровне обслуживания (SLA) работоспособность продукта?
Есть несколько проблем связанных с возможностью полагаться на обещания вендоров. Во-первых, вендоры обычно не обещают полного удовлетворения. Уровень услуги в контракте очень узко и конкретно описан. Это значит, что все, о чем вы не подумали и не включили в контракт - не будет прикрыто. Тестирование - процесс, который помогает выявить часть сервиса, которая важна для нас.
Во-вторых, есть проблема со временем. К тому времени, когда вы обнаружите проблемы в продукте вендора, вы уже можете зависеть от него. Возможно, вы уже широко развернули продукт. Может быть, уже слишком поздно отступить и изменить решение. Может быть, ваша компания обговорила юридически такой вариант, но практически это неисполнимо. Если ваш вендор очень маленький, он не может позволить себе быстро исправить свой продукт. Если ваш поставщик очень большой, он может позволить себе еле переставлять ноги по пути к исправлению проблемы.
Приемочное тестирование заставляет вендора серьезней относиться к качеству
приемочное тестирование никогда не должно проводиться силами вендора. Однажды я был нанят вендором для пентеста их продукта, чтоб успокоить клиента. Но у вендора нет ни стимула помочь мне добиться успеха в моей, ни желания добросовестно сообщать о уязвимостях, которые я обнаружил. Было бы гораздо лучше, если бы клиент нанял меня.
Только у принимающей стороны есть стимул хорошо провести тестирование. В приемочном тестировании не должно быть жестко ограниченного запланированного набора специфических проверок, иначе поставщик будет уверен, что пройдет их. Тестирование должно быть непредсказуемым, чтоб у поставщика был стимул сделать продукт удовлетворяющим требования в общем. Оно должно быть адаптивным (исследовательским), таким, чтоб любое слабое место, что вы нашли, можно было исследовать и использовать.
Вендору нужны ваши деньги. Если ваша компания достаточно большая, а вендор голоден, он сдвинет горы, чтоб заставить продукт хорошо работать если знают, что вы обратите на это внимание. Приемочное тестирование, проведенное творчес кой и квалифицированной командой тестировщиков, держит поставщика на кончиках пальцев.
Если вы проведете тестирование до принятия решения о том, что вы принимаете продукт, у вас появится шанс избежать катастрофы - слишком поздно обнаружить, что продукт - лимон disaster of discovering too late that the product is a lemon, идиома такая, видимо).
Мой менеджмент не задумывается о вопросе приемо-сдаточных испытаний. Что мне делать?
1. Привести аргументы, изложенные выше.
2. Формально сообщить менеджменту об этом (в письменной форме)
Принимают решения в области рисков бизнеса - руководство. Они могут считать, что о риске не стоит беспокоиться. В этом случае вы должны ждать и наблюдать. Людей легче убедить яркими впечатлениями, а не абстрактными принципами.
1. Соберите конкретные примеры проблем, о которых говорите. Какие баги вы нашли в продуктах поставщиков?
2. Соберите новости и багрепорты о продуктах ваших (или других) вендоров, которые были наиболее разрушительными.
3. В случае, если вы собираетесь провести небольшое приемочное тестирование, запишите все, что вы найдете и будьте готовы напомнить руководству о этой истории.
http://www.satisfice.com/blog/archives/973
Justifying Real Acceptance Testing
В защиту настоящего приемочного тестирования
Этот пост не том виде тестирования, о котором люди говорят, когда близится релиз и принимается решение о выпуске. Для этого у меня есть другое слово. Я называю это "тестирование" или что-то вроде финального тестирования или тестирования релиза. Во многих проектах такое тестирования проводится настолько поверхностным образом, что лучше описать его как проверку, в соответствии с отличиями проверок от тестирования, о которых я уже писал в этом блоге. как отмечает Майкл болтон, такие проверки можно лучше описать, как проверки на отказ, так как "fail" дает основания заявить, что продукт не будет готов, пока некоторое количество "passes" не покажет, что он готов.
Приемочное тестирование может быть определено несколькими способами. Этот пост о том, что я считаю настоящим приемочным тестированием, которое я определяю как тестирование потенциальным акцептором (заказчиком), выполняемое с целью получения информации для принятия (приобретения, возможности полагаться) продукта.
Нужно ли нам приемочное тестирование?
До тех пор, пока бизнес принимает решение полагаться на какой-либо компонент или сервис, существует опасность, что продукт сломается и бизнес пострадает. Один из подходов к решению этой проблемы - стадное принятие решения: следуй за большей частью роя, выбирай популярный продукт, который рекламируется, о котором известно, что он делает то, что вам нужно и у тебя все, скорее всего, будет в порядке. Я поступил так со смартфоном, защищенным ноутбуков, файлообменным сервисом и так далее - и получил хорошие результаты, хотя иногда и был разочарован.
У меня небольшой бизнес. Я шустрый по сравнению с почти любой другой компанией в мире. Мое приемочное тестирование обычно принимает форму подписки на обслуживание продукта, который я приобретаю или загрузки "базовой" версии продукта. Я работаю с ними и наблюдаю за тем, как я себя чувствую. Таким образом, я научился любить Dropbox, несмотря на тревожную ситуацию в области безопасности (я не могу заблокировать мои Dropbox файлы) или на значительную вероятность того, что большие файлы будут повреждены (я не доверяю ему ничего больше половины гига).
Но что, если бы я консультировал большую компанию по услуге или продукту, который будет использоваться и на который будут полагаться сотни и тысячи сотрудников? Что делать, если продукт создан по специальному заказу только для них? В таком случае приемочное тестирование становится важным.
Гарантирует ли соглашение об уровне обслуживания (SLA) работоспособность продукта?
Есть несколько проблем связанных с возможностью полагаться на обещания вендоров. Во-первых, вендоры обычно не обещают полного удовлетворения. Уровень услуги в контракте очень узко и конкретно описан. Это значит, что все, о чем вы не подумали и не включили в контракт - не будет прикрыто. Тестирование - процесс, который помогает выявить часть сервиса, которая важна для нас.
Во-вторых, есть проблема со временем. К тому времени, когда вы обнаружите проблемы в продукте вендора, вы уже можете зависеть от него. Возможно, вы уже широко развернули продукт. Может быть, уже слишком поздно отступить и изменить решение. Может быть, ваша компания обговорила юридически такой вариант, но практически это неисполнимо. Если ваш вендор очень маленький, он не может позволить себе быстро исправить свой продукт. Если ваш поставщик очень большой, он может позволить себе еле переставлять ноги по пути к исправлению проблемы.
Приемочное тестирование заставляет вендора серьезней относиться к качеству
приемочное тестирование никогда не должно проводиться силами вендора. Однажды я был нанят вендором для пентеста их продукта, чтоб успокоить клиента. Но у вендора нет ни стимула помочь мне добиться успеха в моей, ни желания добросовестно сообщать о уязвимостях, которые я обнаружил. Было бы гораздо лучше, если бы клиент нанял меня.
Только у принимающей стороны есть стимул хорошо провести тестирование. В приемочном тестировании не должно быть жестко ограниченного запланированного набора специфических проверок, иначе поставщик будет уверен, что пройдет их. Тестирование должно быть непредсказуемым, чтоб у поставщика был стимул сделать продукт удовлетворяющим требования в общем. Оно должно быть адаптивным (исследовательским), таким, чтоб любое слабое место, что вы нашли, можно было исследовать и использовать.
Вендору нужны ваши деньги. Если ваша компания достаточно большая, а вендор голоден, он сдвинет горы, чтоб заставить продукт хорошо работать если знают, что вы обратите на это внимание. Приемочное тестирование, проведенное творчес кой и квалифицированной командой тестировщиков, держит поставщика на кончиках пальцев.
Если вы проведете тестирование до принятия решения о том, что вы принимаете продукт, у вас появится шанс избежать катастрофы - слишком поздно обнаружить, что продукт - лимон disaster of discovering too late that the product is a lemon, идиома такая, видимо).
Мой менеджмент не задумывается о вопросе приемо-сдаточных испытаний. Что мне делать?
1. Привести аргументы, изложенные выше.
2. Формально сообщить менеджменту об этом (в письменной форме)
Принимают решения в области рисков бизнеса - руководство. Они могут считать, что о риске не стоит беспокоиться. В этом случае вы должны ждать и наблюдать. Людей легче убедить яркими впечатлениями, а не абстрактными принципами.
1. Соберите конкретные примеры проблем, о которых говорите. Какие баги вы нашли в продуктах поставщиков?
2. Соберите новости и багрепорты о продуктах ваших (или других) вендоров, которые были наиболее разрушительными.
3. В случае, если вы собираетесь провести небольшое приемочное тестирование, запишите все, что вы найдете и будьте готовы напомнить руководству о этой истории.
среда, 18 декабря 2013 г.
Рекламы пост
Пост все еще не проплачен.
У нас есть ребята, делающие крайне годную и полезную приложуху для пользователей общественного транспорта.
Проверил, пользуюсь, удобно. Но есть куда стремиться. Чтоб ребятам было на что стремиться, поддержал их материально на boomstarter.
Ссылке:
Приложение: https://play.google.com/store/apps/details?id=ru.UseIT.Interface
Поддержать: https://boomstarter.ru/projects/mikeavdeev/etransport
У нас есть ребята, делающие крайне годную и полезную приложуху для пользователей общественного транспорта.
 |
| Альбом: randompics4lj |
Проверил, пользуюсь, удобно. Но есть куда стремиться. Чтоб ребятам было на что стремиться, поддержал их материально на boomstarter.
Ссылке:
Приложение: https://play.google.com/store/apps/details?id=ru.UseIT.Interface
Поддержать: https://boomstarter.ru/projects/mikeavdeev/etransport
вторник, 17 декабря 2013 г.
Ы!
У Шутника Дануты замечательные хоррор-хокку:
эти таблетки
практически безопасны
только вот зубы
ты убедился
что хорошо его запер?
что там за шум в при
вы не могли бы
четче произнести вслух
приглашение
мне показалось
здесь что-то есть в подвале
ой оно шеве
не бойся меня
где твои мама и папа?
эй что ты дела
да ладно тебе
это детские сказки
давай откроем.
эти таблетки
практически безопасны
только вот зубы
ты убедился
что хорошо его запер?
что там за шум в при
вы не могли бы
четче произнести вслух
приглашение
мне показалось
здесь что-то есть в подвале
ой оно шеве
не бойся меня
где твои мама и папа?
эй что ты дела
да ладно тебе
это детские сказки
давай откроем.
пятница, 13 декабря 2013 г.
Так
Возможность заранее записаться (забронировать?) и выбрать врача неотложной помощи - это медитативно.
четверг, 12 декабря 2013 г.
Так
Есть одно полезное свойство, которое я приобрел за этот год: научился не дочитывать книги, которые мне не нравятся.
Раньше, не так уж и давно, любая хрень, пару страниц которой я выдержал, всерьез рисковала быть дочитанной до конца. Читаю я быстро, это не было проблемой, пока у меня была куча времени. Но стоило исчезнуть свободному времени...
К примеру Стейнбек, "Квартал Тортилья-флэт". Черт-побери повесть о алкашах, гопниках и мелких ворах. Зачем, кому это интересно? Я должен сопереживать героям?
Впрочем ладно, на вкус и цвет..
Это самое новоприобретенное свойство дало презабавные последствия: я обнаружил, что в мире немного Книг. А Книг, которые нужны мне именно сейчас - вообще исчезающе мало. До этого у меня было ощущение легкого сожаления и грусти, что я за всю свою жизнь не успею прочесть всего того, что уже создали и создают писатели. Теперь именно этот факт вызывает у меня радость, а грущу я оттого, что так и не смогу откопать те несколько миллионов страниц, рази которых стоит копать.
М-да.
К чему это я? Из около 30 книг, что я добавил в план благодаря вам, уже минус семь. Из них четыре в мусорку.
Раньше, не так уж и давно, любая хрень, пару страниц которой я выдержал, всерьез рисковала быть дочитанной до конца. Читаю я быстро, это не было проблемой, пока у меня была куча времени. Но стоило исчезнуть свободному времени...
К примеру Стейнбек, "Квартал Тортилья-флэт". Черт-побери повесть о алкашах, гопниках и мелких ворах. Зачем, кому это интересно? Я должен сопереживать героям?
Впрочем ладно, на вкус и цвет..
Это самое новоприобретенное свойство дало презабавные последствия: я обнаружил, что в мире немного Книг. А Книг, которые нужны мне именно сейчас - вообще исчезающе мало. До этого у меня было ощущение легкого сожаления и грусти, что я за всю свою жизнь не успею прочесть всего того, что уже создали и создают писатели. Теперь именно этот факт вызывает у меня радость, а грущу я оттого, что так и не смогу откопать те несколько миллионов страниц, рази которых стоит копать.
М-да.
К чему это я? Из около 30 книг, что я добавил в план благодаря вам, уже минус семь. Из них четыре в мусорку.
вторник, 10 декабря 2013 г.
понедельник, 9 декабря 2013 г.
Рутина
А вы знали, что на рынке стремления к прекрасному существует такое?
- Сахарная эпиляция подбородка женская
А у сэра Терри Пратчетта гномы женского пола тоже бородатые...
- Гальваническая чистка лица
Цинкование кузова...
- Мытье волос женское
Чем? Чем оно отличается от мытья длинных мужских волос?
- Лимфодренажный массаж
Акведуки, чистка стоков...
- Парафинотерапия рук женская
Да, руки в кипящий воск!
- Стрижка горячими ножницами
Увеселения и казни(с)tavlla
- Горячий маникюр
Продолжаем пытки!
А еще, а еще(с) существует "Академия Эпиляции". Академия. Ну ептыть... Дердена на вас нет.
- Сахарная эпиляция подбородка женская
А у сэра Терри Пратчетта гномы женского пола тоже бородатые...
- Гальваническая чистка лица
Цинкование кузова...
- Мытье волос женское
Чем? Чем оно отличается от мытья длинных мужских волос?
- Лимфодренажный массаж
Акведуки, чистка стоков...
- Парафинотерапия рук женская
Да, руки в кипящий воск!
- Стрижка горячими ножницами
Увеселения и казни(с)tavlla
- Горячий маникюр
Продолжаем пытки!
А еще, а еще(с) существует "Академия Эпиляции". Академия. Ну ептыть... Дердена на вас нет.
суббота, 7 декабря 2013 г.
Рутина
Оказывается, есть не только самолетики, но и паравозики! Они там двигаются!
Как то так:
 |
| Альбом: office |
Как то так:
 |
| Альбом: randompics4lj |
четверг, 5 декабря 2013 г.
суббота, 30 ноября 2013 г.
Рутина
Занятная статья.
http://habrahabr.ru/company/yandex/blog/204192/
Особенно интересно то, что вот почти все эти штуки мы с ребятами в свое время создавали, может даже и покруче местами. Но как излагает! Модификаторы, билдер, граф состояний...
Да, надо уметь продавать тестирование.
http://habrahabr.ru/company/yandex/blog/204192/
Особенно интересно то, что вот почти все эти штуки мы с ребятами в свое время создавали, может даже и покруче местами. Но как излагает! Модификаторы, билдер, граф состояний...
Да, надо уметь продавать тестирование.
понедельник, 25 ноября 2013 г.
воскресенье, 24 ноября 2013 г.
Быстрое тестирование, Кобб
Начал читать: Роберт Калбертсон, Крис Браун, Гэри Кобб, "Быстрое тестирование".
Книга неплохая, серьезно. Но она точно не про быстрое. Она даже скорее про неспешное и вдумчивое, да...
Вот тут про нее хорошо сказал Сергей Мартыненко
* Ни о каком "Быстром тестировании" речь там не идет. Это теория обычного, классического тестирования.
* Определения, даваемые в книге мягко говоря расходятся с общеупотребительными. См. например "валидация" и "верификация" стр 18.
* Многие положения книги спорны, но это обычное дело. не обращайте внимание.
* Книгу нужно обязательно купить, т.к. это практически единственный источник на русском языке, где приводятся примеры заполненных документов. СМ. главы 13-16. По этой же причине книгу стоит приобрести системному аналитику.
 |
| Альбом: bug |
Книга неплохая, серьезно. Но она точно не про быстрое. Она даже скорее про неспешное и вдумчивое, да...
Вот тут про нее хорошо сказал Сергей Мартыненко
* Ни о каком "Быстром тестировании" речь там не идет. Это теория обычного, классического тестирования.
* Определения, даваемые в книге мягко говоря расходятся с общеупотребительными. См. например "валидация" и "верификация" стр 18.
* Многие положения книги спорны, но это обычное дело. не обращайте внимание.
* Книгу нужно обязательно купить, т.к. это практически единственный источник на русском языке, где приводятся примеры заполненных документов. СМ. главы 13-16. По этой же причине книгу стоит приобрести системному аналитику.
пятница, 22 ноября 2013 г.
Неоплаченной рекламы пост
Есть такая программка Zello
Делает из андроида подобие рации.
В повседневной жизни нафиг не нужна, но для движух, когда требуется координация голосом распределенной команды - отличная штука.
Живет и на слабом канале.
Я в ней Wolonter.
Делает из андроида подобие рации.
В повседневной жизни нафиг не нужна, но для движух, когда требуется координация голосом распределенной команды - отличная штука.
Живет и на слабом канале.
Я в ней Wolonter.
вторник, 19 ноября 2013 г.
Есть вопросы
Друзья, а накидайте мне названий всяких зачотных книг, которые вы только что прочли или вот вот собираетесь. Художественных и не очень. Пару штук каждый, а? Пожалуйста. Еще хочу найти занятное из психологии для самых маленьких типа Берна.
Только не про работу, про работу у меня есть.
Вот что я прочел совсем недавно:
Рой, Крайтон
Волоколамское шоссе, Бек - перечитал
Стажеры, Путь на Амальтею, Страна багровых туч - перечитал
Кукольник, Олди
Только не про работу, про работу у меня есть.
Вот что я прочел совсем недавно:
Рой, Крайтон
Волоколамское шоссе, Бек - перечитал
Стажеры, Путь на Амальтею, Страна багровых туч - перечитал
Кукольник, Олди
среда, 13 ноября 2013 г.
I'm done with you
Сегодня мой последний день работы в Naumen.
Я пришел сюда 21 апреля 2009 года, четыре года и 7 месяцев назад.
Я отправил 4463 письма и написал около тысячи тестов.
Это был интересный период моей жизни и в первую очередь я благодарен компании и нашему SD за возможности которые мне дали.
За возможность учиться одинаково быстро работать в любой операционной системе, но при этом иметь свои предпочтения.
За возможность узнать новую профессию - сотрудника техподдержки, но не забывать, что я тестировщик.
За возможность учиться новым умным словам, но не забывать, что люди важнее.
За книги, которые в изобилии лежали на полках. Те, что по тестированию, я прочел.
За право отстаивать свою точку зрения и соглашаться с чужой.
За возможность хотеть чего-то нового и создавать это.
За возможность задавать вопросы на конференциях, а затем - создавать конференции.
За возможность выбирать с кем я буду работать.
За помощь в реализации идей.
За то, что ценили преданность делу не меньше, чем опыт и знания.
Дальше - картинки на память:
Я пришел сюда 21 апреля 2009 года, четыре года и 7 месяцев назад.
Я отправил 4463 письма и написал около тысячи тестов.
Это был интересный период моей жизни и в первую очередь я благодарен компании и нашему SD за возможности которые мне дали.
За возможность учиться одинаково быстро работать в любой операционной системе, но при этом иметь свои предпочтения.
За возможность узнать новую профессию - сотрудника техподдержки, но не забывать, что я тестировщик.
За возможность учиться новым умным словам, но не забывать, что люди важнее.
За книги, которые в изобилии лежали на полках. Те, что по тестированию, я прочел.
За право отстаивать свою точку зрения и соглашаться с чужой.
За возможность хотеть чего-то нового и создавать это.
За возможность задавать вопросы на конференциях, а затем - создавать конференции.
За возможность выбирать с кем я буду работать.
За помощь в реализации идей.
За то, что ценили преданность делу не меньше, чем опыт и знания.
Дальше - картинки на память:
 |
| Альбом: nauLast |
 |
| Альбом: nauLast |
 |
| Альбом: nauLast |
 |
| Альбом: nauLast |
 |
| Альбом: nauLast |
 |
| Альбом: nauLast |
 |
| Альбом: nauLast |
 |
| Альбом: nauLast |
 |
| Альбом: nauLast |
 |
| Альбом: nauLast |
 |
| Альбом: nauLast |
 |
| Альбом: nauLast |
 |
| Альбом: nauLast |
 |
| Альбом: nauLast |
 |
| Альбом: nauLast |
 |
| Альбом: nauLast |
 |
| Альбом: nauLast |
 |
| Альбом: nauLast |
 |
| Альбом: nauLast |
 |
| Альбом: nauLast |
 |
| Альбом: nauLast |
 |
| Альбом: nauLast |
 |
| Альбом: nauLast |
 |
| Альбом: nauLast |
среда, 6 ноября 2013 г.
вторник, 5 ноября 2013 г.
В кабинете по результатам соревнования звучит такое:
- Я не обязан знать вулканский!
Спасибо khazzar и товарищам за зачОтную движуху.
- Я не обязан знать вулканский!
Спасибо khazzar и товарищам за зачОтную движуху.
четверг, 31 октября 2013 г.
Рутина
Хорошая песня, лет шесть назад хорошо пели мы ее.
А в стране дураков дураков не осталось.
Все приехали к нам погулять, отдохнуть.
А у нас, как всегда, темнота и усталость,
А у нас - все путем. Только где он, тот путь?
Припев:
Под тяжкий вздох хлопну стакан.
Сам себе Бог, сам себе пан.
В душу залез - там темный лес,
В лесу дупло, в дупле тепло.
А у нас днем с огнем, а в потемках без свечки
Согреваемся в стужу, а сохнем в воде.
И вокруг мельтешат, в основном, человечки,
И все меньше и меньше нормальных людей.
Припев.
А в страну дураков дураки не вернуться,
Им без наших теперь ни туда, ни сюда.
И вздыхают басы, кудри по ветру вьются,
И осталось в войне победить, как всегда.
А в стране дураков дураков не осталось.
Все приехали к нам погулять, отдохнуть.
А у нас, как всегда, темнота и усталость,
А у нас - все путем. Только где он, тот путь?
Припев:
Под тяжкий вздох хлопну стакан.
Сам себе Бог, сам себе пан.
В душу залез - там темный лес,
В лесу дупло, в дупле тепло.
А у нас днем с огнем, а в потемках без свечки
Согреваемся в стужу, а сохнем в воде.
И вокруг мельтешат, в основном, человечки,
И все меньше и меньше нормальных людей.
Припев.
А в страну дураков дураки не вернуться,
Им без наших теперь ни туда, ни сюда.
И вздыхают басы, кудри по ветру вьются,
И осталось в войне победить, как всегда.
вторник, 29 октября 2013 г.
Создал тривиальную задачу программистам - поправить пару id элементов интерфейса, делов на пару часов, сломать ничего нельзя.
В течении дня получу 4 письма от JIRA о изменении полей таски:
1. Обратная связь аналитикам: Не нужна
2. Requirements review status: Не требуется
3. Проверять на dev-стенде: Нет
4. Нужен автотест: Отклонен
Контроль качества - такой контроль.
В течении дня получу 4 письма от JIRA о изменении полей таски:
1. Обратная связь аналитикам: Не нужна
2. Requirements review status: Не требуется
3. Проверять на dev-стенде: Нет
4. Нужен автотест: Отклонен
Контроль качества - такой контроль.
суббота, 26 октября 2013 г.
Добрые вести
А к нам в город приезжает Алексей Баранцев рассказать за селениум и автоматизацию. Вот:
http://it-people.ru/avtomatizaciya-funkcionalnogo-testirovaniya-selenium-2-0/
Генералы одобрили отправить аж двух моих бойцов, ништяк и спасибо.
А еще мой руководитель тоже туда намылился, видимо ко мне в группу хочет. Потому что все знают, что мы молодцы и всем мальчишкам пример.
http://it-people.ru/avtomatizaciya-funkcionalnogo-testirovaniya-selenium-2-0/
Генералы одобрили отправить аж двух моих бойцов, ништяк и спасибо.
А еще мой руководитель тоже туда намылился, видимо ко мне в группу хочет. Потому что все знают, что мы молодцы и всем мальчишкам пример.
среда, 23 октября 2013 г.
Есть вопросы
Вот тут интересно и хорошо написано.
Мое отношение к оплате цифровой информации хорошо описал баш:
Я программист. Я не ворую софт. Я ворую только медиа контент.
Вопрос к вам, друзья.
Онлайн давно уже понял, что за внимание и информацию о пользователе можно и нужно платить. Чаще всего - услугами, сервисом.
Используйте наш почтовый клиент, играйте в наши игры, читайте новости, пользуйтесь программами, получайте обновления.
Как считаете, оффлайн когда-нибудь придет к этой модели? Необходимость смотреть на всю наружную рекламу будет приносить профит конечному пользователю непосредственно (а не через отчисления в горбюджет или что еще там)?
Накидайте примеры, а? Когда в оффлайне платят за информацию о вас, за ваше внимание?
Мое отношение к оплате цифровой информации хорошо описал баш:
Я программист. Я не ворую софт. Я ворую только медиа контент.
Вопрос к вам, друзья.
Онлайн давно уже понял, что за внимание и информацию о пользователе можно и нужно платить. Чаще всего - услугами, сервисом.
Используйте наш почтовый клиент, играйте в наши игры, читайте новости, пользуйтесь программами, получайте обновления.
Как считаете, оффлайн когда-нибудь придет к этой модели? Необходимость смотреть на всю наружную рекламу будет приносить профит конечному пользователю непосредственно (а не через отчисления в горбюджет или что еще там)?
Накидайте примеры, а? Когда в оффлайне платят за информацию о вас, за ваше внимание?
вторник, 22 октября 2013 г.
Ы
Результаты онлайн-конференции Chief ConfeT&QA
На онлайн конференции можно было задавать вопросы и самых-самых спрашивающих поощряли:
Среди тех, кого выделили докладчики: Ольга Киселева, Nikolay Huber, Станислав Поляков, Сергей Петров, Наталья Суханова (ее выделили аж пять докладчиков, поэтому мы решили поменять правила и отправить Наталье футболку и календарь).
Так случилось(она помогла с оплатой), что эта самая Наташа - ваш покорный слуга.
Вот так леххкий троллинг докладчиков вообще и Руколь в частности (на тему ее пересказа своими словами tMMi) может вылиться в приятные ништячки.
На онлайн конференции можно было задавать вопросы и самых-самых спрашивающих поощряли:
Среди тех, кого выделили докладчики: Ольга Киселева, Nikolay Huber, Станислав Поляков, Сергей Петров, Наталья Суханова (ее выделили аж пять докладчиков, поэтому мы решили поменять правила и отправить Наталье футболку и календарь).
Так случилось(она помогла с оплатой), что эта самая Наташа - ваш покорный слуга.
Вот так леххкий троллинг докладчиков вообще и Руколь в частности (на тему ее пересказа своими словами tMMi) может вылиться в приятные ништячки.
понедельник, 21 октября 2013 г.
среда, 16 октября 2013 г.
Уникальная красота снежинки - это не про вас.
Обожаю эксперименты над людьми.
Поэтому намедни написал коллегам-тестерам письмо примерно следующего содержания:
Subj: Игра: угадай человека по резюме
Анонимно заполняем некое подобие резюме, вечером сравниваем и пытаемся узнать кто есть кто.
Цель: fun
Так как опыт у всех разный и по нему проще простого срисовать человека, то будем считать, что все работали только один год и только у нас. Этот опыт и описать так, как вы бы показали это будущему работодателю. Не пишите, где учились, когда родились. Только опыт и скилы последнего года.
Хвастаться можно. Врать - нет.
Всего у нас 13 (вроде бы) человек.
Итоги порадовали и удивили. Попадания у всех примерно 50%.
Точнее всего - 80% у руководителя группы. Я промахнулся мимо одного своего бойца! Из трех моих меня узнал только один. И это при том, что наша группа занимается автоматизацией, в отличие от остальных.
Самое смешное в движухе - оглашение правильных и неправильных ответов.
Рекуомендую, узнаете, насколько вы похожи и непохожи.
Поэтому намедни написал коллегам-тестерам письмо примерно следующего содержания:
Subj: Игра: угадай человека по резюме
Анонимно заполняем некое подобие резюме, вечером сравниваем и пытаемся узнать кто есть кто.
Цель: fun
Так как опыт у всех разный и по нему проще простого срисовать человека, то будем считать, что все работали только один год и только у нас. Этот опыт и описать так, как вы бы показали это будущему работодателю. Не пишите, где учились, когда родились. Только опыт и скилы последнего года.
Хвастаться можно. Врать - нет.
Всего у нас 13 (вроде бы) человек.
Итоги порадовали и удивили. Попадания у всех примерно 50%.
Точнее всего - 80% у руководителя группы. Я промахнулся мимо одного своего бойца! Из трех моих меня узнал только один. И это при том, что наша группа занимается автоматизацией, в отличие от остальных.
Самое смешное в движухе - оглашение правильных и неправильных ответов.
Рекуомендую, узнаете, насколько вы похожи и непохожи.
понедельник, 14 октября 2013 г.
Вот тут okiseleva высказывает разные мысли, и цитирует некоторые книжки, мне очень понравилась мысль (насколько я понял, okiseleva не совсем согласна):
Диалог подтверждения - удобный выход для программиста, поскольку избавляет его от ответственности за содействие непреднамеренному удалению. Однако здесь имеется неправильное понимание источника проблемы. Удаление целиком лежит на совести пользователя, и он уже набрал команду. В действительности имеет место уход от другой ответственности - ответственности программы быть готовой отменить действия, пусть даже пользователь захотел их выполнить.
Я за концепцию, когда операционная система не задает глупых вопросов, но позволяет отменить (или не позволяет, играем на nightmare, хрен ли). Нажимая кнопку клавиатуры я подтверждаю, что согласен, ответственен и так далее. Ибо уже со мной что-то не так, если я топчу кнопки не думая или выполняю одни и те же действия тысячи раз.
Другой вопрос как быть с touch интерфейсами, где нечаянные нажатия или промахи — обычное дело.
Диалог подтверждения - удобный выход для программиста, поскольку избавляет его от ответственности за содействие непреднамеренному удалению. Однако здесь имеется неправильное понимание источника проблемы. Удаление целиком лежит на совести пользователя, и он уже набрал команду. В действительности имеет место уход от другой ответственности - ответственности программы быть готовой отменить действия, пусть даже пользователь захотел их выполнить.
Я за концепцию, когда операционная система не задает глупых вопросов, но позволяет отменить (или не позволяет, играем на nightmare, хрен ли). Нажимая кнопку клавиатуры я подтверждаю, что согласен, ответственен и так далее. Ибо уже со мной что-то не так, если я топчу кнопки не думая или выполняю одни и те же действия тысячи раз.
Другой вопрос как быть с touch интерфейсами, где нечаянные нажатия или промахи — обычное дело.
А музыка звучит
Слушал тут песню О. Медведева «Корабельный кот».
Сперва вспомнил баш:
- Поменял проц и материнку, почему винда не грузится?
- Ну вот представь, живешь ты себе, ходишь в институт, учишься, работаешь, а потом однажды просыпаешься... А ты - кот о_О
А еще узнал, что есть на свете знаменитый корабельный кот, цитирую вики:
Непотопляемый Сэм (англ. Unsinkable Sam) - корабельный кот, служивший в годы Второй Мировой войны на германском линкоре, британском эсминце, а позже на авианосце, пережил гибель всех трёх кораблей и умер на берегу в 1955 году.
Он эпичен.
Сперва вспомнил баш:
- Поменял проц и материнку, почему винда не грузится?
- Ну вот представь, живешь ты себе, ходишь в институт, учишься, работаешь, а потом однажды просыпаешься... А ты - кот о_О
А еще узнал, что есть на свете знаменитый корабельный кот, цитирую вики:
Непотопляемый Сэм (англ. Unsinkable Sam) - корабельный кот, служивший в годы Второй Мировой войны на германском линкоре, британском эсминце, а позже на авианосце, пережил гибель всех трёх кораблей и умер на берегу в 1955 году.
Он эпичен.
 |
| Альбом: randompics4lj |
пятница, 11 октября 2013 г.
Рутина
Стебаться над стажером весело:
- Мы все тебе сочувствуем, чини тест.
или так:
- Наше сочувствие не бесконечно.
- Мы все тебе сочувствуем, чини тест.
или так:
- Наше сочувствие не бесконечно.
среда, 9 октября 2013 г.
Игры ingress пост
В минувшие выходные ingress-ekb тусовка (звучит, хех) устроила ивент мирового (это слово надо тянуть, ага) масштаба.
Процитирую итоговый пост организатора:
Операция "Fusion Star"
Екатеринбург, Россия, 5-6 октября 2013г.
Первая массовая совместная операция сопротивления и просвещения в Екатеринбурге.
Активная часть операции заняла 12 часов активной линковки.
В акции участвовало 27 агентов, 8 экипажей.
ИТОГО Общее кол-во линков 1214: 607 на зеленый портал и 607 на синий.
Узловые порталы выбраны в историческом сквере города:
«Памятник Татищеву и де Геннину» (Памятник основателям города был установлен 14 августа 1998 г. и приурочен к 275-летию Екатеринбурга)
«Водонапорная башня» - символ Екатеринбурга (архитектурный памятник конца XIX века)
Переведу: За ночь 27 человек на 8 машинах посетили 1214 точек в Екатеринбурге (памятники, красивые места, граффити, иногда - что попало) соблюдая внутриигровые правила.
Мои ощущения:
Куча упоротых носится по ночному и не очень городу Такой уровень организации, координации и преданности делу редко встретишь даже там, где за это платят деньги. И ребята зачОтные.
Оператор неба в реалтайме вел счет синие-зеленые, операция хоть и совместная, но потягаться было можно, до часу ночи примерно зеленые вели, но потом сказался то ли яростный рывок синих, то ли тот факт, что зеленые точки были не так кучно сложены в городе. Впрочем, к девяти утра счет сравняли.
И да. В нашем городе много, очень много, непередаваемо много неисследованных ебеней, памятников, рисунков, наскальной живописи и странных трансформаторных будок.
Присоединяйтесь, чо.
Картинки. Раз:
Два:
Три:
Четыре:
Ссылки:
Пост в гуглоплюсе на мунспике.
Порадовали комментарии: That is super badass и Must be cold there, even inside they all wear jacket. Good job Russia.
Пост в гуглплюсе по-нашенски.
Вконтагтег
Процитирую итоговый пост организатора:
Операция "Fusion Star"
Екатеринбург, Россия, 5-6 октября 2013г.
Первая массовая совместная операция сопротивления и просвещения в Екатеринбурге.
Активная часть операции заняла 12 часов активной линковки.
В акции участвовало 27 агентов, 8 экипажей.
ИТОГО Общее кол-во линков 1214: 607 на зеленый портал и 607 на синий.
Узловые порталы выбраны в историческом сквере города:
«Памятник Татищеву и де Геннину» (Памятник основателям города был установлен 14 августа 1998 г. и приурочен к 275-летию Екатеринбурга)
«Водонапорная башня» - символ Екатеринбурга (архитектурный памятник конца XIX века)
Переведу: За ночь 27 человек на 8 машинах посетили 1214 точек в Екатеринбурге (памятники, красивые места, граффити, иногда - что попало) соблюдая внутриигровые правила.
Мои ощущения:
Оператор неба в реалтайме вел счет синие-зеленые, операция хоть и совместная, но потягаться было можно, до часу ночи примерно зеленые вели, но потом сказался то ли яростный рывок синих, то ли тот факт, что зеленые точки были не так кучно сложены в городе. Впрочем, к девяти утра счет сравняли.
И да. В нашем городе много, очень много, непередаваемо много неисследованных ебеней, памятников, рисунков, наскальной живописи и странных трансформаторных будок.
Присоединяйтесь, чо.
Картинки. Раз:
 |
| Альбом: Ingress |
Два:
 |
| Альбом: Ingress |
Три:
 |
| Альбом: Ingress |
Четыре:
 |
| Альбом: Ingress |
Ссылки:
Пост в гуглоплюсе на мунспике.
Порадовали комментарии: That is super badass и Must be cold there, even inside they all wear jacket. Good job Russia.
Пост в гуглплюсе по-нашенски.
Вконтагтег
вторник, 8 октября 2013 г.
Кино
Вот как-то так нужно рекламировать фильмы.
Это, как вы поняли, реклама фильма Carrie, который наши надмозги перевели как Телекинез.
Книга вполне интересна, потому что Стивен Кинг.
Первый фильм не так уж плох, потому что они нашли идеальную актрису Sissy Spacek. Раз:
И два:
Фильм 2002 года не очень. Тянули, нудили. Надеюсь, что в этом году будет больше мести, крови, ненависти и прочего гуро. А то кто ж в детстве не мечтал разнести школу, городок...
Это, как вы поняли, реклама фильма Carrie, который наши надмозги перевели как Телекинез.
Книга вполне интересна, потому что Стивен Кинг.
Первый фильм не так уж плох, потому что они нашли идеальную актрису Sissy Spacek. Раз:
 |
| Альбом: films |
 |
| Альбом: films |
Фильм 2002 года не очень. Тянули, нудили. Надеюсь, что в этом году будет больше мести, крови, ненависти и прочего гуро. А то кто ж в детстве не мечтал разнести школу, городок...
пятница, 4 октября 2013 г.
Видео
Пересказ книги Ицхака Адизеса "Идеальный руководитель" Славой Панкратовым плюс его мысли. Лучше, конечно, прочесть книгу, но если нет времени, то и так сойдет.
вторник, 1 октября 2013 г.
пятница, 27 сентября 2013 г.
Я не люблю
Я очень не люблю вещи, которые делают с серьезным выражением лица. Исключения, конечно, есть, но их мало, а большая часть из них при ближайшем рассмотрении не такие уж и исключения.
Например, я очень не люблю то, что называют буллшит бинго.
Слова из буллшит бинго когда-то обладали глубоким смыслом, подразумевали мысль и наличие души, теперь они - маркеры глупости, лени или лицемерия.
Изначально Я слышу эту фразу так: Я не потрудился рассказать вам об этом раньше
Изучать Я изучал python, я изучал рынок, я изучал линукс, я изучал продукт. А что ты делал? С умным видом ковырял конфиги? Как ты мог изучать язык программирования, не написав при этом ни строчки кода? Что ты, черт возьми делал? Я слышу эту фразу так: Два дня я внимательно смотрел на объект исследования
Я ничего не успеваю Слышу так: Я брался за все, я бегал и метался, но так ничего полезного и не сделал
Можно сделать Слышу так: Будет зашибись, если вы сделаете еще и это, Ваше поделие оскорбляет мои эстетические чувства, переделайте все, ага. пиздеть не мешки ворочать
Надо понимать Слышу так: Странно, вы не умеете читать мои мысли Надо объяснять!
В целом, в общем В зависимости от контекста Я не могу логически объяснить, как я пришел к этому выводу или Вы делаете все неправильно, так как не понимаете (см. выше) глобальной цели(тм)
Анализировать Это вообще волшебно - Я анализировал цифры и статистику, я проанализировал данные... Каждый раз, когда произносится эта фраза - результатов работы нет. Просто нет. Нет выводов, нет обязательного этапа, следующего за анализом - синтеза. Ах, нет. Есть, блядь, графики. На которые все смотрят с умным видом и не принимают никаких решений. Или принимают, но те, которые уже были до графиков. Я слышу это так: Я выгрузил все это в гуглдок, шесть раз отсортировал, сгруппировал, построил семь графиков. И изучил(см. выше) результат.
Анализ - одно из моих любимых слов. Странно, но почти все, кто его произносит, забывают о синтезе. Я даже расскажу историю.
Жила-была проблема. Например - сбои на n-м этапе техпроцесса.
И были приняты тяжелые меры, усилен накал борьбы, изменен процесс, переучены люди, сменены несколько интерфейсов и ряд регламентов. Вообще случилась масса субъективно полезных вещей, связанных не только с этими сбоями.
А затем человеку дали задание - посчитать, как изменилось количество сбоев по сравнению с предыдущими периодами (там, к сожалению, нужно считать руками).
Все правильно? Да, смарт, измеримый результат (еще б заранее определить целевой показатель, но и так сойдет).
Но есть нюанс и вместе с ним вопрос: зачем вообще нужна эта работа?
Вопрос был задан и на него получен резонный ответ: чтоб узнать, были бы меры эффективными, принесли ли результат.
Отлично, а что мы сделаем, если ответ - нет, не были, не принесли мы вернем все обратно?
Если ответом было бы да, то я сочту проделанную работу полезной.
Если бы мне ответили нет, то у нас получится анализ без синтеза, без принятия решения.
Хм.
Да, я сам пользуюсь всем этим булшитом. Надеюсь, что все меньше
Например, я очень не люблю то, что называют буллшит бинго.
Слова из буллшит бинго когда-то обладали глубоким смыслом, подразумевали мысль и наличие души, теперь они - маркеры глупости, лени или лицемерия.
Изначально Я слышу эту фразу так: Я не потрудился рассказать вам об этом раньше
Изучать Я изучал python, я изучал рынок, я изучал линукс, я изучал продукт. А что ты делал? С умным видом ковырял конфиги? Как ты мог изучать язык программирования, не написав при этом ни строчки кода? Что ты, черт возьми делал? Я слышу эту фразу так: Два дня я внимательно смотрел на объект исследования
Я ничего не успеваю Слышу так: Я брался за все, я бегал и метался, но так ничего полезного и не сделал
Можно сделать Слышу так: Будет зашибись, если вы сделаете еще и это, Ваше поделие оскорбляет мои эстетические чувства, переделайте все, ага. пиздеть не мешки ворочать
Надо понимать Слышу так: Странно, вы не умеете читать мои мысли Надо объяснять!
В целом, в общем В зависимости от контекста Я не могу логически объяснить, как я пришел к этому выводу или Вы делаете все неправильно, так как не понимаете (см. выше) глобальной цели(тм)
Анализировать Это вообще волшебно - Я анализировал цифры и статистику, я проанализировал данные... Каждый раз, когда произносится эта фраза - результатов работы нет. Просто нет. Нет выводов, нет обязательного этапа, следующего за анализом - синтеза. Ах, нет. Есть, блядь, графики. На которые все смотрят с умным видом и не принимают никаких решений. Или принимают, но те, которые уже были до графиков. Я слышу это так: Я выгрузил все это в гуглдок, шесть раз отсортировал, сгруппировал, построил семь графиков. И изучил(см. выше) результат.
Анализ - одно из моих любимых слов. Странно, но почти все, кто его произносит, забывают о синтезе. Я даже расскажу историю.
Жила-была проблема. Например - сбои на n-м этапе техпроцесса.
И были приняты тяжелые меры, усилен накал борьбы, изменен процесс, переучены люди, сменены несколько интерфейсов и ряд регламентов. Вообще случилась масса субъективно полезных вещей, связанных не только с этими сбоями.
А затем человеку дали задание - посчитать, как изменилось количество сбоев по сравнению с предыдущими периодами (там, к сожалению, нужно считать руками).
Все правильно? Да, смарт, измеримый результат (еще б заранее определить целевой показатель, но и так сойдет).
Но есть нюанс и вместе с ним вопрос: зачем вообще нужна эта работа?
Вопрос был задан и на него получен резонный ответ: чтоб узнать, были бы меры эффективными, принесли ли результат.
Отлично, а что мы сделаем, если ответ - нет, не были, не принесли мы вернем все обратно?
Если ответом было бы да, то я сочту проделанную работу полезной.
Если бы мне ответили нет, то у нас получится анализ без синтеза, без принятия решения.
Хм.
Да, я сам пользуюсь всем этим булшитом. Надеюсь, что все меньше
пятница, 20 сентября 2013 г.
четверг, 19 сентября 2013 г.
Рутина
А боец нашей группы будет вести курсы для будущих тестировщиков. Она волнуется, но старается и молодец.
Вот тут с 40 секунды начинает вещать она:
Меня туда не взяли, потому что ленивый и морда лица не преподавательская.
Не знаю насчет ее студентов, но ей эти курсы точно помогут. Начала читать литературу, есть риск, что добьет недослушанные вебинары по тест-дизайну. Растет над собой. В одном месте своего рассказа даже цитирует меня. Пару лет назад я сюда выкладывал текст лекции по тестированию, пока искали этот шуточно-матерный, жизненный материал, наткнулись на старый пост Как на войне. Оттуда:
Тестировщики. Тестировщики это, конечно, пехота. Танки танками, но очистить местность от врага могут только они и хотят это делать за такой паек – тоже только тестировщики.
Во время атаки следуют за танками (в приличных соединениях – вместе с ними), зачищают местность, работают медленно и скрупулезно. В случае необходимости могут захватить ДОТ(создать фичу), но смогут сделать это самые опытные, делать будут долго и не спеша.
Если часть стоит в обороне(стабилизация и техподдержка), то они продолжают делать свое нелегкое дело – копать окопы (кейсы), которые, как известно, они могут или копать, или не копать. При достаточном количестве этих окопов враг не пройдет даже при полном отсутствии иных родов войск.
Тестировщики – шутники, но очень усталые.
Читать олностью.
Вот тут с 40 секунды начинает вещать она:
Меня туда не взяли, потому что ленивый и морда лица не преподавательская.
Не знаю насчет ее студентов, но ей эти курсы точно помогут. Начала читать литературу, есть риск, что добьет недослушанные вебинары по тест-дизайну. Растет над собой. В одном месте своего рассказа даже цитирует меня. Пару лет назад я сюда выкладывал текст лекции по тестированию, пока искали этот шуточно-матерный, жизненный материал, наткнулись на старый пост Как на войне. Оттуда:
Тестировщики. Тестировщики это, конечно, пехота. Танки танками, но очистить местность от врага могут только они и хотят это делать за такой паек – тоже только тестировщики.
Во время атаки следуют за танками (в приличных соединениях – вместе с ними), зачищают местность, работают медленно и скрупулезно. В случае необходимости могут захватить ДОТ(создать фичу), но смогут сделать это самые опытные, делать будут долго и не спеша.
Если часть стоит в обороне(стабилизация и техподдержка), то они продолжают делать свое нелегкое дело – копать окопы (кейсы), которые, как известно, они могут или копать, или не копать. При достаточном количестве этих окопов враг не пройдет даже при полном отсутствии иных родов войск.
Тестировщики – шутники, но очень усталые.
Читать олностью.
Рутина
Randall Munroe жжот.
Сайт с переводом: http://xkcd.ru/1204/ Оригинал: http://xkcd.com/1204/
А в это время: Схемы зданий на Google Картах приходят в Россию
Гугл, если ты меня слышишь, коллеги просят станцию метро Ботаническую.
вторник, 17 сентября 2013 г.
Ingress Green Night
Неделю назад, в ночь со вторника на среду, мы провели Green Night.
В рамках акции перекрасили в красивый зеленый цвет центр и юго-запад Екатеринбурга, поставив 195 порталов 8 lvl (причем по России и ближнему СНГ их на тот момент было 410, считая наши). Восьмерки продержались до пятницы, к выходным сопротивление зачистило остатки.
Практика совместных действий показала, что в таком серьезном деле, как игра — дисциплина и планирование значат больше, чем на работе. Ну и по Адизесу, демократия возможна только до начала работы, после — только тоталитаризм и единовластие, только хардкор. За последние четыре часа сделали втрое больше, чем за первые четыре.
В самую жару, часа в три ночи, деплоили с размаху, не выходя из транспорта, с вытянутых рук, некоторые по-македонски.
Выглядело это примерно так:
Пирожок с верхней полочки тому, кто первый расскажет, зачем на 10й секунде парень разбегается в стену, хех.
Ну а @Raspberries не останавливается, и проводит еще акции. Вива Enlightened!
В рамках акции перекрасили в красивый зеленый цвет центр и юго-запад Екатеринбурга, поставив 195 порталов 8 lvl (причем по России и ближнему СНГ их на тот момент было 410, считая наши). Восьмерки продержались до пятницы, к выходным сопротивление зачистило остатки.
Практика совместных действий показала, что в таком серьезном деле, как игра — дисциплина и планирование значат больше, чем на работе. Ну и по Адизесу, демократия возможна только до начала работы, после — только тоталитаризм и единовластие, только хардкор. За последние четыре часа сделали втрое больше, чем за первые четыре.
В самую жару, часа в три ночи, деплоили с размаху, не выходя из транспорта, с вытянутых рук, некоторые по-македонски.
Выглядело это примерно так:
Пирожок с верхней полочки тому, кто первый расскажет, зачем на 10й секунде парень разбегается в стену, хех.
Ну а @Raspberries не останавливается, и проводит еще акции. Вива Enlightened!
пятница, 13 сентября 2013 г.
Lesson 293
Это последний урок последней главы книги Lessons Learned in Software Testing Сэма Канера и его товарищей.
22 августа 2011 года, 2 года и три недели назад я перевел первый урок.
С того дня я ни разу не менял место работы, сменил три квартиры, два телефона и двух провайдеров.
Через три недели после того дня появится первый тест в системе, которую мы создаем и сейчас. Принятые тогда неправильные решения разгребаем до сих пор.
Скорость перевода - два урока в неделю.
Из козырного кабинета, в который тогда переехала моя группа, нас не выгнали до сих пор.
Единственно верный способ оценки эффективности процесса тестирования (и не только тестирования) вспоминаю до сих пор.
Да мало ли чего еще напоисходило..
Собирать перевод в одну xml'ку или pdf'ку мне лень, я книгу уже прочел, больше мне не интересно.
Дальше - возьму следующую книгу. Виттакера, может быть Копланда. А вообще Сэм, если я правильно понял, написал еще одну книгу, The Domain Testing Workbook, дождусь издания.
Максим cartmendum, пишу, как и обещал. Я добил последнюю страницу.
Слово Канеру
Относитесь к циклам тестирования как к сердцебиению процесса тестирования
Вы предоставляете услугу тестирования циклически. Цикл тестирования начинается с новой сборкой и заканчивается одной из двух вещей: новой сборкой или признанием того, что дальнейшее тестирование лишено смысла. Ваша стратегия конкретизирует эти циклы. Планируйте именно их. Чтоб предоставлять самую качественную информацию вашим клиентам. Вот один из способов организации цикла:
1. Возьмите продукт. Убедитесь, что у вас правильный билд.
2. Сконфигурируйте систему тестирования. Очистите ее. Восстановите диск, полностью удалите предыдущую версию продукта.
3. Проверьте тестируемость. Это хороший билд? Он стоит того, чтоб его проверять? Проведите smoke-тесты, демонстрирующие, что основная функциональность работает.
4. Определите, что появилось нового, а что было изменено. Какой код расширял или менял возможности продукта?
5. Выясните, какие ошибки были исправлены. Также, найдите проблемы, которые отклонили и отреагируйте соответствующим образом.
6. Проверьте исправления. Их стоит проверять вначале, так как программисты еще помнят о них. Если ошибка не была исправлена, то программистам нужно быстро об этом узнать.
7. Протестируйте новые или менявшиеся области продукта. Это еще одна тема, которая еще свежа в умах программистов.
8. Протестируйте остальные области (высокие риски в первую очередь). Тестируйте все остальное, пока не кончится время. Выполните автоматизированные регрессионные тесты.
9. Сообщите о результатах. Результаты нужно предоставлять периодически, не реже одного раза в день в ходе цикла тестирования.
22 августа 2011 года, 2 года и три недели назад я перевел первый урок.
С того дня я ни разу не менял место работы, сменил три квартиры, два телефона и двух провайдеров.
Через три недели после того дня появится первый тест в системе, которую мы создаем и сейчас. Принятые тогда неправильные решения разгребаем до сих пор.
Скорость перевода - два урока в неделю.
Из козырного кабинета, в который тогда переехала моя группа, нас не выгнали до сих пор.
Единственно верный способ оценки эффективности процесса тестирования (и не только тестирования) вспоминаю до сих пор.
Да мало ли чего еще напоисходило..
Собирать перевод в одну xml'ку или pdf'ку мне лень, я книгу уже прочел, больше мне не интересно.
Дальше - возьму следующую книгу. Виттакера, может быть Копланда. А вообще Сэм, если я правильно понял, написал еще одну книгу, The Domain Testing Workbook, дождусь издания.
Максим cartmendum, пишу, как и обещал. Я добил последнюю страницу.
Слово Канеру
Относитесь к циклам тестирования как к сердцебиению процесса тестирования
Вы предоставляете услугу тестирования циклически. Цикл тестирования начинается с новой сборкой и заканчивается одной из двух вещей: новой сборкой или признанием того, что дальнейшее тестирование лишено смысла. Ваша стратегия конкретизирует эти циклы. Планируйте именно их. Чтоб предоставлять самую качественную информацию вашим клиентам. Вот один из способов организации цикла:
1. Возьмите продукт. Убедитесь, что у вас правильный билд.
2. Сконфигурируйте систему тестирования. Очистите ее. Восстановите диск, полностью удалите предыдущую версию продукта.
3. Проверьте тестируемость. Это хороший билд? Он стоит того, чтоб его проверять? Проведите smoke-тесты, демонстрирующие, что основная функциональность работает.
4. Определите, что появилось нового, а что было изменено. Какой код расширял или менял возможности продукта?
5. Выясните, какие ошибки были исправлены. Также, найдите проблемы, которые отклонили и отреагируйте соответствующим образом.
6. Проверьте исправления. Их стоит проверять вначале, так как программисты еще помнят о них. Если ошибка не была исправлена, то программистам нужно быстро об этом узнать.
7. Протестируйте новые или менявшиеся области продукта. Это еще одна тема, которая еще свежа в умах программистов.
8. Протестируйте остальные области (высокие риски в первую очередь). Тестируйте все остальное, пока не кончится время. Выполните автоматизированные регрессионные тесты.
9. Сообщите о результатах. Результаты нужно предоставлять периодически, не реже одного раза в день в ходе цикла тестирования.
вторник, 10 сентября 2013 г.
Lesson 292
В минувшие выходные боец @Raspberries жгла. Результат примерно такой:
Подробности и фоточки.
И еще история про кота от Александра Селяева.
Слово Канеру
Создайте стратегию тестирования как ответ на особенности и риски проекта
Хорошая стратегия тестирования формируется не только рисками, но и особенностями проекта. Вот несколько принципов формирования стратегий. Основанных на деталях проекта:
- Не теряйте баги в щелях между тестами. Если вы не используете принцип разных полумер или перекрывающихся зон ответственности, то сталкиваетесь с опасностью того, что определенная функциональность не будет проверена, так как окажется на границе ответственности между двумя тестировщиками или командами.
- Тестируйте то, что вас просят тестировать. Вы тестируете от имени большого количества клиентов. Что они считают, что вы должны проверить? Узнайте, и убедитесь в том, что вы удовлетворяете потребности хотя бы некоторых из них.
- Иногда проверяйте то, что вас просили не проверять. Иногда вас просят не тестировать определенные части продукта. Это деликатный вопрос и мы точно не скажем вам, что делать. Однако иногда те вещи, которые вас просили не тестировать являются теми, которые больше всего нуждаются в тестировании.
- Тестируйте путаницу и противоречия. Like coder; like code. Везде, где есть путаница и противоречия, процветают дефекты. Если программист не уверен в том, что делает функция — протестируйте ее. If he's new to the technology, test it. Если два программиста создавали части, взаимодействующие друг с другом — протестируйте их и вы не будете разочарованы.
- Не бейте мертвую фичу. Когда становится ясно, что фича полна ошибок — прекратите тестирование, если только вы не делаете это с разработчиком. Это может быть сломанная сборка, некорректная конфигурация. Кроме того, если компонент настолько плох, что будет заменен, а не пересмотрен, то любые ошибки, что вы найдете, будут закрыты.
- Чем больше изменений, тем больше тестирования. Теоретически, мельчайшее изменение в продукте может повлечь большие нелокальные эффекты. Это значит, что любое изменение потенциально обесценивает все тесты, которые вы когда либо проводили с продуктом. В действительности, большинство изменений имеют довольно ограниченный диапазон влияния. Тем не менее, вы должны следить за изменениями в продукте. Чем больше изменений, тем больше вы должны тестировать. Это становится серьезной работой в конце проекта.
 |
| Альбом: Ingress |
Подробности и фоточки.
И еще история про кота от Александра Селяева.
Слово Канеру
Создайте стратегию тестирования как ответ на особенности и риски проекта
Хорошая стратегия тестирования формируется не только рисками, но и особенностями проекта. Вот несколько принципов формирования стратегий. Основанных на деталях проекта:
- Не теряйте баги в щелях между тестами. Если вы не используете принцип разных полумер или перекрывающихся зон ответственности, то сталкиваетесь с опасностью того, что определенная функциональность не будет проверена, так как окажется на границе ответственности между двумя тестировщиками или командами.
- Тестируйте то, что вас просят тестировать. Вы тестируете от имени большого количества клиентов. Что они считают, что вы должны проверить? Узнайте, и убедитесь в том, что вы удовлетворяете потребности хотя бы некоторых из них.
- Иногда проверяйте то, что вас просили не проверять. Иногда вас просят не тестировать определенные части продукта. Это деликатный вопрос и мы точно не скажем вам, что делать. Однако иногда те вещи, которые вас просили не тестировать являются теми, которые больше всего нуждаются в тестировании.
- Тестируйте путаницу и противоречия. Like coder; like code. Везде, где есть путаница и противоречия, процветают дефекты. Если программист не уверен в том, что делает функция — протестируйте ее. If he's new to the technology, test it. Если два программиста создавали части, взаимодействующие друг с другом — протестируйте их и вы не будете разочарованы.
- Не бейте мертвую фичу. Когда становится ясно, что фича полна ошибок — прекратите тестирование, если только вы не делаете это с разработчиком. Это может быть сломанная сборка, некорректная конфигурация. Кроме того, если компонент настолько плох, что будет заменен, а не пересмотрен, то любые ошибки, что вы найдете, будут закрыты.
- Чем больше изменений, тем больше тестирования. Теоретически, мельчайшее изменение в продукте может повлечь большие нелокальные эффекты. Это значит, что любое изменение потенциально обесценивает все тесты, которые вы когда либо проводили с продуктом. В действительности, большинство изменений имеют довольно ограниченный диапазон влияния. Тем не менее, вы должны следить за изменениями в продукте. Чем больше изменений, тем больше вы должны тестировать. Это становится серьезной работой в конце проекта.
понедельник, 9 сентября 2013 г.
Lesson 291
Пару дней назад в Екатеринбург приезжал Максим cartmendum Дорофеев.
Как обычно, жог.
Из запомнившегося:
Купить книгу: Ментальные ловушки. Глупости, которые делают разумные люди, чтобы испортить себе жизнь
Это неловкое чувство, когда ты выключаешь сервер по питанию, а он продолжает пинговаться
Эффект козлов: переписка с человеком в три письма — и такое ощущение, что он там козел. Позвонил по телефону — адекватный вроде бы человек. Приехал в командировку и увиделся лично — отличный парень, никаких проблем. Вернулся, три письма в переписке — козел и вообще ничего не понимает.
Бритва Оккама-????(Дорофеева?): Из всех объяснений ситуации наиболее вероятно то, в котором количество мудаков минимально. Первое следствие (Захарова?): Если ситуация объясняется тем, что все вокруг — мудаки, то скорее всего мудак — объясняющий.
При всем при этом с основной мыслью Максима позволю себе не согласиться. Он говорил, что из вариантов Алгоритмы, бизнес-идеи, языки программирования, общение самое важное для IT-специалиста — умение общаться, 50%, остальные три пункта по 15%.
Я считаю - это верно для всех, кроме программистов. Программист должен любить писать код. По поводу и без. Общаться за него должны все остальные — аналитики, тестировщики, саппорты, админы, менеджеры и прочий обслуживающий строчки кода персонал. Потому как без строчек кода все эти люди - предприниматели, ОТК, заведующие складом и вахтеры. Но не IT-специалисты.
З.Ы. Максим, а ты напишешь про меня восторженный твит, когда я закончу перевод Канера? Мне осталось 2 страницы.
Слово Канеру
Два тестировщика, тестируя одно и то же не дублируют работу.
Некоторые тестировщики беспокоятся о дублировании работы. Расслабьтесь. Не волнуйтесь о том, что люди перекрывают одни и те же области или задачи. Дублирование тестирования не то же самое, что дублирование тестов. Есть вероятность, что два тестировщика, тестируя одно и то же, обнаружат разные проблемы. Это потому, что они прогоняют разные тесты. Даже тогда, когда они считают, что работают одинаково, между ними есть различия. Кроме того, один тестировщик заметит проблемы, которые другой просто выпустит из виду.
Дублирование усилий по тестированию никогда не пройдет впустую. Реальный вопрос заключается в том, чтоб решить, какая часть продукта заслуживает того, чтоб ее тестировали несколько раз.
Как обычно, жог.
Из запомнившегося:
Купить книгу: Ментальные ловушки. Глупости, которые делают разумные люди, чтобы испортить себе жизнь
Это неловкое чувство, когда ты выключаешь сервер по питанию, а он продолжает пинговаться
Эффект козлов: переписка с человеком в три письма — и такое ощущение, что он там козел. Позвонил по телефону — адекватный вроде бы человек. Приехал в командировку и увиделся лично — отличный парень, никаких проблем. Вернулся, три письма в переписке — козел и вообще ничего не понимает.
Бритва Оккама-????(Дорофеева?): Из всех объяснений ситуации наиболее вероятно то, в котором количество мудаков минимально. Первое следствие (Захарова?): Если ситуация объясняется тем, что все вокруг — мудаки, то скорее всего мудак — объясняющий.
При всем при этом с основной мыслью Максима позволю себе не согласиться. Он говорил, что из вариантов Алгоритмы, бизнес-идеи, языки программирования, общение самое важное для IT-специалиста — умение общаться, 50%, остальные три пункта по 15%.
Я считаю - это верно для всех, кроме программистов. Программист должен любить писать код. По поводу и без. Общаться за него должны все остальные — аналитики, тестировщики, саппорты, админы, менеджеры и прочий обслуживающий строчки кода персонал. Потому как без строчек кода все эти люди - предприниматели, ОТК, заведующие складом и вахтеры. Но не IT-специалисты.
З.Ы. Максим, а ты напишешь про меня восторженный твит, когда я закончу перевод Канера? Мне осталось 2 страницы.
Слово Канеру
Два тестировщика, тестируя одно и то же не дублируют работу.
Некоторые тестировщики беспокоятся о дублировании работы. Расслабьтесь. Не волнуйтесь о том, что люди перекрывают одни и те же области или задачи. Дублирование тестирования не то же самое, что дублирование тестов. Есть вероятность, что два тестировщика, тестируя одно и то же, обнаружат разные проблемы. Это потому, что они прогоняют разные тесты. Даже тогда, когда они считают, что работают одинаково, между ними есть различия. Кроме того, один тестировщик заметит проблемы, которые другой просто выпустит из виду.
Дублирование усилий по тестированию никогда не пройдет впустую. Реальный вопрос заключается в том, чтоб решить, какая часть продукта заслуживает того, чтоб ее тестировали несколько раз.
среда, 4 сентября 2013 г.
Lesson 290
Слово Канеру
Остерегайтесь поклонения предкам при повторном использовании материалов тестирования.
Переиспользуя материалы тестирования или любые другие, не рассматривайте их как черный ящик. Изучите из. Выясните, почему они созданы именно такими. Во многих случаях архивные материалы для тестирования настолько низкого качества, что лучше их не использовать вообще. Тенденция тестировщиков доверять старым материалам только потому, что они старые загадочна. Мы многократно видели древние тесты, которые выполнялись через много лет после того, как стали неактуальны. Мы видели умных и квалифицированных тестировщиков, беспрекословно следующих тестам, которые писали менее квалифицированные тестировщики. Это темная сторона повторного использования.
В одной тестовой лаборатории было правило «всегда прверяй с Compaq Presario, because they are notoriously incompatible». Это правило было написано в 1996 году. Оно все еще актуально? Кто-нибудь возвращался к этой проблеме? Кто-нибудь подвергал сомнению авторитет Древних, которые писали правила?
Если вас привлекают к написанию тестов, которые будут выполняться повторно, спросите себя: как люди узнают, что вы имели в виду? Почему эти тесты нужны? Когда их нужно отправить на пенсию или переписать заново? Иначе есть отличные шансы, что ваши клиенты будут относиться к вашей работе как к магическому тотему, а не использовать тесты так, как вы бы того хотели.
Остерегайтесь поклонения предкам при повторном использовании материалов тестирования.
Переиспользуя материалы тестирования или любые другие, не рассматривайте их как черный ящик. Изучите из. Выясните, почему они созданы именно такими. Во многих случаях архивные материалы для тестирования настолько низкого качества, что лучше их не использовать вообще. Тенденция тестировщиков доверять старым материалам только потому, что они старые загадочна. Мы многократно видели древние тесты, которые выполнялись через много лет после того, как стали неактуальны. Мы видели умных и квалифицированных тестировщиков, беспрекословно следующих тестам, которые писали менее квалифицированные тестировщики. Это темная сторона повторного использования.
В одной тестовой лаборатории было правило «всегда прверяй с Compaq Presario, because they are notoriously incompatible». Это правило было написано в 1996 году. Оно все еще актуально? Кто-нибудь возвращался к этой проблеме? Кто-нибудь подвергал сомнению авторитет Древних, которые писали правила?
Если вас привлекают к написанию тестов, которые будут выполняться повторно, спросите себя: как люди узнают, что вы имели в виду? Почему эти тесты нужны? Когда их нужно отправить на пенсию или переписать заново? Иначе есть отличные шансы, что ваши клиенты будут относиться к вашей работе как к магическому тотему, а не использовать тесты так, как вы бы того хотели.
вторник, 3 сентября 2013 г.
Lesson 289
Отсортируйте по значимости, от большего к меньшему:
В некой группе людей вас ...
чтят
восхищаются
восторгаются
высоко оценивают
признают
принимают во внимание
ценят
любят
уважают
Слово Канеру
Тестируйте серый ящик
Даже если вы и не располагаете полной информацией о внутреннем устройстве продукта, стратегия тестирования, частично опирающаяся на знания его внутреннего устройства - хорошая идея. Мы называем это тестированием серого ящика. Концепция проста: если вы знаете что-то о том, как продукт работает внутри, то у вас есть возможность лучше проверить его снаружи. Этот способ не следует путать с тестированием белого ящика, при котором тестируется внутренние компоненты продукта. В случае серого ящика, вы тестируете так же, как тестировали бы черный, но выбор тестов, которые вы проводите определяется знанием о особенностях работы и взаимодействия компонент продукта.
Тестирование серого ящика особенно важно для тестирования веб- и интернет-приложений, так как интернет построен вокруг слабо интегрированных компонент, соединяющихся через хорошо определенные интерфейсы. Если вы не понимаете архитектуру сети, то тестирование будет поверхностным. Testing Applications on the Web (2000) Hung Nguyen — хороший пример стратегии тестирования серого ящика, применимой в веб.
В некой группе людей вас ...
чтят
восхищаются
восторгаются
высоко оценивают
признают
принимают во внимание
ценят
любят
уважают
Слово Канеру
Тестируйте серый ящик
Даже если вы и не располагаете полной информацией о внутреннем устройстве продукта, стратегия тестирования, частично опирающаяся на знания его внутреннего устройства - хорошая идея. Мы называем это тестированием серого ящика. Концепция проста: если вы знаете что-то о том, как продукт работает внутри, то у вас есть возможность лучше проверить его снаружи. Этот способ не следует путать с тестированием белого ящика, при котором тестируется внутренние компоненты продукта. В случае серого ящика, вы тестируете так же, как тестировали бы черный, но выбор тестов, которые вы проводите определяется знанием о особенностях работы и взаимодействия компонент продукта.
Тестирование серого ящика особенно важно для тестирования веб- и интернет-приложений, так как интернет построен вокруг слабо интегрированных компонент, соединяющихся через хорошо определенные интерфейсы. Если вы не понимаете архитектуру сети, то тестирование будет поверхностным. Testing Applications on the Web (2000) Hung Nguyen — хороший пример стратегии тестирования серого ящика, применимой в веб.
понедельник, 2 сентября 2013 г.
пятница, 30 августа 2013 г.
Есть вопросы
А за чем бы вы пошли по дороге из желтого кирпича? Ясно, что не хватает, как всегда, мозгов, как у Страшилы.
А чего - хочется? Мне бы сердце..
А чего - хочется? Мне бы сердце..
Lesson 288
Совместно со стажером выполнили первый пункт полугодового плана группы - повесили сетку. К ней прилагаются восемь мячиков.
Ништяк.
Слово Канеру
Используйте уровни тестирования для упрощения обсуждения сложности теста
Чтоб упростить взаимодействие по поводу стратегии тестирования, для многих проектов полезно различать уровни тестирования. На низком уровне более простые, менее обширные тесты. Тесты высокого уровня более сложны и всеохватывающи. Это позволит упростить обсуждение стратегии тестирования by providing a shorthand for talking about classes of testing. Вот пример иерархии уровней тестирования:
- Уровень 0: Smoke тестирование. Простые тесты, показывающие, что продукт готов к тестированию, a sanity check. Если не прошли тесты нулевого уровня, отправьте код назад к программистам.
- Уровень 1: Тестирование возможностей. Тесты, проверяющие работоспособность фич. Цель — убедиться в том, что каждая функция выполняет свою задачу. На этом уровне стоит избегать раздутых сценариев, сложных данных и взаимодействия фич.
- Уровень 2: функциональное тестирование. Тесты, проверяющие как работу, так и надежность каждой функции продукта. Интерес представляет покрытие тестами и сложные методы оценки результата. Используйте граничные значения, стресс-тесты, тесты на обработку ошибок, но избегайте запутанных сценариев и взаимодействия функций.
- Уровень 3: комплексное тестирование. Тесты на взаимодействие потоков управления группами функций, сложные сценарии. Фокус расширен и включает оценку производительности, совместимости, конфликты за ресурсы, утечки памяти, надежность и другие критерии качества, которые становятся проверяемыми по мере зрелости продукта.
Каждому из этих уровней может соответствовать ряд различных техник тестирования и их комбинаций. Общий смысл в том, чтоб начать тестирование с сочувствием к продукту, а затем перейти к коварству по мере роста продукта. Использование 3 уровня на ранних стадиях развития продукта без использования уровней 1 и 2 приведет к раздражению программистов. Скорее всего. Вы просто не сможете провести эти тесты.
 |
| Альбом: office |
Ништяк.
Слово Канеру
Используйте уровни тестирования для упрощения обсуждения сложности теста
Чтоб упростить взаимодействие по поводу стратегии тестирования, для многих проектов полезно различать уровни тестирования. На низком уровне более простые, менее обширные тесты. Тесты высокого уровня более сложны и всеохватывающи. Это позволит упростить обсуждение стратегии тестирования by providing a shorthand for talking about classes of testing. Вот пример иерархии уровней тестирования:
- Уровень 0: Smoke тестирование. Простые тесты, показывающие, что продукт готов к тестированию, a sanity check. Если не прошли тесты нулевого уровня, отправьте код назад к программистам.
- Уровень 1: Тестирование возможностей. Тесты, проверяющие работоспособность фич. Цель — убедиться в том, что каждая функция выполняет свою задачу. На этом уровне стоит избегать раздутых сценариев, сложных данных и взаимодействия фич.
- Уровень 2: функциональное тестирование. Тесты, проверяющие как работу, так и надежность каждой функции продукта. Интерес представляет покрытие тестами и сложные методы оценки результата. Используйте граничные значения, стресс-тесты, тесты на обработку ошибок, но избегайте запутанных сценариев и взаимодействия функций.
- Уровень 3: комплексное тестирование. Тесты на взаимодействие потоков управления группами функций, сложные сценарии. Фокус расширен и включает оценку производительности, совместимости, конфликты за ресурсы, утечки памяти, надежность и другие критерии качества, которые становятся проверяемыми по мере зрелости продукта.
Каждому из этих уровней может соответствовать ряд различных техник тестирования и их комбинаций. Общий смысл в том, чтоб начать тестирование с сочувствием к продукту, а затем перейти к коварству по мере роста продукта. Использование 3 уровня на ранних стадиях развития продукта без использования уровней 1 и 2 приведет к раздражению программистов. Скорее всего. Вы просто не сможете провести эти тесты.
среда, 28 августа 2013 г.
Lesson 287
Слово Канеру
Тестируйте продукт на зрелость
Хотя общие стратегии для фаз жизни проекта, как правило, недостаточны, все же имеет смысл применять разные стратегии на разных фазах, в зависимости от того, насколько зрелым является продукт:
- На старте проекта тестируйте снисходительно. В начале проекта продукт плохо работает и вы мало о нем знаете. Серьезные тесты на данном этапе по большей части не нужны, так как даже простые тесты найдут ошибки. Таким образом, программисты, знающие, что продукт еще не готов, будут огорчены излишним усердием тестировщиков. Программисты хотят знать, работают ли функции, которые они реализовали.
- В середине проекта тестируйте агрессивно. Так как продукт поставляется вместе с реализованными фичами и техническим долгом, простые тесты теряют свою эффективность. Программисты чувствуют себя уверенно в продукте. Они переходят от реализации фич к фулл-тайм исправлению багов. Самое время, чтоб провести полное и более сложное тестирование. Mine flaky parts of the product for all they're worth. Найтиде и зарепортьте так много дефектов, как можете. Создайте беклог ошибок для разработчиков.
- Ближе к концу проекта тестируйте разными способами. В зрелом продукте сложнее найти ошибки, тестирование должно быть более творческим. Это время довести разнообразие тестирования до пределов вашей фантазии. И руководство окажет вам поддержку. Используйте помощников, автоматизацию, мероприятия тестировщиков (bug finding parties or bug bounties), эвристику, бетатестеров и все остальное. Если вы все сделаете правильно, ваша кривая скорости поиска ошибок будет идеальной кривой, как на диаграмме. Поднимите ее вверх на ранних этапах за счет агрессивного тестирования и удерживайте там во время завершения проекта за счет разнообразного тестирования, пока у вас не кончатся идеи для новых и лучших тестов.
- В последние дни проверяйте тщательно. Ошибка последних дней может стоить вашей компании очень дорого. Когда вы приближаетесь к дедлайну, тестирование должно стать оборонительным. Тщательно проверяйте каждое изменение. Проверьте каждый файл, который будет выпущен в релиз. Используйте парное тестирование, чтоб обеспечить вдвое больше глаз, наблюдающих за тестированием.
Общая цель заключается в том, чтоб непрерывно корректировать стратегию тестирования продукта, удерживая скорость нахождения важных ошибок в продукте на высоком уровне.
Картинки.
Раз:
Два:
Три:
Четыре:
Тестируйте продукт на зрелость
Хотя общие стратегии для фаз жизни проекта, как правило, недостаточны, все же имеет смысл применять разные стратегии на разных фазах, в зависимости от того, насколько зрелым является продукт:
- На старте проекта тестируйте снисходительно. В начале проекта продукт плохо работает и вы мало о нем знаете. Серьезные тесты на данном этапе по большей части не нужны, так как даже простые тесты найдут ошибки. Таким образом, программисты, знающие, что продукт еще не готов, будут огорчены излишним усердием тестировщиков. Программисты хотят знать, работают ли функции, которые они реализовали.
- В середине проекта тестируйте агрессивно. Так как продукт поставляется вместе с реализованными фичами и техническим долгом, простые тесты теряют свою эффективность. Программисты чувствуют себя уверенно в продукте. Они переходят от реализации фич к фулл-тайм исправлению багов. Самое время, чтоб провести полное и более сложное тестирование. Mine flaky parts of the product for all they're worth. Найтиде и зарепортьте так много дефектов, как можете. Создайте беклог ошибок для разработчиков.
- Ближе к концу проекта тестируйте разными способами. В зрелом продукте сложнее найти ошибки, тестирование должно быть более творческим. Это время довести разнообразие тестирования до пределов вашей фантазии. И руководство окажет вам поддержку. Используйте помощников, автоматизацию, мероприятия тестировщиков (bug finding parties or bug bounties), эвристику, бетатестеров и все остальное. Если вы все сделаете правильно, ваша кривая скорости поиска ошибок будет идеальной кривой, как на диаграмме. Поднимите ее вверх на ранних этапах за счет агрессивного тестирования и удерживайте там во время завершения проекта за счет разнообразного тестирования, пока у вас не кончатся идеи для новых и лучших тестов.
- В последние дни проверяйте тщательно. Ошибка последних дней может стоить вашей компании очень дорого. Когда вы приближаетесь к дедлайну, тестирование должно стать оборонительным. Тщательно проверяйте каждое изменение. Проверьте каждый файл, который будет выпущен в релиз. Используйте парное тестирование, чтоб обеспечить вдвое больше глаз, наблюдающих за тестированием.
Общая цель заключается в том, чтоб непрерывно корректировать стратегию тестирования продукта, удерживая скорость нахождения важных ошибок в продукте на высоком уровне.
Картинки.
Раз:
 |
| Альбом: bug |
Два:
 |
| Альбом: bug |
Три:
 |
| Альбом: bug |
Четыре:
 |
| Альбом: bug |
Подписаться на:
Сообщения (Atom)