testmaster-devel Mailing List for Testmaster
Brought to you by:
alandpearson
Menu
▾
▴
testmaster-devel — Issues related to testmaster development
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
(23) |
Mar
(9) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2007 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Fan W. \(fanwan\) <fa...@ci...> - 2007-01-14 03:40:19
|
Hello,
I am looking for a test management system to track testcase
execution, result reporting, etc.
And I found test master is just what I want.=20
However, I found the latest information of it is long time
ago. so I am wondering if test master project is still carrying out ?
=20
Regards
-- Fan Wang
=20
|
|
From: Chad U. <ch...@mk...> - 2005-03-15 05:51:59
|
Hey Alan Give this a try. It's the tool I'm using: http://www.dbwrench.com/ Chad Alan Pearson wrote: > Chad > I'm not getting far with kompany data architect. > I'm gonna give it a swing on Linux upstairs then give up :-( > Damn ODBC. |
|
From: Alan P. <ala...@ya...> - 2005-03-14 22:50:42
|
Chad I'm not getting far with kompany data architect. I'm gonna give it a swing on Linux upstairs then give up :-( Damn ODBC. -- AlanP On 14 Mar 2005, at 17:36, ch...@mk... wrote: > Greetings > > I kind of dropped of the map for a while there but I'm back now (sort > of). > I still have a ton of other work to do, so my contributions to > Testmaster > will probably be limited and sporadic. > > I have a bunch of bugs in our current Testmaster implementation that I > need to fix urgently, so as I ge them done locally I will try and add > them > in to CVS. I'm also going to try and get that DB schema diagramed out > by > the end of the week. > > Ciao, > Chad > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real > users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Testmaster-devel mailing list > Tes...@li... > https://lists.sourceforge.net/lists/listinfo/testmaster-devel |
|
From: Alan P. <ala...@ya...> - 2005-03-14 19:08:13
|
No problem Chad. I was out of it for the past few weeks to as I only just got my laptop back friday. Developing in a cold room upstairs ain't pleasant. I plan to have the initial schema bottomed out tonight, just waiting for your comments / corrections. Someone showed me a good ER tool by the kompany (costs money but I may splodge out) http://www.thekompany.com/products/dataarchitect/ I'm gonna download an eval and play around. -- AlanP On 14 Mar 2005, at 17:36, ch...@mk... wrote: > Greetings > > I kind of dropped of the map for a while there but I'm back now (sort > of). > I still have a ton of other work to do, so my contributions to > Testmaster > will probably be limited and sporadic. > > I have a bunch of bugs in our current Testmaster implementation that I > need to fix urgently, so as I ge them done locally I will try and add > them > in to CVS. I'm also going to try and get that DB schema diagramed out > by > the end of the week. > > Ciao, > Chad > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real > users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Testmaster-devel mailing list > Tes...@li... > https://lists.sourceforge.net/lists/listinfo/testmaster-devel |
|
From: <ch...@mk...> - 2005-03-14 17:36:25
|
Greetings I kind of dropped of the map for a while there but I'm back now (sort of). I still have a ton of other work to do, so my contributions to Testmaster will probably be limited and sporadic. I have a bunch of bugs in our current Testmaster implementation that I need to fix urgently, so as I ge them done locally I will try and add them in to CVS. I'm also going to try and get that DB schema diagramed out by the end of the week. Ciao, Chad |
|
From: Alan P. <ala...@ya...> - 2005-03-03 22:36:14
|
Chad As said before, no pressure, no timescales !! Al On Thursday 03 March 2005 00:52, ch...@mk... wrote: > Hi Guys > > I know I've promised to get an ER diagram up for the schema, but htings > have gotten crazy busy at work. I'll try and carve out some time for > this, but I'm not going to promise when. > > Chad > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Testmaster-devel mailing list > Tes...@li... > https://lists.sourceforge.net/lists/listinfo/testmaster-devel -- AlanP |
|
From: <ch...@mk...> - 2005-03-03 00:55:23
|
Hi Guys I know I've promised to get an ER diagram up for the schema, but htings have gotten crazy busy at work. I'll try and carve out some time for this, but I'm not going to promise when. Chad |
|
From: <ch...@mk...> - 2005-03-01 17:31:18
|
Alan First off, I meant to put a lot more of my thoughts on the wiki last night but faded completely, so I apologise. Well, I think it's perfectly alright to say "Sorry, 1.2 will be out a little later then originally thought, we took the time to really evaluate things and there's more work to be done then was first thought". In the end, we're delivering a better tool. I'm going to try and find some time today to draw up a first-pass ER diagram for the schema based on what you and I have said. It'll definately not be perfect, but will give us a good place to start our discussions. Chad > Chad > Agree with below and what was said on wiki. > One thing though, if we start from scratch with the db_schema, this > will mean an almost rewrite of testmaster (it'll not be just a matter > of tweaking column names), but perhaps this is what is necessary > anyhow. > > Al > On 1 Mar 2005, at 06:11, Chad Ullman wrote: > >> Hi >> >> Sorry for the delay in responding, but work was sort of cray today. >> Anyway, here goes: >> >> I totally agree that it's worth the effort to get the DB knocked in to >> shape. And I'm neutral to doing it now or for 2.0. So let's go ahead >> and do it now. >> >> However, I'd like to take a more structured approach to the DB design. >> Basically, let's pretend we have nothing, and think through exactly >> what we want in the DB, figure out the entities and their >> relationships and then translate that in to actual DDL. >> >> I think my take on this is going to get really long, so instead of >> putting it in this email, go to >> http://mkulu.org/scgi-bin/tmwiki.cgi/DbSchema and I'll document my >> thoughts there. >> >> Chad >> >> Alan Pearson wrote: >> >>> Guys >>> >>> I've been modifying the 1.2 Schema, and what started out as a gentle >>> feathering turned into a massacre (sp?) ! I know this is going to >>> cause at least 2 weeks of pain getting 1.2 to match the new schema. >>> >>> Before I go into _what_ I'd like to change, the reason why I think we >>> should have the pain _now_ as opposed to later (1.3? 2.0 ) is : >>> >>> I think we agree that the structure of testmaster (i.e. not the db, >>> but testcases, trees, departments, project etc etc) is pretty much >>> what we want. Sure other features will be added, but the underlying >>> concepts are good ( I think ). So with that in mind, lets get the db >>> structure to match the concept in a _good_ way now. Waiting till >>> later will cause more pain, as new features will have been added, and >>> the need to create porting tools for yet another release. >>> >>> I originally started out with the idea of a 1.2 release that added >>> features (90% of which Chad has done) but then was persuaded by >>> someone that if I didn't take the time to get the schema damn near >>> perfect now, then I'd pay the price in the future. I know the schema >>> will always change, but at least if we start with a good underbelly, >>> then the pain won't be so great. (Adding new tables is easy, changing >>> column names & changing structure is a world of pain). >>> >>> Anyhow here's what I think is wrong with the old schema >>> >>> * Inconsistent column naming convention >>> * Everything should have a unique id (and be referenced ONLY by the >>> id by the app) * Created by pg_dump which changes between releases >>> * Some stuff is PG dependent >>> >>> >>> Chad, I saw that you had triggers for updating tm_tc_update_history >>> and tm_tc_execution history. I think that is the correct place to >>> have this functionality (down and dirty at db level, not by app). >>> I'm wondering how to do this across different engines (ie pg, oracle >>> etc) without having to maintain a load of different db specific code >>> (ie plsql, pgpl etc etc). >>> It is nice to move this work to the db. Any ideas ?? >>> >>> >>> OK, on to the changes. I suggest you diff against the first revision >>> of testmaster-schema-1.2.sql to see what has changed but here's an >>> overview >>> >>> *) id column in most tables renamed to something table specific (i.e. >>> dept_id, user_id) >>> *) Other columns renamed to table specific convention >>> *) Removal of all pgpl stuff and db functions >>> *) Constraints added in original create table statements not alter >>> statements (maybe bad idea, but makes schema easier to understand by >>> examining file) >>> *) tm_attachments table added >>> *) online column changed to xxx_state >>> Existing stuff to discuss >>> >>> *) Purpose of automated column ? >>> Is this needed ? Original idea was lots of testscripts in various >>> languages would access testmaster via tmSOAP and update whatever >>> testcase script was executing. I don't see any value in have the name >>> of script or automated flag in tm_testcases ? Enlightenment >>> appreciated ! >>> *) tm_ts_tree >>> As Chad has said this needs expanding out >>> >>> >>> >>> As I said, I know this will cause a world of pain. Question is less >>> pain now, or more pain later. >>> >>> Thoughts ? >>> >>> >> >> >> >> ------------------------------------------------------- >> SF email is sponsored by - The IT Product Guide >> Read honest & candid reviews on hundreds of IT Products from real >> users. >> Discover which products truly live up to the hype. Start reading now. >> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click >> _______________________________________________ >> Testmaster-devel mailing list >> Tes...@li... >> https://lists.sourceforge.net/lists/listinfo/testmaster-devel > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Testmaster-devel mailing list > Tes...@li... > https://lists.sourceforge.net/lists/listinfo/testmaster-devel > |
|
From: Alan P. <ala...@ya...> - 2005-03-01 09:25:05
|
Chad Agree with below and what was said on wiki. One thing though, if we start from scratch with the db_schema, this will mean an almost rewrite of testmaster (it'll not be just a matter of tweaking column names), but perhaps this is what is necessary anyhow. Al On 1 Mar 2005, at 06:11, Chad Ullman wrote: > Hi > > Sorry for the delay in responding, but work was sort of cray today. > Anyway, here goes: > > I totally agree that it's worth the effort to get the DB knocked in to > shape. And I'm neutral to doing it now or for 2.0. So let's go ahead > and do it now. > > However, I'd like to take a more structured approach to the DB design. > Basically, let's pretend we have nothing, and think through exactly > what we want in the DB, figure out the entities and their > relationships and then translate that in to actual DDL. > > I think my take on this is going to get really long, so instead of > putting it in this email, go to > http://mkulu.org/scgi-bin/tmwiki.cgi/DbSchema and I'll document my > thoughts there. > > Chad > > Alan Pearson wrote: > >> Guys >> >> I've been modifying the 1.2 Schema, and what started out as a gentle >> feathering turned into a massacre (sp?) ! I know this is going to >> cause at least 2 weeks of pain getting 1.2 to match the new schema. >> >> Before I go into _what_ I'd like to change, the reason why I think we >> should have the pain _now_ as opposed to later (1.3? 2.0 ) is : >> >> I think we agree that the structure of testmaster (i.e. not the db, >> but testcases, trees, departments, project etc etc) is pretty much >> what we want. Sure other features will be added, but the underlying >> concepts are good ( I think ). So with that in mind, lets get the db >> structure to match the concept in a _good_ way now. Waiting till >> later will cause more pain, as new features will have been added, and >> the need to create porting tools for yet another release. >> >> I originally started out with the idea of a 1.2 release that added >> features (90% of which Chad has done) but then was persuaded by >> someone that if I didn't take the time to get the schema damn near >> perfect now, then I'd pay the price in the future. I know the schema >> will always change, but at least if we start with a good underbelly, >> then the pain won't be so great. (Adding new tables is easy, changing >> column names & changing structure is a world of pain). >> >> Anyhow here's what I think is wrong with the old schema >> >> * Inconsistent column naming convention >> * Everything should have a unique id (and be referenced ONLY by the >> id by the app) * Created by pg_dump which changes between releases >> * Some stuff is PG dependent >> >> >> Chad, I saw that you had triggers for updating tm_tc_update_history >> and tm_tc_execution history. I think that is the correct place to >> have this functionality (down and dirty at db level, not by app). >> I'm wondering how to do this across different engines (ie pg, oracle >> etc) without having to maintain a load of different db specific code >> (ie plsql, pgpl etc etc). >> It is nice to move this work to the db. Any ideas ?? >> >> >> OK, on to the changes. I suggest you diff against the first revision >> of testmaster-schema-1.2.sql to see what has changed but here's an >> overview >> >> *) id column in most tables renamed to something table specific (i.e. >> dept_id, user_id) >> *) Other columns renamed to table specific convention >> *) Removal of all pgpl stuff and db functions >> *) Constraints added in original create table statements not alter >> statements (maybe bad idea, but makes schema easier to understand by >> examining file) >> *) tm_attachments table added >> *) online column changed to xxx_state >> Existing stuff to discuss >> >> *) Purpose of automated column ? >> Is this needed ? Original idea was lots of testscripts in various >> languages would access testmaster via tmSOAP and update whatever >> testcase script was executing. I don't see any value in have the name >> of script or automated flag in tm_testcases ? Enlightenment >> appreciated ! >> *) tm_ts_tree >> As Chad has said this needs expanding out >> >> >> >> As I said, I know this will cause a world of pain. Question is less >> pain now, or more pain later. >> >> Thoughts ? >> >> > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real > users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Testmaster-devel mailing list > Tes...@li... > https://lists.sourceforge.net/lists/listinfo/testmaster-devel |
|
From: Chad U. <ch...@mk...> - 2005-03-01 06:12:02
|
Hi Sorry for the delay in responding, but work was sort of cray today. Anyway, here goes: I totally agree that it's worth the effort to get the DB knocked in to shape. And I'm neutral to doing it now or for 2.0. So let's go ahead and do it now. However, I'd like to take a more structured approach to the DB design. Basically, let's pretend we have nothing, and think through exactly what we want in the DB, figure out the entities and their relationships and then translate that in to actual DDL. I think my take on this is going to get really long, so instead of putting it in this email, go to http://mkulu.org/scgi-bin/tmwiki.cgi/DbSchema and I'll document my thoughts there. Chad Alan Pearson wrote: >Guys > >I've been modifying the 1.2 Schema, and what started out as a gentle >feathering turned into a massacre (sp?) ! I know this is going to cause at >least 2 weeks of pain getting 1.2 to match the new schema. > >Before I go into _what_ I'd like to change, the reason why I think we should >have the pain _now_ as opposed to later (1.3? 2.0 ) is : > >I think we agree that the structure of testmaster (i.e. not the db, but >testcases, trees, departments, project etc etc) is pretty much what we want. >Sure other features will be added, but the underlying concepts are good ( I >think ). So with that in mind, lets get the db structure to match the concept >in a _good_ way now. Waiting till later will cause more pain, as new features >will have been added, and the need to create porting tools for yet another >release. > >I originally started out with the idea of a 1.2 release that added features >(90% of which Chad has done) but then was persuaded by someone that if I >didn't take the time to get the schema damn near perfect now, then I'd pay >the price in the future. I know the schema will always change, but at least >if we start with a good underbelly, then the pain won't be so great. (Adding >new tables is easy, changing column names & changing structure is a world of >pain). > >Anyhow here's what I think is wrong with the old schema > >* Inconsistent column naming convention >* Everything should have a unique id (and be referenced ONLY by the id by the >app) >* Created by pg_dump which changes between releases >* Some stuff is PG dependent > > >Chad, I saw that you had triggers for updating tm_tc_update_history and >tm_tc_execution history. I think that is the correct place to have this >functionality (down and dirty at db level, not by app). I'm wondering how to >do this across different engines (ie pg, oracle etc) without having to >maintain a load of different db specific code (ie plsql, pgpl etc etc). >It is nice to move this work to the db. Any ideas ?? > > >OK, on to the changes. I suggest you diff against the first revision of >testmaster-schema-1.2.sql to see what has changed but here's an overview > >*) id column in most tables renamed to something table specific (i.e. dept_id, >user_id) >*) Other columns renamed to table specific convention >*) Removal of all pgpl stuff and db functions >*) Constraints added in original create table statements not alter statements >(maybe bad idea, but makes schema easier to understand by examining file) >*) tm_attachments table added >*) online column changed to xxx_state > >Existing stuff to discuss > >*) Purpose of automated column ? > Is this needed ? Original idea was lots of testscripts in various languages >would access testmaster via tmSOAP and update whatever testcase script was >executing. I don't see any value in have the name of script or automated flag >in tm_testcases ? Enlightenment appreciated ! >*) tm_ts_tree > As Chad has said this needs expanding out > > > >As I said, I know this will cause a world of pain. Question is less pain now, >or more pain later. > >Thoughts ? > > > |
|
From: Alan P. <ala...@ya...> - 2005-02-27 23:42:59
|
On Sunday 27 February 2005 23:26, Alan Pearson wrote: > Guys > > I've been modifying the 1.2 Schema, and what started out as a gentle > feathering turned into a massacre (sp?) ! I know this is going to cause at > least 2 weeks of pain getting 1.2 to match the new schema. [SNIP] This is by no means complete and needs a lot more work when I'm more awake. I think I've missed off a lot of constraints which I'll have to go over with a fine tooth comb. Call this a taster. It tastes foul I know, especially for Abdullah who want tm 1.2 by Tuesday ;-) -- AlanP |
|
From: Alan P. <ala...@ya...> - 2005-02-27 23:25:40
|
Guys I've been modifying the 1.2 Schema, and what started out as a gentle feathering turned into a massacre (sp?) ! I know this is going to cause at least 2 weeks of pain getting 1.2 to match the new schema. Before I go into _what_ I'd like to change, the reason why I think we should have the pain _now_ as opposed to later (1.3? 2.0 ) is : I think we agree that the structure of testmaster (i.e. not the db, but testcases, trees, departments, project etc etc) is pretty much what we want. Sure other features will be added, but the underlying concepts are good ( I think ). So with that in mind, lets get the db structure to match the concept in a _good_ way now. Waiting till later will cause more pain, as new features will have been added, and the need to create porting tools for yet another release. I originally started out with the idea of a 1.2 release that added features (90% of which Chad has done) but then was persuaded by someone that if I didn't take the time to get the schema damn near perfect now, then I'd pay the price in the future. I know the schema will always change, but at least if we start with a good underbelly, then the pain won't be so great. (Adding new tables is easy, changing column names & changing structure is a world of pain). Anyhow here's what I think is wrong with the old schema * Inconsistent column naming convention * Everything should have a unique id (and be referenced ONLY by the id by the app) * Created by pg_dump which changes between releases * Some stuff is PG dependent Chad, I saw that you had triggers for updating tm_tc_update_history and tm_tc_execution history. I think that is the correct place to have this functionality (down and dirty at db level, not by app). I'm wondering how to do this across different engines (ie pg, oracle etc) without having to maintain a load of different db specific code (ie plsql, pgpl etc etc). It is nice to move this work to the db. Any ideas ?? OK, on to the changes. I suggest you diff against the first revision of testmaster-schema-1.2.sql to see what has changed but here's an overview *) id column in most tables renamed to something table specific (i.e. dept_id, user_id) *) Other columns renamed to table specific convention *) Removal of all pgpl stuff and db functions *) Constraints added in original create table statements not alter statements (maybe bad idea, but makes schema easier to understand by examining file) *) tm_attachments table added *) online column changed to xxx_state Existing stuff to discuss *) Purpose of automated column ? Is this needed ? Original idea was lots of testscripts in various languages would access testmaster via tmSOAP and update whatever testcase script was executing. I don't see any value in have the name of script or automated flag in tm_testcases ? Enlightenment appreciated ! *) tm_ts_tree As Chad has said this needs expanding out As I said, I know this will cause a world of pain. Question is less pain now, or more pain later. Thoughts ? -- AlanP |
|
From: Alan P. <ala...@ya...> - 2005-02-25 21:25:56
|
Cool with me ! Did you move the tag to 1.1Beta3 ? Al On Friday 25 February 2005 17:44, ch...@mk... wrote: > OK, looks like there was already a tag made at some point called > release_1_1. So lets say we'll adopt this convention moving forward. > > Chad > > > Unfortunately, once a branch has been named, you're stuck with that name. > > What I can do however is add a tag to the branch that follows that > > convention, so if you check out on that tag I think you'll get the right > > branch. Let me try it and see. > > > > Chad > > > >> Thanks Chad > >> > >> Any chance of renaming the branch to the convention suggested in : > >> > >> http://www.magic-cauldron.com/cm/cvs-bestpractices/index.html > >> > >> (linked from the great cvs link you sent) > >> > >> release_{major version #}_{minor version #} > >> > >> > >> Cheers matey > >> > >> On 25 Feb 2005, at 01:38, ch...@mk... wrote: > >>> I've created a branch in CVS for testmaster 1.1. This branch is based > >>> off > >>> the files labeled rel-1-1-0b3. > >>> > >>> The branch label is Testmaster-1_1 > >>> > >>> You can check this out of cvs using: > >>> cvs -d :ext:cvs.sourceforge.net:/cvsroot/testmaster co -r > >>> Testmaster-1_1 > >>> testmaster > >>> > >>> That means we're now good to start adding code to the trunk. > >>> > >>> Also, in terms of using CVS as a team, I suggest we follow the > >>> practices > >>> outlined in the CVS book (http://cvsbook.red-bean.com/). > >>> > >>> Basically, we communicate changes via email, always do a cvs update > >>> before > >>> a commit and continue communicating openly. We should use the wiki to > >>> assign/volunteer to handle certain areas of work. > >>> > >>> Chad > >>> > >>> > >>> ------------------------------------------------------- > >>> SF email is sponsored by - The IT Product Guide > >>> Read honest & candid reviews on hundreds of IT Products from real > >>> users. > >>> Discover which products truly live up to the hype. Start reading now. > >>> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > >>> _______________________________________________ > >>> Testmaster-devel mailing list > >>> Tes...@li... > >>> https://lists.sourceforge.net/lists/listinfo/testmaster-devel > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Testmaster-devel mailing list > Tes...@li... > https://lists.sourceforge.net/lists/listinfo/testmaster-devel -- AlanP |
|
From: <ch...@mk...> - 2005-02-25 17:44:18
|
OK, looks like there was already a tag made at some point called release_1_1. So lets say we'll adopt this convention moving forward. Chad > Unfortunately, once a branch has been named, you're stuck with that name. > What I can do however is add a tag to the branch that follows that > convention, so if you check out on that tag I think you'll get the right > branch. Let me try it and see. > > Chad > >> Thanks Chad >> >> Any chance of renaming the branch to the convention suggested in : >> >> http://www.magic-cauldron.com/cm/cvs-bestpractices/index.html >> >> (linked from the great cvs link you sent) >> >> release_{major version #}_{minor version #} >> >> >> Cheers matey >> >> >> On 25 Feb 2005, at 01:38, ch...@mk... wrote: >> >>> I've created a branch in CVS for testmaster 1.1. This branch is based >>> off >>> the files labeled rel-1-1-0b3. >>> >>> The branch label is Testmaster-1_1 >>> >>> You can check this out of cvs using: >>> cvs -d :ext:cvs.sourceforge.net:/cvsroot/testmaster co -r >>> Testmaster-1_1 >>> testmaster >>> >>> That means we're now good to start adding code to the trunk. >>> >>> Also, in terms of using CVS as a team, I suggest we follow the >>> practices >>> outlined in the CVS book (http://cvsbook.red-bean.com/). >>> >>> Basically, we communicate changes via email, always do a cvs update >>> before >>> a commit and continue communicating openly. We should use the wiki to >>> assign/volunteer to handle certain areas of work. >>> >>> Chad >>> >>> >>> ------------------------------------------------------- >>> SF email is sponsored by - The IT Product Guide >>> Read honest & candid reviews on hundreds of IT Products from real >>> users. >>> Discover which products truly live up to the hype. Start reading now. >>> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click >>> _______________________________________________ >>> Testmaster-devel mailing list >>> Tes...@li... >>> https://lists.sourceforge.net/lists/listinfo/testmaster-devel >> > > |
|
From: <ch...@mk...> - 2005-02-25 17:41:07
|
Unfortunately, once a branch has been named, you're stuck with that name. What I can do however is add a tag to the branch that follows that convention, so if you check out on that tag I think you'll get the right branch. Let me try it and see. Chad > Thanks Chad > > Any chance of renaming the branch to the convention suggested in : > > http://www.magic-cauldron.com/cm/cvs-bestpractices/index.html > > (linked from the great cvs link you sent) > > release_{major version #}_{minor version #} > > > Cheers matey > > > On 25 Feb 2005, at 01:38, ch...@mk... wrote: > >> I've created a branch in CVS for testmaster 1.1. This branch is based >> off >> the files labeled rel-1-1-0b3. >> >> The branch label is Testmaster-1_1 >> >> You can check this out of cvs using: >> cvs -d :ext:cvs.sourceforge.net:/cvsroot/testmaster co -r >> Testmaster-1_1 >> testmaster >> >> That means we're now good to start adding code to the trunk. >> >> Also, in terms of using CVS as a team, I suggest we follow the >> practices >> outlined in the CVS book (http://cvsbook.red-bean.com/). >> >> Basically, we communicate changes via email, always do a cvs update >> before >> a commit and continue communicating openly. We should use the wiki to >> assign/volunteer to handle certain areas of work. >> >> Chad >> >> >> ------------------------------------------------------- >> SF email is sponsored by - The IT Product Guide >> Read honest & candid reviews on hundreds of IT Products from real >> users. >> Discover which products truly live up to the hype. Start reading now. >> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click >> _______________________________________________ >> Testmaster-devel mailing list >> Tes...@li... >> https://lists.sourceforge.net/lists/listinfo/testmaster-devel > |
|
From: Alan P. <ala...@ya...> - 2005-02-25 16:29:31
|
Thanks Chad Any chance of renaming the branch to the convention suggested in : http://www.magic-cauldron.com/cm/cvs-bestpractices/index.html (linked from the great cvs link you sent) release_{major=A0version=A0#}_{minor=A0version=A0#} Cheers matey On 25 Feb 2005, at 01:38, ch...@mk... wrote: > I've created a branch in CVS for testmaster 1.1. This branch is based=20= > off > the files labeled rel-1-1-0b3. > > The branch label is Testmaster-1_1 > > You can check this out of cvs using: > cvs -d :ext:cvs.sourceforge.net:/cvsroot/testmaster co -r=20 > Testmaster-1_1 > testmaster > > That means we're now good to start adding code to the trunk. > > Also, in terms of using CVS as a team, I suggest we follow the=20 > practices > outlined in the CVS book (http://cvsbook.red-bean.com/). > > Basically, we communicate changes via email, always do a cvs update=20 > before > a commit and continue communicating openly. We should use the wiki to > assign/volunteer to handle certain areas of work. > > Chad > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real=20 > users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=3D6595&alloc_id=3D14396&op=3Dclick > _______________________________________________ > Testmaster-devel mailing list > Tes...@li... > https://lists.sourceforge.net/lists/listinfo/testmaster-devel |
|
From: <ch...@mk...> - 2005-02-25 01:38:29
|
I've created a branch in CVS for testmaster 1.1. This branch is based off the files labeled rel-1-1-0b3. The branch label is Testmaster-1_1 You can check this out of cvs using: cvs -d :ext:cvs.sourceforge.net:/cvsroot/testmaster co -r Testmaster-1_1 testmaster That means we're now good to start adding code to the trunk. Also, in terms of using CVS as a team, I suggest we follow the practices outlined in the CVS book (http://cvsbook.red-bean.com/). Basically, we communicate changes via email, always do a cvs update before a commit and continue communicating openly. We should use the wiki to assign/volunteer to handle certain areas of work. Chad |
|
From: Alan P. <ala...@ya...> - 2005-02-24 20:23:18
|
On Thursday 24 February 2005 20:11, ch...@mk... wrote: > Is everything ready in CVS for branching off 1.1? Alan, what exactly of > the 1.2 code have you added to CVS on SourceForge? Everything in 1.2Chad (your email), which has been sanatised as per email. Yes we are ready to branch, but we need to branch before I added 1.2 code. Al > > Chad > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Testmaster-devel mailing list > Tes...@li... > https://lists.sourceforge.net/lists/listinfo/testmaster-devel -- AlanP |
|
From: <ch...@mk...> - 2005-02-24 20:12:02
|
Is everything ready in CVS for branching off 1.1? Alan, what exactly of the 1.2 code have you added to CVS on SourceForge? Chad |
|
From: Alan P. <ala...@ya...> - 2005-02-23 23:22:00
|
Thanks Abullah, all added to wiki. On Wednesday 23 February 2005 23:09, Al-Mamoon, Abdullah wrote: > 1. ProcessAntiWordDoc changes takes four columns. The first column > has ids, the second column contailns testcases and sections, the third > column contains statuses and section identifiers, the fourth column > contains descriptions. The function concatenates the first and second > column and creates a string. This string is either a testcase if it has > a status in column three or a section if column three contains a S. A > section row should come before a testcase row. The section row is > placed in the section_id column. Then the next row contain the testcase > is added to the testcase_id column. Truncation is done if columns are > too long. And then the contents are added to the database once a full > sql statement can be built with all required fields. > > > 2. tm_tc_states has been changed in the data base > > 0 Pass > 1 Fail > 2 On Hold > 3 In Progress > 4 Pending > 5 Blocked > 6 N/A > 7 Not Started > 8 Awaiting Fix > 9 Dropped > 33 Retired > > 3. DisplayTestsuites has been changed to include 4 buttons for reports > and > 4 links for word reports. > Reports are different percentage breakdowns of status of test plans > > 4. New Functions Added. > GenerateExecutiveSummaryRp used to send hml to std output to open > using > word > > 5. CalculateExcecutiveSummaryStats added to calculate report statistics > > 6. DisplaySummary has been added to control the display of the four > types > of reports. > > > 7. UploadCSVTestcases has been changed to upload testcase_id, > section_id, requrements, status, and description. 5 column upload > instead of 4 column upload. > > 8. testmaster.cgi has been modified to include DisplaySummary call > > > That's all I have for now. > > > Thanks, > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_ide95&alloc_id396&op=Click > _______________________________________________ > Testmaster-devel mailing list > Tes...@li... > https://lists.sourceforge.net/lists/listinfo/testmaster-devel -- AlanP |
|
From: Alan P. <ala...@ya...> - 2005-02-23 23:12:30
|
All 1.2Chad is now in CVS, and it has been purified a little. =46rom here on in 1.2Chad is 1.2 ! Still lots more to do. Wiki updated. Changes : =3D=3D=3D=3D=3D=3D * Customisation removed and put back to 'Testmaster' where appropriate * Credits to everyone on About page * Inclusion of link to 'nosoftwarepatents.com' on about page (comments) * cgi-bin prefix of every testmaster.cgi innvocation=20 (I agree with Chad, this should be customisable, but for now I think it sho= uld=20 match 1.1. If we have time, the install script should populate every file=20 with the correct location using placeholders like %%CGI_LOCATION%) * Removal of dead files (there were quite a few from pre 1.1 days, and even= =20 some not related to tm) * install.sh changed to be able to _attempt_ to install a 1.1 using new CVS= =20 structure ( lots more work required) Al =2D-=20 AlanP |
|
From: Al-Mamoon, A. <AAl...@va...> - 2005-02-23 23:08:33
|
1. ProcessAntiWordDoc changes takes four columns. The first column
has ids, the second column contailns testcases and sections, the third
column contains statuses and section identifiers, the fourth column
contains descriptions. The function concatenates the first and second
column and creates a string. This string is either a testcase if it has
a status in column three or a section if column three contains a S. A
section row should come before a testcase row. The section row is
placed in the section_id column. Then the next row contain the testcase
is added to the testcase_id column. Truncation is done if columns are
too long. And then the contents are added to the database once a full
sql statement can be built with all required fields.
2. tm_tc_states has been changed in the data base
0 Pass
1 Fail
=09
2 On Hold
3 In Progress
4 Pending
5 Blocked
6 N/A
7 Not Started
8 Awaiting Fix
9 Dropped
33 Retired
3. DisplayTestsuites has been changed to include 4 buttons for reports
and
4 links for word reports.
Reports are different percentage breakdowns of status of test plans
4. New Functions Added. =20
GenerateExecutiveSummaryRp used to send hml to std output to open
using =20
word
5. CalculateExcecutiveSummaryStats added to calculate report statistics
6. DisplaySummary has been added to control the display of the four
types =20
of reports.
7. UploadCSVTestcases has been changed to upload testcase_id,
section_id, requrements, status, and description. 5 column upload
instead of 4 column upload.
8. testmaster.cgi has been modified to include DisplaySummary call
That's all I have for now.
Thanks,
abdullah
Thanks,
Abdullah
|
|
From: Al-Mamoon, A. <AAl...@va...> - 2005-02-23 22:37:23
|
=20 =20 13241 Woodland Park Road Herndon, VA 20171 703-345-3445 aal...@va... =20 -----Original Message----- From: Al-Mamoon, Abdullah=20 Sent: Wednesday, February 23, 2005 5:36 PM To: 'tes...@li...' Subject: Abdullah's Changes =20 1. ProcessAntiWord function =20 Column1 Column2 Column 3 Column 4 =20 Testplan id Section id / Testcase id Status/Section Description =20 =20 Concatenates column 1 and column 2 to a string . Column 3 states status if a testcase , S for section =20 =20 Then stored into database. =20 2. =20 Status =20 Additional Field for Remedy Ticket ID =20 =20 0 Pass =20 1 Fail =20 =20 =20 =20 2 On Hold =20 3 In Progress 4 Pending =20 5 Blocked =20 6 N/A =20 7 Not Started 8 Awaiting Fix 9 Dropped =20 33 Retired =20 =20 =20 Finish list next week =20 =20 Thanks, A =20 abdullah =20 =20 13241 Woodland Park Road Herndon, VA 20171 703-345-3445 aal...@va... =20 |
|
From: Alan P. <ala...@ya...> - 2005-02-23 12:06:37
|
That is impressive. I like the << and >> buttons to go between testcases The editing of a testcase is seriously cool too !! I'll talk to you all later on. On 23 Feb 2005, at 01:04, Chad Ullman wrote: > Hi > > I've put together a quick movie of some of the mods I've made to > testmaster in action. Sorry about the hideous colours, that's > something I still need to play with. You can see the movie at > http://www.mkulu.org/scrap/testmaster.html > > Chad > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real > users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Testmaster-devel mailing list > Tes...@li... > https://lists.sourceforge.net/lists/listinfo/testmaster-devel |
|
From: Chad U. <ch...@mk...> - 2005-02-23 01:04:11
|
Hi I've put together a quick movie of some of the mods I've made to testmaster in action. Sorry about the hideous colours, that's something I still need to play with. You can see the movie at http://www.mkulu.org/scrap/testmaster.html Chad |
