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

Some ideas to help you explain to your project manager why things just do not happen by themselves

You can't always get what you want


Result is not something guaranteed, not something you can count on, no matter what. Result is something you can get, if you are lucky and all the conditions are in your favor, and you can focus, and you are prepared to invest some extra effort, if you, despite all the desperate measures, run out of your resource.

I observed that planning is often done without even attempting to check if the goal or its parts are really feasible. The industry seems to be forming this habit of not questioning the task unless problems are too obvious. They pay you for doing something. And that means there's no way back, because some other people have already committed to do it, so now you have to provide a solution to support their commitment.

This way of doing things is not very helpful when it comes to planning, especially if area is not sufficiently familiar.

Flow for Managers

There's no such a thing as a universal way to do your job and not let it kill you.

To achieve the best results some professions need to work in a flow, and some -- in a quick succession of tense-release phases. And, among other things, 'the result' is assessed by how much better your life has become (or maybe it took a turn for the worse).

It looks like Pomodoro-like techniques are best for managers who are forced to operate in a quickly changing environment, while flow is necessary for engineers and researchers.

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):