воскресенье, 3 ноября 2013 г.

ilivid пока не работает

Что-то я зря на Mavericks переехал. Почти все программы с ним работают. мягко говоря, плохо.

Process:         iLivid [69184]
Path:            /Applications/iLivid.app/Contents/MacOS/iLivid
Identifier:      ???
Version:         ??? (???)
Code Type:       X86 (Native)
Parent Process:  launchd [172]
Responsible:     iLivid [69184]
User ID:         502

Date/Time:       2013-11-03 22:49:13.269 +0700
OS Version:      Mac OS X 10.9 (13A603)
Report Version:  11
Anonymous UUID:  1EB8671D-74A3-C05A-F841-3ACF74B49579

Sleep/Wake UUID: FA8839C1-75C3-4498-99B9-25B01A11A11C

Crashed Thread:  0  Dispatch queue: com.apple.main-thread

Exception Type:  EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000007

суббота, 27 октября 2012 г.

Создаем облако для тестирования ПО

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

"Пока компании вроде Google и Microsoft активно рассказывают простому пользователю о счастье, которое ожидает их на облачных сервисах, я хочу поделиться другой стороной облаков — счастьем для разработчиков и тестировщиков ПО. За те несколько лет, в течение которых я руковожу группой тестирования Parallels Plesk Panel, была собрана неплохая коллекция лайфхаков по использованию облака для наших целей."

подробно читать на хабре

пятница, 24 августа 2012 г.

8 лет в Parallels

Сегодня ровно 8 лет как я в Новосибирском Parallels. За 6,5 лет я прошел путь от разработчика до директора по разработке& Быстро? - Я не знаю, но точно интересно. 

  • 2004-2005, разработчик
  • 2005-2007, ведущий разработчик
  • 2007-2008, руководитель группы 
  • 2008-2009, координатор R&D процессов 
  • 2008-2011, руководитель тестирования
  • 2009 2011, руководитель направления по (program manager) производительности и безопасности
  • 2011- по наст. время, руководитель по разработке 

среда, 1 августа 2012 г.

Мотивация для не мотивируемых

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

Уволить или терпеть? Терпеть не нужно! Уволить всегда успеете. Попробуйте починить ситуацию дабы сохранить сотрудника в компании.
Несколько полезных советов:
  1. Оцените сколько у вас времени на исправление ситуации. От этого будет зависеть выбор метода, а значит и скорость, и болезненность процесса. При чем в большей степени для вас, поскольку именно вам нужно будет смириться с некоторыми неудачами, которые вас с 90% вероятностью постигнут в начале или даже в середине вашего пути.
  2. Забудьте, что вы начальник для этого сотрудника. Рассматривайте себя как его коллегу, возможно даже менее опытного.
  3. Будьте честными.
  4. Доверяйте сотруднику.
  5. Всегда давайте так много информации, насколько это вообще возможно. Не устраивайте сотруднику информационную блокаду. Это плохо кончится в любом случае.
  6. Обрисуйте какие задачи возложены на вас.
  7. Формулируйте проблему так, чтобы сотрудник сам мог придумать план ее решения, а свою точку зрения высказывайте последним.  Если план совпал с вашими ожиданиями, значит вы на одной волне. Ура! Отдайте лавры сотруднику, поблагодарите его/ее за хорошую работу.
  8. Если что-то не устраивает в решении, то старайтесь донести свою точку зрения через формулировку новых проблем.
  9. Если вы проводите совещания, на которых присутствуют сразу несколько ваших подчиненных, обязательно спросите мнение каждого, даже если вы уже все для себя решили.
  10. Время от времени обсуждайте приоритеты задач, так как даже опытные сотрудники могут столкнуться со сложностями и быть не правы (это кстати относится и к вам самим).
  11. Опытные сотрудники любят быть наставниками. Если у вас есть такая возможность, обязательно воспользуйтесь этим.

понедельник, 23 июля 2012 г.

Стратосфера в Новосибирске

Запускаем с коллегами из Parallels проект Стратосфера от Панкратова и Орлова  в Новосибирске. Подробности и регистрация у меня в блоге.

суббота, 3 декабря 2011 г.

Еще один верный шаг на пути к хорошему тестированию

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

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

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

Уже сейчас на совещаниях с разработчиками я задаю вопросы не потому что мне не понятно как они собираются решать задачу, а потому чтобы заставить их самих сомневаться в правильности своего решения. Если разработчик продумал все "За" и "Против", а значит оценил все риски в используемом подходе, то здесь можно быть спокойным. Тестировщику в этом случае достаточно просто перенести все что говорит разработчик на бумагу в виде TTL/TSO и ждать когда фича или ее кусочки будут готовы к тестированию.

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

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


суббота, 23 апреля 2011 г.

Agile практики в детском саду

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

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