Хорошие ресурсы про рестораны, бары и клубы:

• московские кафе на александровском саду
• где находится локо парк
• рестораны кузнецкий мост тургеневская трубная
• кафе Арусяк на корнейчука
• караоке клубы москвы м. красногвардейская
• ntktajy rke,f lbkt;fyc
• Пиво-воды фото
• Космик-Глобал Сити фото
• бильярд рязанский проспект 24
• Суши бар м.Сходненская
• Дешевые бары СПб на карте
• загородные рестораны СПб отзывы
• Новые кафе Санкт-Петербурга метро
• Все караоке Петербурга режим работы
• Любые ночные клубы Санкт-Петербурга адреса
• Все пабы СПб фото
• Новые пивные рестораны Санкт-Петербурга режим работы
• Любые рестораны Питера на карте
• Любые суши Питера режим работы
• забегаловки СПб фото
• Любые казино фотографии
• Все кондитерские СПб фотографии
• Недорогие кофейни Москвы режим работы
• Дешевые стриптиз-клубы адреса
• Лучшие спорт-бары отзывы
• Дешевые караоке СПб
• Дешевые бильярдные Петербурга метро
• Все боулинг клубы Петербурга на карте
• суши России фотографии
• Дешевые кофейни Питера
• Дешевые бары России контакты
• Хорошие бильярды Питера
• Новые загородные рестораны в России фото
• Хорошие кафе Москвы телефон
• Новые караоке в России контакты
• Все ночные клубы в России контакты
• Интересные пабы Питера меню
• Любые пивные рестораны Москвы контакты
• Лучшие Рестораны СПб фотографии
• доставка суши в петродворец
• il patio екатеринбург заказать еду
• отзывы о ресторане code 011
• ???? ????
• Коньки
• Все кондитерские цены
• Хорошие пиццерии Москвы отзывы
• Хорошие кофейни в Москве фотографии
• Интересные стриптиз-клубы фото
• Новые бары в Москве меню
• кондитерские в Петербурге меню
• Интересные пиццерии в Петербурге адрес
• Хорошие бары в Петербурге фотографии

Перый номер вышел в начале февраля.

Второй номер планируетсяк концу июня. Заявки на статьи принимаются до 31 мая 2010 года.

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

(с) http://blog.softwaretestingclub.com/magazine/

Есть желающие отправить свои материалы в этот журнал? Или может кто хочет, но мало времени — так давайте скооперируемся ;)

Часть тестировщиков хорошо уже изучила книжку «Тестирование Дот Ком, или Пособие по жестокому обращению с багами в интернет-стартапах»
Кому интересно — Роман Савин объявился вконтакте и жаждет общения: «Ребята, становитесь моими друзьями. Буду рад ответить на все вопросы: тестирование, поиск работы, жизнь в США.
С уважением,
Роман Савенков (подпольная кличка „Савин“)»

Лимончелли в «Тайм-менеджменте для сисадминов» даёт советы, заточенные для сисадминов. А где дают советы по личному управлению временем, заточенные для тестировщиков (не лидов)? Интересуют интструменты повышения продуктивности, Ваш негативный и позитивный опыт, постановка мозгов в разных подходах к тестированию.

Примеры в кучу:

0). To find unexpected problems, elusive problems that may occur in the field, or more problems quickly in a complex product…
1. Start from different states (not necessarily clean).
2. Prefer complex, challenging actions.
3. Generate tests from a variety of models.
4. Question your lab procedures and tools.
5. Try to see everything with open expectations.
6. Make the test hard to pass, instead of easy to reproduce.

1). Обнаруживайте серьезные проблемы быстро
    * что изменилось а потом остальное
    * основные функции перед второстепенными
    * работают ли функции в принципе прежде чем детально углубляться в проверку работы каждой из них в различных условиях
    * обычные ситуации и данные раньше
    * распространенные опасности и  нагрузки раньше экзотических
    * сначала проблемы, которые принесут большой ущерб в случае сбоя
    * востребованные области раньше незапрошенных
будете находить важные проблемы раньше, если узнаете как можно больше о продукте, программном обеспечении и оборудовании, с которым он должен взаимодействовать и людях, которые будут его использовать bugsclock.blogspot.com/2008/12/blog-post.html

2). «выполняя миссию, тестировщик часто что-то замечает „в стороне“. И тут нужен компромисс — с одной стороны, хорошо бы это зафиксировать, с другой стороны — нельзя отвлекаться сильно, иначе миссия не будет выполнена, и это не есть гут. Поэтому в журнале делается отметка об отклонении от миссии, чтобы потом это отдельно проанализировать. А хорошие инструменты ещё и следят, чтобы время проведённое on opportunity не было слишком большим, и время от времени напоминают о необходимости вернуться к выполнению миссии»

