sql server - Test plan for reporting system -
i have software suite consists of multiple integrated software packages. run off of single centralised sql database.
we in stage writing test plans , have allocated single test plan each independent module of software. 1 left write test plan reporting module. particular module nothing run reports on data in sql database (which written other modules).
any testing iterations preceded developer, regression , integration testing, should remove issues of database data not being correctly maintained.
my dilemma how approach black box test plan reporting module. way see there 3 options:
- append reporting test cases test plans modules influence them (downside: modules work produce reports; reports cannot divided module that)
- write test plan reporting specified pre-requisites, list of instructions of tasks perform in other modules, followed test cases test reporting producing correctly in response these tasks (downside: complicated , long-winded)
- write test plan reporting set datasets on dedicated controlled sql database (downside: lack of flexibility)
it looks me second option best. it's longest-winded alone hardly reason discount something.
does have experience testing module purely reporting, can provide insight best / industry-standard ways this?
thanks in advance!
a useful question ask "what purpose of test?". check out agile testing quadrants detail on role of different test types.
(image credit: lisa crispin)
option 1 focuses on integration points themselves, may valuable team can simplify diagnosis of issues (given 1 module used @ time) fails test system practically used. in sense, falls quadrant 2.
option 2 focuses more on testing system used in real world scenario, invoking multiple modules. lose easy diagnosis of issues option 1, start test in way valuable end user, putting in quadrant 3.
option 3 less flexible version of option 2. you're losing lot of interaction individual modules makes option 2 valuable (in exercises system whole). sufficiently 'real-world-like' database make q3 option, you're still losing flexibility.
comparing options 2 , 3 through lens, can see they serve different purposes. certainly, both execute lot of same code paths, option 1 supports team, letting them know when change specific module has broken reporting while option 2 serves critique product, asking if work in real world scenario. question of outcomes more valuable you, , team.
hope helps.
Comments
Post a Comment