Сообщений в теме: 59

[Green]

Ребята! Не надо утрировать!

Если я не написал о наличии требований, то это еще не значит, что их нет. :D
К моменту начала работаты дата моделера и архитектора, требования уже должны быть готовы и утверждены заказчиком. И это всего лишь один из целого списка документов, которые готовяться к началу этапа создания ПО. Не надо на нем заморачиваться. Документ - это всего лишь отражение технологии, ее артифакт. Если у вас есть она, ТЕХНОЛОГИЯ, то и документ вы создадите, а если у вас ее нет, то ... Создавай документ или не создавай, это не поможет компании выжить. Только агонию продлит. :(

Против утвержденных в компании процессов, знаете ли, не попрешь! (или попрут тебя) B)

[Mike]

Проблема в том, что QA немыслим без организации работы с требованиями, ибо, по определению - качество есть соответствие требованиям.

Олешка, у меня есть из своей практики забавный пример, когда тестировщики не имели доступа к требованиям вообще. Процесс был организован следующим образом - есть "заказчики" (они же, отдел маркетинга, канадцы), которые пишут задания разработчикам на очередную версию. После прохождения приёмочного (smoke) тестирования, параллельно с другими процедурами тестирования, версия отправляется в Канаду, где канадцы играются с программой и пишут баги на несоответствие требованиям. Тестировщики же при подозрении на несоответствие требованиям, обращаются к проджэкту на данный продукт. То есть, требования есть в двух местах - в переписке проджэкта с канадцами и в голове проджэкта ;). Возможно, проджэкт тоже пишет для себя какие-то требования, но тестировщики их не видят. Система работала довольно хорошо, хотя, так как проекты были гигантские, между тестеры и разработчики регулярно играли в пинг-понг (Submit->Reject->ANew->Reject->...) именно на почве того что тестер считает что "должно быть не так", а программист считает что "это фича". Арбитрами в результате являлись Главный Программист и Менеджер по качеству.

[Kaluga]

Документ - это всего лишь отражение технологии

Документ это инструмент! ;)
И требования - не обязательно формальный документ, вполне возможно и словесное описание.
Кстати, вы сертифицировали свою ТЕХНОЛОГИЮ? Или хотя бы проводили внутренний аудит, насколько она зрелая? ;)

[Green]

To Kaluga.

В этом плане у меня "сильные тылы". Наша компания недавно получила сертификат CMMI, уровень 4. Первые в Европе и вторые в мире. :ph34r:

[Олешка]

To Kaluga.

В этом плане у меня "сильные тылы". Наша компания недавно получила сертификат CMMI, уровень 4. Первые в Европе и вторые в мире. :ph34r:

Круто! Поздравляю :)

[Case]

Сначала по процедурному вопросу:

А при чем здесь Булкаков?

Фраза про первый сорт тестера, мной нагло спёрта у классика из "Мастера и Маргариты" (диалог Воланда и Буфетчика, об осетрине по моему)

Потом по личному:
Присоединясь к поздравлению в адресс компании в которой работает господин Green.

Теперь по количеству тестировщиков на душу населения:
Как было верно замечено есть определённые методики рассчётов кол-ва тестировщиков на кол-во разработчиков. Сооотношение зависит как вы понимаете от типа проекта и организационной структуры команды тестировщиков. Принцип "Дымовой трубы" сейчас рассматривать нет смысла - у нас не аутсорснутое тестирование, у нас команда своя родная.

Беру рекомендации из моей настольной книги "Автоматизированное тестирование программного обеспечения" (Automated Software Testing) авторов Элфрид Дастин, Джефф Рэшка, Джон Пол.
[ более подробно о книге в библиотеке сервера ]
Приведу всю табличку рекомендаций для различных типов проектов.

