UI automation – it’s not free – Aditi Mulay | SeleniumConf Chicago


ADITI: Thank you. Thank you, Lydia, and thanks a lot, everyone. I understand this is the third back-to-back
session that you guys are attending, so I hope you guys are awake, you had your coffee
breaks, and my presentation will be interesting enough not to put you to sleep! A quick brief introduction. Lydia gave some idea about where I come from. I’ve been in the field of automation for more
than ten-plus careers. I started off as a developer, but then I loved
automation enough to switch sides. For the last ten years, I’ve been doing automation,
leading and managing test teams, execution teams, trying to roll out best practises in
my team. I’ve worked out the sectors to date, and I
currently work in a government consulting company called Carson Solutions, based in
Virginia. My office hours are not today, they’re tomorrow. You can reach out to me on LinkedIn and Twitter. If you see me, let me know at any time. With this brief introduction out of the way,
let me get started on the main topic, UI automation, and why it’s not free. Why is your automation popular? We have 650 people gathered here today, because
automation is popular, everyone is using it, and we’re using it in multiple ways. But just a quick two-minute intro on why it’s
so popular. One of the things is it is open source. Since Selenium was introduced ten-plus years
ago, it was been used in so many teams and extensively. When someone talks about automation, the first
thing they think of is UI automation. It’s like automation is synonymous with front-end
automation. The best thing about the Selenium WebDriver
is that it’s open source, and the tools you need to work with, Java, Python, these are
available to you free of charge. There’s lots of online documentation available
to us, so someone tells you to start automation, this is the way to go. So it’s really, really popular because of
all these features. Another big advantage with this is functionality
testing. This is the most important aspect that UI
provides to us. You’re imitating the user interactions, what
the end-user is going to use on your web application, you’re using those scenarios. That’s a big step with UI automation. One fun fact about this, I had taken my kid
to work on the Take Your Child to Work Day. He was a five-year-old at the time. I showed him a test running on the browser
without me touching my keyboard or me typing anything. He literally thought it was magic. So it was a pretty good feeling for me for
me to think that he thinks his mum performs magic at work. I always try to put it on my r�sum� if
I can. I like the feeling that I get when I complete
one test case, I get it to run successfully for the first time on my screen. After that, I don’t want to see, sit there
watching it, just running it. I would prefer Jenkins to do that job for
me, but that’s a visual validation that you get, that you’re testing your application
when you’re doing this UI automation. These are the great things that UI provides
us. Then what happens? What is, UI also comes with its own sort of
baggage. So, before we delve deeper into what baggage
it brings and why I think it’s not free, even though there’s no license requirement, there’s
no initial investment in terms of money that you need to put in before starting UI automation,
so just a quick things, most of my work has been focused in Java, and I have worked on
Python and other scripting languages, but most Java. So all my presentation examples will have
some sort of object-orientated concepts in that. I’ve been using behavior-driven development. I might face scenarios as part of my examples. In respect of all of these things, the experience
that I have gained and the values that I’ve learned, lessons that I’ve learned out of
this, they’re not language-specific. They can apply to anyone using any language
out here. One last thing: when I talk about UI test,
I’m only talking about the automated UI test and not the manual UI test. Let’s dig deeper into the baggage that your
automation brings with it. This is something that all of us who has been
using automation is aware: long execution times. A test, if not written correctly can go on
for a long time, and the longer it runs, the more chances of failure it brings with it. It takes time for the UI to run because we
know the browser has to be started. You have to navigate to the page of interest,
and then perform the actions, and the validations that you need. That takes time. A test not written properly will really mess
up your whole framework. Let me give you an example. A long time back, around the time we had Selenium
1 versions, Selenium 2 was far, far in the future, our team started with automation. We decided, okay, let’s start with automation. It was the new thing to do at the time. So we started off with UI automation. These started with a basic testing functionality,
create, read, update, delete. Four things for every entity that we had in
our application. We built a framework around Selenium WebDriver,
Selenium, and then we ran it. It was pretty successful. Then we got to ask now that you have your
proof of concept ready, why don’t you guys start converting our manual regression into
automated? We took on that job. Our productivity was determined depending
on how many UI tests with manual tests we can put in the automation. It took us a lot of times. Since our productivity was on that number,
we hired a lot of people to help us with that, and, at some point, we reached our goal. This is what we had. We had around 1,000-plus tests. These were were running for 22 hours every
day. We were using parallel execution. [Laughter]. Yes, we were not using sequentially slow one
after another. We will 100 servers on the test. We had 400 agents running against those servers
to get those tests done. Our pass rate – I don’t think anyone would
guess here – was 70 per cent passing. If we ran 100 tests, 30 of those were failing. That was a huge amount of effort for us to
find out why the failure happened, to analyze the test, and to get the feedback to the development
team. That was taking us two to three days just
to figure out what went wrong. So the execution happened on day one. We figured out the problems by day four. And then the feedback went to the development
team. So, as you can see, that was not a great idea
out there. And one of the reasons why this was happening
is some of our tests were taking more than an hour to execute. We had huge workload tests which took us an
hour, so, if that test failed, we used to spend 30 to 40 minute just weight and looking
at the screen, waste, waiting and looking at the screen. If the test failed, we dug deeper in the troubleshooting. Not a great idea. Spending a lot of our time on coffee breaks. This was one of the biggest problems. Right now, I call it an experiment. This took loom a year for us to work on. Out of that, we learned quite a few lessons
that I want to share today. One of the biggest ones was what to automate. You might have heard this from a lot of people,
but this is really critical. Figuring out what is the most good automation
candidate, the best automation candidate, and then automating it rather than just blindly
converting from manual to automation. That’s something we really, really need to
take care of when doing UI automation. One of the biggest things? Too long a test, break it up. If it is running for more than five or ten
minute, break it up. Maintaining it and trouble shooting it will
always be a pain in the long run. Remove flaky tests. I think Angie, I attended her workshop in
the morning, she talked about the flaky test, but just make sure you’re not removing and
throwing it away. Make sure you pull it out of your suite, work
on it, and fix it in such a way that it’s going to be more robust, running more stable,
and then put it back into your regression suite. So this is very important, because we always
spent a lot of time on tests which are passing one week, failing another week, and there
was no change in the application code underneath for them. So these are the few important things that
we learned out of that experiment. But other than the long execution times, there
is another thing that is most important with the UI information – maintenance. A lot of people have this issue, just really
identify with this guy, because right now, I’m coming out of a project. I worked on it for two months. I was refactoring code that someone else had
written and that was not fun. Every day, I was literally ready to bang my
head against a wall. It’s like what am I doing? Why do I have to do this? Maintenance is something we all have to live
it. You can’t push the work and say ignore it
at any point. Change is the constant in life. Our application is going to change all the
time. It is not going to, the UI, the application
is not going to remain the same constantly. One of the things that happened was in one
of my teams, we had spent a lot of time and effort getting to the level of having good
automation coverage. We were in sync with the dev team and what
they were doing. When they had an announcement, we had an automation
to support that announcement. Then there was in product modernization drive. They wanted to change the whole UI. The functionality remained the same, but the
UI look was outdated, so they decided to change the UI. There went all our efforts down the drain. It was not a very good feeling. See, if I had known then when I know today
from Raj’s presentation about dynamic locators, and using AI to fix them, that would have
saved us a lot of time. As he mentioned, AI can identify the locators
which are changing, fix them, your test won’t break at all. That would have saved us a lot of time in
the maintenance. Since that was not available to us then, and
I’m hoping that moving forward, you guys all of us here will be able to leverage the AI,
that would be a great one. That will reduce a lot of strain that we have
with UI maintenance. As we all know, EU maintenance comes with
a huge cost: time, effort, and sometimes, it’s not fun to fix a code which someone else
has written. This is the biggest baggage which I feel UI
automation carries. This is one of the biggest surveys carried
out, which is the biggest challenge you have in your life as an engineer? Maintenance was the one they answered with. This is one of the biggest baggages that UI
has. In addition to these two, there are a few
more things that come up. One of them is when you’re testing the UI
from the front-end, you’re not always testing the business logic. Sometimes, your business logic is hidden in
the web services layer. Sometimes, it’s there in the database layer. It is in the stored procedures. You may not actually be reaching that point
to test that functionality all the time. So, just testing the UI is not enough. The second thing: when you’re using the you
for testing, you cannot say that you’re done, you’re test-complete until you ran your test
on different browsers, different environments, and, if you’re in the mobile world, then against
different devices. So that’s a lot of work to say you’re test-complete. Last but not the least is scaleability. So, it’s very easy to write new tests. But at some point, you will reach a point
where the regression suite is so huge, the execution time keeps on increasing, and you’re
running into the problem that we ran in my example that I showed. Unless you have a sophisticated system which
will say, “Okay, your code has not changed in this area so I’m not going to run the test
from that area,” there might be those out there, but they’re not open source, for sure. Scaleability is a big thing that you need
to keep in mind when you’re working on your UI automation test. So, sorry, I went a little bit ahead! So, if we cannot depend on our UI automation
to help promote our build, what can happen next? A few years ago, I came across this picture. This is the pyramid as most of you might have
been aware of. It was proposed by Mike Con and is in the
book AI Testing. We have Lisa Crispin attending this conference. She’s the expert on this. You can talk to her about it. This was like a lightbulb moment for me. When I saw this image, it was like this is
exactly what I wanted to see, because at that time my team was literally drowning in the
burden of our huge UI regression suite. We had a little bit of API and extremely little
unit testing available to us. So we had the perfect anti-pattern that we
call as the ice cream cone in our team. We knew, it’s not that we were not aware on
the wrong part, but we were having a tough time convincing the decision-makers that we
need to change our strategy. We should not be focusing on our UI test for
testing the functionality. We need to do something different, we need
to diversify. When I saw this pyramid, it actually gave
us that road map, and that’s why I love this pier instead completely. So, as you can see from this pyramid, as you
go from the top to the bottom layers, your test become much, much faster. Unit tests are faster than your UI tests. They’re more stable than the UI tests, and
you get immediate feedback. Less effort, so there are a lot of advantages
if you’re pushing your test down to the lower-most level in this pyramid. Since looking at the pyramid, and I was able
to convince my team-mates to join this model, I have been literally using it as my road
map. So, the biggest thing that this is, it’s just
a road map. You can use it or customize it depending on
how your team works, and how exactly you need to you need it to work for you. It least gives that you guidelines. Let’s take a deep look at each of the layers
that we have in this pyramid, but before we go there, I just want to get a quick idea
about how many of your teams have unit testing coverage? Some coverage. Okay. And how many of you have 80 per cent code
coverage, unit test? Wow. You see! So it was almost 80 fares of you people here,
almost 80 per cent of you people here had the unit testing. It’s not at the level that most other teams
would wish for. Unit testing from my point of view, they’re
really critical that we could implement. They’re really granular. And they’re really helpful. Much, much faster than any of the upper layers
that we have seen. One of the things that with unit tests is
we always consider it as a developer thing. It is not something that we testers are doing,
it is like on the other side of the fence. The developers would be doing the unit test,
and then later on, the control sort of comes to us. But I sort of completely don’t agree with
that type of approach. Quality is a team responsibility. So any of this we can do it, it should be
the responsibility of the whole team, not just one part of the team. Also, one thing that I need to note is these
days, companies are looking for people who are like full stack developers. They are expecting developers to do their
automation for us. So, if that is the case, then why we as testers
and engineers we can’t move to the other side? Unit tests are the best way. They’re the nicest stepping stones we can
use to, if you want to learn more about development, or technical stuff. They’re simple to write, and you always have
the development team to help you out if need be. Luckily for me, all my development teams have
been really, really great with help, and there’s been a lot of collaboration with them. So I always feel unit tests should be given
more importance in our tester domain, even though it is considered to be on the other
side of the fence. Another thing with unit tests, most of the
time, it’s a good practise to start off unit testing if you’re starting an application
from scratch, best practise. I need to have a unit test and if I’m starting
an application. That’s not always possible. Most of the time we start in teams that have
testing in place or a bare minimum testing in there. In those scenarios, we can try to roll out
this best practise for every announcement that goes out, at least try to put unit testing
for that, so you’re not trying to do everything in one day but little by little, in small
steps, you’re trying to achieve your goal. You can start off using some tools like Sonar
Cube and Jenkins which will give you the coverage of unit test. For today, let’s say the threshold is 25 per
cent because we don’t have enough unit tests. As and when we go and increase our unit tests
repository, we can keep on increasing that thresh hold. The number that you finally stop at can be
something that may not be 100 per cent. I would like it to be 100 per cent but not
always possible. Time and resources, a lot of things come into
the picture. If it is 80 per cent, we can stop there and
at least get our unit-testing to that level. That way, you can literally leverage this
really great testing layer that we have out here. Again, Sonar Cube metrics, it’s a really great
tube not just for unit test coverage but for static code analysis and a lot of other things. You can integrate it with Jenkins, and you
can put a lot of gates and parameters, so if the threshold is not reached, your build
is not going to be promoted to the next level. Those are the few things that we can look
into when you’re looking at unit test. The next layer: API testing. Don’t get scared looking at the cat. It’s just a picture of her. It’s really, really easy to do API testing. It’s not that complicated. Again, a kick show efficient hands. How many of you have testing in your web services
layer or the API layer? Wow. This is amazing. It was missing in a few teams that I worked
on, and this is my favorite testing layer in the whole pyramid. It’s really, really great because it’s really
stable. One of the biggest things with API is, when
you’re doing APIs testing, and I’m talking about the Java REST API stuff, when there
are changes coming into API, the signature of the API is changing, you always know that
the change is coming, because there’s always going to be a paper trail. There’s going to be a change in the requirement
documentation. There’s going to be a kit available for you
that talks about that change. That’s a pretty big thing for API, because
on the UI side, you rarely sometimes get that notification that the UI is going to change. It can happen that the developer decides that
I don’t like the name of this button, or I want to change the attribute of a button,
and then, that impacts a lot of UI tests. With API, there’s very less chance of that
happening because API as such is developed by one team, consumed by not just one but
multiple others. That change is far-reaching effects, so it
will come with you in a more structured manner. You will actually see a lot of documentation,
a lot of heads-up that were your API it changing. Make sure your tests are going to break, or
make sure that you’re ready to handle that change. There’s that heads-up that we get with API
changes. That’s why they’re much more stable. The second thing is faster feedback. So, with API tests, it will it’s really much,
much faster. It’s not as fast as you are, it’s immediate
with the unit test, sorry, but it is much faster than the UI test. I wanted actually to see how fast is that
difference? So luckily, I had one application that I was
working on where you just had to log in, and, on the first page itself, there was an API
call being made behind the scenes. So I wrote one small UI test, where, actually,
I logged in, I went to that first page, I validated some data on it. I wrote one small API test also for the same
where I directly made the call to the API, parsing in the particular parameters it required,
and then verified the response. So my UI test took me around four minutes
to run. It was pretty simple but still it took four
minutes to run. While my API test, 30 seconds. So that’s a drastic difference you see right
there. 30 seconds and four minutes. You’re seeing so much time, and you’re actually
getting to test the core functionality, the core business logic of that API. So that’s a pretty big advantage with API
testing. Faster feedback, and directly you’re going
to the root of it, the functionality of your application. Lastly, these are again very easy to maintain. As I said, the changes that come in, you are
always getting the heads-up of the changes, so you don’t get blind sided by anything. I’ve rarely seen that I have to go and fix
something in the API unless the API end point has changed. I rarely have to go go and fix something. On the UI side? Yes, on the page load, multiple times. Any numbers of reasons that can happen that
I have to go and fix my test. With the API, there is a less chance of doing
that. Lastly, APIs are developed by one team, and
sometimes consumed by the same but sometimes by different teams in your application. Sometimes, in my case, it is actually being
used by another company out there, so, these are actually really good integration points. You are actually doing integration testing
when you’re testing your APIs, because they are literally like the bridge between two
applications, two modules. So, you can really sort of put a lot of effort
and put a lot of, you get a lot of confidence if you’re testing these APIs basically. So these are the reasons why I think APIs
are the best, and we should be really spending a lot of time on automating them, and testing
this particular layer. This actually gives you the bang for the buck. If you have to convince your decision-makers,
your management, or anyone, APIs are the best way to go because they are listed here. They don’t run as slow as UI tests, so you’re
saving on time, resources, maintenance resources, and so on. So you can actually convert this into a sort
of monetary matrix and show it to your managers if you want to. So, until now, I’ve been talking about API
testing. But the biggest thing is this layer also comes
takes care of web services, your web services. Recently I had this chance of actually practising
what I preach. My team had unit tests and UI tests but missing
the intermediate layer testing. We were using vistas because it was an older
application, we were using SOAP and so on. At the time, I didn’t have enough knowledge
about web services. I had worked with Rest Assured and everything,
but not Vistas and so on. I took on the challenge and I started off
very small. I stamped off using SOAP UI which is a tool,
we have a sponsor upstairs. So I started using SOAP UI. I created a test suite for my, and I added
input and assertions to it, simple assertions like schema appliance, making sure I get a
200 or a 400 response back, just the basic stuff. I had my test suite ready for me. It was running perfectly fine on my local
system. Running it locally doesn’t make it automated. You need to get it run in your pipeline to
make sure that you’re automating that particular process. So, all I did was using a tool called Maven
and some plugins in it, I was able to run the whole test suite on my Jenkins pipeline. Once I had that, that became my proof of concept. I had a report which was generated to me. It was a basic report – not a fancy one – but
it went through the end points that I had the assertions for, gave me all the errors,
and so on. So I had all of this thing just by using a
small – this was my basic demo to my team that we can do web service testing, it is
not that complicated, and we can spend time on this because it’s much, much easier to
work on this rather than spending our time only on the UI side. So that was my POC, and these were the few
things that I took into consideration, leverage SOAP UI, assertions, and run it in the pipeline. Three basic steps that I did to get my POC
out there. Once I had seen this, if you actually do a
small demo showing that something is possible, you’re highly likely to get that buy-in from
your team, your managers, and everyone. All it takes, if you put it in theory, it
may not always work. Having that small proof of concept, it will
actually get you more buy-in from everyone. A few things to keep in mind with web services
testing is there are a few things we just need network that we’re working as expected. One of them is does your API work? It’s a simple, like, does it work meaning
do I get response back? Do I get the status code? That’s all you need to make sure for. Does it work as expected? So, you’re actually passing the response that
you get from your API or web servers. Here, you might require more technical skills,
you will have to parse XML or JSON. Other tools are out there to help us examine
that if needed. You’re parsing the response looking for specific
key words or data, that’s it. What happens if your server is down? Are you getting a response back, or getting
any particular codes back? That’s all you need to test for. Even with web services, if we keep it simple,
you will get a lot of advantage out of it, and very less maintenance. With this, we come back to our favorite layer,
the UI testing layer. I spent some time telling you that UI automation
comes with its own baggage but it has a lot of advantages that it brings with it. One of the main things is end-to-end work
flows. That’s what you’re looking for when you have
a web application that you have to be able to go from point A all the way to point B
successfully in your application. Before you release it to the end-users. So, that’s the main thing that you need to
keep in mind when doing UI testing. It’s easy to go overboard and write all sorts
of tests, check every single thing through the UI. If you keep your UI testing to the end-to-end
scenarios, that will help us in the long run, reducing our maintenance workload. So this is the biggest part of how to figure
out what is the critical functionality in your application. And, that I think is the biggest task that
you have with UI, finding out what is the happy path that you need to test. Once you figure that out, writing the test,
implementing it, is, I think, pretty simple. So, let’s take this example. For the online course, we are trying to do
as an online student, I want to take, enrol in a course, take a quiz, and make sure I’m
able to submit it successfully. This is very important for online learning
system. So, these are the steps that you need to take. Create a user, enrol, perform the actions,
verify the mission was successful. To do this, it’s very easy, and I’ve seen
this happen in a loft places, that I’m doing all these things, why not start my test like
this. I create a user, I try to create the parameters,
I fail, then I create a course with good parameters, I pass, and then I start off the rest of the
process. This is like an example, but the main point
I’m trying to make here is, it’s very easy to get distracted when you’re doing your work
flows. If you try to test too many things, and try
to put too many things into your work flow, you will again end up with this problem that,
when you’re trouble-shooting it, debugging it, you will spend a lot more time than it’s
needed. Try to keep your test to the minimal. Focus on what exactly you’re trying to do
in your work flow. And, for that, this is a test automation pattern
that has been documented. There is a link to it at the end of my presentation
to the website. But, what this pattern tell us tells us is
focus on what you’re trying to do here. Even when you’re looking for a good candidate
from manual to automation, what are you trying to do there? Converting the whole manual test to automation
or trying to figure out what is the purpose of this test and then focus on implementing
that particular functionality. So one purpose pattern is a pretty important
thing that I’ve always used when I’m trying to write a test, which has a lot of complex
work flows. I literally sit down and say what am I trying
to do here? And then I move on with that. Another thing to keep in mind with UI testing
is I always try to want to make in my test more robust, and to do that, I leverage non-UI
components. Non-UI components are like database, APIs. Leverage those to do your set-up and tear-down. Once you do that, it’s easy to folks on the
navigation and the validations that you want to do. If you try to do the set-up and tear-down
using the AI, you will be spending a lot of time, and it might fail at some point stopping
the whole test. So, last thing, trust your low-level test. I’m assuming by this time, you have your API
test and your unit test in place. If you’re testing your API, is there a need
also to test the same thing from the UI? No. You can actually bypass it, and that’s what
I mean when you trust your test. If you have some testing in one layer, try
not to duplicate the same thing in the UI layer. This is one example I wanted to show about
the best way of doing scenarios. The one scenario on the left-hand side is
talking all about ways you can do. You’re trying to test the entity creation
in that side. The scenario on this side, it’s separating
it out. My scenario is pretty compact. I actually have something called this background
which is like a set-up annotation, and a set-up method you might call. In that method, I’m calling and creating my
entities that I need for my testing, and, in my scenario, I focus on my critical work
flow. Quick thing about the job ground: you can
actually leverage APIs as I mentioned, non-UI components. I’m creating a user, making an API call to
do that. You could replace this with database insert
query. You can do a lot of things with set-up and
tear-down. Any time saved in UI is always great. It is literally time is money, as they say. So, moving on to one thing. Sometimes, with end-to-end test cases, you
always get a pushback, that, for our application, testing the application is not enough. We want you to test more. This enhancement has more UI elements in it,
so you want to do more UI testing. In that case I write something I call as my
UI unit test. These are more granular than the work flows. They again focus on one clear thing. I ask myself what am I doing to test this
particular feature, and that’s the only thing I test. One example is if you log in as user 1, a
table should appear on the page, while you log in as user 2, the table should not appear
on the page. This type of test cases, I call it as my unit
test. All I’m doing is logging in as the user where
they find the elements, and that’s it. These are my unit tests. UI unit tests, as I call them. Lastly been I also leverage my UI test for
accessibility testing. Coming from a government background, I actually
have need to have compliance, and that’s what I do, multi-purpose my UI test to do accessibility
testing because otherwise I’m going on the page, going to interact with the elements,
so why not do accessibility testing at the same time? These are the few things that we want to do
as part of UI testing. Last but not the least, the cloud at the top
that you see, that’s actually talks about manual testing, but it’s also something that
can be used for exploratory testing. I think that’s a very important term that’s
gaining a lot of traction in our testing community. The difference between manual and exploratory
is that manual has more regimented test cases. You have your use case and your spreadsheet
which tells you there are other things that you need to do, and these are the things that
you should do out of the step you’ve taken. Exploratory testing on the other hand is more
as the word suggests, you’re exploring the application. The way I have done exploratory testing with
my teams is we used to gather our whole team in a room for the duration of just one hour,
and we just grabbed popcorn, chips, something, just to, it was more an informal affair, and
we just looked it over at the enhancement we planned on rolling out, just that enhancement. We had our business analyst, product owners,
texts, whoever was – architects, whoever was involved, we pulled that in. We did something you might know: bug bash. It was a type of exploratory testing for us. Some of us were knew, exploring the application,
some of us were exports with that particular feature, and we were testing it, but it was
a giant effort, and the biggest advantage of that was we got information, we got clarification
from the actual people who are talking about the end-users. We got feedback from people who are new to
the application telling us,”Oh, I’m not sure what that button is supposed to do, it’s not
self-explanatory, the UX is not friendly.” We got feedback from that experience. We built up rapport with our team which normally
we don’t get time if you’re just working in your cube doing your own stuff. Even the planning, and stuff, it’s more formal. This was more informal, and built those bridges
we could really use later on. So this is a very important thing, and I would
suggest we at least try it out in your teams if you haven’t done so. It may not be possible for all the enhancement
or every release that goes out, but especially for a release which is more UI-centric, this
is a really good way to go, rather than writing, sitting and writing automation tests all the
time. Another thing is something called this hackathon. I put it here, although does it actually fall
under exploratory testing? Hackathon, just a quick background. It was done in one of my teams where our teams
were diverse. We were not just like geographically diverse,
we were on the East Coast, West Coast, Europe, and other offshore countries. So, it was very difficult to get our product
to roll out on time. We were facing delays with co-ordination,
communication, and so on. So, our management decided to bring all of
us together in one location for aure ration of five days, and those five days were spent
coding, hacking, getting everything that we could get – at least get our questions answered. We didn’t end up with a complete solution,
but we at least got those main things, the things in our work flow ironed out during
those five days. Again, in that, we built a lot of personal
relationships with the rest of the teams, the rest of the teams, and sorry, rest of
the members in other teams, which who then we could reach out to if needed, because just
talking on the email, or Skype, it is not enough. You need that face-to-face interaction to
say,”I know this guy, I can reach out to him and get the informing I needed.” So that actually was a very good experience. I would really suggest, if you can do that,
that is actually hackathon just after this session, so, give it a try if you haven’t
done so before. It’s a great learning exercise and a great
tool for testing. With this, I would like to conclude my presentation
with this last slide. These are the pointers I would wish you guys
take back from my talk. One of the things is diversify your testing,
don’t just depend on UI to promote your bills as you’ve seen. Use the map to tweak and it the way you want
for your guiding map. It’s a good way of testing, I think a lot
of people here I saw actually are leveraging it, so that is great to see that. With UI, try to use your unit-testing if your
push comes to shove and you have to write your unit test, but otherwise stick to the
work flows and use APIs and web services for your data service and clean-up. It’s really fun and a good exercise to try
out. With that, I would like to end my presentation. I would like to thank you the SeleniumConf
and organizers to give me this opportunity, especially Ashley, and I would like to thank
all of you who have been listening to me for the last 40 minutes. Thank you! [Applause].

1 thought on “UI automation – it’s not free – Aditi Mulay | SeleniumConf Chicago

  1. Hi Aditi, nice presentation! The idea of having automation engineers writing Unit Tests to help improve the coverage sounds interesting. But it will also require more resources. Is your company doing this? And out of curiosity, what is the Developer/Automation Engineers Ratio in your current organization?

Leave a Reply

Your email address will not be published. Required fields are marked *