Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

9 кругов Ада: антипаттерны UI-Автоматизации

704 views

Published on

Доклад Антона Семенченко на SQA Days-22. 17-18 ноября 2017. Санкт-Петербург, Россия
www.sqadays.com

Published in: Education
  • Be the first to comment

  • Be the first to like this

9 кругов Ада: антипаттерны UI-Автоматизации

  1. 1. 9 кругов Ада: антипаттерны UI- Автоматизации Антон Семенченко
  2. 2. О себе Founder of communities www.COMAQA.BY, www.CoreHard.by, www.InterIT.by, www.ITUp.by; co-founder of company www.DPI.Solutions, CSO; «tricky» manager at EPAM Systems. 15+ years of experience in IT, main specialization: Automation, С++ and lower development, management, sales
  3. 3. COMAQA.by • Community’s audience Students looking for perspective profession Testing specialists (manual and automated) Automation tools developers Managers and sales specialists in IT IT-specialists, thinking about migrating to automation. • Community goals Create unified space for effective communication for all IT-specialists in the context of automated testing.
  4. 4. COMAQA.by • Your profit Ability to listen to reports from leading IT-specialists and share your experience. Take part in different educational activities as a lecturer, mentor and listener mentee. Take part in COMAQA be-weekly Morning Coffee and COMAQA Open Air: rafting, kayak, camping trip and other activities combined with QA related education. Become a part of Open Source community with COMAQA help. Propose personal solutions Start ups directly or indirectly connected to QA, find soulmates and like-minded people for implementing ideas. Meet regularly, at different forums, community «offices», social networks and messengers.
  5. 5. COMAQA.by • Email: info@comaqa.by • Skype: dpi.Semenchenko • https://www.facebook.com/comaqa.by/ • http://vk.com/comaqaby • https://www.youtube.com/channel/UCzAhXR53eIvHht9qmFPBVxg • https://twitter.com/comaqa • +375 33 33 46 120 • +375 44 74 00 385
  6. 6. CoreHard.by • Community’s audience «Harsh» С++ developers & co, IoT, BigData, High Load, Parallel Computing Automation tools developers Managers and sales specialists in IT Students looking for perspective profession. • Community goals Create unified space for effective communication for all IT-specialists in the context of «harsh» development.
  7. 7. CoreHard.by • Your profit Ability to listen to reports from leading IT-specialists and share your experience. Take part in different educational activities as a lecturer, mentor and listener mentee. Propose personal solutions Start ups directly or indirectly connected to QA, find soulmates and like-minded people for implementing ideas. Meet regularly, at different forums, community «offices», social networks and messengers. .
  8. 8. CoreHard.by • Email: info@corehard.by • Skype: dpi.Semenchenko dpi.Naumovich • https://www.facebook.com/corehard.by/ • http://vk.com/corehardby • https://www.youtube.com/channel/UCifgOu6ARWbZ_dV29gss8xw • +375 33 33 46 120 • +375 44 74 00 385 • +375 29 770 95 82
  9. 9. InterIT.by • Community’s audience IT specialists relocated to Belarus. • Community goals The goal of the new community InterIT – is to create a space for effective communication of IT-specialists in the context of relocation and adaptation in Belarus. Help colleagues find answers on 3 main groups of questions about relocation: support of international employees, tourism and recreation, social connections. And also, to spend time with pleasure, organize a lot of informal entertainment for you and you dates.
  10. 10. InterIT.by • Your profit Support of international employees, tourism and recreation, social connections. spend time with pleasure, organize a lot of informal entertainment for you and you dates.
  11. 11. InterIT.by • Email: info@interit.by • Skype: dpi.Semenchenko r.n.soroca • https://www.facebook.com/InterItby-1980118052264615/ • https://www.youtube.com/channel/UCe_UO8lZxZNxzV- akjjLWbA • +375 33 33 46 120 • +375 44 74 00 385
  12. 12. ITUp.by
  13. 13. DPI.Solutions • Trainings http://dpi.solutions/education?name=testing-strategy http://dpi.solutions/education?name=roi-for-automation-testing http://dpi.solutions/education?name=metrics-in-testing .
  14. 14. Олитературеный план беседы  1. Алгоритм «Как избежать грехов UI Автоматизации тестирования» 2. Критерии переходов для поиска точки баланса в данный момент 3. Структура паттернов антипаттернов рассмотренная сквозь понимательно – литературную греховную призму с яркой ноткой инкапсуляции  4. Что дальше? 
  15. 15. План беседы 1. Инкапсуляция – как основной единственный  принцип ООП 2. Инкапсуляция2  – как эффективный способ «классификации» Design Patterns (в том числе «процессных» ) 3. Рефакторинг по Фаулеру и Кириевски – как критерий перехода 4. Минимальный полный спектр теоретической информации
  16. 16. План беседы 5. Алгоритм best practices + сквозная нумерация 6. Страстный призыв «Думай» 7. «Горячая» проверенная временем метафора 8. Новый взгляд на Гемификацию 9. Символ  10. Список видео аудио литературы
  17. 17. Условная категоризация 1. Концептуальные 2. Процессные Организационные 3. Уровня взаимодействия с бизнесом 4. Уровня Архитектуры 5. Уровня Дизайна 6. Человеческий Капитал 7. Гибридные
  18. 18. Условная категоризация - «человеческий фактор» 1. Концептуальные 2. Процессные Организационные 3. Уровня взаимодействия с бизнесом 4. Человеческий Капитал 5. Гибридные
  19. 19. Условная категоризация – тех. составляющая 4. Уровня Архитектуры 5. Уровня Дизайна
  20. 20. Контекст
  21. 21. Примеры 
  22. 22. «Викторина» от COMAQA  Тот, кто первым пришлет на info@comaqa.by правильный ответ на вопрос «Почему докладчик использовал картинку с Советско- Вьетнамской дружбой в контексте примера-задачи» - получит абонемент на посещение всех конференций сообщества COMAQA в течении 2018 года, вне зависимости от страны города формата. Спасибо за участие, коллеги! PS: Правильный ответ несколько раз звучал в других выступлениях докладчика
  23. 23. Theoretical fundamentals
  24. 24. 1. Page Objects – encapsulates the way of identification and logical grouping of widgets. 2. Page Object == Logical Page 3. Page Object != Physical Page Page Object – just to “refresh”
  25. 25. Page Object – “example” 
  26. 26. Page Object – “example” 
  27. 27. 1. Let’s compare: • Photo • Share – looks like parallelism (easy parallelism). • Video • Share – looks like parallelism (not trivial parallelism). State-less or state-full solution?
  28. 28. 1. How easy transform solution from “single” to “multi” threading (to decrease “QA Automation Windows”) • State-less – like share a photo • Just 5 minutes of work. • State-full – like share a video • Not trivial task, could be a night mare. 2. Summary • prefer state-less solutions to state-full solutions in mooooost cases; • before start implementation a state-full solution, please, take a break for a minute, and re-thing everything again, possibly you can find a proper state-less solution. State-less or state-full solution?
  29. 29. 1. Static class • could be implemented as a state-less solution easily 2. Object • State-full solution in 99,99% cases 3. Summary • prefer static class based solutions (state-less) to object based (state-full) in mooooost cases; • before start implementation based on objects, please, take a break for a minute, and re-thing everything again, possibly you can find a proper solution based on static classes. Object or static class State-full or state-less solution?
  30. 30. 1. Too complicated business logic due to Domain 2. Too complicated business logic due to System size (thousands test-cases) 3. Too many “contexts” • Browser versions • Environments • Customers with a tiny nuances of functionality • Platforms (cross-browser Web plus cross-platform Mobile) • Combination  4. Combination  Page Objects – state-full, general case
  31. 31. 1. Web UI that behaves like a Wizard 2. Web UI in combination with Mobile in one use case 3. Internet of Things (in most cases) 4. More then 1 page during 1 test (for example several portals or several instances of one portal to implement one “business use case”): • Really seldom; • Looks like integration tests (in most cases): • Std solution- some type of “Unit” Tests or “White Box” Testing (terminology question). 5. Many others “special cases” Page Objects – state-full, special cases
  32. 32. How to select a proper PO implementation?
  33. 33. 1. 30 Physical Pages 2. Standard Header, footer and search functionality for all physical pages 3. Each Physical Page consists of • Header – H • Footer – F • Search – S • Some functionality, specific for the Page – U (unique) Hypothetical project context – to compare
  34. 34. 1. 33 Static Page Objects = Logical Pages 2. 0 explicit and 30 implicit Physical Pages 3. Just share 33 Static Page Objects between 30 implicit Physical Pages • For example, Header Static Page Object (static class) is used in test cases for all 30 Physical Page Objects 4. Complexity – just 33 static state-less entities (plus limitations due to state-less solutions) Compare complexity – Static Page Object based
  35. 35. 1. 33 Dynamic Page Objects = Logical Pages 2. It depends on implementation (one of the ways): • 0 explicit and 30 implicit Physical Pages • implicit Physical Page implements on Action layer (limitations example) • Action for Physical Page aggregates all necessary Dynamic Logical Pages • Physical Pages are implemented in a next way: create all necessary instances of logical pages, aggregate in some way, use Action layer as a point of aggregation in most cases, free resources Compare complexity – Dynamic Page Object based (option 1)
  36. 36. 1. 120 objects (min), each with some state, dynamically created and frees to implement necessary behavior - to implement 30 implicit Physical Pages 2. Complexity – 120 dynamic, state-full entities min (plus some limitations due to state-full solution implementation nuances) Compare complexity – Dynamic Page Object based (option 1)
  37. 37. 1. 33 Dynamic Page Objects = Logical Pages 2. It depends on implementation (another way): • 30 explicit Physical Pages • Multiple Interface inheritance • Combine Page Objects and Actions layer (at least low level actions, in most cases) • Action-Physical Page (low level actions, sometimes “business” actions or both plus limitations example) • Implements all Logical Pages interfaces using aggregation and “delegation” • Aggregate all Dynamic Logical Page Objects • Create and frees resources (Dynamic Logical Page Objects) Compare complexity – Dynamic Page Object based (option 2)
  38. 38. 1. 150 objects, each with some state, dynamically created and frees to implement necessary behavior - to implement 30 explicit Physical Pages 2. Complexity – 150 dynamic, state-full not trivial entities with a multiple interface inheritance (plus some limitations due to state-full solution implementation nuances) Compare complexity – Dynamic Page Object based (option 2)
  39. 39. 1. Can be used together with next Design Patterns Approaches • Action (both static – preferable and dynamic) • Key-word driven • DSL – external only • BDD – partially, it depends on exact BDD engine implementation limitations 2. Can’t be used together with next Design Patterns • Factory • Flow (Fluent Interface) • Navigator (for Web) Compare “tech” limitations - Static Page Object based
  40. 40. 1. No limitations, but … • For example, in most cases it’s hard to isolate Action and Page Objects layers Compare “tech” limitations - Dynamic Page Object based
  41. 41. 1. (-) Too complicated business logic due to Domain 2. (-) Too complicated business logic due to System size (thousands test-cases) 3. (-) Too many “contexts” • Browser versions • Environments • Customers with a tiny nuances of functionality • Platforms (cross-browser Web plus cross-platform Mobile) • Combination  4. (-) Combination  Compare “business” limitations - Static
  42. 42. 1. State-less approach - you have a conditional that chooses different behavior depending on … 2. Solution to simplify the project – refactoring “Replace Conditional with Polymorphism” 3. Polymorphism = object = State-full approach Rationale “business” limitations – Static (Transformation)
  43. 43. 1. “From Refactoring to Patterns” • There is a set of specific Design Patterns 2. The trickiest part – find a balance for your project now and update point of balance in time Rationale “business” limitations – Static (Balance)
  44. 44. 1. (-) Relatively simple business logic due to Domain 2. (-) Relatively simple business logic due to System size (hundreds test-cases) 3. (-) Not so many “contexts” • Browser versions • Environments • Customers with a tiny nuances of functionality • Platforms (cross-browser Web plus cross-platform Mobile) Compare “business” limitations - Dynamic
  45. 45. 1. State-full approach - you have a set of objects classes, which developed, possibly, using several Design Patterns to implement necessary functionality – to choose different behavior depending on … 2. Solution to simplify the project – refactoring “Replace Polymorphism with Conditional” 3. Polymorphism ~= object ~= State-full approach 4. No Polymorphism ~= no objects ~= State-less approach Rationale “business” limitations – Dynamic (Transformation)
  46. 46. 1. “From Patterns to refactoring” • There is no need to use a set of specific Design Patterns 2. The trickiest part – find a balance for your project now and update point of balance in time Rationale “business” limitations – Dynamic (Balance)
  47. 47. Find and “update” a balance for your own project
  48. 48. 1. Ask yourself "how can I hide some details from the rest of the software?“ 2. What is encapsulation? • hide variability • hide complexity • Details • "conflict of interests“ • “tech” discussions 3. Example of public member or private member + setter/getter • What is really hidden? • Where is simplicity? Encapsulation – the most important OOP principle
  49. 49. 1. “Refactoring is a controlled technique for improving the design of an existing code base.” 2. “Its essence is applying a series of small behavior-preserving transformations, each of which "too small to be worth doing".” 3. “The cumulative effect of each of these transformations is quite significant.” 4. “By doing Refactoring in small steps you reduce the risk of introducing errors. You also avoid having the system broken while you are carrying out the restructuring - which allows you to gradually refactor a system over an extended period of time.” Refactoring by Martin Fowler
  50. 50. 1. “There is a close relationship between refactoring and patterns.” 2. “Often the best way to use patterns is to gradually refactor your code to use the pattern once you realize it’s needed.” 3. “Joshua Kerievsky’s Refactoring to Patterns explores this topic, making this a great topic to learn about once you’ve got the basic refactoring's under your belt.” 4. “From Refactoring To Design Pattern” path – from pure design to adequate design 5. “From ~Design Patterns To Refactoring” path – from over design to adequate design Refactoring and Design Patterns by Martin Fowler
  51. 51. 1. “Refactoring to Patterns is the marriage of refactoring - the process of improving the design of existing code - with patterns, the classic solutions to recurring design problems.” 2. “Refactoring to Patterns suggests that using patterns to improve an existing design is better than using patterns early in a new design. This is true whether code is years old or minutes old.” 3. “We improve designs with patterns by applying sequences of low-level design transformations, known as refactoring's.” 4. And vice versa Refactoring and Design Patterns by Joshua Kerievsky
  52. 52. 1. There are more then 90 types of refactoring 2. Refactoring types that relate to a particular field is called a ”Refactoring Language” 3. ”Refactoring Language” gives a common terminology for discussing the situations specialists are faced with: • “The elements of this language are entities called Refactoring types”; • “Each type of Refactoring describes a problem that occurs over and over again in our environment”; • “Each type of Refactoring describes the core of the solution to that “~low level” problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice!” Refactoring Catalog / Language
  53. 53. 1. You have a conditional that chooses different behavior depending on the type of an object. 2. Move each leg of the conditional to an overriding method in a subclass. Make the original method abstract. 3. And vice versa 4. Example Replace Conditional with Polymorphism and vice versa
  54. 54. 1. Replace Conditional Dispatcher with Command Design Pattern • Create a Command for each action. Store the Commands in a collection and replace the conditional logic with code to fetch and execute Commands. 2. Replace Conditional Logic with Strategy Design Pattern • Create a Strategy for each variant and make the method delegate the “calculation” to a Strategy instance. 3. Replace Conditional Logic with State Design Pattern • Create a State for each variant as a part of “State Machine” and make the method delegate tricky “calculation” to the “State Machine”. Replace Conditional with … more sophisticated options
  55. 55. 1. Problem: • You have a conditional that performs various actions depending on object type or properties. 2. Solution: • Create subclasses matching the branches of the conditional. • In them, create a shared method and move code from the corresponding branch of the conditional to it. • Replace the conditional with the relevant method call. • The result is that the proper implementation will be attained via polymorphism depending on the object class. Replace Conditional with Polymorphism – detailed description
  56. 56. 1. This refactoring technique can help if your code contains operators performing various tasks that vary based on: • Class of the object or interface that it implements • Value of an object's field • Result of calling one of an object's methods 2. If a new object property or type appears, you will need to search for and add code in all similar conditionals. Thus the benefit of this technique is multiplied if there are multiple conditionals scattered throughout all of an object's methods. Why refactor
  57. 57. 1. This technique adheres to the Tell-Don't-Ask principle: instead of asking an object about its state and then performing actions based on this, it is much easier to simply tell the object what it needs to do and let it decide for itself how to do that. 2. Removes duplicate code. You get rid of many almost identical conditionals. 3. If you need to add a new execution variant, all you need to do is add a new subclass without touching the existing code (Open/Closed Principle). Benefits
  58. 58. 1. For this refactoring technique, you should have a ready hierarchy of classes that will contain alternative behaviors. If you do not have a hierarchy like this, create one. Other techniques will help to make this happen: 2. Replace Type Code with Subclasses. Subclasses will be created for all values of a particular object property. This approach is simple but less flexible since you cannot create subclasses for the other properties of the object. 3. Replace Type Code with State/Strategy. A class will be dedicated for a particular object property and subclasses will be created from it for each value of the property. The current class will contain references to the objects of this type and delegate execution to them. 4. The following steps assume that you have already created the hierarchy. Preparing to Refactor
  59. 59. 1. If the conditional is in a method that performs other actions as well, perform Extract Method. 2. For each hierarchy subclass, redefine the method that contains the conditional and copy the code of the corresponding conditional branch to that location. 3. Delete this branch from the conditional. 4. Repeat replacement until the conditional is empty. Then delete the conditional and declare the method abstract. Refactoring Steps
  60. 60. 1. Follow Refactoring to Patterns or Patterns to Refactoring flows How to select a proper PO implementation?
  61. 61. Find and “update” a balance for your own project
  62. 62. Base class, inheritance, virtual functions and overloading
  63. 63. «Паттерны» и «антипаттерны»
  64. 64. #0 Думай
  65. 65. Концептуальный [1]
  66. 66. #1 Не может существовать абсолютных решений Описание: 1. Применимость не применимость 2. Сама категоризация да и понятие Паттерн АнтиПаттерн – относительно и зависит от контекста Паттерны: • Избегайте holy war -ов • Как минимум, до начала полемики, четко и однозначно выясните контекст, а так же сформулируйте в явном виде основания на которых вы стоите и которых ожидаете от собеседника
  67. 67. Концептуальный [1]
  68. 68. 1. Ask yourself "how can I hide some details from the rest of the software?“ 2. As with any encapsulation this yields two benefits (QA Automation, Page Object Design Pattern context): • store logic that manipulates the UI to a single place you can modify it there without affecting other components in the system; • it makes the client (test) code easier to understand because the logic there is about the intention of the test and not cluttered by UI details. Encapsulation – the most important OOP principle
  69. 69. 1. Page Element – encapsulates “complexity” of UI element, canonical example – table as a part of UI. 2. Page Element – the simplest Page Object (Page Object with one and only one UI element) 3. Let’s focus on Page Objects and then return back to Page Element Design Pattern. #2 Page Element
  70. 70. 1. Page Objects – encapsulates the way of identification and logical grouping of widgets. 2. Page Object == Logical Page 3. Page Object != Physical Page #3 Page Object
  71. 71. #3 Page Object – state-less approach
  72. 72. #3 Page Object – state-less approach 
  73. 73. 1. Aggregation 2. Inheritance • Much more complicated then aggregation. 3. Summary: • prefer aggregation to inheritance in mooooost cases; • before start implementation based on inheritance, please, take a break for a minute, and re-thing everything again, possibly you can find a proper solution based on aggregation. 2 ways (main, in 99% of cases) of re-usage any entity in OOP
  74. 74. 1. Let’s compare: • Photo • Share – looks like parallelism (easy parallelism). • Video • Share – looks like parallelism (not trivial parallelism). State-less or state-full solution?
  75. 75. 1. How easy transform solution from “single” to “multi” threading (to decrease “QA Automation Windows”) • State-less – like share a photo • Just 5 minutes of work. • State-full – like share a video • Not trivial task, could be a night mare. 2. Summary • prefer state-less solutions to state-full solutions in mooooost cases; • before start implementation a state-full solution, please, take a break for a minute, and re-thing everything again, possibly you can find a proper state-less solution. State-less or state-full solution?
  76. 76. 1. Static class • could be implemented as a state-less solution easily 2. Object • State-full solution in 99,99% cases 3. Summary • prefer static class based solutions (state-less) to object based (state-full) in mooooost cases; • before start implementation based on objects, please, take a break for a minute, and re-thing everything again, possibly you can find a proper solution based on static classes. Object or static class State-full or State-less solution?
  77. 77. 1. Static classes based 2. State-less 3. Summary: • Such an implementation (the simplest one, state-less) – is a proper one in most cases; • You can find dozens of examples in this presentation. #3 Page Object – the simplest implementation
  78. 78. 1. UI Map – one entry point • One entry point, tree of Page Objects; • One entry point, tree of locators. #4 UI Map
  79. 79. Уровня Дизайна [5]
  80. 80. 1. Web UI that behaves like a Wizard 2. Web UI in combination with Mobile in one use case 3. Internet of Things (in most cases) 4. More then 1 page during 1 test (for example several portals or several instances of one portal to implement one “business use case”): • Really seldom; • Looks like integration tests (in most cases): • Std solution- some type of White Box Testing. 5. Many others “special cases” #3 Page Objects – state-full, special cases
  81. 81. 1. “Page objects are a classic example of encapsulation - they hide the details of the UI structure and widgetry from other components (the tests).” • “store logic that manipulates the UI to a single place you can modify it there without affecting other layers in the QA Automation solution (architecture)”; • “it makes the test code easier to understand because the logic there is about the intention of the test (focus on business logic) and not cluttered by UI details”. #3 Page Object by Martin Fowler
  82. 82. 1. “When you write tests against a web page, you need to refer to elements within that web page in order to click links and determine what's displayed.” 2. “However, if you write tests that manipulate the HTML elements directly your tests will be brittle to changes in the UI.” 3. “A page object wraps an HTML page, or fragment, with an application-specific API, allowing you to manipulate page elements without digging around in the HTML.” 4. ”Page Object should allow a software client to do anything and see anything that a human can.” 5. ”Page Object should also provide an interface that's easy to program to and hides the underlying widgetry in the window.” #3 Page Object by Martin Fowler, “general” rules
  83. 83. #3 Page Object by Martin Fowler
  84. 84. 1. “The page object should encapsulate the mechanics required to find and manipulate the data in the UI control itself” 2. “Changing the concrete control - the page object interface shouldn't change.” 3. “A page object wraps an HTML page, or fragment, with an application-specific API, encapsulate a way of page elements manipulation (without digging around in the HTML).” 4. ”A page object should also provide an interface that's easy to program to and hides the underlying widgetry in the window.” #3 Page Object by Martin Fowler, “encapsulation”
  85. 85. 1. “A page object wraps an HTML page, or fragment, with an application-specific API, allowing you to manipulate page elements without digging around in the HTML.” 2. “Despite the term "page" object, these objects shouldn't usually be built for each page, but rather for the significant elements on a page” 3. “A header page object and a footer page object – canonical examples.” #3 Page Object by Martin Fowler, “logical page” rule
  86. 86. 1. “Model the structure in the page that makes sense to the user of the application.” 2. ”Page Object should allow a software client to do anything and see anything that a human can.” 3. “Some of the hierarchy of a complex UI is only there in order to structure the UI - such composite structures shouldn't be “showed” by the page objects.” #3 Page Object “hierarchy of a complex UI”
  87. 87. 1. “To access a text field you should have accessor methods that take and return a string, check boxes should use booleans, and buttons should be represented by action oriented method names.” 2. “Page object operations should return fundamental types (strings, dates) or other page objects.” 3. “If you navigate to another page, the initial page object should return another page object for the new page.” #3 Page Object by Martin Fowler, “should return” rule
  88. 88. 1. “There are differences of opinion on whether page objects should include assertions themselves, or just provide data for test scripts to do the assertions.” 2. “Advocates of including assertions in page objects say that this helps avoid duplication of assertions in test scripts, makes it easier to provide better error messages, and supports a more TellDontAsk style API.” 3. Asserts in Page Objects increase QA Automation window dramatically. #3 Page Object by Martin Fowler, “assertion” rule
  89. 89. 1. “Advocates of assertion-free page objects say that including assertions mixes the responsibilities of providing access to page data with assertion logic, and leads to a bloated page object.” 2. “I favor having no assertions in page objects.” 3. “I think you can avoid duplication by using assertion libraries (there is a huge set such a frameworks) for common assertions - which can also make it easier to provide good diagnostics.” #3 Page Object by Martin Fowler, “assertion” rule
  90. 90. 1. We've described this pattern in terms of HTML, but the same pattern applies equally well to any UI technology. I've seen this pattern used effectively to hide the details of a Java swing UI and I've no doubt it's been widely used with just about every other UI framework out there too. 2. Patterns that aim to move logic out of UI elements (such as Presentation Model, Supervising Controller, and Passive View) make it less useful to test through the UI and thus reduce the need for page objects. #3 Page Object - notes
  91. 91. 1. Page objects are most commonly used in testing, but can also be used to provide a scripting interface on top of an application. 2. It's best to put a scripting interface underneath the UI, that's usually less complicated and faster. 3. However with an application that's put too much behavior into the UI then using page objects may make the best of a bad job. (But look to move that logic if you can, it will be better both for scripting and the long term health of the UI.) #3 Page Object – alternative areas of usage
  92. 92. Уровня Дизайна [5]
  93. 93. 1. Page Element – encapsulates “complexity” of UI element, canonical example – table as a part of UI. 2. Page Element – the simplest Page Object (Page Object with one and only one UI element) #2 Page Element
  94. 94. Уровня Дизайна [5]
  95. 95. 1. Action – a set (tiny or huge) of lines of code based on “primitive” “low level” API (for example Selenium or some wrapper) calls. 2. Action is usually used in a combination with Page Element and Page Object Design Patterns. 3. Action layer could be separated from, combined with Page Objects layer … or even both approached in one solution. #5 Action
  96. 96. 1. 2 “types” of Actions: • QA Automation specialist oriented; • Business (~Product Owner) oriented; 2. Action – isn’t a right place for asserts in mooooooooost cases: • There is no sense to check the same functionality in the same build dozens of times; • Such an approach seriously increase QA Automation windows; #5 Action
  97. 97. 1. QA Automation specialist oriented Action can contain just several lines of code, to simplify manipulations with Widgets. 2. Business oriented Action can be a “copy” of some test (without all asserts). 3. In general Action layer could be implemented ether as a classical API or as a DSLFlow based API. #5 Action
  98. 98. Уровня Дизайна [5]
  99. 99. #6 Flow, Fluent Interface, “logical chain” • Ubiquitous language • Domain model • Domain driven design (DDD) • In fact – really-really useful, general purpose practice, part of fully implemented Agile process • Key word driven QA Automation • Behavior Driven Development (BDD) approach – as a special case of DSL based QA Automation solutions
  100. 100. #6 Flow, Fluent Interface, “logical chain” • Domain specific language (DSL) based QA Automation • Flow – as a way of implementation DSLBDD • State-full solution
  101. 101. #6 Flow, Fluent Interface, “logical chain” • Flow- fluent interface is an implementation of an object oriented API that aims to provide more readable code. • A fluent interface is normally implemented by using method cascading (concretely method chaining) to relay the instruction context of a subsequent call (but a fluent interface entails more than just method chaining). • Generally, the context is defined through the return value of a called method self-referential, where the new context is “equivalent” to the last context terminated through the return of a void context.
  102. 102. #6 Flow, Fluent Interface, “logical chain” LoginPage.Instance().Navigate() .Login() .Search("some entity") .ClickImages() .SetSize(Sizes.Large) .SetColor(Colors.BlackWhite) .SetTypes(Types.Clipart) .SetPeople(People.All) .SetDate(Dates.PastYear) .SetLicense(Licenses.All);
  103. 103. #6 Flow, Fluent Interface, “logical chain” Flow by Martin Fowler • “Building a fluent API like this leads to some unusual API habits.” • “One of the most obvious ones are setters that return a value.” • “The common convention in the curly brace world is that modifier methods are void, which I like because it follows the principle of CommandQuerySeparation. This convention does get in the way of a fluent interface, so I'm inclined to suspend the convention for this case.”
  104. 104. #6 Flow, Fluent Interface, “logical chain” Flow by Martin Fowler • “You should choose your return type based on what you need to continue fluent action.” • “The key test of fluency, for us, is the Domain Specific Language quality. The more the use of the API has that language like flow, the more fluent it is.”
  105. 105. Уровня взаимодействия с бизнесом [3]
  106. 106. #7 Keyword driven testing Вы можете найти детальную информацию «#8 Domain Specific Language» COMAQA Piter 2017. Роман Иовлев vs Антон Семенченко. BDD vs notBDD battle
  107. 107. Уровня взаимодействия с бизнесом [3]
  108. 108. #8 BDD Вы можете найти детальную информацию «#8 Domain Specific Language» COMAQA Piter 2017. Роман Иовлев vs Антон Семенченко. BDD vs notBDD battle
  109. 109. Уровня взаимодействия с бизнесом [3]
  110. 110. #9 Domain Specific Language DSL • DSL = Domain (ether technical or business … or both – Gherkin for specific domain) + Language • Language = Dictionary + Structure • Dictionary = Ubiquitous language • Structure = some rules how to combine words (business terms) from dictionary in a proper ways (based on business logic) • Way of implementation (one of the ways) – Flow Design Pattern
  111. 111. #9 Domain Specific Language DSL by Martin Fowler • The basic idea of a domain specific language (DSL) is a computer language that's targeted to a particular kind of problem (QA Automation or even QA Automation in exact domain), rather than a general purpose language that's aimed at any kind of software problem. Domain specific languages have been talked about, and used for almost as long as computing has been done. • DSLs are very common in computing: examples include CSS, regular expressions, make, rake, ant, SQL, HQL, many bits of Rails, expectations in JMock …
  112. 112. #9 Domain Specific Language DSL by Martin Fowler • It's common to write tests using some form of DomainSpecificLanguage, such as Cucumber or an internal DSL. If you do this it's best to layer the testing DSL over the page objects so that you have a parser that translates DSL statements into calls on the page object.
  113. 113. #9 Domain Specific Language DSL types by Martin Fowler • Internal DSLs are particular ways of using a host language to give the host language the feel of a particular language. This approach has recently been popularized by the Ruby community although it's had a long heritage in other languages - in particular Lisp. Although it's usually easier in low-ceremony languages like that, you can do effective internal DSLs in more mainstream languages like Java and C#. Internal DSLs are also referred to as embedded DSLs or FluentInterfaces
  114. 114. #9 Domain Specific Language DSL types by Martin Fowler • External DSLs have their own custom syntax and you write a full parser to process them. There is a very strong tradition of doing this in the Unix community. Many XML configurations have ended up as external DSLs, although XML's syntax is badly suited to this purpose. • Mixed (internal with external) • Graphical DSLs requires a tool along the lines of a Language Workbench.
  115. 115. Уровня взаимодействия с бизнесом [3]
  116. 116. #10 Navigator (for Web) • Navigator (for Web) – follows “DRY” and “Single source of truth” principles, encapsulates “complexity” of links transitions between web pages and store this information in one and only one place. • Usually: • works in a combination with a “Page Object” and “Action” Design Patterns for QA Automation; • “Action” layer implements via Flow or DSL approaches; • state-full approach; • applies for really big projects.
  117. 117. Уровня Дизайна [5]
  118. 118. #11 +20 Design Patterns в контексте Автоматизации тестирования Эти DP в контексте Автоматизации тестирования будут рассмотрены в соответствующем 8 часовом тренинге: 1. Factory method, Abstract Factory, Creational Method, Builder 2. Assert Object / Matchers 3. Builder, Composite, Iterator, Decorator, Visitor 4. Proxy / Loadable component
  119. 119. #11 +20 Design Patterns в контексте Автоматизации тестирования Эти DP в контексте Автоматизации тестирования будут рассмотрены в соответствующем 8 часовом тренинге: 5. Data Registry / Singleton 6. Object Pool / Flyweight / Singleton 7. Data Provider / Singleton 8. Value Object / Data Transfer Object
  120. 120. #11 +20 Design Patterns в контексте Автоматизации тестирования Технические детали тренингов по Архитектуре: • В ООП существует всего 2 базовых средства «художественной выразительности»: агрегация и наследование. • Даже если мы начнем оперировать на более высоком уровне абстракции, что в корне не верно, но все же, то получим 5 базовых элементов (+ объект, класс, интерфейс). • Средств «художественной выразительности» единицы; DP сотни и даже тысячи; бизнес проблем миллионы.
  121. 121. #11 +20 Design Patterns в контексте Автоматизации тестирования Технические детали тренингов по Архитектуре: • Классический подход предлагает нам сделат ь выбор mapping в общем виде новой для себя проблемы на новые для себя DP используя связь проблемы – DP’s и их комбинации. • Если мы попытаемся разобраться в родственных DP’s, используя классические подходы к класификации, то 10-ки или даже 100 DP’s реализованы с использованием одних и тех же средств «худ. выразительности», возможно в чууууть иных комбинациях, а значит сделать разумный выбор без экспертной оценки невозможен.
  122. 122. #11 +20 Design Patterns в контексте Автоматизации тестирования Технические детали тренингов по Архитектуре: • Пример: Factory Method, Abstract Factory, Creational Method, Builder как способ формирования Composite или вариант группировки Decorator-ов реализованы с помощью агрегации и наследования ... А значит сделать среди них осознанный выбор в неизвестном контексте опираясь на классические начала невозможен.
  123. 123. #11 +20 Design Patterns в контексте Автоматизации тестирования Технические детали тренингов по Архитектуре: • Предложенный многими специалистами mapping БизнесПроблема – DP не работает и работать не может (за исключением стандартного списка проблем, что так удобно для студентов и молодых специалистов) • Инкапсуляция! Что именно инкапсулирует тот или иной DP! • Бизнес проблема - что, когда, как и почему нужно инкапсулировать => минимальный полный набор инкапсуляций по которому и строится связка DP с выбором оптимизацией по некоему доп. критерию.
  124. 124. Уровня Дизайна [5]
  125. 125. #12 State-less or State-full solution Вы сможете найти детальную информацию в «Theoretical fundamentals».
  126. 126. Уровня Архитектуры [4]
  127. 127. #13 Особенности функционирования в экосистеме Enterprise языков Проблема (на популярном примере): Java – один из самых популярных языков для Автоматизации тестирования; основная задача Java – разработка ПО для «кровавого» Enterprise-а => большая часть конструкций языка слишком сложна излишня для Автоматизации тестирования, best practices – переусложнены для Автоматизации, советы официальной документации и форумов проф разработчиков – так же выдают не оптимальное для Автоматизации, а переусложненное решение.
  128. 128. #13 Особенности функционирования в экосистеме Enterprise языков Паттерн: • Использовать минимальное полное подмножество языка (Java) • Сознательно выбирать наиболее простые конструкции языка • Сознательно избегать большинства популярных библиотек (субъективный пример на базе выборки ЭПАМ: так Swing используется примерно в 40% проектов по Автоматизации тестирования на Java, а реально необходим лишь в 2%)
  129. 129. #13 Особенности функционирования в экосистеме Enterprise языков Паттерн: • Использовать специализированную литературу и форумы с фокусом в Автоматизации тестирования, а не классической разработки. • Задуматься о переходе на легковесные языки, скажем Kotlin
  130. 130. Уровня Архитектуры [4]
  131. 131. #14 Трудоемкая разработка Архитектуры тестового проекта Паттерн: 1. В подавляющем большинстве случаев (не владею точными данными по отрасли в целом, пусть будет 98% ) разработка стартового варианта Архитектуры тестового проекта должна занимать от 4 человеко-часов (при наличии опыта и готовых наработок) до считаных человеко-дней (в обратном случае) ... Любое затягивание фазы работы над архитектурой автоматически приводит к проблеме Over-Design-а.
  132. 132. Уровня Архитектуры [4]
  133. 133. #15 «Прости Господи Архитектор» Проблема: Специалисты в Автоматизации тестирования регулярно не могут найти конструктивный способ саморазвития ... И не найдя конструктива, погружаются с головой в деструктив: разработка Архитектуры ради Архитектуры, разработка собственных вспомогательных инструментов без бизнес обоснования, и конечно разработка собственных Wrapper-ов над популярными инструментами, вроде Selenium-а, без единого здравого аргументу в пользу инвестиций человеко-месяцев лет Паттерн: Работа Resource Manager-а особенно важна и трудоемка с Автоматизаторами.
  134. 134. Человеческий капитал [6]
  135. 135. #16 Использование конфигураций Hardcoded values Данные
  136. 136. #16 Использование конфигураций Hardcoded values Конфигурации
  137. 137. #16 Использование конфигураций Hardcoded values Паттерн: 1. Вместо hardcoded values используйте 1. Параметры командной строки для CI 2. Соответствующий набор конфигурационных файлов того или иного формата Выбор опции «1» или «2» зависит от размера сложности проекта, деталей окружения Универсальное решение: сразу использовать пусть вырожденный, но уже готовый для потенциального расширения набор входных конфигурационных файлов (контр аргумент – преждевременное, пока не оправданное, введение дополнительного уровня косвенности)
  138. 138. Процессный [2]
  139. 139. #17 Удобная отчетность
  140. 140. #17 Удобная отчетность Паттерн: 1. Используйте “QA Automation Analyses Windows” метрику для контроля анализа принятия решения 2. Разработка matcher-ов в качестве стандартных helper-ов проекта 3. Идеальный конечный результат: 1. Вы пишете, но не читаете логи и трейсы 2. Вы вкладываетесь в зеленый параметр метрики “QA Automation Analyses Windows”
  141. 141. Процессный [2]
  142. 142. #18 Понеслась Контекст: Заказчик выступил в роли «не компетентного» инициатора Автоматизации: • Автоматизация – это «модно»; • CI – это «модно», но без АвтоТестов не работает; • Запрос на Автоматизацию – один из самых популярных;
  143. 143. #18 Понеслась Паттерн: • Начинать поиск решение с Vision, Test Strategy, Test Plan, QA Automation ROI, Metrics • COMAQA Piter 2017. Антон Семенченко. Разработка эффективной тестовой стратегии • http://dpi.solutions/education?name=testing-strategy • http://dpi.solutions/education?name=roi-for-automation-testing • http://dpi.solutions/education?name=metrics-in-testing АнтиПаттерн: • Just do it Понеслась
  144. 144. Процессный [2]
  145. 145. #19 Test Pyramid Описание Паттерн: • Антон Семенченко. Пирамида Тестирования через призму ROI калькулятора #1 • Антон Семенченко. Пирамида Тестирования через призму ROI калькулятора #2 АнтиПаттерн: • Не использование некорректное использование пирамиды тестирования • «Мороженка»  • «Кексик» 
  146. 146. #19 Test Pyramid Юнит-тесты API-тесты UI- автотесты Ручное тестирование
  147. 147. #19 Test Pyramid – «Мороженка» Много ручного тестирования Слой хрупких и требовательных тестов очень велик Слой самых быстрых и надежных тестов крайне мал
  148. 148. Откуда берутся ... «Мороженки» Кажущаяся сложность написания юнит- тестов (создание / поддержка моков) по сравнению с UI-тестами Нужно таски закрывать! Какие юнит-тесты?!
  149. 149. #19 Test Pyramid - «Кексик» Ручные тесты дублируют проверки того, что покрыто UI-автотестами UI-тесты дублируют проверки того, что покрыто Unit-тестами
  150. 150. Откуда берутся ... «Кексики» Стремление автоматизировать все, что можно Нет четкого плана (каскадность антипаттернов ... как и паттернов) “Положительные” контр примеры пирамидальных трансформаций: опыт работы с Siemens, Intel, Telekom*
  151. 151. Паттерн  Юнит-тесты API-тесты UI- автотесты Ручное тестирование
  152. 152. Процессный [2]
  153. 153. #20 Не атомарные Test Cases == не линейные отчеты + проблема тестирования тестов четность ошибок TableDefaultBehaviorTest PASSED TableDefaultBehaviorTest FAILED
  154. 154. #20 Не атомарные Test Cases == не линейные отчеты + проблема тестирования тестов четность ошибокПричины проблем: • Стремление «сэкономить» на количестве тестов, т.е. времени их разработки, поддержки, прогона. • «И так же проверяет!» • «А по другому не получается!» Паттерн: «Разделяй и властвуй» - дробите Автотесты до минимальной цикломатической сложности; в идеале, добивайтесь автомарности автотестов
  155. 155. #20 Не атомарные Test Cases == не линейные отчеты + проблема тестирования тестов Дополнительные источники информации: COMAQA Piter 2017. Антон Семенченко. Системный взгляд на параллельный запуск Selenium #1 «Хорошие» и «плохие» варианты параллельного запуска Selenium WebDriver тестов — Антон Семенченко #2
  156. 156. Процессный [2]
  157. 157. #21 На позитиве Контекст: • Доминирование «позитивных» тестов Паттерны: • Планирование: Test Plan, Metrics • COMAQA Piter 2017. Антон Семенченко. Разработка эффективной тестовой стратегии • http://dpi.solutions/education?name=testing-strategy • http://dpi.solutions/education?name=roi-for-automation-testing • http://dpi.solutions/education?name=metrics-in-testing
  158. 158. #21 На позитиве АнтиПаттерны: • Отсутствие планирования • «Майндсет» разработчика • «Бездумное» следование спецификации
  159. 159. #21 На позитиве ;) Большой объем тестирования остается за ручными тестировщиками
  160. 160. Паттерн  Keep calm and stay pessimistic
  161. 161. Процессный [2]
  162. 162. Main “principles” • “If you have WebDriver APIs in your test methods, You're Doing It Wrong.” - Simon Stewart • Don't repeat yourself (DRY): “Every piece of knowledge must have a single, unambiguous, authoritative representation within a system” - Andy Hunt and Dave Thomas in their book The Pragmatic Programmer • “Broken windows theory”
  163. 163. “Tell-Don't-Ask” principle This is a principle that helps people remember that object-orientation is about bundling data with the functions that operate on that data. It reminds us that rather than asking an object for data and acting on that data, we should instead tell an object what to do. This encourages to move behavior into an object to go with the data.
  164. 164. Useful “principles” • “Test-driven development” • “Single responsibility principle” • “Single source of truth” • “Interface segregation principle” • “Occam's razor” • “Poka-yoke”
  165. 165. Время метафор 
  166. 166. Врата - песнь 3, стихи 22-31 • Там вздохи, плач и исступленный крик • Во тьме беззвездной были так велики, • Что поначалу я в слезах поник. • Обрывки всех наречий, ропот дикий, • Слова, в которых боль, и гнев, и страх, • Плесканье рук, и жалобы, и всклики • Сливались в гул, без времени, в веках, • Кружащийся во мгле неозаренной, • Как бурным вихрем возмущенный прах.
  167. 167. Врата Аантипаттерны UI-Автоматизации Если за дело берется «прости Господи Архитектор», то «оставь надежду всяк сюда входящий»
  168. 168. Что делать? Стараться избегать рисков из областей: #11, #12, #13, #14, #15
  169. 169. Первый круг: Лимб – песнь 4, стихи 25-31 • Сквозь тьму не плач до слуха доносился, • А только вздох взлетал со всех сторон • И в вековечном воздухе струился. • Он был безбольной скорбью порожден, • Которою казалися объяты • Толпы младенцев, и мужей, и жен.
  170. 170. Первый круг: Лимб Statefull решение без причины - ...
  171. 171. Что делать Стараться избегать рисков из областей: #12
  172. 172. Второй круг: Похоть – песнь 5, стихи 31-39 • То адский ветер, отдыха не зная, • Мчит сонмы душ среди окрестной мглы • И мучит их, крутя и истязая. • Когда они стремятся вдоль скалы, • Взлетают крики, жалобы и пени, • На господа ужасные хулы. • И я узнал, что это круг мучений • Для тех, кого земная плоть звала, • Кто предал разум власти вожделений.
  173. 173. Второй круг: Похоть Разработка собственного Selenium Wrapper-а 
  174. 174. Что делать Стараться избегать рисков из областей: #11, #12, #14, #15
  175. 175. Третий круг: Чревоугодие – песнь 6, 7-15 • Я в третьем круге, там, где, дождь струится, • Проклятый, вечный, грузный, ледяной; • Всегда такой же, он все так же длится. • Тяжелый град, и снег, и мокрый гной • Пронизывают воздух непроглядный; • Земля смердит под жидкой пеленой. • Трехзевый Цербер, хищный и громадный, • Собачьим лаем лает на народ, • Который вязнет в этой топи смрадной.
  176. 176. Третий круг: Чревоугодие «Прости Господи Архитекторы - Гурманы»
  177. 177. Что делать Стараться избегать рисков из областей: #11, #12, #14, #15
  178. 178. Четвертый круг: Моты Жадины – песнь 7, стихи 24-35 • Так люди здесь водили хоровод. • Их множество казалось бесконечным; • Два сонмища шагали, рать на рать, • Толкая грудью грузы, с воплем вечным; • Потом они сшибались и опять • С трудом брели назад, крича друг другу: • "Чего копить?" или "Чего швырять?" / «Over-design» или «Pure- design»
  179. 179. Четвертый круг: Моты Жадины – песнь 7, стихи 24-35 • И, двигаясь по сумрачному кругу, • Шли к супротивной точке с двух сторон, • По-прежнему ругаясь сквозь натугу; • И вновь назад, едва был завершен • Их полукруг такой же дракой хмурой.
  180. 180. Четвертый круг: Моты Жадины «Апологеты» Over-design или Pure-design 
  181. 181. Что делать Стараться избегать рисков из областей: #12 + Refactoring and theory
  182. 182. Пятый круг: Ленивые Гневливые – песнь 8, стихи 31-38 • Посередине мертвого потока • Плачь, сетуй в топи невылазной, • Проклятый дух, пей вечную волну!
  183. 183. Пятый круг: Ленивые Гневливые «Понеслась» или начать работу предварительно не подумав запланировав
  184. 184. Что делать Стараться избегать рисков из областей: #18, #19 и как следствие #20, #21
  185. 185. Шестой круг: Еретики и лжеУчителя – песнь 9, стихи 115-124 • Гробницами исхолмлен дол бесплодный, - • Так здесь повсюду высились они, • Но горечь этих мест была несходной; • Затем что здесь меж ям ползли огни, • Так их каля, как в пламени горнила • Железо не калилось искони. • Была раскрыта каждая могила, • И горестный свидетельствовал стон, • Каких она отверженцев таила
  186. 186. Шестой круг: Еретики и лжеУчителя – песнь 11, стихи 1-7 • Мы подошли к окраине обвала, • Где груда скал под нашею пятой • Еще страшней пучину открывала. • И тут от вони едкой и густой, • Навстречу нам из пропасти валившей, • Мой вождь и я укрылись за плитой.
  187. 187. Шестой круг: Еретики и лжеУчителя «Апологеты» BDD, Kew-word driven, Flow Fluent Interface 
  188. 188. Что делать Стараться избегать рисков из областей: #6, #7, #8, #9 и как следствие #12, #11
  189. 189. Седьмой круг: Насильники Тираны – песнь 12, стихи 100-118 • Вдоль берега, над алым кипятком, • Был страшен крик варившихся живьем. • Я видел погрузившихся по брови. • Кентавр сказал: "Здесь не один тиран, • Который жаждал золота и крови: • Все, кто насильем осквернил свой сан. • Потом мы подошли к неотдаленной • Толпе людей, где каждый был покрыт • По горло этой влагой раскаленной.
  190. 190. Седьмой круг: Насильники Тираны Over-design Архитекторы в Автоматизации жестоко насилуют десятки разработчиков тестов ежедневно
  191. 191. Что делать Стараться избегать рисков из областей: #14, #15 и как правило #11, #12, #13
  192. 192. Седьмой круг: Самоубийцы – песнь 13, стихи 4-16 • Там бурых листьев сумрачен навес, • Там вьется в узел каждый сук ползущий, • Там нет плодов, и яд в шипах древес. • Там гнезда гарпий, их поганый след, • С широкими крылами, с ликом девьим, • Когтистые, с пернатым животом, • Они тоскливо кличут по деревьям.
  193. 193. Седьмой круг: Самоубийцы Over-design Архитекторы в Автоматизации которые лично реализуют Авто-тесты на базе собственной переУсложненной архитектуры; костыль и велосипед
  194. 194. Что делать Стараться избегать рисков из областей: #14, #15 и как правило #11, #12, #13
  195. 195. Седьмой круг: Богохульники и Содомиты – песнь 14, стихи 19-31 • Я видел толпы голых душ в пустыне: • Все плакали, в терзанье вековом, • Но разной обреченные судьбине. • Кто был повержен навзничь, вверх лицом, • Кто, съежившись, сидел на почве пыльной, • А кто сновал без устали кругом.
  196. 196. Седьмой круг: Богохульники и Содомиты – песнь 14, стихи 19-31 • Разряд шагавших самый был обильный; • Лежавших я всех меньше насчитал, • Но вопль их скорбных уст был самый сильный. • А над пустыней медленно спадал • Дождь пламени, широкими платками, • Как снег в безветрии нагорных скал.
  197. 197. Седьмой круг: Богохульники и Содомиты Все те, кто по неким «соображениям» не читает классических книг священного писания IT специалиста, а пытается постичь азы теории путем практического экспериментирования, обычно, проходящего через опу ...
  198. 198. Что делать Стараться избегать рисков из областей: #0 + теория о рефакторинте как критерии перехода
  199. 199. Восьмой круг: Сводники Обольстители – песнь 23, стихи 58-70 • Внизу скалы повапленный народ • Кружил неспешным шагом, без надежды, • В слезах, устало двигаясь вперед. • Все - в мантиях, и затеняет вежды • Глубокий куколь, низок и давящ; • Так шьют клунийским инокам одежды.
  200. 200. Восьмой круг: Сводники Обольстители – песнь 23, стихи 58-70 • Снаружи позолочен и слепящ, • Внутри так грузен их убор свинцовый, • Что был соломой Федериков плащ. • О вековечно тяжкие покровы! • Мы вновь свернули влево, как они, • В их плач печальный вслушаться готовы.
  201. 201. Восьмой круг: Сводники Обольстители Все те, кто идет на поводу «требований» заказчика в виде лозунга «Автоматизация – это тренд», «Автоматизация – один из наиболее популярных бизнес запросов» ... отбрасывая Test Strategy, QA Planning, ROI Calculator, Test Pyramid и конечно Metrics для принятие адекватного задаче решения ... Команда же взваливает на себя «Сизифов труд».
  202. 202. Что делать Стараться избегать рисков из областей: #18, #19 и как следствие #20, #21
  203. 203. Девятый круг: Предатели – песнь 32, стихи 22-47 • Что подо мною озеро, от стужи • Подобное стеклу, а не волнам. • И как лягушка выставить ловчится, • Чтобы поквакать, рыльце из пруда, • Когда ж ее страда и ночью снится, • Так, вмерзши до таилища стыда • И аисту под звук стуча зубами, • Синели души грешных изо льда.
  204. 204. Девятый круг: Предатели – песнь 32, стихи 22-47 • Свое лицо они склоняли сами, • Свидетельствуя в облике таком • О стуже - ртом, о горести - глазами. • И их глаза, набухшие от слез, • Излились влагой, и она застыла, • И веки им обледенил мороз.
  205. 205. Девятый круг: Предатели Жертвы ошибок при использовании QA Automation ROI и Test Pyramid
  206. 206. Что делать Стараться избегать рисков из областей: #18, #19 и как следствие #20, #21
  207. 207. «Что мы имеем в итоге ...» 1. Алгоритм best practices + сквозная нумерация 2. Инкапсуляция – как основной единственный  принцип ООП 3. Инкапсуляция2  – как эффективный способ «классификации» Design Patterns (в том числе «процессных» ) 4. Рефакторинг по Фаулеру и Кириевски – как критерий перехода 5. Страстный призыв «Думай» 6. «Горячая» проверенная временем метафора 7. Новый взгляд на Гемификацию 8. Символ  9. Список видео аудио литературы
  208. 208. Думай!
  209. 209. «Горячая» метафора
  210. 210. Гемификация - было
  211. 211. Гемификация – стало 
  212. 212. Символ
  213. 213. Символ Научно-технический рэп «Костыль и велосипед» • Если программисты строили бы дом, • Фундамента могло б не оказаться в нем. • Четыре стены глухие, двери - потом, • Окна - тоже, понадобится - пробьем! • Так, что еще нужно? А, крыша! • Видишь картон? Бери его, парниша! • Тащи его наверх, клади его в два слоя, • Чтоб ветром не срывало, к черту остальное. • Опять стройка встала, на стройке паралич - • Прораб изобретает свой собственный кирпич. • Пока косится лавэ, все прорабу трын-трава, • Он ходит-напевает эти странные слова
  214. 214. Символ Научно-технический рэп «Костыль и велосипед» • Если программисты были бы врачами: • "Чувак, сломал ногу" - голвами покачали: • "Эй, гляди сюда, такая же нога, • Но у меня работает - бугага" • У хирурга был бы самый неблагодарный труд: • Он все время что-то режет, но люди не встают, • Хирург пишет на форуме: "Наверно, мой косяк. • Вот фотки со стола, что я делаю не так?" • А еще в стационаре есть нацистская бригада, • Она следит за тем, чтоб все было так, как надо • И не зная праздников, не зная выходных, • Отправляет прямо в морг недолеченных больных.
  215. 215. Символ Научно-технический рэп «Костыль и велосипед» • Все правильно, конечно - зачем людей лечить, • Если можно просто выключить и снова включить, • Живыми из больнички не выходят зачастую, • Персонал напевает эту песенку простую: • Семь бед - один ответ: • Костыль и велосипед, • Семь бед- один ответ: • Вставь костыль, изобрети велосипед
  216. 216. Символ  Семь бед - один ответ: Костыль и велосипед, Семь бед- один ответ: Вставь костыль, изобрети велосипед
  217. 217. Автоматизация сегодня  Семь бед - один ответ: Костыль и велосипед, Семь бед- один ответ: Вставь костыль, изобрети велосипед
  218. 218. Идеальный конечный результат
  219. 219. Решение Человеческий фактор на 90%
  220. 220. Полезное видео 1. Николай Алименков — Паттерны проектирования в автоматизации тестирования 2. Вадим Зубович. Жизнь на костылях, или антипаттертны UI- автоматизации
  221. 221. Полезное аудио  1. Научно-технический рэп «Костыль и велосипед» 2. Научно-технический рэп «... и в продакшн» 3. Научно-технический рэп «Полиморфизм» 4. Научно-технический рэп «Дедлайн» 5. Научно-технический рэп - Ария тестировщика ПО 6. Научно-технический рэп «Папа может в си»
  222. 222. Литература  • Данте «Божественная комедия»
  223. 223. Martin Fowler “Refactoring” • http://martinfowler.com/books/refactoring.html • http://refactoring.com/ • http://refactoring.com/catalog/ • http://refactoring.com/catalog/replaceConditionalWithPolymorphis m.html
  224. 224. Refactoring to Patterns and vice versa • https://industriallogic.com/xp/refactoring/ • https://industriallogic.com/xp/refactoring/catalog.html • https://industriallogic.com/xp/refactoring/conditionDispatcherWith Command.html • https://industriallogic.com/xp/refactoring/conditionalWithStrategy. html • http://martinfowler.com/books/r2p.html
  225. 225. Полезные линки от source making • https://sourcemaking.com/ • https://sourcemaking.com/refactoring • https://sourcemaking.com/refactoring/replace-conditional-with-polymorphism • https://sourcemaking.com/design_patterns • https://sourcemaking.com/antipatterns • https://sourcemaking.com/antipatterns/software-development-antipatterns • https://sourcemaking.com/antipatterns/software-architecture-antipatterns • https://sourcemaking.com/uml
  226. 226. Человеческий фактор 1. Tom de Marco «Peopleware: Productive Projects and Teams.» Notes: «Spiritual» book... easy to read, almost fiction... recommend to read twice. [E1-E3] 2. Tom de Marco «The Deadline: A Novel About Project Management» Notes: «Spiritual» book... easy to read, almost fiction... recommend to read twice [E1-E3] 3. F. Brookes «The Mythical Man-Month: Essays on Software Engineering» Notes: «Spiritual» books ... easy to read, almost fiction ...recommend to read twice. [E1-E3]
  227. 227. Обще техническая литература 1. Grady Booch “Object oriented analysis and design with C++ examples” Notes: Do not be afraid of С++ examples, 95% of the material is conceptual, and not depending on the exact programming language From my point of view it’s one of the best books for real learning what OOP is. It might look too simple for you – which makes it even more pleasant to read before going to bed. [E1-E3]
  228. 228. Обще техническая литература 2. Martin Fowler «Refactoring» Notes: IMHO strongly recommend to read from the beginning to the end, twice in a row, to make the ideas of the book part of your life and active professional skill. (I’ve done it myself and recommend to everybody). You should put the additional attention to the refactoring “Replace Conditional with Polymorphism” and vice versa “Replace Polymorphism with Conditional” and concepts “From Refactoring to Design Patterns” and “From Patterns to Refactoring” (the book and the following articles), those 2 pair refactoring and 2 pair concepts give us an exact answer where we should or shouldn’t use Design Patterns, also during designing the Architecture solutions for Automation, give us solution criteria when we should make existing lean architecture more complex and add patterns, and when should we make the existing “monster” simpler, and avoid the created complex architecture to a couple of if’s. [E1-E3]
  229. 229. Обще техническая литература 3. D. Thomas, A. Hunt “The Pragmatic Programmer: From Journeyman to Master” Notes: Amazing book, consisting of a ton of atomic advices. IMHO should be read twice from the beginning to the very end and then you should look through different chapters while preparing to the discussion with the customer or an interview. [E2-E3] 4. Steve McConnell «Code compete» Notes: Do not be afraid of the size of that book...It should be read before going to bed from any place of the book...or by separate chapters, in order to get update and refresh the knowledge of different fiel. [E1-E3]
  230. 230. Обще техническая литература 5. Gang of four “Design patterns” Notes: IMHO strongly recommend to read from the beginning to the very end, at minimum, 2 times in a row, in order to have contents of the book become your active professional baggage, and then implement each of the pattern on your personal, even training project. [E1-E3] 6. «Pattern-Oriented Software Architecture» Volume 1-3 Notes: IMHO very good book about architecture, recommend to read from the beginning to the very end. [E3-E5]
  231. 231. Обще техническая литература 7. «Domain Specific Languages», Martin Fowler Notes: IMHO recommend to read from the beginning to the end, because creating DSL – a regular practice in Automated testing. [E3-E5] 8. «Patterns of Enterprise Application Architecture», Martin Fowler Notes: IMHO a big variety of additional Design Patterns which are relevant for big complex systems. [E2-E4] 9. Kent Beck «Extreme programming. Development through testing» Notes: IMHO easy to read book, conceptually holistic book, with useful examples [E1-E2]
  232. 232. Пишите-звоните  Email: semenchenko@dpi.solutions Skype: dpi.Semenchenko +375 33 33 46 120 +375 44 74 00 385 https://www.facebook.com/semenchenko.anton.v https://www.linkedin.com/in/anton-semenchenko-612a926b
  233. 233. DPI.Solutions • Trainings http://dpi.solutions/education?name=testing-strategy http://dpi.solutions/education?name=roi-for-automation-testing http://dpi.solutions/education?name=metrics-in-testing .
  234. 234. DPI.Solutions
  235. 235. Project A
  236. 236. Project A
  237. 237. Project A
  238. 238. Project B
  239. 239. Project B
  240. 240. Project B
  241. 241. Project C
  242. 242. Project C
  243. 243. Project C
  244. 244. Project D
  245. 245. Project D
  246. 246. Project D
  247. 247. Project E
  248. 248. Project E
  249. 249. Project E
  250. 250. Project F
  251. 251. Project F
  252. 252. Project F
  253. 253. Project J
  254. 254. Project J
  255. 255. Project J
  256. 256. Project H
  257. 257. Project H
  258. 258. Project H
  259. 259. Project I
  260. 260. Project I
  261. 261. Project I
  262. 262. Project J
  263. 263. Project J
  264. 264. Project J
  265. 265. Спасибо за внимание!

×