Чтобы Яндекс показал Ваш сайт в числе первых, нужно чтобы он максимально полно отвечал на запрос пользователя. И это будет уже половина успеха. Оставшаяся половина это удобство, техническая составляющая сайта и его простота. Ниже я привел чек-лист из 68 пунктов, который был разработан специально для системы управления задачами PTYSH, совместно с компанией DFAKTOR. А теперь я делюсь им с Вами. Кропотливое выполнение каждого пункта из данного чек-листа позволит вывести практически любой сайт на самый верх поисковой выдачи. Но придется как следует поработать. Начнем с самого малого.

Знакомьтесь, это обычный «литровый» пакет молока:

• Проверка на внимательность: там 900 грамм. Рядом несколько по 950. Но пакет может быть воспринят как литровый.
• Проверка на знание физики. Рядом лежит похожий кефир. Объём измеряется в миллилитрах, масса — в граммах. Плотность кефира трагически выше плотности воды. То есть 900 грамм кефира 3,2% жирности — это примерно 874,5 миллилитров.

Второй пациент:



25 лет гарантии. Круто, правда? Есть одна проблема. Надо сохранять чек. Проверка, опять же, на знание физики. Чек у них печатается на обычной кассовой термоленте (я проверил на месте). У меня в офисе лежит много чеков. Мы их ксерокопируем, потому что через год-два они полностью выцветают. Самый старый чек, который видел коллега, держался 3 года в папке в архиве. UPD: смотрите самый низ топика, Икея ответила.

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

Осторожно, трафик: под катом много находок с фотографиями.

Как обычно, мы пытаемся решить сложную математическую задачу минимальными средствами и затратами. Суть задачи – сортировать товары интернет-магазина так, чтобы это было наиболее удобно покупателю.

Самый простой способ – задавать порядок вручную. В физических магазинах на полках делается именно так, и это называется «выкладка». У нас её делают продавцы по планограммам под каждую точку (это входит в обучение), а в тех же больших продуктовых – специальные чуваки-мерчендайзеры, которые следят, чтобы всё было ок. В Интернете, конечно, хочется сделать так же, но метод хорош до 50 позиций.

На другой стороне шкалы методы больших данных, когда все данные о вас начиная от сборки браузера, типа девайса (точнее, его цены) и разрешения экрана, плюс все данные профиля и оценка ваших действий на сайте ведут к оптимальному результату. Самый простой способ использования таких данных – за первые 20-30 секунд нахождения на сайте строить ваш профиль и сравнивать с профилями таких же людей. И предлагать вам в итоге не самые дешёвые квартиры и отели, например, а начинать с тех цен, которые для вас будут приемлемыми. Вы наверняка знаете эту сортировку, которую почему-то подают в прессе под соусом «самой удобной для клиента».

По моим ощущениям, самая удобная для нашего покупателя – это такая, которая понятна и поддаётся контролю.

Самый лучший способ оценить, хорошо ли мы протестировали продукт – проанализировать пропущенные дефекты. Те, с которыми столкнулись наши пользователи, внедренцы, бизнес. По ним можно многое оценить: что мы проверили недостаточно тщательно, каким областям продукта стоит уделить больше внимания, какой вообще процент пропусков и какова динамика его изменений. С этой метрикой (пожалуй, самой распространённой в тестировании) всё хорошо, но… Когда мы выпустили продукт, и узнали о пропущенных ошибках, может быть уже слишком поздно: на “хабре” появилась про нас гневная статья, конкуренты стремительно распространяют критику, клиенты потеряли к нам доверие, руководство недовольно.

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

