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

Командная строка появляется при нажатии комбинации клавиш Shift-F2 и обладает системой дополнения команд и их параметров; также не забыли про подробные подсказки. Спектр задач, которые могут быть решены из командой строки, довольно широкий — от управления содержимым веб-страницы и её разнообразным анализом до создания скриншотов отдельных сегментов страницы, которые могут определяться, так сказать, «изнутри» — прямо по тегам. Видео-демонстрация работы нового инструмента приведена на видео ниже:



На данный момент Firefox 16 доступен в виде бета-версии здесь.

Итак, пятница, почти конец рабочего дня… Программистам посвящается.
(стырено на просторах интернета)
UPD: нагло стырено вот отсюда.


Утро, начало рабочего дня — Миссионерская поза

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

Может кому будет интересно как «по-быстрому» провести нагрузочное тестирование своего веб-приложения.
Подробности под катом

В топике блиц-обзор книг, которые будут полезны IT-специалистам, бизнесменам и тем, кто собирается открыть своё дело. Рядом с каждой — короткие пояснения, почему и зачем стоит прочесть.

Отобраны лучшие 10% из примерно 200 прочитанных книг о маркетинге, продажах и всем связанном — самые «пробивные» вещи, которые помогут вам не тратить время на всякий шлак, а сразу начать с главного.

В конце — суммация книг, которые хабровчане рекомендуют в комментариях помимо основного списка.

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

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

Релиз.

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

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

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

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

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

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

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

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

Сегодня я не смогла уснуть. Тяжкие думы не первый день омрачают моё бренное существование.

Их первоисточником (или, скорее, катализатором) послужило описание сферы тестирования на сайте SQA Testing School, находящейся в Силиконовой долине. В этом описании тестирование представляется как элементарная область, научиться которой можно очень быстро, знаний для этого нужно минимум, а зарабатывать в которой можно очень даже неплохо.

Первой праведной мыслью было: тестирование обидели!

На смену первой пришла вторая, более взвешенная: описанное вполне соответствует действительности. Устроиться тестировщиком легко. Быть плохим тестировщиком и при этом не быть уволенным — легко. Не приносить ни малейшей пользы проекту, и при этом зарабатывать нормальные деньги — легко.

Но ведь бывают, бывают истинные гении своего дела, которые приносят пользу, и, несмотря на «болотистый» рынок труда в сфере тестирования, являются высококвалифицированными специалистами!

Кто они?
Как отличить настоящих джедаев от поддельных тестировщиков?

Результатом раздумий стал СПИСОК ИЗ ДЕСЯТИ ОТЛИЧИЙ НАСТОЯЩЕГО ТЕСТИРОВЩИКА ОТ ПОДДЕЛЬНОГО.

Для бизнесменов есть разные книги: «Как сделать ЭТО», «Как сделать ТО». А есть книги, задача которых — мотивировать, помочь посмотреть на ситуацию с новой стороны, побороть страхи и начать действовать.

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

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

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

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

Конечная цель автоматизации тестирования представляет собой некий набор автотестов, которые, при нажатии на кнопку «GO!», будут поочередно запускаться. Ну или всегда можно запустить какой-либо автотест отдельно, если для этого есть необходимость. Каждый такой скрипт проверяет правильность работы определенной части приложения и фиксирует ошибки в случае, если что-то работает не так.
О том, насколько выгоднее использовать автоматизированное тестирование чем ручное, а так же о плюсах автоматизированного тестирования хорошо написано в этой статье. Я же хочу описать возможные проблемы, с которыми может столкнуться тестировщик, решивший использовать автоматизированные тесты.

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

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

Если присмотреться к различным ИТ-профессиям, складывается ощущение, что «движухи» у тестировщиков больше, чем в любом другом направлении. Оно и понятно: отрасль молодая, незрелая, и уровень квалификации по сравнению с западным отстаёт.

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

Я 8 лет занимаюсь тестированием. Ручным и автоматизированным, в роли тестировщика и тест-менеджера, как сотрудник компании и как представитель аутсорса. И почти на всех проектах сталкиваюсь с одной и той же проблемой: руководители проектов не понимают, зачем им нужно тестирование.

Если задать среднестатистическому РМ'у простой вопрос: «Зачем на этом проекте тестирование?», то чаще всего ответом будет «Ты же тест-менеджер, ты и должна ответить на этот вопрос».

Но ведь приходя в парикмахерскую вы не говорите мастеру «вы сами знаете, что мне нужно»? И в продуктовом магазине вы не просите продавца накидать вам в корзину то, что вам нужно? Вы можете советоваться, вы можете узнавать «а как можно?», спрашивать варианты, но решение всегда за вами. В чём отличие тестирования? Может, в том, что слишком мало менеджеров проектов понимают, зачем оно им?

В этой статье я постараюсь выступить в роли продавца, который показывает клиенту: «а что вообще бывает?» Многие вещи будут описаны, возможно, слишком подробно, слишком просто… Не серчайте, мне просто очень хочется быть понятой :)

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

Зачем что-либо измерять?

Есть проект. Ваш любимый, родной, которому вы желаете расти и процветать.
Но как вы оцените его процветание, если нет критериев этого самого процветания?
Как вы сможете оперативно среагировать на проблемы до того, как они стали неисправимыми, если не будете использовать «датчик грядущей Ж»?
Как вы поймёте, что именно следует улучшать, если вам неизвестен источник проблем?

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

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

А если не приходят, значит метрику можно смело выбросить ;)

Многие считают, что тестирование ПО — это поиск ошибок. Иногда я говорю тестировщикам: «не старайся найти как можно больше ошибок, старайся пропустить как можно меньше!», и меня не понимают: а в чём разница?

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

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

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

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

История 17-летнего австралийского веб-программиста Лэйчи Грума (Lachy Groom) показывает, что предпринимательство — это талант: или он есть с малых лет, или его нужно долго в себе искать.

Этот парень (на фотографии он учит программированию студента) начал заниматься бизнесом с малых лет, в детстве он торговал газировкой и занимался выгулом собак, к 11-ти годам отец научил его HTML и CSS. В 2008 году в возрасте 13-ти лет мальчик основал первый стартап PSDtoWP.com. По заказам клиентов, преимущественно, из Европы и США, он создавал WordPress-темы из макетов Photoshop. Спустя девять месяцев сайт купила крупная консалтинговая компания.

Данный пост навеян статьей "Я, пользователь!", которая вызвала много споров, и была весьма прохладно встречена сообществом. Обсуждение в комментариях показало, что мысль, которую Автор высказал довольно жестко и агрессивно, была воспринята как призыв вернуться к ветряным мельницам. Однако, на мой взгляд, проблема затронутая автором, гораздо глубже.

Привет всем!

Хочу представить вам Карту Интернета или результат кластеризации более чем 350 тысяч сайтов в соответствии с переходами пользователей между ними. Размер круга определяется посещаемостью сайта, цвет – национальной принадлежностью, а положение на карте – его связями с другими сайтами. Если два сайта имеют стабильный поток пользователей между ними, то они будут «стараться» расположиться ближе друг к другу. После завершения работы алгоритма, на карте можно наблюдать скопления сайтов (кластеры) объединенные общими пользователями.



Например, если ввести в поиск habrahabr.ru, то можно увидеть, что dirty.ru и leprosorium.ru в том же «созвездии», а еще подальше livejournal.ru. Это говорит о том, что тот, кто сейчас читает этот текст, также с высокой вероятностью посещает эти сайты (относительно усредненного пользователя Рунета конечно).

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

Тем, кого интересует краткое техническое описание – добро пожаловать под кат