In previous articles, we discussed “E2E development challenges and overview of the E2E testing frameworks” and “E2E Test Components”. The goal of this article is to simulate what a real user scenario looks like from start to finish and to provide E2E test examples with Cucumber and Nightwatch.

We will show real examples of our backyard project, how to set up the environment, and how to automate some of your tests.

The test includes three parts:

• Feature file, which is a clear description for each step of your test using Gherkin syntax.
• Step file, which is the script for matching the features and the Java code.
• TestRun, which is the configuration setup for running your test.

Some important things need to be taken into consideration when you configure your test-runner.ts. You need to configure it for your needs:

• Add environment option. Tests should be able to be easily rerun in any environment.
• Plan which tests to be run
  • Smoke tests only?
  • Specified tagged test(s)?
  • Specified feature file(s)?
• Plan where tests are to be run
  • Chrome in headless mode
  • Browserstag
  • Saucelabs
• Plan to run tests in parallel (if this is what you need)
• Set seleniumHost and seleniumPort

Writing nightwatch.conf.ts file

Take screenshots for the failed tests. This will help in debugging the failed tests.

Add option for your tests to be run on Saucelabs and Browserstack. This will help in browser compatibility testing.

Package.json

{

“name”: “api-e2e”,

“version”: “1.0.0”,

“scripts”: {

“report”: “node build/create-html-report.js”,

“prebuild”: “npm run clean”,

“build”: “tsc”,

“build:watch”: “npm run build — -w”,

“clean”: “node ./clean-up.js”,

“lint”: “tslint -c tslint.json   ./src/*ts  ./src/**/*ts”,

“debug”: “node –inspect-brk run-tests.js”,

“test:run”: “cucumber-js –require ./src/features/\\*\\*/*ts –require-module ts-node/register –require ./src/hooks/*.ts –format ./node_modules/cucumber-pretty ./src/features/”,

“test”: “./node_modules/.bin/ts-node src/test-runner.ts”,

“selenium:local-standalone”: “ts-node server.ts”,

“selenium:local-docker-hub”: “docker-compose up”,

“generate-report”: “ts-node ./src/create-report.ts”,

“e2e-test”: “npm test”

},

“keywords”: [ ],

“author”: “”,

“license”: “ISC”,

“devDependencies”: {

“@types/cheerio”: “^0.22.7”,

“@types/cucumber”: “^4.0.4”,

“@types/debug”: “^0.0.30″,

“@types/faker”: “^4.1.2″,

“@types/lodash”: “^4.14.115”,

“@types/node”: “^10.3.2”,

“fs-extra”: “^6.0.1”

},

“dependencies”: {

“bluebird”: “^3.5.2”,

“cheerio”: “^1.0.0-rc.2”,

“chromedriver”: “^2.40.0”,

“config”: “^1.30.0”,

“cucumber”: “^5.0.0”,

“cucumber-html-reporter”: “^4.0.1”,

“cucumber-junit”: “^1.7.1”,

“cucumber-pretty”: “^1.4.4”,

“debug”: “^3.1.0”,

“deepmerge”: “^2.1.1”,

“emailjs-imap-client”: “^3.0.7”,

“faker”: “^4.1.0”,

“fecha”: “^2.3.3”,

“geckodriver”: “^1.12.2”,

“jsonschema”: “^1.2.4”,

“lodash”: “^4.17.21”,

“nightwatch”: “^1.0.11”,

“nightwatch-api”: “^0.4.0”,

“npm-run-all”: “^4.1.5”,

“selenium-server”: “^3.12.0”,

“start-server-and-test”: “^1.7.1”,

“ts-node”: “^7.0.1”,

“typescript”: “^2.9.1”,

“wait-on”: “^3.0.1”,

“yargs”: “^11.0.0”

}

}

E2E test examples with Cucumber and Nightwatch

In this article, we are providing examples of how we can automate some testing scenarios.

We are going to show how we implemented the following scenarios:

• User access tests
• Search list item
• Edit Item
• Create item
• Delete item
• Test empty system

The following diagram is describing our application, where we wanted to simulate a complex application structure that depends on different services and components.

https://github.com/IT-Labs/backyard/blob/master/doc/Backyard%20arch.jpg

As we discussed in our previous articles, we are using dockers and volumes to run our test in repetitions. All commands are written in shell scripts for an easy start. For example, starting all applications for testing all scenarios you should only run the restart.sh file and system are ready for use, cleaning all resources you should use clean.sh.

Steps:

• Download code from https://github.com/IT-Labs/backyard
• Build the code with the script build.sh
• Start the environment with a restart.sh ./path to your local back yard folder
• Run tests with a test.sh

More details about the commands and environment you can find in the project readme file https://github.com/IT-Labs/backyard/blob/master/README.md.

Here is one example of how to run multiple tests with the previous steps:

https://raw.githubusercontent.com/IT-Labs/backyard/master/doc/TestRun.gif

User access rights

In this example system, we have two types of users: public and administrator users. For testing both scenarios we have two feature files, https://github.com/IT-Labs/backyard/blob/master/fe/e2e_tests/src/features/home/home.feature  and  https://github.com/IT-Labs/backyard/blob/master/fe/e2e_tests/src/features/home/home-public.feature .

Here is how gherkin is written:

Scenario Outline: Verify menu items from Home page when user is admin

    Then the menu <Link> should be <isVisible>

Examples:

| Link        | isVisible |

| Home        | true      |

| Admin       | true      |

| About       | true      |

| Hi Username | true      |

| Login       | false     |

| Logout      | true      |

Code:

Then(/^the menu (.*) should be (.*)$/, function (link:string,isVisible:boolean) {

return menu.checkLinkVisibility(link, isVisible);

});

Code related to this example  https://github.com/IT-Labs/backyard/blob/master/fe/e2e_tests/src/features/home/home-steps.ts   , https://github.com/IT-Labs/backyard/blob/master/fe/e2e_tests/src/domain/menu/menuPage.ts

Example run: https://github.com/IT-Labs/backyard/blob/master/doc/featureHomeAdminRun.gif

Search list item

For this example, we prepare one scenario, where we are going to validate the search by name. For that purpose, our volume data has already populated data.

Code can be found here: https://github.com/IT-Labs/backyard/blob/master/fe/e2e_tests/src/features/items/items.feature

https://github.com/IT-Labs/backyard/blob/master/fe/e2e_tests/src/domain/items/itemsPage.ts

Scenario: Verify correctness by Search by Name

When I add SearchItem in items search name

Then I should get item with that SearchItem as a result

When I add Search in items search name

Then I should get 1 results that contain Search in the name

Example from the run https://raw.githubusercontent.com/IT-Labs/backyard/master/doc/SearchItem.gif

Delete item

In this example, we are presenting how we can test deletion of one item from out test environment. For that purpose, our volume data has already populated data. We must be aware that for each test run we must restore the volume from initial backup.

Code can be found here: https://github.com/IT-Labs/backyard/blob/master/fe/e2e_tests/src/features/items/delete-items.feature

https://github.com/IT-Labs/backyard/blob/master/fe/e2e_tests/src/domain/items/itemsPage.ts

Scenario: Verify delete item

When I click on Delete icon for item with name DeleteItem

Then I should see delete confirmation modal

When I click on OK on the modal

Then Item with name DeleteItem is not shown on items page

Example from the run: https://github.com/IT-Labs/backyard/blob/master/doc/DeleteItem.gif

Create item

In this example, we are presenting how we can test creating an item. For this test requirements are the item not exist in the system, and for that purpose our database before each run is restored from initial backup.

Scenario: Verify user can create item using all fields in Create item page

When I click on create button

Then I should see create item page

When I add Name SampleName

And I add Description SampleDescription

And I select Status

And I check Is Public checkbox

And click create item

Then Item should be created

And I should be redirected on list items page

Code can be found here:  https://github.com/IT-Labs/backyard/blob/master/fe/e2e_tests/src/features/items/create-items.feature

https://github.com/IT-Labs/backyard/blob/master/fe/e2e_tests/src/domain/items/itemFormPage.ts

Example from the run: https://github.com/IT-Labs/backyard/blob/master/doc/CreateItem.gif

Edit item

In this example, we are presenting how we can test deletion of one item from our test environment. For that purpose, our volume data has already populated data. We must be aware that for each test run, we must restore the volume from initial backup.

Code can be found here: https://github.com/IT-Labs/backyard/blob/master/fe/e2e_tests/src/features/items/edit-items.feature

https://github.com/IT-Labs/backyard/blob/master/fe/e2e_tests/src/domain/items/itemsPage.ts

Scenario: Verify user can edit item changing only mandatory fields

When I click to edit item with name EditItem

Then I should see edit item page

When I change the Name to TestEditedItemName

And click create item

Then I should be redirected on list items page

And  I add TestEditedItemName in items search name

And I should get item with that TestEditedItemName as a result

Example from the run: https://github.com/IT-Labs/backyard/blob/master/doc/EditItem.gif

Test Empty system

This is a scenario where we are verifying how the system will behave when there are no records. For that purpose, we have a separate environment where a database is without any record, and we start all service as separate instances.

Code can be found here: https://github.com/IT-Labs/backyard/blob/master/fe/e2e_tests/src/features/home/home-public.feature

https://github.com/IT-Labs/backyard/blob/master/fe/e2e_tests/src/features/home/home-steps.ts

Scenario: Verify Home page main page when there are no public published items

Then I should see message in the middle of the screen: There are no items yet!

Example from the run: https://github.com/IT-Labs/backyard/blob/master/doc/emptySystem.gif

Summary

It is so important to test your software from top to bottom. E2E testing is a great way to do it — you just need to follow some rules that will implement the process properly.

When you write the tests, add a descriptive test step. A descriptive test step is helpful when a test fails, it gives them a clean and readable description of test steps (for example why this test, how it is done, etc.). Also, descriptive tests simplify the process of automation test maintenance  in large projects. What’s more, having reports that will visualize and tell you which test failed and which test passed is will also help.

Since our approach implements feature files, you need to keep into consideration that the feature files can easily become very large and messy files. And running the tests — especially if they are part of some CI/CD process — can take considerable time, especially when you want to run your test in different browsers and you have large coverage.

On the other hand, large coverage is always good to have no matter the duration of the tests, because it creates greater confidence in your code.

Software bugs beware!

The software testing team at IT Labs has brought home the gold — as in, Gold Partner status awarded by the International Software Testing Qualifications Board, or ISTQB.

This ISTQB partnership is an indicator of the high-level skills and competencies of the 200-member team at IT Labs, which has a longstanding commitment to the continual growth and development of its team members.

“What this recognition means in real terms is a powerful combination of defect prevention, pre-test defect removal, and better testing that avoids costly and embarrassing bugs in software,” says Ilija Mishov, founding partner of IT Labs. “That saves time and improves quality.”

Testing certification brings software quality awareness, best practices, and context for developers, testers and business analysts as they work together in the Agile environment.

“It makes a huge difference to have objective metrics to guide and control a project and accurately report the status, as well as having defined entry and exit criteria,” Mishov adds. “Also, this level of certification means a testing team is able to meet and overcome some of the obstacles to high quality – incoming quality, time, manpower, and so on – because they’re now equipped with tools and techniques to address those issues. This arsenal of testing techniques has a direct and positive impact on the bottom line.”

The ISTQB Partner Program comprises four levels of partnerships (Silver, Gold, Platinum and Global), and the partnership level of an organization is determined through the number of certification points it has accumulated.

For more information, visit http://www.istqb.org/partner/.

As software architecture evolves, the front end should follow that evolution as well, as shown in Figure 2. If we look back, the applications were built as large monoliths. This slowly progressed to microservices, but the UI got stuck as one large monolithic codebase, structured around the solution as a whole and not around a certain domain. This way, even the smallest of changes that needed to be deployed would’ve meant redeploying and running the pipelines for the whole front end again.

The proposed approach of micro-frontends came about naturally by following the microservices pattern,

Figure 2. Software Architecture from Monolith to Microservices

where it would be dividing the teams as independent owners of the whole feature end-to-end.

Each team would be responsible for the creation of the UI portion of the application, styling, code, layout, architecture, backend, devops, and connection to the database.  It has its own build and test pipelines and CI/CD procedures. This enables the following:

• Better scaling capabilities of the frontend application
• Fewer communication issues between the multiple teams for one feature change
• Reduced code and testing complexity
• Aids with the application being more resilient to non-working or broken portions
• Helps to overcome the law of diminishing returns

Figure 3. End to end teams with micro frontends

Several companies and projects are running into the issue of having old, large codebases demanding full rewrites. These were probably the side effect of pressure to get faster to production and market, instead of evolving the product for maintainability. This is creating a situation that can be seen as a time-consuming rabbit hole where developers get weighed down by old tech stacks or the large monolith’s sheer complexity and subsequently unable to deliver new features to customers without being held back.

And usually this is where incremental updates start with having one team getting the first feature as a micro frontend delivered to production and the rest of teams will follow. The end-game is that we are free to make case-by-case decisions on individual parts of the product and be able to make the incremental upgrade to the existing architecture. Each micro frontend can be upgraded when needed or makes the most sense and be redeployed as a separate portion, rather than having to upgrade and migrate everything at once. If we want to experiment or do the new feature in the latest technology that is still in the experimental version, we can do that in a more isolated fashion than we could before.

The source code being delivered for each micro frontend is much smaller than the source code for the whole monolith which is also a plus because you can implement lazy loading and improve the performance of each service separately and thus on overall on the application and the user experience. The code is isolated and may be placed even in different repositories. There is a clear line around the bounded context and what should the application contain according to that context. Micro frontends architecture forces your decisions to be explicit and deliberate about data and events flow between portions of the application.

Independent deploy ability of micro frontends is key to success! This reduces the scope of any given deployment and all the risks that comes with it. Autonomous teams have full ownership of everything and they deliver the value to users which enables them to move quickly and effectively and as described in Figure 3. Teams need to be formed vertically for each functionality on the contrary to technical capabilities.

Monoliths are not bad but at times they are hard to manage. In a large monolith with pieces tightly coupled and interdependent, whatever change, upgrade, update, fix, no matter how small it is it demands the whole monolith to undertake the change and be released, and in cases if there is sub-dependents on the monolith they will also be affected.

In order to be successful with micro frontends there a number of cases that need to be discussed and decided. From an implementation point of view, there are certain principles that need to be followed

• Define – Each micro frontend needs to be defined around a business domain or a feature. Model around the business domain
• Compose – How each micro frontend is going to be composed
• Route – How is it going to be called or routed to
• Communicate – How is it going to communicate with the rest of the application
• Decentralization – Separate each micro frontend in its own repository , create independent pipeline as you are working in a single independent application
• Orchestration – bringing all the micro parts to work together
• Independent deployment – The team owning a micro frontend should be able to independently work, update, deploy, redeploy the application without touching on any of the other micro frontends.
• Isolation of failure – When one micro frontend is not working properly or down that should not affect the other existing applications.

Before starting developing and architecting a solution we should also have in mind that the solution that we are going to build should be technology agnostic.

• All of the code that is going to be written should be isolated and independent per micro frontend
• Each team should posses its own prefixes and they should not come into conflicts with other teams
• Stick to the native browser features and do not go and invent your own
• The application that is going to be built should be as resilient as possible (Universal Rendering and Progressive Enhancement to improve perceived performance).

There are implementations ways of achieving micro frontends and we will be discussing some of them next.

Figure 4 Micro Frontend Techniques

There are two approaches to micro frontends based on the type of runtime they have and both with its sub-approaches. As the name suggests, these are being divided based on the environment the micro frontend has and if its being shared between multiple micro frontends a.k.a shared runtime or does it has its own separate runtime.  This two further branch out as it is being displayed in Figure 4.

In this approach the runtime of the application is being shared between the micro frontends. Thus we might conclude that if there are two or more micro frontends in the same page and one of them is doing some heavy computation or requires the main thread more, this might cause blockage for the other micro frontends that are on the same page.

Pros of this approach are :

• Web components are more or less encapsulated depending on if Shadow DOM is used or not.
• Leverage common assets and consistent look and feel.
• Easy to consume shared code and reduced overall amount of code that needs to be shipped (also prevents code duplication).
• SEO and A11y are being treated as any other HTML code.
• Fully framework agnostic and can be used as both web app or mobile hybrid application.

Cons to this approach are:

• Bad support of older browsers (using pollyfills).
• Initializing and bootstrapping multiple components in a page can cause performance impact.
• If the application is bundle as a whole, any small change can trigger the whole build/deploy cycle for the whole application.

These are usual framework build controls and can be built with any of the existing or the framework to come. The challenges that need to be overcome in order for this approach to work are the vendor lock-in, they are difficult to migrate and it is extremely difficult to combine with multiple frameworks. They are not tech agnostic and they are hard to be build as autonomous features.

This includes applications that are being rendered at the server side using various techniques to do server side rendering and the combination of various applications in order to be delivered as a single page. The benefits of this approach are simplified client side processing and user experience, but the cons to this approach is that there is no native way of doing it and that it slows the overall page.

In this approach each micro frontend has its own runtime and it is fully independent of the other micro frontends. All of the micro frontends should be able to run in parallel without any taking the main thread and blocking the others.

When using the microapps approach tend to build features horizontally by vertically dividing teams, so in terms of meaning when you start developing the micro frontend respect the tradional development with embracing the javascript ecosystem and dynamic rendering, whilst investing up front in setting up teams structure and overcoming testing and scalability challenges and also dependency management.

With micro apps the user experience is slightly off because each application is isolated and has its own styles, framework, team and code logic, so there might be places where UX might be off. Other then that micro apps reap all the benefits from this approach meaning they are autonomous, tech agnostic, value and microservice driven, and they are being owned by a team. The combination of the application can be done on both the frontend side and on the server side and this will change complexity of the application transfering the complexity to the side that is going to be doing the combination. If done on the client side browser would include the content using AJAX and this reduces the backend complexity but it will introduce huge front end complexity and performance problems.

This approach is also not tech agnostic and tends to deliver bad user experience:

• Pros of this approach are:
  • That the team developing the application can be fully independent also in terms of choosing their own technologies and cycles

  The application is fully encapsulated in the iframe, so it does not affect The Host javascript or css.

  Cons to this approach are:

  • A lot of duplicated code if more then one micro app is initialized in a single page and this is mostly because assets, fonts, styles cannot be shared between host and app
  • Routing can become very complex
  • Difficult internationalization, preservation of unified styles
  • Additional code to handle iframe resize and problems that come with iframes
  • Not so much SEO and A11y friendly

  No matter what of the upper approach you would be taking, Orchestration for bringing everything together is needed in order to combine all the micro-parts to be functioning and working together. This can be assured with having a dedicated team to do just that and that team is called ‘The Host’. This team is in charge and responsible for orchestration and composition and is responsible for

  • Configuration for initialization
  • Routing
  • Communication between components
  • State Management
  • Providing commons/shared code
  • User triggered event-based API’s

  In order to dive deeper into micro frontends there are a number of useful API’s that can excel the composition of micro frontends.

  • Intersection Observer
  • Mutation Observer
  • Channel Messaging
  • Push API
  • Service workers and WebSockets
  • Client side storage and cache

Some micro frontend implementations can lead to duplication of dependencies, increasing the overall size bundle of the application and the bytes the user must download. As a caution that you should be also aware is because of the team autonomy each team can work in a separate fashion and that can cause team fragmentation.

As number of micro frontends grows so does proportionally the number of repositories, tools, build/deploy pipelines, servers , domains etc. So, before continuing further, code quality and consistency should be agreed upon, the governance of the teams should be assigned, automation for all the processes should be provisioned, and the processes set should be able to scale.

When you choose micro frontends, by definition you are opting to create many small things rather than one large thing. You should consider whether you have the technical and organizational maturity required to adopt such an approach without creating chaos.

It is best to have a separate page for each micro frontend and not to mix them too much on a single page. So the recommended way of handling the routing is to give the control to “The Host” micro front end and he is responsible for doing the navigation and loading of the bundles.

https://host.com/Team-A

https://host.com/Team-B

https://host.com/Team-C

Testing each micro frontend should be easy and simple as testing a monolith with the exception that not a lot of external dependencies and connections are required.

The framework that we used in our example — as of this writing, one of the best out there —  was Single Spa (Micro frontends approach that is composing multiple SPA’s together built by Canopy) with the support of System.js where you can define a single root micro frontend that is going to provide the previously talked “The Host” capabilities to all the rest of the applications. Some of the rest are :

• Bit – which is component-based approach. Different teams can build, publish and expose their components independently, while you can also integrate and compose independent components together.
• FrintJs – It lets you load apps coming in from separate bundlers, gives your applications a structure, and handles routing, dependencies and more. (mostly for react)
• Mosaic – Mosaic is a set of services, libraries together with a specification that defines how its components interact with each other, to support a micro-service style architecture for large scale websites.
• Podium – server side composition of micro frontends
• Polymer – Web components approach. This is a Google-owned project.
• OpenComponents – is an open-source, “batteries included” micro frontends framework.

We will be using the Single Spa approach to building a demo micro frontends application.

The application that we are going to build is displayed on the following image:

Figure 5: Micro frontend demo application

There are two types of highlights in the figure above and the red highlight is for the Navigation bar application which will be active all the time together with the root application – “The Host” and the rest of the applications are highlighted in green and they are as the name suggests Account Settings micro application built with Angular v10, Admin micro application also built with Angular v10 and Users micro application build with React v16.

Here you can have at least two more micro applications based on the architectural decisions that you need to make and which approach should you choose. You can have application with shared libraries and resources and also a micro app that will import the general styles for all the micro frontends. In our approach we choose not to use any shared styles, libraries or modules in order to not have any coupling between the micro applications.

In order to start with developing the micro frontends applications you need to have single spa installed globally (or locally on your machine). In order to install it, type the following command in your command prompt:

npm install —global create-single-spa

Assuming that you are already in the folder that you want to start working with micro frontends you can go ahead and type in:

// Creating the single-spa app       
npx create-single-spa

if not, you can use the following commands to create a directory and navigate to it from the command prompt:

// Creating the folder for all projects
mkdir microfrontends
cd microfrontends

// Creating the root app folder
mkdir root-config
cd root-config

and then type the command for creating the single spa root application:

// Creating the single-spa app       
npx create-single-spa

So, after running this command you will be prompted to fill out a number of additional inputs via the command line and you should select this according to your need (you can see on the Figure 6 bellow for information on how the prompt looks like).

For Directory you can type free text to create a directory for where you want the cli to generate the new application,  for new project you can select one out of three options that are there

1. single-spa root-config (you can have only one of this kind)
2. single-spa application / parcel
3. in – browser utility module( styleguide , api ,cache , etc) as shown in the figure below:

Figure 6: single-spa app configuration

Some of the other questions that you are asked are which package manager you would like to use and you can choose npm or yarn, will this project use typescript and you can choose Y/N, if you would maybe like to use the Single-spa layout engine which is very useful it asks for an organization name and a project name and you are done.

Figure 7: single-spa app additional configuration

The important one is the second one which asks you to Select type to generate? and for that you should enter single-spa root config in order to generate the root micro application.

After generation of the root config, go ahead and for each application create a new folder to put the micro application in and repeat the step of:

npx create-single-spa

you should now select:

single-spa application/parcel

and for framework you can choose which one you wish to use.

Repeat this step for all the applications that you need (Account Settings, Admin, users)

When you finish with the installation of each application in the console logs you see the following output:

Figure 8: single-spa creation output

You can choose to start it locally or follow the steps 2, 3 and 4 in order to test it in the browser in the single spa playground.

We used System.js to create import maps for all the micro frontend applications that we needed and imported them into the root config. For production and for development use these can be set to be loaded dynamically.

System.js allows us to import a module over the network and map it to a variable name.

Figure 9: System.js configuration

Each micro frontend application should have different ports.

In order to register the application you need to define it in the root-config.js .

Figure 10: App configuration – root-config.js

All of your micro frontend’s applications must be registered in this file so for each application we would have a similar registerApplication function call like the one shown below. The name usually follows the pattern of “@organization/appName”.

We used eev for communication between the micro frontend applications and you can add a number of custom properties based on the needs of the organization.

To define cases where you want them to be valid only for certain environment you can wrap them in an “if” statement following the pattern shown in the figure below (This is in the index.ejs file in the root-config application).

Figure 11: Environment configuration

For the layout of the application, we used single spa layout which is a helper library from single spa that allows us to write template in the head of the html document in order to specify the layout of the application:

Figure 12: single-spa layout

If you want to checkout the full source code of this example you can do that here.

Single-Spa supported with the optional helper package  single-spa-layout  is a great framework and you can do a lot with it. It provides micro apps layout, routing, lazy loading, top level routing API controls, apps out of the box.

It supports most of the existing popular frameworks and libraries out there (at the time of writing this article) so that you can go ahead and create a new application add single spa to it and transform your application in a micro application. Because it has a lot of features, the best way to learn more about the framework is to go through the official documentation.

You can access the full source code of this example here. Have a great micro-frontend-programming!

For more information on how to proceed, go here.

They are the first faces you will probably meet in IT Labs, and there is a reason for it. Biljana Stefkov and Ana Georgieva have a major role in the company’s growth by recognizing the talent that’s a good fit for our high-performing teams. You will immediately feel comfortable in their presence because they are a real embodiment of the company culture – professionals that are also kind-hearted people.    

And they are the right people that can explain and clear the air on much confusion around the recruitment process. We had a wonderful conversation on different important topics related to recruitment in general, and how the process of recruitment looks like in IT Labs. It has meaningful insights that can help you prepare and make the right impression, so take a deep dive and read it.

Why did you choose this profession? Was it a life calling? 

Ana: I think that I defined my career path early in my high school days, but I wasn’t sure what it meant back then. I started volunteering in the local NGOs led by the desire to be the voice of the voiceless, a friend of the lonely, and shelter for the unprotected. And as the saying goes, one thing leads to another, I started working as a social worker, but then I realized that I love business as well. Long story short, this is how I became part of the IT Labs HR team.

Biljana: I’ve always wanted to help people. By being a recruiter, that’s what you do. On the one hand, you help people find great jobs, and on the other, you help the company or client find great people. Seeing the creation of a long-lasting successful relationship is something that fulfills me.  Years ago, I became interested in HR in general, and during my career, I was involved in a few of the streams covered by HR, but recruitment stuck close to my heart. The connections you create, the people you meet, the relations you see. Everything plays its part in deciding why I choose to work as a recruiter.  I also see my personality as a mix of equal parts of creativity and drive for analytics. And found recruitment as THE profession that combines those two daily.

How do you break the ice with a candidate? Do you have a trick in your sleeve? 

Biljana: I see the interview as a conversation with a smart, mature person who is great at what they do and is also aware of why we are having the conversation.  So, in this case, I don’t necessarily see the need for having an ice breaker. When you know why you are there and know the discussion subject, it comes quite naturally to have the conversation. The main idea of having a quality talk is to listen to the candidate carefully and skillfully direct the conversation.

Ana: When I was a beginner, I was trying to introduce myself more formally and professionally. But, as time went on, I realized that the perfect mix between being professional and friendly to the candidate is the key to leading the candidate towards a fruitful and successful recruitment process. The candidates should be aware that the recruiters are their friends and the bridge between them and the hiring managers. After all, we have the same goal – to hire them.

What is your general impression – are people afraid of interviews? Can you suggest something that can help them shake off the anxiety? 

Ana: Work on your attitude. I am not saying that you should be overconfident, but everyone enjoys having a conversation with people who have a winning attitude. Don’t overthink possible interview scenarios, prepare yourself (learn more about the position and the company), and go with the flow.

Biljana: I think people generally are not afraid of interviews. At the beginning of the conversation, it might come a bit odd to start sharing professional and personal aspects of one’s life with someone you’ve just met. Still, it’s the recruiter’s role to create an environment that will make the candidate feel comfortable and safe.

What‘s your favorite question to ask? 

Ana: I don’t have favorite questions, although I always want to learn more about candidates’ favorite projects. In my opinion, it’s vital to learn about their points of interest, such as technologies, challenges, or what kind of teams they want to work in. Having this conversation can lead you to the conclusion if your company culture matches the candidates’ expectations.

Biljana: Each person is unique, and so is the conversation (interview) you have with them. I don’t have any favorite questions that I ask. The questions depend on the candidate’s story and the type of connection you create during the interview.

How would you describe the recruiting process of IT Labs? 

Biljana: Process-driven and flexible 😊. That’s what I love about IT Labs. It has its defined ways of how a quality recruitment process should look like. Even though we follow it in most cases, it is flexible and able to be modified to achieve the best results for all parties involved (company and candidate).

Ana: I would agree on this one with Biljana. The perfect definition is indeed process-driven but flexible.

Why should a candidate become part of IT Labs? 

Ana: If you want to work in a process-oriented, structured, but friendly environment, you should seriously consider joining our company. As part of the IT Labs team, I would like to emphasize that working in an organization focused on people’s growth makes me feel comfortable about my future.

Biljana: The decision of someone to change a job is quite personal, and I do think it needs to be based initially on personal needs, combined with what the other company and position have to offer. Once the personal aspect is set, IT Labs has a variety of advantages it can offer:  multiple projects and clients, modern technologies used, interesting set of requirements in job positions, a culture of appreciation, balanced approach towards support and challenge of its employees… and much more 🙂

How do you sustain a professional manner while also being friendly to the candidates? 

Biljana:  I think that in business people create special bonds (especially during a recruitment process), but I see it as different rather than regular. A specific type of connection that is leaning more towards a professional behavior combined with politeness rather than friendliness.

Ana: Professionalism, among other things, means knowing the boundaries between work and personal life. There is no need for extra effort if you follow this simple rule.  However, we have to show empathy and validate people’s feelings during the recruitment process.

What is the biggest challenge of being a recruiter?  

Biljana: As in any profession, there are good days and bad days. What is important is to love what you do, and that’s how you’ll find joy in most of the days spent doing that. Personally, I don’t see a specific challenge of being a recruiter.

Ana: To understand your potential candidates’ needs, their interests, and to get their attention. I am not sure if this is the biggest challenge or the shortest job description ever (just kidding). 🙂

There is a negative trend of ghosting in the recruitment process. What is your take on this? 

Biljana: To be honest, this trend is a worldwide issue from both sides – candidates and recruiters. As bad it is to be ghosted by the candidate, it’s good to take that as a lesson from a recruiter’s point of view and just imagine how a candidate would feel if you don’t come back with feedback after an interview. But I see this as a resolving issue in the future, since it’s quite connected with the increased usage of social media, and I believe that polite behavior principles will apply in this type of communication with time.

Ana: Being ghosted, either you are a candidate or recruiter, can make you feel uncomfortable. If the recruitment process was software, ghosting is the perfect example of having a bug in the software. It is essential to understand that the bug is not intentional neither nor personal.

I believe that both candidates and recruiters are aware of ghosting’s negative effect, but sometimes it happens.

It’s up to us to work on the continuous improvement of our responsiveness.

What is the biggest misconception that you have noticed regarding the recruitment process in general? 

Ana: The biggest misconception that people have regarding the interview process and recruiter, in general, is that recruiters are just people who are collecting resumes and only care to fill the position no matter what. As a recruiter, I would say that this belief is incorrect. Our recruitment team is striving to build strong and long-term relationships with the candidates, understand the requirements in detail, find and hire the best-in-class engineers, and deliver high-quality results.

Biljana: Oh, there are quite a few… 😊. But something that I’ve noticed through the years is the misconception that the initial interview with the recruiter is unnecessary, meaningless, or just a procedural meeting, without the opportunity to benefit from it. I think the truer side of the story is quite the opposite.

The initial interview is a crucial part of the recruitment process. The discussion where both sides – the company (through the recruiter) and the candidate – can find out every important detail that helps them clarify whether they are a good potential match. The initial conversation with the recruiter is where you can ask and share literary anything you consider important for your career. It is a conversation that can lead to a life-changing decision.  It has weight; it is a constructive and directed conversation towards a specific goal. At the same time, it is flexible enough to provide a safe environment for sharing and asking the tough question you naturally wouldn’t ask during the rest of the recruitment process. It provides the candidate with a key to all the company inside info you cannot find easily on the web. On the other hand, it allows you to meet your “go-to” person – the person you can lean on through the whole recruitment process (the recruiter).

On the positive side, I think this misconception of undervaluing the initial interview is slowly changing, as people feel freer to explore the labor market and go to interviews more often than they did previously.

How can a candidate WOW you?  

Ana: People speaking with integrity can always WOW me. I am always amazed by candidates who have a high level of self-awareness, not only for their strengths but also their weaknesses. And the third thing that is crucial for me is the candidate’s eagerness to learn.

Biljana:  True, honest people, with an awareness of personal strengths and flaws, amaze me in any setting, not only during the interviews. Having a conversation with this type of person is truly remarkable. And I consider myself lucky since this profession allowed me to meet many great people who nurture those values in themselves.

What‘s the best interview advice you can give to candidates or people looking for job opportunities? 

Biljana: Just be yourself. Take ownership of what you know and what you do and bring that to the recruitment process.

Ana:  Try to listen carefully and take your time to answer the questions. Interviewers are just people who passed the same process as you to get their jobs. We are aware that, sometimes, the interviews might be stressful for the candidates. Don’t fake it till you make it. Be yourself.

Maja Tanushoska

Digital Marketing Specialist