 Good afternoon everyone. I am Anand Raghmar. For those who come in recently, I hope you had a great time coming in. Today we will be talking about test data, wood core test automation framework. Quick introduction about myself. We've been testing rather, sort of, about 19-20. We believe in doing whatever it takes to help build a quality product. So in that sense, the whole time, this activity is a big matter. My Twitter ID is here. More contact information can be found from the above page. These slides will be available on Slideshare. I'll also put a blog post about this. The video is also going to be shared. So don't worry too much about trying to take notes. Instead, it would be great to have more interactions and discuss more based on each other's experiences. That's the best way we can learn from each other and grow from each other. Enough about myself. Why are you here? What do you expect from this particular session? I'm playing it safe. Test data is the biggest challenge. Quality of testing is based on test data. Sorry, I'm going to be repeating so that people in the back also will be able to follow. Variety in test data. You were saying? Maintaining test data across different environments. Anything else? Anyone expects? Test data across different pages, different similar pages, but the structure is not really the same. Storing test data in different sources. Yes. Generating test data. Very important. Design patterns for helping design test data. Reading test data dynamically to provide in the test execution. Test data for any type of scenario. Happy, negative, edge cases. Test case doesn't know if it is happy or negative. Test case is a test case. But you are right. How do you provide different types of test data? Using production test data into the test. Automatically generating test data on the fly. OK. OK. Usage of test data. So far, unfortunately, you guys are completely on spot. So that means we have to cover all these topics in the next 40 minutes. This is going to be tricky because all these issues are really complex. That's why you are here as well. Not just to learn but also share your experiences what has worked or what has not worked. I believe we learn a lot from things which have not worked, whether for us or for others, so that we can apply better practices or better techniques going forward. So Far, I think most of us are on track what we expect from this session. And let's see if we can do justice or rather if I can do justice to your expectations. What is one thing, one practice that seems successful? One of the practices. In fact, there are many. One of the practices. A common practice. A practice is a practice. It's repeated failures. That's not a practice. Consistency, repeatability. That's not a practice. In fact, loop is not a practice. Communication is a practice. Various things, right? That's fine. I'll proceed. Test automation is one of those practices What is a practice? Rather, one of the practices that can also make teams unsuccessful. Absolutely. Why? You said same thing. Why is it? Absolutely. The way you treat test automation the kind of value the team gives to test automation will determine are you using the right discipline the right set of practices to implement it to get the repeatability get the quick feedback loop out of the test that you are automating or you are executing. So, if it is done well this is a practice that will help the teams succeed. If it is not done well, it becomes a liability. Now that understand what this particular practice is rather what it can need to let's think about why do we do test automation you mentioned some things, right? Already we mentioned that answer. So, I will not wait for this. Quick feedback. Quick feedback of course has to be reliable. It cannot be once I am saying pass, once I am saying fail within a few seconds. It does not help if it is not if it is not reliable. Guys, if you don't mind sitting down there is a lot of space in front over here. Down I went literally down sorry and if you stand in between people in the back will not be able to see. So, what essentially it means is automation is a safety net. The example I always like to use is fisherman going to the sea to catch fish. If he wants to catch small fish he is not going to go with the net of a very large size, great size. The fish does not risk. So, automation has to be appropriate which means you have to identify the correct set of test intents that you would like to repeat every time in order to get feedback about the product. You can automate each and everything. Does it mean you should? You have to really think about the cost value each test is going to give you and based on that you need to okay. So, how do we get the value from automation? Repeat it right. If you run any test whether it is one test or hundreds of tests on every change in the product or the test code base I have added new tests or every factor I have deleted to make sure nothing else has broken that means there will be no false positives or false negatives on every change in the code base, product or test need to be running at this and that is the only way you will be able to get value out of whatever you have automated. So, what is going to make automation successful? Repeatable? And it has to indicate quality of the product that quality could be functional breaking or whatever as non-functional side of this as well. You have to get that information as quickly as possible. Now, given all this what makes automation repeatable? And that is specific. You have to be able to run the same test hundreds of times without having to worry about possible system in the correct state and that state could be configuration could be the test metadata that is required for execution or whatever else. We will talk about a lot of these things. Test data is the critical aspect as we rightly mentioned earlier on to ensure to get value from automation. So, what exactly is tested? My aspect test data is really of two types. First, what we give as input to the test in order to make it execute. And that could be in form of environment configuration credentials, URLs or whatever else. This is going to make the test run. Whatever actions I need to make on the product I need to be able to tell that in specific. The other aspect which is also equally important is what is the expected output out of it? How do I validate that? It's not just the request completed it's a status request 200 that means it's completed. What was the result of that action if you are not able to validate that the assertions what we call the expectations what we call from JavaScript side of things. That is very important if you do not have a lot of details in what we expect to see we have lost a lot of value from running that test. It's as if writing a test and saying assert 2 equals 2 it is always going to pass. Does it help? Not really, right? So these are two aspects of test data that you need to think about very carefully whenever you are doing automation. Now before we get into more details let's look at what is the design pattern. Do we know what is the design pattern? What is the design pattern? What is the solution for a known problem of sorts, right? A pattern by definition it means it's repeatable. It's a design that's repeatable of sorts. So a design pattern from a software terminology or software development standpoint is going to be for a known problem what is a set of techniques that can be applied to solve it in a better way. Why do we talk about these things in patterns? Unconsciously also even if you have not used or thought about patterns or known about patterns you would be doing certain things automatically subconscious because you know this is a known problem like oh there's a wire over here I need to step over it. Every time I see something on the ground I'm going to be conscious about it. I don't know what this really is called it's not pattern but what makes patterns very powerful is it's language agnostic implementation agnostic it is a common language if this is a pattern I know in which cases it can solve my problems that's what design patterns are in a nutshell. So let's look at some test data patterns related to this. Why do we need to think differently about test data? Find out bugs. How is test data going to help you find it? Who said this? How is test data going to help you find it? Code coverage is not governed by test data. Different use cases. So it's not really to find bugs you do testing with the intention to ensure there are no bugs some people won't argue the other way we do testing to find bugs. Doesn't matter overall intention is to make sure it's a quality product we know where things work and do not work. Test data is a way to help facilitate those activities different combinations whatever you are saying will help trigger different port paths in your product execution which will result in different behaviors. That is going into an implementation site for a specific scenario. So we will get into those aspects as well. But why do we really need to think about test data? It's because data is inherently complex. Is that a true statement or a false statement? So let's have some poll of sorts. Which domains do we represent over here? What type of products have you got? Telecom project. Can you describe in a nutshell without any confidential information? What type of testing? So is it for end consumer to go into a Verizon store to get sims or do account transactions? So that is one domain any other domain? Any online appointment booking? Can you give me an example which domain it can be used? So in spas and salons for example I think that's a very different type of example which is important to talk about if you think about a Verizon customer so a telecom customer what kind of detail could be required for that customer in order to do any type of transaction? So customer information, what are details around that customer information past billing, history, what are it might be the plans, what are you might have changed all. Versus if you look at a salon appointment for example, all you probably need is what are the type of test data you need for that or information you need for both kind of questions. 3-4 pieces of information name, phone number email address and any other specific nodes that might be there for that now that seems like it's a simple test data but compared to this other mobile application or telecom based application data is very different so data is inherently complex is again very relative it's subjective to which context you're talking about thinking about and you really need to think about that because that is going to mean how much you need to put effort in designing your automation framework related with data as it is very important to think about data needs to mimic real data now for a salon appointment I can give any type of information in those appeals it should be fine because all I'm really concerned about is potentially I'm making things up about the domain knowledge over here is I don't care if it's repeated or not maybe the same customer has got back to back five appointments I don't really care but for a mobile customer I cannot have more than one account maybe it's not possible if it is that's a different business to multiple accounts linked within that customer information I cannot create two customers in Verizon database with the name Anand for example that is domain business logic business rules that I implement so you have to think about that and in that case I have to really think about is my data realistic enough for me to test this critical application versus this other appointment cooking application it becomes very different way you think about it also needs to be unique in most cases like I said in the appointment cooking case it does not matter probably but in the other case you need to ensure that whenever you run your test whether it is run manually or in an automated fashion has to be unique data can be nested we spoke about an example right now again I'm thinking hypothetical I'm hoping that's how it relates in the domain as well but a customer has a account or can have multiple accounts each thing each account would have current plan and past plans but plan is a plan entity is a plan so if I have to mimic such kind of behavior what kind of test data do I need to provide maybe set up in the system or provide when my test is executing to mimic all this complete information I have to repeat the data so many times as well so it becomes more and more complex as you start thinking about end-to-end scenarios how it's going to be played out when it comes to automation the uniqueness aspect becomes even more complex because this is in code any form of code if it is in code if I have entered the customer name as Anand Bhakbar the next time my test is going to run to create a new customer it is going to fail because the first time it has passed but now Anand Bhakbar exists in the system I cannot use that same test again how can I leverage automation in such cases some might say okay I will delete the customer if exists first and then create what is that deletion is not possible for example anyone from banking domain first time no one from banking oh so in banking domain for example if there is a bank customer so any bank that you might have an account with right you close the account your data is never really going to be deleted from the account the account is going to be marked as closed or whatever the other statuses might be or regulatory purposes whatever or a good number of years the account details will not be removed from the system so when I say I am going to delete an account from a banking domain case and then I will create it again it is not going to work you have to think about all these what it means is you have to get much deeper understanding about the domain about the product you are working with to understand what type of tests are important done automated and for that what type of test data is going to be required also what do you expect out of data can be shared and reused of course because if I have created a customer created an account with it I do not want to create a new customer create a new account with it just to say if I can add one more account to that same customer you have to think from a big picture perspective ideally yes each test is completely atomic which will create its own data do its actions, validations delete the data and proceed but in many cases due to limitations of the product architecture it will not be possible so to think about those aspects as well how do I structure my data in such a way that I can reuse these or I can share certain information without creating dependencies in how my tests are going to execute where question so far is this something that we relate to understand already yeah so let's look at some examples and this is where I want from your experience you to tell me what type of test data is going to be important for these different types of test data okay and old amazon.com page let me give you a couple of scenarios that we may want to do for this as a non-amazon user I want to search for products for the shopping cart see what is the final amount that it comes out to put in shipping or as a registered user I want to search for a particular set of products add them to the shopping cart and finish it and verify the order received what type of test data would you require sorry one at a time credentials for registered user now let's take one thing at a time let's not complicate it I gave two scenarios that's fine so credentials what type of data if you had to product ID who said product ID fine then have you purchased a book or anything from amazon gift cart what product ID did you provide that is discount coupon that's a very specific that's a coupon ID if you talk about product ID if I have to buy a book I don't have a product ID what I have is information about the book it could be the name, author name ISBN name, publisher name that is the kind of information I would have and potentially there might be multiple such results that come back I need to be able to select a unique one from that maybe I need a combination of this data unless I give an ISBN number which is going to be unique anything else could return you multiple results unless my intent is choose the first one and then proceed which is also fine okay so our assumption again comes in very has to be made very explicit in such cases right the idea is correct it's not wrong product ID is going to be unique it's going to be spot on but probably not from end to end perspective because the end user never knows about the product ID or from which system it is coming back from that path right so fine we've got credentials we've got product information in fact it's multiple products that I want to buy so there will be multiple products information it could be a book it could be a mobile it could be a television it could be toys for kids whatever it might be and each product has different set of basic information it requires metadata required for each is going to be different it's not there is no ISBN number for a toy right so you have to think about what type of test data is going to be required for it to proceed special character sure you could also do that more from a functional side if I know what type of data is there I could try some negative test giving special characters as well okay agree agree someone else was mentioned credit card information for payment now would you give your credit card information in code will you write it and check it and when it was in control system dummy card what does it mean if you provide a dummy card the system has to identify it as a dummy card and be able to proceed completely because my intention is to verify the order summary right so even before thinking about starting to I love writing code I am an expert in writing code that we start doing this but to think about end to end what it really means for that scenario in some cases I need to be talking to a payment gateway and they have to tell payment is successful or not how can I provide a dummy card information to that payment gateway unless you have certain things sorted out it doesn't make sense starting off with the test automation side at least or you say I am going to proceed up to this point and then I will wait that is the other aspect right that yes absolutely you can use mocking scub out those calls and say if it is this card information return me always succeeded otherwise make call to the actual end point that could also be done there are various ways to handle it but there needs to be a way to really think through all this what type of information is it requiring what type of information am I expected to get back out of this and at the same time do I need my product behavior to change in certain ways to help in testing as well there are a lot of different aspects that come along with this okay so that is one we understand the complexity of this right what if I want to search and compare compare features also I want to compare couple of products right what type of information do I need to give in my test to say these are the features that I want to compare for a phone it would be different for any electronic products it would be different other items would be different to think about all these aspects what is it that I want to do then proceed another example any social media product if anyone anyone from Facebook over here would have actually got in a insights into how they test this type of interaction so for a Facebook page where certain information is static per account lot of other information is coming from feeds of various different sorts recent most active whatever it might be and there are also ads and various other things around that how would you do end to end testing to ensure sanity of my profile page for that back so there is a lot of dynamic data coming over here right it is complex certain aspects I can say yes or a particular user this is my family information that I have provided set up as my test data bed whatever information I have set up in the product I should always be able to see these members as my family members correct so someone mentioned earlier right using production data of sorts it is similar you are injecting seeding data in some form now what type of algorithm who is going to give the recommendation the product will give so so maybe that is what is happening here as well right for that matter assuming that is true what type of test data would you provide to say I have got 20 people in the room I want to validate they are seeing independent information based on what information they have in the seeded system so Anand should see this Mark should see this you should see some other information it is not going to be the same information for everyone what type of test data would you provide to ensure that is the same the product is going through some algorithms to split that out they are always giving it a set of users it is almost like a switch case implementation this user give this data back of course it is not that so you have to think about these aspects right it is very important fair fair let us leave it at that point for another reason in such cases this is one of the complicated cases where the data is truly very dynamic very different and if you want to actually test after releasing to prod for example production I want to test the sanity of my system there is no way I can predict that kind of thing right on a real life system so there are certain aspects of testing that we should be very explicit and say this just seems a little bit too complicated I do not want to mimic my product behavior in my test framework let us not even bother about automating certain aspects you should be able to take a call to say this data not just data this testing itself is extremely complex in my test environments I will do whatever required unit testing integration testing with the seeded data type of testing to ensure for 10 different users I see 10 different pages randomly I will give any name and I should see that type of information but anything beyond that it does not make sense to automate potentially it might be a good call to take about the cost value aspect as well right you do not want to replicate your product implementation behavior in your test framework to ensure the testing is also going across in some cases you have to but not in all cases so again data can become very complex in different types of products EMR based products patient information doctors appointments or medical treatments whatever it is a completely different set of information patient history medical history around that family history comes in place what are past appointments might be there prescriptions around that the allergies that might be that is such complexity around this how do you test this kind of a product big data there have been lot of users of analytics and big data in real world of late how do you really test those what kind of data do I want to provide as test input to a big data system and what type of output do I see from there what type of data is required to say this is a chart that is generated and yes this is correct has anyone tested any visual type of product for that matter map based or such type of complex graph charts these are realities the game testing that's another really complex one right and automation is the key to make these products successful as well that means there is definitely a way to do this but not from a traditional perspective we have to think holistically that's what it really comes down to the reason I said these case studies is to really re-emphasize on what already you had or know in your mind the data is complex I just wanted to expand that horizon from just your context there is many more things out in the world next project or product you might be working on might be completely different and you might need to rethink your approach completely with that in mind let's look at some core samples now everyone understands code in the room yeah java ruby any coding thing is fine again the intention of showing this code is to demonstrate certain types of test data approaches that you can potentially take in your test frameworks the implementation is not important it's just the concept where to put your data and how do you model your data okay so let's look at this so the first most easy thing that can be done again the what exactly the code is doing does not matter but what we are saying this is a test method itself java unit page test and what we are doing in the test is we are specifying some patient information related to patient what the patient information is and that I am going to use in my test input something to drive creation of a new patient this is the first most common thing that can be done when I am doing automation I start doing automation I don't want to think too much over engineer too much about the data side of things or config files or whatever data files might be there let's start by building a test data as specified I am using the data to proceed in my test implementation it works very well anyone has not done this approach has not followed this approach specifying data in the test itself so why would you not follow this approach if there is change in data you will have to change the code ok we will come back to that one hold on someone said sorry one multiple times what if it is a case about the appointment type product right I don't care if it is reused again no sorry one minute different tests expect different type of test data so this is one test which is using this test data no but why I just want to create a patient information once that is the main aspect I am saying if it is an appointment type of product then it is ok what is wrong in specifying like this sorry you are saying something duplicate thing right ok maybe I say whatever I create over here I am going to delete off in the tear down ok so what it comes down to is I for sure do not see any disadvantage in this test if this is just one test I can create the same patient hundreds of times a product is ok maybe I will clean up the database afterwards I don't care assumptions are very important over here we are assuming a lot of behavior of complex systems when we are doing this if for the first test that I am writing I end up building a massive infrastructure of no duplicate data whatever else I am spending a lot of time on things which are potentially not needed right now where what if the requirement changes how often do you know requirements do not change requirements always change point is do what is expected at that point in time ok your aspect about to change any test data you need to change code what is the alternative to that ok ok conflict file a separate file what we are talking about right is that file also checked into code positive version control system right so that means you still need to change that file you still need to rebuild the product redeploy the product or whatever change is required regardless it still is not going to solve too much so I understand so ok it's not that I am saying this is the right way or this is the wrong way context determines that ok people working on the product on the framework determines what is going to be right or wrong even if it is in a separate conflict file that conflict file can be of any format the person who puts data inside over there puts in an extra line new line or a typo over there problem is still going to be there right it comes on to the risk that comes along with it and of course no product is as simple as just saying one patient information is going to be enough so eventually I will need to move into a different pattern of saying this works now what's next to take a step by step process for that right and that's what typically happens that you would provide data ensure it works and then ok let me now move it to a different type of file or a different place where I am going to store my data and my reason might be I want to probably have different types of data over there for whatever reasons as well right so you will start evolving in that fashion another example ok I think this is a cucumber example where you have given when then and in cucumber you can provide tables to provide the test data over there this is as good as being in code and not in code as well right because this is not really going to be compiled in some sense unless you have missed out on some of these delimiters which cucumber might itself flag as errors but otherwise compilation time things would be reduced at the same time this brings out an advantage as well as a disadvantage what are the advantages disadvantages of this so you know exactly what data is being used in the test execution right at the same time is it really important to see what data is used in the test execution depends it depends the answer is it depends right depends on who the audience is and what value is that data really bringing over there now in this case what I am saying is I want to upload data with various different attributes there are 4 3 rows over here one is a header row create 3 kind of upload with different type of data I don't really care what type of data is used my intention over here is I upload data with different types of attributes again it depends on who is really consuming it right so if my intention as a product owner is I am able to upload different types of data upload data of having different types of attribute that's what I am concerned about I don't care which 100 parameters I am passing in over there in that case this is actually noise this is reducing visibility of what BDD test is giving you have to think about these aspects there is other obvious thing that we have spoken about external files right we can have data in various different format files and just have your test pick it up saying ok this is my file name it's coming from environment variable or I have given the hard coded path whichever it might be load that file and use that data the file can again be of any format which format to choose depends on the text stack that you are using that is one second who is going to be contributing to it and how is the updates going to really keep on happening on that so for example if I using a javascript stack having JSON files is very easy because I just say require that JSON file I can access all the nodes attributes of that JSON file directly in code however if it's some different format like CSV format I have to load the CSV file convert it into some manageable objects that I can interact with so again what format you use is very important another interesting aspect what I have seen quickly show that as well so this is something that I have done which has helped me a lot what type of minimal information is essential for knowing what the test is doing provide only that information the rest let the framework take care of loading that aspect so for example I am saying I want to create a new individual customer this one the contact information entity type is contact information section to use as individual one addresses and something else what this means is in my framework these are JSON files in this particular case but it can be anything that you really want to implement what I have done is I have got a JSON file having the same name the entity file type that I have provided and the value of that was which section to use if I say BNERES1 this is the address I want that much information might be sufficient to understand what the intent of the test is okay the other aspect is of this you could say now here comes a duplicate information aspect right I cannot create the same customer multiple times so what I will do is I specified the data in code in some file anyway file or what I am going to say is based on the section am I randomizing or not if I say yes my framework knows what the entity type contact information I need to randomize certain information which information is important for me to randomize to be the first name last name email address that is important for me to randomize and the framework will read this data from the JSON file, apply some logic on top of that, manipulate that data to say Anand Bhagmar has now become Anand 1 Bhagmar 1 and that is the data I am going to use to create a new customer so the framework is deeply tied into your product implementation anyway so might as well leverage that aspect and knowledge of the domain knowledge of the domain and implement it in your framework in a minimalistic way to support that okay so these are some examples of how you can provide data and validate as well we did not really speak about validation or it goes very much hand in hand out of that if I am able to specify a complex entity type like a customer or address or anything else I will be able to think about the equal type of validation also from that we can specify it in similar formats okay so what did we observe there are different ways to specify this in test implementation where in my page object for example I am saying login and my username is hard I am always going to login using this that is one in test specification or intent in my test annotation or in my cucumber feature file I specified over there it can be in code but in separate files or data structures could be java classes enums whatever really bits that particular text pack that you are using it can be in external files decent files, yaml files, whichever other files that might be there I am sure you know more of these file types than what I do it could also be a database someone mentioned earlier on a production copy of the data you could leverage that as well what becomes important is how do you choose which format makes sense you have to think about what is going to be easy to specify I don't need to be a rocket scientist to specify test data that means I have created a very specialized role in my organization in my team that means I can never go on a leave if I go everyone's work is going to stop which is not really a good place to be in because I cannot be involved in doing different things as well so it has to be easy to specify for everyone it has to be easy to read and consume as well for individuals looking at the code as well as for the framework to take it and proceed from it you need to be able to override the values easily of course it depends on the context of the product if you need to override or make random values out of certain things you should be able to do that easily looking at that randomize is one example so override might be okay in my I've got my base data set what a customer information looks like it's always going to be anand, bagmar, punay whatever that address information is but now I want to say I want to create this for ruchika what does it mean all information is same I'm going to override certain values and use the rest around that could be one other it has to be usable of course it cannot be so complex but again it's not easy to understand or reuse some tips for implementation of this kind of consistent ways it will start off in one way I started off putting my test data in the test intent itself or in the implementation itself it's fine to start off but never leave it at that state evolve based on what the new understanding is what you understand as a team what is adding value or not evolve and don't just evolve for the new set of scripts that you write also make changes to what was existing so that you're not leaving stale code or different ways of specifying data around ok so refactoring is a key to making sure it's going to be consistent around you have to think about reading the data as business entities if I want to purchase a book on amazon don't say ok load entity from file what entity am I reading if I look at the code it should help me say ok I'm reading a book entity from file and that's what I'm going to use to use business terminology business domain objects in your test data itself it will help you relate and correlate with what the product is doing what the development team is doing what the business analyst or product owner expect out of it it is all similar line override as appropriate create DSLs to give meaningful data I want to read customer of this type I want to load customer information of this type ok make code as readable as possible it will help in the maintenance side of things which means you don't need documentation also to support that because no one reads documentation and use this in test implementation implement utilities on top of the test data to say ok I'm loading this type of data I have loaded I want to create a customer ok which means I have to read a customer data from json files for example after creation I want to validate the created customer so again I have got the similar object now customer from what has been created if you build utilities like equals copy find you should be able to say ok is the customer I created equals to the customer that I wanted it's a DSL like equals operator spring equals we have now we have it on objects and you can have complex object comparison that you can find out exactly which field might be different for that which again makes it very helpful in debugging finding good cause and fixing it as well ok so which is the best pattern to use completely depends completely depends on the context understand the context you have to spend time in understanding context writing code is very easy writing good code is very difficult there is a big difference in that and if you do not spend time in your design test design test data design it will be a problem going forward last thing to leave you with to help in manual testing I don't know how many people are aware of these there are lot of plugins and tools one example is autofill plugin in Chrome similar plugin is available in Firefox as well if you have to do a lot of form filling during testing in your web pages you can train this particular plugin to say what type of data I want to fill automatically come to that form click a button automatically all form data is filled and you can proceed to the next step that is one of the most painful things when you are testing web pages at least it forms in web pages such kind of plugins help a lot sorry I had to rush through a lot of the code I had many more code samples to show but in interest of time I had to proceed very quickly the data files again there are various different types environment based you can have these are environments because the question around test data for different environments either you could have different environment based directly to say this is what my test data is going to be for each environment that is very tricky and painful to maintain ideally or the best way probably would be have the same test data into different environments by test data we are seeing the metadata right I want to create a customer of 5 types I can create a customer of 5 types those 5 types if they are consistent across all the 5 environments that I have it becomes easy I am just saying I want to create customer anand for type A customer ruchika for type B for type C whatever it is the same thing it helps in that way so if everyone is ok we are actually done with the session I am done with my content but if you are ok we can continue talking about these things those of want to be thankful for your time ok but so in that case right let me quickly show you an example so what I have over here is in my data sources in my data sources I have got various different types of environments itself each environment now this is a ruby example each environment has got its own configuration what are the things it could have ok there is also common data file which is common across to everyone ok now what I do is any environment that I go through a default environment is always going to get common data based on whichever other environment I have I will be overriding or providing additional information to whatever is there that is from environment side of things likewise from the data side of things as well you could do that I have my set of users which is different so for example I want to run sanity test in production as well right my production credential is going to be different than what my test environment credentials are so I have environment specific data files and based on the environment I will pick that and proceed yeah there are five screens for example and it is difficult for me to just say directly without really looking at the screens on mobile or the legacy form but there could be couple of phase you can approach this maybe there is some common set of data across both of these that common aspect I am going to provide in one phase which is going to be used for mobile and the rest is going to be in the legacy so if my environment is not mobile I am going to use common plus whatever other things are there and otherwise I will use this one second thing you can create components or rather logical sections of course when I am providing to create a customer there is a lot of information personal information address information dependent information for example right these are sections each section potentially represents a screen on mobile for that matter there is some form of mapping so you could think about it from that way specify a test data in such a way based on logical section if it is a traditional or legacy page which is everything in together I am just going to go through all of them and specify data if it is screen based I know which logical section I am working that might be another option sorry you had a so factory girl or factory methods which are there you can create data based on what the models are what the database models are connect to that database model and you can create whatever type of objects you want n number of objects any data that you create is not going to be ever like production data okay that is something that we have to understand data becomes even more difficult in creating using factory objects the dependencies and those kind of things right create realistic data the best way is to really understand production really understand the user and think about those different aspects can you use a production snapshot anonymize it and use that in your testing itself if you are using that form but otherwise creating data you need to spend time understanding what the real users are what is it in production what different cases can happen only then you can do that sorry one in some cases it is fine the risk so the risk with populating database directly is huge why because there is usually a lot of layers on top of a lot of layers on top of the database which has business rules domain logic implemented on top of it which does validations as well if you are entering directly in the database like seeding of database right that is possible absolutely absolutely again the risk is that you are always going to be creating data which is bypassing all the rules validations of sorts special characters any typos would also get in the database regardless of what rules are there so you have to be very careful with it read access absolutely as long as you have the same read access in product as well not a problem but rather in all the environments you should have the read access only then the test will be repeatable across any environment so sorry to stop we can continue the conversation afterwards or after the session thank you for your time