Before checking this out, check out my other article where I have explained how I organised my framework folder structure.

How I organised my tests in my test framework?

The Environment Variables that I used

In total, I have used only three environment variables. They are FEATURES, TAGS and ENV. Environment variables must be passed in capital letters before the actual command like this:-

TAGS=<tags> npm test

where <tags> are the list of tags to be run. You can refer to https://cucumber.io/docs/cucumber/api/?sbsearch=tags#tags to learn how to pass tags.

I collect these environment variables and initialise a global variable that will be used in my cucumber.js file. Here is how I initialised them in env.js file.

// This file contains all environment variable declarations

// Speicify Features to Run
global.features_to_run = 'features'
if(process.env.FEATURES != undefined){
    global.features_to_run = 'features/' + process.env.FEATURES
}

// Speicify Tags to Run
global.tags_to_run = '--tags "not @blocked"'
if(process.env.TAGS != undefined){
    global.tags_to_run = '--tags ' + `"${process.env.TAGS}"`
}

// Speicify the environment for which to Run
global.env = 'local'
if(process.env.ENV != undefined){
    global.env = process.env.ENV
}

Here is how I consume them in the cucumber.js file

module.exports = {
    default: `-f json:${json_report_path} --format-options '{"snippetInterface": "synchronous"}' --require step_definitions --require library --require features ${features_to_run} ${tags_to_run}`
}

This way if tags are passed on runtime, only the test cases with the passed tags will be executed and if a particular feature file path is specified, then only that feature will be executed. I use the env variable to read from env.json.

The Global Variables that I used

I use a lot of global variables. Most of them can be avoided and it is said that it is not a good practice to use too many global variables. But still, I use them because they are much more convenient and can be used across all files. I initialise them as a first step in executing my test suite. How do I do that? I include

require('./library/support/globals')

it as the first line in my cucumber.js file as it is the first file to get executed.

This is how my globals.js looks like:-

// This file contains all global declarations

// cucumber related initialisations 
const {Given, When, Then} = require('@cucumber/cucumber');
global.Given = Given;
global.When = When;
global.Then = Then;

// for assertions
global.assert = require('assert');
const { expect } = require('chai')
global.expect = expect

// for time
global.moment = require('moment');

// common name for every generated file
global.running_time = moment().format('D.M.Y_h.m.s');

// current working directory
global.working_dir = process.cwd() + '/';

// loading all library files except for ones in support
global.lib = require(`${working_dir}library/support/loaders/require_lib`)({}, working_dir + 'library');

// custom logger
global.log = lib['logger']
global.feature_type = null

// loading all page_objects
global.page_object = require(`${working_dir}library/support/loaders/load_page_objects`)({}, working_dir + 'page_objects')

// initialise other global vars
global.vars = {}
global.get_glob = lib['param_helpers'].get_global_value
vars['auth_tokens'] = {}

A question might pop into your mind, why am I initialising common libraries like assert, chai and moment as global variables? The reason is that whenever I need to use those libraries, I can just use the global variable instead of declaring it again and again in all files. This is a repeated action and I reduced it by using global variables. Generally, you can declare any variable that might be used across several files as a global variable.

In an application I worked for every API we have to use login tokens that are generated once when the user logs in. We cannot log in for every single test case, so we maintain the same login credentials for the entire set of test cases. For this, I use global variables as they can be shared among different step defs. That’s where I use the variable vars and get_glob . Instead of having too many global variables, I have one array variable and I keep appending it to the same array. You might be wondering that I’m I use a method get_global_variable to access the global variable from the vars array. Here is the method:-

function get_global_value(global_var){
    if (vars[global_var] != undefined){
        return vars[global_var]
    }
    else throw new Error(global_var + ' not found!')
}

You might wonder why we need a function for this. We could have directly accessed like vars[global_var] . But if the variable doesn’t have a value or is not defined, we might face an issue and that’s why we need to throw an error to identify the issue easily.

There is a little bit of memory and time wastage in using arrays and methods for using the global variables. But it is worth it when lots of people work on the project because if someone wants to use the same global variable, they could identify them by just reading the array without having to look for all the files.

How I used global vars and env vars in my test framework? was originally published in Testing diaries on Medium, where people are continuing the conversation by highlighting and responding to this story.

