Есть ещё порох в пороховницах.

Раздумываю вернуться к творчеству и вновь начать описывать свой опыт разностороннего развития... )

За 2 с половиной года c момента последнего поста я достаточно сильно продвинулся по основной (тестирование) и побочной (развиваться во все стороны) сферам

Купил Kindle и прочитал много книг по тестированию, IT, менеджменту и психологии. Также прочитал давно интересовавшую книгу James Bach, там меньше про тестирование и больше про подход к жизни, но это тоже заслуживает отдельного поста.
Посетил ряд тренингов и прослушал ещё больше как тренингов, так и подкастов по разнообразным сферам жизни.

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

Цели буду преследовать как и раньше достаточно эгоистичные, задокументировать свои знания  и самодисциплинировать себя. Если это будет интересно и читателям, тогда отлично.

До встречи,
Антон

Lessons learned in software testing (book)

Всё так и не начал запланированный конспект по книге Rex Black, но уже решил написать про следующую прочитанную english book.

Кстати, почему её так и не перевели на русский, для меня остаётся секретом. Книга очень достойная и до сих пор (издана в 2002) держится топ-листе на amazon.com Думаю, этот показатель явно указывает на качество книги.

Ну да ладно, у меня то она есть в оригинале и трудностей с её освоением не обнаружилось. Читается легко с одной стороны и даёт много пищи для ума с другой. 

Суть: авторы представляют на суждение читателя 293 урока (немного не дотянули до красивой цифры в 300 :) ).

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

В отличии от предыдущих мною прочитанных книг, здесь очень много конкретики и всё по делу. 

Вообще в предисловии к книге советуется читать книгу как бокал дорого вина, постепенно, раздумывая о насущном, и наслаждаясь процессом. И это очень верно. Я же конечно прочитал залпом и теперь вынужден всё время возвращаться. Много всего от быстрого чтения осталось за бортом и теперь приходится возвращаться и перечитывать и переосмысливать. 

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

Lesson 24 -- All tests are an attempt to answer some question. 

Интересно, а если тест уже прогонялся много раз, нужен ли мне теперь ответ на этот вопрос. И правильную ли я стратегию задавания вопросов выбрал?

Итак каждый вопрос заставляет задуматься и постараться переложить на собственный проект. В этом и смысл защищаемой авторами концепции Context-driven-approach. Контекст у всех свой, поэтому уроки носят общий характер и каждый делает свой собственный вывод.

На сегодня всё, постараюсь писать чаще. 

В данный момент я уже почти закончил читать Testing computer software, так что обзор тоже по нему будет. Так же на просторах сети нашёл бесплатный видео курс по black box software testing от авторов Lessons learned in software testing. Качество видео не ахти, но интересно http://testingeducation.org/BBST/index.html. Пока только начал, так что воздержусь от конечных оценок.

Software testing books

Пока я так и не собрался с конспектами двух прочитанных книг. Но зато я уже начал читать новые книги :) В этот раз я пока ничего не покупал и нашёл интересный ресурс, гже есть много полезных для тестеровщиков книг.  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

Так что продолжаем тестировать и развиваться!

I'm back. + testing podcasts

Дамы и господа.
Наконец я собрался и буду опять продолжать работу по разбору книг и прочих материалов по тестированию. Отсутствовал я по объективно-субъективным причинам. Болел, работал, сдавал на права и ездил в США в командировку.
Книги, что я заявил прочитать, я прочитал. Так что с меня просто конспект прочитанного и оценка. Для меня этот конспект полезен будет, да и для вас надеюсь тоже.

Если кратко, то обе книги мне понравились.( Lessons learned in software testing and Managing testing process. )  Потянуло ещё читать про тестирование дальше.

Для себя за это время открыл подкасты по тестированию на английском.
http://codingqa.com/ - интересные ребята. Главный приоритет отдаю передаче 28, где участвует James Bach. Хотя сам всё конечно не слушал и многое только собираюсь.
http://testingpodcast.com/ тут тоже можно найти интересное, но как-то они не особо активны в этом году.

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

После предварительной оценки проекта и рисков по тестированию самое время переходить к написанию тест плана или планов, что советует 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.

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