"Зачем мне знать язык, я же не на диктанте"
"Зачем мне учить математику, я же не в магазине"
К сожалению, это очень часто слышно на улице.

А ещё я регулярно слышу фразы в духе "Ну, я тестировщик, мне тут математика ваша не нужна".

Нужна.

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

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

2. Вам как рекрутеру или HR надо нанимать тестировщиков в команду.
Но вы не понимаете кто вам нужен. 

3. Вы планируете выбрать курсы или создать их.

4. Вы просто хотели бы понять, как ложится прочитанная вами теория на практику. 

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

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

Всем привет! В своём докладе я расскажу вам об одном из подходов к процессу тестирования, который можно назвать Testing As Service. Скорее всего, вы уже слышали об этом или где-то читали: при этом подходе отдел тестирования не очень сильно зависит от отдела разработки, но, внезапно, этим решается проблема загруженности.

Всем привет! 

Это продолжение моего доклада про вредные привычки в тестировании. 

Допустим, мы извлекли урок из прошлого доклада. Но, ведь, мы работаем не одни, а с людьми. 

Управляем мы, управляют нами. 

Я расскажу вам про вредные привычки в тест-менеджменте, которым стоит научиться. 

Приходите. 

Я научу вас плохому.

Второй акт.

В своём докладе я расскажу о такой, казалось бы, очевидной вещи, как "Авторский контроль".
Бывало ли у вас такое, что всё сделали по ТЗ, учли все спеки, протестировали и всё хорошо...?

Но получается полный отстой.

Как этого избежать?

В своем докладе я расскажу вам о такой практике как "Авторский контроль", как и когда и зачем её применять.

Но на самом деле, вы и правда все это делаете. Просто ещё не знаете.

Человек устроен так, что учится только тому, к чему лежит душа. Из-под палки не научишь. Нужно давление. 

Но это не наш метод, Шурик.

Как показывает история человечества, человек лучше всего предается саморазрушению и падению в пучины порока и хаоса.

Так и в тестировании. 

Не все стремятся достигать высот, оставаясь беленькими и чистенькими.

В своем докладе я научу вас некоторым "вредным" привычкам, которые облегчат вашу жизнь как тестировщиков и тест-менеджеров.

Добро пожаловать на темную сторону. 

Я научу вас плохому.

Было рассказано очень много саксесс-стори о том, как создать отдел или наладить процессы. Но я не люблю истории успехов. Поэтому в докладе пойдет речь о типичных ошибках, которые совершал я и другие руководители. Все примеры будут взяты из моей практики на предыдущих местах работы. В полной яда и ненависти форме вам будут представлены несколько «грешков», которые так любит совершать наше с вами руководство. Это поможет вам понять, как самим не попасть в подобные ловушки. Внимание! Все совпадения не случайны.

В своем докладе я расскажу о том что такое BDD и как с помощью Gherkin автотесты сможет писать даже тот, кто никогда не занимался программированием. Ведь это так заманчиво, когда автотесты заранее может писать даже проектировщик!

Давным давно я поделил для себя все доклады на две части. 

1. Сферическая методология в вакууме

2. Смотрите как это реализовано у нас. 

 Я решил сделать свой доклад по второму варианту. В своём докладе я познакомлю вас с одним из возможных способов ведения разработки и тестирования вёб-интерфейсов. Покажу что такое git issues, расскажу о реализованной схеме деплоев и continious delivery. Этот доклад - своеобразный отчет о проделанной работе. Не обойдётся и без животрепещущих капитанских вопросов: 

• Как припеваючи жить без баг-трекера и зачем нужно дружить с проектировщиками? 
• Преимущества обработки пулл-реквестов через L.I.F.O.? 
• Что такое L.I.F.O.? 
• "ФФФФ" - что это и зачем? 
• Как избежать накопления реликтовых залежей из пулл-рекветов по методике "ПВО"? 
• CD руками тестера - зло или благо? 
• Нужно ли кормить программистов по ночам? Если да, то зачем? 
• Сисадмины экстраверты - добро или зло? 
• Гибкое планирование- как это реализовано у нас. 

 Жду вас на своем докладе!

Кто из нас не сталкивался с ситуацией, когда реализованные требования Заказчика оказываются совсем не тем, что ему требовалось? Из-за чего реализацию приходится многократно переделать, если не выбрасывать. В докладе мы расскажем о построении отношений с Заказчиком, нацеленном на решение его проблем, а не на отработку требований. Это не просто рассказ о том, как вам жить, - доклад построен на реальных кейсах, возникающих при взаимоотношениях с Заказчиком. Предложим методы построения отношений, разберем сочетание неформальных и формальных коммуникаций, а также вопросов стоимости и оплаты работ. Еще мы затронем психологическую составляющую на разных этапах проекта. Без этого никак, ведь совместная работа предполагает не формальное взаимодействие, а коммуникации и сотрудничество, с перспективой построения партнерских отношений для совместного создания value. В соавторстве с Андреем Мясниковым и Риной Ужевко.