How to best estimate QA times for Localization testing projects
I work in a company that doesnt carry out any development work, just localization testing.
Typically we need to do an initial QA estimate up front & so when you receive a new product, what do you do to verify how much time is required for testing?
Do you estimate by the number of strings in the resources files/potential number of test cases etc
Any feedback would be appreciated for this newbie
This is a difficult one.
My first pass answer is "it depends".
If all you're doing is checking that the strings change when you change the language, the time frame is basically as long as it will take to open every single page/form in the application and scan for anything in the wrong language. This can vary if you need to enter data to trigger popups, dialogs and so forth.
To check that the foreign language strings actually display reasonably in the application takes longer because you have to inspect all the buttons, form elements etc. and make sure that nothing is cut off (which means knowing what the foreign language string should be). I'm sure you've noticed that English is more compact than just about any other language.
Longest (unless you have someone who speaks the language in question natively) is validating that the foreign language strings are correct for each page/form/field/control.
Some of the other complications I've seen depend on how the language display is implemented. ASCII/Unicode symbols are fairly compact. I've seen languages like Japanese stored internally as images, which caused ugly out of memory errors in strange places since a single character required over 1024 bits.
Absolutely agree with katepaulk.
I have been involved with my team in implementing 3 different languages very recently for the product that we are working on and what we did was...
A) Listed down all the...
1. UI screens as primary.
2. Pop-ups and additional link pop-ups as secondary.
B) Did a quick review of the number of fields with field types & averaged them out.
C) An impact analysis was carried out on modules for certain work-flows where we know that the UI changed. This was added to the above listing &
D) Moreover, UI behaviour was also assessed with the business team for "specific" field behaviour and expected outcomes. This was also added to the above listing.
We did a mini-POC and took the numbers for the above averages and computed the total man hours.
After doing the prioritization based on business risks, we came up with a healthy number that could be achieved by the testing team.
Test Estimation Technique
The success of a software testing project greatly depends on the project test estimation technique and its implementation. It is essential to work as per the estimation technique in order to maintain good rapport with the client. From the point of view of quality assurance test estimation techniques are a must. Software testing estimations can be made based on previous work records, available documents, assumptions, calculated risks. All testing companies and IT companies provide a test estimation to their clients to give them an approximate idea about how long it would take to test the software. With every project the team will understand its flaws and learn to create a more accurate estimation report which is again a very important QA requirement. While it is not difficult for experienced people to provide estimates but those who are new in testing jobs or are going to prepare software test estimation for the first time should keep certain things in mind.
When it comes to software testing, always remember to add a buffer time to your estimates. So, that in case there is a delay or any other issue due to which the project cannot be continued then there is no panic created. The buffer time should be practical. The test estimation depends on the bug cycle. If a developer takes time to fix the bug then it is quite obvious that the bug cycle will be delayed causing a delay in testing. Before starting off with the estimation techniques call all your team members and check if any one of them is planning to take a leave during the project and if yes then what are the dates. By considering the availability of the resources you will be able to draft a realistic estimation. It is important to understand that estimations can wrong therefore before finalizing the test estimations it is necessary to have discussion with the team members and make the necessary changes and then make a commitment.
There are 3 main ways of estimating testing in general.
1. Using historical statistics. Have a TCM system that tracks time spent and allow you to calculate number of tests and approximate time needed, find days logged against historical task tickets in your change tracking. (used for well known projects that have clear amount of verification points)
2. Use complexity comparisons. Find a similar project, figure out if it's more or less complex, and adjust the time needed. https://www.scrumalliance.org/commun...stimation.aspx (used mostly in agile)
3. Using Delphi method. Break down the tasks as fine as you can do it. Then get a panel of experts to give estimates in a facilitated way. https://en.wikipedia.org/wiki/Delphi...in_forecasting (used when data is scarce)