Before I begin with how I organise it, let me brief a bit on my framework. I have worked on a few frameworks and this is the one that I have loved to work on and it cumulates all that I have learnt so far. It is written in javascript and uses cucumber and selenium webdriver. Come on, let’s check the basic folder structure.

The Basic folder structure

> External Scripts
> Features
> Library
> Outputs
> Page Objects
> Step Definitions
> Test data

Other than these, package.json, package-lock.json, cucumber.js, README.md and other git-related files are located in the root folder without any folder structure because they need to be in the root folder for access.

Let me brief you on what I include in each folder.

External Scripts

In this folder, I create all subfolders that run outside my tests. For example, as soon as my tests have been completed, I generate a set of reports in json formats which in future I plan to convert into an HTML page. So the files that generate these reports will be inside reporting subfolder inside the external scripts folder. Then I plan to put all the code required for Jenkins job configurations and Docker containerisation in separate folders inside External Scripts.

Features and Step Definitions

In cucumber, all tests are separated into Features and Step definitions. Features are English text that is literally instructions as to how to test the feature without any code intervention. They are basically test cases. The code that performs the actions for these test cases is contained in Step Definitions. For each and every Feature file, there should be a corresponding step def file with the same order of test cases. But at times we have to deviate from this rule when we need steps that are common and can be used across several features or test cases. Basically, for features, I form a subfolder structure where I separate the tests into UI, API, FTP and DB. Within these, I create sub-folders for each module and then within them, I create separate feature files. If the test cases are too many, it is better to segregate them and put them in separate feature files with numbering or some other identification. And when it comes to step definitions, instead of following the same pattern, I create files directly within them because I try to generalise all steps as much as I can so that they are reusable across features.

Library

The library contains all logic. In step definitions, I call all functions that I have written in Library. Basically, I modularise wherever possible and I do not write any logic inside step defs. Within Library, I have another detailed folder structure that is as follows:-
> Application Helpers
> Builders
> Generic Helpers
> Infra
> Services
> Support
> Utils
> Validators

The application helpers folder contains all files that have functions that are written uniquely for the Company application and cannot be used generally for any other application.

The builders folder contains files that build something like a json or create objects. I create a temp data file that is generated for every test that is local only to the test, for example, run-time created users or other similar data. Files creating such data are put in this folder.

Generic Helpers includes all files that have functions that can be utilised for any application. For example, I include array helpers (that have functions like slicing strings, etc), file helpers (that have functions like creating directories if not present, etc) and param helpers (that have functions that evaluate parameters, etc).

The Infra folder contains files that do cleanup, generate logs, sets the environment, that does webdriver setup, etc.

The services folder contains files that act as a service for connecting with DBs or Apis or FTP servers.

The support folder has a subfolder named loaders. There are two files in this subfolder that loads page objects and all library files. Basically, I create two global variables lib and page_object which are arrays that have all functions in the library and page objects. So it would be easier to call the function like this:-

lib['array_helpers'].slice_string_after_substring(response['redirectUrl'], 'token=')

These global variables and a few other such global variables are initialised in the file name globals.js inside the support folder. There are hooks.js and init.js files too in the support folder. The hooks file basically contains the before and after methods where I log error messages, take screenshots, compute time taken, etc. In the init file, I initialise whatever is required as a basic setup for the test suite to run. For example, creating an outputs folder, connecting databases, etc.

Under the Utils folder, I have two files, poller and random. I could have included these two in generic helpers or put those files in generic helpers in the Utils folder. But the difference between the two is that the functions in generic helpers are functions that are written when in need and not pre-written. For example, I have a function get_last_value() in the array_helpers file. This was written because every time I want to get the last value, I can’t write a piece of code every time.

The last folder in the library is the Validators. In this folder, I have two files, api_validation and validation_map. The functions in API validation file compare the given inputs and validate the same. I have something called validation maps under the test data folder. These contain the mappings between the API json terms (eg app_super_admin) and the UI terms (Super Admin). So the validation_map file in validators has functions to validate them.

Outputs

