SALar

Первичный гигиенический фактор - размер и вид компенсации. Если он сильно недостаточный, то о дальнейшем можно не разговаривать. Вы просто не будете ходить на работу (office). И смысл?

Теперь о том, чтобы работу (work, task) делать.
Ключевых вопросов немного и почему то их почти все забывают задать:

1. Кто мой непосредственный руководитель (согласует отпуска, инициирует повышение зарплаты, планирует и контролирует мою деятельность)?
* Если это разные люди (бывает, бывает), то поработать эффективно, скорее всего, не получится. Но ходить на работу это не сильно мешает.
* Если ответ вымученный или его нет, то поработать эффективно, скорее всего, не получится. Но ходить на работу это не сильно мешает.

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

Очень много проблем можно избежать, если задать этот вопрос на собеседовании. Ваш непосредственный руководитель - ваш первый контакт в фирме. Неготово рабочее место - к руководителю. Где доки - к руководителю. Как зовут ту симпатичную девушку тут с чаем, кофе - к руководителю.

2. Кто может отдавать мне распоряжения напрямую?
Хороший ответ - никто кроме непосредственного руководителя.

2.а. Кто имеет право приоритезировать мои задачи?
Это вариант того же вопроса и лучше задавать в обоих вариантах.
Хороший ответ - никто кроме непосредственного руководителя.

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

Группа на эффективность компании:
1. Какой размер в милионах долларов прохода в год? Да, да не удивляйтесь размер компании меряется не числом занятых стульев, а именно деньгами.
2. Сколько человек работает?
На самом деле, задавая этот вопросы вы всего лишь выясняете ключевую для вас вещь:
Сколько денег приносит в год один сотрудник?
Для эффективных компаний (Apple, MS, ...) это порядка $1 000 000 в год на сотрудника. Эта цифирь означает, что компания может позволить себе платить вам приличную зарплату. Скажем $100k в год. Или $200k.
Будет платить или не будет - другой вопрос. Главное может себе позволить.

А если цифирь $20 000 в год на сотрудника, то сами понимаете....

-- Сначала -----
"Выход из кризиса" Деминг
"Пространство доктора Деминга" ("Организация как система") Генри Нив
"Критическая цепь" Элияху Голдратт
"Цель-3" Элияху Голдратт
"Управленческие дилеммы" Эли Шрагенхайм
"Бережливая разработка ПО" Мэри и Том Поппендик

-- Потом ------------------
"Цель" Элияху Голдратт
"Цель-2" Элияху Голдратт
"Теория ограничений Голдратта" Детмер
"Производство с невероятной скоростью" Детмер Уильям, Шрагенхайм Эли
Бережливое производство Бережливое производство. Как избавиться от потерь и добиться процветания вашей компании Джеймс Вумек, Дэниел Джонс
"Синдром стога сена" Элияху Голдратт
"Новая экономика" Э. Деминг
"It's matter (блеск и нищета информационных технологий)" Николас Карр


-- И потом еще много чего --------------------

Почитайте о сравнении разных систем:
http://www.trackstud...on-redmine.html
http://www.trackstud...comparison.html

И таки, да, я рекомендую trackstudio
* Ставится легко
* демо попробовать можно
* денег ~ $1000 на все
* функционал покрывает большую часть потребностей организации

Есть и определенные минусы:
* Система отчетности гораздо слабее чем у CQ
* нельзя вести версионность как в CQ
* нет массовых операций
Но это те вещи, которые, как правило, не используются

Внимание, халтура!


Книга плохая. Она не стоит времени, потраченного не нее.
Огромное количество грубых ошибок как авторов, так и переводчиков.

Примеры ошибок.
* Первое предложение части IV "Автоматизация": "Автоматизация тестов - основная практика гибкой методологии". Минимум два заблуждения в одном предложении.
* На той же странице еще много заблуждений от авторов, но вот пример перлов от переводчиков: "Тема автоматизации также является весьма обширной. Она включает такие задачи, как написание простых сценариев оболочки, установка свойств сеансов и создание устойчивых автоматизированных тестов." Что хотели сказать то?

Резюме: потратьте деньги и время на что нибудь приличное.

SALar, отвечаю Вам: нет, тестирование мне нравится, но вот когда весь год занимаюсь что тыканьем на кнопки мышки ну или на кнопки телефона, и понимаешь, что тут дальше я никуда не выросту,тогда уже начинается какая то паника и нервозность. Одним делом заниматься долгое время нельзя, пусть даже это будут разные проекты, но действие остаются, к сожалению, одними теми же. Мы было начали автоматизировать один проект, когда нас было больше, было очень интересно, даже задерживалась на работе, потому что хотелось написать очередной тест, или доделывала дома. Но потом нас осталось мало, и все забросили. Андроид сама начала делать, но никто время на него мне как не выделял, так и не выделяет. Это очень грустно.

