So the question that I want to post to you now is do you believe that with the keyword
driven approach that these tests have illuminated enough possible sources of change to actually
be stable and not be classified as brutal again.
Sadly I don't think so.
I believe that key words are given to us although they are a amazing step up from a record to
us.
They still have a ton of problems that will cause you to spend a lot of time debugging
and not be able to maintain your automation frameworks.
I remember many years ago when I was writing Cambridge given to us it was actually utilizing
QBP.
I remember how hard over time we had automating tests utilizing the keywords or in the framework
can be we're doing a pretty good job.
We had a good team of really smart people writing key driven tests because we thought
that that's the best approach and we still would spend weeks trying to make a single
test pass.
Granted we were doing a lot of things wrong but again we were all utilizing that keyboard
driven approach and we were wondering why is this so hard.
Why is our automation so brittle that it takes us weeks to put out an automated functional
to us.
It was really sad but it is a good lesson because we thought that was the right way
we thought that this is the way that it should be done without realizing it.
And that's what I want to help you guys here with today to be able to understand that there
are better ways regardless.
So the first main issue that I see with the coverage given to us is that they are still
wet.
We are still writing everything twice.
They're not dry and they don't follow the DRY principle.
For example take a look at test number one lines 19 and 20.
How does two methods along even with this verification they are repeated here and test
two.
And they're also repeated in tests three in fact almost this entire test is of repetition
in each of the tests.
And yes of course I know that these tests are literally duplicates because I just copied
and pasted them.
But you can see how from scenario to Scenario A lot of steps can still be repeated Right
because our steps were just logging into an application.
That's one of the very basic features of every application and we can take it into many different
directions from there.
We can start logging in and then validating that a video opens we can start logging in
and then validating that we can select the video we can go in validate that we can go
through an entire course.
There are many different kinds of functionalities but they all have this log in functionality
in common and it is all being repeated through all of our tests.
So whenever we make any kinds of changes for example a synchronization change because our
application is now slower or for whatever reason maybe it's we introduced a bug that's
making our application slower.
So now for example if we have to deal with the synchronization point we might need to
come here and replace this implicit wait with an explicit way to be able to better handle
the loading of the application.
And so now we have to apply this change to all of our five hundred tests as opposed to
a single place.
I actually had that happen to me recently where I had a bunch of Turse I think a few
thousand times that were running.
And then when I look back at the results I saw that there were about 100000 that had
actually failed.
And it was really interesting to me that that failed because I was like what's going on.
And then when I further analyzed why the tests failed it was actually because our application
I think had gotten a little bit slower.
And so what had happened was the test was running too fast for the application.
And so now it was failing because there was a bad synchronization point and saw what I
had to do was go away and of the the synchronization point and then that fixed my 100 Tests.
The beauty of it was that I fixed the synchronization pointed at a single place rather than all
of these other places and all of the tests.
And that made my fix really quick and really easy and then the test passed right after
I finished running them.
But it does happen synchronization issues happen all the time.
And my point is that you need to be prepared for those changes as good as you can.
And unfortunately the key words in the framework approach doesn't really prepare us as well
as it can.
Some other issues that can actually occur with a keyword driven framework that will
break all of your tests our flow changes.
Right so here in my in this current flow I'm logging in but I am logging in with a browser
in a standard maximum window size.
What if now I needed a test that logs in with a browser in half size would if I knew to
have the logs in with a browser in a mobile window write that functionality is different
and it needs to be handled different.
And so what am I going to do am I going to create a completely new keyboard to be able
to log in in a different kind of mode or should I have one method that handles both of the
situations depending on which situation you're in.
I would argue that the method is a better approach because you decrease your duplication
of code and all of the methods and now you're just stuck with one method as opposed to two
methods that you need to maintain.
But the final piece of the puzzle that can actually break a bunch of our automated functional
tests is a change to our actual driver.
Yeah that's right.
Selenium can disappear at some point it may no longer be relevant and you might need to
replace it.
So all of our tests that are using these find elements all of these hard coded methods for
selenium web driver they're going to break and you're going to need to replace that with
an entirely new driver.
And if you don't believe me that the driver can change.
Take a look at Google Trends with me for a second.
I'm sure that a lot of you guys remember QBP right.
And here in Google Trends what I did was I just compared the popularity of cuchi versus
selenium web driver and down here you can see GGP versus solanine web drive or searches
over time.
So take a look back in 2011 TGP used to be really popular and selenium web driver did
it.
And now over time that is actually reverse where so many drivers are becoming more popular
than GTP.
Yes those are Google search trends.
But what it should also tell you is that Q-tips is on the decline and less and less people
are starting to use it.
And so any web drivers the opposite.
So if you are an individual like myself who had frameworks coded in key you T.P.
what the heck are you going to do.
You either need to maintain those frameworks in T.P. and have less robust code or you need
to transition everything over to sell any and web driver.
And if you coded different frameworks you were not insulated from that change.
The other factor is that I can actually say where so many drivers actually now more popular
than QBP is if you want to look at job trends.
I pulled up here dice and search for and web driver just in the Washington D.C. area and
you can see that it has 150 positions with solatium of driver.
And then also I pulled up dice with QBP in Washington D.C. and you can see that it has
42 positions so so any web job actually is becoming more popular is becoming more relevant.
In fact almost 4 to one jobs for so many drivers compared to QBP.
So like I said cuchi is dying.
So everybody that has a cute framework or is maintaining an GTP framework at some point
they're either going to need to get rid of it and replace it with selenium web driver
or they're just going to have to maintain it until the technology becomes irrelevant.
And so that's going to be a super painful change to the thousands of tests that exist
there to do automated functional testing that are completely unprepared for the changes.