Перейти к содержимому

Публикации chezar

16 публикаций создано chezar (учитываются публикации только с 29 марта 2023)


#75822 Формируем сообщество тестировщиков в Беларуси

Отправлено автор: chezar 19 мая 2010 - 15:35 в Обучение тестировщиков ПО

Да форматов общения можно придумать сколько угодно. Важно чтобы было с кем это обсуждать.
Несмотря на то, что в Беларуси очень много тестировщиков я не смог собрать прошлую поинтовку. Был только 1 отзыв, и то не по моему посту в форуме.
Быть может надо подумать об отдельном ресурсе, как это сделали питерские ребята.

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


Соглашусь с LeshaL.
Поднять ресурс вроде it4business.ru или software-testing.ru, привлечь аудиторию, а главное поддерживать его - задача, которая должна сильно мотивировать, в общем-то быть хлебом насущным (например, для консалтера постоянно практикующегося на предоставлении услуг по курсам/консалтингу и не занимающегося больше ничем другим). Или, как написал LeshaL, должен быть как минимум постоянный костяк заинтересованных людей, объединенных общей идеей, а лучше задачей (целью), хотя и в этом случае тоже должен быть кто-то, кто на этом будет зарабатывать деньги и кровно заинтересован, т.е. быть двигателем прогресса. Если нет хотя бы одного кровно заинтересованного - будет что-то вроде "http://sqadotby.blogspot.com/", организаторы все очень умные сильные специалисты (всем привет :)), заинтересованные в получении и шаринге знаний, но по ходу недвижимые неким крепким мотиватором. Результат - последний пост за "понедельник, 6 июля 2009 г.", т.е. почти год назад. Запала хватило на год (что впрочем считаю отличным достижением).

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



#76300 Требования <> Features list <> Test cases

Отправлено автор: chezar 14 июня 2010 - 12:59 в Инструменты управления тестированием ПО

TestDirector - это который сейчас именуется Quality Center ? Немного почитал о нем - действительно, по описанию там есть что-то похожее, но демо/триал версии найти не получилось.
Ну и продукт, вероятно, сильно перекрывает мои задачи. Учитывая стоимость решений от Mercury - переплата за ненужные функции выльется в кругленькую сумму :)


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

Если у вас есть лицензии на IBM Rational Suite - то requisite pro + test manager, то что решит ваши задачи.



#76259 Требования <> Features list <> Test cases

Отправлено автор: chezar 11 июня 2010 - 06:32 в Инструменты управления тестированием ПО

а чем не нравится HP TestDirector?



#76349 Тестовые задания для технических писателей

Отправлено автор: chezar 17 июня 2010 - 06:11 в Свободное общение

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

Да, теоретически - можно тестировщиков попросить написать пользовательскую документацию.
Уф..... почитайте форум.

Только вот - шанс, что полезут из всех щелей жаргонные словечки крайне велик.
И опять же - функционала-функционалом.
Есть масса вещей, которые профессиональный технический писатель знает и умеет.

И!
На минутку -
Программный продукт - это программа + документация.
Думаю, что экономить на пользовательской документации не стоит. Пусть документацией профессионалы занимаются!


Не буду, спорить :). В нашей компании эта практика достаточно успешно существует, вероятно вы пытались давать разрабатывать документацию не тем людям.
Жаргонные словечки могут полезть у кого угодно, даже у тех писателей (не все они родились тех писателями, большинство ранее занимали какие-то специфичные позиции на ИТ проектах), ситуацию можно контролировать если у вас в компании есть:
1) Грамотный шаблон пользовательской документации.
2) Описаны правила структуризации информации, есть готовый лексикон для описания событий и свойств приложения, есть правила редактирования документов (т.е. процесс формализован).
3) Есть ответственное лицо с солидным опытом работы, которое может выступить в качестве редактора, потратить час своего времени, чтобы сгладить потенциальные недостатки документов.

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



#76283 Тестовые задания для технических писателей

Отправлено автор: chezar 11 июня 2010 - 14:21 в Свободное общение

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


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



#76253 Смоук тест для клавиатуры

Отправлено автор: chezar 10 июня 2010 - 15:13 в Тест-дизайн и ручное тестирование

Смоук тест для клавиатуры говорите...
Подключаем клаву к ящику - если ничего не задымилось, значит тест пройден :)

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



#75823 Сайт для тренировки

Отправлено автор: chezar 19 мая 2010 - 15:48 в Тест-дизайн и ручное тестирование

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


А чем Вам не нравится старый добрый ListBoxer? :) ИМХО для тренировки самое то.



#76350 Оцените проект биржи тестирования

Отправлено автор: chezar 17 июня 2010 - 06:53 в QA: обеспечение качества

вообще идея русского варианта Utest хороша, странно что раньше не сделали. Хотя и есть небольшие сомнения, на сколько хорошо это будет работать в наших реалиях.

