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

• управляющего проектом это позвоночник и вегетативная нервная система
• программисты это скелет и моторика
• аналитики это органы чувств
• тестеры это совесть

Quality Assurance часто считается синонимом тестирования, но на самом деле это методика предотвращения ошибок, а не их поиска и исправления. Качество в этом смысле — характеристика сделанного продукта.

Формально говоря, тестер должен проверять даже техническое задание, план проекта и анализ на логичность и понятность, а не только код и интерфейс программы. Тестирование как независимая дисциплина в общем потоке разработки ПО появилась в начале девяностых, когда стали более важны аудитория (клиенты), качество и время разработки.
Важность тестирования ПО особенно важна в критических системах. К примеру аппарат по лучевой терапии Therac (1985) облучил смертельной дозой радиации 6 человек из-за отсутсвия проверки состояния агрегата в коде и валидации. Или марсоход в 1999 году принёс убыток в 125 млн долларов из-за непродуманности единой системы измерения между коммандами разработчиков. И даже в Эстонии при электронных выборах были проблемы из-за плохого нагрузочного тестирования.
Основные принципы тестирования воплощены в небольшом документе ISTQB и в книге «Foundations of software testing».
Вся «прелесть» специальности тестера в том что как правило для этого не нужны большие познания в программировании и люди далёкие от web-строительства могут себя попробовать в этой роли.

Я занимаюсь в Яндексе продуктовой безопасностью и, кажется, сейчас самое время подробнее, чем уже было на YaC, рассказать на Хабре о том, как мы внедряем TLS.

Использование HTTPS-соединений является важной частью безопасного веб-сервиса, так как именно HTTPS обеспечивает конфиденциальность и целостность данных на этапе передачи их между клиентом и сервисом. Мы постепенно переводим все наши сервисы только на HTTPS-соединение. Многие из них уже работают исключительно по нему: Паспорт, Почта, Директ, Метрика, Такси, Яндекс.Деньги, а также все формы обратной связи, имеющие дело с персональными данными пользователей. Яндекс.Почта уже больше года даже обменивается данными с другими почтовыми сервисами по SSL/TLS, поддерживающими это.



Все мы знаем, что HTTPS — это HTTP, завернутый в TLS. Почему TLS, а не SSL? Потому что принципиально TLS — это более новый SSL, при этом название нового протокола наиболее точно характеризует его назначение. А в свете уязвимости POODLE можно официально считать, что SSL больше использовать нельзя.

Привет, Мегамозг! Раньше подобные материалы мы писали на Хабр, но после отселения «управленческих и маркетинговых» историй, решили попробовать здесь.

Недавно мы запустили совместно с UMI большой образовательный спецпроект про продажи и маркетинг для студий и агентств (мы уже опубликовали все 5 сезонов в 17 эпизодов). В его рамках я подготовил текст про ключевые KPI в управлении и планировании развития бизнеса агентства — и хотел поделиться им с аудиторией Хабра/Мегамозга.

1. Вводная, зачем этот материал

Наверное, любой руководитель агентства с минимальным управленческим бэкграундом будет знаком с 80% описанных в нашем материале KPI. Цель нашего материала — показать многообразие возможных показателей оценки результативности и эффективности бизнеса с учетом агентской специфики. Если вы найдете в нашем списке из более чем 50 индикаторов хотя бы пару показателей, об учете которых вы ранее не задумывались, а они важны — то мы добьемся своей цели.

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

Доброго времени суток. На данный момент я занимаю должность Senior/Team Lead IOS Developer. Так вышло, что за последний год мне довелось побывать на огромном количестве собеседований, так сказать, по обе стороны баррикад. Поэтому мне бы хотелось поделиться своим опытом и поговорить о том, как, на мой взгляд, надо проводить собеседование, ведь в общей суматохе можно упустить ряд важных моментов, что, впоследствии, может негативно отразиться на качестве собеседования.



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

В марте 2014 года компания Quickme объявила Партнерскую программу Quickme Sfera 2014. Горизонты программы — продажи решений компании через ресейлеров — облачных, классических хостинг провайдеров, телко. Сегодня я хотел бы расставить акценты в ответе на вопрос «почему» стоит бизнес с нами — включать наши сервисы в продуктовый портфель компании. Это вызвано исключительно большим количеством запросов от потенциальных партнеров после предыдущих публикаций, в которых мы говорили о партнерских каналах в частности.

