суббота, 7 ноября 2009 г.

С днём рождения uml2.ru

1 ноября 2009 года Сообществу системных аналитиков исполнилось 3 года.  

Сообщество системных аналитиков сформировалось на базе сайта uml2.ru в 2006-м году, в настоящий момент активно развивается и насчитывает более 30 профессиональных системных и (или) бизнес-аналитиков, которые хотят передавать свой опыт начинающим, организовывать совместную экспертизу и консалтинг, и конечно, развиваться в данном направлении.

По этому поводу 5 ноября в 3-х городах: Москве, Киеве и Санкт-Петербурге прошли офлайн встречи. Питер был на связи, а вот до Киева не достучались (подвел Wi-Fi).

Кроме того замечательные девушки-аналитики (Ирина Сурова и Ирина Векленко) взяли интервью у “отцов основателей” ресурса – Александра Байкина и Эдуарда Галиаскарова. Прочитать его можно здесь.

P.S.  Последнее время off-line жизнь сообщества значительно возросла. Проводится много регулярных семинаров в городе Москве, члены сообщества участвуют в конференциях (Training Labs, SECR, Req-Labs и т.д.). Кроме того, семинары и конференции проводятся в Санкт-Петербурге, Киеве, Минске. Пожелаю удачного развития и в дальнейшем.

четверг, 24 сентября 2009 г.

О менеджерах среднего звена.

Читая статью об отношении к образованию в области менеджмента

http://scepticist.narod.ru/essays/diploma.htm

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

 

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

В определении есть спорные моменты, но в целом, с моей точки зрения, верно подмечено.

Главное не останавливаться на этом и идти дальше!

пятница, 18 сентября 2009 г.

Сообщество тестировщиков 2.0

В свое время Слава Панкратов сделал замечательный ресурс software-testing.ru. Со временем, в области тестирования, Славе стало тесно и он открыл ресурс it4business.ru.

На Веборубе 2008 замечательный человек и отличный специалист Алексей Баранцев предложил попытаться совместно определить некие фишки/потребности, которые необходимо реализовать на вновь возродившемся software-testing.

На текущий момент Алексей является главным редактором ресурса и его идейным вдохновителем. И несмотря на его заверения про то, что он не верит в профессиональные социальные сети, пару месяцев назад он открыл коллективный проект Панбагон, который жил некоторое время на платформе Blogger, но её возможности оказались ограничены.  Да и не хотелось останавливаться только на одном блоге, хоть и коллективном.

Поэтому родился проект Сообщества тестировщиков 2.0, который работает на движке LiveStreet и живет по этому адресу: http://community.software-testing.ru/.

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

Прошел месяц – полет нормальный.

четверг, 3 сентября 2009 г.

2007 год. SQA – 2. Продолжение истории.

После первой встречи, описанной здесь (условно мы ее назвали SQA - 1) в сентябре 2007 года возник вопрос о проведении нового мероприятия.

Краткая хронология:

07 сентября В преддверии дня тестировщика в Москве собрались человек 10 с форума it4business отметить это дело в неофициальной обстановке. Не смотря на нелетнюю погоду беседа на Калужской площади под открытым небом оказалась увлекательной, пиво - вкусным, компания - интересной.

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

10 сентября. Сергей Мартыненко: Дмитрий Ручко задал вопрос, а не пора ли? Надо сказать, что к этому времени я уже относительно безуспешно вел переговоры с людьми, предлагая взяться за это дело. Ну что ж, мы нашли друг друга и нас стало двое.

13 сентября. На семинаре по Scrum Сергей попросил помощи у комьюнити Agile Russia. Ребята обещали помочь с помещением и докладами. Денис обещал помочь с организацией

среда, 2 сентября 2009 г.

2007 год. SQA Days и другие. Как всё начиналось.

DSCN2852

12 Марта

Влад Орликов на форуме software-testing.ru (ныне расположен на it4business.ru/forum) открывает тему Who is Tester со следующими тезисами:

  1. Профессия тестировщика не престижна.
  2. Многие не имеют представления от том "Who is tester".
  3. Оплата труда тестировщика как правило ниже чем разработчика.
  4. На тестировщиков нигде не обучают (курсы на которых дают только поверхностное представление не в счет). В ВУЗах отсутствует такая специальность/специализация.
  5. Нет общепризнанной сертификации тестировщиков (brainbench не в счет).
  6. и т.д. и т.п. ...