В своей предыдущей статье про создание msi-пакетов я описал способ как запаковать любое приложение в msi. MSI-пакеты я использовал для развертывания приложений через GPO, но к сожалению данный метод меня крайне разочаровал по нескольким причинам: установка только при загрузке компьютера, т.е. пользователю приходится дожидаться окончания установки, а иногда требуется побыстрее начать работу. Из этого вытекает, что некоторые не дожидаются и грубо перезагружают компьютер, результатом чего является недоустановленное ПО. Мне все это надоело и я вспомнил, что где-то читал про установку сторонних обновлений через WSUS. Действительно, способ относительно не новый и осуществляется с помощью Local Update Publisher, про установку которого есть достаточно полная статья. Особенностью данного метода развертывания ПО помимо всех преимуществ WSUS является возможность установки из exe и нет необходимости перепаковки в msi. И если с публикацией msi все понятно, то я хочу рассказать про установку через exe, в которой есть особенности.

Один технический специалист нашей компании PayOnline, которая занимается автоматизацией приема платежей, предложил перевести статью автора Pascal de Vink, который проработал тим-лидом уже 2 года. Когда Pascal только занял эту должность, оказалось, что ко многим вещам он был просто не готов. Эта статья поможет избежать многих ошибок на пути от разработчика к лидеру команды. Ниже идет непосредственно перевод.

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

Меньше заниматься разработкой

Может, это и очевидно, но роль ведущего разработчика означает, что надо больше смотреть на общую картину, чем углубляться в конкретные аспекты того, что происходит. Я этого не понимал, пока не проработал пару месяцев, в течение которых мучился от того, что хотел разобраться во всех задачах, а времени на это не было. У меня было все меньше времени копаться в коде, а люди продолжали обращаться ко мне со своими очень узкоспециализированными задачами. Слишком поздно я понял, что надо разбираться в команде, а не во всех ее знаниях. Узнать, кто разбирается в нужной области оказалось намного быстрее и ценнее. Хотя, копаться в коде было намного веселее.

В современном вебе несправедливо мало внимания уделяется хоть сколько-нибудь автоматизированному тестированию UI. Особенно это касается статической вёрстки. На проекте 2ГИС Онлайн мы попытались частично восполнить этот пробел. Какие полезные практики мы приобрели, и о каких хороших библиотеках мы узнали, расскажем далее.

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

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

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

Релиз.

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

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

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

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

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

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

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

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

Написано по просьбам из соседнего топика — Как мы тестируем поиск в Яндексе. Screenshot-based тестирование блоков результатов

История про глубокий рефакторинг.

В нашем приложении был один модуль, реализованный на заре бизнеса. Модуль был реализован используя отличные от других модулей патерны, во всю эксплуатировал глобальные переменные, состоял из более чем сотни javascript файлов, которые были тесно связаны друг с другом. Малоизвестный фреймворк, на базе которого был сделан модуль, больше не использовался нигде. В результате, исправление ошибок или добавление новой функциональности занимало у команды в 2-3 раза больше времени, по сравнению с другими модулями. В связи с грядущими изменениями функциональности назрела острая необходимость отрефакторить этот немаленький модуль.

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

Чаще всего для автоматизации тестирования веб-сервисов применяется Selenium WebDriver. Как правило, с его помощью пишут функциональные тесты. Но, как всем хорошо известно, функциональные тесты не могут решить задачу тестирования верстки сервиса, что требует проведения дополнительных ручных, зачастую кроссбраузерных, проверок. Как тест может оценить корректность верстки? Чтобы обнаружить регрессионные ошибки верстки, тесту потребуется некоторый эталон, в качестве которого может выступать изображение корректной верстки, взятой, например, с продакшен-версии сервиса. Этот подход носит название screenshot-based testing. Подход этот применяется достаточно редко, и чаще всего верстку все же тестируют вручную. Причина этому – ряд достаточно строгих требований к сервису, к среде выполнения тестов и к самим тестам.

Расширенные ответы сервисов Яндекса в результатах поиска — мы у себя внутри по старой традиции называем их «колдунщиками» — дополнительное звено, в котором что-то может сломаться.

На примере тестирования колдунщиков в поиске мы расскажем, какими особенностями должен обладать тестируемый сервис, какие проблемы возникают у нас при использовании screenshot-based testing, и как мы их решаем.