This folder is auto-generated when I run the test suite. The first thing that gets generated is the temp test data folder. It contains all temporary test data that gets generated on runtime. The next folder is created with the name containing the date and time so that it is unique for each test suite. Inside them, I have 3 folders: failure screenshots, logs and reports. The logs get generated separately for setup and separately for each feature file with the same folder organisation.

Page Objects

These contain page object classes. These page objects are unique for each page. I liked the idea of page objects, so I included them in my framework. This makes automating UI much easier.

Test Data

All the test data is contained inside this folder. I have two subfolders, sample payload structures and api validation maps. And then I have four JSON files, api endpoints, db credentials, default temp data and env. The default temp data file contains all the temporary data that will be used every time the test suite runs. Generally, this data is included within the test cases, but as I said, I separate test data from the test case code so that if we have to edit the test data (for example, if the user is deleted), it would be easier. The env.json contains data generic to each environment (staging, prod, dev, etc).

Read my other article to get a grasp on what makes a good test framework. And be aware that it is only my point of view and not a general idea.

What is a test framework? How it cannot be compared to regular frameworks like Angular or Rails?

How I organised the tests in my test framework? was originally published in Testing diaries on Medium, where people are continuing the conversation by highlighting and responding to this story.

What is Git and why do we need it?

Git is a distributed version control system. If you don’t know what a version control system is, let me explain with a simple example.

Suppose there are 3 people working on the same application. A repository is a codebase or the collection of files (directory) that forms the application. Say it is in a cloud (we call the repo ‘remote’), and all 3 have a downloaded copy of the repository in their systems (we call it ‘local’ because it is only visible to them). They all make changes in the files, some are on the same files while some are on different files. Now they all need to upload the repository to the original location. These are 3 different versions of the same project.

So this is where a version control system (VCS) comes into play. The VCS maintains different versions of the repository. The first main version is the one that was already on the cloud. Let's call it origin and say it has a main branch named master which is the most updated and the one that is used in the application. Branches are different versions of the repository. We can have many branches or just one branch. But, it’s not advisable to have one branch, if there is more than one contributor. Now each of the contributors creates a unique branch from the master branch and makes their changes to them. Once they are done, they push their changes to their respective branches and raise a pull request to get these branches merged into the master branch. When a pull request is raised, the VCS compares the changes and gives a green signal to combine if there are no conflicts, else the conflicting areas are shown where the contributor makes changes accordingly. One more benefit of VCS is that you can track what changes you have made and make sure no dumb changes are pushed to the main branch. Even in case the dumb changes are pushed, a VCS helps you to recover old files thus keeping your repository safe.

Setting up

To start with git, you need to install git in your system. Most of the OS nowadays have git pre-installed. If not, check out https://git-scm.com/downloads.

To pull a project from Github, you can copy the HTTPS link and in your terminal, navigate to the root folder where you want the repository to be and enter git clone and the copied link.

If you want to start a project from scratch, in your terminal, navigate to the root folder where you want the repository to be and then create a folder with the name of the repository and navigate to the same. Then enter git init

Committing and Pushing to GitHub

The proper way of coding when using git is by creating a separate branch from the master branch and working on top of it.

To create a new branch, enter git branch the name of the new branch. You can check what branches are available in your system with the command, git branch . Now, you have to work on the new branch, so you enter git checkout the name of the new branch. Now you are in the new branch. Any change you make and push now will only affect your branch and not the master or whichever branch from which you created a new branch. You check what branch you are in, by entering git branch and the branch where you see * is the branch you are in.

Once you have a branch, you can start coding. Once coding is done, commit your changes. It makes sure that your files are not lost. Enter git status to check what files you have made changes in. The terminal itself would prompt you to add the files with the command git add and file name. Instead of adding each and every file separately, you can enter git add . Check git status and see what files you have added. In case you don’t want a particular file, you can enter git reset and filename. If you want to check what changes you made, you can enter git diff . If you don’t want the changes you made and want to erase them, you can do it easily with the command git checkout -- filename.

Once you are ready with what you need to update, we need to commit the changes. Before that, we need to set our user details. Every commit has an author and every author has an account in GitHub or any other VCS. So to enter your details, type git config --global user.name “your user name in GitHub " and then git config --global user.email " your email ID used in GitHub " and then git config --global user.password " your password for GitHub " . Now whenever you make a commit, the author will be you. If you want to change this, you can change it using commands. To check the details, use git config -l