суббота, 22 августа 2009 г.

Цитата из Хайнлайна

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

четверг, 6 августа 2009 г.

Семинар «Управление производством на основании численных данных»



В понедельник 03/08/09 посетил семинар Сергея Мартыненко и Стаса Фомина по мотивам теории ограничений (ТОС) и книгам Голдрата. Семинар проводился на площадке компании Заказные ИнформСистемы.

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

В ходе подготовки семинара Стас с помощью линейного программирования нашел ошибки в рассуждениях Голдрата и это было весело.

Единственное, что не могу удержаться продублировать выводы семинара:

  • Человек не рожден для вычислений.

  • Рассуждения в литературной форме из-за аббераций восприятия легко уводят от оптимума.

  • Поиск оптимума в виде рассуждений трудно верифицировать.

  • Если есть возможность — нужно составить математическую модель. Человеку ее легко верифицировать, а машине — легко решать.


суббота, 1 августа 2009 г.

Бесплатные семинары от Лаборатории качества

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

Вчера 31.07.09 Лаборатория качества провела первый семинар из этой серии, который я и посетил.

На семинар пришло около 30 человек.

Начали с короткого знакомства (Имя, компания, должность)

Сам семинар длился 3 часа (19.00 – 22.00) и состоял из трех частей.

среда, 15 июля 2009 г.

Описание дефекта: Severity и Priority

У одного из тестировщиков возник вопрос по одному из полей в описании дефекта. А именно влияние на функциональность (там было два статуса: влияет/не влияет).

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

По каким причинам он появился у нас в описании дефекта в таком виде уже и не вспомнишь. Поэтому начали разбираться. Как оказалось, это был компромисс между добавлением/не добавлением поля Severity (а компромисс это зачастую наихудшее решение).

В итоге разобрались и документально зафиксировали следующее:

пятница, 20 марта 2009 г.

О чем "забывают" при управлении проектами

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

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

Наиболее часто забываемые активности:

  1. Правильная постановка задач

  2. Управление рисками

  3. Управление изменениями

  4. Post-mortem анализ

  5. Управление знаниями


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

вторник, 17 марта 2009 г.

Минск. Тренинг по тестированию

На этих выходных 14-15 марта провел в Минске тренинг по тестированию. Тренинг проводился для минского офиса компании, которая занимается аутсорсингом тестирования.

С учетом того, что на тренинге были в основном тим-лиды,  за 2 дня успели пройти очень много материала.

В первый день поговорили о теории тестирования:

  • разнице между QA, QC, Testing;

  • видах тестирования;

  • техниках тестирования (с разбором практических примеров);

  • работе с требованиями;

  • артефактах тестирования;

  • аксиомах и мифах тестирования, а также как избежать основных ошибок тестировщиков;

  • работе с дефектами;

  • активностях и этапах тестирования.


На второй день:

  • поговорили об управлении тестированием;

  • разобрали пример о важности планирования;

  • рассказал о том, что такое риски и как с ними можно работать на основании моего опыта;

  • разобрали кейсы по работе с персоналом;


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

Весь тренинг был заснят на видео. Так что теперь надо отсмотреть 14 гигов видео, переосмыслить подачу и объем некоторых тем (сделать их более живыми и интересными).

четверг, 22 января 2009 г.

Практика перераспределения задач

Есть мнение, что вы собираетесь


найти формальное решение там,


где его быть не может


Алексей Никулин



Дано:

  1. Несколько параллельных проектов по тестированию схожей тематики (или один большой проект из некоторого количества достаточно объемных модулей (по функционалу)).

  2. На этих проектах присутствует определенный объем ручного тестирования (функциональное и/или регрессионное).

  3. На каждом проекте (модуле) свой специалист по тестированию, входящий в проектную группу.

  4. Проекты достаточно продолжительные по времени.


После некоторого времени работы эти специалисты по тестированию становятся так называемыми гуру в данном проекте/модуле.

Проблемы:

  1. Страдает мотивация, человек начинает искать другую работу (да, да, очень мало людей просят перевести куда-нибудь, многие просто тихонько ищут другую работу). Думаю, не нужно объяснять стоимость ухода такого специалиста.

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


В итоге:  или теряем специалиста по конкретному проекту/модулю, или теряем в качестве тестирования.