Любой специалист, причастный к тестированию веб-приложений, знает, что большинство рутинных действий на сервисах умеет делать фреймворк Selenium. В Яндексе в день выполняются миллионы автотестов, использующих Selenium для работы с браузерами, поэтому нам нужны тысячи различных браузеров, доступных одновременно и 24/7. И вот тут начинается самое интересное.



Selenium с большим количеством браузеров имеет много проблем с масштабированием и отказоустойчивостью. После нескольких попыток у нас получилось элегантное и простое в обслуживании решение, и мы хотим поделиться им с вами. Наш проект gridrouter позволяет организовать отказоустойчивый Selenium-грид из любого количества браузеров. Код выложен в open-source и доступен на Github. Под катом я расскажу, на какие недостатки Selenium мы обращали внимание, как пришли к нашему решению, и объясню, как его настроить.

Прежде чем начать рассказ про наш очередной opensource-инструмент, давайте я поясню, для чего мы его сделали. Я довольно много общаюсь с коллегами-тестировщиками и разработчиками из разных компаний. И, по моему опыту, автоматизация тестирования ─ один из самых непрозрачных процессов в цикле разработки ПО. Посмотрим на типичный процесс разработки функциональных автотестов: ручные тестировщики пишут тест-кейсы, которые нужно автоматизировать; автоматизаторы что-то делают, дают кнопку для запуска; тесты падают, автоматизаторы разгребают проблемы.



Я вижу здесь сразу несколько проблем: ручные тестировщики не знают, насколько автотесты соответствуют написанным тест-кейсам; ручные тестировщики не знают, что именно покрывается автотестами; автоматизаторы тратят время на разбор отчётов. Как ни странно, но все три проблемы вытекают из одной: результаты выполнения тестов понятны только автоматизаторам — тем, кто эти тесты писал. Именно это я и называю непрозрачностью.

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

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

Привет всем из 2023 года!
Я написал эту статью 12 лет назад. И внезапно — это — моя самая популярная статья. Я так же удивился что люди до сих пор заходят сюда и читают эту статью. Поэтому я решил её обновить. И после прочтения понял, что обновлять ничего не буду.

Да, powershell обновился за последние годы. Теперь он стал Powershell Core, и его можно запускать как на Windows, так и на Linux и MacOS. В скриптах появилось много плюшек, но основная идея осталась той же.

Если вы только начинаете писать на Powershell эта статья для вас. Вам будут даны основные понятия, которые относятся к Powershell в 2023 году, и которые позволят вам погрузиться в эту оболочку с головой.

Приди ко мне брате в Консоль!
— Админ Долгорукий.

Много ярлыков улетело в корзину со времён выхода в свет 2008 Windows. Люди попроще дивились новому синему окошку, которое ребята из Майкрософт зачем-то вставили в свои новые продукты. Люди, которые сидят на блогах и знают программирование начали изучать это окошко.



В итоге к народу начало приходить осознание того, что Майкрософт действительно разработали что-то новое и интересное.
И так, зачем вам это нужно? В основном, программа под названием PowerShell (в дальнейшем PS) предназначена для администраторов и программистов. Она позволяет автоматизировать примерно 99% всех действий в системе. С помощью неё вы можете настраивать удалённые компьютеры, запускать и перезапускать сервисы и производить обслуживание большиства серверных приложений. Как выяснилось, возможности у программы потрясающие.

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

Задача этой статьи проста — показать вам малую долю возможностей PS и дать вам концептуальное понимание предмета. В действительности документации по предмету написано несметное количество, так что я не стремлюсь охватить всё. Я так же ознакомлю вас с набором утилит, которые позволят не вылезать из PS в принципе.

Tsung — это распределенная система нагрузочного тестирования, написанная на Erlang'е. Заявлена поддержка HTTP, WebDAV, SOAP, PostgreSQL, MySQL, LDAP and XMPP/Jabber. В этой статье я опишу как протестировать обычный web сайт на нагрузку.

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

