Когда код «убивает», или зачем нам тестировать наши...

Когда код «убивает», или зачем нам тестировать наши продукты

Стрекаловский Олег

«R-Style Softlab»

Конференция «WebDev», Вологда

4 апреля 2015 г.

2

Как мы обычно делаем ЭТО

3

•Сформировали требования


4


•Побежали пилить


5




•Пилим, пилим, пилим, …

6





•Наступает период ПСИ

7






•Конечно, внезапно обнаруживаем проблемы и недоработки в ТЗ!

8






•Конечно, внезапно обнаруживаем проблемы и недоработки в ТЗ!

Welcome To The Hell ;-)

Менеджеры

10

Тем временем у программистов …

11

Continues цейтнот у ручных тестировщиков

12

Внедренцев становится жалко

13

Наш «счастливый» клиент

14

Основная проблема разработки ПО

16

«Я опасаюсь, что мы потерпелипоражение в борьбе со сложностью систем»

Эдсгер ВибеДейкстра

Основная проблема разработки ПО

17

Почему вы не заботитесь о качестве вашего продукта?

18

Почему вы не заботитесь о качестве вашего продукта?

19

«В нашем продукте нет ошибок!»

20

Работаете с железом?

21

Управляете объектами в real-time?

22

Защищаете приватные данные?

23

Автоматизируете предприятия?

24

Работаете с диском пользователя?

25

Работаете с диском пользователя?

26

Создаете приложения с UI?

27

28

Game Dev?

29

Game Dev?

«Мы их всему научим, а они потом уйдут.»

30

«Мы не знаем, как этим эффективно заниматься.»

31

Путь к созданию надёжного ПО

32

33

•Осознание наличия проблемы


34


•Изучение опыта индустрии


35

Тематические каналы YouTube

36

Конференции

37

Книги

38


•Внедрение «Best Practices»:•Code Review•Автоматизация тестирования•Парное программирование



39


•Внедрение «Best Practices»:•Code Review•Автоматизация тестирования•Парное программирование


•Изменение подхода к написанию кода?!


40

TDDALL CODE IS GUILTY

UNTIL PROVEN INNOCENT

Test Driven Development

TDD за 1 минуту

41

TDD дает кучу плюшек!

42


43

•Быстро находим ошибки


44

•Не боимся рефакторить код



45


•Актуальная документация



46




•Меньше over-engineering’a


47





•Более удобный для клиента API


48





•Более удобный для клиента API

•Интрига при каждом запуске тестов

TDD – это хорошо, а с Agile – ещё лучше!

49

AgileTDD

Что нам всем даст тестирование

50


51

•Хороший код - программистам


52

•Много автотестов - тестировщикам



53



•Нормальную жизнь - внедренцам


54




•Уверенность - менеджерам


55




•Уверенность - менеджерам

•Непоправимое счастье – клиентам!

Выводы

Приложения ХардварФреймворки

Библиотеки Middleware

UI

57

58

Профессиональный подход

59

1. Найдите для своего языка, фреймворкаинструменты тестирования (unit-тестирование, функциональное и т.д.).


60


1. Если готовых нет – плохо искали напишите сами, заопенсорсите!


61



2. Если готовых нет и не можете их написать –не используйте этот язык или фреймворк!


62




2. Пишите тесты для вашего приложения.


63




2. Пишите тесты для вашего приложения.3. Автоматизируйте их прогон для получения быстрой

обратной связи.


64





обратной связи.4. ???


65





обратной связи.4. ???5. PROFIT !


Тестирование – вот наш путь!

66

Начни сам и убеди начать других!

67

Личное обращение

Дяденьки и тетеньки, вы вместо очередного %bullshit%.js,лучше попишите тестов для вашего продукта, пожалуйста, а?

68

Спасибо за внимание!Вопросы?

[email protected]

slideshare.net/ssuser3c5f11

olegstrekalovsky.blogspot.ru

o.strekalovsky

Когда код «убивает», или зачем нам тестировать наши...

Education