Created
June 19, 2009 12:26
-
-
Save costa/132588 to your computer and use it in GitHub Desktop.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
A thought on specs (no reality check has been done yet): | |
Specs in ruby are so nice that they may actually serve a formal basis for PM-R&D-QA communication. | |
One idea on one aspect along those lines follows. | |
Sometimes the specs are incomplete (putting it nicely), but sometimes they are inherently incomplete | |
(like missing required functionality description whatsoever) which is grave bad, and | |
sometimes a partial (wordy) description for a certain function is present – lacking a formal example. | |
I am dealing with the latter case of course, which may just be more than popular in UI-oriented apps. | |
More than that, I see situations where formal spec for a feature is just too expensive to code, | |
e.g. a general user experience over a set of web pages. | |
# For instance: | |
describe "my beautiful page is shown" do | |
it "should look perfect" | |
end | |
Leaving the requirement at PENDING is okay, but to me, there is a better option of.. uh.. manual check! | |
# Something like: | |
describe "my beautiful page is shown" do | |
it "should look perfect" do | |
man_browse url ... | |
end | |
end | |
# Or: | |
describe "my beautiful page is shown" do | |
it "should look perfect at", url(...) | |
end | |
That is, when spec check sees such a description it should pop up the browser at the specified URL | |
and make the testing person check the page(s) manually. The checking script should wait for the tester | |
to accept/reject the description manually and then continue with the tests. | |
There is a lot of opportunity for browser-based automation of this thing | |
(e.g. a plugin which pops-up a "manual spec check confirmation dialog" and transfers button clicks to the script being run). | |
There is also an opportunity of making the test results persistent – such a permanent test result file | |
should be the newest-modified file in the project repository (make-like reasoning). | |
Again, I hope there is some appropriate tooling in existence, but if not, | |
it doesn't look like a great deal to implement the basics of it. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment