Workshop Experience: Certified Selenium Engineer

 

This writing is my experience report of workshop Certified Selenium Engineer conducted by Verity Software and Rahul Verma as a trainer.  I could not attend the scheduled workshop, once.  Vinay Baid from Verify Software allowed me to attend the workshop on another date.  I thank him and Verity Software for the help.  In this, conversation, Anil Nahata helped me by coordination and I thank him as well.

Disclaimer

I have not been paid or asked to write this blog post.  I have decided to share my experience and take away from the workshop which I have attended.  I'm doing it, to have my learning experience recorded in brief.  As well, it can help the trainer in a way that her/his workshop will reach more people.

About the workshop

This workshop is on Selenium having the title "Certified Selenium Engineer".  More information about the workshop can be found on the website of Verity Software.  Per my experience, the Verity team is approachable and they coordinate learning the context of workshop attendee.

It was a three days workshop and it was conducted in a hotel at Koramangala, Bengaluru.  Following the workshop, there was a mock test and then a certification test on the third day.  The questions needed thinking to solve and to analyze and choose an answer  Not all questions were straight.

I did not feel the paper as tough.  It engaged me well and made me think.  On understanding the fundamentals well and with the practice that one does in the workshop, the test paper can be easily attempted.

Why did I attend the workshop?

Here are my reasons why I attended this workshop

• Rahul Verma
• I see Rahul Verma as a serious and thoughtful practitioner in the Software Testing space
• Listening to what he has to share in the workshop
• I know he will not just talk in and around Selenium topics that were mentioned in the workshop details
• What can I unlearn and learn listening to him?
• There will more and beyond Selenium, in using Selenium better for sure
• I needed this; I wanted to listen to this; I wanted to see how he thinks and interprets
• I said myself do not be biased with words and thoughts of Rahul Verma
• Think about what he says
• Interpret on what he says
• Understand what he says
• Think what you (Ravisuriya) think
• I see whatever he spoke in the workshop, it makes very senseful

What I made out of this workshop?

I got what I wanted from the workshop.  I made sure, I make most of it and I was attentive to it.  I share a few of them here:

• I said myself come with an open mind; forget whatever you know for a while; unlearn and look from a fresh mind
• I did not open my mouth to talk except for asking questions; I had kept my mind open and attentive
• I did not like missing any word spoken in the tutorial be it from trainer and attendees
• Rahul Verma shared beyond Selenium's basics
• Rahul Verma spoke about Programming in fact and how to use programming for making the best out of a Selenium library
• Starting with
• What is the web?
• How the web works?
• What the web page is?
• What is DOM, HTML, CSS?
• What is an element, tag, attribute, and value in the HTML?
• What constitutes the browser?
• What is Selenium?
• The architecture of Selenium and JSON Wire Protocol
• Design Patterns and Design Pattern used in Selenium library
• What is said in the syllabus were covered with examples
• Not just examples of automation using Selenium
• But also with an example of what to do and not do - this is a treasure!
• This is what I want to listen from the practitioner's experience
• Framework and Test Authoring
• If I did write everything in detail and how the topics were discussed, it might look like an exaggeration; but it is no exaggeration
• It has to be experienced at least once from the practitioner's training

My experience and learning

Whatever Rahul Verma spoke it is available in books and web content that talks about Selenium.  The difference is

• Concepts were said in simple terms
• Examples shared for the topic spoken were from his work experience
• Programming - do's and don'ts with each example and concepts
• Keeping it simple, workable, and learnable
• If want to be strong in the fundamentals of Selenium, this workshop helps

For the kind of my mindset of learning style and expectation, this workshop from the trainer gave me satisfaction.  I'm happy!

Not a Senseful Question: Is API Testing important than UI Testing?

It is usual for a tester/SDET to come across the question and discussion around API Testing versus UI Testing, asking which is better or more important. More questions which one might cross on the same topic are as below:

• Which testing helps the tester to find more bugs and faster -- API Testing or UI Testing? 
• Which testing is quicker and effective -- API Testing or UI Testing?
• Which testing is less flaky -- API Testing or UI Testing?
• Which testing helps to find risks and problems early in the development cycle -- API Testing or UI Testing?
• Which testing has less dependency and maintenance comparatively -- API Testing or UI Testing?
• Which testing provides quicker feedback on the health of product -- API Testing or UI Testing?
• Which testing needs little efforts and investment to build, execute and maintain -- API Testing or UI Testing?
• A tester can start testing with API before the UI is available, so which testing is effective -- API Testing or UI Testing?
• If API Testing is covered no need for UI Testing?
• Which tests cases while programming is in progress or yet to start -- API Testing or UI Testing?
• The APIs can be used to test web application service logic, so which testing is effective -- API Testing or UI Testing?
• UI affects the UX, so UI Testing is required; don't the API affect the UX? If both affect the UX, which testing is of priority and more influential?
• The testing of a system for data using API is possible before the UI is available, so which testing is effective -- API Testing or UI Testing?
• One can say it is functional just by using API with no UI, so which testing is effective -- API Testing or UI Testing?
• API Testing can reveal more details of services and web application server, which UI testing cannot with or without load balancers, so which testing is effective -- API Testing or UI Testing?

