DEV Community: Stipe

Mobilewright Part 2: From The First Test to a Real Test Suite

Stipe — Tue, 06 Oct 2026 18:32:59 +0000

You've written your first Mobilewright test. Now let's grow it into a suite that's organized, readable and ready to run on real devices.

In Part 1 we covered what Mobilewright is, why it feels so familiar if you know Playwright.

One basic test isn't a test suite. What happens when you have 10 tests? 50? Several screens, several devices, and a teammate who wants to add tests too?

In this post I will take that single test and grow it, step by step, into something you would be proud to hand over to your team. As before, there is very little code: this is about how to think about structure, not memorizing syntax.

How your very first test might have looked like

Your first test looked roughly like this:

test('user can log in', async ({ screen }) => {
  await screen.getByTestId('username').fill('demo');
  await screen.getByTestId('password').fill('Bigs3cret');
  await screen.getByRole('button', { name: 'Log in' }).tap();
  await expect(screen.getByText('Welcome')).toBeVisible();
});

It works. But imagine 20 tests that all start by logging in. If the login button gets a new test ID or name. You'd be fixing the same line in 20 places.

That's the first problem we'll solve.

Step 1: Give every screen its own home (Screen Objects)

In web testing with Playwright, you have probably heard of Page Objects. In mobile testing, the same idea is usually called Screen Objects.

The idea is simple:

One class per app screen. It knows where the buttons are and what you can do on that screen.

So instead of tests that talk about test IDs and buttons, you get tests that talk about what the user does:

test('user can log in', async ({ loginScreen, homeScreen }) => {
  await loginScreen.login('demo', 'secret');
  await expect(homeScreen.welcomeMessage).toBeVisible();
});

That reads almost like English. And when the login button changes, you update one file, the Login screen class, and every test is fixed.

Beginner tip: start with a small base class that every screen extends. It's a handy place for things all screens share, such as "am I on Android or iOS?"

Step 2: Let fixtures do the setup for you

Did you notice loginScreen and homeScreen in the test above? We didn't create them with new LoginScreen(...). They just appeared.

That's a fixture, one of Playwright's best features, and Mobilewright has it too.

A fixture is a way of saying:

"Whenever a test asks for loginScreen, build one and hand it over."

You define it once, and every test can simply ask for what it needs. Your tests stay short and focused on behavior, and all the setup lives in one place.

If you've used Playwright's page fixture, you've already used this pattern. You're now just making your own.

Step 3: One config, many devices

Here is where mobile starts to feel different from web, and where Mobilewright shines.

On the web, Playwright projects let you run the same tests on Chrome, Firefox and Safari. In Mobilewright, projects are devices:

a Pixel emulator
an iPhone simulator
a real Samsung phone in the cloud

You list your devices once in the config, and then choose which one to run on:

npx mobilewright test --project="Pixel 8"

A nice pattern I recommend is keeping the device list in a small separate file (JSON works well). Then adding a new device means adding one line, not editing your config logic.

Step 4: Same tests, laptop or cloud

In Part 1 I mentioned that you can start locally and move to real devices later. Here is how that looks in practice.

Your config can check one environment variable:

No cloud key set → use the local driver and your emulator
Cloud key set → use real devices from a device farm

Your tests don't change at all. Only where they run changes.

This is great for teams: developers run tests on their own emulators during the day, and the pipeline runs the same tests on real phones every night.

Beginner tip: when running locally, make sure that cloud key is empty. Otherwise you might accidentally book a cloud device when you only wanted your emulator.

Step 5: Write tests your whole team can read (BDD)

Once your suite grows, you will have people asking:

"What exactly do our mobile tests check?"

Reading TypeScript isn't fun for everyone. That's where BDD (Behavior-Driven Development) comes in. You describe tests in plain language:

Scenario: User logs in with valid credentials
  Given the app is open on the login screen
  When the user logs in with valid credentials
  Then the home screen is displayed

Each line is connected to a small piece of code (a "step"), and those steps use your Screen Objects from Step 1. Everything you've built so far fits together:

Feature file → Steps → Screen Objects → Mobilewright

Product owners can read the feature files, testers can write new scenarios by reusing existing steps, and the automation runs underneath.

Step 6: Stop preparing data through the app

This is the lesson that saved me the most time.

Say a test needs a brand-new user. The tempting approach is to tap through the sign-up screens at the start of every test. Don't. It's slow, it's flaky, and if sign-up breaks, every test fails, even ones that have nothing to do with sign-up.

Instead:

Create test data with API calls before the test (in a "before" hook)
Clean up with API calls after the test (in an "after" hook)
Use the app's UI only for what you're actually testing

Your tests get faster and more stable, and when something fails you know exactly where the problem is.

Step 7: Every test starts fresh

This one sounds obvious, but it's easy to forget.

If test A logs in and test B silently relies on already being logged in, you have created a hidden dependency. Which is path to flaky test.

Rule of thumb: Every test should start from a clean app, as if it were just installed. Yes, it costs a few seconds per test. It saves hours of debugging failed tests.