Before committing, check git status once more and commit the changes with the command git commit -m " message with a one-liner on the changes made " . If you don’t like to add each file one by one you can skip adding files and commit directly using the command git commit -a .

You can check your commit logs with the command git log . And if you want to make changes in the commit, you can use the command git commit --amend . If you want to reset the entire commit, use the command git reset HEAD~ . Now if your commit is ready to be pushed to the remote branch, i.e. the copy of your branch in remote. If the branch is not present in the remote, this command will create the branch in the remote with the newly committed changes. Enter git push origin and branch name. Yay, now you have learnt the basic usage of git.

Now you can login to Github and raise a pull request (PR). A pull request will check changes in the new branch against the main branch. If there are no conflicts, your PR will be approved and will be merged. If you have lots of commits and want to make them as a single commit, you can squash and merge them. But suppose you have conflicts in your files, you need to manually make changes and commit and push again and then raise PR again. This ensures that the master branch is safe. Suppose you didn’t take a separate branch from master and worked directly on top of master, it would have been difficult to track these conflicts and the entire repo will be a mess.

There are advanced concepts in git such as rebasing, stashing, blaming and many more that I haven’t covered in this article. It is in your hands to explore and find out about them. I hope this article helped you out with your first-ever experience with Git and GitHub. And by the way, like GitHub, there are lots of other software that utilise Git for versioning.

The very basic git and GitHub knowledge that you need and must require was originally published in Testing diaries on Medium, where people are continuing the conversation by highlighting and responding to this story.

In an interview I attended once, an Engineering Manager mockingly questioned me “You built a framework?” after seeing the lines on my resume, ‘Built a test framework from scratch’. At that time, I was super nervous and thought maybe my perception of a framework was wrong and what I did was not in fact a framework at all. But then when I explored more about it, I realised that a test framework cannot be compared to frameworks like Angular or Rails. If only I had that knowledge beforehand, I could have confidently retorted to that comment.

So what really is a Test Framework?

In the testing world, frameworks like Rails or Angular are called testing tools, for example, Cucumber, Selenium, Capybara, etc are all tools and not frameworks. They are used to build what we call a test framework. A test framework is actually the set of code files(a library) through which manual testing effort is automated. It contains files that contain test cases and the code required to execute the test cases without manual intervention. It is structured in such a way that tests are separated from common utility methods. It uses and combines one or more test automation tools.

From a developer's point of view, frameworks like Cypress, Playwright, etc are test frameworks. But as I said, in the testing world, it differs. We testers write code for automation and we call it framework because it acts as a template for further automation. Most experienced people are aware of it and most of them are not. So, it’s important to educate everyone on the difference.

A basic and simple test framework has separate codes for each and every test case. It collects only test data from users and prints test results when executed. A proper or complicated test framework does more than that.

Let’s look at what makes a good test framework

• It should have a good file structure with separate folders for
  -> test data
  -> test cases
  -> general utilities
• There are several types of testing on different layers of software. The same can be applied to automation as well. A good test framework combines all of them

• It should have proper setup and cleanup scripts that prepares the environment for testing with proper pre-requisite data in place and deletes them once the test is completed
• It should be able to test in different environments without much effort
• It should be able to run in different browsers and different versions of browsers as needed. For that, we have to choose the right tools
• It should have minimal setup steps or should be just downloaded and run with the proper reference manual in place
• The codebase should follow standards of coding including modularity, lesser loc, readability (easily understandable), etc. No lines of code should be repeated in any place throughout the framework even though they are for different purposes
• It should be able to run with any specification — just one test case or clubbed number of test cases or segregated into modules or run entirely
• It should be able to execute quickly. The easiest way is to run independent cases in parallel
• It should print and record the results in some file or cloud storage properly for future reference
• It should generate good logs with screenshots of the failures for easy backtracking
• It should never depend on any manual intervention other than what to test
• All test-related files should be organised and nested within a single file structure (the test framework) including test reporting and should not involve checking in another file structure. Any different testing tools used must be combined in one place itself

Sorry, I have not worked on mobile, so I cannot tip on the same

