This is probably a great time for me to re-RTFM, but I'll post it out for discussion anyway. What is the intended process model for TestLink?
I don't mean the specific flow as laid out in the earlier thread and manual, I am asking what methodology it is modelled toward. I've seen mention of the IEEE test standard and still other users have posted questions which seemed more Agile process oriented.
Users:
What process models do you use TL with?
Which would you like to?
Devs:
Would a request for a 'select workflow by methodology' option be unreasonable, even as a very long term project?
One of the things I like about the current 'process problems' in TL is that they mean TL does not trap you into the problems inherent with any of them. This makes it extremely flexible as a tool rather than a dictation of process. Is the overall goal to offer more rigid adherance to standard approaches, or even one particular approach?
General Methodology
Moderators: Amaradana, TurboPT, TL Developers
I hope not!
Every company I've worked for has had its own process for development and testing. In the current state of software "engineering" there's no "standard" development process. Lives are not at stake as they are in bridgebuilding, but wallets are, so each software "engineering" organization develops its own processes[1] to meet the needs of the market-driven schedule. Making a test database fit one specific methodology is easier, but it limits the size of the audience. The people using that methodology will like it, but it will feel like binders and straitjackets to everyone else.
And then the standards organization in charge of the process will change it and charge you money for the manual that describes the new version[2] and all your tools are obsolete.
Make the tool more flexible. Make it possible for the developers using certain "standard" processes to use the tool, and encourage the nonstandard groups use it too. (If you can get the wildest bunch to use a test tracking tool without hurting them a lot, then maybe they'll eventually understand why it's a good thing to do.)
[1] yes, I wrote that intentionally
[2] CMU SEI CMM, for instance
Every company I've worked for has had its own process for development and testing. In the current state of software "engineering" there's no "standard" development process. Lives are not at stake as they are in bridgebuilding, but wallets are, so each software "engineering" organization develops its own processes[1] to meet the needs of the market-driven schedule. Making a test database fit one specific methodology is easier, but it limits the size of the audience. The people using that methodology will like it, but it will feel like binders and straitjackets to everyone else.
And then the standards organization in charge of the process will change it and charge you money for the manual that describes the new version[2] and all your tools are obsolete.
Make the tool more flexible. Make it possible for the developers using certain "standard" processes to use the tool, and encourage the nonstandard groups use it too. (If you can get the wildest bunch to use a test tracking tool without hurting them a lot, then maybe they'll eventually understand why it's a good thing to do.)
[1] yes, I wrote that intentionally
[2] CMU SEI CMM, for instance
I can say just what is my personal view on the process maintenance by testlink. So this is not a view of all developers.
The goal is to have simple tool, that could be enhanced via configuration. This is difficult goal, because each piece of code must complain all possible configuration. This slow down development. However, we will not tied your processes with TL logic. That's master benefit.
I'm asking developers to make each new feature as optional. It doesn't work everytime.
I'm using the tool in company using process based on waterfall model. I need to implement review process to fit this more. meantime I do review externally.
But I believe that TestLink is usable also for agile process. Of course agian there are holes that could satisfied this type of development.
The goal is to have simple tool, that could be enhanced via configuration. This is difficult goal, because each piece of code must complain all possible configuration. This slow down development. However, we will not tied your processes with TL logic. That's master benefit.
I'm asking developers to make each new feature as optional. It doesn't work everytime.
I'm using the tool in company using process based on waterfall model. I need to implement review process to fit this more. meantime I do review externally.
But I believe that TestLink is usable also for agile process. Of course agian there are holes that could satisfied this type of development.
I am using Testlink for a couple of weeks in our company and it is obvious that a more process-oriented approach may be a plus for professional use.
I also agree, that such a process has to be an optional element and highly configurable to fit company requirements. Even if no standard development process exists, Testlink may include a "Best Practice Model" so that test-newies may have an orientation.
I also agree, that such a process has to be an optional element and highly configurable to fit company requirements. Even if no standard development process exists, Testlink may include a "Best Practice Model" so that test-newies may have an orientation.
I don't completely agree with that policy. Mainly because I think that you should have a firm approved basis for your testing tool. If you use IEEE, TMAP or ISTQB for this, does not really matter.
But to create a tool without a basis is like handing over an Excel sheet which you can configure yourself (not the best comparison by the way, but the point is made
).
Furthermore I think that testing still is not seen as a profession on its own. It should NOT (!!!) be done by developers, designers or the customer...it should be done by Test professionals. I guess that in America a test engineer is more common, but to me this sounds like a developer that does some testing
concerning the methodology; all companies should use a approved and widely used one (like IEE, TMAP or ISTQB) and not invent one themselves....that's like inventing your own programming code while there is already enough that can be used.....
But to create a tool without a basis is like handing over an Excel sheet which you can configure yourself (not the best comparison by the way, but the point is made
).Furthermore I think that testing still is not seen as a profession on its own. It should NOT (!!!) be done by developers, designers or the customer...it should be done by Test professionals. I guess that in America a test engineer is more common, but to me this sounds like a developer that does some testing
concerning the methodology; all companies should use a approved and widely used one (like IEE, TMAP or ISTQB) and not invent one themselves....that's like inventing your own programming code while there is already enough that can be used.....
I don't want to destroy your dream about America (I suppse USA) to be the only place where test engineers do the testing, but most of the european IT companies listed at the Commercial Registry have test engineers.
At my current company, IEEE standard is used for testing and we have another main tool. As I am evaluating TestLink to replace that tool, I simply wanted to implement our workflow in TestLink. So:
What is wrong about implementing e.g. IEEE to TestLink logic?
At my current company, IEEE standard is used for testing and we have another main tool. As I am evaluating TestLink to replace that tool, I simply wanted to implement our workflow in TestLink. So:
What is wrong about implementing e.g. IEEE to TestLink logic?
Like I said, in America, it's more common 
This does not mean that the test engeneer is not used in Europe....
But anyhow, there is nothing wrong with implementing a certain testlink logic (like IEEE), but the basis of a tool should be some sort of methodology, not a free way of creating your own flow....
This does not mean that the test engeneer is not used in Europe....But anyhow, there is nothing wrong with implementing a certain testlink logic (like IEEE), but the basis of a tool should be some sort of methodology, not a free way of creating your own flow....
I have had open internal issue to make TL compliant with these standards. Some point are on trace (for example design review process). You guys should suggest which functions you miss here to satisfy it.
I'm waiting for you suggestions.
BTW: I have experience with Europian and US testing culture. I must say that I'm US teams often cannot do good testing because of business principle. I'm far to say that US testers are worse. Personally I should not do tester in US, but I'm happy to do it in Europa.
I'm waiting for you suggestions.
BTW: I have experience with Europian and US testing culture. I must say that I'm US teams often cannot do good testing because of business principle. I'm far to say that US testers are worse. Personally I should not do tester in US, but I'm happy to do it in Europa.
I would support the idea that testlink should stay process agnostic.
I do work a lot in process definition and having a test tool trying to dictate its own view of process is highly disruptive. Process needs to be looked at from the total SDLC perspective.
The opposite, defining a process intelligently, means that any process agnostic test tool can be used quite effectively.
Stephan
I do work a lot in process definition and having a test tool trying to dictate its own view of process is highly disruptive. Process needs to be looked at from the total SDLC perspective.
The opposite, defining a process intelligently, means that any process agnostic test tool can be used quite effectively.
Stephan
I agree with smeyn.
We have quickly accepted testlink since it nearly fits our needs for a tests database. The main of them is test definition and results storage.
I like the fact that Test Cases can be linked to a Requirements, but it is not a must.
Test Cases are described and not 'software implemented'. Now it is great that it can be linked through the API to the automated tests implementations., but it is not a must.
So, I like the idea of Testlink doing easilly as it does the test cases/suites definition and empowering connectivity to other tasks and resources. It's up to the test engineeers using and configuring connections to meet the workflow of their company.
Antonio.
We have quickly accepted testlink since it nearly fits our needs for a tests database. The main of them is test definition and results storage.
I like the fact that Test Cases can be linked to a Requirements, but it is not a must.
Test Cases are described and not 'software implemented'. Now it is great that it can be linked through the API to the automated tests implementations., but it is not a must.
So, I like the idea of Testlink doing easilly as it does the test cases/suites definition and empowering connectivity to other tasks and resources. It's up to the test engineeers using and configuring connections to meet the workflow of their company.
Antonio.