Step 8: Learn to read failures

As your suite grows, failures happen. That's normal, and it's the whole point of testing!

Mobilewright gives you good tools here, just like Playwright:

The HTML report shows each step, how long it took, and where it failed
The UI tree on failure is a snapshot of everything that was on screen when the test broke (switch it on in the config)
mobilewright doctor is still your friend whenever something about the environment feels off

A few things that might save you time:

A locator found the wrong element. For example, searching for the text "Login" matched the screen title instead of the button. Be specific: prefer test IDs.
Mobilewright doesn't complain about duplicates. Playwright on the web fails when a locator matches two elements. Mobile can quietly pick the first one. Another reason to use unique test IDs.
A button said it was disabled when it wasn't. Some apps report a button as disabled while the keyboard is open. Check what the user actually sees, not only the button's state.

Step 9: Run it automatically (CI)

Now that your suite is organized, the last step is making it run without you.

Since it is "just" a Node.js project with a test command, you can run it in any CI system, such as GitHub Actions, GitLab CI or others. The typical setup:

Install dependencies
Get the app build (APK or iOS app)
Run the tests against cloud devices (no emulator needed on the CI machine)
Save the HTML report as a build artifact so anyone can open it

Remember Step 4? That's why it matters. The tests that run in CI are the exact same tests you run on your laptop.

What your project looks like now

Let's zoom out. We started with one test file. Now we have:

features/      → plain-language scenarios (BDD)
steps/         → glue between scenarios and screens
screens/       → one class per app screen
fixtures/      → setup that tests can ask for
api/           → test data creation and cleanup
devices.json   → which devices we run on
mobilewright.config.ts

Every folder has one clear job. A new teammate can open the project and understand it in minutes.

Recap

Going from one test to a real suite comes down to a few ideas:

Screen Objects keep locators in one place
Fixtures keep setup out of your tests
Projects = devices, so one test runs anywhere
BDD makes tests readable for the whole team
APIs prepare test data, the UI is only for testing
Every test starts fresh
Reports and UI trees explain failures
CI runs it all for you

And the best part? Almost every one of these ideas comes straight from Playwright. If you learned it for web, you already know it for mobile.

How is your mobile test suite organized? Do you use Screen Objects, BDD, or something else entirely? Tell me in the comments! 👇

Mobilewright Part 1: Sleeping Giant: If You Know Playwright, You Already Know Mobile Testing

Stipe — Tue, 29 Sep 2026 18:03:59 +0000

A beginner-friendly introduction to Mobilewright: what it is, why it's great, and how closely it resembles Playwright.

Mobile test automation has a reputation for being painful. You install lots of tools, run servers in the background, wait on things by hand, and get tests that fail for no clear reason.

If you used Playwright for web testing, you know it doesn't have to be that way. The good news is that the same experience now exists for mobile apps. It's called Mobilewright. Oh yes!!

In this post I'll explain what Mobilewright is, why I like it, and how closely it resembles Playwright. You don't need any mobile testing experience to follow along.

What is Mobilewright?

Mobilewright is an open-source framework for writing automated tests for Android and iOS apps. It lets you:

Open your app on an emulator, a simulator or a real phone
Find things on the screen (buttons, text fields, labels)
Tap, type, swipe and scroll
Check that the app shows what it should

In short, it's Playwright, but for phones. Its authors designed it to feel the same: the same way of writing tests, the same kind of commands, and the same reports.

Why QAs will love it

1. Setup is short

Traditional mobile automation often means setting up a separate automation server, drivers and a lot of configuration before your first test runs.

With Mobilewright you install a package, run one command to check your setup (mobilewright doctor), and you're ready. That command tells you what is missing and what to fix, so you are not left guessing.

2. It waits for you

The most common beginner mistake in UI testing is adding "sleep 5 seconds" everywhere and hoping the app has loaded.

Like Playwright, Mobilewright waits automatically. When you say "tap this button", it waits until the button appears. When you say "expect this text to be visible", it keeps checking until the text shows up or a timeout runs out. Your tests get faster and less flaky without extra effort from you.

3. One test can cover Android and iOS

You write the test once and choose which device to run it on. The same test can run on an Android emulator today and an iPhone simulator tomorrow. Important to note is you can use same element locator for both Android and iOS, which is not the case with other frameworks.

4. Local first, cloud when you need it

You can start on your laptop with a free emulator. When you are ready, the same tests can run on real devices in the cloud, usually by changing one setting and not your tests.

5. Reports that show what went wrong

When a test fails, you get an HTML report that shows which step failed, the error, and a snapshot of what was on the screen. Debugging turns into reading the report instead of guessing.

How Mobilewright resembles Playwright

This is what makes it so easy to learn. If you know Playwright, here's how the concepts map:

Playwright (web)	Mobilewright (mobile)
`page`: the browser tab	`screen`: the phone screen
`browser`	`device`: the phone itself
`getByRole`, `getByText`, `getByTestId`	Same locator methods
`click()`	`tap()`
`fill()`	`fill()`
`expect(...).toBeVisible()`	`expect(...).toBeVisible()`
`playwright.config.ts`	`mobilewright.config.ts`
Projects = browsers	Projects = devices
`npx playwright test`	`npx mobilewright test`
`npx playwright show-report`	`npx mobilewright show-report`
Fixtures and Page Objects	Fixtures and Screen Objects

Here's one small example so you can see it for yourself.

Playwright (web):

test('user can log in', async ({ page }) => {
  await page.getByTestId('username').fill('demo');
  await page.getByTestId('password').fill('Bigs3cret!');
  await page.getByRole('button', { name: 'Log in' }).click();
  await expect(page.getByText('Welcome')).toBeVisible();
});

Mobilewright (mobile):

test('user can log in', async ({ screen }) => {
  await screen.getByTestId('username').fill('demo');
  await screen.getByTestId('password').fill('Bigs3cret!');
  await screen.getByRole('button', { name: 'Log in' }).tap();
  await expect(screen.getByText('Welcome')).toBeVisible();
});

That's the whole difference: page becomes screen and click becomes tap. Everything else carries over, including your habits, your project structure and your team's existing Playwright knowledge.

Beginner tips from my experience

Ask developers for test IDs. The most reliable way to find an element is a stable ID that the app developers add for testing. It's a small request that makes every test more stable.

Use the Page Object pattern from day one. Create one class per app screen (for example a Login screen or a Home screen) that holds its buttons and actions. Your tests then read like plain English, and when the UI changes you update one file.

Keep tests independent. Start every test from a fresh app state. If one test depends on another, a single failure spreads through the whole suite.

Prepare data outside the app. If a test needs a user account, create it with an API call, not by tapping through sign-up screens. Save the UI steps for what you actually want to test.

Pin your versions. Mobilewright is young and improves quickly. That's exciting, but pin your versions so an update doesn't surprise you in the middle of a sprint.

Read the failure report before changing code. The screen snapshot in the report usually tells you exactly what went wrong.

Bonus: it works well with BDD

If your team likes writing tests in plain language (Given / When / Then), Mobilewright works with Gherkin feature files through Playwright's BDD tooling. Product owners and testers can read the scenarios, and the automation runs underneath.

Final thoughts

For years, mobile testing felt like a different, more difficult world than web testing. Mobilewright closes that gap. If you can write a Playwright test, you can write a mobile test.

Install it, run doctor, write one test for your login screen, and watch it run on a phone. That first green test is very satisfying. 📱✅

Have you tried testing mobile apps yet? What was the hardest part for you? Let me know in the comments! 👇

Epoch - Ethereum 2.0

Stipe — Mon, 10 Jun 2024 15:44:28 +0000

Greetings!! This is the first article that I plan to publish about random things Ethereum 2.0. In this article boss of the hour is Epoch. You will find out what is epoch in Ethereum 2.0 proof of stake, and what role does it play.

Ethereum Epoch is a time frame during a set of validators activities are happening.

Activities:

Validators propose blocks
Validators attest blocks proposed by others

Each epoch is divided into smaller time units, called slots. One epoch has 32 slots. Each slot lasts 12 seconds. Meaning each epoch lasts approximately 6.4 minutes.
One epoch therefore will have 32 blocks, and each slot will have one block.

In each slot there is one validator that is assigned to propose a new block, and a committee of validators that attest validity of that block.

Imagine a hotel named "The Grand Ethereum hotel". Each night, the hotel's kitchen team of chefs works together in a organised way to prepare a set of dishes for buffet dinner for hotel guests. Kitchen operates on a precise schedule to ensure fairness, efficiency, and culinary excellence.

Let us imagine one epoch is one night, or one dinner service. Therefore each epoch represents one dinner service over entire year.

For each slot, a team of chefs is involved. Among them, one chef is randomly chosen to be the Lead Chef for that slot. Selection process is fair, unpredictable and random, ensuring every chef has the opportunity to lead.

The chosen Lead Chef for that slot is responsible for making key decisions, coordinating the team's actions, and creating a dish (proposing a block).

Supporting Chefs' Role: The other chefs act as committee (attesting validators). They assist the Lead Chef by checking and supporting their decisions and actions, making sure everything is cooked perfectly. They attest the dish before it is given to hotel guests.

To summarise once again, In Ethereum 2.0, epoch consists of maximum 32 blocks. This means every epoch is composed of 32 slots, with each slot potentially holding one block. Slots occur every 12 seconds, making each epoch approximately 6.4 minutes long. Validators work within these epochs to propose and attest to blocks, ensuring the security and consensus of the network.

Distributed validator technology with Obol Labs

Stipe — Thu, 30 May 2024 10:35:51 +0000

Recently I was reading about Obol Labs and found intriguing what they are offering to the world. If you are into proof of stake I think you should read this one and check out their official docs

Obol team is working on Distributed Validator Technology. Their mission is to preserve decentralization, make validators more fault-tolerant, and even give opportunity for smaller individuals to participate as validator.