3). " “Планарий”. Кстати, очень хорошее приложение, рекомендую обратить на него внимание любителям GTD"

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

В условиях ограниченных ресурсов, почему бы не провести стресс-тест для выявления багов функционала? Если стресс-тест сильный (выявляет больше багов, чем другие) почему принято начинать с функциональных и уж никак не смешивать функциональное тестирование со стресс-тестированием?

Можете привести примеры из Вашего опыта, когда ошибки функционала выявлялись стресс-тестами?

(In the Cisco program, you're given the task of fixing a broken router. If your process is reasonable, and if you can articulate it, then you pass the test, maybe even if you don't fix the router. This emphasizes that even a skilled network engineer and appropriate heuristics can be fallible; you might not have fixed the thing because you were unlucky. On the other hand, if your process is not reasonable or you can't articulate it, then you'll fail the test, even if you fix the router. The issue is that even an incompetent engineer and an unreasonable process can be lucky, but we'd just as soon not depend on that.) www.developsense.com/2007/12/why-i-am-not-yet-certified-eurostar.html

Вышел первый номер журнала для тестеров от STP: The Software Testing Club Magazine.

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

Иллюстрации для журнала подготовлены Рози Шерри, с работами которой можно познакомиться в серии Tester Types (сборка иллюстраций без текста есть тут).

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

Нашлась хорошо сделанная программа — Humanized Enso, которая помогает мне меньше трогать мышь и повышает эффективность моей работы.
Стоит заметить, что «хорошо сделанная», к сожалению, не означает «не имеющая дефектов». Под хорошосделанностью в данном случае я понимаю удобство и легкость использования и невероятный эффект подсаживания.

Что делает эта программка?
Можно сказать, что это расширенный вариант стандартной возможности Run… в виндах. Вызывается строка запуска с помощью одной клавиши (CapsLock по умолчанию) и позволяет делать больше разных штучек. Например, open with и назначение shortcut-ов, но не клавиатурных, типа CTR+ALT+F18, который потом (а)не вспомнить и (б)не всегда работает как надо. Шоткаты здесь — это элиасы (как, блин, это по-русски сказать-то?). Например, 'open gmail' у меня открывает в браузере почту gmail, а 'open apt' — руби-горе-редактор aptana radrails.

Очень удобно иметь такую прогу на ноуте.
( Читать дальше )

Коллеги!

У меня тут комп сдох рабочий. Пересел я на другой, свободный.
И вот на нём мне кто-то шипит в наушники. Т.е. шипит всегда, даже когда ничего не играет и когда Mute All выставлено. Я было подумал, что это звуковая карта такая.

Но! Случайно обнаружил, что если таскать иконку Language Bar-a, то не шипит! Т.е. буквально, хватаешь за выпуклость слева от нее и только протащишь чуток — не шипит, отпускаешь кнопку мыши — шипит.

Может быть я слышу звук, которые издает windows, когда совершает какие-то вычисления?

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

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

Какой продукт должен выдать такой поисковик-сборщик?
Инструмент должен облегчить написание сильных кейсов.
Речь о том, что Алексей называет «инкубатором, где из мусора могли бы формироваться идеи, которые могли бы оказаться полезны для поиска багов», аналогичных описанным с изложением мыслей по поводу. Только не «могли бы оказаться полезны для поиска багов», а обязаны (измеряемо в сравнительном исследовании) доказать свою полезность в поиске багов.
Мусор == вся немерянная масса гуглимых багрепортов и мысли по поводу них.

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

Как генерировать эвристику на основе текста (в котором встречается рассмотрение и обсуждение багов, что «помогает «натаскать» взгляд на обнаружение багов, благодаря фиксации в мозгу определённых шаблонов, состоящих из наборов признаков наличия багов того или иного вида»)?

Например, такой текст описывает как был найден баг: techblog.traveltripper.com/search/label/Bugs
Иногда публичные багтрекеры хорошо описывают процесс нахождения бага. Как будем загонять их в инкубатор?

https://bugs.eclipse.org/bugs/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=__closed__&product=&content=recursion
https://bugs.launchpad.net/bugs/+bugs?field.searchtext=recursive&orderby=-users_affected_count&search=Search&field.status%3Alist=FIXRELEASED&field.importance%3Alist=CRITICAL