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

Тестирование REST API
онлайн, начало 26 августа
Автоматизация функционального тестирования
онлайн, начало 30 августа
Азбука IT
онлайн, начало 28 августа
Python для начинающих
онлайн, начало 29 августа

SALar

Регистрация: 25 сен 2003
Offline Активность: 22 авг 2019 04:55
*****

#100790 Классификация тестировщиков

Написано SALar 09 Февраль 2012 - 14:36

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

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


#99438 Что есть план тестирования и зачем он нужен

Написано SALar 10 Январь 2012 - 08:45

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

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

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

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

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

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


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

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

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


#97569 Грейды тестировщиков

Написано SALar 23 Ноябрь 2011 - 11:12

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

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

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


#97037 Максим Цепков: Аналитик и Тестировщик в одном лице – путь к качеству

Написано SALar 14 Ноябрь 2011 - 13:29


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

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

Сергей, 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. Высказанные мной тезисы готов обсуждать на круглых столах. Мне не интересно доказать свою правоту, мне интересно разобраться в применимости и ограничениях того или иного подхода. И с вами, Максим, я с удовольствием поспорю.
  • 1


#94736 Протестировать простейший предмет

Написано SALar 26 Сентябрь 2011 - 06:02

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

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

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


#94479 Что такое ментальная модель пользователя и как ее строить

Написано SALar 20 Сентябрь 2011 - 13:00

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

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

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

Геймеры.

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

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

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


Игроделы

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

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

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


  • 2


#93801 О "единственно правильных" вопросах на собеседовании.

Написано SALar 07 Сентябрь 2011 - 10:41

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

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


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


#93795 Организация работы отдела тестирования

Написано SALar 07 Сентябрь 2011 - 08:53

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

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


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

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


#92178 Метрики процесса тестирования

Написано SALar 05 Август 2011 - 15:00

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


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

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

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

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


#91972 Тестировщик с опытом - куда расти?

Написано SALar 02 Август 2011 - 16:00

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

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


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


#91971 Тестировщик с опытом - куда расти?

Написано SALar 02 Август 2011 - 15:46

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

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

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

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


#90716 Бесконечные баги

Написано SALar 04 Июль 2011 - 15:37

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

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

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

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


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


#90550 Нужна ли кнопка "Спасибо" на форуме

Написано SALar 30 Июнь 2011 - 18:52

зря.
  • 1


#90147 С чего начинать изучать тестирование с нуля! Помогите ПЛИЗ!

Написано SALar 20 Июнь 2011 - 19:18

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

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

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

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

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

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

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

Удачи.

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


#90132 Бесконечные баги

Написано SALar 20 Июнь 2011 - 07:12

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

Неправда.
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. То что описал топикстартер сильно похоже на "воронку Деминга" из этой же книги. Попытки компенсировать случайную ошибку ведут к ухудшению ситуации. Вместо этого нужно просто устранить корневые причины.
  • 2




Яндекс.Метрика
Реклама на портале