Время на творчество

Если вы не в состоянии выделить своим людям время,чтобы у них был шанс вас поразить,вы не добьетесь от них максимальных результатов(c) ( из книги «Муза не придет: Правда и мифы о том, как рождаются гениальные идеи » )

Обычная рабочая неделя. Трекер забит задачами разной важности и приоритетов, немалая часть которых нужна "здесь и сейчас", а то и "вчера". Планы.. планов громадье, в них те же важные задачи, которые будут нужны завтра. Идеи.. идеи возникают разные и подчас оцениваются сквозь призму сиюминутной прагматичности. "Мы все понимаем, было бы круто.. но здесь и сейчас нам надо не это..." При этом все мы хотим прорыва, мы хотим быть лидерами отрасли, мы хотим делать нашу работу лучше, качественнее и эффективнее других... Возможен ли прорыв без подлинного творчества ? Может ли сотрудник выдать что-то гениальное , действительно прорывное, когда он не может поднять головы от рутинных , нужных "сейчас или никогда" заданий ? Есть ли место свободному полёту мысли в условиях "обычной рабочей неделе" или же такому творчеству место только на выходных ? Реален ли подход к планированию , когда людям выделяется фиксированное ( не мизерное ) количество рабочего времени, которое они могут посвятить реализации своих задумок, пусть даже не сильно связанных с текущими решаемыми задачами ? Да, кто-то где-то говорил-писал, что подобие такого подхода есть или было в гугле. Есть ли еще успешные примеры применения такого подхода ?

Бесплатные курсы от MongoDB

Совсем недавно успешно прошел курс MongoDB For Developers. Соответственно, небольшая ретроспектива )

Перед началом обучения у меня имелись некоторые хаотичные навыки использования MongoDB и далеко не полное понимание механизмов работы этой NoSQL субд.

На портале https://university.mongodb.com/ есть набор бесплатных курсов для разработчиков и администраторов.  Я выбрал классический - "для разработчиков" (pymongo + mongodb).

О курсе

Курс разбит на 7 недель + финальный экзамен.

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

Большинство лекций сопровождается небольшим заданием (quiz) , помогающим закрепить понимание. Ответы на такие задания никак не учитываются в финальных баллах. Но рекомендую все-таки выполнять все из них до полного понимания. Задания, к слову, простейшие. Есть лекции-заметки без заданий, но их меньше.

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

Был даже случай, что не работала инфраструктура онлайн-обучения целые сутки. Срок сдачи очередного домашнего задания, тем не менее,  сдвинут не был. А казалось бы, форс-мажор)

Задачки в домашних заданиях тоже не сложные, очень практичные, конкретные и поучительные. Придется и в mongo-консоли повозиться и даже немного поупражняться в pymongo. С первой и до последней недели домашние задания сопровождаются "учебным проектом" - приложение для blog-a. Приложение состоит из микрофреймворка bottle.py, pymongo и самой mongodb.

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

Задачки и вопросы на экзамене посложнее , чем в домашних работах, но , по-моему, тоже не слишком сложные.

Впечатления

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

Ну и несколько советов:

1. не ограничивайтесь видео-лекциями и обязательно "курите" официальную документацию по mongo. Благо, она почти что образцовая.
2. не откладывайте домашние задания на последний день и час - берегите нервы. В последний момент что-то обязательно помешает засабмитить результат в срок. 
3. сразу проверьте, что в установленной у вас версии mongodb есть поддержка aggregation framework. Лично на моем debiane поставленная из репозитория монга была уж очень древняя.
4. пользуйтесь Discussion обучалки - большинство вопросов, которые у вас возникнут , наверняка возникнут еще у кого, то и в форуме будут обсуждены и решены.
5. запаситесь терпением - сертификат об окончании придет далеко не сразу :)

Как легко получить JUnit-отчеты в Django

Хороший все-таки фреймворк Django, удобный,  постоянно улучшающийся и развивающийся, отлично документированный и так далее.

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

Разработчикам автотестов Django предлагает свой wrapper стандартного питоновского фреймворка PyUnit ( unittest ). Причем до версии django 1.6 у этой надстройки был один недостаток - довольно неудобное обнаружение автотестов (test discovey).

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

Но остался нерешенным еще один "недостаток". А именно невозможность "из коробки" генерировать отчеты о прогонах автотестов  в JUnit xml-формате . Это довольно странно, особенно ввиду большого числа CI-решений, которым нужен такой формат: jenkins/hudson, bamboo etc...