В нашем проекте мы постоянно меняем основной лендинг или создаем дополнительные лендинги для направлений нашего сервиса. Каждый раз стараемся найти лучший вариант представления нашего продукта. Но что менять, а что оставлять, не всегда понятно с первого взгляда. Поэтому мы перевели статью, в которой препарируются 20 лэндингов известных стартапов.

Это как собрать идеальную девушку из топ моделей или любимых актрис. Только про лэндинги.
Итак, запаситесь чашкой кофе, понеслась.

Не так давно пришлось столкнуться с тривиальной задачей — найти решение, которое позволит рендерить рисунки графиков для .NET. Сразу оговорюсь, что меня интересовали только линейные графики. Камнем преткновения, который подтолкнул к переделыванию уже существующего решения (это были графики, встроенные в rdlc отчеты), было быстродействие. В целом, к искомому решению были предъявлены такие требования:

1. Необходимо оставить данную оптимизацию незамеченной для конечного пользователя, следовательно, решение должно быть широко настраиваемым, чтобы, в конечном счете, выглядеть так же, как и предшественник.
2. Работать быстро (ну понятно, пользователи не любят ждать).
3. Желательно, быть бесплатным или с открытым исходным кодом. Покупка не стала бы большой проблемой, найди я отличное платное решение, но начать лучше с open source.

У хорошего интерфейса пользователя высокая конверсия и его просто использовать. То есть, он хорош и для бизнеса, и для использующих его людей. Вот список опробованных нами идей.

1 Один столбец вместо нескольких

Один столбец точнее отражает то, что вы хотите донести. Пользователи проходят сверху вниз по более предсказуемому пути. В дизайне с несколькими колонками есть риск отвлечения пользователя от основной задачи страницы.

Недавно я прочитал книгу Алана Купера «Психбольница в руках пациентов». Из нее мне удалось почерпнуть ряд идей на тему «как улучшить разработку». Ниже ряд рекомендаций из книги, которые я беру на вооружение.
Вдохновил меня Milfgard вот этим постом. Попробую прочитать все интересные для меня книги из этого списка.

Учил студентов предмету «Тестирование и отладка программного обеспечения» в ИжГТУ. Структуру курса обучения построил на основе классификации видов тестирования.

Привет, Хабр! Недавно мы запустили большой образовательный спецпроект про продажи и маркетинг для студий и агентств. В его рамках я подготовил текст про подготовку коммерческого предложения на боевом примере — и хотел поделиться им с аудиторией Хабра.

Мы пишем много разных теоретических материалов, и меня часто спрашивают "Андрей, теория — это хорошо, ну а покажи, как должно выглядеть конкретное предложение, которое ты считаешь хорошим?". Этот текст — мой развернутый, почти на 20 страниц, ответ на этот вопрос.

Я выбрал кейс, максимально приближенный к реалиям — и в виде полу-художественного повествования провел своего лирического героя Бубликова по всем этапам подготовки КП и участия в тендере. Давайте начнем:

Итак, в рамках кейса мы представляем выдуманную компанию «Студия Бубликова», работаем в Москве, основаны в 2008 году, в нашем штате 17 человек, мы специализируемся на продакшн-услугах, работаем на UMI, для пары-тройки давних клиентов ведем контекст и немного SMM, работаем по средней ставке в 1700 руб./час, имеем хорошую поддержку (с выстроенными процессами и выделенными ресурсами). Мы есть в некоторых рейтингах веб-студий в середине списка, пару раз в год выступаем с докладами на среднего размера конференциях, позиционируемся как хороший продакшн второго эшелона с сильной поддержкой. Наши клиенты — сфера услуг, ecommerce, несколько добывающих компаний, пара агентств недвижимости. Делаем, в основном, корпоративные сайты, магазины, иногда промо-сайты. Сложные большие сервисы и порталы особо не умеем.

Я тот самый Бубликов, чьим именем названа наша студия.

Продавец это совсем не тот кто, звонит всем и каждому и впаривает свои товары. Время говорящих далдонов, которые берут количеством звонков, безвозвратно уходит, особенно в кризис. Почему покупатели покупают менее привлекательную продукцию или услугу, но у более эффективного продавца, и казалось бы продукцию с более высокими характеристиками при той же цене, совсем не покупают у другого? Хотел бы предложить свои мысли по этому вопросу.

Речь пойдет в основном о корпоративных продажах, но и в рознице данной информацией тоже можно воспользоваться. Материал из серии — галопом по Европам, если будет интерес, смогу по каждой стадии написать.

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