Я десять лет "тыкал" в кнопочки и постоянно узнавал что-то новое без всякой "автоматизации".

Примите как гипотезу: "Автоматизация тестирования приводит к увеличению стоимости тестирования. Чтобы получить от нее пользу нужно кардинально изменить процесс разработки. А для того чтобы обосновать и провести такие изменения нужно быть не просто тестировщиком."

Андроид сама начала делать, но никто время на него мне как не выделял, так и не выделяет. Это очень грустно.

Это не грустно. Это бизнес. Выделять бюджет, чтобы вы могли заниматься абстрактыми исследованиями свистелок неразумно с точки зрения бизнеса.



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

А потому. Хотите писать код - учитесь писать код. По настоящему. С изучением теории, проверкой результатов на заказчике из бизнеса и прочее и прочее.

В продолжение семинара 14 апреля статья о производственных потоках: http://habrahabr.ru/post/139194/

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

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


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

3.
Некоторые книги в списке вас удивят. Ведь о них вы никогда не слышали. И все же настоятельно рекомендую обратить на них внимание.
* Захотите почитать что-нибудь не техническое - обратитесь к разделу "Дополнительная литература, которая по странной причине рекомендуется компьютерщикам"
* Захотите перейти от QC к QA и "Аудит" Лоббека должна стать вашей настольной книгой хотя бы на пару лет.

4.
Предложения.
а) хотелось бы дополнить список оценщиками, специализирующимися на "проектировании", "анализе", "Проектировании GUI", "DBA". Если вы прочитали 42+ книг и хотите помочь, давайте попробуем.
б) "Малые и иные формы" - разделы практически не проработаны. Кто нибудь возьмется отранжировать 500+ статей?
в) Алексей и Наталья. Можно этот список разместить где нибудь на портале?

На картинке текущие тенденции рынка.


Так чтобы требовались именно специалисты - это меньшая часть вакансий. Если брать область контроля качества, то 100+ это штучные вакансии. Например, была вакансия от Бегуна пару-тройку лет назад. Искали они обычного тестировщика (не менеджера, не ведущего). Предлагали $4000. Но требования были такие, что ого-го. В частности "отличное знание Perl", "навык коде ревью", "подготовка юнит-тестов". Т.е. они искали ведущего разработчика на коде ревью и прочие активности связанные с QC.

-- Мне кажется вам были бы полезна литература: -----
Современные методы описания функциональных требований к системам Алистер Коберн
Разработка требований к ПО Карл Вигерс
Принципы работы с требованиями к программному обеспечению. Унифицированный подход Дин Леффингуэлл, Дон Уидриг
Психбольница в руках пациентов Алан Купер
Исскуство мыть слона Влад Головач
Не заставляйте меня думать! Стив Круг
Введение в SQL Мартин Грабер
Developing Time-Oriented Database Applications in SQL Richard T. Snodgrass
Рефакторинг. Улучшение существующего кода Мартин Фаулер
Ключевые процессы тестирование Рекс Блэк
Тестирование программного обеспечения. Фундаментальные концепции менеджмента бизнес-приложений Сэм Канер, Джек Фолк, Енг Кек Нгуен
Наука отладки
Аудит Лоббек
Быстрая разработка программного обеспечения Алистер Коберн
SWEBOK
Вальсируя с медведями Том Демарко, Тимоти Листер
Путь камикадзе Йордан
Бережливое производство программного обеспечения Мэри и Том Поппендик
ГОСТ 9126
ГОСТ 28195_99

-- Дополнительно -------------------
Критическая цепь Элияху Голдратт
Цель-3 Элияху Голдратт
Пространство доктора Деминга Генри Нив
Цель Элияху Голдратт
Цель-2 Элияху Голдратт
Управленческие дилеммы Эли Шрагенхайм
Выход из кризиса Деминг
Теория ограничений Голдратта Детмер
Производство с невероятной скоростью Детмер Уильям, Шрагенхайм Эли
Карьера менеджера Либо Якока

ГОСТ 34.601
ГОСТ 34.602
ГОСТ 34.603
ГОСТ 9126
ГОСТ 28195_99
ГОСТ-54869-2011-Проектный-менеджмент
ГОСТ-54870-2011-Управление-портфелем-проектов
ГОСТ-54871-2011-Управление-программой-проектов
ГОСТ Р 50779.42-99 Контрольные карты Шухарта

