Estimate testing effort based on the iteration content and quality risks

In agile projects a number of user stories are completed by the scrum team. These stories are pointed using some of the following methods

Fibonacci Series 
0,1,1,2,3,5,8,13,21 and so on 

when team points a story , they assign the size based on the work they will have to do

T –shirt sizing

Like a size of shirt, you can see the size of stories.

In points teams it gets tricky on the judgement of a developer can be completely different from a tester or BA. Anyway story point are used a lot in agile world

In one of the projects I did, we used T–shirt sizing for pointing stories instead of numbers. We would focus on finishing the stories without focusing much on completing points.
In another project all user stories were pointed in an inception phase before the project started. The user stories were pointed based on product company's experience in implementations of a product in various companies. When we actually started working on the project we realized that some stories were actually bigger than estimated. Product companies did not consider the complexity of the integration to legacy systems. The program also used Jira, an atlassian tool.
In Jira you can add your user stories and assign points against them. There is a feature of agile board where you can add tasks against that user story

In one of the project I did, we were asked to estimate the hours against these tasks and we were told to split hours in way that each task can be completed in 6 hours. It makes sense , but its very hard to track and manage.

Tools like Jira can show you the actual burndown of your user stories and even burndown of hours. In a bigger program where you have multiple scrum teams it gets really hard to implement such a big process . Agile is more about outcomes and less about anything else.

Here are some screenshots of Jira Burndown charts