Планируем и презентуем план, тест план.

После предварительной оценки проекта и рисков по тестированию самое время переходить к написанию тест плана или планов, что советует Rex Black. Вы приступаете к ознакомлению с моими цитатами из 2-й главы. Managing the testing process

1. Нужно создавать несколько отдельных тест планов по тествовым подпроектам, которые отличаются друг от друга:
- по времени ( планируется в другое время)
- используемым методам
- по различным целям (написание тест планов component, integration, system позволяет сфокусироваться только на каждом отдельно и их конкретных целях)
- по различным аудиториям (тк тест план предмет review, то нужно уметь чётко донести свою мысль, чтобы взамен иметь хорошую обратную связь)

2. Когда есть несколько тест планов, то создаётся ещё единый master test plan, что обобщает текущие тест планы со всеми ссылками на них

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

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

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

6. Успешное прохождение smoke tests один из часто используемых инструментов оценки текущего релиза для тестирования ( entry criteria)

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

8. Необходимо изолировать баги, те работать с системой, пока не найдёшь очевидных, кратких вероятностей и закономерностей возникновения бага.

9. Предпочтительно иметь релиз раз в неделю. Это практика показала себя с самой лучшей стороны на многочисленный проектах.

10. Релиз должен выходить в стандартном формате со стандартной процедурой установки. Тестирование установки (installation testing) - ключевой аспект тестирования любой программы. Также важно не забывать и об обратном, удаление программы.

11. Для каждой из активностей по тестированию, ролям, ответственности проводятся дополнительные совещания. Все эти моменты должны быть включены в тест план.

12. Лучший подход для "продажи" тест плана - это провести митинг со всеми менеджерами. Без подобного митинга можно просто остаться без обратной связи по тест плану. Личная же встреча заставляет хотя бы ознакомится с документом.

13. После ревью-митинга надо иметь тест план с большим количеством пометок и замечаний. Это будет означать, что final version не за горами.

14. Не пиши в документе, что что-то должно быть сделано. Вместо этого чётко формулируй КТО ЧТО и КОГДА. Распределение ролей и обязанностей позволит чётко расставить акценты в проекте и избежать проьлемы с ответсвенностью за ту или иную задачу.

Что мы имеем. (Rex Black)

Некоторое время думал, каким образом лучше описывать главы из книги Managing the testing Process. Решил, надо как обычно - читаю и выделяю ключевые и интересные с моей точки зрения мысли и идеи.


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


1. Перед началом организации всего процесса тестирования нужно определить: 
а) Что мы можем протестировать
б) Что мы должны протестировать
в) И в конце концов, что мы сможем протестировать


2. Проект тестирования нужно продать своему менеджменту для получения необходимых ресурсов и времени.


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


4. Программы, написанные на С и С++ часто имеют серьёзные security bugs, связанные с переполнением буфера.


5. Beta тестирование часто проводится как ad hoc ( случайное, что является худшим вариантом тестирования) или как exploratory (исследовательское, что является лучшим вариантом).


REM: По поводу exploratory testing мне норавилась публикация James Bach Exploratory Testing Explained .


6. Часто прожект план по тестированию игнорирует или недооценивает важность интеграционного тестирования, что приводит к нехватке ресурсов в тот момент, когда возникает в нём необходимость.


7. Acceptance testing включает в себя настоящие данные, натоящее окружение и типичные сценарии пользователей. Поэтому маркетинговый отдел, отдел продаж, техническая поддержка, и даже управленческие кадры компании - лучшие кандидаты для такого тестирования.


8. Для того, чтобы понять что тестировать, нужно определиться: что означает качество применительно к предмету тестирования, и какие риски качества (quality risks) существуют.


9. То, что пользователь чаще всего намеривается или использует в системе, является областью наиболее критичиской с точки зрения рисков.


10. Существует понятие - project risk. Когда первичный эффект от какой-либо проблемы влияет на успех и выполнение всего проекта- это project risk.


