четверг, 18 июля 2013 г.

Книжная полка. С. Архипенков "Лекции по управлению программными проектами"

Под размеренный стук колес поезда по дороге в Санкт-Петербург, прочитал Сергея Архипенкова, "Лекции по управлению программными проектами". Замечательная, "скромная" по своим размерам книга, которая читается на одном дыхании. 




Технико-тактические характеристики:
Год издания: 2009
Страниц: 127
Скорость чтения - выше среднего
Ориентировочное время на прочтение: 2,5 - 4 часа

Отмечу, книга находится в свободном доступе на сайте автора - http://www.arkhipenkov.ru/resources/sw_project_management.pdf, поэтому рекомендую скачать и положить ее себе на смартфон или ноут, когда у вас будет немного свободного времени. А прочитать действительно стоит ведущим тестировщикам, тест-лидам и начинающим тест-менеджерам. Полагаю, и "продолжающие" ТМ'ы могут обнаружить в книге что-то новое для себя. Для тех, кто только начинает знакомство с управлением проектами, книга будет в самый раз, и вот почему:
  • Небольшой объем: можно стартовать с "энциклопедического" , который предлагают многие книги, но есть риск увязнуть в частностях, возможно, даже не применимых к управлению именно программными проектами. Поэтому универсальные книги по менеджменту хороши, но требуется адаптация под IT.
  • Простота и доходчивость: живой и понятный язык, особенно когда автор объясняет технические вещи, некоторые методики.  
  • Полезность: автор выделил самое важное, дорабатывал материал после чтения этого курса на корпоративных тренингах, обратной связи от слушателей. Плюс, большой реальный опыт автора работы в управлении проектами (более 30 лет).
  • Структурированность: книга - настоящий конспект-путеводитель с разбиением тем, пунктов, графиками, в конце каждой главы вы найдете дополнительную литературу для углубленного изучения. 
Книгу лучше читать от начала и до конца, нет смысла "сокращать" на и так небольшом объеме и большой концентрации полезности :) В дальнейшем - можно обращаться к конкретным главам как напоминание.

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

среда, 10 июля 2013 г.

Обзор 5. Джеймс Бах "Идем неуклюжим, неровным шагом"

Продолжаю серию постов-обзоров, на этот раз "внеплановый" доклад от Джеймса Баха "Идем неуклюжим, неровным шагом" (James Bach - A Galumping We Go).

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

You all do a galumphing, but probably none of you had a word for it or an explanation, why you do it.

Как часто мы пробуем только простые, линейные тесты на проверку функционала? Да, они находят очевидные и очень важные баги. И только. Можно делать одну и ту же вещь, но по-разному. Первый способ - прямые, отточенные до автоматизма движения, с применением минимально возможного набора сил и средств, как прямая между пунктами A и B - кратчайшее расстояние между двумя точками. Второй - тот же путь из А в B, но "неправильный", на первый взгляд: непонятый, непоследовательный. Вопрос: зачем нужен второй способ, если есть "эффективный" первый? Возможно, при поездке да, но не в тестировании. Джеймс Бах отвечает на этот вопрос определением ниже ( в своих лекциях, заметках, книгах, Бах не раз говорит о том, что тестирование ПО - это не только набор исчерпывающих тестовых процедур  как, например, проверка заявленного спецификацией цвета: можно сказать словами Майкла Болтона: Testing Dominates Checking)

Galumphing – A style of test design and execution whereby inert variations in test procedure are used to find unanticipated and potentially important bugs.
(перевод: Galumphing - метод тест-дизайна и выполнения тестов, при котором малые вариации выполнения тестов используются для нахождения непредвиденных и потенциально важных багов)

Доклад - просто must see для тех, кто не только пишет и выполняет тесты, но и исследует свой продукт, находит новые баги в старых кейсах, пробуя сделать что-то "не так".

Видео доклада:

Конспект:

  • You all do a galumphing but probably none of you had a word for it or an explanation, why you do it.
  • "Only variety can destroy variety" Ashby's law -> for testing purposes "Only variety can explore variety"
  • Lack of variety = Lack of control
  • Testers are all about exploring the leaky abstractions called specifications
  • If you only have a push button you have to introduce complexity some other way
  • Ways to insert variety injection: micro-behaviors, randomness, data substitution, platform substitution, time/concurrency varations, scenario variation, state pollution, sensitivities and expectations (18:54)
  • The requisite variety that opens up our expressive possibilities comes from practice, play, exercise, exploration, experiment.
  • If you are trying to test an actual product of a kind we test, no explicit set of procedures can ever be enough. That's why we must explicit Ashby's law to inject variety not only of intended kind but of unintended kind.