Quote from their documentation:

The Obol Network will become an open, community governed, self-sustaining project over the coming months and years. Together we will incentivize, build, and maintain distributed validator technology that makes public networks a more secure and resilient foundation to build on top of.

One word is enough. Beautiful.

If you are familiar with Ethereum 2.0, in proof of stake validators get punished for malicious activity. But sometimes validators get penalty without malicious intent. It can happen due to errors or misconfiguration. For example you can have 2 nodes and by mistake use same validator key on both, which would result in double voting or double proposing. Or your validator goes offline for longer than allowed, will result in inactivity penalty. Obol jumps to solve this as well. Lets find out how.

DVT - Distributed Validator Technology is a Ethereum proof of stake validator that consists of multiple entities forming one validator. Not all validators need to be online 100% of the time in order to continue participating in the network. More info on that in here

Charon is a distributed validator client designed to work as part of the Ethereum proof-of-stake protocol. It forms a cluster of nodes that collectively act as a single validator. Meaning they allow multiple entities to join into one group and act as one validator in Ethereum network.

Each node in the cluster is responsible for contributing to the validation process, ensuring high availability and fault tolerance.

Traditionally when you were setting up a node you needed to generate public/private key. Now you probably are already wondering, how will multiple entities who have joined to form one validator keep this trustless. Solution is called key sharing.

Entities who agreed to form a group and act as one validator, will collaboratively generate and share a distributed key without any single participant knowing the complete key. This process enhances security and fault tolerance for operating distributed validators by ensuring that no individual entity holds complete control over the key. You can find out more in official docs

Benefits of Using Charon

Resiliency: The distributed nature ensures that validator operations continue even if some nodes go offline.

Security: Distributed shared key mechanism enhances the security of the staking process.

Decentralization: Helps broader goal of Ethereum’s decentralization by enabling more participants to run validators in distributed way.

Setting up Charon involves coordination and careful configuration but results in a robust and secure validation setup for Ethereum staking. For more detailed steps and technical specifics, refer to the Charon documentation provided by Obol Labs.

Testing Pyramid

Stipe — Sun, 19 May 2024 12:19:40 +0000

Hey developers and CEOs, this article is for you.

Im going to explain you five different types of software testing that you need to know as a software developer or a CEO of an IT company.

You have probably heard of the testing pyramid. Chances are you probably haven't thought much about why the pyramid is a pyramid to start off with.

Unit Tests

Tests at the bottom of the pyramid should make up the majority of the tests in your test suite. This is where you should be focusing most of your efforts on. As we move up the pyramid, the tests become more complex and slower and they take more time to maintain. At the base of our pyramid, we have the unit tests.
Now, most developers are aware of what unit tests are and the importance of them. Developers are the one who are writing unit tests and they are responsible for that part of quality assurance. Developer writes unit tests for all the methods and functions in the code, to ensure that the program is working correctly at the lowest level.
You may wonder on the number of unit tests you have to write. That really depends on what the goal is for your testing strategy. You should aim for and test every single line of your code in your methods. If for some reason something is preventing you, then that should be a sign that your function is doing too much or you haven't written it with testability in mind.
100% testing coverage means to have test coverage of every single line of code.

Unit tests are not enough to ensure that your software is working and looking as expected. You should not assume anything if it is working at the lowest level, that it's all going to work when you put it together. That is often not the case. For that reason we introduce next level of testing in the testing pyramid.

API Automated Tests

The next level up in our testing pyramid is what we call API tests.
This is where we test each endpoint in isolation, to cover expected and unexpected behaviour. Error messages, response body, json schema, http status codes, etc.
API tests are very fast, and we should when scenario allows us aim for writing end to end tests. To ensure that feature workflows are working exactly as we expect them.

You would run them in dev environment which should be a mirror of your prod environment.

Unit tests and API tests are all generally run as part of the build process, before a release, after each git push to your working branch, after each git push to master branch or you have them scheduled to run at certain time. Depending on how your process is defined.

Frontend Automated Tests

If you're writing a web application, then these will typically be in the form of automated UI tests.
And we generally use tools such as selenium, playwright and such, to mimic user action in the UI through a web browser. The goal here is to test that everything is working as expected end-to-end, is clickable, typeable and such. These tests typically include a mix between functional testing, such as making sure that you can signup/login or a form is populated correctly, And acceptance testing, which makes sure that your application is meeting business requirements. I tend to write end-to-end tests in style what is called a Gherkin language, which follows the given-when-then pattern. Frameworks such as Cucumber or any other BDD framework allow us to execute code in this format while still having the tests non-technical-human-eye-readable.
These type of tests are significantly slower than unit and API tests and can take really really really long time to run, and typically they're not run on every single git push. Imagine you have hundreds of these tests, they can take several hours to run, so you generally need to run them overnight.