Для предыдущих версий django cторонние django-разработчики успели реализовать несколько приложений для решения задачи получения xml-отчета. Большинство этих приложений не работают с 1.6 версией и должны быть соответствующим образом доработаны.

Мы ждать не хотим, писать свое нет времени и ресурсов. Поэтом нам на помощь приходит никто иной как pytest. С его помощью можно генерировать junit-отчеты безо всякого изменения настроек django-проекта и без изменений в имеющихся автотестах. 

Для этого надо:

1. поставить pytest-django
2. для запуска тестов использовать py.test вместо django-ского  manage.py test ...

pip install pytest-django

cd /path/to/django/project
py.test --ds=DJANGO_SETTINGS_MODULE --junitxml=/path/to/junit/xml/report

Получив xml-отчет мы можем уже отображать его в любом CI-решении, которому нужен junit-формат. Например,  в bamboo  - используем встроенный компонент JUnit Parser, указав  в его параметрах , где искать xml-отчет о прогоне автотестов. Таким образом, мы можем использовать всю мощь и гибкость py.test и продолжать при этом писать тесты с помощью встроенных в django механизмов.

К слову, можно и сами django-тесты  писать в py.test - стиле. Но лично мне формат PyUnit нравится больше.

Ссылки по теме:

• тестирование в django
• pytest-django
• Atlassian Bamboo

Первые 15 минут у нового провайдера )

Сегодня от "провайдера N" приходил ко мне мастер подключать интернет+ТВ.
У меня уже есть качественный доступ в интернет-услугам, но вот захотелось посмотреть , что у других - тем более предоставляется тестовый доступ на 1й месяц.
Схема подключения - через коаксиальный кабель, модем и ТВ-тюнер (для телека). Подключение заняло минут 15 , не больше. Мастер ушел. Начался тестовый период в прямом смысле слова =)

Интернет

Единственное, что можно сразу проверить  - это соответствует ли реальная скорость обмена данными.

В тарифном плане (ТП) заявленная скорость подключения - 15 мегабит . Ну хорошо, пусть "до 15 мегабит"... Несколько повторных тестов на разных онлайн-тестерах ни разу  не показали больше 7.5 Mbit/s

http://www.speedtest.net/my-result/2952653119

В сравнении с имеющимся текущим провайдером , с его "практически честными" 20 мегабитами , новый провайдер явно не впереди.

Телевидение

Пока это обычное IP-телевидение , никакое не HDTV. Три пакета каналов в том числе и все федеральные.

Качество показа в плане "мурашек" :) хорошее, цифра все-таки ) Но один неприятный момент сразу бросился в глаза - картинка не умещается на экране. Например, логотипы каналов полностью не влезают. Игры с настройками самого ТВ (неплохой телек LG линейки 2012 года) не помогли. 

В аналоговом варианте - те же каналы смотрятся гораздо приятнее.

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

Личный кабинет

Личный кабинет (ЛК) - это самое приятное для тестирование. Это , как обычно, веб-портальчик для управления своим сотрудничеством с провайдером.

Управление услугами

Баг вылез еще до того , как успел  толком оценить функциональность и удобство .

На скрине видим, что получается, если несколько раз кликнуть на развернутом пункте в списке меню:

Хорошо, что такие клики не приводят к реальному изменению списка услуг :) и обновление страницы восстанавливает dom.

И еще непонятно, почему статус нормально работающей услуги (телевидение) красный , что бы это значило ?

Обратная связь

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

Создал сообщение, попытался приаттачить скриншот - "файл не выбран".. попытался еще раз - опять "файл не выбран".

Ну хорошо - отправил без скриншота. В итоге файлы все-таки ушли - два одинаковых )

Тут же решил проверить форму "дополнить сообщение" - и там ошибки. Сабмит формы завершается следующим:

...хотя дополнительные сообщения при этом добавляются ...

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

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

Пробую урезать url до корневого: https://office.operanorN.ru/ - и вижу форму с логином - то есть надо опять логиниться, хотя сессия от старого жива и продолжает жрать ресурсы сервера (бд, очистка старых сессий и так далее)... "Удобно" , ничего не скажешь.

Справедливости ради скажу, что саппорт отвечает очень шустро )

Дальше ковырять пока не стал. Но чувствую, что впереди еще будет много "интересного".

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

