Пока я так и не собрался с конспектами двух прочитанных книг. Но зато я уже начал читать новые книги :) В этот раз я пока ничего не покупал и нашёл интересный ресурс, гже есть много полезных для тестеровщиков книг. http://www.ebookee.net/
Что я там нашё и к чему приступил:
1. A Practitioner's Guide to Software Test Design
2. Effective Methods for Software Testing
3. How to Break Web Software (2006)
4. Software testing fundamentals
5. Systematic Software Testing.
6. Testing Applications on the Web Test Planning for Mobile and Internet-Based Systems,2nd Edition
7. The Art of Application Performance testing
Из блогосферы открыл для себя блог Майкла Болтона http://www.developsense.com/.
Много интересных и развивающих материалов.
Пришёл к пониманию различия между testing vs. checking.
Смотрю видео по exploratory testing on http://www.testrepublic.com/video
Так что продолжаем тестировать и развиваться!
вторник, 4 мая 2010 г.
пятница, 9 апреля 2010 г.
I'm back. + testing podcasts
Дамы и господа.
Наконец я собрался и буду опять продолжать работу по разбору книг и прочих материалов по тестированию. Отсутствовал я по объективно-субъективным причинам. Болел, работал, сдавал на права и ездил в США в командировку.
Книги, что я заявил прочитать, я прочитал. Так что с меня просто конспект прочитанного и оценка. Для меня этот конспект полезен будет, да и для вас надеюсь тоже.
Если кратко, то обе книги мне понравились.( Lessons learned in software testing and Managing testing process. ) Потянуло ещё читать про тестирование дальше.
Для себя за это время открыл подкасты по тестированию на английском.
http://codingqa.com/ - интересные ребята. Главный приоритет отдаю передаче 28, где участвует James Bach. Хотя сам всё конечно не слушал и многое только собираюсь.
http://testingpodcast.com/ тут тоже можно найти интересное, но как-то они не особо активны в этом году.
Наконец я собрался и буду опять продолжать работу по разбору книг и прочих материалов по тестированию. Отсутствовал я по объективно-субъективным причинам. Болел, работал, сдавал на права и ездил в США в командировку.
Книги, что я заявил прочитать, я прочитал. Так что с меня просто конспект прочитанного и оценка. Для меня этот конспект полезен будет, да и для вас надеюсь тоже.
Если кратко, то обе книги мне понравились.( Lessons learned in software testing and Managing testing process. ) Потянуло ещё читать про тестирование дальше.
Для себя за это время открыл подкасты по тестированию на английском.
http://codingqa.com/ - интересные ребята. Главный приоритет отдаю передаче 28, где участвует James Bach. Хотя сам всё конечно не слушал и многое только собираюсь.
http://testingpodcast.com/ тут тоже можно найти интересное, но как-то они не особо активны в этом году.
четверг, 8 октября 2009 г.
Планируем и презентуем план, тест план.
После предварительной оценки проекта и рисков по тестированию самое время переходить к написанию тест плана или планов, что советует 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. Не пиши в документе, что что-то должно быть сделано. Вместо этого чётко формулируй КТО ЧТО и КОГДА. Распределение ролей и обязанностей позволит чётко расставить акценты в проекте и избежать проьлемы с ответсвенностью за ту или иную задачу.
понедельник, 28 сентября 2009 г.
Что мы имеем. (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. Единственное табу в составлении планов - согласиться потом всё сделать за меньшее время или меньшими ресурсами. Если уж менеджмент настаивает, пусть он берёт на себя все риски.
Итоги: Примерно разобрался в первоначальных задачах, что нужно решать при начале проекта. Не всё можно применить в таком виде, что описано в книге, но оно и понятно, условия у всех разные.
Название поста - это мой вольный перевод названия главы. Ну а в скобках автор сего классического труда.
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. Единственное табу в составлении планов - согласиться потом всё сделать за меньшее время или меньшими ресурсами. Если уж менеджмент настаивает, пусть он берёт на себя все риски.
Итоги: Примерно разобрался в первоначальных задачах, что нужно решать при начале проекта. Не всё можно применить в таком виде, что описано в книге, но оно и понятно, условия у всех разные.
вторник, 22 сентября 2009 г.
Книги по тестированию
Наконец, мой товарищ переправил через океан давно ожидавшиеся мной книги. Действую согласно советам старших товарищей 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.
Предвкушаю приятное и полезное чтиво...
суббота, 19 сентября 2009 г.
Теряя невинность.
Название книги Ричарда Брэнсона для России получилось достаточно провакационным. Не многие у нас знакомы с брэндом Virgin, а между тем, это очень известный в западном мире брэнд, созданный Ричардом Брэнсоном.
Книга "Теряя невинность" автобиографичное повествование о жизне Брэнсона и К. О том, как он создал и разивал свой брэнд.
Книгу я прослушивал утром во время зарядки, поэтому цитат нет. Есть просто ключевые мысли, которые запечатлелись у меня в мозгу.
-> Максимальная вовлечённость в работу для достижения результата
- > Цель - постоянное расширение и развитие бизнеса (но не просто деньги и прибыль)
-> Доверять своей интуиции при принятии ключевых для бизнеса решений
-> Настойчивость в достижении цели
-> Уверенность в себе (смело идти на свой страх)
-> Не забывать снимать стресс ( Брэнсон летал на воздушных шарах над континентами и океанами, плавал на лодке через Атлантику, а сейчас даже про космос задумывается)
-> Конкуренция с большими компаниями с позиции лучшего качества обслуживания
-> Всегда искать пути улучшения качества обслуживания, вводить новые виды услуг ( массаж на борту самолёта)
Книга даёт эмоциональной пинок для всех соневающихся. Если очень хотеть и начать делать, то все обязательно получится! Теперь я готов слушать и читать Брэнсона дальше, благо есть ещё 2 книги.
Книга "Теряя невинность" автобиографичное повествование о жизне Брэнсона и К. О том, как он создал и разивал свой брэнд.
Книгу я прослушивал утром во время зарядки, поэтому цитат нет. Есть просто ключевые мысли, которые запечатлелись у меня в мозгу.
-> Максимальная вовлечённость в работу для достижения результата
- > Цель - постоянное расширение и развитие бизнеса (но не просто деньги и прибыль)
-> Доверять своей интуиции при принятии ключевых для бизнеса решений
-> Настойчивость в достижении цели
-> Уверенность в себе (смело идти на свой страх)
-> Не забывать снимать стресс ( Брэнсон летал на воздушных шарах над континентами и океанами, плавал на лодке через Атлантику, а сейчас даже про космос задумывается)
-> Конкуренция с большими компаниями с позиции лучшего качества обслуживания
-> Всегда искать пути улучшения качества обслуживания, вводить новые виды услуг ( массаж на борту самолёта)
Книга даёт эмоциональной пинок для всех соневающихся. Если очень хотеть и начать делать, то все обязательно получится! Теперь я готов слушать и читать Брэнсона дальше, благо есть ещё 2 книги.
Дональд Трамп (искусство заключать сделки)
Знакомлю Вас с очердной книгой, что я прослушал по дороге на работу и обратно.
Дональд Трамп (искусство заключать сделки)
К тестированию книга также отношения не имеет, но может полезна для развития личных и профессиональных качеств тестера.
Без формальностей излишних сразу отмечу те моменты, что важны для каждого в цели достижения своих целей ( у Трампа - это были сделки)
- Целеустремленность и упорство (не раз и не два суд, миниципалитет, элитный клуб отвечал ему нет или просто его игнорировал. Трамп же не сдавался и пытался и пытался)
- Никогда не пробосать своё дело (Выбрал цель и стремись к ней, нельзя всё время отрываться на другое, потом на третье. Так ничего и не достигнешь)
- Уметь ждать своего случая
- Всегда сдавать сдачу (если хочешь достичь в жизни высоких целей, не надо бояться быть зубастым и защищать свои интересы)
- Быть смелым и уверенным
- Способность к нестандартным действиям (слушать свою интуицию и понять, что на уровне логики твои всегда могут легко просчитать)
- Здоровый образ жизни, стабыльные семейные ценности (когда книга писалась Трамп был женат первый раз и было 3 детей, а теперь wiki Однако 3 жены и 5 детей не помешали его финансовому успеху )
- Знание своего дела (это даже для минимального успеха в жизни обычно нужно :) )
- Выбор лучших в свою команду ( как для строительства небоскрёба в Нью Йорке или казино в Атлантик-сити, Трамп всегда выбирал лучших)
- Всегда всё чётко просчитывать и укладываться в срок (а это полезно для любых проектов и по тестированию в том числе)
В целом впечатления приятные, ощущение, что погрузился в жизнь Нью Йорка. Там царит и жадность и наглость и глупость и есть Трамп с его философией и целеустремлённостью.
Есть его Trump Tower , что он построил, а теперь тут и работает и живёт.
Даже возникло желание посмотреть на New York воочию :)
Дональд Трамп (искусство заключать сделки)
К тестированию книга также отношения не имеет, но может полезна для развития личных и профессиональных качеств тестера.
Без формальностей излишних сразу отмечу те моменты, что важны для каждого в цели достижения своих целей ( у Трампа - это были сделки)
- Целеустремленность и упорство (не раз и не два суд, миниципалитет, элитный клуб отвечал ему нет или просто его игнорировал. Трамп же не сдавался и пытался и пытался)
- Никогда не пробосать своё дело (Выбрал цель и стремись к ней, нельзя всё время отрываться на другое, потом на третье. Так ничего и не достигнешь)
- Уметь ждать своего случая
- Всегда сдавать сдачу (если хочешь достичь в жизни высоких целей, не надо бояться быть зубастым и защищать свои интересы)
- Быть смелым и уверенным
- Способность к нестандартным действиям (слушать свою интуицию и понять, что на уровне логики твои всегда могут легко просчитать)
- Здоровый образ жизни, стабыльные семейные ценности (когда книга писалась Трамп был женат первый раз и было 3 детей, а теперь wiki Однако 3 жены и 5 детей не помешали его финансовому успеху )
- Знание своего дела (это даже для минимального успеха в жизни обычно нужно :) )
- Выбор лучших в свою команду ( как для строительства небоскрёба в Нью Йорке или казино в Атлантик-сити, Трамп всегда выбирал лучших)
- Всегда всё чётко просчитывать и укладываться в срок (а это полезно для любых проектов и по тестированию в том числе)
В целом впечатления приятные, ощущение, что погрузился в жизнь Нью Йорка. Там царит и жадность и наглость и глупость и есть Трамп с его философией и целеустремлённостью.
Есть его Trump Tower , что он построил, а теперь тут и работает и живёт.
Даже возникло желание посмотреть на New York воочию :)
Подписаться на:
Сообщения (Atom)