Кусочки из реальных проектов.

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

Думал открыть новую тему, но решил написать сюда.
В данный момент у нас четкой градации нет - все просто "тестировщики", будь то новичок, или тестировщик с 4-летним стажем.
Необходимо создать некую градацию для тестировщиков, некие чёткие критерии, которые будут разделять всех на junior, middle, senior.
Градацию по стажу считаю не очень корректной.
Есть ли смысл сделать некую аттестацию? Какого рода это должна быть аттестация? Общая теория и/или уровень владения тулами?
А может ввести необходимость получения некого сертификата для перехода? Если да, то подскажите, пожалуйста, онлайн сертификаты..
Или же судить нужно по стажу+субьективная оценка менеджера/тимлида?
Спасибо.

http://blog.shumoos.com/archives/253

Правильно ли я понимаю:

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

Нет, не правильно.

Часто очень часто совершаемая ошибка - подмена понятий. Говоря "план" многие очень многие подразумевают активности и расписание (sheduling). Ни в коем случае не путайте эти понятия.
План не должен содержать активностей, сроков, исполнителей, оценок трудозатрат.
И да, риски туда тоже лучше не писать, а делать отдельный документ "План управления рисками".

Определение: План есть декомпозиция конечной цели на промежуточные результаты
Если хотите более академическое определение:

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

Написание плана всегда следует начинать с формулировки конечной цели (смотри "Базовые термины"). Достаточно понятным языком процесс планирования изложен в блоге Влада Балина http://gaperton.livejournal.com/

Навскидку рекомендую эти статьи:
http://gaperton.live...ление проектами

Очень важный момент. В отличии от "расписания", "план" (в том числе план тестирования) весьма статичная вещь. Очень даже может быть, что план не изменится в течении всего проекта. В отличии от расписания, которое меняется каждый день.

http://blog.shumoos.com/archives/253

Коэффициенты оплаты можете взять нижеследующие или придумать свои:

Ведущий - 1,4
Инженер - 1
Младший - 0,7
Стажер - 0,4

От водопада к Agile

"Водопад" никак и ничем не противоречит "Agile". По определению

Сергей, Agile и водопад были антагонистами с самого начала, то есть с зарождения agile.

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

Тезис который я предлагаю: темы "совмещение vs разделения ролей аналитика и тестировщика" и "выбор жизненного цикла разработки" слабосвязаны между собой.
И разделение и совмещение могут быть и там, и там, и там, и там:
* непрерывная поставка
* упаковка по объему
* упаковка по времени
* что-то еще...
Нет смысла увеличивать scoup доклада и вызывать флейм в побочных ветках.
-----------------

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

ГОСТ 34.х никак не ограничивает кросфункциональность. Более того, как раз ГОСТ 34.602 и ГОСТ 34.603 молчаливо предполагает совмещение ролей аналитика и тестировщика.
И в то же время Agile ничего не говорит о необходимости кроссфункциональности. Другое дело такие частные случаи как SCRUM или XP. Но там ни аналитика, ни тестировщика быть не должно.

К ГОСТ-34 я лично отношусь очень несерьезно. Я его читал, и, в общем, не могу относиться иначе к стандарту, в котором разработка системы суть побочный процесс разработки документации на систему (это ГОСТ 34.601-90). Вообще они устарели на 20 лет, то есть навсегда. И если говорить о ролях, то когда они разрабатывались тестировщиков как таковых - не было. Agile сейчас в представлен в виде XP-SCRUM-Canban, о кросс-функциональности говорят они. А дальше, в реальных условиях. это кросс-функциональность получается ограниченной тем или иным образом. Например, таким как в докладе.

Вовсе нет. В ГОСТ-ах 34 серии неплохо дано целеполагание. Включая декомпозицию целей и проверку достижимости. Я бы сказал обратное. Общая культура разработки ПО на текущей момент очень сильно не дотягивает до ГОСТ-ов. Нам (и мне тоже) достаточно тяжело их использовать ввиду общей деградации культуры в последние 10-15 лет. Впрочем, это еще одна тема для настоящего полноценного холивара, слабосвязанная с исходной темой доклада.

Предлагаю не трогать Canban. Это система управления работами, созданная для V-цепочек (не имеет никакого отношения к v-модели в вашем докладе) и цепоцек смешанного типа. Созданного для производства, в котором очень много ролей, но часть производственных участков могут выполнять более одной технологической операции (аналог совмещения ролей). Система создавалась на смену системе управления Форда, которая идеально подходила для производственных цепочек A-типов и, естественно, дала сбой при расширении модельного ряда.
Тот же псевдоканбан, о котором рассказывают консультанты имеет такое же отношение к системе Таичи Оно, какое имеет морская свинка к свиньям и морю. Псевдо "канбан-доски" могут применяться для производственных цепочек только I-типа и то с некоторыми ограничениями. Впрочем, это еще одна тема для настоящего полноценного холивара, слабосвязанная с исходной темой доклада.

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

