Чем меньше пишу, тем больше происходит.
За последние дни лишился зуба и бойца.
Первый выкинули, второй ушел в науку, создавать микропроцессоры.
Поэтому, кстати, ищу человека в команду:
http://www.naumen.ru/career/vacancies/nzhener_po_104/104
Да и вообще, много всякоразного.
Переводы со следующей недели возобновлю.
И да, весной еду в питер на sqa days.
Екб, кто еще?
среда, 30 января 2013 г.
четверг, 24 января 2013 г.
Lesson 236
А кто-нибудь играет в Ingress?
Слово Канеру
Используйте удобные случаи для найма.
Ищите сотрудников в нетрадиционных для этого местах, особенно при жестком рынке труда. Например юристы и бухгалтеры сильны в аналитике; удивительно, но многие из них будут заинтересованы в том, чтоб в течении года изучать, как создается ПО. Другим примером будет старший программист или менеджер проекта, которая стала матерью-одиночкой и ей необходимо работать помедленней и не может найти себе в этом поддержку. Предложите ей 35-часовую позицию с гибким графиком и на 1-2 года вы получите сотрудника с исключительными навыками. Другим примером является отставной руководитель, желающий найти работу с меньшим уровнем стресса.
Слово Канеру
Используйте удобные случаи для найма.
Ищите сотрудников в нетрадиционных для этого местах, особенно при жестком рынке труда. Например юристы и бухгалтеры сильны в аналитике; удивительно, но многие из них будут заинтересованы в том, чтоб в течении года изучать, как создается ПО. Другим примером будет старший программист или менеджер проекта, которая стала матерью-одиночкой и ей необходимо работать помедленней и не может найти себе в этом поддержку. Предложите ей 35-часовую позицию с гибким графиком и на 1-2 года вы получите сотрудника с исключительными навыками. Другим примером является отставной руководитель, желающий найти работу с меньшим уровнем стресса.
вторник, 22 января 2013 г.
Lesson 235
Слово Канеру
Набирайте в команду тестирования сотрудников с разным багажом
Не пытайтесь собрать группу, каждый в которой будет иметь степень по компьютерным наукам, опыт от двух лет в тестировании, опыт работы с указанным инструментом автоматизации и так далее. Создайте группу людей, в которой каждый имеет свои сильные качества и отличается от других. Мы нанимали людей, которые никогда не тестировали, и нанимали тех у кого есть опыт. Будет хорошо, если вы соберете все навыки, которые нужны группе.
Мы не говорим вам, что не нужно нанимать программистов. Безусловно, берите и их. Они вам понадобятся для многих задач. Тем не менее, вам придется обучать их некоторым не-программистским областям знаний. Другие ваши сотрудники могут быть не программистами, имеющие массу знаний, которых нет у программистов. Создайте команду, и сильные стороны одних членов которой будут компенсировать слабости других.
Например (эти примеры основаны на нашем успешном опыте) представьте, что вы наняли человека, который может применить опыт своей предыдущей работы в качестве роли, с которой он будет тестировать спецификацию или продукт. Это может быть адвокат, директор по маркетингу, продавец, техник по ремонту аппаратуры, библиотекарь, программист, менеджер не-IT проекта, сотрудник техподдержки вашего продукта, переводчик (особенно полезно, если ваша компания выпускает программное обеспечение на многих языках), секретарь (Подумайте об информации, которую вы собираете, храните и распространяете, а также о организационных вопросах, которые ложится на плечи вам и вашей команде), системный администратор, который знает сети и пользователей ПО, которое вы тестируете. Любой (или многие) из этих людей может оказаться пользователем вашего продукта.
Но есть ограничение для этого совета. Для некоторых продуктов тестировщик должен уметь программировать. Представьте себе тестировщика компилятора. Для создания интересных тестов вы должны быть способны писать код. В некоторых компаниях непрограммирующие тестировщики считаются сотрудниками второго сорта и не имеет значения, насколько они хороши. В таких случаях нанимайте программиста. Вашей задачей будет нанять программистов, имеющих различны бекграунд. По нашему опыту, это сложно, но достижимо, если вы работаете в хорошей компании и не во время очередного бума занятости.
Еще один вопрос достоин упоминания. Иногда публикуются статьи о расизме, сексизме и дискриминации по возрастному признаку в IT индустрии и мы видели подобное. Нанимают, обучают и стимулируют группы, в которых преобладают белые мужчины, хотя они, напротив, скорее всего будут менее эффективны в тестировании. Чем шире спектр опыта и культуры представлен вашими сотрудниками, тем больше способов они найдут для анализа вашего ПО и больше проблем обнаружат. Разнообразие является одним из важнейших аспектов в тестировании и это не то, чего стоит избегать.
Хотя мы и не всегда имеем возможность следовать этим советам, но все же согласны с одним из наших обозревателей Rex Black: «Когда вы тестируете, используя специальные навыки, например автоматизированное тестирование и особенно при тестировании производительности, я считаю разумным иметь в команде как минимум двух человек, обладающих этими навыками».
Набирайте в команду тестирования сотрудников с разным багажом
Не пытайтесь собрать группу, каждый в которой будет иметь степень по компьютерным наукам, опыт от двух лет в тестировании, опыт работы с указанным инструментом автоматизации и так далее. Создайте группу людей, в которой каждый имеет свои сильные качества и отличается от других. Мы нанимали людей, которые никогда не тестировали, и нанимали тех у кого есть опыт. Будет хорошо, если вы соберете все навыки, которые нужны группе.
Мы не говорим вам, что не нужно нанимать программистов. Безусловно, берите и их. Они вам понадобятся для многих задач. Тем не менее, вам придется обучать их некоторым не-программистским областям знаний. Другие ваши сотрудники могут быть не программистами, имеющие массу знаний, которых нет у программистов. Создайте команду, и сильные стороны одних членов которой будут компенсировать слабости других.
Например (эти примеры основаны на нашем успешном опыте) представьте, что вы наняли человека, который может применить опыт своей предыдущей работы в качестве роли, с которой он будет тестировать спецификацию или продукт. Это может быть адвокат, директор по маркетингу, продавец, техник по ремонту аппаратуры, библиотекарь, программист, менеджер не-IT проекта, сотрудник техподдержки вашего продукта, переводчик (особенно полезно, если ваша компания выпускает программное обеспечение на многих языках), секретарь (Подумайте об информации, которую вы собираете, храните и распространяете, а также о организационных вопросах, которые ложится на плечи вам и вашей команде), системный администратор, который знает сети и пользователей ПО, которое вы тестируете. Любой (или многие) из этих людей может оказаться пользователем вашего продукта.
Но есть ограничение для этого совета. Для некоторых продуктов тестировщик должен уметь программировать. Представьте себе тестировщика компилятора. Для создания интересных тестов вы должны быть способны писать код. В некоторых компаниях непрограммирующие тестировщики считаются сотрудниками второго сорта и не имеет значения, насколько они хороши. В таких случаях нанимайте программиста. Вашей задачей будет нанять программистов, имеющих различны бекграунд. По нашему опыту, это сложно, но достижимо, если вы работаете в хорошей компании и не во время очередного бума занятости.
Еще один вопрос достоин упоминания. Иногда публикуются статьи о расизме, сексизме и дискриминации по возрастному признаку в IT индустрии и мы видели подобное. Нанимают, обучают и стимулируют группы, в которых преобладают белые мужчины, хотя они, напротив, скорее всего будут менее эффективны в тестировании. Чем шире спектр опыта и культуры представлен вашими сотрудниками, тем больше способов они найдут для анализа вашего ПО и больше проблем обнаружат. Разнообразие является одним из важнейших аспектов в тестировании и это не то, чего стоит избегать.
Хотя мы и не всегда имеем возможность следовать этим советам, но все же согласны с одним из наших обозревателей Rex Black: «Когда вы тестируете, используя специальные навыки, например автоматизированное тестирование и особенно при тестировании производительности, я считаю разумным иметь в команде как минимум двух человек, обладающих этими навыками».
понедельник, 21 января 2013 г.
Таки да.
Намедни провели первую городскую сессию тестирования.
Как это было: В прошлом году у нас проходил круглый стол для тестеров, на нем я заикнулся о том, что неплохо бы по примеру питерских коллег такую движуху, когда тестеры собираются, общаются, делятся опытом на живом примере какого-нибудь местного продукта.
Идею тут же поддержали Юлия Герасимович и Марина Гончарова. Объектом тестирования мы попросили стать e96.ru и он в лице руководителя разработки Андрея нас в этом поддержал. Тут же заявлю, что без деятельного участия этих людей ничего из того, что я дальше буду описывать, не произошло бы.
К январю у нас все срослось и вот 19 числа в помещении, любезно предоставленном контуром, мы приступили.
Участники — 15 человек из шести компаний екатеринбурга и не только, от ручных тестировщиков до руководителей службы тестирования.
Продукт — интернет-магазин e96, для контроля процесса от него пришел не только руководитель разработки Андрей (я же правильно назвал должность?), продвигавший идею у себя в компании, но еще и ПМ с программистом. Как выяснилось потом, не зря.
Разбились на 7 команд плюс команда оргов (я и Александр Ахметов из Контура).
Я толкнул речь о том, что наша задача — получить море фана, а попутно раздербанить продукт, который нам дали.
По плану у нас были:
- Сессия исследовательского тестирования, 60 минут.
- Кофе-брейк, затем круглый стол, на котором хотели обсудить приемы и техники, которые каждый тестер использует у себя.
-Вторая сессия с использованием проектирования тестов, 90 минут.
- Обед.
- Раздача слонов.
О слонах. e96 пообещал и сдержал слово — предоставить памятные ништяки всем, а победителям — призы.
Началась первая сессия, я — в команде оргов.
Для тестирования была выбрана фича — корзина, причем на нашем тестовом стенде находилось то, чего еще не было на боевом.
На первый взгляд никаких проблем не видно, и я начинаю бояться, что мы всей толпой найдем лишь пару Trivial — и мне будет немного стыдно перед e96.
Но Александр, в паре с которым я работал, набросился на эту корзину прям таки яростно. За первые полчаса мы наколупали четыре баги, не очень серьезных, но все-таки.
А втянувшись обнаружили пару действительно серьезных уязвимостей.
И совершенно внезапно оказалось, что час прошел, нам пора на перерыв, и вообще приехал обед (который, кстати, тоже любезно был оплачен тестируемым продуктом).
И вот тут настал момент моей профессиональной и организаторской гордости: мы минут десять пытались оторвать участников от поиска и заведения багов в сторону пиццы, чая, морса и прочего кофе. Народ сидел и продолжал яростно искать и заводить баги, руки тянулись к ноутбукам.
После обеда - круглый стол с рассказами, байками и советами из жизни тестировщика. Даже немного поспорили.
Было что сказать не только опытным тестерам, но и тем, кто работает меньше года.
Часть второй сессии тестирования я хотел провести без приложения — только на бумаге. Чтоб включился мозг и воображение. И вообще компьютер мешает думать.
Но звезды решили иначе и команды пошли вновь давить по клавишам.
Половина моей команды ушла по делам, а я пошел брать интервью у e96.
Тут я испытал второй приступ гордости — за коллег: все три представителя в поте лица только и успевали что проверять заведенные баги и расставлять им веса.
Вторая сессия закончилась так же быстро как и первая, и, пока e96 выяснял какая команда победила, коллеги давали мне мудрые советы по организации процесса.
Некоторые из них(на будущее):
- Отобрать у команд вторые ноутбуки, пусть работают за одним, иначе получается какая-то сольная работа.
- Нужны минимум два организатора и минимум два представителя продукта, способных оценивать баги и отвечать на вопросы.
- В следующий раз предложить участникам самим выбрать продукт, устроить голосование.
- Определиться с запоминающимся названием мероприятия.
- Использовать багтрекер с формой ввода багов, а не самопальные гуглдоки.
- Увеличить время сессии тестирования до 90-120 минут.
- Устроить мастер класс часика на полтора, а затем — практикум по нему.
- Придумать номенации. Самый первый баг. Первый критичный баг. Баг, найденный с карандаша, не заходя в продукт..
- В качестве объекта взять банкомат, платежный терминал.
Как-то так.
К этому моменту баги были подсчитаны и оценены.
Результат потрясающий. За 2,5 часа тестирования команды:
Первая: заявила 14 багов
Вторая: заявила 13 багов
Третья: заявила 18 багов
Четвертая: заявила 16 багов
Пятая: заявила 28 багов
Шестая: заявила 23 бага
Седьмая: заявила 35 багов
Восьмая команда оргов, вне зачета: заявили 9 багов.
От половины до двух третей этих багов признаны реальными, треть — серьезными и достойными оперативного исправления (Major).
И да, команда организаторов хоть и нашла меньше всех багов, и набрала меньше всех очков, но нашла вдвое больше Critical, чем остальные (вместе взятые). Мы еще могём.
После оглашения результатов победителям (команда семь, ребята просто напалмом жгли) были вручены призы от e96. Что-то вкусное и алкоголь. Или вкусный алкоголь. Победителям понравилось.
Что я хочу сказать по результатам?
Я боялся что будет скучно участникам — их было не оторвать от продукта, они рвались в бой и просили еще.
Я боялся, что мы найдем мало багов и продуктам будем не нужны — но мы нашли много больше, чем ждал e96 и чем я вообще мог предположить. Ребята фичу просто в клочья порвали.
Для e96 профит несомненный — до выхода в production были обнаружены несколько серьезных уязвимостей, масса дефектов юзабилити и не очень.
Если предлагая идею в первый раз я говорил, что мы наверное найдем баги и надеюсь это будет полезно продукту, то сейчас смело могу говорить, что к вам в гости зайдут одни из лучших в профессии и камня на камне не оставят.
Еще раз — большое спасибо Юле из it-people, Марине из СКБ-Контура и Андрею из e96.
Следующей тест-сессии быть.
Следующей тест-сессии быть гораздо интересней чем эта.
disclaimer Ни пост, ни движуха не являются рекламой и не оплачены никем. Все было абсолютно бесплатно и на добровольной основе.
Как это было: В прошлом году у нас проходил круглый стол для тестеров, на нем я заикнулся о том, что неплохо бы по примеру питерских коллег такую движуху, когда тестеры собираются, общаются, делятся опытом на живом примере какого-нибудь местного продукта.
Идею тут же поддержали Юлия Герасимович и Марина Гончарова. Объектом тестирования мы попросили стать e96.ru и он в лице руководителя разработки Андрея нас в этом поддержал. Тут же заявлю, что без деятельного участия этих людей ничего из того, что я дальше буду описывать, не произошло бы.
К январю у нас все срослось и вот 19 числа в помещении, любезно предоставленном контуром, мы приступили.
Участники — 15 человек из шести компаний екатеринбурга и не только, от ручных тестировщиков до руководителей службы тестирования.
Продукт — интернет-магазин e96, для контроля процесса от него пришел не только руководитель разработки Андрей (я же правильно назвал должность?), продвигавший идею у себя в компании, но еще и ПМ с программистом. Как выяснилось потом, не зря.
Разбились на 7 команд плюс команда оргов (я и Александр Ахметов из Контура).
Я толкнул речь о том, что наша задача — получить море фана, а попутно раздербанить продукт, который нам дали.
По плану у нас были:
- Сессия исследовательского тестирования, 60 минут.
- Кофе-брейк, затем круглый стол, на котором хотели обсудить приемы и техники, которые каждый тестер использует у себя.
-Вторая сессия с использованием проектирования тестов, 90 минут.
- Обед.
- Раздача слонов.
О слонах. e96 пообещал и сдержал слово — предоставить памятные ништяки всем, а победителям — призы.
Началась первая сессия, я — в команде оргов.
Для тестирования была выбрана фича — корзина, причем на нашем тестовом стенде находилось то, чего еще не было на боевом.
На первый взгляд никаких проблем не видно, и я начинаю бояться, что мы всей толпой найдем лишь пару Trivial — и мне будет немного стыдно перед e96.
Но Александр, в паре с которым я работал, набросился на эту корзину прям таки яростно. За первые полчаса мы наколупали четыре баги, не очень серьезных, но все-таки.
А втянувшись обнаружили пару действительно серьезных уязвимостей.
И совершенно внезапно оказалось, что час прошел, нам пора на перерыв, и вообще приехал обед (который, кстати, тоже любезно был оплачен тестируемым продуктом).
И вот тут настал момент моей профессиональной и организаторской гордости: мы минут десять пытались оторвать участников от поиска и заведения багов в сторону пиццы, чая, морса и прочего кофе. Народ сидел и продолжал яростно искать и заводить баги, руки тянулись к ноутбукам.
После обеда - круглый стол с рассказами, байками и советами из жизни тестировщика. Даже немного поспорили.
Было что сказать не только опытным тестерам, но и тем, кто работает меньше года.
Часть второй сессии тестирования я хотел провести без приложения — только на бумаге. Чтоб включился мозг и воображение. И вообще компьютер мешает думать.
Но звезды решили иначе и команды пошли вновь давить по клавишам.
Половина моей команды ушла по делам, а я пошел брать интервью у e96.
Тут я испытал второй приступ гордости — за коллег: все три представителя в поте лица только и успевали что проверять заведенные баги и расставлять им веса.
Вторая сессия закончилась так же быстро как и первая, и, пока e96 выяснял какая команда победила, коллеги давали мне мудрые советы по организации процесса.
Некоторые из них(на будущее):
- Отобрать у команд вторые ноутбуки, пусть работают за одним, иначе получается какая-то сольная работа.
- Нужны минимум два организатора и минимум два представителя продукта, способных оценивать баги и отвечать на вопросы.
- В следующий раз предложить участникам самим выбрать продукт, устроить голосование.
- Определиться с запоминающимся названием мероприятия.
- Использовать багтрекер с формой ввода багов, а не самопальные гуглдоки.
- Увеличить время сессии тестирования до 90-120 минут.
- Устроить мастер класс часика на полтора, а затем — практикум по нему.
- Придумать номенации. Самый первый баг. Первый критичный баг. Баг, найденный с карандаша, не заходя в продукт..
- В качестве объекта взять банкомат, платежный терминал.
Как-то так.
К этому моменту баги были подсчитаны и оценены.
Результат потрясающий. За 2,5 часа тестирования команды:
Первая: заявила 14 багов
Вторая: заявила 13 багов
Третья: заявила 18 багов
Четвертая: заявила 16 багов
Пятая: заявила 28 багов
Шестая: заявила 23 бага
Седьмая: заявила 35 багов
Восьмая команда оргов, вне зачета: заявили 9 багов.
От половины до двух третей этих багов признаны реальными, треть — серьезными и достойными оперативного исправления (Major).
И да, команда организаторов хоть и нашла меньше всех багов, и набрала меньше всех очков, но нашла вдвое больше Critical, чем остальные (вместе взятые). Мы еще могём.
После оглашения результатов победителям (команда семь, ребята просто напалмом жгли) были вручены призы от e96. Что-то вкусное и алкоголь. Или вкусный алкоголь. Победителям понравилось.
Что я хочу сказать по результатам?
Я боялся что будет скучно участникам — их было не оторвать от продукта, они рвались в бой и просили еще.
Я боялся, что мы найдем мало багов и продуктам будем не нужны — но мы нашли много больше, чем ждал e96 и чем я вообще мог предположить. Ребята фичу просто в клочья порвали.
Для e96 профит несомненный — до выхода в production были обнаружены несколько серьезных уязвимостей, масса дефектов юзабилити и не очень.
Если предлагая идею в первый раз я говорил, что мы наверное найдем баги и надеюсь это будет полезно продукту, то сейчас смело могу говорить, что к вам в гости зайдут одни из лучших в профессии и камня на камне не оставят.
Еще раз — большое спасибо Юле из it-people, Марине из СКБ-Контура и Андрею из e96.
Следующей тест-сессии быть.
Следующей тест-сессии быть гораздо интересней чем эта.
disclaimer Ни пост, ни движуха не являются рекламой и не оплачены никем. Все было абсолютно бесплатно и на добровольной основе.
пятница, 18 января 2013 г.
Епт =(
РазИгнорировать или разЫгнорировать?
Эта ссылка права?
http://www.gramota.ru/class/coach/tbgramota/45_66
Эта ссылка права?
http://www.gramota.ru/class/coach/tbgramota/45_66
четверг, 17 января 2013 г.
Lesson 234
Где-то слышал, что хороший специалист может самую сложную свою работу объяснить понятными словами.
Склонен согласиться с этой мыслью.
Я сегодня искал причину падения тестов, оказалось, что у тестовой базы проблемы с русским. Collation задать надо было в скрипте развертывания.
Я вчера считал, сколько нам нужно будет железок для прогона тестов через полгода, если один тестировщик пишет n тестов в месяц, мы оптимизируемвремя прохождения тестов на x% в месяц, удаляем y тестов в месяц, параллелим в z потоков, по w потоков на железке, тест в среднем идет k секунд, накладные на дополнительное распараллеливание j секунд, это все умножить на h веток из расчета по одной ветке на f программистов, которых у нас d человек сейчас, а через полгода будет +s штук. И учесть, что сейчас q тестировщиков пишут тесты, а через полгода им будут помогать r человек писать кейсы, что увеличит скорость написания тестов на t%. Ну и накладные u% времени на поддержку, которые зависят от количества тестов и их качества. Все ж понятно, нам надо в два-три раза больше железок, чем сейчас.
Но иногда я слышу такой ответ: "Думаю, руковожу, слежу и контролирую".
Буллшит! Если не полное симбурде.
Так же как специалист должен уметь без единого термина объяснить суть своей работы, так и менеджер - обязан небулшитовыми словами рассказать, чем он занимался день, неделю, месяц.
Переписывался с клиентами на тему их потаенных желаний, оформлял бумажки с отпусками, проводил собеседование, создавал задачки в jira, отпинывался от стремных задач, делал ревью вашего кода, считал статистику, медитировал на прогресс сборок в jenkins, сидел на пяти совещаниях, три часа уговаривал Петю не увольняться - это я понимаю. По разному отношусь, но понимаю.
«Руководил, думал, следил за выполнением, контролировал, управлял» - буллшит.
Но у вас наверняка есть свои версии на все эти счета?(c)
Слово Канеру
Планируйте в терминах задачи, которую вы делаете и навыков, необходимых для ее выполнения.
Не нанимайте на основе простых классификаций. Настоящая квалификация тестировщика выходит далеко за рамки «уровня » или «лет опыта». Нанимайте людей, имеющих или не имеющих традиционную квалификацию, но доказавших вам, что они могут выполнять свою работу.
Склонен согласиться с этой мыслью.
Я сегодня искал причину падения тестов, оказалось, что у тестовой базы проблемы с русским. Collation задать надо было в скрипте развертывания.
Я вчера считал, сколько нам нужно будет железок для прогона тестов через полгода, если один тестировщик пишет n тестов в месяц, мы оптимизируемвремя прохождения тестов на x% в месяц, удаляем y тестов в месяц, параллелим в z потоков, по w потоков на железке, тест в среднем идет k секунд, накладные на дополнительное распараллеливание j секунд, это все умножить на h веток из расчета по одной ветке на f программистов, которых у нас d человек сейчас, а через полгода будет +s штук. И учесть, что сейчас q тестировщиков пишут тесты, а через полгода им будут помогать r человек писать кейсы, что увеличит скорость написания тестов на t%. Ну и накладные u% времени на поддержку, которые зависят от количества тестов и их качества. Все ж понятно, нам надо в два-три раза больше железок, чем сейчас.
Но иногда я слышу такой ответ: "Думаю, руковожу, слежу и контролирую".
Буллшит! Если не полное симбурде.
Так же как специалист должен уметь без единого термина объяснить суть своей работы, так и менеджер - обязан небулшитовыми словами рассказать, чем он занимался день, неделю, месяц.
Переписывался с клиентами на тему их потаенных желаний, оформлял бумажки с отпусками, проводил собеседование, создавал задачки в jira, отпинывался от стремных задач, делал ревью вашего кода, считал статистику, медитировал на прогресс сборок в jenkins, сидел на пяти совещаниях, три часа уговаривал Петю не увольняться - это я понимаю. По разному отношусь, но понимаю.
«Руководил, думал, следил за выполнением, контролировал, управлял» - буллшит.
Но у вас наверняка есть свои версии на все эти счета?(c)
Слово Канеру
Планируйте в терминах задачи, которую вы делаете и навыков, необходимых для ее выполнения.
Не нанимайте на основе простых классификаций. Настоящая квалификация тестировщика выходит далеко за рамки «уровня » или «лет опыта». Нанимайте людей, имеющих или не имеющих традиционную квалификацию, но доказавших вам, что они могут выполнять свою работу.
Крылья
http://bodhipbaha.livejournal.com/672334.html Парень еще будет летать, нельзя у таких забирать крылья.
UPD Фейк :(
UPD Фейк :(
вторник, 15 января 2013 г.
Lesson 233
Отец купил себе игрушку:
Без баллона, накачка.
Аж три вида пуль:
Занятная штука. Кстати, отстрел серых ворон не запрещен, но приветствуется.
Слово Канеру
Старайтесь не брать людей, которых не приняли в другие группы
Есть люди, которые не могут работать в одних группах, но отлично справляются с работой в тестировании. Но таких людей немного. Чем больше неудачников вы примете в группу, тем вероятней, что ваша группа получит репутацию неудачников. Активно противодействуйте усилиям руководства спихнуть к вам в группу сотрудника, который не внушает вам доверия. Даже если этот «подарок» является для вас бесплатным (он не отнимает время текущих сотрудников и не занимает вакансию), он вам помешает, когда вы захотите нанять еще людей в следующий раз (вы только что получили человека, зачем вам кто-то еще?). Люди вокруг вас ждут, что потенциал вашей группы возрастет пропорционально увеличению размера персонала. Новый тестировщик требует задач для себя. Если вы получили новые задачи, но новый тестировщик не выполняет их, остальным в группе становится сложно работать.
 |
| Альбом: home |
Без баллона, накачка.
Аж три вида пуль:
 |
| Альбом: home |
Занятная штука. Кстати, отстрел серых ворон не запрещен, но приветствуется.
Слово Канеру
Старайтесь не брать людей, которых не приняли в другие группы
Есть люди, которые не могут работать в одних группах, но отлично справляются с работой в тестировании. Но таких людей немного. Чем больше неудачников вы примете в группу, тем вероятней, что ваша группа получит репутацию неудачников. Активно противодействуйте усилиям руководства спихнуть к вам в группу сотрудника, который не внушает вам доверия. Даже если этот «подарок» является для вас бесплатным (он не отнимает время текущих сотрудников и не занимает вакансию), он вам помешает, когда вы захотите нанять еще людей в следующий раз (вы только что получили человека, зачем вам кто-то еще?). Люди вокруг вас ждут, что потенциал вашей группы возрастет пропорционально увеличению размера персонала. Новый тестировщик требует задач для себя. Если вы получили новые задачи, но новый тестировщик не выполняет их, остальным в группе становится сложно работать.
Lesson 232
Кстати, вот так непафосно выглядит мое домашнее новогонднее настроение.
Слово Канеру
Наймите подрядчиков, чтоб получить передышку во время рекрутинга.
Используйте временную помощь, чтоб не торопиться во время поиска нужного человека. Даже в компаниях, строго ограничивающих использование подрядчиков, этот способ часто работает.
 |
| Альбом: home |
Слово Канеру
Наймите подрядчиков, чтоб получить передышку во время рекрутинга.
Используйте временную помощь, чтоб не торопиться во время поиска нужного человека. Даже в компаниях, строго ограничивающих использование подрядчиков, этот способ часто работает.
понедельник, 14 января 2013 г.
Lesson 231
 |
| Альбом: randompics4lj |
В связи со слухами о ЖЖкапце хочу продублировать свой бложик на альтернативной платформе. А может и переехать.
Варианты:
wordpress
blogger
tumblr
Требования:
1. Импорт из жж. Здесь в выдаче гугла по 700к ссылок для wordpress и blogger, 300к для tumblr. Вывод очевиден.
2. Поддержка опенайди и прочей авторизации. Везде есть.
3. Поддержка rss. Везде есть.
4. Простота ведения. Хм, я думаю, что осилю.
5. Клиент под андроид. Нашел все три, какой из них удобней?
6. Возможность формировать ленты из других блогов, списки интересных блогов итпх.
7. Очень не хочу терять френдов, я вас всех очень ценю и читаю. Несколько лет собирал.
Наверняка вам есть что выразить по этому поводу. От жж-юзеров жду как минимум не-уходи-постой.
Слово Канеру
Ваши решения о найме — самые важные
Найм неподходящего для работы человека — одна из худших ошибок, которые вы сможете сделать в качестве менеджера. Вы застрянете с этой ошибкой на длительное время.
Сделайте все возможное, чтоб нанять хороших людей.
суббота, 12 января 2013 г.
Lesson 230
Вот туточки okiseleva пишет как у нее происходило сессионное тестирование.
Почитайте, интересно.
И у нас было такое кино, но на свой коленкор.
Были у нас сессии массового тестирования, раз и два - это когда несколько человек берут и колбасят одну задачку, но каждый за своим компом, а затем обсуждают что получилось. Проходило это с целью обучения стажеров, меряния багами, обсуждения кейсов и взрыва мозга программиста, которому выкладывали здоровенный список баг. Ибо искали яростно.
Неоднократно занимались мы с наташами тестированием парным, когда они мануально тестят хитрую фичу, я смотрю, конспектирую кейсы для автоматики и даю ценные советы.
Получилось тоже неплохо.
А под новый год мы затеяли совсем-совсем массовое тестирование. Мне лень описывать, поэтому просто процитирую письмо ПМа по результатам.
29 декабря в последний рабочий день года при корпоративе 28го как нельзя хочется встать под знамя с надписью "Что угодно, только не работать!". Но мы пошли другим путем! Мы решили провести мероприятие под кодовым названием "Массовый тест".
Правила игры были такими: участники случайным образом разбиваются на пары, в которой один - представитель команды тестировщиков а второй - представитель второй команды (разработчики + аналитики). Пара берет понравившуюся ей задачу с доски, садится за один компьютер и ее тестирует. Потом берет следующую. И еще. И еще. Пока совсем ничего не останется.
Чего хотелось получить от этой акции:
- приведения в порядок досок (уборка перед НГ, все дела), в т.ч. тестирования задач, которые ждут этого по нескольку недель;
- взаимного обучения участников;
- их синергии: разработчик может предположить источник бага и указать эту информацию при его регистрации; аналитик - немедленно внести в постановку необходимые правки и т.д. и т.п.;
- ну и много-много радости, а как же иначе.
В результате с 11 до 16-17 часов (пары заканчивали в разное время) восемью парами участников было протестировано 35 задач. (а это сильно дофига, прим w_bf)Ура-ура! Не проверили только то, что мешали проверить непреодолимые причины типа воспроизведения дефекта исключительно на рабочем приложении клиента.
Вот что участники говорили об акции (разобрано мной с листочка после опроса участников. Возможна гнусная ложь и отсебятина):
- Это эффективно, потому что оба работают.
- Помогает систематизировать знания.
- Понравилось наблюдать за процессом тестирования и придумывать для него кейсы.
- Плохо, что Коли не было.
(колоритная личность, прим w_bf)
- Тестировать вдвоем интереснее, продуктивнее и просто весело. А тестировать с разработчиком - вдвойне.
- Мы очень много всего сделали.
- Было полезно, узнали много нового.
- Получила ценные идеи, как можно упростить работу.
- Хорошо, что разобрали задачи, которые висели по 2 месяца.
- Очень полезно для знакомства с интерфейсом.
- Было бы здорово провести в формате "2 тестировщика в команде: ведущий и ведомый".
- Разработчики придумывают интересные кейсы.
- Интересный обмен опытом, причем, в обе стороны.
- Понравилось просто тестирование без всякой бюрократии.
- Здорово, что аналитики и разработчики уделяют время таким задачам.
- Хорошо бы проводить такое мероприятие 2 раза в год как PR.
Ну и общее мнение: ПОНРАВИЛОСЬ.
Я, как организатор сего действа, в заключение хочу сказать большое спасибо всем его участникам, а также начальству, разрешившим весь этот беспредел в рабочее время.
Со своей стороны хочу сказать, что я ходила с блокнотом, спрашивала всех "Как?", люди говорили "Понравилось", а я им верила. Потому что лица у всех в процессе были действительно очень увлеченные и заинтересованные. А это главное, пожалуй.
С Новым 2013 годом! В нем мы обязательно придумаем что-нибудь еще.
(Цитата неточная, убрал фамилии и сугубо нашу специфику)
Фот фотка доски с задачками в процессе:
А вот после:
Слово Канеру
Создайте возможности для обучения
Организуйте еженедельные или ежемесячные встречи. Цель в чтении статей или глав книг каждую неделю и их обсуждение (сотрудники обсуждают, вы присутствуете, но много не говорите). Сделайте участие в таких встречах добровольным, не принуждайте присутствовать. Но найдите способ наградить людей, которые вносят свой вклад в обсуждения и регулярно посещают встречи (предоставляйте книги тем, кто показал, что будет их читать).
Организуйте собрания-обучения. Раз в неделю или два раза в месяц. На них — расскажите сами о чем-нибудь новом, иногда можно приносить гостя-спикера (тест-менеджера из другой компании). Вы могли бы найти кого-нибудь, кто мог бы сделать это бесплатно, если вы сами проведете лекцию для его сотрудников. Иногда кто-нибудь из ваших сотрудников может выступить с докладом о технике тестирования или о проблемах в тестировании определенного устройства или приложения. Иногда можно делать упражнения для тренировки навыков.
Если ваша компания возмещает деньги на обучение, найдите курсы, предлагаемые местными университетами или онлайн-курсы, желательно связанные с разработкой ПО. Кроме того выясните, какие конференции по тестированию применимы к проектам компании. Поговорите с сотрудниками лично, помогите им спланировать непрерывное обучение. Этот разговор — отличная возможность обсудить долгосрочные цели сотрудника (примите эти цели во внимание, когда будете распределять следующую волну задач). Don't tell someone what courses to take but do point out courses you think are well-taught and relevant to the company's current projects or to the career interests of your staff member.
Главное правило — отправлять сотрудников на курсы (особенно профессиональные семинары) и конференции в парах и тройках. Они будут говорить друг с другом о том, чему научились. Пусть они сделают презентацию для вас и группы тестирования о том, чему они научились, когда вернутся.
Почитайте, интересно.
И у нас было такое кино, но на свой коленкор.
Были у нас сессии массового тестирования, раз и два - это когда несколько человек берут и колбасят одну задачку, но каждый за своим компом, а затем обсуждают что получилось. Проходило это с целью обучения стажеров, меряния багами, обсуждения кейсов и взрыва мозга программиста, которому выкладывали здоровенный список баг. Ибо искали яростно.
Неоднократно занимались мы с наташами тестированием парным, когда они мануально тестят хитрую фичу, я смотрю, конспектирую кейсы для автоматики и даю ценные советы.
Получилось тоже неплохо.
А под новый год мы затеяли совсем-совсем массовое тестирование. Мне лень описывать, поэтому просто процитирую письмо ПМа по результатам.
29 декабря в последний рабочий день года при корпоративе 28го как нельзя хочется встать под знамя с надписью "Что угодно, только не работать!". Но мы пошли другим путем! Мы решили провести мероприятие под кодовым названием "Массовый тест".
Правила игры были такими: участники случайным образом разбиваются на пары, в которой один - представитель команды тестировщиков а второй - представитель второй команды (разработчики + аналитики). Пара берет понравившуюся ей задачу с доски, садится за один компьютер и ее тестирует. Потом берет следующую. И еще. И еще. Пока совсем ничего не останется.
Чего хотелось получить от этой акции:
- приведения в порядок досок (уборка перед НГ, все дела), в т.ч. тестирования задач, которые ждут этого по нескольку недель;
- взаимного обучения участников;
- их синергии: разработчик может предположить источник бага и указать эту информацию при его регистрации; аналитик - немедленно внести в постановку необходимые правки и т.д. и т.п.;
- ну и много-много радости, а как же иначе.
В результате с 11 до 16-17 часов (пары заканчивали в разное время) восемью парами участников было протестировано 35 задач. (а это сильно дофига, прим w_bf)Ура-ура! Не проверили только то, что мешали проверить непреодолимые причины типа воспроизведения дефекта исключительно на рабочем приложении клиента.
Вот что участники говорили об акции (разобрано мной с листочка после опроса участников. Возможна гнусная ложь и отсебятина):
- Это эффективно, потому что оба работают.
- Помогает систематизировать знания.
- Понравилось наблюдать за процессом тестирования и придумывать для него кейсы.
- Плохо, что Коли не было.
(колоритная личность, прим w_bf)
- Тестировать вдвоем интереснее, продуктивнее и просто весело. А тестировать с разработчиком - вдвойне.
- Мы очень много всего сделали.
- Было полезно, узнали много нового.
- Получила ценные идеи, как можно упростить работу.
- Хорошо, что разобрали задачи, которые висели по 2 месяца.
- Очень полезно для знакомства с интерфейсом.
- Было бы здорово провести в формате "2 тестировщика в команде: ведущий и ведомый".
- Разработчики придумывают интересные кейсы.
- Интересный обмен опытом, причем, в обе стороны.
- Понравилось просто тестирование без всякой бюрократии.
- Здорово, что аналитики и разработчики уделяют время таким задачам.
- Хорошо бы проводить такое мероприятие 2 раза в год как PR.
Ну и общее мнение: ПОНРАВИЛОСЬ.
Я, как организатор сего действа, в заключение хочу сказать большое спасибо всем его участникам, а также начальству, разрешившим весь этот беспредел в рабочее время.
Со своей стороны хочу сказать, что я ходила с блокнотом, спрашивала всех "Как?", люди говорили "Понравилось", а я им верила. Потому что лица у всех в процессе были действительно очень увлеченные и заинтересованные. А это главное, пожалуй.
С Новым 2013 годом! В нем мы обязательно придумаем что-нибудь еще.
(Цитата неточная, убрал фамилии и сугубо нашу специфику)
Фот фотка доски с задачками в процессе:
 |
| Альбом: office |
А вот после:
 |
| Альбом: office |
Слово Канеру
Создайте возможности для обучения
Организуйте еженедельные или ежемесячные встречи. Цель в чтении статей или глав книг каждую неделю и их обсуждение (сотрудники обсуждают, вы присутствуете, но много не говорите). Сделайте участие в таких встречах добровольным, не принуждайте присутствовать. Но найдите способ наградить людей, которые вносят свой вклад в обсуждения и регулярно посещают встречи (предоставляйте книги тем, кто показал, что будет их читать).
Организуйте собрания-обучения. Раз в неделю или два раза в месяц. На них — расскажите сами о чем-нибудь новом, иногда можно приносить гостя-спикера (тест-менеджера из другой компании). Вы могли бы найти кого-нибудь, кто мог бы сделать это бесплатно, если вы сами проведете лекцию для его сотрудников. Иногда кто-нибудь из ваших сотрудников может выступить с докладом о технике тестирования или о проблемах в тестировании определенного устройства или приложения. Иногда можно делать упражнения для тренировки навыков.
Если ваша компания возмещает деньги на обучение, найдите курсы, предлагаемые местными университетами или онлайн-курсы, желательно связанные с разработкой ПО. Кроме того выясните, какие конференции по тестированию применимы к проектам компании. Поговорите с сотрудниками лично, помогите им спланировать непрерывное обучение. Этот разговор — отличная возможность обсудить долгосрочные цели сотрудника (примите эти цели во внимание, когда будете распределять следующую волну задач). Don't tell someone what courses to take but do point out courses you think are well-taught and relevant to the company's current projects or to the career interests of your staff member.
Главное правило — отправлять сотрудников на курсы (особенно профессиональные семинары) и конференции в парах и тройках. Они будут говорить друг с другом о том, чему научились. Пусть они сделают презентацию для вас и группы тестирования о том, чему они научились, когда вернутся.
пятница, 11 января 2013 г.
четверг, 10 января 2013 г.
Lesson 229
Отличная периодическая таблица методов визуализации.
Обнаружил у Александра Селяева.
Да, а о праздниках пост писать просто лень. Они, внезапно, были. Работал я из них не больше пары дней, что тоже нетипично.
Потом напишу. С фотками, может даже.
Слово Канеру
Не позволяйте злоупотреблять вашими сотрудниками
Люди иногда плохо обращаются с тестировщиками, запугивают, называют дураками, лжецами и так далее. Если вы тест менеджер и ваши сотрудники работают в жестких проектах, то вам, скорее всего, придется гнуть свою линию. Будьте готовы оказать сотрудникам эмоциональную поддержку и дать отпор противникам.
Парное тестирование также может быть хорошим способом обеспечить поддержку тестировщикам.
В окружении, которое оказывает высокое давление, некоторые ваши сотрудники могут сделать то, о чем пожалеют. Не делайте выговоры публично. Расскажите о недопустимости поведения в личной беседе. Если же поступок повторяется — проведите обычные дисциплинарные процедуры принятые в компании.
Обнаружил у Александра Селяева.
 |
| Альбом: office |
Да, а о праздниках пост писать просто лень. Они, внезапно, были. Работал я из них не больше пары дней, что тоже нетипично.
Потом напишу. С фотками, может даже.
Слово Канеру
Не позволяйте злоупотреблять вашими сотрудниками
Люди иногда плохо обращаются с тестировщиками, запугивают, называют дураками, лжецами и так далее. Если вы тест менеджер и ваши сотрудники работают в жестких проектах, то вам, скорее всего, придется гнуть свою линию. Будьте готовы оказать сотрудникам эмоциональную поддержку и дать отпор противникам.
Парное тестирование также может быть хорошим способом обеспечить поддержку тестировщикам.
В окружении, которое оказывает высокое давление, некоторые ваши сотрудники могут сделать то, о чем пожалеют. Не делайте выговоры публично. Расскажите о недопустимости поведения в личной беседе. Если же поступок повторяется — проведите обычные дисциплинарные процедуры принятые в компании.
Подписаться на:
Сообщения (Atom)