I conclude by telling you to be aware that all of my content is only from my point of view and not a general idea.

What is a test framework? How it cannot be compared to regular frameworks like Angular or Rails? was originally published in Testing diaries on Medium, where people are continuing the conversation by highlighting and responding to this story.

For all those who think manual testing and automation testing are totally different from one another, this piece of content is for you because you are totally wrong, they both go hand in hand. What I mean is that if you need to succeed in testing, you ought to know both manual and automated testing. If you are one of those guys who think, “Yeah, I know how to automate tests with code and I don’t have to test anything manually at all” or one of those who think, “I don’t need to write code to test anything at all”. In a company, there may be separate testers for automation and separate manual testers, but each has to step down or step up to take the other’s role once in a while to succeed in their career of testing.

What I'm trying to say is that even if you do only manual, at some point you will be forced to automate some tasks that are often repetitive and used regularly. This doesn’t mean you need to be an expert in automation, you just need to know what’s enough to automate them. For example, if you are using Postman for testing APIs, you can write basic scripts to validate large json responses instead of scrutinizing each manually. Eventually, you can learn to use postman collection runner too and voila, you have set foot into automation.

Similarly, if you are an automation tester with no prior manual testing experience, I’m sure you will find it very difficult to write tests that cover every scenario. A good test is one which can even validate edge cases, and with no manual experience, there is a 0% chance that you can achieve that. If you are given a test case to automate, first test it manually with all possible scenarios, then write the same in code, that’s how automation works to the fullest, or else there is a possibility that your code fails at some point and you would have no idea how. For example, you might have forgotten to think of a particular edge scenario while writing the test, which causes a failure scenario to pass. If only you had checked it manually first, you would have realised that mistake.

Testing is not as easy as many may think. Even developers have to test, but they will only think from their perspective, even the wrong becomes the right for them. That’s where a tester comes to the rescue, he/she has no idea of the code written in the background, so he/she will only check if it works according to the rule just like a layman. For example, a developer might have written ‘sing up’ instead of ‘sign up’. This mistake would definitely not be visible to the developer as he/she would read it correctly even if it's wrong, because that’s how our mind works. A tester would rightly identify this because a tester’s eyes are always sharp.

If one has to achieve great heights in the field of testing, one has to respect and work on both manual and automation testing.

Automated Testing and Manual Testing go hand in hand was originally published in Testing diaries on Medium, where people are continuing the conversation by highlighting and responding to this story.

When I attended my life’s second interview, I realised that the way QA worked in other companies was way different from how we worked. Our project was a web application but with more focus on the backend and logic. I hadn’t written many test cases for the frontend, nor for mobile. So my one-year experience was equivalent to zero. The first round was a few debugging and programming questions. I answered a few in ruby as I was a bit proficient in it at that time and struggled with a few questions. There were almost 100 people and 25 passed through. Luckily, I was one among them. It boosted my confidence.

In the f2f, the interviewer asked me to tell what and all I would test in a search bar in a mobile application. I told her whatever I knew I would test. But she was highly disappointed with my answer. Then she taught me that there are things like battery consumption, notification bar, etc when it comes to mobile testing and boom, I was rejected.

Then I attended a few more interviews with a few more companies and I was rejected back to back. The reasons were the same as above including lack of experience, not working on a customer-facing product, no experience in java, no proficiency in DSA, not working on Selenium, etc. I started getting depressed. I was so afraid of rejection that I stopped attending more interviews even though I got a few opportunities. I wasn’t eligible to apply for most SDET roles as they required experience and I was just a year old in the industry. So I decided to wait and leave the fate to the gods. And guess what, god really hears our prayers.

How I got into Automation

While I was still working on my Cucumber ruby test framework, our company recruited a new Test Automation Manager. He was supposed to set up a team and start automating all manual tasks. As I was the only one doing API automation in the company, he sought me and I explained to him my work. He was super impressed and urged me to join his team. I learned a lot from him. I would spend an hour or two regularly with him while spending the rest of the time on my manual QA tasks. His framework was based on Cucumber and protractor. So I was moved to code from ruby to Nodejs. I was in charge of rewriting my test cases into the new framework.

