More On Designing TAF Layers

If you decide not to design some parts of TAF at the very beginning, you are guaranteed to have HUGE problems in the long run. Do not deceive yourself by thinking that the future is far away. Issues that stem from poor design can turn out to be nasty. It will not be just 'a bit expensive' to get rid of them. Failing to design TAF layers properly may render the whole system virtually unusable. I always invest a lot into the initial design, and I have never regretted it. It saved me time, effort and sanity.

Real Life Requirements For A Test Framework

The layers

The majority of test frameworks solve the same problem, so it is only natural that even on different projects you end up using the same architecture. The variable part is limited to:
-- tests (they depend on requirements);
-- support of the project-specific infrastructure (you may need to implement support for AWS when assigned to project A, and it will not be required on project B, because the stack is completely different).

Balancing team effort

Personally, I developed a habit of thinking of TAF architecture in terms of layers:
-- a layer of test;
-- a layer of helpers (mainly boilerplate, moved out of tests to avoid duplication);
-- core layer and configuration (start up and shutdown, envrironmnet, logging, working with API of third-pary systems, etc.)
This approach has a lot of advantages, because it allows to share workload across the team without stepping on each other toes.

Test Framework Is A Software Product

When you intend to write a test framework you need to remember the following:

- test framework is a software product, which means everything that applies to a commercial product, also applies to a test framework;

- test framework is not less important than the software under test, it is actually more important (and sometimes more complicated) than the software under test.

Test frameworks are created to help you check if you still meet the requirements (and to do it with less effort than manual test requires). Because if you do not meet the requirements, you do not achieve the project goals and|or create more problems than you solve. For instance, you spend enormous amount of time on manual defect management and dealing with architectural issues when it is too late and too expensive.

So if you decide to create a test framework, you have to:
-- define the requirements;
-- define priorities for the requirements;
-- define stages of maturity (what is to be implemented first and what next);
-- find out how much resource you have (time, technical knowledge, congitive ability, ability to delegate);
-- build the schedule of implementation (preferably by using a Gantt diagram).

Otherwise, I am sorry to say, your test framework will be nothing but a cost.

-------------------------------

Related posts:
Real Life Requirements For A Test Framework
More On Designing TAF Layers

TCP/IP vs Real Life

I was busy talking to my imaginary friends and then it came to me how to explain TCP/IP to the non-technical people. It is important because most of my imaginary friends are non-technical. So, here is how you can do it. 

First, forget the OSI, no one needs it anyway. Think of TCP/IP as your clothes. 

Application layer is your coat, your suit, your jumper, your shoes, your hat.

Transport layer is your shirt, your dress, your pants (meaning trousers), your stockings.

Internet is your underclothes, your lingerie, your thermals.

Link is the naked you.

Protocol stacks follow the same logic. For instance, when you have a date you wear your suit and you put your shoes on, right? Then all this gradually comes off. Then the connection happens. Then you put everything on in the reverse order. You don't put your underwear over your jeans, do you? 

See, technology can be easy to understand.

Firefox Conspiracy Theory

I am a little paranoid which is an unfortunate side-effect of my profession. And due to this side-effect I always keep my third-party cookies switched off. I also use Firefox most of the time, unless it is required to do otherwise. I have been using it since version 0.75 and it is a bit like till death do us part. And this is how I ran into a very funny problem about a year ago: Google began to ask for third party cookies in order to allow you to download the content.

My guess is Google decided to switch from client-side trackers to server-side trackers sometime during summer 2021. They have already been tracking users by means of a fingerprint, and a fingerprint was (and is) built around user's device data, such as network data, payment data like cards (a card number carries information about the bank it was issued by), unique configuration of your device, user activity patterns, etc, etc. Well, they do own about 3/4 of the mobile market, don't they? And they do that without giving the end user the root access to the system.

Why I Don't Regret Starting This Stupid Blog

From time to time I ask myself is it really worth it? The blog. Who reads it? Well, today I got the ultimate answer: I DO. My post from almost three years ago has just saved my OS, my data and my sanity. So, keep writing your blogs, and NEVER EVER switch your BIOS to defaults if you notebook was made to be Windows-friendly. Windows will never be a friend to a Linux user.

The post in question: https://tatjandr.blogspot.com/2020/03/fix-invisible-drive-for-linux-installer.html 

PS: Even my failing touchpad, who started all this, seemed to behave better for a minute