SALar

Что бы сделал мистер Фейнман?

A> Примерно так оно и происходит.
B> знаю, я неоднократно сталкивался с этим :)
A> Проблема еще и в том, что это касается не только задач на креативность, но и чисто профессиональных вопросов.
Например знает интервьюер один единственный "правильный" способ организации деревьев в реляционной базе. Ну и все. Ты попал.
B> в итоге - любое собеседование - это лотерея из серии "попал своими ответами в объем компетенций интервьюера или нет"
A> Точно. За исключением того случая, когда интервьюер находится на уровне "Ri" и знает, что не бывает неправильных ответов. Но есть области применения разных ответов. Но таких спецов мало.

Господа, кто вам сказал что "Улучшение качества ПО" или "Поиск ошибок" или "Уменьшение рисков" - это плохие формулировки целей тестирования?

Т.к. у меня нету опыта работы в других компаниях, я не знаю, правильно ли организована работа.

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

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

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

Скажите, пожалуйста, почему плохая. А какая, например, будет хорошей?

...
Цель контроля тестирования состоит в получении обратной связи и визуализации процесса тестирования.

Классическая ошибка целеполагания. В качестве цели стоит средство. Классика из классик. Процентов 90 целей проектов именно так и пишутся. И в итог е мы имеем то что имеем.

--
Применяем первую мантру:
Как вы узнаете, что проект успешен?
Визуализация появится? Ух ты. А что это? И, главное, зачем? В какое место вы эту визуализацию собираетесь засовывать?

• После этого фирма станет выпускать больше продукции? - больше продаж в перспективе
• Она станет ее выпускать быстрее? - конкурентное преимущество - сумма контрактов выше
• Сколько человек собираются уволить? - сокращение издержек.

Ничего этого не будет? Так где профит? Покажите мне, как сбор метрик поможет фирме зарабатывать денег больше сейчас и/или в будущем. Не можете - не запускайте проект.

PS. Это не совсем правда. Но это правда о том, что цель очень плохая.

Берите ответственность, начинайте проявлять больше инициативы, предлагайте что-то улучшать, беритесь за работу так, как-будто вы уже менеджер!

Это не менеджер.
> Берите ответственность, начинайте проявлять больше инициативы - обязанность каждого инженера
> предлагайте что-то улучшать - SEPG + прочие инженеры
На одном из проектов именно будучи инженерами мы все это и делали. А руководителю проекта показывали готовые, работающие процессы, регламенты и инструкции.


Менеджер это:
* планирование
* персонал
* прокси
* обеспечение (завхоз)
И. И почитайте про активного инженера неожиданно ставшего менеджером: http://cartmendum.li....com/83012.html

Работа управленца действительно не самая интересная.
* Вам интересны интриги?
* А кропотливое, до рези в глазах планирование?
* Вы с удовольствием работаете наставником?
* Вы помните дни рождения двадцати ваших сотрудников, их жен и детей?
А ведь это основные виды деятельности управленца. Хотите? Вперед - делайте. Делайте прямо сейчас. До попадания на менеджерскую позицию. Если станете менеджером до приобретения навыков, то есть очень высокий шанс "испортить виноматериал" ( http://blog.shumoos.com/archives/236 ). Возможно, навсегда. "Безнадежен, т.к. стал менеджером слишком рано." Примеров масса.

Варианты развития "вбок":
1) Тестирование => контроль качества => обеспечение качества
Ветка дивно хороша. В конце маячит переход в SEPG.
Что рыть? Поройте "Контрольные карты Шухарта" и прочие связанные темы. Поройте финансовый и операционный аудит. Покурите ГОСТ 9126 и 28195, и связанные с ним ГОСТ-ы и статьи.

2) Тестирование => системный анализ + тестирование => бизнес анализ + системный анализ + тестирование
Ветка дивно хороша. Кросфункциональность, хотя бы и частичная - это очень, очень хорошо. Стековая система - отличная штука.
Если выйдете на третий уровень, может стать так, что вас автоматически сделают менеджером проекта, потому как: "А кого же еще!?". Со мной именнно так и было неоднократно. Я не вызывался, оно само.
Что рыть? Мой доклад с ЛАФ-2010, uml2.ru,
книги:
"Современные методы описания функциональных требований к системам" Алистер Коберн
"Разработка требований к ПО" Карл Вигерс
"Принципы работы с требованиями к программному обеспечению. Унифицированный подход" Дин Леффингуэлл, Дон Уидриг

"It's matter (блеск и нищета информационных технологий)" Николас Карр
"Бизнес со скоростью мысли" Билл Гейтс
"Поиск решения"