Позавчера я тестировала свой небольшой веб-проект.

За 4 часа я завела 25 дефектов.

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

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

Если бы мне кто-то предложил в этот момент посмотреть фильм, поиграть в компьютерную игру или сходить в клуб, я бы ему ответила, что занята значительно более интересным занятием! Потому что это действительно очень интересно!

Это захватывает, и время пролетает очень быстро. Это творческая, непростая, ответственная работа, которая увлекает на 100%!

И я задумалась. Кто пишет про «скучно», «рутина» и «тупая работа»? Почему не всем нравится? Постаралась выписать всё, что пришло в голову.

Полтора года назад, когда вышла книга «How Google Tests Software», я загорелась перевести ее на русский язык. Я давно восхищаюсь Уиттакером, я переводила его статьи, слушала мастер-классы и считаю его самым крутым чуваком в тестировании. Тогда я еще работала руководителем отдела тестирования в «Иннове», и компания поддержала мой проект.

С тех пор многое поменялось: я перестала заниматься тестированием, выпускала приложения для iOS, сейчас работаю продакт-менеджером большого веб-проекта. Уиттакер же еще в 2012 году ушел из Google в Microsoft, громко хлопнув дверью.

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

И вот, в январе издательство «Питер» выпустило книгу на русском языке с нашим переводом и дизайном:

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

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

Вы PM. Как узнать – готова ли вёрстка к реальному использованию?
Вы заказчик. Как убедиться, что работа выполнена качественно?
Как оценить качество вёрстки?

Когда я стал тим-лидом, а позже PM, передо мной стала задача проверять вёрстку наших проектов. Нужно было выработать формальные, легкопроверяемые критерии, соответствие кода которым, должно было давать некую гарантию, что не будет факапов и ни клиент, ни программеры не сказажут потом “WTF?”.

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

Требования должны были быть такие, что соблюсти их легче, создавая качественную вёрстку, а не говнокод. Я составлял такой чек-лист в течении полутора лет. За последние полгода в него не добавилось ничего. Значит самое главное учтено.

Итак что же это за список?

Краткая версия теперь доступна на html5checklist.com (github), где можно вносить pull-request'ы.

История обновлений:

• 2015/08/11: Актуализировал рекомендации по оптимизации скорости загрузки. Добавил требование поддержки Retina. Дополнил «19. Мелочи» требованием что изображения должны масштабироваться в зависимости от размера окна.
• 2015/08/10: актуализирован список исключений для CSSLint
• 2015/07/29: актуализирован пункт №13 «плохо»/«хорошо»
• 2015/04/08: добавлено требование использования препроцессоров и рекомендация использования систем сборки
• 2013/04/25: добавлены анализаторами качества кода: CSSLint и JSHint, указан сайт подбора css font stack (спасибо @fliptheweb), мелкие уточнения (работу интерактивных элементов страницы, что не пропадает фон на высоких разрешениях, не должно быть пустых презентационных блоков, при проверках контента — пробовать удалять заголовки, менять местами блоки)
• 2013/04/24: добавил пункт об минимизации каскада (БЭМ-техники, MCSS, SMACSS), необходимости вписывания в экран моб. устройства, заменил ссылку на проверочный текст отображения стандартного html на код с normalize.css, поправил пример где в рекомендации встречался длинный каскад, упомянул про Opera на Presto и новый уровень семантики — в именах классов BEM.
• 2012/04/12: отсортировал пункты проверки в порядке важности, выделил главные, дополнил статью подробностями
• 2011/12/07: дополнил согласно доклада на WSD Минск'2011.
• 2011/07/19: добавлено про повышение надёжности вёрстки благодаря html5-тэгам, про необходимость favicon/apple-touch-icon, отсутствие багов при ресайзе textarea
• 2011/06/15: добавил пояснения какие ошибки валидации допустимы, рассказал про отсутствие официальной кнопки «HTML5 Valid» и про официальное лого HTML5 на сайте.

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

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