Frontend automated tests are not ideal if you want to be releasing very often in a startup style. Most QA teams split up their tests into multiple groups tagging scenarios by critical group that they can run before each deployment.
For example, most essential tests can be tagged as @smoke and you can setup to run only subset of those tests tagged with that tag after given action. This would save you time, and you would run only what you need. While full suite of tests you could schedule overnight.

It is important to note that these tests need all the components working together, and therefore they're typically run on an environment such as QA or UAT. It can take a while to have a stable set of end-to-end tests. Subtle things such as your application taking a little longer to load, or someone accidentally breaking QA or UAT environment can cause your tests to break, and therefore you generally need someone working full time on your automation tests. Maintenance is absolutely crucial, in both API and Frontend tests. Especially in Frontend tests, as they are most dependent and most fragile.

Manual Tests

As cherry on top of our pyramid, we have manual tests. These are the tests that either need human eye, human exploratory mind, or they are not worth the time in trying to automate them. Manual testing even though unfairly not respected enough play important part in the last final piece of functional and visual side of the software application.

There are certain bugs you can only find by executing manual testing.
Manual testing should be executed in various phases. While feature is developing, you want to test new things, but you also want to make sure you are executing entire suite of tests you have from before, to ensure that new code did not break existing features. That is also called regression testing.

When you find a bug in your application, it is always better to find it lower down the pyramid than near the top. Each bug found in manual testing phase makes you to run application, reproduce the issue and search for logs and try and work out where exactly your application failed. Compare that to finding a bug in your unit tests and you will be given a stack trace that shows you the exact line where the problem occurred.

Testing is...

Stipe — Thu, 16 May 2024 09:54:10 +0000

Testing involves conducting a variety of experiments to understand the product's actual behaviour, capabilities, and limitations, revealing insights beyond initial expectations or documentation.

Testing is:

Ensure everything works as expected
Identifying potential risks
Uncover edge cases
Promote culture of quality
Be the client (Put yourself in shoes of clients)

The main objective of testing is to uncover risks that could affect the product's success, including vulnerabilities, performance issues, and other factors that might lead to failures in production.

When we talk about edge cases, there are testers that will seem efficient in the eyes of project managers but they will never add extra layer that might cover potential risk. Testing seeks to find those rare but critical scenarios that occur at the extremes, they cover what can happen in rare situation. Rare does not mean less risky. One "hole" can be very expensive if discovered in production.

Testing is not:

Just writing test plan and test cases
Only finding and reporting bugs
Automate every single thing
One time thing

While documenting test plan and test cases is necessary, effective testing goes beyond this, requiring critical thinking, creativity, and adaptability to new information and evolving requirements.

Testing isn't about assigning blame for defects. It's a collaborative effort to improve the product. A blame-free environment encourages open communication and teamwork, which are crucial for successful testing and quality assurance.

Having automated tests is a super useful, but it cannot replace exploratory testing and human judgment. Some scenarios necessitate manual testing to uncover issues that automated scripts might miss.

Testing should be integrated into every phase of development, from initial design to post-release maintenance. It’s not just a final checkpoint but an non-stop process contributing to the product's continuous evolution and standard of quality.

The Graph Demystified - Fetching Data From The Limitless Blockchain Bookshelves

Stipe — Wed, 13 Mar 2024 14:45:32 +0000

As a curious man I was reading about the graph protocol. Since I am not a blockchain developer I wasn't aware of challenges when you are in need of grabbing certain data from a particular location on the blockchain. I found it interesting how Graph works and I think it is a good idea to share with others what I have learned and how I understood it. So let's get started.

Standard definition:
The Graph enables indexing and querying of data from various blockchains. It facilitates efficient and performant access to complex data sets, such as those from smart contracts and NFTs. These APIs(subgraphs) are queried with GraphQL.
More in official docs: https://thegraph.com/docs/en/about/

All humans common language definition:
Finding needle in the Blockchain data haystack, this is what Graph let's you to do in quick and easy way.

The Graph is not Google of blockchains. However, unlike Google where users directly type in search queries to find information, The Graph is used by developers. They integrate The Graph into their applications (web3 or Dapp) to query blockchain data efficiently. So, it's like Google's powerful indexing and data retrieval capabilities, but specialised for the world of blockchain data, accessible through a developer's toolkit rather than a simple search bar.

There are 3 roles in the system:

Indexor
Delegator
Curator

I will use analogy to explain each role in the system, so it's easier to understand.

Imagine Graph is gigantic library. Library is full of book. Someone needs to maintain those books, keep them in order, suggest new books that should be added to the library, add new books, and keep entire library running smoothly and safely. So lets get started.

Librarian = Indexor
Helper/Investor = Delegator 
Book Scout = Curator
Library user = Graph user
------------------------
Graph    = Library
Subgraph = Book

Now imagine a scenario, you are a research student/library user and you need to find certain information for your thesis. Next day you decide to visit library and see if they have a book that contains data that you need.

It's Monday, 08:00h in the morning, library just opened, inside the library are librarian (indexor) and the book scout (curator).