Тип продукта | Кол-во разработчиков | Соотношение | Кол-во тестировщиков
Комерческий продукт| 30 | 3:2 | 20
(крупный рынок сбыта)
Комерческий продукт | 30 | 3:1 | 10
(ограниченный рынок сбыта)
Приложение для одного клиента | 30 | 6:1 | 5
(на заказ)
Разработка и интерграция готовых продуктов | 30 | 4:1 | 7
(для одного клиента)
Разработка внутренненого приложения | 30 | 5:1 | 6
(для правительственных структур)
Разработка корпоративного приложения | 30 | 4:1 | 7
(внутренненого для корпорации или компании)

Есть ещё процентный метод, нужно - выложу.

[SNord]

2 Green:
Присоединяюсь к поздравлениям!!!
В порядке уточнения вопрос: питерская Моторола с их CMM Level 5 - это выше CMMI 4 или нет?

[Green]

To SNord.

CMMI это, то же что и CMM, только вид сбоку. :D

Вначале был CMM...
Он описывает принципы технологии создания качественного продукта для любого производства, начиная от туристических фирм и заканчивая производством подводных лодок. Кто проходил сертификацию на ISO, меня поймет. B)

CMMI - это разновидность CMM, предназначенная для сертификации IT компаний (без подводных лодок :) ). Эта разновидность стандарта была разработана недавно, по-этому мы в первых рядах...

[Mike]

Насчёт тестовых заданий до собеседования. Там где я сейчас работаю принята именно такая практика. Совсем не напрягло выполнить тестовое задание (скорее получил удовольствие от грамотно составленных задачек). Кстати, половину ответов пришлось искать в интернете, а половину задачек на написание кода - проверял у себя на компе (о чём честно признался на собеседовании).
Мне кажется, чтобы не отпугнуть кандидатов, задания должны прежде всего, быть интересными. И небольшими (максимум - на 2 часа), и не включать в себя никаких сочинений на тему "как бы я тестировал ПО" или "почему я хороший работник" (были прецеденты). Что до предположения что "соискатель может отдать заполнять тестовое задание другу" - так это и не важно - основной отсев всё равно должен быть на собеседовании. Да и вообще, не столь важно как претендент нашел информацию, главное, он смог это сделать (так, в институте где я учился, на экзаменах можно было пользоваться чем угодно. Даже при ответе на теоретические вопросы - смог найти нужный абзац в книже на 700 страниц или в конспекте лекций плохим подчерком - и слава Богу). В чём-то это правильный подход.

[Darkus]

Мне очень понравилась эта тема.
(И идея тестирования карандаша :) )
Выношу на суд общества свою точку зрения.
Приём на работу тестировщика - это действительно задача сложная. Вот моё IMHO почему...
1. Тестировщик получает, как правило з.п. ниже программиста. Уже не помню где-то была статистика, эта сумма составляет от 50 до 80% з.п. (Можно и здесь на форуме увидеть подовляющее большинство в одном из разделов).
Соответственно.
Хороший программер на эту з.п. не пойдёт. А если и пойдёт, то только потому, что нужда.

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

3. Делаем гипотетический вывод, что люди, которые умело пишут алгоритмы и привыкли создавать программы на должность тестера в большинстве своём НЕ ПОЙДУТ.

Ну и что дальше? Терпенье... Обо всём попорядку.

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

Большинство из этих качеств есть.. правильно у программистов.
Вопрос. Что будет делать программист на месте тестировщика ? (п1-3).
Видимо это несостоявшийся или вынужденный работать по этой линии программист. Уже гораздо позже тестировщик набирается опыта, смиряется с меньшей з.п. и становится философом.
И этот человек всё равно будет пытаться работать программистом. Ведь он может потерять квалификацию...