11. Для успеха в тестирование нужно расставить все тесты по приоритету и начинать тестирование всегда с самого важного. При недостатке времени всегда можно будет убрать из плана менее важные тесты.


12. Самые важные функциональности или аспекты тестируемого софта должны быть покрыты самым большим разнобразием тестов. И усилися при тестировании прилагаться соответсвующим образом.


13. Предварительный анализ всех усилий по тестированию обычно базируется на некорректных предположениях и недостаточной информации.


14. Лучший способ определения рисков качества - проведения многосторонних встреч с техническими и бизнес специалистами в компании.


15. Сhecklist всех аспектов, входящих в понятие качества продукта, достаточно большой.
Вот некоторые из аспектов:
- Functionality
- Performance
- Error/disaster handling and recovery
- Data flow coverage
- User Interface
- Installation setup and initial configuration
- Documentation and packaging
...


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


17. Слишком сильная детализация рисков приведёт к сложностям в упралении ими, низкакя детализация вызовёт тркдности в установке приоритетов тестов.


18. При невозможности придти к согласию по степени рисков эту степень должен выставить тот, кто в конечном счёте ответственен за качество поставляемого продукта.


19. "Schedule, cost and quality - pick two" Что означает, выбираешь и устанавливаешь 2 аспекта и они уже определяют третий. 
NB: VERY IMPORTANT 


20. Структура тест - цикла ( Confirmation Tests --> Scheduled Tests --> Exploratory Tests)


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


22. Хороший продакт менеджмент предполагает постоянный анализ существующего плана и его изменение согласно менеющимся обстоятельствам.


23. Предварительное планирование предполагает участие в обсуждение плана всех лиц, участвующих в проекте. Однако согласно исследованиям первичные оценки изменяются проектов изменяются на 50, а то и на 200%


24. Оценку тестирования сложно сделать идеальной, но не ужасно сложно сделать хорошо.
Составить план требует нетривиальных способностей, поэтому в начале старайтесь делать более простые планы.  В сложных планах можно и запутаться.


25. Единственное табу в составлении планов - согласиться потом всё сделать за меньшее время или меньшими ресурсами. Если уж менеджмент настаивает, пусть он берёт на себя все риски.


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

Книги по тестированию

Наконец, мой товарищ переправил через океан давно ожидавшиеся мной книги. Действую согласно советам старших товарищей http://www.happy-pm.com/blog/?p=1626.

Managing the Testing Process: Practical Tools and Techniques for Managing Hardware and Software Testing by Rex Black. Третье издание вот только только вышло в августе. Для меня это не особо принципиально, предыдущие я не читал. Но всё равное приятно оказаться на волне со временем и почитать самую новою и в тоже время классическую книгу по тестированию. Я планирую читать и, по мере чтения, делиться ключевыми мыслями из книги  публикуя посты. Глав что-то около 12, так что как раз до НГ должно хватить, посмотрим на мою английскую скорость чтения, понимания и конспектирования.

Вторая книга, что прилетела ко мне из-за океана Lessons Learned in Software Testing by Cem Kaner.
Книга вообще бородатая, уже 2001 года. НО всё равно считается одной из самых лучших книг по тестированию. С ней у меня примерно такой же будет план, чтение и публикации. Буду читать последовательно. Сначала Black, затем Kaner.

Предвкушаю приятное и полезное чтиво...

Теряя невинность.

Название книги Ричарда Брэнсона для России получилось достаточно провакационным. Не многие у нас знакомы с брэндом Virgin,  а между тем, это очень известный в западном мире брэнд, созданный Ричардом Брэнсоном.
Книга "Теряя невинность" автобиографичное повествование о жизне Брэнсона и К. О том, как он создал и разивал свой брэнд.
Книгу я прослушивал утром во время зарядки, поэтому цитат нет. Есть просто ключевые мысли, которые запечатлелись у меня в мозгу.

-> Максимальная вовлечённость в работу для достижения результата

- > Цель - постоянное расширение и развитие бизнеса (но не просто деньги и прибыль)

