Test plans are defined by customers,
and are a vital piece of documentation throughout a product's life cycle –
from the lab to the pharmacy shelf.
Because test plans change over time,
it is not enough to store a list of tests that are required for each part.
Each sample must be traceable to the plan it was tested against.
Problem
At the moment,
testing requirements are defined one-by-one in the specification table.
Once a specification has been created,
there is no way to delete it through the UI.
There is not an intuitive way to see
which tests were required at a certain point in time,
or to look at how testing requirements have changed over time.
Possible Approaches
Option 1
Add a new database table called test_plans.
Associate each specification with a test_plan,
in a parent/child relationship.
The downside of this approach is that
for a small change to an existing test plans,
we will need to copy most of the data
from the existing plan onto the new plan.
I've used this approach in the past.
It works, but it leaves a lot to be desired.
Option 2
Add a database table called test_plan_modifications.
When a specification is added, link it to a test_plan_modification, as a addition_event.
When a specification is removed, link it to a test_plan_modification as a removal_event.
This would mean:
Active specifications have addition_event is not null and removal_event is null
We'd have a handy place to attach files that document changing requirements.
We could view a test plan at a certain point in time with:
select * from specification
inner join test_plan_modifications addition
on specification.addition_event = addition.id
inner join test_plan_modifications removal
on specification.removal_event = removal.id
where addition.timestamp < '2018-01-01'
and removal.timestamp > '2018-01-01'
or removal.timestamp is null
If we require versions to be sequential numbers,
We could view a test plan at a certain version (e.g. 6) with:
select * from specification
inner join test_plan_modifications addition
on specification.addition_event = addition.id
inner join test_plan_modifications removal
on specification.removal_event = removal.id
where addition.version <= '6'
and removal.version > '6'
or removal_event is null
The downside of this approach
is that we will almost never be able to query specification
without joining it up to test_plan_modifications.
This isn't a huge deal,
but it requires everyone to have an understanding of how the system's set up.
Verdict
Option 2 seems like a much cleaner route to go,
and it will give us room to experiment with an event-based data store.
We might be able to minimize the query overhead
with a data modeling system like MobX (See #44).
Test plans are defined by customers, and are a vital piece of documentation throughout a product's life cycle – from the lab to the pharmacy shelf.
Because test plans change over time, it is not enough to store a list of tests that are required for each part. Each sample must be traceable to the plan it was tested against.
Problem
At the moment, testing requirements are defined one-by-one in the
specificationtable.Once a specification has been created, there is no way to delete it through the UI.
There is not an intuitive way to see which tests were required at a certain point in time, or to look at how testing requirements have changed over time.
Possible Approaches
Option 1
test_plans.test_plan, in a parent/child relationship.The downside of this approach is that for a small change to an existing test plans, we will need to copy most of the data from the existing plan onto the new plan.
I've used this approach in the past. It works, but it leaves a lot to be desired.
Option 2
test_plan_modifications.test_plan_modification, as aaddition_event.test_plan_modificationas aremoval_event.This would mean:
Active specifications have
addition_event is not nullandremoval_event is nullWe'd have a handy place to attach files that document changing requirements.
We could view a test plan at a certain point in time with:
If we require versions to be sequential numbers, We could view a test plan at a certain version (e.g.
6) with:The downside of this approach is that we will almost never be able to query
specificationwithout joining it up totest_plan_modifications. This isn't a huge deal, but it requires everyone to have an understanding of how the system's set up.Verdict
Option 2 seems like a much cleaner route to go, and it will give us room to experiment with an event-based data store.
We might be able to minimize the query overhead with a data modeling system like MobX (See #44).