blob: 5f864841955b88695ea6b837080d840503b96496 [file] [log] [blame]
<?xml version="1.0" encoding="utf-8"?>
<?xml-stylesheet type="text/xsl" href="../../../../wtp.xsl"?>
<html>
<head>
<meta name="root" content="../../../../../" />
<title>wtp milestone 4 test plan</title>
</head>
<body>
<h1>XML Editor M4 test plan</h1>
<h2>Status of this Document</h2>
<p>
This is the test plan for the XML Editor for the Milestone 4
release. Last updated on 04/15/2005.
</p>
<h2>Overall goals</h2>
<h3>Co-developer Testing</h3>
<p>
We will inspect &quot;runtime&quot; version of build to be
sure extra source is not included, and more important, we'll
inspect and test importing SDK version to be sure all
relevant &quot;open source&quot; is included in that SDK
build and that it correctly imports into a development
environment.
</p>
<h3>API Testing</h3>
<p>
Here in M4 we don't consider we have any official API yet
(since not spec'd as such) but will reserve this space for
future plans to details were API Unit tests are, their
coverage, etc.
</p>
<h3>End User Testing</h3>
<p>
Our primary goal in M4 End-User Testing is to ensure basic
functions work. Specifically, we want to confirm that the
user is able to add, modify and delete catalog entries.
</p>
<p>
I might also point out that the nature of the end-user
testing is intentionally planned to be "ad hoc" instead of
specifying step by step "how to" directions and specific
"expected results" sections often seen in test cases. This
is done because its felt leads to greater number of "paths"
being tested, and allows end-users more motivation for
logging "bugs" if things didn't work as
<i>they</i>
expected, even if it is working as designed.
</p>
<p>
As we progress through milestones, we'll add more and more
detail for special cases, special files, special projects,
etc.When we do have special or sample test files and
projects, we will keep those stored in CVS, as projects
under a
<i>testdata</i>
directory under the
<i>development</i>
directory of relevant component so that testers (from
immediate team, or community) can easily check out into the
environment being tested.
</p>
<h3>Platform Testing</h3>
<p>
While we do not have any platform specific code, or
function, we will have some team members do end-user tests
on Linux, some on Windows. We will also confirm unit tests
pass on both platforms.
</p>
<h3>Performance Testing</h3>
<p>
We do not have any specific performance testing planned for
M4, but will add automated performance tests along the lines
of the Eclipse base performance unit tests in future
milestones.
</p>
<h2>Tests</h2>
<B>General Scenario</B>
<UL>
<LI>
Validate an invalid document and ensure problems are
shown as annotations in the editor's source ruler and
margin
</LI>
<LI>
Check that error messages are listed in the problems
view
</LI>
<LI>Check that navigation works for error markers</LI>
<LI>Check that line numbers match error markers</LI>
<LI>
Correct errors and revalidate and ensure all markers and
messages are removed
</LI>
<LI>
Ensure popup message dialog appear with the correct
validation message
</LI>
</UL>
<B>XML Catalog</B>
<UL>
<LI>Test that validation works with the XML Catalog</LI>
</UL>
<B>Referenced Files</B>
<UL>
<LI>Test errors in referenced files</LI>
<LI>
good xml, bad xsd. ie. XSD errors should not show in XML
resource. There should be however one message to
indicate that there are errors in the referenced file
</LI>
<LI>Test similarly also for good xml, bad dtd</LI>
</UL>
<B>Validation Preferences</B>
<UL>
<LI>Test validate on file save</LI>
<LI>Turn it on and off</LI>
<LI>Test global vs project settings</LI>
<LI>Test maximum number of messages</LI>
</UL>
<H4>XML Examples</H4>
<UL>
<LI>
Create the Editing and validating XML files Examples
</LI>
<LI>
Verify that the sample files are created in the
designated folder
</LI>
</UL>
<B>XML Tutorials</B>
<UL>
<LI>Excercise XML Catalog tutorial</LI>
<LI>Excercise XML Validation tutorial</LI>
<LI>Excersice Creating XML Documents tutorial</LI>
</UL>
</body>
</html>