Да, что обсуждалось я понимаю, но я не нашел. Если так, то можете натолкнуть на правильный ход мыслей для начала, хотя бы в двух словах. Что, вы, например, расчитываете услышать по поводу космической станции?

Посмотрите проект "Панбагон". Он создавался как раз для этого.

PS. Вопрос про тестирование лифта или чашки - не самый удачный вопрос на собеседовании.
Дайте на собеседовании потестировать сайт РЖД. Это может быть очень увлекательно. Если будете делать - сделайте видео, потом выложите на ютуб. Может после этого они почешутся.

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

Никто не видел?

Архетипы персонажей.
* Разрабатывались для одного из веб проектов. Проект вполне реальный, но заброшенный. Проект не коммерческий. Just for fun.
* Документ писался скорее чтобы набить руку, но польза от документа достаточно ощутимая. Документ не причесывался, выкладываю as is.
* Использовался для разработки функционала и пользовательского интерфейса.
* Разрабатывался в соответствии с рекомендациями Алана Купера.

Геймеры.

Домохозяйка Нина
33 года, двое детей (один ходит в школу, другой в детский сад). Муж основную часть времени проводит на работе или отсыпается дома.
Все время, не занятое домашним хозяйством проводит около домашнего компьютера (одноклассники, "правильный шоппинг", игры). Записывая развесистые ответы в социальных сетях, наработала неплохую скорость печати.
Следит за собой, регулярно наводит "марафет".
Может включить выключить, запустить браузер, игру, пожаловаться на то что "не работает".
С компьютером познакомилась еще до замужества. Но слова Вольфенштейн или Мастер оф Мейджик душу не трогают.
Игровые предпочтения: простенькие стратегии, квесты, год-симы (максимум - the sims XXX)
Терпение: сумочку нужной расцветки, фасона и размера будет искать пока не найдет (пользуется только яндексом, ибо о других не знает и знать не хочет)
Не против писать отзывы и сообщения об ошибках, но при этом имеет невысокий технический уровень.

Офисная планктонина Георгий
25 лет, не женат, детей естественно нет.
С компьютером на вы, но не показывает этого. И вообще сидению за компом предпочел бы рыбалку и боулинг.
Умеренно следит за собой, чтобы окружающие девушки не шарахались по сторонам.
Играет преимущественно на работе, пока начальство не видит (периодически отвлекаясь на чтение новостей и прочих социальных сетей)
Игровые предпочтения: таймкиллеры, короткие action-стрелялки, которые не затрагивают мыслительные центры.
Терпение: особым терпением не отличается, быстро перескакивает с одного на другое.
Может оставить комментарий, но сопровождать его не будет.

Геймер MadSerg
Считает себя кулхацкером, но вряд ли дотягивает до скрипткиддера. Системник всегда со снятой крышкой.


Игроделы

Алексей
28 лет, профи-программист flash. Вырос из кодировщика, не очень хорошо рисует, кроме того есть проблемы с игровой
механикой. Делает хорошие аркады, но тестировать не умеет, поэтому продукт выходит, хоть и интересный, но глюкавый
и не всегда востребованный.
Имеет хороший опыт работы в фирмах с высокой культурой разработки ПО.
Игры любит, и считает что ими можно зарабатывать. Основную работу еще не бросил, но если доходы от игр будут позволять,
уйдет в свободное плавание. Интересуется теоретическими основами разработки ПО.
На ошибках учится, даже пытается на чужих. Готов воспринимать критику извне (дорос года полтора назад. до этого юзеров
воспринимал как прямую угрозу).
Помимо компьютеров и программирования имеет хобби - радиоуправляемые машинки. Гоняет с энтузиастами на выходных.

Тоха
40 лет, вольный художник и всегда им был.
До сих пор держит небольшую сеть (являясь субпровайдером), для ограниченного числа пользователей. Но из этого бизнеса постепенно вытесняется крупными провайдерами.
Берется за любую ИТ'шную халтуру (протянуть сеть, настроить 1С, поднять шлюз и т.д.) лишь бы не работать на постоянном месте.
Имеет несколько постоянных клиентов, которые его знают лет 10-15 и подкидывают постоянные заказы.

Выбор редакции.
Тоха или Нина. Скорее сего Нина, Т.к. Тоха может просто "забить" на критику.