1.9.4 unable to import testcases using xls

[istream]

- Clean install of 1.9.4.
- Login
- Create a Project, Create Test Suite, and Try to import test cases using an .xls file (works in 1.9.2)
I get following in the events:
====================================
E_NOTICE Undefined variable: pimport_fn - in /usr/local/TL194/lib/testcases/tcImport.php - Line 80
09/27/2012 10:18:08 E_WARNING move_uploaded_file() [<a href='function.move-uploaded-file'>function.move-uploaded-file</a>]: Unable to move '/tmp/phpOdwUiB' to '' - in /usr/local/TL194/lib/testcases/tcImport.php - Line 60
09/27/2012 10:18:08 E_WARNING move_uploaded_file() [<a href='function.move-uploaded-file'>function.move-uploaded-file</a>]: Filename cannot be empty - in /usr/local/TL194/lib/testcases/tcImport.php - Line 60
09/27/2012 10:18:08 E_NOTICE Undefined index: XLS - in /usr/local/TL194/lib/testcases/tcImport.php - Line 1108
===================================================
Solution?

Thanks.

[fman]

Forget XLS, use only XML

[istream]

When a single test case is exported as XML, and then imported into spreadsheet as described in "file format documentation", instead of seeing four columns (name, summary, steps and expected results) I see a lot more columns, with internal id, name, node_order, external_id, version, summary, preconditions, execution type, importance, step number, actions, expectedresults, execution_type2, name3, value.
Common users of TL wont understand meaning of all the columns and values to provide. Is there any other trick to only see the four columns?

[fman]

we need to re-think completely the XLS approach.
But IMHO we have more important things to do, and XML is working well.
Then I hope users will undertand that XML is the way to go (at least for a long time)

[PMat]

Forget XLS, use only XML

Hi fman,

I'm sorry to say this, but I have worked with paid tools like Quality center 10, and xls is an accelerator to load biggest sets of tests on platform. (I think) nobody in the HP is thinking disable this functionality (!).

I understand your position and humbly accept it, but it was a feature that could bring many other "customers".

BR
Paulo Matos
Portugal

[fman]

>> worked with paid tools like Quality center 10
the point is there => PAIDED tools than cost lots of money as Quality Center. (10K U$S?)
When we will get people willing to pay us for the excel feature, we will consider it addition.
Meanwhile, we are using our forces to add other test management related features

[PMat]

>> worked with paid tools like Quality center 10
the point is there => PAIDED tools than cost lots of money as Quality Center. (10K U$S?)
When we will get people willing to pay us for the excel feature, we will consider it addition.
Meanwhile, we are using our forces to add other test management related features

Yes you are right. I agree with you fman!
I just said what I said because I know software projects with a testing effort with 1 to 3 months and a solution like TestLink is great because it seems easy to implement. Allied to this, if there were a way to load test cases in quantity such as from an excel was excellent!
I'm sure you see what is happening on the web, when we found some pages/blogs ... spread over the web with excels + vba, trying to succeed on this task.
But again, you are right is not paid! And I appreciate that development is done in TestLink, only by donations and the team time!

BR
Paulo Matos
[Portugal]

[istream]

Hi,
Please don't get me(us) wrong, TL is the most beautiful tool there is for QA people out there. With newer releases, it is getting more robust and useful, its just that, typically, QA has to plan in a hurry, so testers tend to or always want to put in their test cases in brief, i.e. a spreadsheet, with name, summary, step(s) {minimum}, and expected results. Once in TL dB, we are able to share the workload with rest of the teams in the project, to get proper schedule alignment etc. Also, as the features, etc. is not very clear during planning, being able to import from XLS (or XML) is very nice. Details are put in as the project moves forward.

Can someone, lay out detail steps as to how to go about doing this, using XML. Since exporting a simple test case from my dB, resulted in 6 rows {1 row per custom field} in the spreadsheet with 15 columns (instead of 4, as expected). I am all for working with XML, if we can have some more information as to how to achieve this.
Thanks for you help.

[fman]

@istream
I do not fully understand your problem, then I will try to answer with what I have grasped:

1. you can work on tl, creating test suites, test cases and so on.
2. you can export Test suites with it's contents on XML format that is documented (you can also get examples on file_examples folder).
3. you can edit this file and reimport

Steps information is NOT on tcversion table but in tcstepst tables.
While in the past test case structure was simple i.e all info on just one table, was not an issue the use of XLS, because each row on your XLS mapped to one row on tcversions table.
But now that you have ONE ROW on tcversions and ONE or MORE for steps on tcsteps, the import procedure is not straight forward and
more the layout to give to XLS also.
That's why the choice was said goodbye to XLS.
But You have a CHOICE: you can use the utility written by a former developer (this utility IS NOT SUPPORTED by Dev TEAM), is a XLS with some macros that allow to do your work o XLS and then click a button to GENERATE THE REQUESTED TL XML file.
THere is also a similar tool fot requirements.

IMHO this is the way for people that want to use XLS, but obviously we do not support this workflow:

1. work on TL
2. export on XML
3. get the info (only God knows how) on an XLS
4. make your changes
5. reimport on TL

Hope thing now are clear.
An important thing is that unfortunatelly we have some documentation that has been not updated (sometime we do not find the time
to do all the tasks) and this can be misleading. Since introduction of TC STEPS we have dropped support for XLS import.
I appologize if we have not comunicated clearly this.


Again if someone needs/wants a different feature and is willing to request a paided development, there are no problems, we can consider it

[PMat]

1. you can work on tl, creating test suites, test cases and so on.
2. you can export Test suites with it's contents on XML format that is documented (you can also get examples on file_examples folder).
3. you can edit this file and reimport

Hi again,
I know this possibility.
The problem here is you can just "change the existing test case" (because the id already exists in database)... so you don't insert new test cases, as I think the author of the original post was also thinking.

When I decided to join at this forum, it was to sharing knowledge, finding answers and solutions to improve, not the tool TL by inside (because isn't my role), but how to QA testers uses the tool.

I continue in that spirit and like istream user, if someone share a way to convert xls to xml, to turn easy and rapid to import test cases, would be a very noble gesture to tester community, and many more I think will join us.

Thanks for your understanding.

Paulo Matos
[Portugal]

[fman]

>> The problem here is you can just "change the existing test case" (because the id already exists in database)...
>> so you don't insert new test cases
Absolutely false.
Issue is, that 99% of TL users find easier to avoid any kind of simple experiments, and just start posting saying: 'this can not be done.'
If you write the XML file and use A NOT EXISTENT Internal ID, TestLink will create NEW TEST CASES with a new internal id and a new external one.
Regarding:
>> ... as I think the author of the original post was also thinking.
You are trying to do a guess, while I need to work in a different way in order to provide results.
I need to have clear facts, and/or clear use cases and/or clear requirements, to avoid any kind of confusion and avoid waste of development time to build something that was not requested.

Our work will be a lot easier if users provide clear use cases (not half explained), clear detailed steps to reproduce and so on.

May be when I do the post, I do it in a confused way but:

1. I've explained why we do not want to do work on XLS import
2. I've explained that ALREADY THERE IS A WAY TO WORK ON XLS using ONE FIXED XLS provided by a user (you can find posts regarding this XLS on forum and can find the XLS on [TL INSTALL DIR]/doc/utils).
3. I've done test that any user can do, check if import can be done.

We have done our best efforts, now I'm going to wait and see when we are going to receive a contribution that solve this, instead of complains.