Формирование виртуальной личности

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

• вам нет 18. Стереотип безответственной школоты ничем не уничтожить
• вконтакте вас зовут Вася, на бирже Петя, а вебмани будет выдавать, что вы Маша. Мало кто задумывается в самом начале пути о своём виртуальном профиле, а зря, потом уже ничего не изменить. Подумайте не только о достоверности вводимых данных, но и о их «чистоте». Если юзер под вашим ником будет на форуме phpclub-а просить научить его программировать, то будьте готовы к внезапно потерянным клиентам.
• дайте будущему заказчику максимум информации о себе: телефон, скайп, аська, номера кошельков и счетов.
• уделите внимание социальным сетям. Ни что так не компрометирует исполнителя, как страничка вконтакте содержащая мат, падонские выражения и т д
• поставьте себя на место заказчика и проверьте на чистоту и логичность всю эту информацию через поисковые системы
• старайтесь писать без ошибок и опечаток. Про матершину в общении с заказчиком думаю даже говорить не стоит.

Привыкайте жить в новую эпоху…

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. Спустя девять месяцев сайт купила крупная консалтинговая компания.

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