 Good afternoon again a good day so far excellent, so thank you for coming in this track I know it's always a tough choice with multiple tracks. I always have a tough time which one to go through So really happy to see so many of you over here Hopefully the AC is also not going to get too cold for us to have to run out soon enough So quick introduction about myself. I'm Anand Bhagmar. I am a tester by heart and so on Don't know what that really means, but I've been doing testing, been involved with testing for a long time Currently I'm playing the role of a test practice leader at ThoughtWorks But that's just a fancy way of saying that I'm more involved in testing in all different aspects That said and done Enough about myself my contact information Twitter hashtag is over here Please feel free to reach out to me later today No, I'm in tomorrow as well or after that is in the contact information The slides will be available on Slideshare where I can I'll be putting out a blog post from my blog So you can get a link of that as well the video whenever that is available that will also be linked up with it So you'll get reference of this again Okay Enough about myself. We know how to get in touch with me for follow-up questions discussions around it What is a pattern Okay, now I'm looking for a lot of interaction Otherwise, I know you guys are sleeping or you're really hungry that you're just waiting for the session to get over What is a pattern? Sorry It's repeatable something that is repeatable. Okay, sorry proven solutions. Yes, sorry Someone said something. I don't understand what that means. You see it again and again. Okay, good There are some chairs over here as well if people want to grab it from there Okay, and now pretty spot on right. It's something that is repeatable. You see a specific use case and you say, huh I know this before of sorts. I know how to it's a common well-known thing And I know how to solve that specific problem of sorts or how to approach that's problem. Okay So fair we understand pattern well enough Before we get into the next one, how many developers in the room any developers in the room? Good to developers. Okay, I'm expecting a lot of answers from you guys specially. How many testers QS? Great are all of you also doing automation or only automation both Okay, the other roles are the BS or product owners managers. Is that what the? Okay, excellent. So From a pattern perspective developers which patterns have Do we typically use for which patterns are the more common patterns from a development perspective and we see Gang of four that's not in your pattern Factory pattern. Yes, sorry Observer someone said Visitor singleton. So there are a lot of patterns right from a test automation perspective Have you heard of any patterns or which of the patterns fit into test automation side as well? Sorry Mocking is mocking really a pattern? It's a framework. It's a way you would do automation. It's not really a design pattern in that sense Okay Page object pattern. That's one and we'll be talking a lot about that What are the patterns? Sorry strategy What do you mean by that? Okay, can you explain? Okay, I have not really come across That at least in that name before so maybe I should now look it up But fair and maybe I should talk to you also to understand more. Okay But some of the common patterns that we typically use of course is a page object. That's the first one There's something else called business layer page object pattern which I've started using at least I started calling it a business layer page object some call it a user journey or Low base pattern. There's no standard name to it But we'll talk about that as well and there are a lot of other patterns from a developer perspective the design patterns Some of them are very applicable on the test automation side as well Okay, they could be singleton composition factory builder patterns. These are some of them. Okay, not all of them Now disclaimer, right the patterns that we are talking about or the focus of this session We're talking about test automation One primary aspect of this is related with the top layer of the test pyramid, which is the UI side So it's a UI test automation framework related discussion But some of these discussions some of these things that we talk about are also going to be applicable to other types of automation API level integration unit testing water it might be of course the context differs So what you really use in which context also changes so let's look at Some of the patterns from building a test automation framework perspective what that would be Page object pattern the first one Which is one of the most common and most powerful pattern from an automaker functional UI automation perspective And why is that so if you take a case study of this old Amazon dot com page The page boundaries over here the colors are slightly weird now from the projector, but that's fine So what it really means is if I need to build a test automation framework for testing the home page of Amazon dot com Or code or in whichever that page might be You cannot really think of building automation framework for this one page Entirely why this is very very complex though. It looks like a simple design It is extremely complex in the way it has been built the way the data is coming in the way It is presented to the end users and you can start thinking of it in smaller snippets And those snippets might be just a search it might be the header It might be specific ads now that are placed in the header It might be the featured products that might be there there might be related views or recently viewed items There is in the headers that drop downs each drop down might represents a lot of complex functionality And that list can keep going on right now as complex as the page gets and typically as you start building your automation and you get more You build a more comprehensive automation framework. We need to start breaking down your Representation of the pages into smaller snippets. Why because it is going to be easier for you to manage and interact with as well Okay, so now this is what the different page snippets might represent What is the advantage the page object pattern is really giving you've broken it down into logical chance But what are the real advantage that are coming out? So first thing is you start modeling your pages in code because they are smaller snippets You can easily model specific aspects of that snippet of the page better in code how to interact with that You start simulating the user actions about it. What are the related items from that view that I'm getting? How do I search for a specific thing? So all the user interactions with that snippet of the page you can start Simulating that behavior in terms of doing actions on that snippet or Getting information from the snippet as it is represented It also becomes a one-place change Imagine if that homepage for Amazon was everything was in one page file of sorts. It is such a big file How do I know if something related with search has changed? It's not one team member that is really working on it It's a team of Developers testers working on building that how do I find out where to make that one change in a way that nothing So one with the snippet approach, you know exactly for us search related thing I go to the search page or search in header page For example and make the change over there. Nothing else is really getting impacted by so it's one place change Which is easier to find as well It also reduces the code duplication Imagine again if it's a complex set of interactions in one big file and it's a team of developers testers working on that automation How do I know am I supposed to say search for item or item to search for? Different people would think about it in a different logical way Now if it's a huge file Finding out which is the way it has been represented by someone who has done it first was as someone who needs to update it or reuse it It's going to be a problem. So what would end up happening is? Okay, okay, okay, so if umakanth has written a method search for item And I'm not thinking in the same logical way as umakanth is thinking. I'll go to that page and say a beat a minute I'm not finding this method search for item I am looking for an item to search. Let me create a new method for it Why just because I did not find that implementation in a easy enough way I'm going to start creating new things So if you keep the page small enough logical enough it becomes easy to read through and also understand what is going on in that So reducing the duplication and the snippets of pages is very important because a search page or rather the header Is going to be seen on each and every other page Versus the related views is seen only on the home page So now I can if I have built my header page in a correct fashion I can reuse it in a composition pattern from any other page from a product page or a profile page And I can make reuse easier. So snippets become very important to making it logical okay so if you look at a general architecture as a framework evolves into as The framework evolves as you have get more and more tests automated This is typically what the page object pattern based test framework architecture would look like you'd have a test intent Which has domain functionality the actions verifications and rules. This is what I need to do This is my test intent and how I would go ahead accomplishing that intent and doing the assertions on it But that would really talk to your different page objects page objects would talk to either your Driver which is interacting with the browser or maybe you have a common DSL to say maybe there are some web services Water is required around that right so your framework keeps growing You'd also say about entities and models in terms of what really is my test data How do I manage my test data? How do I interact with my test data or objects in the? product itself a mobile phone has as a model of An object versus a user profile How do I really specify that and interact with that and resources maybe my test data is external How do I load it so you start building your framework to be more and more Feature rich of course it gets more complex, but with a purpose and this is what typically it comes out. Okay? With that in mind, I want to actually show you some examples of Code what this would look like and my this page object pattern sort of makes sense Now remember I am showing you some code the intention is not to really go through the code itself But we understand certain concepts around that so As soon as I can get this moved across So what we have over here is I have this one test Which is saying should be able to add new patient. This is where my intent is and this intent Says that okay have some test data over here I'm saying what is my expected patient information when I create a new patient and How do I go ahead with interacting with the product to create this patient and doing the validation? So now I'm talking to various different pages registration page do something patient chart page do something else registered patient Or get me this information from what has happened in the earlier steps, and then I do the assertion to say yes My registered patient is now the same as what I expect the patient to have been Okay, and what this means is now this is just my test intent It is not telling me how I'm interacting with each specific page that is happening from the specific pages over here I've purposely mixed it up Java Ruby water because I don't know who is familiar with which Language but again the point over here is you're separating the concerns into specific snippets your intent is clear What are you trying to validate? What actions are you trying to do what you're trying to validate and your implementation is going to have the details around that Okay, now this is a very interesting example a Classic case of why you need snippets the home page think about this as your home page class for Amazon And this page is about almost a thousand lines if umakant had written some method and I am Expected to find out if it is existing or not I have to read so many lines of code some people might argue documentation helps No, it doesn't really because it's still again thinking about in a different direction And it's not solving the problem at the root cause itself So what you would end up doing is You would evolve this kind of a page to say Okay, maybe I've got some partials Partials can be very specific things that okay. Maybe this is for browsing the results filter This is for feedback. This is for footer and these are very specific things that are there Which has very little information only related with that snippet and now with this kind of thing I can have functional Partials which are reused across maybe they are related with a specific speech I said However, you really want to organize it and only the team members know what is the best way to organize? They are working with the product. They know those details Okay And you would have various such other utilities So why did we really talk about this Why did we have to see this example the two examples that we show about a huge class file and then the partial snippets This is an evolution that happens in a test automation framework. You're using a pattern you started using it But then you eventually realize maybe it is solving the problem only up to a certain level And there is something missing out of this what next needs to happen You want to identify the root cause and fix that rules cause to identify the root cause Let's look at some of the limitations what the page object pattern comes across The first thing is the test intent starts getting polluted Think about a scenario where I have a variant of a similar functionality Maybe it could be if I have to book a flight ticket. I could book it using I'm not a registered user on that particular website or that particular airline, right? So I want to book a flight ticket as an unregistered user. It is possible to do that The second variant is I want to book a flight ticket as a registered user What that is going to mean in terms of business functionality, of course, there is an impact right as a registered user I'll see it in my profile my future flights water might be there but with this variant of these tests Most of the steps maybe 90 95% of the actions related to booking a flight are going to be the same There's going to be some variation related with registered versus unregistered user Now to implement this test what you would do in your test intent You have implemented one test copy paste into another one start making changes and now I've got two tests automated excellent It was so fast. But now what has happened is if my user flow changes how I'm booking a ticket I have to go and change in two different places Even if 10 lines out of the 20 lines are common across both the tests If they're in the same file you could create a private method and reuse that in certain ways What if it has to be shared across different test classes, for example And it is very much possible The requirement may be such. So how do you start doing that? So the test intent pollution becomes a one big major problem as your test framework grows purely with a page object pattern Because of this duplication of the intent the implementation also starts getting duplicated in various ways How do you start managing that Also now to assist in better reuse the intent has started becoming imperative In the example that I showed in the registration of a new patient I'm talking about specific actions over there right Once the business rule really apparent out of it why we are trying to register a patient what type of patient are we trying to register To make it reusable to keep it simple we start thinking about imperative actions based on the UI flow of the product Not necessarily what the business case really is what is the business value you're trying to derive out of automating that intent And page object pattern as the framework specially grows it starts making it more and more imperative in various ways And also the maintenance challenges that we spoke about how do you make reuse if something changes you have to go across and change in so many different tests around that Because of the maintenance challenges scaling also becomes a problem as I keep on adding more and more features how do I do that really well With me so far on the challenges of page object Do we relate to these challenges Yes no So that's where I started thinking of okay there's something missing and maybe this was already a solved problem but it's not really a well publicized problem Our solution for that matter I said no this duplication does not make sense I believe in keeping my report dry Keeping it only fit for purpose of sorts no reuse or duplication so how can I manage that plus at the same time I am a very strong believer of the value the test automation pyramid brings to the teams Which means I have to keep my UI focus test functional focus test very precise very crisp and clean and it has to be really high value for me to say to justify the cost of doing it at a UI level So from that perspective what is most important? I want to automate the business value which is of critical essence to the product it has to keep working every time from an end user perspective So for that I started thinking about this business layer page object pattern and all it does is it abstracts the existing earlier architecture into one layer more Now we have a test intent but the test intent is not really going to be about what functionality I want to automate how do I interact with the pages My intent is going to be a pure business intent if I have to book a flight ticket taking that example okay what do I need to do I need to search I need to select based on certain criteria from the search results based on that selection I have to enter passenger information make the payment And ensure my PNR is my ticket is booked correctly PNR has been generated for these are my business operations do I really care which page do I need to go to search from where do I select the search results That is not of any value to the business the business value is search search results booking that is the business value that is what I will provide in my test intent The business layer is actually saying okay how do I want to search to search I need to go to maybe the home page or on any page that I am I have a search functionality over there I will use that The business layer knows how to implement that So the test intent is very crisp and clean business layer business operations the business layer is going to know is it a complex business functionality that I need to talk to other smaller business operations Which are need to be done maybe login is one aspect of that it's a business operation in a way right authenticate a user before proceeding that's a business operation So business layer might call other business layer functionality or it could call other pages entities the resources as earlier to get that specific business operation implemented Also the other difference is now the test intent does not really have actions or verifications or assertions of sorts But test doesn't care if my PNR has been the test should fail if the PNR is not generated The business operation itself should say if I'm booking and I expect this to be a valid booking request PNR should be generated the business layer is going to do that assertion and send it back The value this brings to me is the test intent again has remained clear it's about business operations any time when the test execution is going on any part of it fails whether it's at business layer or page layer The test is going to fail anyway with proper logging you and error messages you should be able to see the exact root cause of white fail but when anyone looks at the test intent you know why that test is important what business value you are getting out of Okay, so let's know by the way this architecture about actions verifications rules being in a business layer that is purely my thought I strongly feel it makes sense to put assertions here and not in the test intent I'm open for discussion around why that might not be the right thing but this has worked really well for me okay so let's look at another quick example for this Now this example is a cucumber JVM example using a BDD tool to automate a specific functionality for simplicity it is a very trivial example of sorts We could say in fact this might be a better one okay given I'm on the Google search page when I search for certain content I should see a list of related posts this is a very imperative scenario I know that this is not really a business driven scenario But when I have this as a starting point for my framework for example I specified what my intent is what this relates to in the step file again cucumber terminology it's okay if you don't really if you have not used it before But what it means is now my test intent is calling business operations only over here I'm just saying search for certain criteria I'm not instantiating a search page over here to say okay search for this in this particular page My business operation is saying search for this criteria that is all I'm saying and in my implementation in the implementation of the search page I will say okay instantiate a new search page and this is how you would search for We have created an abstraction layer in a trivial example it just seems like a lot of overhead you are unnecessarily calling methods which is not really providing any value But when you relate this with a complex example as your product is really scaling as a framework is really scaling up having a lot of tests you will start seeing aspects of reusability over here which is not possible if you keep it in the test intent itself Okay questions what's The abstraction is the step definition Okay, let me correlate this with another example non cucumber example or to start off if it's a J unit or test NG based test you have a test annotation and that's where your intent is going to be In the example that I showed earlier for this one we are calling pages directly in my test intent The difference is going to be over here now I'm going to call business layer operations which might be registration is a business operation and that would have a register patient or register different type of patient or whatever that really means You're not talking to pages directly from your intent you're talking to business operations and the business operations is going to talk to whichever other business operations or orchestrate the different interactions with various types of pages to get it In that business operation you would also have validations and assertions for Yes, so page objects in inheritance fashion to handle business layer it's really a different problem you're trying to solve in my opinion I would Need to use inheritance or composition for that matter of pages to build up what seems like my home page or my registration page whatever that is I would use that but is that really my business operation not really And that's a fair point still I don't necessarily agree with it for the simple reason why what really is a page object I know we are digressing I'll try to keep it short and we can have a follow up on this Exactly right so the page object what is the intent of a page object how do I interact with certain aspects of the page it represents How do I get information how do I set information The page object doesn't know what is right or wrong that is what the business rule is And that's the reason why I like to keep that separate because my business rule might remain the same but the way I interact with the page is different A drop down has changed to a radio button or whatever it might be the page doesn't care why the page just says how And why another classic example login right a login page would have username password and a submit button Now the method on a login page to log in with these two parameters What is expected out of the login page the next page should be maybe the home page or the profile page what are the business logic is Now if I want to test an invalid login scenario there's a page object need to care on the next pages not this I'm supposed to remain on the same page And so is authentication really a page though and that's where it is getting complicated Yes exactly that abstraction is what I'm calling as a business layer The pages what we talk about is directly what you can relate with in the UI or on the device That's the mapping Possibly, possibly Okay, so this is what the business layer page object pattern starts helping towards solving a specific problem Now if you're starting off on a new project, yeah Sure Yeah So to keep it short yes and no depending on what is the intent of your test framework If you're talking through end to end including external dependencies then yes of course If you're talking about some stage where my external dependencies have been mocked out because I don't really control that I don't have a test environment for that for what a reason then it's a different thing right So the intent of the test really comes out or it comes out today And there are ways around that but again the point is depending on how your environment is set up What type of test data you have or not you could be able to do the whole mind in that sense is payment successful is being generated Okay So what are the advantages we spoke about some of these we are now thinking about what is important to business to your customers Because business sort of represent what the customers want right that's how they're prioritizing you're validating that aspect You're ensuring your test pyramid remains sane and that's a very Mighty comment to make because you're still focused only on the top layer But by reducing the top layer of the pyramid you're forcing your other automation Test cases scenarios to be pushed down in the layer to say this is important has to be done Look at a JavaScript level or whatever else is required around that but your UI layer you're trying to keep it small The abstraction layers help to separate the concerns if my business logic is changing I'm going to change the business layer if my page logic is changing I'm changing there In some cases I need to make those changes in together for that matter The changes remain isolated now you've got a very good abstraction layer in your framework And hence maintaining and scaling of your framework becomes relatively easier Cannot say it is easy for sure but it becomes relatively easier you now know what has changed And you can go ahead and make those changes according So that's to accomplish the page object or business layer And various aspects related with your test framework you might have to use other patterns Anywhere we spoke about singleton composition various other patterns Which bring these things together which make it feasible Let's look at test data now which is something unfortunately not thought about as much Not focused upon as much Creates a lot of problems in depending on the type of product you're interacting with But before we do that why do we need to think differently about test data Has anyone had fun working with any product or create any type of test data? That's one so I create a user can I create that user again for example Can I repeat with the same set of data? What else? That's a very That I'm not even touching upon right now but you're very right How do you really ensure that is it just the stream is coming through correctly or not Or actually validating what is coming inside the stream So variants of data which is going to cover different aspects of how the product would behave Absolutely, absolutely So what are the criteria we think about so these are some of the criteria which we have right Repeatability and behavior aspects And why does it really become a challenge though Because data is complex If I just have to think about I want to implement an automation to buy a particular product A cell phone from Amazon Phone has got very specific set of features Am I going to buy any phone? Do I want to buy a specific phone? Does it have to be in stock or out of stock? Do I want to search for different types of products and select one from that On what basis do I select one from that So depending on your intent, excuse me Depending on your intent of what the test needs to do The data can become really complex Think about a banking transaction right I want to create a new customer For a particular type of account Now the customer has got a lot of complex information It's not just a personal information name Salutation everything Also address becomes a part of it Is it your permanent address, current address What type of address is it What is your official address, business address for example In some cases maybe you need that Maybe it also needs a dependent information And dependents could again have the same type of Deep requirements as well For whatever reason So how do you really create this type of data From your testing perspective to say I want to create this type of customer with these details And ensure it is created correctly So it can be really simple I want to register just giving my email id Or I want to create a customer having this complex information So how you would specify this data Is very very critical Yes, most importantly It has to mimic real data I cannot just create this data on the fly Thinking about anything If it is not realistic what is going to happen We are going to get surprises in production Because that's where the real type of data would come So that has to be there It needs to be unique Is it two customers with the same details For a bank? No There has to be certain criteria which is separating it Data hence can be nested also We spoke about that customer example Though specified as static it needs to be dynamic Now why is this important? Same case, repeatability If I can create only one Anand Bagmar As a customer in the bank How can I repeat this in an automated fashion To ensure I can create this customer every time So do I specify Anand Bagmar as my test data And ensure I delete this customer And next time it comes up again it is possible But in banking systems can you really delete customer information? No, they are archived or they are marked as deleted Not a customer whatever They don't really delete it for some time Maybe for regulatory reasons It becomes more complex So we have to think of it as I specify it as static But it needs to convert it into dynamic As we proceed Maybe my framework will say Taking the first name, last name I am going to add some unique prefix suffix to it When I am actually executing the test So I am specifying it as static But in the implementation of when the test is running I am going to convert it into dynamic and then proceed That might be a way to prevent cleanup Which might not even be in your control Or it may not be possible as well You have to think about data can be shared and reused If I have specified some test data in my test Someone else might say Okay, I already have a customer of this type Let me reuse that same data and do something else with it Is it going to pose any problems or not? There are a lot of things to be considered for this Now, given all these criteria In which different ways have you specified Test data in your test framework So if I have to say Login details, use a name password I need to login using Anand Bagmar And password ABC Where and how will you specify this data in your framework? Maybe in an YAML file Do I need a YAML file for just providing use and in password? Questions to ask Absolutely, I am not disagreeing I am asking the question Is that the right approach or not Based on the context That is one definite way Typically when you start writing a test The first thing you would do is In my test implementation itself I will say this is login, hard code the values Proceed, am I able to login or not? Next is what Maybe I need to try different variants Maybe I have specified a separate file With different combinations, whatever You start evolving into that So in test implementation Or in the test specification Or intent itself So these two are different things Implementation is not at the intent level In the page object itself I have hard coded it From the test intent I am specifying it as parameters to my page object To say login using these details The third thing is What you said right now Of sorts is it is either in code Maybe in separate Hash maps, lists, whatever it might be As separate resource files Or it could be in separate external files itself As a YAML file So a lot of options when you can do this Now Separate files itself has got a lot of combinations A lot of options that you might have Typically you start thinking of If it is a windows based Organization Excel is the first thing that comes to mind Even though there might be simpler ways to do it But Excel is one CSV files are a variant of Excel in a certain way Of course it becomes platform agnostic The minute to turn it to a CSV You can have property files You can have XML files Hopefully no one uses XML anymore Or there are better alternatives YAML is there, database is there JSON is there There are so many different options Which one would you really choose And why When you start building a test framework You need to think about the overall approach What you need to have for your framework What is the overall intent Where do you see the framework really growing How many tests, how many people potentially working on it To think about the strategy What to use What test data It is very important You also have to think about how to make it reusable and manageable Do I really need to provide 100 fields to create a customer Or can I do something more intelligent And this is where Experiences having Certain foresight Which might be wrong, which is fine But at least you are trying to think about what the future might be For your product and framework But based on that understanding what is the right strategy to use To get on that path And based on that, these are just some ways You can do that implementation Where your data can be there But is this the only way Is this the right way The answer is no There are many more variants you can create Based on these information that you have collected Now how to really proceed And let me show you a quick example on that Yeah So I am going to go back to Our cucumber example As soon as I can find it on I can locate the mouse So what I have is This cucumber file I want to create A new individual customer I am referring to a line number 56789 for example I want to create A new individual customer Think about a customer as a complex data That is required to create a new customer In the banking system What I am saying over here is I know my entity type is A new customer What I need to provide as input to this particular Business implementation I need to provide it contact information And I need to provide it some address What I have done in this implementation Is I am using a data table Which goes in as an input to the step But over here I am saying entity type Is contact info And which data section I want to use I want to use individual one Which address I want to use I want to use BNERES3 What I have done is I have created entities In these entities The entity type matches The name of the JSON file over here So my contact info Is a JSON object I am saying from this entity file Use this JSON object and create Use that information To create the personal information For it. The address Likewise Use it from here Why is this important? Because I don't want to Pollute my intent I don't care what the name really is What the address really is As long as it is fitting a certain demographic Certain criteria that is sufficient for me to know From an intent perspective How to create that customer Then the next aspect I now need to Make certain aspects dynamic Why? Because I cannot create the same customer Every time. So what I have done is I added another column in this data table And I am adding this aspect over here Randomize Again a cucumber specific example how to override it But I am saying randomized value is going to be Based on whatever the scenario outline Has it. So this scenario Outline is going to run Twice once with this data The other time with this data So in the first case, randomized value Is true. In the second case When it runs again, randomized value is false But now what I do is In my implementation, I also use This value and say, okay If I have to randomize And it is of type contact info Which feels out of contact Input via randomized. That is my own Framework intelligence that I am building To mimic a real system, a real world Scenario So you are now using external Files specifying relevant Data in your test itself And telling it how to proceed With it. You are also building intelligence In your framework to say how are you Dynamic and reusable at the same time Okay I am almost I am almost done. We still have Two minutes. But I will be done In that. So Criteria is it has to be easy to specify Easy to read and consume Ability to override as Required and it has to be usable Don't make it so complex that no one can use it You need a special set of people to manage test data Okay Think about consistent ways to Represent it. Think about the data as Business entity. So you don't have to Map a customer what it means in your Mind or the testers mind And what it represents in your product If it is similar, it makes A great Provides a great piece. Override as appropriate So you specify some data And override certain values out of that as well And maybe create DSLs to give it More meaningful information how to Go with that. Okay Certain things which have really helped me is Thinking about how to build certain utilities On your test object itself data Objects to compare test data in certain Ways or copy it replicated That helps a lot speeds up Implementation in various ways Locators similar for UI you need to interact with certain Elements you can think about it in the same Way as test data is just a differences It's not test data. It's used in implementation That's the only difference Okay Last quick bits. So what are the Advantages of patterns? We understand that well As developers, testers, we have used Page objects and other patterns so we understand This aspect well But what are the advantages of Patterns in test automation? It helps in the single ownership The pattern knows exactly What is to be done. It's a known problem How to solve it. It's a single point of change If I'm using a page object And I need to make a change I go to one place and make that change It will work fine If I'm using an effort, eventually To start building it based on the patterns There is effort required. There is complexity there But once you set it up, it is going To speed up a lot of things later on And it also helps in implementation Maintaining, debugging and scaling Of the framework as it goes on But the most important, patterns Will help move your test automation code To as close to production quality As possible. Patterns Doesn't ensure it's of production quality But it's one step in that direction To make it better Which pattern is best to use? It really depends on the context What is the product you're doing What is the intent of the test And what will help you get to that level Really have to rush through the last few minutes She's already standing up Because she has to kick me out of here But as I said My contact information is here We have lunchtime right now I'm happy to continue discussions during lunch as well Thank you for this time From value out of this Thank you