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

ISTQB is a bad bad thing

ISTQB is a bad, bad thing. Reeeeeally bad thing. And here is why.

First of all, they certify something there are more than one opinion about. Something that has different approaches. Something that is poorly measurable since it depends on efficiency of decision making process. And decades of IQ testing and similar attempts to measure and control human brain and psyche proved it spectacularly inefficient.

Whatever you can read in ISTQB material is just an opinion and a book would suffice to share it. Unfortunately, royalties that only one or even several books can bring is nothing compared with certification system would bring. Basically, you bypass market competition by forcing people into buying books and paying for exams, and you do it by pressuring their employers into pressuring their employees.

Test Plan structure proven by several projects

Some time ago I wrote about the importance of using standards as a time saver. Since then I had a chance to apply this approach to several projects where I participated as a test expert.

So, below you can find a structure that helps to collect in one place all info you need to know about the state of test in a project. (I usually build a test plan as a single entry point for all the questions related to test by means of Atlassian Confluence, but I guess any other knowledge sharing system will do).

Also, I can guarantee that if you are able (have enough info, that is) to fill all the sections of my version of a test plan, then you do have your test process under control. So it can function as a checklist and and answer to a question where to start.

My version of a test plan consists of eight sections with subsections. Subsections may vary for each particular project, but I recommend sticking with the top-level ones.

IMPORTANT: Don't duplicate info, don't add info just to fill in sections, it is important that test plan is not just a formal piece of paper.

Total automation with sellotape and glue

Luckily for all of us every profession evolves, and test automation is no exception. What I can see is test automation is now more affordable, and is done in a more professional way than before.

Same goes for approaches and tools (and for those who still trust Internet more than their own judgement, some gurus have already posted a very good knock out article leaving losers like myself with a tingling feeling of guilt for being too slow to update the blog).

But there's still another subject I would like to speak about. It concerns the approach to automation in general. Actually, it intends to slightly shift the way we understand automation and targets some of the popular stereotypes in attempt to get rid of them.

The major three - Building a test plan with professional standards

Apparently you can't be president with a whole brain. 
Zaphod Beeblebrox

Sometimes your employer is a company with a well-documented process. Sometimes this is not the case. And if you are reading this, you are probably facing one or both of these problems (or have had a similar experience ealier) :

1. Your manager doesn't understand what process is and what it is for.

2. There is no project documentation available that you can re-use to setup or streamline your test share of whatever you are participating in.

As it is out of scope for this article to fix the whole world, and as it is unlikely that you'll be able to quickly change your manager's point of view (things like that are normally connected with person's life values and are extremely hard to adjust), I suggest we concentrate on #2 as a more realistic option. 

Standards

In brief, the answer is IEEE 829. And you do not have to spend your salary to get access, as Internet contains enough information for you to start with. Also you do not have to follow every single word there, but rather use it as a guideline or a checklist.

The major three - Health assessment for a test project

Let me start with some trivia. No project is the same. No project is dull. Every project is what you make of it. The interesting part is what you should do if you wanna make it.

Personally, I hate doctors. But in situations like this I have to act like one, which means, I start with collecting a medical history. And here are some hints regarding what to look for (as they say, including, but not limited to):

The major three to start a test project

Sometimes you just have to start a test project from a scratch. And it often feels and looks like having to pull a rabbit out of a hat. Or having to learn Chinese overnight. The normal state of mind for everyone, who is not that experienced in such matters, or who is used for managing health projects, is a stupor.

This is why I decided to publish these three posts I wrote for my future self in case I, like all normal people, get temporary amnesia:

    1. Do project health assessment.
    2. Build a test plan based on standards
    3. To make it three (as they say three is easier to remember) -- smile =)


Good luck!