масдай

Вчера утром windows-7 на домашнем компьютере в очередной самообновилась, после чего запуск любого невиндового приложения приводил к ошибке 0x000005 Так как сразу было ясно , что виной всему очередной непротестированный ms-патч, то удаление всех обновлений этого утра и последующая перезагрузка с запретом дальнейших апдетов решили проблему. Не первый раз уже подобные казусы случаются а масдаевскими патчами. Поэтому становится очень интересно, в чем именно состоит технология тестирования обновлений в Microsoft ? Тестируются ли они ? Ведь бывало даже так, что ось даже не загружалась после очередного обновления. Такое сложно им отловить ? Или быть может эдакое неявное краудсорсерское тестирование и есть технология тестирования апдейтов в MS? Эта организация славится своими спецами в области qa, красивыми и живыми докладами на эту тему, различными best practice по организации процесса контроля качества ПО, но ежедневные наблюдения почему-то подсказывают, что "не все в порядке в датском королевстве"... Ведь неслучайно хакеры/исследователи радостно потирают ручки , если вдруг им удается выяснить , что на исследуемом хосте крутится именно MS windows ?

Хабр не выдержал хабраэффекта )

Универсальное резюме :)

Автотесты на автотесты ?

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

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

Попробуем разобраться, почему так происходит...

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

Первый пункт обсуждать, думаю, не имеет смысла - это вопрос опыта, осознанности..

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

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

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

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

uml для описания тест-кейсов

Уже довольно продолжительное время приходится заниматься дизайном тестов для ПО из сферы телекомуникаций.
Как правило тест-кейсы направлены на проверку взаимодействия абонента, сетевого оборудования , ААА-серверов и т.д.
Для описания тестовых случаев мною обычно применялся классический способ - текстовое описание предусловий, последовательности действий, результата.
С некоторых пор стал замечать, что описанным классическим способом тестовым случаям не хватает наглядности, а само описание текстом последовательности пакетов, действий с БД и так далее - довольно утомительное занятие, при котором сам дизайнер нет-нет да оставит что-то между строк как само собой разумеещееся.
Все это приводит к появлению риска неполного или неправильного понимания описания тестировщиком, увеличивает число уточняющих вопросов к дизайнеру при выполении теста. Для решения этой "проблемы" решил попробовать uml-диаграммы. А точнее activity-диаграммы.
Например:
 
На мой взгляд, гораздо нагляднее и лаконичнее, чем расписанная по пунктам последовательность действий, пакетов , ответов...
И чем сложнее тестовый-случай (взять хотя бы сценарий использования Cisco SSG , личного кабинета с какой-нибудь турбокнопкой ) , тем оправданнее становится применение подобных схем. Текстовое описание входных данных , к которым прикрепляется подобная activity-диаграмма делают тест-кейсы подобного рода более наглядными и понятными конечному тестировщику.
Конечно же возникает вопрос способа рисования такой диаграммы.
Лично я не использую никаких десктопных приложений в стиле "перенеси и брось", а просто компиллирую uml-код в изображение.

Вот код для картинки, которая помещена выше:

@startuml
title 
Тест-кейс "Неверный пароль"
end title

participant User
participant NAS
participant Radiusd
participant DB

User    -> NAS: Start internet session with username = 'ivan' and password='007'
NAS     -> Radiusd: Access Request 
Radiusd -> DB: User authentication (check username and password)
DB      -> Radiusd: Incorrect password
Radiusd -> NAS: Access Reject
NAS     -> User: failed to establish internet connection

@enduml

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

Неплохой фаззер

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

Фаззер: uniofuzz



Написан на python. Довольно прост и в то же время универсален -  умеет генерировать рандомные файлы, фаззить tcp-соединения, пайпы и т.д.(см -help)

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

"Почти" - потому что пришлось научить ее фаззить udp вместо tcp и немного "поиграться" с длиной содержимого пакета.

Патч прост:
 
235c235
<               sock=socket.socket(socket.AF_INET, socket.SOCK_STREAM)
---
>               sock=socket.socket(socket.AF_INET, socket.SOCK_DGRAM)

Пример фаззинга (2 пакета в секунду) в сетевом соединении:

./uniofuzz.py -n -i 0.5 -ip 127.0.0.1 -port 12345 -s 9999

Утилита проста и эффективна, код открыт и прямолинеен - допилить под свои нужды - не проблема.