To incorporate my test cases into the framework, I had to make a few structural changes. Then when I saw that there were almost 1000 lines in a function that could be easily written in 100–200 lines, I set out to modify them. Then I realised I made more contributions to the framework than those who were working only on it. Everyone in my team knew I liked working on automation more than QA including my manager. So when our product didn’t work out and when our team was split and put into different teams, I was put on the automation team. And I officially became an Automation Engineer.

The rest of the story

I worked on the automation team for about five-six months. After which I got married and got pregnant. I worked till the last month of the gestation. In the entire year I worked, I contributed to stabilising the daily regressions, wrote many test functions that could be reused with zero coding effort and automated almost 500 test cases. In between, we were asked to shift to python as developers couldn’t understand the plain English concept of cucumber, which I felt was too much ado. As we were not in a position to fight back, we had to accept and start afresh with a new framework. My entire hard work was put to vain. And this all happened when I was on my marriage leave. I was very much agitated, but there was nothing I could do about it. And I worked with the same interest in the new framework. As I’m a person who doesn’t like complex functions for things that could be done easily with simpler functions, I improvised in the new framework as well.

During the last period of my work, my colleague and I were put into a team to manage QA, both manual and automation, as there was a lack of QA engineers in the company. I was in charge because I had previous experience and my colleague was quite new to manual testing. I taught her to write manual test cases. As the project was still under development, we wrote test cases and automated them simultaneously with development. We lagged a little, yet we completed it on time. And I was so proud that we automated the project entirely. But before we could add in language testing and some other stuff, we were asked to move out of the team as another old employee had joined back after her maternity leave. And voila, again my beautiful experience was smashed. And I got back to the same old routine. I took my maternity leave one month in advance and then I did not touch my laptop for the next six months!

Once my maternity leave was over, I tried to work, but as many know it’s not possible for a mother with no one else at home to take care of the child to continue her profession. We kept a maid, yet it didn’t work out as our boy was hyperactive and needed attention 24/7. And that’s the end of the journey from manual to automation and to duh, nothing!

The Journey from Manual to Automation — Part Two was originally published in Testing diaries on Medium, where people are continuing the conversation by highlighting and responding to this story.

Some Background

When I was in my final year of college, our Placement Officer called a few students including me for an interview the next day after the college symposium. Everyone else was enjoying their day off while we were supposed to attend an interview for the post of QA Intern. Believe me, though we had a subject on Software Testing, I didn’t even know that such a job posting existed. I did a little digging on what the job requirements were. It had some vague concepts which I already knew because of the subject I had. As I was not that great with programming at that point, I was happy that there was no programming stuff at all in the requirements. It was the first real interview of my life. The first round was aptitude and to be frank, I thought that I would fail because I didn’t prepare well and some answers were actually a fluke. But since the company was a supply chain management platform, most of the questions were on distance, speed and time, which were quite easy for me to crack.

When we were waiting for the results, some of the other candidates were revising large books of content on testing. I was scared as hell looking at them. But somehow, I cleared the first round and faced a few rounds of face-to-face in which to my relief they mostly asked only reasoning, a few simple programs, a few basic testing concepts and questions like how to test this and that. Two to three days later, my PO came to our class and told me that I failed the interview. I wasn’t disappointed at all as it was a good learning and there was a lot more to go. But it turned out that he had actually tried to fool me. I got the offer. Without any second thought, I agreed to join.

The Intern Period

I had no industry knowledge. It was a small startup with lesser than 30 people sitting inside the small office room with large spacey cabins for each. I was a noisy kid all through school and college. So when I entered the room which was very very quiet, I terribly feared that I won’t last long. All of the people were very much elder to me. They might have been in their early 30s or late 20s and I was merely 20. But I was good at talking. I believe that it was that which landed me the job in the first place.

I was given a spacey cabin near the door and a MacBook worth 1.5 lakh. ‘My God, how can you trust me with such costly stuff’, I thought to myself. Actually, I was and I’m a butterfingers.

