Typically you want to keep things as data-driven as possible. That is, use an actual scripting language very sparingly. A quest can be comprised of a series of steps, with each step having some requirements to complete, and then a reward. More complex games might need more intricacy here, but the gist remains the same. You might allow calling out to a script here or there for some pieces of this, but again, do so as rarely as possible.
The advantage of being data-driven is that you can build a nice GUI for churning out quests. You can also write tools that analyze quests to ensure they're completable, tell you an estimate of the difficulty/reward ratio, and so on. Roughly something like:
<quest name="Save the Place">
<stage id="get_key" name="Get the Key">
<requirements>
<talk npc="gatekeeper" />
</requirements>
<results>
<acquire item="red_key" />
<experience amount="100" />
</results>
</stage>
<stage id="enter" name="Enter the Place">
<prerequisite>
<complete stage="get_key" />
</prerequisite>
<requirements>
<arrive area="the_place" />
<unlock door="gate" />
</requirements>
<results>
<experience amount="100" />
</results>
</stage>
<stage id="cleanse" name="Kill the Dudes">
<prerequisite>
<complete stage="enter" />
</prerequisite>
<requirements>
<kill enemy="dude" number="10" area="the_place" />
</requirements>
<results>
<experience amount="500" />
</results>
</stage>
<stage name="Report Success">
<prerequisite>
<complete stage="cleanse" />
</prerequisite>
<requirements>
<talk npc="gatekeeper" />
</requirements>
<results>
<experience amount="2000" />
<acquire item="cool_sword" />
</results>
</stage>
</quest>
There'd likely be a bit more to it in a real example. You can allow scripting to offer new types of prerequisites, requirements, or results, but that script should be separated from the data; the script is an implementation detail of how quests work, not a fundemantal piece of logic to the quest itself. The data still defines the outline of what goes on.
You can allow stages to be optional, allow both OR and AND requirements (so you either need to do A or B, not both), integrate more tightly with your dialog system, control spawning/instancing, and so on.
The system allows both easy editing in a GUI, should you choose to build one, and naturally maps to in-game displays. The game might have some little quest marker on the screen (or in the game journal) that looks something like:
(X) Get the Key
(X) Enter the Place
( ) Kill the Dudes (4/10)
Stages could also set item id's as quest items (so an item is a quest item only while the quest is active), set a target location/enemy for directional indicators, etc. All data-driven with not a single extra line of code needing to be written for each quest.