Текущая реализация оставляет желать лучшего - поддерживаю все вышеперечисленные коменты. Главный слоган "дешевое тестирование" - навевает на мысли о некачественной работе :(.



#76437 Должен ли подчиненный "пинать" своего менеджера?

Отправлено автор: chezar 22 июня 2010 - 15:31 в Управление тестированием

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



#76457 Должен ли подчиненный "пинать" своего менеджера?

Отправлено автор: chezar 23 июня 2010 - 09:37 в Управление тестированием

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

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


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

А в целом, помогая начальнику, наталкивая его на какие-то шаги, высказывая пожелания по организации работы, вы тем самым в конечном итоге добиваетесь двух вещей:
1) проект успешно сдается, вашему менеджеру дают бюджет на выделение премий команде;
2) нормальный менеджер всегда вспомнит о том, кто хорошо работает и дает дельные советы, и в зависимости от степени Вашего вклада либо даст Вам премию, либо напишет запрос на повышение Вам ЗП, либо напишет рекомендацию на перевод вас на более высокую позицию, ну или все сразу если вы мега мозг и ваши идеи рулят :).



#76352 Деструктивное мышление

Отправлено автор: chezar 17 июня 2010 - 07:27 в Свободное общение

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



#73389 Вопрос: Как действовать, когда к подчиненному обращаются в обход непос

Отправлено автор: chezar 21 января 2010 - 16:45 в Обучение менеджеров проектов

Из того, что вышестоящий руководитель (из руководства компании) поставил задачу рядовому сотруднику не через непосредственного менеджера, можно сделать как минимум два вывода:
1) Вы работаете в небольшой компании, где все знают компетенцию друг друга (кто за что отвечает, какими навыками обладает), задача была поставлена вероятно в ваше отсутствие, или во избежании бюрократических проволочек (ускорение процесса), задача несложная, не требующая больших временных затрат. То что оказалось, что задача более сложная, чем ожидалось - сыграли риски :).
Вывод: в целом нет большого криминала со стороны вышестоящего руководства по данному событию, но тем не менее стоит вежливо обсудить проблему назначения, контроля, выделения времени и приоритезации задач для ваших подчиненных.
Решение:
- Отстоять у руководства практику, чтобы таски вашему отделу ставились только через Вас.
- Дать полбу сотруднику, объяснить, что необходимо согласовывать свою загрузку и краткосрочные планы непосредственно с Вами.

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

Решение: см. пункт 1.



#76080 Внедрение автоматизации тестирования ПО на уровне проекта

Отправлено автор: chezar 02 июня 2010 - 07:19 в Портал Software-Testing.Ru

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

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

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

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

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

Да, keyword-driven не универсален, нельзя применить везде где ни попадя и вообще универсального решения/средства/методологии до сих пор, на сколько знаю, не придумали :). Но, как написано в статье "в большинстве случаев, мы рекомендуем.....". Никто не говорил про бездумное ориентирование на одно решение. В таких проектах всегда есть этап исследования, в рамках которого выбирается инструмент, оценивается инфраструктура заказчика, уровень подготовки специалистов, .... Все эти данные перевариваются, и только после этого предлагается решение. Заказчик, после этапа исследования и выданных предложений по внедрению, может посчитать плюсы и минусы, опять таки бабки (не факт, что будет возможность применить бесплатное средство автоматизации или то, на которое у заказчика по каким-то счастливым обстоятельствам могут оказаться лицензии), и в конечном итоге подумать "а оно мне надо или я смогу прожить и дальше без автоматизации?".

По поводу того, что не вдавались в описание преимуществ автоматизации, ну что тут скажешь, по поводу плюсов/минусов можно написать целую книгу, а не статью :)))). На самом деле, как заметил SALar преимущества автоматизации не всегда очевидны, часто спорны, на каждый плюс можно найти минусы. Поэтому в статье сделана ремарка, что думать про автоматизацию надо по крайней мере, когда у вас хорошо построен базовый процесс контроля качества и автоматизация будет Вам помогать, а не станет дополнительной головной болью.
Преимущества однозначно выделить нельзя, надо изучать процесс, проектные задачи, оценить стоимость ручных регрессионных и кросс-платформенных тестов, посчитать стоимость разработки автоматизированных тестов и ожидаемое тестовое покрытие. После этого можно заводить разговор про плюсы/минусы.

Еще раз всем спасибо за отзывы и критику :).
Удачного дня!



#76261 База учета тестируемых функций

Отправлено автор: chezar 11 июня 2010 - 06:45 в Инструменты управления тестированием ПО

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


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



#76260 Import to QC

Отправлено автор: chezar 11 июня 2010 - 06:36 в Hewlett-Packard (Mercury) - Functional Testing

Guys -

Does QC have import feature for design steps?


Есть импорт требований, багов и Test Plan Tree. В user guide для Quality Center посмотри секцию "Developing a Test Plan Tree". Импорта непосредственно степов по ходу нет.

Note: In addition to creating a test plan tree directly in Quality Center, you
can also import test plan data from Microsoft Word or Microsoft Excel to
your Quality Center project. To import from Word, you must install the
HP Quality Center Microsoft Word Add-in and the HP Quality Center
Connectivity Add-in. To import from Excel, you must install the
HP Quality Center Microsoft Excel Add-in and the HP Quality Center
Connectivity Add-in. You can install the add-ins from the HP Quality Center
Add-ins page. For more information, refer to the HP Quality Center
Installation Guide.



#76455 Почта: враг внутри

Отправлено автор: chezar 23 июня 2010 - 09:01 в Анонсы и обсуждения материалов it4business.ru

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

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

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

Ситуацию "дурацкая манера доброй половины менеджеров1 не доводить начатое до конца" не совсем понимаю. Как и писал ранее, на мой взгляд ключевая задача менеджера: инициализировать, поставить и контролировать прогресс и сдачу проекта (или выполнение задачи). Если задача не доведена до конца - подразумевалось, что это завал проекта?