Концепция сайта — это первый результат дизайна сайта в широком смысле этого слова (в дальнейшем я буду употреблять его именно так, понимая под ним процесс проектирования и создания сайта). И первое, что, на наш взгляд, необходимо оценивать (не в коммерческом смысле этого слова, а в смысле «получить качественную оценку»).

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

Пройдя в очередной раз весь путь от выбора CMS до тестирования я задумался о том, что весь этот путь хорошо описан. Вот только найти внятную информацию о тестировании, без предложения спустить на него все деньги или не делать вообще — очень сложно. Надеюсь, моя статья побудит профессионалов в области тестирования исправить это положение и написать о тестировании. Особенно о тестировании в проекте, бюджет которого невелик.
Те Хабровчане, кто давно занимается разработкой сайтов возможно (я надеюсь) найдут мою статью довольно банальной и само собой разумеющейся. Но пользователи, которые делают только первые шаги смогут подчерпнуть для себя толику полезного.
Что мы получаем, проведя описанные ниже действия можно посмотреть здесь.

Буквально вчера на свет появилась первая версия удивительного проекта, о котором я хочу вам рассказать. Называется он несколько неприглядно — Fake.
Если коротко, то Fake — это основанный на WebKit и Applescript браузер, предназначенный для автоматизированного тестирования веб-приложений. Наверняка те из вас, кто еще не познал прелести автоматизированного тестирования, помнят, как отлаживали какую-нибудь сложную форму регистрации и, отлавливая особо хитрый баг, приходилось кучу раз перезагружать страницу и раз за разом заполнять форму. И даже те, кто уже пишет тесты, не могут быть уверены, что Javascript и Ajax работают как надо и все равно вынуждены тестировать сайт вручную загружая странички, снова и снова.

Очень хочется принять участие в конкурсе Visual Studio 2010. Уже писали о Unit-тестировании, о UI тестировании приложений, поэтому я напишу про тестирование веб-приложений. А так как в комплекте с новой Visual Studio 2010 поставляется ASP.NET MVC Framework 2, то использовать я буду именно его.
Это НЕ серьезное руководство по UI тестированию, это лишь легкое чтиво, которое просветит еще зеленых любителей студии (таких как я) о важном и удобном, но слегка пугающем функционале.

«Конверсия, конверсия, конверсия» — слова, которые постоянно крутятся в голове. Как заработать больше затрачивая меньше? Почему только каждый 100-й покупает мой товар? Что ему не хватает? Стоп! Давайте по порядку.

Что покупателю нужно?

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

На пути покупателя множество проблем. Я для себя разделяю их как «кто здесь?», «где здесь?» и «чё за на??!»

Тестирование веб-проектов. jsFUnit

В профессиональном программировании огромную роль играют автоматезированные тесты. Они заменяют и команду профессиональных тестеров и подсказывают о возникших неполадках в других частях
обширного проекта во время разработки. Работу веб-приложения необходимо тестировать на разных браузерных движках: Gecko, Presto, KHTML, WebKit и Trident.

Разновидностью автоматизированных тестов являются функциональные тесты. Их главная особенность — эмуляция работы пользователя с приложением
через интерфейс. В веб-программировании для написания функциональных тестов используют Selenium. Огромный недостаток Seleniuma — это его невысокая скорость выполнения таких тестов.

Более быстрым фреймворком оказался jsUnit. Правда, jsUnit предназначен для написания unit-тестов, а не функциональных. Обладает он и рядом других мелких недостатков. Как то —
обращение к тестам по их пути, а не выбор теста из списка. В случае хоть одной ошибки весь ползунок закрашивается в красный цвет, а не разделялся на зелёные/красные участки, соответствующие успешно/не успешно выпоненным тестам.

Всё это привело к созданию jsFUnit.