Should bugs be added as tasks or as stories on the board?

A board isn't necessarily a part of Scrum. The Scrum framework recognizes the Product Backlog and the Sprint Backlog. Some teams may use a board to represent these backlogs, particularly the Sprint Backlog, but this isn't necessary. The Scrum framework also doesn't recognize distinct types of Product Backlog Items, although some teams may find it useful to identify different types of work.

If the work needs to be done in the current Sprint, then it would be represented on the Sprint Backlog, however the team chooses to do that. Since the Developers are fully accountable for the Sprint Backlog, no one other than the Developers should accept the work into the current Sprint. Otherwise, the work would go into the Product Backlog, be ordered by the Product Owner, and refined as necessary by the Scrum Team.

The Product Backlog represents all that is needed to improve the product.  There is nothing in the Guide that distinguishes different types.  I actually advocate that all items in the Product Backlog be the same type.  That helps people treat everything equally.  After all, a bug is just a change that is needed to improve the product just a new feature would.  

My recommendation is that you write the bugs as an item in the Product Backlog so that they can be ordered by the Product Owner appropriately.  Then the Developers can decide whether to include those items in the next Sprint. 

I have a sprint that was finished and released but some bugs came from production

I bet they didn't. I bet they came from development and were exposed in production.

and they need to be added to the next sprint . what's the best way to write the bugs on the board ?

Improve the Definition of Done so product quality is not compromised by such defects again. If a Product Backlog item is defective, it will remain on the Product Backlog until it is Done.

So you have Work Items that need to be prioritized and go into the Backlog on the Board. (Yes, I meant to use Kanban terms)



That's it actually. In Scrum terms: Product Backlog Items go onto the Product Backlog and can be chosen for the Sprint Backlog during Sprint Planning.



Why would a bug be different from any other items?

I may be misunderstood here. I am referring to the way if writing.should it be as stories.. Example 

As a user i would like to do xxx sothat xxxx

Or i can list it directly without a story for example

Fix xxxxx not showing correct results

Scrum is not going to tell you how to capture information. User stories are not a Scrum artifact. 



Thew team needs to adapt their process based on what makes sense in context. 



 

There is no "best way" to capture defects as Product Backlog Items (PBIs), only what makes sense for your team so that the issues are transparent and clear and the team knows what needs to be addressed. As others have mentioned, User Stories are a complimentary practice that teams may or may not leverage for PBIs. 

As an example, the team I am currently serving uses a bit of a template for their in-Sprint defects and production bugs that highlights things like expected behaviour, actual behaviour, environment found, impact, screen shots etc. For this team, these types of PBI attributes support them in understanding the impact of the defect. For another team, they may just have a PBI that says "fix the thing", and if as a team they understand what that means, that could be all they need.

Newly found bugs which are part of delivered solutions must be fixed on priority

it should be added into Product Backlog for the next sprint without creating a new stories. 

Usually production bugs means we need to improve our testing data and method as well 

Haytham, what about documenting 2-3 bugs with the team collaborative? The style of documentation will emerge in that session. 

User stories help people understand requirements, but they are not a golden standard.  User stories should be a business nead.

It's hard to write a bug as a business need.  I, for one, wouldn't let a user story format or formality get in the way of getting work done.  It's usually not helpful, in my experience, to write bugs as user stories.

Resolving the bugs are also going to add more value to the Product. My opinion as of others is that they should be added into the Product Backlog first, prioritized with the Product Owner and then maybe included in the Sprint Backlog for the next Sprint. Its up to the Team to decide how the information related to the Bug should be captured.

Important would be to discuss the Definition of Done in the next Sprint Retrospective to find ways to reduce occurrence of bugs in future.