| || |
Testing offsite printed documents
Currently QA tester has to test print documents prior to install to production by reviewing PDF and going offsite to a print vendor since PDF may not display breaks accurately. Once we deploy the project, QA has to go to a print vendor again to test the print. Vendor verification is out of questions. What would you suggest? I think users (internal department) should go onsite to look at it once the project is installed, not QA. When QA has to go offsite to test the print, they are unable to perform functions onsite and there is no telling when they will be back. If we have multiple projects deploy there is only 1 QA resource to has to sign off under all the documents tested. That does not seem right as this tester may not have tested the project itself.
One of the thing about QA is you have to really get away of testing like a user, and finding ways of testing if the program behaves good enough with reasonable confidence.
In this case, you have an example PDF right? The developer could use easily rewrite their app to use Dependency Injection to make the PDF generation module testable in integration testing with code coverage metrics, where the output can be compared byte for byte with the expected output. Then you have a pretty reasonable confidence that if the module was fed in correct input, it would output the PDF correctly.
Then you're left to testing whether the module gets the correct input.
Originally Posted by dlai
Appreciate your response.
To make things easier we use AS400 for all calculations and web is just for input/ output. So it is AS400 that kicks off the print process. Typically a spool file is generated and converted to human readable format by ULURO then postscript is created and print vendor who also uses ULURO gets the docs to print. ..PDF is also created and stored in ONBASE where you can view documentation.
What is exactly dependency injection?