Context-Driven Testing | Glossary

Definition:

Context-driven testing is a model for developing, debugging a software in a specific context where the programs will be used or expected to be used in the real world. Developers identify the intended market and evaluate the environments in which people are likely to employ the product. It is fact that users are humans with preferences, needs, abilities and limitations and programs that works well for a person may not be same for other as the context may be different.

Context-driven testing enhances user-friendliness of the end product, where functionalities are optimised for intended users as well as looking at adaptability of the product based on changing markets and social values. Context-driven school of software testing advocates continuous and creative evaluation of testing opportunities in the light of the potential information revealed and the value of that information in that particular context. It advocates testing in a way that conforms to the context of the project, as opposed to testing as opposed to testing in a way that follows some fixed notion of “best practice”. Context-driven testing could arguably be called agile testing because the principles it recommends are analogous to those suggested in the Agile Manifesto.

Further Reading:

Book: AGILE TESTING A Practical Guide for Testers and Agile Teams
http://wiki.c2.com/?ContextDrivenTesting

Release Candidate | Glossary

Definition:

A Release Candidate(RC) is a beta version with potential to be a final product, which is ready to release unless we find any significant bug. Release Candidate is also known as “going silver”. A release is called on code complete when the development team agrees that no new code will be added to this release at this stage and product is stable with agreed features designed, coded and tested through multiple beta cycles with no showstopper bugs. Testing is conducted at the customer locations from user’s perspective using the release candidate as though it is a finished product.

Release candidate has few issues when compared to the Beta testing build. Release candidates are not for production deployment but are for testing purposes only, however there is no difference between the final build and the last release candidate. Installation issues are verified for final time, critical workflow test is performed against the release candidate. Automated regression test is recommended to done against every release candidate. A team can use a checklist to evaluate each release candidate which includes all features that provide business value for the release, meeting all build acceptance criteria, has proof of having passed all agreed upon test, has no open defect reports.

Further Reading:

Book: AGILE TESTING A Practical Guide for Testers and Agile Teams
https://en.wikipedia.org/wiki/Software_release_life_cycle#Release_candidate
https://www.tutorialspoint.com/software_testing_dictionary/release_candidate.htm