Inclusion of the Documentation work as Story in the Sprints

There is no "proper scrum way" for this.  This is something that your Scrum Team needs to decide.  This statement comes from the Scrum Guide section that describes Sprint Planning

For each selected Product Backlog item, the Developers plan the work necessary to create an Increment that meets the Definition of Done. This is often done by decomposing Product Backlog items into smaller work items of one day or less. How this is done is at the sole discretion of the Developers. No one else tells them how to turn Product Backlog items into Increments of value.

Your Developers need to decide how to handle those tasks. As part of refining the Product Backlog Items, they can break the work down in any way that they feel is best. 

These could be PBIs or they could be included as part of the DoD, or a split of both, it all depends on how the scrum team wish to capture them. 

Daniel is right that there's no one way to do this that is more consistent with Scrum than another way.

For the creation of the OQ scripts, I would suggest considering the Definition of Done. Since the Product Backlog Items represent things that the team needs to do to improve the product, I would think that it's likely that a change would impact your test scripts. I believe that it makes sense for calling a Product Backlog Item "done" to require at least checking for impact to the test scripts and updating them, as necessary. The team would then consider this when estimating or sizing the work (if they estimate or size Product Backlog Items) and when selecting Product Backlog Items for a Sprint.

For IQ, I would ask how frequently you intend to carry out your IQ activities. Are you releasing your product every Sprint? How much time and effort does the execution of your IQ take? There are multiple ways to handle this. Since it's being done by a member of the Scrum Team, I would recommend making it visible on the Sprint Backlog where the IQ happens and making sure the time and effort required is considered when planning the Sprint.

At the end of the day, though, the team should find ways to ensure that the work is remembered, made visible, and tracked to completion in a way that makes sense for them as well as other stakeholders who may need to see the current state of the team's work.

Please let me know what is the proper scrum way of having these activities in form of a story so that I can also capture the effort for the resource in the sprint.

The proper Scrum way would be for you not to capture the "effort for the resource" at all. Scrum Developers are not resources, they are skilled people who make their own estimates.

What benefit do you get by ‘capturing the effort’? Decide that, and then consider how best to achieve it.