General Methodology

Discuss test processes, standards, documentation, teams, criteria, test environments, etc.

Moderators: Amaradana, TurboPT, TL Developers

General Methodology

Postby Nogem » Mon Feb 18, 2008 10:08 pm

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?
Nogem
Advanced user
 
Posts: 21
Joined: Tue Nov 13, 2007 10:53 pm

Postby mroeder » Sat Mar 15, 2008 1:00 am

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
mroeder
TestLink user
 
Posts: 6
Joined: Sat Feb 02, 2008 12:26 am

Postby havlatm » Tue Mar 18, 2008 1:59 pm

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.
havlatm
Member of TestLink Community
 
Posts: 940
Joined: Mon Oct 31, 2005 1:24 am
Location: Czech

Postby Choff » Thu Aug 21, 2008 12:57 pm

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.
Choff
TestLink user
 
Posts: 3
Joined: Thu Aug 21, 2008 12:50 pm

Postby fman » Thu Aug 21, 2008 5:10 pm

Ok.
We need some help.
do you want to write this document?

regards

francisco
fman
Member of TestLink Community
 
Posts: 3068
Joined: Tue Nov 15, 2005 7:19 am

Postby Choff » Fri Aug 22, 2008 7:03 am

After my vacations in september I will start to work on a generic test workflow.
What will be the further steps regarding implementation?

regards,
Claudio

fman wrote:Ok.
We need some help.
do you want to write this document?

regards

francisco
Choff
TestLink user
 
Posts: 3
Joined: Thu Aug 21, 2008 12:50 pm

Postby baamster » Tue Sep 02, 2008 11:03 am

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.....
baamster
Advanced user
 
Posts: 27
Joined: Thu May 24, 2007 7:46 am

Postby Choff » Tue Sep 02, 2008 11:48 am

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?
Choff
TestLink user
 
Posts: 3
Joined: Thu Aug 21, 2008 12:50 pm

Postby baamster » Tue Sep 02, 2008 1:55 pm

Like I said, in America, it's more common :D 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.... :wink:
baamster
Advanced user
 
Posts: 27
Joined: Thu May 24, 2007 7:46 am

Postby havlatm » Thu Sep 04, 2008 2:29 pm

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.
havlatm
Member of TestLink Community
 
Posts: 940
Joined: Mon Oct 31, 2005 1:24 am
Location: Czech

Postby smeyn » Thu Mar 12, 2009 1:41 am

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
smeyn
Advanced user
 
Posts: 22
Joined: Tue Mar 03, 2009 7:50 am

Postby tstr » Thu Mar 12, 2009 10:05 am

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.
tstr
TestLink user
 
Posts: 9
Joined: Fri Mar 06, 2009 11:58 am


Return to General Testing and Test management



Who is online

Users browsing this forum: No registered users and 3 guests