I hope that was not a big list of questions, and this list keeps growing if I share what I have come across as part of the reasoning. Probably, you might as well have witnessed such questions when discussing the API Testing over UI Testing.

The word "Testing" is vague!

I learn the word "Testing" is vague when used with no precise context and expectation. For example, "API Testing" does tell that subject of discussion and work is around API in one's testing. Also, it does not communicate precisely -- what in the testing of APIs. The same is for the testing of UI.

In most of our discussion, we see such words loosely said in conversation. As a result, it may lead to ineffective thoughts. For example, "Is API Testing important than UI Testing?". To me, this question does not tell -- What to provide as a response, so one can think about it and decide? On what basis the comparison is made for the effectiveness and in which context?

We can test API and UI for quality criteria as -- Functional, Performance, UX, Security, Accessibility, Simplicity, Usability, and more. Yes, we can test the APIs for UX.

How can one reduce the vagueness when the words become too casual?  

When used the word "testing" providing the context of expectation, it can reduce the vagueness in communication. For example, "Testing for the API functionality is important than the functionality of UI?" Now you see the difference and clarity with this question in comparison to -- "Is API Testing important than UI Testing?"

API and UI are individual operating entities in a System

To benefit the reader here, let me take Mercedes-Benz's car assembly line illustration. What can relate to APIs and UI here? Can the exterior of the car be seen as UI and internal as multiple APIs which take the input and respond for movement of the car?

So the question here is:

• Testing of functionality just for the internals of a car is enough?
• By doing so, there is no need to test for the exterior (UI) of the car?
• If yes, why would skilled people work in designing and testing the UI that is exterior of a car, constructing various scenarios?
• Testing for the security of a car internal is sufficient? Should the UI of also of a car be subjected to security tests? Ask the same for performance, functionality, and UX.

I have heard there OTA updates for the software installed in a car. This software can control the internal and external of a car is what I see.

I learn the API and UI are two individual entities of a system. Testing of one entity will not overrule the need for testing of other entities. Instead, it can complement and help testing better. If thinking testing of API is enough and no need to test UI, then asking what tests look repetitive is logical.

Why would people invest so much money, time, and resources in building the interactive UI? Why the world faces the problem with fragmentation in each segment? Having the engineering focus on the API segment alone is enough?

Why we usually have two teams working on APIs and front-end?  Why each of these teams are specialized and skilled in working at their areas and not in both?  If testing for API is sufficient, why there is a dedicated team for programming the front-end and its testing?  Answering these questions can arrive one at having a clarity.

Should the client be seen as UI?

What is UI in this context? The client end of the system will have code for:

• UI
• Rendering of UI based on context
• Processing the input
• Processing the output
• Processing and interacting with peripherals and its event
• And much more

To imagine the client's complexity, look at the exterior of your mobile phone device and how it interacts with internals for the input you provide. Think about the Push Notification you receive via an API and how it appears as UI in the notification tray. How acting upon the push notification in UI will respond? It looks simple case but not so when it comes to the handling of UI.

Seeing the client as UI and an endpoint to input the data and display is reasonable. But confining only to that will blind one. What was the need for the Developer Tool in a browser, if the API testing was sufficient? Every piece i.e. each entity in the software system is complex. Testing of one will not override the need for the other entity.

UI fails as hard as the API

I have been working on the server end and as well client end. I have experienced API functioning well but the client fails though it abides by contract. Should the client be seen as just UI?

The attributes of API will connect and communicate with the attributes of UI. If the API is functional and it does what is expected does not mean the client will be functional. The API is secure does not mean the client is secure. The API (service) is doing better in performance does not mean the client is also performing well. The UX can be annoying by the API while the UX of the client is well received. The context in which API is tested in isolation is different from the testing of a client.

To share one experience of me, the user entered the insurance details as in the insurance card. The API internally did handle the details differently in the presentation. As a result, the next time when API responded with insurance detail, the client crashed. It was the same data but presented in a different way which the client did not accept or understand. But when tested the API in isolation, API accepted the data in both formats. Then the business wanted the detail as expected by the client and not how the API presented it. Could the testing of API alone help me to learn the problem at the client end here? The API was vulnerable but not the client in one case. I used the API as an entry point for the attack. Eventually, the impact was reflected in UI with the response.

I have more such examples from my experiences, to say API and UI are two different entities. Testing for one in any quality criteria will not override the need for testing of the other. But it helps me to plan and design my tests well knowing them individually and how both interact.

How to respond for -- API Testing or UI Testing?

• Both are distinct, important, and needed
• Testing of each provide unique information and value
• Ask details for what to test and what is expected out of testing
• Rephrase the question asked to better one which is explicit with clarity
• Myths:
• Testing for API is important than testing for client
• Testing for API is sufficient and no need to test for client
• Testing for API will cover data which client do not cover
• As the automation pyramid talks of Unit, Integration (API) and UI layers, it is confused the client is UI layer.  UI is one part of the client and not the whole.
• Testing for API finds unique information which may or may not be found by testing client
• Identify what to test in these two distinct layers
• Both of these layers have their own state and behaviorial differences
• So trying to mock with stubs on other layer be it from API or from client, may always have something critical unlearned
• When testing in this way, usually the focus is one element of a software and so it is called Unit Testing
• Testing for the APIs and testing for the client have distinct weight and importance