5. Допустим, это не программист. Многие начинают с тестирования, а не с программирования.
Такие люди видят специфику своей работы немного с другой позиции. Они действительно вольные охотники и фанаты своего дела. Таких людей ценят в компаниях (в меру финансовых возможностей) и такие люди уже никуда не уходят с работы, если их всё устраивает. По-крайней мере дёргаются меньше, чем программисты. Они заслужили к себе уважение в той компании, где они работают. Их может прельстить только более высокая з.п. или смена обстановки.
Вопрос. Зачем такому человеку приходить в фирму, которая знает, что нужен тестировщик, но нужен он только потому, чтобы: "наконец-то избавиться от нескольких глюков", "ради того, что просто нужен тестировщик" или " в конце концов кто-то же должен этим заниматься"?
Им нужно подешевле и получше, как и всем другим фирмам. У нас пока ещё менталитет не дорос до того, что Хороший Тестер - Это звучит гордо - Оплачивается высоко.
Представьте, что начнётся, если у Тестировщика з.п. будет выше чем у Программиста?
(Программисты вздрогнули и сглотнули слюну) %). Шутка.

Учитывая все пункты давайте теперь реально представим кто же приходит к нам на собеседование в качестве Тестировщика? Студенты, начинающие тестировщики, те, кому лень программировать, те у кому просто хочется кушать? Прошу дополнить список.
Какие цели преследует этот человек, если он действительно хочет быть тестировщиком?
Как говорится в книге Канера - у тестировщика может быть только одна перспектива - стать Начальником тестировщиков :)
....

Это была прелюдия. И только моё мнение, которое сложено на личном опыте (5 лет).
...
Кто в моём понимании хороший тестировщик.
Это человек, который обладает хорошей памятью, сообразительный, гибко переключающийся на другие условия работы ввиду большого опыта работы и может не только, как робот писать код, покрывающий функционал, но и придумывает интересные тесты, которые программисты не станут никогда делать и даже интуитивно может предугадать где свалится программа. Человек со здоровыми амбициями и энтузиазмом.
Человек, который сможет за 5 минут рассказать какие ошибки наиболее вероятны после просмотра документации на тестовое приложение. Как он собирается тестировать такую программу и с помощью каких средств. Это может быть очень беглое устное тестирование, но оно и есть самое важное при приёме человека.

Может быть на основе этого и можно составлять "тестовое задание".
У меня есть своя методика тестирования, мне приходилось помогать при приёме и программистов, и тестировщиков, но я хотел бы вначале посмотреть, что ответят на это сообщение.
Если большинство решит, что я не прав, то возможно не стоит дальше "мусорить" :)

[Andrei Kulabukhau]

Вначале был CMM...
Он описывает принципы технологии создания качественного продукта для любого  производства, начиная от туристических фирм и заканчивая производством подводных лодок. Кто проходил  сертификацию на ISO, меня поймет.  B)

Да не, и CMM и CMMI - они оба для Software Industry, а "обо всем" - это ISO.
Коротко - CMMI - это Integrated CMM.

На сайте www.interface.ru есть пара статей про это. Если кому интересно - поищу ссылки.

[Case]

Учитывая все пункты давайте теперь реально представим кто же приходит к нам на собеседование в качестве Тестировщика? Студенты, начинающие тестировщики, те, кому лень программировать, те у кому просто хочется кушать?

Пригласите меня что ли на собеседование? :) Я вам популярно обьясню, как делал не раз на собеседовании, кто такой тестер, чем он от QA отличается :)

А если чесно, как-то не вяжется у меня ваша картина 5-летнего опыта с моим более чем скромным руководством отдела. Собеседований было не много, но приходили в основном тестеры как ни странно. Сам пришёл в тестирование после администрирования серверов БД, программирования под десктопы и под веб. Попробовал всё включая курс молодого бойца (кабеля прокладывал по потолкам в том числе) и приёшл в тестирование. Да и случай помог, но и вариантов вернуться в программирование или администрирование было много, но как-то я уходил от них - не моё.
Так что либо у вас непонятные мне требование к тестировщикам (зп скорее всего, вы этот момент указывали), что к вам неудавшиеся программисты всё идут да студенты одни (я кстати сам за студентов горой), либо что-то тут не так, как гвоорится.

