Join 34,000+ subscribers and receive articles from our blog about software quality, testing, QA and security.
 
  This website uses cookies to ensure you get the best experience on our website.
Yes, I consent No, Thanks

Changing a string field to an integer

#1

I realize I cannot change the type of a field, but that is what I want to do. I am inheriting a TestRail setup from someone else. They defined a field called “Estimate” as a string. Noone is using it now. I would like to start using it, and I would like it to be an integer so that I can add up the values in my test plan to get an estimate of how many test hours are involved in my test plan.

I was wondering if you had a suggestion on how I should proceed… I create a new field and call it something else, like “Run Time”, and change the name of the other field to something else to avoid confusion?

#2

TR has an Estimate field on the Cases table that is an int. It shows up on the add Cases screen - the last field on the right next to the Priority drop down. The field records time in seconds - so 5 minutes on the screen will be saved as 300 in the table.

#3

Hello Bill,

Thanks for your posting. I would recommend using the built-in Estimate field and this is now also listed under Administration > Customizations (as system field). Are you sure that your team added a separate custom field or do you see the Estimate field labeled as system field under Administration > Customizations?

Regards,
Tobias

#4

I apologize for my ignorance. Like I said, I am new to TR, so I might be asking a silly question.

I go into the “Administration” tab. The first display is the Customzations, and alist of “Case Fields”. The firt field listed is "Estimate (estimate) and the type is “String”. It looks like it is a System field.
So, is it a string that is used as an integer? How does it work?

#5

That is a custom field but it is unnecessary as TR includes an Estimate field already and it is defined as an int - look on the cases table.

The built in Estimate field is the 6th field from the top of the field listing. The custom field will be at the bottom prefixed with ‘custom_’

The above is the setup for TR 4.1/4.2

#6

Hello Bill/Brian,

Starting with TR 4.2, the Estimate field (and some additional system fields) are now also listed under Administration > Customization and can be customized to some extent (e.g. disabled). The Estimate field supports a variety of input formats (including simple integers as minutes) and you can learn more about the supported format here:

http://docs.gurock.com/testrail-userguide/userguide-tips#scheduling_and_forecasting

Regards,
Tobias

#7

Crap - I checked 4.2 and did not see it was listed as ‘string’ - my apologies for any confusion. With the DB and my testing, the string would be for the field definition in the UI. This allows the UI to use and see the d, w, s (8 hours/day - work hours) and do the calculations for the db field as it is an int.

Since the import/export does not use the UI - it only accepts int (seconds) - the UI will do the conversion when viewed in TR itself.

#8

I changed the title of this thread. Hopefully it will be more useful that way. I realize I may have been asking about implementing a solution here without explaining what my problem is, so let me back up…

I have two types of estimates (those for manual vs. automated tests) and would like to treat them differently depending on what type of test is being run. I m nor sure if I am using TestRail as intended. Automated tests are designated using the field “Methodology” and set to either “Manual” or “Automated”. An estimate for a manual test should be using an 8hr/day calendar since someone has to be doing work in order to run the test. An estimate for an automated test should be using a 24hr/day assumption since they run as soon as the build completes. For these tests, if I say it takes 16hours, it really takes 16hours, not 2days. Is there a way I can set up my tests to reflect this?

#9

Hi Bill,

Thanks for the additional details. I would recommend using the built-in Estimate field for your manual tests and this would be a perfect fit for the 8 hour work days. You can also use the extended timespan syntax in this case (e.g.: ‘2m’, ‘2 hours and 5 minutes’, etc). For the automated cases, I would recommend using a single integer custom field instead (either handled as minutes or seconds, for example, depending on the precision you need).

Regards,
Tobias