Русский
Конференции для профессионалов индустрии информационных технологий

Мартыненко Сергей

Преподаватель
нет
Россия
Москва

Биография:

Первую программу написал в 1986. Выполнял роли: программиста, эникейщика, тестировщика, проектировщика интерфейсов, руководителя проектов и т.д.

Продолжаю писать "Байки для оруженосца".

Доклады

Жестокое обращение с ошибками в требованиях на глазах у публики

06.01.2017

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


Но.


Как только доходит до практики, требования часто просто не выверяют (а иногда и не читают). Если же доходит до выверки, то обычно все заканчивается проверкой орфографии и пунктуации. И потом ошибки попадают к конечному пользователю. Почему? Причин этому много. Первое – это психология. Здесь и «это придумано не у нас» и разные контексты мышления и многое другое. Второе это отсутствие описанных техник верификации. Литературы и тренингов по написанию требований довольно много, а вот по верификации практически нет.


На мастер-классе будут рассмотрены:

* психологические барьеры, мешающие верификации;

* техники верификации;

* пример верификации юзкейса, присланного участником сообщества uml2.ru.


Мастер-класс является частью моего тренинга по написанию и верификации требований.

Уровень сложности
Мастер-класс (1 ч 30 мин)

Подготовка стратегии тестирования под высокорискованный, высокодоходный проект

09.10.2015

Бизнес-сценарий который будет рассмотрен: 
1. Инновационный проект.
2. Более половины таких проектов не взлетает.
3. Те, которые взлетают, приносят миллионы в неделю. Не рублей.  Каждая лишняя неделя разработки - это многомиллионные потери. Приоритет – скорость. 
4. Ошибка в системе, подобная описанной в "данетке для разработчика" (http://goo.gl/xJfVcj), может сделать фирму банкротом в течении часа. 

В ходе доклада будет: 
  • Рассмотрен обобщенный алгоритм построения стратегии тестирования.
  • Подробно показано, как выстраивается фасет за фасетом стратегия и как улучшается поток в целом для конкретного случая. 

  • Также будет показано отличие стратегию от не стратегии.

Целевая аудитория доклада 
  • В первую очередь тестменеджеры. Им это нужно, потому что им писать и отстаивать стратегию тестирования. 
  • Руководители проектов. Им согласовывать стратегию тестирования с общей стратегией разработки. 
  • Рядовые тестировщики. Им это нужно для понимания и приятия стратегии. 

Уровень сложности доклада очень высокий.

Уровень сложности
Секционный доклад (40 мин)

Стратегии тестирования. 42 способа сделать ваш проект успешнее

11.01.2014
СТРАТЕГИЯ [strategy] (в исследовании операций) — способ использования средств и ресурсов, направленный на достижение цели операции. С. определяется принимаемыми значениями управляемых переменных. Для выбора этих значений важно знать также условия “внешней среды”, т. е. значения неуправляемых переменных. В многошаговых процессах сам способ может меняться, в этом случае С. определяет правила принятия дальнейших решений (т. е. выбора траектории) на основе получаемой на каждом этапе информации о ходе процесса и изменениях среды. Задача исследования операций, как правило, состоит именно в выборе оптимальной из числа альтернативных С. (альтернатив) на основе того или иного критерия. От научного, перейдем к обыденному пониманию. Стратегия - это приоритезация видов действия, направленная на достижение результата с наименьшими затратами. Так например, атака укрепленной позиции противника во второй мировой войне могла предполагать следующую последовательность шагов: предварительное разминирование, артподготовка, совместная атака пехотой и танками. Применение тех же шагов в обратной последовательности приведет к увеличению потерь на достижение того желаемого результата. Точно так же, выбор правильной стратегии тестирования способен увеличить эффективность тестирования в разы. Верно и обратное. Я был свидетелем, как неверная стратегия тестирования привела к уменьшению эффективности в десятки раз. Собирать и классифицировать материал к этому докладу я начал в 2001 году. Практически все стратегии, о которых я буду говорить я применял в своих проектах или наблюдал их применение вживую. Так же анализировал границы их применимости. Насколько я знаю, ничего подобного этой классификации на постсоветском пространстве нет. И еще момент. Это не доклад о том, как проектировать тесты. И не о том, какие тесты нужно провести. Это доклад о том, какие ошибки искать в первую очередь, какие в последующую. Ну, или, если хотите, в какой последовательности выполнять тесты и о том, какие тесты можно/ нужно не выполнять совсем. Доклад будет полезен всем, начиная со стажера, но по настоящему полезным (возможность применять «из коробки») он будет тем, кто завел и проанализировал по несколько тысяч дефектов.
Уровень сложности
Секционный доклад (40 мин)