-> Доверять своей интуиции при принятии ключевых для бизнеса решений

-> Настойчивость в достижении цели

-> Уверенность в себе (смело идти на свой страх)

-> Не забывать снимать стресс ( Брэнсон летал на воздушных шарах над континентами и океанами, плавал на лодке через Атлантику, а сейчас даже про космос задумывается)

-> Конкуренция с большими компаниями с позиции лучшего качества обслуживания

-> Всегда искать пути улучшения качества обслуживания, вводить новые виды услуг ( массаж на борту самолёта)

Книга даёт эмоциональной пинок для всех соневающихся. Если очень хотеть и начать делать, то все обязательно получится! Теперь я готов слушать и читать  Брэнсона дальше, благо есть ещё 2 книги.

Дональд Трамп (искусство заключать сделки)

Знакомлю Вас с очердной книгой, что я прослушал по дороге на работу и обратно.
Дональд Трамп (искусство заключать сделки) 
К тестированию книга также отношения не имеет, но может полезна для развития личных и профессиональных качеств тестера.
Без формальностей излишних сразу отмечу те моменты, что важны для каждого в цели достижения своих целей ( у Трампа - это были сделки)

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

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

- Уметь ждать своего случая

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

- Быть смелым и уверенным

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

- Здоровый образ жизни, стабыльные семейные ценности (когда книга писалась Трамп был женат первый раз и было 3 детей, а теперь wiki Однако 3 жены и 5 детей не помешали его финансовому успеху )

- Знание своего дела (это даже для минимального успеха в жизни обычно нужно :) )

- Выбор лучших в свою команду ( как для строительства небоскрёба в Нью Йорке или казино в Атлантик-сити, Трамп всегда выбирал лучших)

- Всегда всё чётко просчитывать и укладываться в срок (а это полезно для любых проектов и по тестированию в том числе)

В целом впечатления приятные, ощущение, что погрузился в жизнь Нью Йорка. Там царит и жадность и наглость и глупость и есть Трамп с его философией и целеустремлённостью.
Есть его Trump Tower , что он построил, а теперь тут и работает и живёт.

Даже возникло желание посмотреть на New York воочию :)

911 и тестирование

Сегодня 8-я годовщина трагедии в штатах. Кто виноват, кто реальный исполнитель и тд. - эти вопросы не для моего блога. Мне просто стали интересны ряд вопросов.
А ведь и конструкции самолётов и состав материалов, и порядок расположения людей в салоне - всё должно тестироваться на различные случаи. В данном случае это stress testing наверно. Также просто инструкциий стюардессам мне кажется недостаточно, нужно и их тестировать на психологическую стрессоустойчивость. А ситуаций может быть много: психованный пассажир, истерика, травма, родах ( такое тоже бывает) и тд. А ведь есть и пилоты и борт инженеры - и тут тестирование и симуляции многих ситуаций помогает много.


Вот ведь как, без тестирования в нашей жизни никуда. Да даже собеседование и испытательный срок тоже своего рода тестирование. Вот как событие 911 навело меня на философию. Зато тестерская самооценка повысилась ещё.


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


Вобщем и целом пост получился напоминаем о 09.09 - дне тестера. Тестеры - нужны, тестеры - важны
Поздравляю себя и ... если кто ещё прочитает этот поток сознания!

Жизнь внутри пузыря.

Прочитал Игоря Ашманова "Жизнь внутри пузыря". К тестированию это не имеет по сути никакого отношения. Просто интересное и отлично описанное биографическое произведение об IT проекте. Как проект развивался, какие были социальные и межличностные конфликты на фоне приличного финансирования. По традиции, я отмечал любопытные для себя цитаты.


--Любой проект разработки ПО - риск.


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


--Инвесторы пытаются рулить проектом и принимать практические решения, но не брать за это ответственность.


--Хороший инвестор обещает не больше денег, а перспектив.


--Уволился, так как понял, что вынужден общаться на работе с неприятными и хуждыми мне людьми


--Лишней работы не бывает.


