Feature

Test cases and Requirement Tracking

Summary

open
Sep 1, 2006
Sep 1, 2006 / pixtur
Jun 25, 2008 / pixtur
 

Attached files

No files uploaded
 
For software development in small teams defining and running test-cases could help a lot. Actually we could have used this very well for a project I have just been working on. It would fit very well into strebers concept:

We would have another type of tasks called Requirement. (The name could change).

For a project we can define any number of:
  • TestSuites - Holding a description and a number of requirements to be tested
  • TestLogs - Collects the results of a TestSuite ran by a team member at a certain time, version and plattform.
Requirements are listed in a list similar to 'my tasks' and can be grouped into the project folders. TestSuites are listed like versions in the top navigation of the project. In the view of a TestSuite you would see a table of the previous test-results and the option to run a new test.


Running a TestSuite:π

Form with:
  • date (filled automatically)
  • version_id
  • version (alternative string)
  • plattform
  • comment
for each requirment form with following options:
  • tested: [no, yes, not possible, unclear meaning,...] (not sure if we need this)
  • result: [not tested, passed, failed]
  • rate: [ excellent, good, ok, sufficient, imperfect, horrible, not existing]
  • comment
TestProtokolls could be printed for signing with clients.

Normally you only would create one test suite for a project. But it might be useful to define several e.g. for different project phases or purposes. The good thing is, that this function allows you to add testers to your project and get them to work immediatly. If the requirements are written in plain words, they just start testing. As you probably know, this is not the funniest job, but it has to be done and getting people to do it, is a tremendous help.

Tracking the results over some time could provide important feedback.


Database Tables:π

testsuite:π

  • id
  • name
  • project

testsuite_taskπ

  • id
  • testsuite (id)
  • task (id)
  • importance (TINYINT Optional ... Required)

testprotokollπ

  • id
  • INT testsuite (id)
  • INT person (id)
  • VARCHAR version
  • INT version
  • VARCHAR version_string
  • VARCHAR plattform
  • LONGTEXT comment (Wikitext for other attends, resulting tasks etc.)

test_taskπ

  • INT testprotokoll (id)
  • INT testsuite_task (id)
  • TINYINT tested: [no, yes, not possible, unclear meaning,...] (not sure if we need this)
  • TINYINT result: [not tested, passed, failed]
  • TINYINT rate: [excellent, good, ok, sufficient, imperfect, horrible, not existing]
  • VARCHAR comment
  • INT follow_of_bug

mental notes & Qustionsπ

  • Turning normal Tasks into Requirements could be tricky because of broken links. Actually any task could be part of a test_suite (it might be useful to test if a fixed bug or and implemented feature is still working). So we could just assign any task to a test_suite
  • Showing Test-feature would be an option of each project and are hidden by default.
  • With the API tests could be done automatically with scripts and streber could be only used for tracking the results
  • hierarchical tests would be really nice. Like we could break down tests for streber into following Test_suites:
    • Installation
    • upgrade
    • Creating of Types
    • Assignment, Profiles, Rights and Visibilty
    • CSS and Layout
    • Wiki Rendering
  • We could define Suites of Test_suites:
    • a "basic db" set for Server, PHP and MySQL tests (Installation, Upgrade, Creation of types).
    • a "browser set" with (installation, creating of types, css & layout, wiki rendering)
    • a "Complete tests" for motivated testers, etc
  • Since each Task (Requirement) can have a wiki description including images, we could describe very nice, how the tested thing would behave. (e.g. like a css layout is supposed to look like).

also see:π


6 Comments

tino:Hello Tom

12 years ago

this is a very needed feature for the future!

pixtur:Just finished my last project!

12 years ago

I already played around with jquery and ajax. The new javascript-stuff is just increbilbe. If there wouldn't been IE6 we could build a much improved version very quickly.

Runnings tests would benefit extremely from clever javascript interaction... I am anxious to play around some more. I am not sure, if I should check in my earliest tries, because nothing will work in IE anymore. I need some browser-forking ;-(

tom

tino:Hmm

12 years ago

hey Tom,

we shouldn't lose sight of IE6!
For me Firefox is the best browser at the moment, but there are still over 80 percent using IE ;-(

And a forked version of streber isn't good, from my point of view!

pixtur:Do not be afraid

12 years ago

I know very well, that there is no way around IE. But still it is a pain in the ass. I will have to delay the cool JQuery-Features for a while and start refactoring the already implemented JS-Features first.

tino:Hey tom

12 years ago

start refactoring the already implemented JS-Features first

I agree with you - that sould be our focus.

I'm looking forward to it

guest:

8 years ago - visible as suggested -

[link=google.com]google[/url]