The first day was all introduction and setting up. For the next few days, I literally had to bug my manager to give me a task because I didn’t like sitting idle and not knowing what to do. Then I was directly asked to test a new product. That team didn’t have another QA who could train me or who I could reach out to in case of doubts. My first task was to write test cases. They didn’t provide me with a sample at which I could have a look. So my test cases looked like how it was portrayed on the internet. As I loved formatting and had to place my words perfectly, I took a lot more time to write simple test cases. Then the CTO who was very close with everyone working in the tiny office introduced me to my mentor. She was my lifesaver, but I felt stupid in front of her every time when I made embarrassing mistakes.

Somehow I blended well and got to work. Actually, some tasks were really fun to do. Give input creatively and check the corresponding output. I got to work with databases and APIs, which I didn’t know back then. I realised that no matter how good we are at learning concepts at school or college, practical knowledge is only what helps us understand the concepts. The theory gets easier when you get hands-on.

Back in college, I felt like a star. I was the first to get placed in my batch. I got good honours and of course, attracted a lot of jealousy. It was only I who knew what hardship I went through during my intern period. To others, I had a job and my life was settled. But I was lagging very much behind the people in my office. I just didn’t have the pace. I had to work extra hours to manage the work. Meanwhile, I also had to complete my college assignments and submit them on time. And on top of all these, I had to work late nights on my final project. Thanks to one of my office buddy, who was another intern who joined with me, he helped me tonnes with the project.

Though I feared getting kicked out, somehow I completed my internship successfully passing two checkpoints each trimester and joined the company as a QA Engineer. I was doing nothing new after being employed, just that my salary increased and I got some perks. But as time passed on, I was frustrated with doing just QA and no coding. The thing is I got very much interested in coding during that period. I had even built a website on my own with animations and hosted them online using Heroku and all that.

Automation Introduced

While I was still interning, I was introduced to Automation using a Java Spring framework with TestNg. In the little extra time that we had while working, I and my lead wrote some methods in the framework. Unfortunately, I didn’t do any research on what it was and didn’t even go through the entire framework. Just did what I was told to do.

Then somehow that framework got forgotten and after about 6–7 months, there was a need to automate our testing process to increase the speed and reliability. Since I was very interested in programming, I was given the chance to begin with API automation. I did a lot of research on the best technologies and how to automate Apis. API automation was similar to front-end development. Instead of manipulating the data and displaying it on the webpage, we just assert it.

Since my manager asked me to go with cucumber and ruby, I learned them and incorporated them into a test framework with feature files and step definitions that had a separate library with helper functions. And yes, I got some help from my developer teammates. They were the most amazing people who taught me everything that I needed to know to kickstart my career in test automation.

I began by automating what I felt was the most hectic manual testing task, data preparation. I automated about 23 test cases in a short span. And they were the most vital ones. But the problem was that I didn’t showcase any of that and I was improving the same thing over and over. Changing the variable names, changing the structure. The problem was that there was no proper guidance other than the sources on the internet. The mistake that I did was that I was focusing more on improving the framework rather than increasing the coverage. I integrated it with Google Sheets for storing the APIs results with their response times and then with TestRails, a tool for test case management and played around with it to create test runs and update the results in it whenever the test suite was executed. I made the environment run as a configurable one and wrote methods to create pre-requisite data so that there is no manual intervention at all. I also wrote scripts for creating bulk demo data. I had also written complex functions to find data from CSV files based on the conditions that are provided in the cucumber steps. I did this much extra work.

So why I said improving the framework rather than increasing the coverage was a mistake was because it looked like I was too slow though I really wasn’t. So the best tip I can give you is that whatever you do, if you are satisfied with it, just go on, and showcase it. And always make it work first and perfect it later.

Trying to move on

So as time passed, I didn’t see any learning curve. I was stuck in the same place where I was. Same routine testing and my code was barely used. However, I exploited them as much as possible for my manual testing. I couldn’t automate much as there wasn’t even enough time for regular testing. Then I got to know that there are roles for only automation and they were called SDETs. I knew that my company had way too many expectations and I wouldn’t be able to fulfil them, so I didn’t request a role change. Instead, I decided to attend interviews with other companies. Since I had not failed my first interview, with that confidence, I attended another interview.

to be continued…

NEXT PART:

The Journey from Manual to Automation — Part Two

The journey from Manual to Automation in Software Testing was originally published in Testing diaries on Medium, where people are continuing the conversation by highlighting and responding to this story.