--Люди,мотивированные делом, это те, кто говорит кратко, разумно и по делу на совещаниях, а после совещаний выполняет принятые на них решения.


--Работа вперёд.


--Если даёшь результат и держишь небо, то уволить тебя или опорочить гораздо труднее.


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


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

Transition to IT manager.

Жанр сложно определить, но просили рецензию.
Блоггер я начинающий, поэтому такой стиль ,думаю, мне простителен.
Начну из далека. Как-то в феврале случайно заглянул в большой список рассылок, что ежедневно сваливается мне на почту. Уж и не помню когда я его читал до, и после не особо радовал вниманием. Так вот смотрю - бесплатный вебинар.
Что такое вебинар я тогда не знал, но слово бесплатный конечно заставило прочитать всё до конца. Тема мне интересна и я решился. Работа не волк.., можно и после обеда придти.
Так что умылся, побрился, приготовил завтрак и включил свой ноут в сеть. Сказал ребёнку не шуметь, мол папа собрался делом заняться. Вот так случайно у меня на кухне и зазвучали голоса Орлова и Панкратова.
Ну так вот, к делу.
Какие мысли для меня оказались новыми и интересными:
а)  сделать проект для себя дома и посмотреть, готов ли на подвиги на работе
б) оценить уровень желаемой зп через год, три и пять и соотнести с уровнем предполагаемой должности и ответсвенности
в) всегда доказывать, что лучший среди равных и готов у продвижению вперёд
г) Оценивать менеджера по тому, как он спорит, приводит аргументы и тд
+оценивать своего менеджера и чему возможно, учиться у него
д) PM = не просто товарищ с большой зп, но защитник интересов команды
е) нужно заниматься PR в IT, иначе кто узнает, что ты такой хороший, мягкий и пушистый
ж) превосходить\опережать ожидания
з) use the pencil first + who what when
и) TM - Архангельский (большое спасибо за ТМ!)

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

Что банально, но от этого не менее важно
а) уметь общаться ( слушать)
б) публично выступать
в) знать хорошо английский
г) "я не 100$ чтобы всем нравится"
д) Стивен Кови и его 7 навыков
е) time/budget/ customer satisfaction

Просто запомнилось:
" Солнце ещё высоко...." ( себе так тоже написал дома)
" Нормальная зп потом, а жить тоже потом?"
" иии..... ты вопрос решил?"
Любимая кружка - лидер вебразработки.
"Сидеть на попе ровно"
"турбонадув включать сразу"

ЧТо не понравилось:
- иногда были проблемы со связью,
- коллеги ведущие забывали нажимать unmute,
- перерыв был очень коротким ( когда прибежал из ЖЭКа, тренинг уже продолжился :),
- не определили изначально порядок ответов на вопросы и долго тянули с основной программой тренинга.
- Панкратов, как мне кажется, "болоболил" больше и много прерывал Орлова.

Что можно было бы ещё осветить:
... много всего, но и за это большая благодарность.

Общие итоги:
Я очень благодарен Орлову и Панкратову за их бесплатную для меня инициативу. (4 часа инветиционного времени не в счёт)
С конца февраля моё желание сомообразование получило более чёткую структуру. Я прослушал TM и стал применять ( увы уже много опять надо начинать заново, но кое-что осталось). Составил список книг для прочтения и начал по-немногу двигаться по нему. Начал заполнять пробелы в знаниях о тестировании. Открыл свой блог ( это уж только благодаря Орлову). Action plan составил и... забыл (может пока время не пришло).
И наконец, мне доверили небольшой QA project.

I'm on the way to it manager :)

Ещё немного цитат по Тестирование.com

Листал свою тетрадь с записями и нашёл ещё несколько цитат из книги. Пусть и они не потереяются в многочисленных моих тетрадках, а остануются в памяти потомков :)


18.  Отвечать на вопросы по спеку - святая обязанность продюсера (автор спека)


НО!


