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

Тестирование безопасности
онлайн, начало 10 июля
Тестирование мобильных приложений
онлайн, начало 10 июня
Программирование на Java для тестировщиков
онлайн, начало 12 июня
Школа для начинающих тестировщиков
онлайн, начало 11 июня

SALar

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

#105301 Лайза Криспин. Гибкое тестирование.

Написано SALar 10 мая 2012 - 11:59

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


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

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

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


#104957 Помогите сделать из резюме конфетку!

Написано SALar 27 апреля 2012 - 08:12

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

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

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

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

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



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

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


#104468 Тестирование как сервис, предоставляющий услуги всем группам разработк

Написано SALar 18 апреля 2012 - 11:03

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

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


#103119 Рекомендую [не] читать: <...><...>

Написано SALar 28 марта 2012 - 11:52

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


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

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

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

Прикрепленные файлы


  • 3


#103098 Знания требующиеся на зарплату от...

Написано SALar 28 марта 2012 - 08:47

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


Так чтобы требовались именно специалисты - это меньшая часть вакансий. Если брать область контроля качества, то 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 Контрольные карты Шухарта
  • 1


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

Написано SALar 01 марта 2012 - 08:20

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

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

Прикрепленные изображения

  • cr.PNG
  • mo.PNG

  • 1


#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




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