Да уж, век живи - век учись. Спасибо, почитаем.
По поводу корневых проблем. Бывает так, что один офис считает корневой проблемой другой офис. Тут главное удалить правильно. Точнее, найти...

Тоже мне проблему нашли. Строите диаграмму "Дерево текущей реальности" по методу из этой книги: http://www.ozon.ru/c...ail/id/5288956/ (Детмер "Теория ограничений Голдратта: Системный подход к непрерывному совершенствованию.")


PS. Это жестокий совет. Количество матана в этой книге превышает летальную дозу для большинства людей в несколько раз.
Начните с книги "Управленческие дилеммы: Теория ограничений в действии." (Шрагенхайм) http://findbook.ru/r...artner=findbook

Она сильно проще. Но и строить диаграммы она не научит как следует.


PSS. Если нет документации - это большой дефект. Тоже можно завписать.

зря.

Стажерам или тем кто только начинает.

Зубры из зубров могут искать работу очень просто. Они изменяют статус "в контакте" на "ищу работу". На этом их активная деятельность по поиску работы заканчивается и они просто выбирают куда пойти работать. Иногда они не утруждают себя и этим. Бывает и так. Иногда они выбирают фирму, приходят и говорят: "У вас прикольно, как насчет меня?" - и их берут.

Но для этого нужно много делать. Что же делать сейчас?

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

А если у вас еще нет работы.
Советы:
* делайте как сказал astenix
* Работайте на пользу сообщества. Чаще добровольно и бесплатно. Вам нужны связи, а не деньги.
* Идите на фрилансерские сайты, не торгуясь берите любые работы и честно указав, что вы в параллель с сотрудником нанятым за деньги, будете тестировать бесплатно. Ваш бенефит не деньги, но опыт. Единственное ваше условие - чтение ошибок более опытного тестировщика. Но именно в параллель. деньги за тестирование обязательно должен получить хоть кто-то. Не вы. Вам нужно "читатть код". Поработайте в паре, потом выпросите условие - предоставление текстов найденных вами ошибок будущему работодателю.
* Помните, не вас покупают, но вы продаетесь. По крайней мере пока.
* Учите панбагон и дописывайте его. (К Баранцевым).

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

Советы:
* Прямо сейчас начинайте фиксировать список людей, у которых вы бы хотели учиться/работать. С кем вы бы хотели работать. Я такой список веду.

Удачи.

PS. Некоторые люди - мои ученики. Возможно, не все они об этом знают. Если вы соответствуете некоторым притчам, вас, возможно, тоже кто-то возьмется учить.
"истинное знание не требует платы, ибо вы посвящаете ему жизнь."
Но помните. Плата за это гораздо больше, чем просто оплата тренингов деньгами. Может быть вы не сможете заплатить. Или не захотите. Я захотел.

[*]Это первая конкретная вещь, которую мне посоветовали с момента начала поиска информации по проблеме. Спасибо.