19. Нет email - нет доказательств. АП- я сам теперь стал чаще использовать этот простой приём. Ответ будет всегда у себя в папке. Да и слово не воробей, а тестеру спокойней :)


20. Тестеры на работе используют ту степень детализации, которая нужна в конкретной ситуации. АП - это как раз про тесты напоминание. Тесты нужно писать в соответсвии с достаточной для выполнения детализацией. Мне это близко - поэтому я подчеркнул этот момент.


21. Блок - схемы - визуальные источники идей для тестирования. АП- пока не использовал, но надо обязательно попробовать. Всё равно, для понимания некоторых вещей приходится рисовать схемы в тетрадке.


В качестве анонса: изучал открытую для доступа презентацию Славы Панкратова "Менеджмент тестирования". Сделал ряд пометок и цитат. Скоро выложу.

Тестирование.com Part 3 (Final)

Продолжаю цитировать Тестирование.com.


15. Количество багов до релиза ничего не говорит об эффективности тестирования. Баги найденные после релиза - вот это важно. АП- "Качество продукта - количество багов найденных клиентом и его реакция на них." На одном из докладов по тестированию в Agile labs 2009 про тестирование услышал это определение. ( Для подробностей отсылаю к Александру Орлову )
Мне оно очень понравилось, теперь я тоже смотрю на вещи шире. Идеального продукта не было и не будет, задача тестирования найти максимум проблем.


16. АП- Спецификация конечно мать или отец всех тестов, но можно и просто воспользоваться здравым смыслом. Далее я привожу список примеров ожидаемых результатов тестов из книги Романа.
а)  жизненный опыт

б) здравый смысл
в) общение ( с разработчиками в том числе)
г) устоявшиеся стандарты
д) статистические данные
е) авторитетное мнение


17.  Тест- смета создаётся после чтения спека. Факторы анализа при составлении тест-сметы *10% (примерно всё посчитать и накинуть минимум 10 процентов)
а) предполагаемая сложность новых фич 
б) есть ли опыт тестирования похожих фич
в) опыт работы на прошлых проектах с теми же продюссером ( автор спецификации) и программистами.
г) Будет ли интеграция нашего ПО с ПО наших бизнес партнёров
д) Нужна ли автоматизация.
АП- Не всегда все эти элементы удаётся посчитать, поэтому я в текущем своём проекте просто прикинул по срокам, которые пришли сверху и составил свою смету в рамках текущих сроков.

После написания всех тестов, успешной настройки всей нетривиальной системы и 1-го прогона тестов буду править текущих план.


Итого: Книга Романа мне понравилась, написана бодро и весело. Несколько интересных моментов я отметил цитатами выше. Ещё много осталось за кадром. Жаль что я пришёл к ней только через 4 года тестирования, до этого у меня было много здравого смысла, интуиции. А теперь есть ещё и знания.  А мог бы уже быть выше по карьерной лестнице :)

Тестирование.com Part 2

Продолжаю цитировать книгу Романа Савина Тестирование.com.


8. Тестировать пограничные значения. АП - Думаю все знакомые с тестированием хорошо представляют о чём идёт речь. Но я всё же расшифрую. Мы имеем какое либо поле, которое поддерживает значения от 1 до 99. Соответсвенно, чтобы хорошенько проверить это нужно ввести следующие значения: 0,1, 50,99,100,-1
-1,0 и 100 не должны приниматься системой, как выходящие за рамки требований.


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


10. MRD (marketing requirements document) АП- я это пометил, тк для самого стало сюрпризом, что основа требований для разработчиков и тестеров является документ от маркетинга. В своей практике я пока такого не встречал. В моём текущем проекте требования пишет разработчик уже после создания программы и то только потому, что мне нужно писать тесты по требованиям. :)


11. Спецификации должны иметь уникальный ID. AП - Я конечно это знал давно, но просто отметил для себя, это действительно важный момент. Если спек поменяют и удалят требование, а на его место поставят другое, то сложно будет для тестеров понять. Почему в тесте ссылка на спек, который описывает совсем другую функциональность.