Book Scout (Curator) has been very busy. He has been exploring various sources, looking for Books that contain unique, valuable, or particularly relevant data. When he finds a Book that meets these criteria, he signals its value to the Library with a "recommendation" tag, which effectively is communicated to the Librarians (Indexors). It then is prioritised for acquisition.
This is how books (Subgraphs) are added to the library (Graph)

At roughly 08:30h, you (the student) are entering the library. Inside the library you are welcomed by the librarian (indexor), a knowledgeable individual, who manages the organisation and accessibility of the books (subgraphs).

In a short chat, you explain what kind of topic you are searching, and librarian (indexor) points you (graph user) to a particularly well-regarded book (subgraph) that covers exactly what they need.

Now when I have found the book I need, I am ready to borrow it but I only need one piece of information from the book. Good old librarian explains me that there is a new technique where I can take with me a particular piece of the book if I want. That new technique seems like a great idea, he explains that I can specify a "list of data" (GraphQL query) of certain chapters (fields) and he will service me with exact info that I chose. So this is what I did. I submitted a list to the librarian (sent a query to indexor), who found data in that book (subgraph) and delivered me exactly what I wanted. Wow, super nice!!!

It's important to note that Library's vast collection of books and its organised state are partially thanks to Helper/Investor (Delegator) who, although not actively participating in the day-to-day management, has invested resources into the Library. His support enables the Librarian to maintain and expand the Library's collection, ensuring that it remains a valuable resource for all library users.
In return Helper/Investor (Delegator) is rewarded with a portion of the profit.

Library user is amazed with how good the library ecosystem is functioning. Helper/Investor helps with his resources (GRT token), book scout (curator) busy as a bee searching and suggesting new great books (subgraphs), while good old librarian (indexor) is always there to serve in best possible way. Therefore in this harmony of collaborative effort they are providing library users (graph users) with access to exact data they need in efficient and accurate way.

If you have thoughts on how you see the Graph ecosystem, or you would like to add to this analogy, make sure to comment.

User should understand blockchain technology?

Stipe — Thu, 29 Feb 2024 16:54:57 +0000

Blockchain has been around since 1991. A lot of people relate blockchain to Bitcoin and think Satoshi Nakamoto invented it. What Satoshi did was he combined several existing technologies into one masterpiece, as no one had done before.

In the 1980s at BellCore, there were two colleagues, Stuart Haber and W. Scott Stornetta, who realized that everything was going to become digital, and digital records can be easily changed. So, the idea of having a need to have immutable records was born. In 1991, they finished their work, but it showed the world and its current technology development was not yet ready for it. So, it waited for many years to get picked up.

Blockchain technology is more than crypto. Important thing to know is it can be used not only in cryptocurrencies world, but almost everywhere. Why it's not already used in all other aspects of our digital services is another pair of shoes.

This technology is often thrown out there as buzzword in regular conversations by the business people who may not understand it, but they want to be part of the train that might acquire them some earnings. That is ok, not everyone should be a technologist.

There are two sides: those who create it and those who use it.

Those who create it are engineers, and they should know how it works. But should user know how it works?

Today you are using internet, tv, mobile phone, but do you bother to understand the foundation technology behind the internet, TCP/IP. Do you wonder how your tv converts a digital signal into an image? A tech called DSP. Or have you ever questioned your mobile phone and how the tech behind it enables you to talk and receive messages, GSM/4G/5G, probably no, and you are still an everyday user of all of these three. It's so common and easy to use that you now take it for granted, as if you are entitled to them.

That should be the goal of engineers: To implement blockchain technology into products that are useful for you, and the only thing that should matter is that the product you are using is useful and easy to use.

The assumption that understanding the technical details of a technology is essential for its adoption is misleading. Lack of technical knowledge has not stopped the mass adoption of tv/computer/internet/mobile phone. People are generally indifferent to the mechanics of technologies as long as they serve their needs effectively.

Therefore, leave the details of the problematics to those who are working on finding solutions, everyone else should wait to see if there will be a useful product that they would use.

Docker explained for non-technical people

Stipe — Thu, 22 Feb 2024 17:09:22 +0000

Over the years working in software testing I came to realise that there are keywords thrown out there as if everyone understands them. If I know how to use Docker it does not mean everyone else knows it, and to show respect we should always know the audience with who are speaking with and adjust the language so that everyone can understand. Goal is NOT to play smart, but person on the other side to actually understand you. That is also a form of respect.

Let's imagine a conversation inside a company between QA and Recruiter. Recruiter received a task to hire new QA, and we/company gave him a list of tools a new candidate should have. Recruiter received the info and that's were it usually ends.
Recruiter is left to find a person based on keywords, which is ok, but what if I, you or your colleague actually take a bit of time and help your recruiter to better understand what certain tool does for us.
Now, you can say: "OK, let recruiter google it, I don't have time". Fine, thats what everyone has been doing since Google is founded.

Remember this old wisdom:

Give a man a fish, and you feed him for a day. Teach a man to fish, and you feed him for a lifetime.

To show some respect, take a bit of your time and explain in real life examples a certain tool so that anyone who heard about that tool can understand what it does. High level is enough.

