Testing for Quality Software

As the blog title goes… to be Practical SDLC, I will start with a “software quality assurance” topic; that is actionable.

Failed Interview
In a QA-specialist job interview, interviewer has asked a friend of mine to give test cases for a hypothetical simple-calculator; the company want to sell ( with only digits and plus/minus signs).
My friend has talked about building test cases for small numbers, big numbers, zero, negatives etc.

Interviewer has told him that he failed that portion of the interview because… a tester must always ask for initial requirements to build additional test cases needed to satisfy the ultimate goals for the product (in the case of the calculator, if it was meant for childlen... rugged, big buttons, distinct beeps for plus and minus etc.).

So... practical actionable items are

1. When you are asked to build test cases, always ask for original requirements.
2. Involve QA from day one of a project; ask testers to think about (or start creating) ways (test cases/scenarios) to verify requirements (vision, scope, goals, success criteria) stated in early documents.
3. This also means that, do not start building without vision, scope, goals and success-criteria documented (let’s talk Agile later).

Some QA related references for further research
Project Charter [business vision is stated in business language]
Requirement Specifications [to be used as input for later documents] Functional Specification, Logical Design, Physical Design, Interface Specification(s) [output documents based in requirements]
Black box testing [input: Requirements, functional specification, high level design docs. output: Test plans for interface tests, load tests, stress tests, security tests/review, various usability tests like globalization.]
White box testing [input: high level design docs, detail design docs, source code. output: Test plans for internal methods (various code path performance, resource utilization, locking models, loops, conditional statements, boundary checks, security tests etc.)]
Peer review [getting peers to review code at code completion ] Everybody does unit tests, integration tests, functional tests, system tests, performance tests, user acceptance tests etc., we sometimes forget to Install/uninstall, failover, disaster recovery (is service level documented?) tests.
Don’t forget usability tests [MSF defines a user experience role; dedicated to ensure end-user (business, operations, helpdesk etc.) satisfaction.]
Mutation tests [create bugs to see if existing tests can catch created bugs]
V-Model software development [pays special attention to importance of testing]
Maintenance Specifications [documents related to maintenance activities]


QuestionWho is responsible, if a delivered solution is declared useless due to... business having a valueless vision or IT incorrectly interpreting business vision/goals?