Ссылки на обзоры этого выступления в других блогах:

пятница, 5 июля 2013 г.

Обзор 4. Никита Постолакий "Разработка тест кейсов по методике pairwise"

И опять - продолжение серии постов-обзоров. Доклады в подборке получаются разноплановые: были на русском и на английском, доклад-пазл с набором фишек для тест-менеджера, классический от гуру, story-telling... Теперь посмотрим мастер-класс по тест-дизайну с конференции SQA Days 11.

Сегодня у нашей рубрики виртуально в гостях Никита Постолакий "Разработка тест кейсов по методике pairwise". Pairwise testing или техника тестирования попарных комбинаций - один из методов черного ящика, применим для оптимизации количества проводимых тестов.

Однозначно must see для тест-дизайнеров, отличный доклад, будет полезен для ознакомления с этим замечательным методом, его применением и использованием одной из возможных бесплатной специальной тулы для моделирования тестов по pariwise - PICT. Полный список тулов для pairwise можно найти, например, здесь.

Еще к плюсам выступления Никиты можно отнести подачу материала в доступной форме, с ответами на вопросы прямо по ходу доклада. И еще, кроме самого pairwise, интересен сам процесс программирования модели из полученных входных данных.

Pairwise использует предположение (по докладу - исследование IBM), что к 97%  ошибок в ПО приводит взаимодействие всего двух параметров между собой. Поэтому, в случае если у вас, например, 3 параметра, у каждого из них 4, 5, 7 возможных значений соответственно, то не всегда имеет смысл проводить полный перебор всех возможных триад-комбинаций, количество которых в нашем примере равно 4 * 5 * 7 = 140. А что, если параметров не 3, а намного больше? А если увеличить не только количество параметров, но и возможных значений? Полный перебор займет очень много времени, и будет не очень эффективен в плане нахождения всех ошибок, так как...


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

В заключение, я дам вам еще несколько полезных ссылок на источники по pairwise-тестированию:

  • http://www.amibugshare.com/pict/help.html - инструкция по PICT
  • Доклад Алексея Баранцева на осенней Confet&QA-2012
  • Книга Рекса Блэка "Advanced Software Testing - Vol. 1", раздел 4.3.
  • http://hexawise.com - Сайт для генерации тестов по pairwise, довольно удобная альтернатива PICT. Очень удобная встроенная система обучения пользованию этим сайтом, рекомендую к прохождению.


Видео доклада:

Конспект:


  • "К 97%  ошибок в ПО приводит взаимодействие всего двух параметров между собой" - исследование IBM
  • Предварительная оптимизация данных: классы эквивалентности + граничные значения
  • При добавлении сложных условий для пар - используем тулы (автоматизируем генерацию пар)
  • Алгоритм разработки модели pairwise: сбор входных данных, оптимизация данных, описание зависимостей, автоматическая генерация тестов
  • Требования к pairwise-инструменту: условия, типы данных, алиасы, негативные тесты, приоритизация (предпочтительные значения, наиболее приоритетные для проверки), регрессионные наборы (повторное использование при расширении набора)
  • PICT, построение модели

Презентация доклада:

понедельник, 1 июля 2013 г.

Рубрика "ПочитайQA". Полезные ссылки за июнь-2013

Продолжаю традиционную рубрику "ПочитайQA" - список интересных ссылок за июнь. Предыдущая майская подборка - здесь.

Несмотря на летний период и мой двухнедельный отдых, прошедший месяц оказался для меня весьма продуктивным, блог развивается, растет. Спасибо большое за вашу обратную связь и предложения по улучшению. Если вам есть что сказать, спросить, пожелать, пишите - ladutko_andrey[собачка]tut.by.


Quality Assurance.


Studying.



Gamification.


Many other.


Books.


Хорошего вам отдыха, если у вас он впереди, и интересной продуктивной работы, если вы сейчас в офисе! Но даже в "офисном" графике пожелаю вам найти время, чтобы "перезарядить батарейки" :) Summer is in the air! Enjoy!