Неправда.
1. Вам уже говорили про управление конфигурациями. Теперь ваш вопрос должен быть о том, где об этом читать. Ответ: SWEBOK ( http://swebok.sorlik...management.html ) - очень хорошо, но тяжеловато для начала. Поэтому идите на habrahabr и ищите по тегам "конфигурационное управление", "управление конфигурациями", "Версионный контроль" и т.д. Там где-то и моя статья есть.

2. Я вам уже давал ответ: Дефекты нужно править до написания кода, а не после него.. Не совсем понятно? Тогда вот развернутое объяснение: http://blog.shumoos.com/archives/230 . Опять непонятно? Э-э-э...

3. Может вам специалиста по тестированию пригласить? Алексея Баранцева, например? Благо сейчас он в основном и занимается тренингами и консалтингом.

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

[*]К сожалению, осмысливается тяжеловато. Легче всего поняла часть про психологию. Может быть, по той причине, что старательно пытаюсь понять, что происходит в голове у коллеги. И почему оно происходит только сейчас, а не раньше.
[*]Пока единственное, что вынесла, -- "не делайте вредное и бесполезное". И не удивительно: сомневаюсь в том, что и как делаю в данном контексте, я же не управленец. Всего лишь хочу, чтобы мне не мешали выполнять мою работу. При этом написано, что невозможно отличить хорошее от плохого заранее наверняка. А вопрос "что делать?" никуда не исчез.

Это одна из лучших (или лучшая) книга о менеджменте. Но она контринтуитивна.
В лучшем случае получится примерно так:
1. Что за чушь?
2. Да, ерунда все это.
3. Это неправда потому что: ...
4. Да но...
5. Да но как это сделать?!

Между первым и пятым вполне может пройти 3-10 лет. И вам сильно повезет, если вы не успеете стать "большим начальником" до достижения 4 или 5. пому как потом переучиваться существенно дольше, сложнее и дороже.

PS. То что описал топикстартер сильно похоже на "воронку Деминга" из этой же книги. Попытки компенсировать случайную ошибку ведут к ухудшению ситуации. Вместо этого нужно просто устранить корневые причины.

ошибок может сократить уровень ошибок до такой степени, что выделенное тестирование будет не нужно.

И есть ли у нас пример программного продукта, доказывающего это утверждение?

Огромное количество отличных программ было создано без тестирования. На одном из проектов, я доказал с цифрами в руках и добился остановки тестирования до встраивания качества в продукт. Дело в том, что ~ 70% ошибок были связаны с отсутствием всего двух проектных документов. И дешевле было их написать, чем тестировать.
На другом проекте мы поступили по иному. После нахождения второй типичной ошибки в ПО мы вносили еще один пункт в FAQ и рассылали его. Поиск ошибок такого типа прекращался на некоторое время, до устранения расхождений самими программистами.

Так, что да, у меня есть примеры.

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

И еще. Посмотрите главу 18 из книги "Пространство доктора Деминга". Потом читайте всю, книгу, но сначала туда.

В этом форуме вы ответ вряд ли найдете.

Есть два (грубо) архетипа собеседующих вас людей.
-- Тип первый
Этот человек прочитал в одной Очень Умной Книге (Услышал На Очень Серьезном Семинаре)
Правильный Ответ на Правильный Вопрос.
Теперь он наделен эзотерическим знанием: "Есть только одна партия, тьфу, религия, тьфу, правильный ответ".
Для того, чтобы пройти это собеседование нужно просто знать, какой же ответ этот человек считает правильным.
И не вздумайте показать что вы знаете несколько решений! Если вы не угадали, у вас еще есть шанс сыграть на самолюбии: "Я не очень опытный, но ведь вы меня научите?". Если же вы сказали, что есть несколько решений и, еще хуже, указали границы применимости - все, вы враг народа, все пункты 58 статьи ваши.
Я вас уверяю, что ответ "за 9 проектов никогда не вылетал из графика " точно является неправильным. Как же так, у них ни один проект в сроки не укладывается, а тут приходит не пойми кто и субординацию нарушает.

-- Тип второй
Ему не очень важно какой тип решения вы выберите. Он может оценить корректность даже неизвестного ему способа решения.


Эти два архетипа очень хорошо представлены в известной басне "об измеpении высоты башни с помощью баpометpа". Заметим, что Нильс Бор получил неуд у преподавателя соответствующего первому архетипу.

PS. IMHO, применять с осторожностью. среди собеседующих из HR преобладает люди первого архетипа, из технического отдела - также больше людей соответсвующих первому архетипу, но соотношение, скорее, 60/40.

Достаточно?

------------------------------------------------
4.2 Типы тестов
4.2.1 Объект тестирования
Unit (Элемент) – наименьший компонент, который можно скомпилировать.
Unit testing (поэлементное тестирование) – заключается в изолированной проверке каждого отдельного элемента путем запуска тестов в искусственной среде. Для этого необходимо использовать драйверы и заглушки. Поэлементное тестировани – первейшая возможность реализовать исходный код. Оценивая каждый элемент изолированно и подтверждая корректность его работы, точно установить проблему значительно проще, чем если бы элемент был частью системы.
Драйверы – модули тестов, которые запускают тестируемый элемент.
Заглушки - заменяют недостающие компоненты, которые вызываются элементом и выполняют следующие действия:
• возвращаются к элементу, не выполняя никаких других действий;
• отображают трассировочное сообщение и иногда предлагают тестеру продолжить тестирование;
• возвращают постоянное значение или предлагают тестеру самому ввести возвращаемое значение;
• осуществляют упрощенную реализацию недостающей компоненты;
• Имитируют исключительные или аварийные условия.
Тестирование сборки. Проверяется корректность функционирования скомбинированных вместе элементов. Существует четыре стратегии сборки:
• Снизу вверх. Сначала следует выполнить поэлементное тестирование для компонентов, находящихся на более низком уровне, а затем перейти к высокоуровневым компонентам. Для этого метода используются драйверы.
• Сверху вниз. Высокоуровневые подпрограммы становятся драйверами для остальных элементов. В этом методе используются заглушки, имитирующие поведение низкоуровневых элементов.
• Сэндвич. Здесь комбинируются методы сверху вниз и снизу вверх.
• Большой взрыв. Объединяются все элементы. Объединяются все элементы.
System testing (тестирование системы)- Проверяется продукт в целом. После того как все програмные и аппаратные компоненты собраны, подтверждается соответствие продукта исходным требованиям проекта. При наличии полностью скомпонованной системы тестер может оценить многие атрибуты, которые нельзя оценить на более низких уровнях тестирования. Результатом даного тестирования является решение о готовности системы к выпуску. Среда тестирования должна быть как можно ближе к среде развертывания.
Integration testing – в ходе этого тестирования проверяется взаимодействие тестируемого приложения с другими приложениями.


4.2.2 По целям
Инсталляционное тестирование – основная цель, убедиться, что программное обеспечение может быть установлено при различных условиях.
• новая инсталляция,
• усовершенствование системы (upgrade),
• полная или выборочная инсталляция – при нормальных и ненормальных условиях. Недостаточное количество дискового пространства, недостаток привилегий (например, на создание директорий) и т.д.
Данные и целостность базы данных. Проверяется конистентность данных. Включает в себя проверку:
• ссылочной целостности (основной источник проблем)
• ограничений на значения параметров
• ограничений на неинициализацию значений
• ограничений на уникальность значений
Функциональное тестирование - основной тест. Проверка правильности работы. Каждая функция должна отвечать требованиям.
Тестирование бизнес-цикла - должно имитировать действия, выполняемые пользователем и охватывать все типичные операции пользователя. Как правило, тесты объединяются в единый тест сьют.
Тестирование графического интерфейса пользователя.
Тестирование производительности - скорость работы системы при идеальных условиях и максимальная нагрузка
Нагрузочное тестирование – это те же тесты производительности, при которых система подвергается различным нагрузкам; при этом цель этого тестирования – оценить способность системы правильно функционировать при некотором превышении планируемых нагрузок при реальной эксплуатации (система имеет некоторый «запас прочности»).
Объемное тестирование - приложение нагружается большим количеством данных, чтобы определить, когда достигаются условия, при которых система перестает работать.
Стресс тестирование - поведение системы при недостатке ресурсов (дискового пространства, обрывов сети, …)
Конфигурационное тестирование - тестирование работы на различных платформах. Различные варианты аппаратной конфигурации, версии операционной системы и окружения (MDAC, .Net, браузеры, …).
Тестирование безопасности и прав доступа - сосредоточено на двух ключевых областях безопасности:
• Безопасность уровня приложения, в том числе доступ к данным или бизнес-функциям.
• Безопасность уровня системы, включая вход в систему или удаленный доступ к системе.


4.2.3 Способ работы с кодом
White-box test. Тестирование методом «Белого ящика». Для конструирования тестов используются внутренняя структура кода и управляющая логика. При этом существует вероятность,что код будет проверяться так, как он был написан, а это не гарантирует корректность логики.
Black-box test. Тестирование методом «Черного ящика». Для конструирования тестов используются требования и спецификации ПО. Недостатки:
• таким способом невозможно найти взаимоуничтожающихся ошибок,
• некоторые ошибки возникают достаточно редко (ошибки работы с памятью) и потому их трудно найти и воспроизвести и т.д.

4.2.4 Стадии тестирования
Исследовательское тестирование – Прогон приложения с целью выяснения функций приложения и их реализации для подготовки тевстовых сценариев. первый этап в принятии решения что и ка будет тестироваться. Применяется при недостаточном документировании процесса разработки (отсутствие или неполнота спецификаций, прототипов интерфейса, …)
Smoke test (проверка на дым) - Оставшийся с доисторических времен способ проверки электронного оборудования в процессе переконфигурации или ремонта, который сводится к элементарной подаче напряжения на данный модуль и визуальной проверке, нет ли искрения, дыма или других явных признаков неработоспособности.
В более общем смысле первый прогон программы (после написания или после внесения существенных изменений). Как правило используется для определения готова ли программа для передачи в тестирование и продолжается 4-8 часов.
Регрисионное тестирование – Повторное использование поднабора тестов в новой версии приложения, чтобы убедиться, что функции, которые работали в предыдущей версии системы, по прежнему работают так, как ожидалось.
Приемочное тестирование – быстрая проверка работоспособности очередного релиза. Является подмножеством функциональных тестов и состоит из типичных пользовательских сценариев, сосредоточенных на основных требованиях к функциональным возможностям. Как правило, это тестирование автоматизируют.


4.2.5 Метод выполнения.
Ручное тестирование – ввод исходных данных и проверка корректности результата производится непосредственно человеком. Слабо применимо для:
• нагрузочного тестирования
• тестирования производительности
Автоматическое тестирование - ввод исходных данных и проверка корректности результата производится специализированным ПО.