Приведу лишь один пример. Организация может пригласить консультанта из Agile alliance или из SEI. Эти консультанты поставят взаимоисключающие диагнозы и назначат прямо противоположное лечение.
Не совсем в тему пример. Речь не идёт о выборе методологии разработки.
QUOTE
анкетирование для того чтобы узнать мнение работников о текущем состоянии качества в компанию?
На этот конкретный вопрос, поставленный автором топика в первом сообщении ответ должен быть примерно одинаков независимо от того какую методологию "проповедует" консалтер. Конечно, с поправкой на общую вменяемость и фанатичность консалтера. Если он проводил хотя бы несколько аудитов и ест с этого хлеб - то ответ будет в рамках реальности.
QUOTE(Yury @ Apr 27 2007, 05:32 AM)
А в Казахстан и я соглашусь поехать, при условии, что знаю заранее, какой совет от меня ожидается.
анкетирование для того чтобы узнать мнение работников о текущем состоянии качества в компанию?
На этот конкретный вопрос, поставленный автором топика в первом сообщении ответ должен быть примерно одинаков независимо от того какую методологию "проповедует" консалтер. Конечно, с поправкой на общую вменяемость и фанатичность консалтера. Если он проводил хотя бы несколько аудитов и ест с этого хлеб - то ответ будет в рамках реальности.
1) Первый вопрос, который задаст себе консультант, который уже сталкивался с подобными ситуациями раньше, это "А с чего это вдруг руководство озаботилось мнением работников?". Как правило, это означает, что руководство чем-то недовольно и пытается что-то улучшить. И начинать надо, конечно-же, с прояснения ответа на этот вопрос.
2) Любой аудит проводится на основе стандартизированных методик, основанных на некотором понимание процесса разработки. Поэтому аудиторы от разных организаций, естественно, могут прийти к самым разным выводам для одной и той же ситуации.
3) Аудитором я ни разу не был и не собираюсь им быть. А вот консултантом приходилось работать. Были у меня случаи, когда мои советы принимались, и ситуация кардинально менялась к лучшему. Но был и случай, когда мои советы были полностью проигнорированы, так как они не соответсвовали ожиданиям руководства. Поэтому, на основании своего опыта и опыта других людей, с которыми я общался, я скептически отношусь к заявлениям о том, что любой консултант в состоянии разобраться в любой ситуации и "прописать лекарство", которое будет принято и изменит что-то к лучшему.
Пакет навыков для начинающего тестера (Управление тестированием ПО: тест менеджмент)
2007-04-30 12:35 rulllesss
Всем привет! Есь вопрос по минимальным требованиям к тестеру Много людей (которие приходяит на собеседование) думають что для тестера (для начала) основное - уметь кликать по кнопкам и знать что такое Windows при этом обязуются бистро учится в тд. Но реально очень трудно работать с такими людьми (на вопрос какая у тебя ip отвечают - незнаю, а как єто узнать, или не знают что такое SELECT * from .....)
Так вот, может кто знает или имеет такой себе CheckList для тестера типа: 1. Знание жизненного цыкла разработки ПО 2. Windows (продвинутий юзер) 3. SQL основы 4. ООП ......
Пакет навыков для начинающего тестера (Управление тестированием ПО: тест менеджмент)
2007-04-30 16:24 KaNoN
Универсального CheckList-а скорее всего нет, поскольку само понятие "среднестатистического тестера" если и есть, то наверняка весьма размыто, так как тестирование - это достаточно широкая область и знания могут быть нужны самые разные. Поэтому, как минимум желательно выделить группы вопросов, которые можно задать кандидату на собеседовании. Примерно накидаю систему, по которой у нас составляют вопросы на собеседовании.
Обычно во время собеседования от кандидата стараются получить информацию о его предыдущей профессиональной деятельности. Поэтому 1-я категория вопросов - вопросы о предыдущей проф. деятельности кандидата. Интересно просто послушать, что и как он рассказывает, на чем ставит акценты. Это не совсем кореллирует с данной темой, но тем не менее уже здесь можно сформировать определенное мнение о кандидате.
Естественно, желательно, чтобы человек имел хотя бы общее представление о тестировании. Соответственно, 2-я категория вопросов - это общие вопросы о тестировании, например:
- Что такое тестирование? - Какие виды тестирования вы знаете? - Какие техники используются при тестировании (примеры)?
Ну и тому подобное. Уже здесь можно примерно определить уровень кандидата. Более того, это вопросы, на которые ответов может быть очень много, так что каждый раз придется выслушивать "сочинения на вольную тему".
Далее, уже можно проверить умение работать с операционными системами. Если требуется знание Unix, то пару-тройку простеньких вопросов по Unix. Затем, горький опыт должен подсказать, какие знания вы бы хотели видеть у своего сотрудника (или даже подчиненного). То есть здесь можно и проверить, как извлечь IP той или иной машины, как проверить, если ли такой-то компьютер в сети и т.п. То есть 3-я категория вопросов: навыки работы с операционными системами.
Последняя категория вопросов - проверка специальных знаний. Данная категория зависит от используемых технологий, используемых средств. Если есть работа с базами данных, то можно проверить у кандидата знание общей теории баз данных (хотя бы, что такое реляционная модель баз данных и т.п.). Если вы считаете, что при работе нужно еще и знание SQL, то пару вопросов по SQL.
Также можно проверить знания относительно технологий, на основе которых реализован интерфейс приложения (то есть это или .NET, Java, или DOM-модель). Как минимум стоит поинтересоваться, как устроены те или иные модели, какая иерархия у объектов. Подобные знания в достаточной мере желательны, поскольку хорошо, когда человек понимает внутренние механизмы работы приложения, которое он тестирует.
Насчет таких программерских заморочек, типа ООП заранее ничего сказать не могу, но если кандидат претендует на позицию автоматизатора тестирования, то его еще и по программированию желательно "полирнуть", причем достаточно основательно (вплоть до тестовых заданий), так как может оказаться, что из кандидата кодер просто никакой ( как минимум это позволит с чистой совестью предложить кандидату вознаграждение поменьше ).
Таким образом, берутся все вышеуказанные категории и по ним уже детально можно составлять вопросы, проверяющие разные спектры знаний кандидата. А что именно проверить по каждому из пунктов - это уже определяйте из своих пожеланий к хорошему кандидату. Хотите, чтоб кандидат знал SQL - составьте несколько вопросов по данной теме, хотите, чтоб человек знал свой IP - спросите кандидата, как IP можно узнать (а там и сопутствующие вопросы дозреют). А вообще, представьте просто в уме того кандидата, который бы вам подошел и с которым не было бы никаких проблем и по этим представлениям формируйте контрольные точки для проверки знаний, навыков и прочих характеристик
Основная цель - отобразить структурой основные разделы знаний и направлений в тестировании ПО: тест менеджмент, тест дизайн, выполнение тестов и багтрекинг, автоматизированное функциональное тестирование и тестирование производительности.
Срау хочу оговориться: ничего не пропадёт, так как ничего пока не удаляется. Явный мусор, который будет попадаться на глаза, конечно уйдёт в корзину, но сейчас цель не чистка, а именно изменение структуры.
Вопросы и предложения можно и нужно оставлять в этой ветке.
Как я понимаю надо сделать подфорумы отдельно по инструментам автоматизации функц. тестирования и по средствам тестирования производительности, а потом (неприятный сюрприз...) переносить руками из первой категории форумов во второй те топики, которые по тулам и вопросам нагрузочного тестирования.
Проблемы форума по тестированию производительности (Революция - это тут!)
2007-05-02 03:15 Case
Дима, салют. Думаешь просто скопировать две структуры по вендорам там и там? Я думаю этот вариант и вариант с форумами по конкретным тулам и общий по теории. Как думаешь - как прозрачнее с точки зрения структуры?
1) Первый вопрос, который задаст себе консультант, который уже сталкивался с подобными ситуациями раньше, это "А с чего это вдруг руководство озаботилось мнением работников?". Как правило, это означает, что руководство чем-то недовольно и пытается что-то улучшить. И начинать надо, конечно-же, с прояснения ответа на этот вопрос.
Тут вы говорите, что сначала идёт аудит, я верно понял?
QUOTE(Yury @ Apr 29 2007, 10:37 PM)
2) Любой аудит проводится на основе стандартизированных методик, основанных на некотором понимание процесса разработки. Поэтому аудиторы от разных организаций, естественно, могут прийти к самым разным выводам для одной и той же ситуации.
То есть, если в компании проекты ведутся по Agile, а консультант будет ориентирован на MSF то о качестве процессов он скажет что всё плохо? :) Что-то у вас или консалтер какой-то получается однобокий - "если не так как я понимаю, то однозначно плохо", или я никак не уловлю логики.
Кроме того, получается - снова таки по вашим словам - что аудит возможен только тогда, когда лицо проводящее аудит уже знает и понимает процесс разработки в компании Заказчика. Простой вопрос - откуда он это знает? Вы не путаете Консалтинг и внутренний аудит?
Вы как-то непонятно отделяете аудит от консалтинга и Аудитора от Консультанта.
QUOTE(Yury @ Apr 29 2007, 10:37 PM)
3) Аудитором я ни разу не был и не собираюсь им быть. А вот консултантом приходилось работать.
И снова не понятно. То есть вы консультировали без предварительного аудита? Как это согласуется с вашей же точкой зрения высказанной абзацем выше?
QUOTE(Yury @ Apr 29 2007, 10:37 PM)
Поэтому, на основании своего опыта и опыта других людей, с которыми я общался, я скептически отношусь к заявлениям о том, что любой консултант в состоянии разобраться в любой ситуации и "прописать лекарство", которое будет принято и изменит что-то к лучшему.
Если формулировать именно так как вы говорите, то, конечно, фигня это всё, а не консалтинг :)
Только вот снова у вас консалтер получается как Анальгин - пригласили ТОГО консультанта, повезло Заказчику, а если не ТОГО то всё, всё у Заказчика будет плохо. При этом видимо Заказчик должен сам угадать какого консультанта ему звать? А если был Agile, а теперь хотим RUP то звать двух и смотреть как будут драться? :)
Если говорить всё же ближе к теме запроса, то речь идёт - как я себе вижу - о процессном менеджере, который может быть приглашен в качестве консультанта для проведения стороннего обследования и консультирования в направлении выявленных процессных несостыковок. И никакого универсального консультанта, который прийдёт и всё починит, тут даже на горизонте нет.
А ничего удивительного. Знающие специалисты есть, а если еще и прозвучит волшебное слово "аутсорс", то и подрядчик тут же нарисуется весь в белом и на белой коне
Так что если этого сервиса в Люксофте еще нет, то наверняка появится.
Немного не так, а вернее совсем не так. Люксофт - как я себе пониманию - достаточно крупная компания, чтобы не бросаться на любой, пусть даже денежный, проект. Тут вопрос скорее в сфере фокусировки на услугах, чем денег. И с фокусом на сервисе разработки у Люксофта, как я понимаю, всё в полном порядке.
Отсюда мой вопрос всё тот же :)
Проблемы форума по тестированию производительности (Революция - это тут!)
2007-05-02 05:26 Dmitry_NJ
Привет, Слава. Я думаю, что стоит реализовать ту же структуру, что и в форуме по функциональному тестированию - общие вопросы и вопросы по инструментам, по которым нет своего подфорума, класть непосредственно в "Тестирование производительности". И там же создать специализированные подфорумы по конкретным вендорам.
Но просто копировать не стоит. Во-первых, вендоров для performance testing будет меньше, а во-вторых, Borland и Segue надо бы объединить уж коли это теперь одна компания.
Вы как-то непонятно отделяете аудит от консалтинга и Аудитора от Консультанта.
В моём понимании, аудитор - это человек, который проводит формальный аудит, на основе утверждённых методик, например "CMM/CMMI/ISO/SPICE". Его задача - это ответить на вопрос: "Соответствует или не соотвествует стандарту?" и задокументировать все отклонения. Причём эти отклонения могут быть как в лучшую, так и в худшую сторону. Консультант же - это человек, в задачу которого входит улучшение чего-либо.
P.S. Вполне возможно, что мои определения не являются общепринятыми.