12. Излишняя детализация тестов усложняет поддержку, а излишнее абстрагирование ведёт к непониманию. АП - Часто вопрос выбора стратегии написания тестов, вопрос времени, денег и ресурсов. При наличии всего в достатке, можно писать очень подробные тесты. А при отсутствии оного, просто следовать в тестировании некому чек-листу, списку наиболее важных моментов для тестирования. Я сам на данный момент нахожусь в промежуточной ситуации, поэтому тесты пишу, но без лишних подробностей.


13. Шаги и настройки повторяющихся сценариев можно вынести в отдельный документ.
АП - Чувствую, что очень полезная вещь. Но пока в практике у меня не было такого, попробую в текущем проекте.


14. Два и более ожидаемых результата в тесте - нормальная практика. АП- При написании тестов я часто пользуюсь таким приёмом, это сокращает время на создание теста. Но начинающим тестерам, это не всегда понятно, почему тут сразу несколько результатов.


To be concluded

Тестирование.com Part 1

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


Когда я читал книгу, я  подчёркивал фломастером интересные и важные мысли. Поэтому я буду просто делиться тезисами из книги Романа Савина в своей интерпретации, прикладывая к этому свои мысли. 
Мысли будут начинаться с АП(Антон Пирогов)


1. Источник ожидаемого результата теста - СПЕЦИФИКАЦИЯ.  АП - это всё конечно правильно, но у меня в практике столько раз было и сейчас есть, что тестировать уже надо, а спецификация ещё в зародыше или примерно отражает версию продукта в лучшем случае годовой давности. В таком случае разработка спецификации и тестирование идут параллельно, взаимно дополняя друг друга.


2. В запасе на регрессионное тестирование должно быть минимум 3 дня. АП - как я понимаю, желательно просто к основному плану добавлять эти дополнительные дни на случай задержки или осложнений при тестировании( отлавливание редкого бага или что-то другое)


3. Приоритезация тестов и test suits (тестов, сгруппированных по объекту тестирования) - наиважнейшее из задач в условиях дефицита времени, человеческих ресурсов или денег
АП - в моем пока самом большом проекте (2.5 года) мы совсем этим не занимались. При хорошем финансировании из-за океана у нас было много времени, чтобы и все тесты поделать и просто погонять систему под любым углом. Лишь в кризисные времена стали заниматься отсевом тестов для финального регрессионого тестирования.


4. Необходимо примерно знать время выполнения каждого теста и соответсвенно test suit.
АП - думаю тут без комментариев.


5. Негативаное тестирование находит больше багов, чем test to PASS. 
АП - Как тестер в большим опытом манульного тестирование не могу не согласится с этим утверждением и даже больше. Это моё любимое занятие - пытатться сломать систему


6. Severity - категория абсолютная, оценка бага с точки зрения функционирования программы.
Priority - категория относительная, важность бага с точки зрения бизнеса.
АП - тут будет ссылка на статью про Severity and Priority ( забыл где прочитал). Основная идея статьи была, что severity ставит инженер, а Priority выставляет менеджер.


7. Перед тем как занести баг в систему трэкинга багов, вопроизведи его!
АП - Ой какой важный принцип, иногда так хочется сразу написать и отрапортавать. Мол,вон какой я молодец, как здорово работаю. Сам иногда натыкаюсь на эти грабли, увы.


to be continued...

Стартую!

Всем привет!

Вот в мой 28-й день рождения я наконец созрел для блога. Тк вот уже 4 года я работаю в тестировании, то думаю можно наконец о нём писать. 

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

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

Начну я как и советуется Александром Орловым и К с Романа Савина Тестирование.сom

В блоге я также буду делиться резензиями и краткими резюме из книг по

самосовершенствованию и ит-менеджменту, тк для хорошего тестирования нужно

всё!

"Начинать всегда трудно..." Гришковец "Как я съел собаку"

Поэтому засим откланиваюсь и готовлю материал для первого поста.

А это был блин, чувствую всё-таки комом :)