We answer a question why to generalize things and approaches in development, as well as in test automation. OOP is good way to achieve good tests, but you do not have always experts or just good enough programmers who could then support your OOP and some complicated approaches introduced during that. Also in a company you need a way to share achievements/common components. I will share how we started to develop XML2Selenium, which objections we had, how it transformed into a platform not depending even on Selenium, will show architectural aspects/paradigms inside XML2Selenium, what allows you to make your own frameworks if you need that.
I won't just advertise a product, but concentrate on real business cases and examples from a practice, which pushed us to create something new. I believe some ideas from what we achieved provides you another look at how test automation could be organized. E.g. in XML2Selenium all artifacts, logs, screenshots, video is put on the server into separate folder, and you are able to access that just through web interface. Another good thing is integration of some approaches from Test Management into XML2Selenium reports, which allows managers do not check a status in spreadsheets, but just use the same report.
I will show you how manual QA engineer without special programming experience could create complicated tests, handling complicated things in the app.
2. Who is on the phone
•
•
•
•
•
•
•
10 years of Java Development
Eclipse Committer
Founder and CEO at JazzTeam
Worked in different roles from Junior to CEO
Always was close to Test Automation and Processes
Master' Degree in Computer Science, SCJP/SCWCD
Product Owner of XML2Selenium Test Automation
Platform
3. Agile Java Development
• Java and world of Test Automation
• Java ideally fits TDD and DDT
• Agile/XP promotes Test Automation and Continuous
Integration
• We earn from Test Automation
• Have good experience in Generalization Programming,
including OOP, patterns, frameworks, finishing with
plugin based systems e.g. Eclipse
4. Generalization
• I would like share ideas behind XML2Selenium
architecture.
• That allows you to apply them in your everyday life.
• This does not mean you need own platform or
framework.
• This talk is not an advert. It reflects our way to make
generalization and allows us to talk to that.
14. History: complicated utilities
Blur applied through NDA, that method for typing in edit control
includes try/catch, clipboard and mouse over support, wait for object
Synchronization, DDT values, logging etc.
18. Evolution
• Utils
• Many
• Tricky thing to support
• Still need something for storing states
• E.g. singleton containers
• OOP (Page Object etc.)
• We need context
• We need some workflows
• We need reporting/advanced logs/video/dynamic
flows
19. Evolution: DSL XML
• DSL XML
• Context hidden. Applied to Test Case/Test/Frame.
Support hierarchy
• Variables are just simple
• Reusability
• Reporting
• Plugin based
• Artifacts
• Good for TDD/DDT/BDD
20. Generalization:
polymorphism
•
Main thing in OOP is polymorphism
• You have a list of different objects
• You would like to make some actions at these objects
• You would like to add new types of object
• You do not want to change something in algorithm
• Plugins = OOP/polymorphism + reflection
•
When you are developer always think in Polymorphic way
• Even factories for test/dummy/mock implementations
• Almost all the patterns
•
Block schemes are not cancelled in OOP! Please run your algorithm in mind
to find bugs in your generalized algorithm
21. Contexts
•
•
•
•
•
•
•
•
•
Great for de-coupling entities
Rights to write and read from contexts
What could and should be stored in context
Good way to expose API of core functionality
You could introduce tree of contexts, one inside another
We could have several existed contexts
Context could have interceptors
Context could have rich nature e.g. sending events/invoke listeners if some
settings set
Nice to organize in flows and apply some rules. E.g. one component would
like to have in a context certain variable. Another component would expose
some variables to context and if doesn’t do that it is mistake.
23. Plugin development
•
•
•
•
•
•
•
•
OOP
Reflexion
Configuration
Extension points
Core API for plugins
Events subscription
Permissions
Dependencies
•
I need full basis then I am happy!
• It pushes you to make algorithm of a system really generic
• Practice would evolve your system
• The same block scheme. Try to run different combination through you
system
25. Vertical movements of
projects
•
•
•
•
Copy pasting
Utility
Class
Library
• Share it
• Framework
• Share it
• Good thing when different teams in a company have a way to share
projects
• Maven + Nexus work in Java
29. Use it for testing itself
• Master build
• Always green, contains all possible XML
combinations
• Smoke Test build
• Not green, allows to have different statuses
• Self Testing build
• Uses XML2Selenium tests to test Smoke Test. Out
manual tester like this build a lot and motivated to
create new tests
• Best Practices build
30. Sharing ideas
•
•
•
•
Maven and Nexus are good for sharing dependencies, and for dynamical
building of class path
Go for early adoption. Ask you colleagues, customers, friends to check new
thing. Do not say to programmers it is trial check. Introduce real customers
and real processes
Apply processes with 100% of seniority
• Product owner
• Backlog
• Iterations
• Demos
• Manual testers
• Scrum board
Think about open source
32. Future
•
•
•
•
Going into Cloud and SAAS wrapping
Integration with CloudBees
Eclipse Studio to work without XML
XML based debug mode. In WebView to see the
contexts for every line