What is the goal? Why would you waste your time?
Sharing knowledge is never wasted time. It's called help. Helping someone to understand, will help him to do his job better, and ultimately find a better colleague who will work with you everyday.

Sharing knowledge is something you should be excited about. It should give you a feeling of satisfaction/accomplishment.

Let's write this in a dialog between me and recruiter.
Imagine a video call between two colleagues in the company. Recruiter Marco and QA Stipe :-)

Recruiter: Ok, amigo. Tell me what is Docker
Stipe: Docker is a platform. There are buzz words such as container and image. But don't worry too much about them.
Imagine a container as your own virtual machine where you can install OS (such as Ubuntu, Windows, ...), libraries, programming languages, applications, etc.

Recruiter: OK, and?
Stipe: And now you can use that container and run your application on it, or you can run automated tests.

Recruiter: Hmm, interesting. Can you tell me more but use some kind of real-life analogy
Stipe: Sure, imagine there is a chef who works in portable kitchen on various venues and events to cook meals.
Before event each portable kitchen is equipped with all the chef's tools, ingredients, and recipes. No matter the location of the event chef always has same conditions for cooking his meals. So he can cook meal in the same way each time, without any external factors as disturbance.

Recruiter: Mmmm, I'm listening
Stipe: You can look at portable kitchen as Docker container, while ingredients/tools/recipe inside his portable kitchen are libraries/tools/os. You see where I am getting?
This means Docker delivers to your entire team one environment for working. Their local computer, different versions of this and that are irrelevant, they can now bring that container up spin their application in it, deploy, run, test. And with that, a legendary headache of "it works on my machine" is resolved, because everyone has same versions of everything.

Recruiter: Oh, now I get it. Docker is brilliant
Stipe: It sure is. I'm glad you understand it better now :-)

Selenium/Playwright explained to non-technical person

Stipe — Sun, 18 Feb 2024 22:52:34 +0000

Aimed to non-technical audience, this post explains what is automation tool selenium and playwright, in everyday analogy.

Imagine Selenium or Playwright as professional bodyguard assigned to protect bustling metropolis called "About YOU webshop"

This web metropolis is filled with various items, offering various clothing, shoes, accessories, etc. And quite often it has discounts, and best deals. This marketplace is constantly evolving, and the traffic is insane. To keep lifeline of the system running a good old bodyguard Selenium-Playwright is on his constant watch.

This digital metropolis consists of:

citizens (aboutyou users)
storefronts (webshop pages)
store item barcode (element locator)
and much more

Mission of Mr. Selenium-Playwright is to make sure daily flow, and functionality of the metropolis is working seamlessly.

Just as bodyguard protects and prevents certain problems, Mr. Selenium-Playwright mimicks user interaction to ensure every part of the metropolis works as expected. He can blend in using different disguises(browser) to ensure his employer understands the experience of every citizen(user).

Wanna find out how does a normal day look like for bodyguard Mr. Selenium-Playwright?

Ok let's dive into it.

1. Patrolling metropolis

Every day, mimicking citizen behaviour he goes through every storefront, including store items all through the cash register, where he confirms he can purchase items without any issues. He executes all actions citizens would normally do.

Therefore, he regularly walks through the digital streets(executing automated tests) and ensures all storefronts(webshop pages) are working and makes sure citizens(users) can use them without experiencing any faulty(bugs) behaviour that may cause metropolis to close down or repel user from entering once again.

2. Catching and identifying

Each time he executes a list of scenarios citizen(user) would do, there is a result at the end of each scenario. Sometimes those scenarios result in finding bugs/issues. He gathers evidence, and gives exact location of faulty(bug) behaviour, and a screenshot.

3. Reporting

At the end of each run of citizen behaviour test, he gives a nice report. This report is delivered to his boss. In that report he displays how many scenarios he executed, how many of them passed and how many are with faulty behaviour.

For what is Mr. Selenium-Playwright useful?

In the narrative of "AboutYou Webshop" Selenium and Playwright automation tools stand as the guardian of the digital city, working tirelessly behind the scenes to ensure that every user action, application functionality, elements is as smooth as a well-oiled machine. Magic of how Selenium or Playwright can execute all of these tests lays in hands of your software tester aka QA Engineer. That individual will write code for each scenario and add that to a continuous integration job, where those tests will be run on a certain schedule

Facts about automated tests:

they run faster then any other manual testing
reports are delivered after each test run
repetitive regression testing is no longer boring
find out if new features blend in with existing ones perfectly or they break something
saves time which gives QA Engineer more time to focus on complex testing scenarios that may require human judgment
win on the long run (the more automated tests you have the bigger ROI)
more time for exploratory testing
more time for writing new automated tests
covers more combinations than any human can in given time
eliminates human error

How you find this article? Let me know in the comments.

Can IT company survive without QA?

Stipe — Mon, 12 Feb 2024 11:42:55 +0000

In always fast-developing technological world, the question whether an IT company can survive without having a Quality Assurance (QA) team or not seems to be actual as never before.