По вашему так и в фирмах, которые аутсорсингом тестирования живут очень хорошо, тоже отставшие от паровоза программеры тусуются? Ой как нет. Очень сурьёзные ребята. Грамотные.

[Green]

Да не, и CMM и CMMI - они оба для Software Industry, а "обо всем" - это ISO.
Коротко - CMMI - это Integrated CMM.

На сайте www.interface.ru есть пара статей про это. Если кому интересно - поищу ссылки.

Каюсь, в желании упростить объяснение я слегка "забрел" не туда. B)
Но товарищи бдят... :)

Кстати, для тех кто хочет получить дополнительную информацию по CMM и CMMI и не хочет напрягаться, разбираясь в английском, можно почитать здесь:
http://www.interface...publicat.htm#18

Введение в СMMI:
http://www.interface...=/misc/cmmi.htm

[SNord]

To Green:
Бдит не только Andrei Kulabukhau :)
Что касается CMMI, то, по версии QAI, нет нумерации по уровням, а вводятся расширения, определяемые дисциплинами (CMMI - SE/SW/IPPD/SS), иными словами, определяемыми тем, какие области процессов (PA) покрываются .
Так что все-таки имелось в виду под CMMI-4?

[Darkus]

To Case
Ну вот наконец-то здоровая критика. А то ничего за весь день не было. Я уже засомневался, что здесь кто-то читает :)

А если чесно, как-то не вяжется у меня ваша картина 5-летнего опыта с моим более чем скромным руководством отдела.

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

Сам пришёл в тестирование после администрирования серверов БД, программирования под десктопы и под веб. Попробовал всё включая курс молодого бойца (кабеля прокладывал по потолкам в том числе) и приёшл в тестирование

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

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

Да, поэтому я считаю вас человеком, который уже определился с тестированием, как с профессией.
Я упоминал про таких людей. (п5)

Так что либо у вас непонятные мне требование к тестировщикам (зп скорее всего, вы этот момент указывали), что к вам неудавшиеся программисты всё идут да студенты одни (я кстати сам за студентов горой), либо что-то тут не так, как гвоорится.

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

[ahatan]

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

[Zenturio]

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

Нет ничего хуже для тестировщика, чем предлагать ему выполнить тест, да и еще за бесплатно.
На одно я убил весь день, это было задание для одноклассников - а у них сайт допускал логин только через 20 мин после выхода...
В итоге я потерял время... Есть множество способов проверить знания человека, не задавая ему каверзных вопросов и тестов.

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

Идея карандаша интересна. Но опять же именно потому, что предлагает поразмыслить и на данный вопрос нету правильного ответа

[Tuchka_84]

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

Очень многое зависит от человека и я не считаю , что если "тушуются, мнутся" равносильно - ничего не знают. Это совсем не так. Подготовьте задания заранее, на каждую из вакансий. Где требуется знание языка программирования , подготовьте его задачку. Где требуется умение писать планы, предложите написать план. Не давайте заданий, которые нужны Вам лишь для того, чтобы узнать психологию человека, а не его знания. Давайте реальные задания, а не карандаши.
Причем, если человек "замялся", дайте ему задание на дом. Ничего в этом страшного нет. Пусть на следующее собеседование придет и расскажет Вам все по пунктам, что он делал и почему. Либо приглашая человека сразу говорите ему взять с собой примеры его работы.
Всегда проще говорить по СВОЕЙ проделанной работе и приятно о ней рассказывать. А задать вопросы по теории можно и по его работе. К примеру, Вы видите он принес с собой тест-план. Вы же можете заглянув в него сразу все увидеть, разве не так? Вы можете задать вопрос почему человек расписал такие тестовые случаи, а такие не учел. Писать можно очень долго. У каждого своя точка зрения, как правильно проводить собеседования.

[Freiman]

Давайте реальные задания, а не карандаши.

по-моему, это уже одна из холиварных QA-HR тем - давать карандаши или не давать :)