В этой статье я покажу вам некоторые из лучших JavaScript библиотек для построения диаграмм/схем (и сводных таблиц). Эти библиотеки помогут вам в создании красивых и настраиваемых графиков для ваших будущих проектов.

Хотя большинство библиотек являются бесплатными и свободно распространяемыми, для некоторых из них есть платные версии с дополнительным функционалом.

Казалось бы, зачем сейчас вообще вспоминать про IPv6? Ведь несмотря на то, что последние блоки IPv4-адресов были розданы региональным регистраторам, интернет работает без каких-либо изменений. Дело в том, что IPv6 впервые появился в 1995 году, а полностью его заголовок описали в RFC в 1998 году. Почему это важно? Да по той причине, что разрабатывался он без учета угроз, с той же доверительной схемой, что и IPv4. И в процессе разработки стояли задачи сделать более быстрый протокол и с большим количеством адресов, а не более безопасный и защищенный.

Введение

oDesk — крупнейшая в мире (ну по крайней мере так считает сам oDesk) международна биржа фрилансеров. Про сам оDesk на хабре писали уже довольно много раз, например тут или тут, где, на мой взгляд, практически разжёвано зачем и для кого создан данный ресурс, и особенно “с чем его есть”. В связи с этим этап описания и принцип работы сайта можно опустить. Я же попытаюсь провести анализ данных как о самих фрилансерах, так и о заказах, заказчиках и их требованиях к фрилансерам — грубо говоря что нужно уметь и знать, чтобы быть более менее в теме современных технологий. Также проанализирую спрос и предложение на основе данных о навыках фрилансеров и требованиях клиентов. И конечно некоторые статистические данные и немного красивых картинок в качестве примеров (кто работает на oDesk, откуда в основном идут заказы, кто больше зарабатывает, а кто лучше работает и т.д.). И все это на основе самостоятельно собранной информации, так открыто и благородно предоставляемой самим oDesk’ом посредством API. Стоит отметить, что статья с небольшим количеством статистики про oDesk ранее уже успела промелькнуть на просторах хабра, однако в ней, в отличии от текущей статьи, oDesk сам себя хвалил предоставил результаты. В целом же, сразу хочу сказать, что не претендую на полноту обзора, однако ниже будет кратко описан процесс сбора данных, что позволит провести Ваш собственный анализ при необходимости.

Много статей и публикаций есть в сети. Однако я решил написать свою методичку.
Дело в том, что как Вы понимаете — интернет с большего не модерируеться. А устроен так, что хранит все и очень долго. По этому, то что было актуально год назад — не актуально сейчас.

Когда читаешь интересную книжку, часто хочется обсудить с друзьями конкретные фрагменты текста, просто поделиться с ними или хотя бы сохранить для себя какие-то цитаты. К сожалению, в случае с бумажной книгой это почти невозможно сделать, разве что оставить пометки на полях, но их всё равно никто не прочитает. Другое дело — электронные книги, если к ним прикрутить удобный «социальный» интерфейс, то может получиться довольно интересно. Subtext — очередная попытка сделать популярное приложение такого рода.

Добрый день хабрачитатели. Вчера я наткнулся на неприятный факт, а именно, код AdSense работает только при загрузке страницы. Если же попытаться обработать код AdSense, который находится в данных, которые мы получаем при помощи ajax, то ничего из этого не выйдет (выйдет только ошибка). Подгружаемый скрипт Google, использует document.write, который работает только при загрузке страницы. Но ведь страница уже загружена. И я начал копать…

В последние несколько лет регулярно появлялись статьи о роли социальных интернет-сервисов в так называемых революциях, то и дело вспыхивающих в разных уголках третьего мира (среди них особо выделяется одна, рассказывающая о применении таких технологий как Tor, OpenGSM, mesh networking [1]). Как правило, дальше констатации факта их использования дело не шло. Но в этой статье, с помощью Википедии и здравого смысла, попытаемся копнуть чуть глубже и увидим удивительную схожесть между DDoS-атакой и «твиттер-революциями», а также способы противодействия им.

В продолжение или в поддержку поста Видео. Пример разработки приложения с помощью TDD. За основу мы взяли задачу — написать крестики-нолики с использованием TDD.

Отличие данного примера:
* больше теории про TDD
* немного отошли от стандартного цикла тест-код-рефакторинг
* пришлось ускорить сессию парного программирования в 5 раз (иначе получится двух часовая запись)
* запись в стерео, поэтому будет разговор в разных ушах

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