Being small private IT company or big, pace is always the same, speed in delivery is important. Competition is big, customers are nowadays having less patience. Every detail matters, from UX to quality of the product. If you want to succeed, having smooth user experience is the key. When you signup to the service, if experience at first minute is not good, your potential customer is gone to the competitor. Same goes for every feature you have inside. Everything matters. Some more than other, but ultimately quality is the key.

If you are super small company, a startup, you might want to cut expenses and live on the edge for a while. That is understandable. In such case when you get on your feet, and you decide that flying in a non-tested brand new airplane is still good idea, it is your legitimate right. That airplane can have malfunction and crash any second now, however with lots of good luck it may be success. Question is, do you want to invest your time/money into a company that is basing its success on luck?

In software delivery cycle, quality assurance is very important process to quality development, it is ensuring that product attains certain levels of quality before it lands in the hands of the user. One thing we all need to accept, is that we are humans and we all make mistakes. That is normal. Some make more, some make less. Without QA, companies release their products with bugs, security gaps, and risk having their reputation and financial base collapsed.

QA is not only about finding bugs but more about proving the product is reliable, user-friendly, and meeting the expectations of its users. Those are the goals. If the company wants to attain high level of quality, entire company needs to be more educated in quality assurance. Mindset is the key. Being safe is always better then being fastest.

Would you rather buy nicest looking fast car with highest speed and newest tech but you know it is not tested for safety, or would you drive competitors car who released slightly later but it passed all the safety and quality tests?
I presume decision would be on the latter

If you run a IT company, and you don't have a QA, you should consider adding testing into your delivery process.

There are different types of testing, and depending on what QA resources you have, QA team covers an all-round check of the product as far as its functionality, happy-path covering, negative-path covering, edge-case covering, usability, frontend manual and automated testing, api manual and
automated testing, etc.

All of this will depend on the developers to find and fix all the problems without any QA. That will only slow down the development pace and remove resources from innovative work.
Also mindset of a developer and QA is very different oriented.
In my experience, QA can find 10 bug where dev can not see 1 bug looking at his code.

In conclusion, theoretically, an IT company might manage without the QA team, but practically, without it, the quality of products would be more likely compromised, and satisfaction of the customers on the long run, its in great danger. There is no overstating the importance of quality assurance in the software development life cycle because it is an indispensable part of the cycle.

Idempotency explained in restaurant analogy

Stipe — Sat, 03 Feb 2024 21:32:21 +0000

In a bustling city of New York, there was a renowned restaurant named "Giovanni". This restaurant was unique for it's traditional meals from south of Italy, and they served meals in the same concept of idempotency in API development.

In the sphere of APIs, idempotency means that regardless of how many times one makes identical request, the outcome remains unchanged after the first request is made. This principle is ingeniously applied in the old Giovanni's restaurant.

Enter our protagonist, a chef named Marco, culinary virtuoso. Marco's kitchen was the heart of idempotency magic. Each dish was like a unique response to the API request made by the customer. Made with love, taste and never duplicated.

One summer evening, a couple on their first date arrived at "Giovanni" restaurant. Arthur and Brenda.

Arthur ordered a nice stake, while Brenda ordered a dish called "Palermo delight". Order went to kitchen with unique identifier "table #6 - order 130". Arthur was a rascal and always ready for some misdeeds. He called waiter and ordered same meals again, hoping to see if they would end up with two dishes instead of one.

Back in the kitchen chef Marco received again identical order with same unique identifier "table #6 - order 130".

Marco immediately recognized the duplicate. He informed entire team in the kitchen that this is idempotent request and they should prepare only one stake and one Palermo delight. In any other restaurant this would resulted with duplicate order, but not in Giovanni's.

Rascal Arthur and Brenda were served with one order, corresponding to their first order.

Let's break down the process from order to serving of the meal.

1. MEAL ORDER = POST REQUEST

Arthur and Brenda's first order of stake and Palermo delight equals to a POST request to an API.
When POST request is made, it sends data to the server, ordering to cook meals.

2. ORDER NUMBER = UNIQUE IDENTIFIER

Once Arthur and Brenda told what they want to eat, waiter assigned a table number and order number to it. Order was taken to the kitchen. This unique identifier is crucial.
It ensures that even if same order is placed 20 times, it will be recognized as duplicate.

This means, when api request is made, we assign it a unique identifier, ensuring server recognizes it and prevents duplications, server overload and poor user experience.

3. KITCHEN PROCESSING ORDER = SERVER PROCESSING THE REQUEST

Kitchen took the order with unique identifier, and places it into schedule of cooking. Arthur thought he is clever, but chef Marco's idempotent system is without flaw.

You can look at this as user making same api request again and again, perhaps due to network issue or serial clicking mania :-)
All of these requests will be recognized to who they belong, they will then be ignored, and only first request will be executed.

User is unaware of checks that occur behind the scenes, and he is served with what he requested in the first place. And that is most important.

How do you look at idempotency? Share your view.