ತಂತ್ರಾಂಶ ಪರೀಕ್ಷೆ

ತಂತ್ರಾಂಶ ಪರೀಕ್ಷೆ ಎಂಬುದು ಒಂದು ಕ್ರಮಬದ್ಧವಾದ ಪರೀಕ್ಷೆಯಾಗಿದ್ದು, ಪರೀಕ್ಷೆಗೆ ಒಳಪಟ್ಟಿರುವ ಉತ್ಪನ್ನ ಅಥವಾ ಸೇವೆಯ ಗುಣಮಟ್ಟದ ಕುರಿತಾದ ಮಾಹಿತಿಯನ್ನು ಮಧ್ಯಸ್ಥಗಾರರಿಗೆ ಒದಗಿಸಲು ಇದನ್ನು ನಡೆಸಲಾಗುತ್ತದೆ.^[೧] ವ್ಯವಹಾರದ ಅಸ್ತಿತ್ವವು ತಂತ್ರಾಂಶದ ಅನುಷ್ಠಾನದ ಅಪಾಯಗಳನ್ನು ಗ್ರಹಿಸುವುದಕ್ಕೆ ಮತ್ತು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದಕ್ಕೆ ಅನುವು ಮಾಡಿಕೊಡುವ ದೃಷ್ಟಿಯಿಂದ, ತಂತ್ರಾಂಶದ ಒಂದು ವಸ್ತುನಿಷ್ಠ, ಸ್ವತಂತ್ರ ನೋಟವನ್ನೂ ಸಹ ತಂತ್ರಾಂಶ ಪರೀಕ್ಷೆಯು ಒದಗಿಸುತ್ತದೆ. ತಂತ್ರಾಂಶದ ದೋಷಗಳನ್ನು ಕಂಡುಹಿಡಿಯುವ ಆಶಯದೊಂದಿಗಿನ ಒಂದು ಕಾರ್ಯಸೂಚಿ ಅಥವಾ ಅನ್ವಯಿಕೆಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವ ಪ್ರಕ್ರಿಯೆಯು ಸದರಿ ಪರೀಕ್ಷಾ ಕೌಶಲಗಳಲ್ಲಿ ಸೇರಿಕೊಂಡಿದೆಯಾದರೂ, ಕೌಶಲಗಳು ಅಷ್ಟಕ್ಕೇ ಸೀಮಿತಗೊಂಡಿಲ್ಲ.

ಒಂದು ತಂತ್ರಾಂಶ ಕಾರ್ಯಸೂಚಿ/ಅನ್ವಯಿಕೆ/ಉತ್ಪನ್ನವು ಈ ಕೆಳಕಂಡ ಚಟುವಟಿಕೆಗಳನ್ನು ಕೈಗೊಳ್ಳಬಲ್ಲದು ಎಂಬ ಅಂಶವನ್ನು ಆಧಾರವಾಗಿರಿಸಿಕೊಂಡು, ಕ್ರಮಬದ್ಧಗೊಳಿಸುವುದರ ಮತ್ತು ಪರಿಶೀಲಿಸುವುದರ ಪ್ರಕ್ರಿಯೆಯಾಗಿಯೂ ತಂತ್ರಾಂಶ ಪರೀಕ್ಷೆಯನ್ನು ವ್ಯಾಖ್ಯಾನಿಸಬಹುದು:

ಅದು ತನ್ನ ವಿನ್ಯಾಸ ಮತ್ತು ಅಭಿವೃದ್ಧಿಗೆ ಮಾರ್ಗದರ್ಶನ ನೀಡಿದ ವ್ಯಾವಹಾರಿಕ ಮತ್ತು ತಾಂತ್ರಿಕ ಅವಶ್ಯಕತೆಗಳನ್ನು ಈಡೇರಿಸುತ್ತದೆ;
ನಿರೀಕ್ಷಿಸಲ್ಪಟ್ಟಂತೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ; ಮತ್ತು
ಅದೇ ಗುಣ ಲಕ್ಷಣಗಳೊಂದಿಗೆ ಅದನ್ನು ಅನುಷ್ಠಾನಗೊಳಿಸಬಹುದು.

ಅಳವಡಿಸಿಕೊಳ್ಳಲ್ಪಟ್ಟ ಪರೀಕ್ಷಾ ವಿಧಾನವನ್ನು ಅವಲಂಬಿಸಿ, ಅಭಿವೃದ್ಧಿ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿನ ಯಾವುದೇ ಸಮಯದಲ್ಲಿ ತಂತ್ರಾಂಶ ಪರೀಕ್ಷೆಯನ್ನು ಅನುಷ್ಠಾನಗೊಳಿಸಬಹುದು. ಆದಾಗ್ಯೂ, ಅವಶ್ಯಕತೆಗಳು ವಿಶದೀಕರಿಸಲ್ಪಟ್ಟ ನಂತರ ಮತ್ತು ಸಂಕೇತಿಸುವ ಪ್ರಕ್ರಿಯೆಯು ಸಂಪೂರ್ಣಗೊಳಿಸಲ್ಪಟ್ಟ ನಂತರ ಬಹುಪಾಲು ಪರೀಕ್ಷಾ ಪ್ರಯತ್ನವು ನಡೆಯುತ್ತದೆ. ಹಾಗೆನ್ನಬಹುದಾದ ಪರೀಕ್ಷೆಯ ವಿಧಾನಶಾಸ್ತ್ರವು, ಅಳವಡಿಸಿಕೊಂಡ ತಂತ್ರಾಂಶ ಅಭಿವೃದ್ಧಿಯ ವಿಧಾನಶಾಸ್ತ್ರದಿಂದ ನೆರವೇರಿಸಲ್ಪಡುತ್ತದೆ.

ವಿಭಿನ್ನ ತಂತ್ರಾಂಶ ಅಭಿವೃದ್ಧಿ ಮಾದರಿಗಳು ಅಭಿವೃದ್ಧಿ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿನ ವಿಭಿನ್ನ ಘಟ್ಟಗಳೆಡೆಗೆ ಪರೀಕ್ಷಾ ಪ್ರಯತ್ನವನ್ನು ಕೇಂದ್ರೀಕರಿಸುತ್ತವೆ. ಅಗೈಲ್‌‌‌ನಂಥ ಹೊಸದಾದ ಅಭಿವೃದ್ಧಿ ಮಾದರಿಗಳು ಅನೇಕವೇಳೆ ಪರೀಕ್ಷಾ ಪ್ರೇರಿತ ಅಭಿವೃದ್ಧಿಯನ್ನು ಅಳವಡಿಸಿಕೊಳ್ಳುತ್ತವೆ ಮತ್ತು ಪರೀಕ್ಷೆಯ ಒಂದು ವರ್ಧಿಸಲ್ಪಟ್ಟ ಅಥವಾ ಅಭಿವೃದ್ಧಿಪಡಿಸಲ್ಪಟ್ಟ ಭಾಗವು ಪರೀಕ್ಷಕರ ಒಂದು ಔಪಚಾರಿಕ ತಂಡಕ್ಕೆ ತಲುಪುವುದಕ್ಕೆ ಮುಂಚಿತವಾಗಿ, ಅದನ್ನು ಅಭಿವರ್ಧಕರ ಅಧೀನದಲ್ಲಿ ಇರಿಸುತ್ತದೆ. ಹೆಚ್ಚು ಸಾಂಪ್ರದಾಯಿಕವಾಗಿರುವ ಮಾದರಿಯೊಂದರಲ್ಲಿ, ಪರೀಕ್ಷಾ ನೆರವೇರಿಕೆಯ ಬಹುಭಾಗವು ಅವಶ್ಯಕತೆಗಳು ವಿಶದೀಕರಿಸಲ್ಪಟ್ಟ ನಂತರ ಹಾಗೂ ಸಂಕೇತಿಸುವ ಪ್ರಕ್ರಿಯೆಯು ಸಂಪೂರ್ಣಗೊಳಿಸಲ್ಪಟ್ಟ ನಂತರ ಸಂಭವಿಸುತ್ತದೆ.

ಸ್ಥೂಲ ನೋಟ[ಬದಲಾಯಿಸಿ]

ತಂತ್ರಾಂಶದೊಳಗಿನ ಎಲ್ಲಾ ದೋಷಗಳನ್ನು ಪರೀಕ್ಷೆಯು ಎಂದಿಗೂ ಸಂಪೂರ್ಣವಾಗಿ ಗುರುತಿಸಲಾರದು. ಅದರ ಬದಲಿಗೆ, ತಪ್ಪಾಗದ ಮಾರ್ಗಸೂಚಿಗಳಿಗೆ ಪ್ರತಿಯಾಗಿ ಉತ್ಪನ್ನದ ಸ್ಥಿತಿಗತಿ ಮತ್ತು ವರ್ತನೆಯನ್ನು ಹೋಲಿಸುವ ಒಂದು ಗುಣದೋಷ ವಿವೇಚನೆ ಅಥವಾ ಹೋಲಿಕೆ ಯನ್ನು ಇದು ಒದಗಿಸುತ್ತದೆ; 'ತಪ್ಪಾಗದ ಮಾರ್ಗಸೂಚಿಗಳು' ಎಂಬುದು, ಸಮಸ್ಯೆಯೊಂದನ್ನು ಗುರುತಿಸಲೆಂದು ಪರಿಣಿತರು ಆಧಾರವಾಗಿಟ್ಟುಕೊಳ್ಳುವ ತತ್ತ್ವಗಳು ಅಥವಾ ಕಾರ್ಯವಿಧಾನಗಳಾಗಿರುತ್ತವೆ. ನಿರ್ದಿಷ್ಟ ವಿವರಣೆಗಳು, ಒಡಂಬಡಿಕೆಗಳು,^[೨] ಹೋಲಿಸಬಹುದಾದ ಉತ್ಪನ್ನಗಳು, ಅದೇ ಉತ್ಪನ್ನದ ಹಿಂದಿನ ಆವೃತ್ತಿಗಳು, ಆಶಿಸಲ್ಪಟ್ಟ ಅಥವಾ ನಿರೀಕ್ಷಿಸಲ್ಪಟ್ಟ ಉದ್ದೇಶದ ಕುರಿತಾದ ತೀರ್ಮಾನಗಳು, ಬಳಕೆದಾರರ ಅಥವಾ ಗ್ರಾಹಕರ ನಿರೀಕ್ಷೆಗಳು, ಸುಸಂಬದ್ಧ ಪ್ರಮಾಣಕಗಳು, ಅನ್ವಯಿಸುವ ಕಾನೂನುಗಳು, ಅಥವಾ ಇತರ ಮಾನದಂಡಗಳನ್ನು ಈ ತಪ್ಪಾಗದ ಮಾರ್ಗಸೂಚಿಗಳು ಒಳಗೊಂಡಿರಬಹುದಾದರೂ ಅವು ಅಷ್ಟಕ್ಕೇ ಸೀಮಿತಗೊಂಡಿಲ್ಲ.

ಪ್ರತಿ ತಂತ್ರಾಂಶ ಉತ್ಪನ್ನವೂ ಒಂದು ಉದ್ದಿಷ್ಟ ಶ್ರೋತೃವರ್ಗವನ್ನು ಹೊಂದಿರುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, ವಿಡಿಯೋ ಆಟದ ತಂತ್ರಾಂಶಕ್ಕೆ ಸಂಬಂಧಿಸಿದಂತಿರುವ ಶ್ರೋತೃವರ್ಗವು ಬ್ಯಾಂಕಿಂಗ್‌ ತಂತ್ರಾಂಶಕ್ಕೆ ಸಂಬಂಧಿಸಿದಂತಿರುವ ಶ್ರೋತೃವರ್ಗಕ್ಕಿಂತ ಸಂಪೂರ್ಣವಾಗಿ ವಿಭಿನ್ನವಾಗಿರುತ್ತದೆ. ಆದ್ದರಿಂದ, ಸಂಸ್ಥೆಯೊಂದು ತಂತ್ರಾಂಶ ಉತ್ಪನ್ನವೊಂದನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುವಾಗ ಅಥವಾ ಅದರಲ್ಲಿ ಹೂಡಿಕೆ ಮಾಡುವಾಗ, ಅದು ತಂತ್ರಾಂಶ ಉತ್ಪನ್ನದ ಕುರಿತಾಗಿ ಒಂದಷ್ಟು ಮೌಲ್ಯ ನಿರ್ಣಯವನ್ನು ಕೈಗೊಳ್ಳುತ್ತದೆ; ಅಂದರೆ, ಸದರಿ ತಂತ್ರಾಂಶ ಉತ್ಪನ್ನವು ಅದರ ಆಂತ್ಯಿಕ-ಬಳಕೆದಾರರಿಗೆ, ಅದರ ಉದ್ದಿಷ್ಟ ಶ್ರೋತೃವರ್ಗಕ್ಕೆ, ಅದರ ಖರೀದಿದಾರರಿಗೆ, ಮತ್ತು ಇತರ ಮಧ್ಯಸ್ಥಗಾರರಿಗೆ ಸ್ವೀಕಾರಯೋಗ್ಯವಾಗುತ್ತದೆಯೇ ಎಂಬುದನ್ನು ಸಂಸ್ಥೆಯು ನಿರ್ಣಯಿಸುತ್ತದೆ. ತಂತ್ರಾಂಶ ಪರೀಕ್ಷೆ ಎಂಬುದು ಈ ಮೌಲ್ಯ ನಿರ್ಧಾರಣೆಯನ್ನು ಕೈಗೊಳ್ಳಲು ಪ್ರಯತ್ನಿಸುವುದರ ಪ್ರಕ್ರಿಯೆಯಾಗಿದೆ.

NIST ವತಿಯಿಂದ 2002ರಲ್ಲಿ ನಡೆಸಲ್ಪಟ್ಟ ಅಧ್ಯಯನವೊಂದು ವರದಿ ಮಾಡಿರುವ ಪ್ರಕಾರ, ತಂತ್ರಾಂಶದ ದೋಷಗಳಿಂದಾಗಿ U.S. ಆರ್ಥಿಕತೆಗೆ ವಾರ್ಷಿಕವಾಗಿ 59.5 ಶತಕೋಟಿ $ನಷ್ಟು ವೆಚ್ಚವಾಗುತ್ತಿದೆ. ಒಂದು ವೇಳೆ ಉತ್ತಮವಾದ ತಂತ್ರಾಂಶ ಪರೀಕ್ಷೆಯನ್ನು ನಿರ್ವಹಿಸಿದ್ದೇ ಆದಲ್ಲಿ, ಈ ವೆಚ್ಚದ ಮೂರನೇ ಒಂದಕ್ಕಿಂತ ಹೆಚ್ಚು ಭಾಗವನ್ನು ತಪ್ಪಿಸಬಹುದಾಗಿದೆ.^[೩]

ಇತಿಹಾಸ[ಬದಲಾಯಿಸಿ]

ದೋಷಗಳ ತೆಗೆದುಹಾಕುವಿಕೆಯನ್ನು ಪರೀಕ್ಷೆಯಿಂದ ಪ್ರತ್ಯೇಕಿಸುವುದರ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಆರಂಭದಲ್ಲಿ ಗ್ಲೆನ್‌ಫೋರ್ಡ್‌ J. ಮೈಯರ್ಸ್‌ ಎಂಬಾತ 1979ರಲ್ಲಿ ಪರಿಚಯಿಸಿದ.^[೪] ಒಡೆಯುವಿಕೆಯ ಪರೀಕ್ಷೆಯ ಮೇಲೆ ಅವನ ಗಮನವಿತ್ತಾದರೂ ("ದೋಷವೊಂದನ್ನು ಕಂಡುಹಿಡಿಯುವ ಪರೀಕ್ಷೆಯೊಂದು ಯಶಸ್ವಿ ಪರೀಕ್ಷೆ ಎನಿಸಿಕೊಳ್ಳುತ್ತದೆ"^[೪]^[೫]), ದೋಷಗಳನ್ನು ತೆಗೆದುಹಾಕುವಿಕೆಯಂಥ ಮೂಲಭೂತ ಅಭಿವೃದ್ಧಿ ಚಟುವಟಿಕೆಗಳನ್ನು ಪರಿಶೀಲನೆಯಿಂದ ಪ್ರತ್ಯೇಕಿಸುವಲ್ಲಿನ ತಂತ್ರಾಂಶ ಎಂಜಿನಿಯರಿಂಗ್‌ ಸಮುದಾಯದ ಬಯಕೆಯನ್ನು ಇದು ವಿಶದಗೊಳಿಸಿತು. 1988ರಲ್ಲಿ ಡೇವ್ ಗೆಲ್‌ಪೆರಿನ್‌ ಮತ್ತು ವಿಲಿಯಂ C. ಹೆಟ್‌ಜೆಲ್‌ ಎಂಬಿಬ್ಬರು ತಂತ್ರಾಂಶ ಪರೀಕ್ಷೆಯಲ್ಲಿನ ಹಂತಗಳು ಮತ್ತು ಗುರಿಗಳನ್ನು ಈ ಕೆಳಕಂಡ ಘಟ್ಟಗಳಲ್ಲಿ ವರ್ಗೀಕರಿಸಿದರು:^[೬]

1956ರವರೆಗೆ - ದೋಷಗಳನ್ನು ತೆಗೆದುಹಾಕುವುದರ ಉದ್ದೇಶಿತ^[೭]
1957–1978 - ಪ್ರಮಾಣೀಕರಣ ಉದ್ದೇಶಿತ^[೮]
1979–1982 - ವಿನಾಶಕ ಉದ್ದೇಶಿತ^[೯]
1983–1987 - ಮೌಲ್ಯಮಾಪನ ಉದ್ದೇಶಿತ^[೧೦]
1988–2000 - ತಡೆಗಟ್ಟುವಿಕೆಯ ಉದ್ದೇಶಿತ^[೧೧]

ತಂತ್ರಾಂಶ ಪರೀಕ್ಷಾ ವಿಷಯಗಳು[ಬದಲಾಯಿಸಿ]

ವ್ಯಾಪ್ತಿ[ಬದಲಾಯಿಸಿ]

ತಂತ್ರಾಂಶದ ವೈಫಲ್ಯತೆಗಳನ್ನು ಪತ್ತೆಹಚ್ಚುವುದು ಪರೀಕ್ಷೆಯ ಒಂದು ಪ್ರಧಾನ ಉದ್ದೇಶವಾಗಿದ್ದು, ಇದರಿಂದಾಗಿ ದೋಷಗಳನ್ನು ಪತ್ತೆಹಚ್ಚಲು ಮತ್ತು ಸರಿಪಡಿಸಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ. ಇದೊಂದು ಯಕಃಶ್ಚಿತ್ತಾಗಿರದ ಅನುಸರಣೆಯಾಗಿದೆ. ಎಲ್ಲಾ ಸ್ಥಿತಿಗತಿಗಳ ಅಡಿಯಲ್ಲಿ ಉತ್ಪನ್ನವೊಂದು ಸೂಕ್ತವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಪರೀಕ್ಷೆಯು ಪ್ರಮಾಣೀಕರಿಸುವುದಿಲ್ಲವಾದರೂ, ನಿರ್ದಿಷ್ಟ ಸ್ಥಿತಿಗತಿಗಳ ಅಡಿಯಲ್ಲಿ ಇದು ಸೂಕ್ತವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವುದಿಲ್ಲ ಎಂಬುದನ್ನಷ್ಟೇ ಇದು ಪ್ರಮಾಣೀಕರಿಸಬಲ್ಲದು.^[೧೨] ತಂತ್ರಾಂಶ ಪರೀಕ್ಷೆಯ ವ್ಯಾಪ್ತಿಯಲ್ಲಿ ಈ ಅಂಶಗಳು ಅನೇಕವೇಳೆ ಸೇರಿರುತ್ತದೆ. ಸಂಕೇತದ ಅವಲೋಕನವಷ್ಟೇ ಅಲ್ಲದೇ, ಹಲವಾರು ಪರಿಸರಗಳು ಮತ್ತು ಸ್ಥಿತಿಗತಿಗಳಲ್ಲಿ ಆ ಸಂಕೇತದ ನೆರವೇರಿಕೆ ಮತ್ತು ಸಂಕೇತದ ಮಗ್ಗುಲುಗಳ ಪರೀಕ್ಷಿಸುವಿಕೆಯು ಇದರಲ್ಲಿ ಸೇರಿರುತ್ತದೆ; ಅಂದರೆ, ಅದು ಏನನ್ನು ಮಾಡಬೇಕೆಂದು ಅಂದುಕೊಳ್ಳಲಾಗಿದೆಯೋ ಅದನ್ನು ಹಾಗೂ ಅದು ಏನನ್ನು ಮಾಡಬೇಕಿದೆಯೋ ಅದನ್ನು ಸಂಕೇತವು ಮಾಡುತ್ತದೆಯೇ ಎಂಬುದನ್ನು ಪರೀಕ್ಷಿಸುವುದು ತಂತ್ರಾಂಶ ಪರೀಕ್ಷೆಯ ವ್ಯಾಪ್ತಿಯಲ್ಲಿ ಸೇರಿರುತ್ತದೆ. ಈಗಿನ ತಂತ್ರಾಂಶ ಅಭಿವೃದ್ಧಿಯ ಸಂಸ್ಕೃತಿಯಲ್ಲಿ, ಪರೀಕ್ಷಾ ಸಂಸ್ಥೆಯೊಂದು ಅಭಿವೃದ್ಧಿ ತಂಡದಿಂದ ಪ್ರತ್ಯೇಕವಾದ ಅಸ್ತಿತ್ವವನ್ನು ಹೊಂದಿರಬಹುದು. ಪರೀಕ್ಷಾ ತಂಡದ ಸದಸ್ಯರಿಗೆ ಸಂಬಂಧಿಸಿದಂತೆ ಹಲವಾರು ಪಾತ್ರಗಳು ಅಸ್ತಿತ್ವದಲ್ಲಿವೆ. ತಂತ್ರಾಂಶ ಪರೀಕ್ಷೆಯಿಂದ ಪಡೆಯಲಾದ ಮಾಹಿತಿಯನ್ನು, ತಂತ್ರಾಂಶವು ಅಭಿವೃದ್ಧಿಪಡಿಸಲ್ಪಡುವ ಪ್ರಕ್ರಿಯೆಯ ಸರಿಪಡಿಸುವಿಕೆಗ ಬಳಸಿಕೊಳ್ಳಬಹುದಾಗಿದೆ.^[೧೩]

ಕಾರ್ಯತ್ಮಕ ಪರೀಕ್ಷೆಗೆ ಎದುರಾಗಿ ಕಾರ್ಯತ್ಮಕವಲ್ಲದ ಪರೀಕ್ಷೆ[ಬದಲಾಯಿಸಿ]

ಸಂಕೇತದ ಒಂದು ನಿರ್ದಿಷ್ಟ ಕ್ರಮ ಅಥವಾ ಕ್ರಿಯೆಯನ್ನು ಪರಿಶೀಲಿಸುವ ಚಟುವಟಿಕೆಗಳಿಗೆ ಕಾರ್ಯತ್ಮಕ ಪರೀಕ್ಷೆ ಎಂದು ಉಲ್ಲೇಖಿಸಲಾಗುತ್ತದೆ. ಸಂಕೇತದ ಅವಶ್ಯಕತೆಗಳ ದಾಖಲೆ ಸಂಗ್ರಹಣದಲ್ಲಿ ಇವು ಸಾಮಾನ್ಯವಾಗಿ ಕಂಡುಬರುತ್ತವೆಯಾದರೂ, ಬಳಕೆಯ ಪ್ರಕರಣಗಳು ಅಥವಾ ಬಳಕೆದಾರರ ಕಥೆಗಳನ್ನು ಆಧರಿಸಿ ಕೆಲವೊಂದು ಅಭಿವೃದ್ಧಿ ವಿಧಾನಶಾಸ್ತ್ರಗಳು ಕಾರ್ಯ ನಿರ್ವಹಿಸುತ್ತವೆ. "ಬಳಕೆದಾರನು ಇದನ್ನು ಮಾಡಬಲ್ಲನೇ" ಅಥವಾ "ಈ ನಿರ್ದಿಷ್ಟ ಲಕ್ಷಣವು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಕೆಲಸ ಮಾಡುವುದೇ" ಎಂಬಂಥ ಪ್ರಶ್ನೆಗಳಿಗೆ ಉತ್ತರ ನೀಡುವ ಪ್ರವೃತ್ತಿಯನ್ನು ಕಾರ್ಯತ್ಮಕ ಪರೀಕ್ಷೆಗಳು ಹೊಂದಿರುತ್ತವೆ.

ಆರೋಹ್ಯತೆ (ಪ್ರಮಾಣ ವೃದ್ಧಿ ಸಾಮರ್ಥ್ಯ) ಅಥವಾ ಭದ್ರತೆಯಂಥ, ಒಂದು ನಿರ್ದಿಷ್ಟ ಕೆಲಸ ಅಥವಾ ಬಳಕೆದಾರರ ಕ್ರಮಕ್ಕೆ ಸಂಬಂಧಪಡದ ತಂತ್ರಾಂಶದ ಮಗ್ಗುಲುಗಳಿಗೆ ಕಾರ್ಯತ್ಮಕವಲ್ಲದ ಪರೀಕ್ಷೆ ಎಂದು ಉಲ್ಲೇಖಿಸಲಾಗುತ್ತದೆ. "ಒಮ್ಮೆಗೆ ಎಷ್ಟು ಜನರು ಲಾಗ್‌ ಇನ್‌ ಆಗಲು ಸಾಧ್ಯ" ಎಂಬಂಥ ಪ್ರಶ್ನೆಗಳಿಗೆ ಉತ್ತರ ನೀಡುವ ಪ್ರವೃತ್ತಿಯನ್ನು ಕಾರ್ಯತ್ಮಕವಲ್ಲದ ಪರೀಕ್ಷೆಗಳು ಹೊಂದಿರುತ್ತವೆ.

ದೋಷಗಳು ಮತ್ತು ವೈಫಲ್ಯತೆಗಳು[ಬದಲಾಯಿಸಿ]

ಸಂಕೇತಿಸುವಿಕೆಯಲ್ಲಿನ ತಪ್ಪುಗಳಿಂದಲೇ ತಂತ್ರಾಂಶದ ಎಲ್ಲಾ ದೋಷಗಳೂ ಉಂಟಾಗುತ್ತವೆ ಎಂದೇನೂ ಅಲ್ಲ. ದುಬಾರಿ ಎಂದು ಪರಿಗಣಿಸಬಹುದಾದ ದೋಷಗಳ ಒಂದು ಸಾಮಾನ್ಯ ಮೂಲವು ಅಂತರಗಳ ಅವಶ್ಯಕತೆಯಿಂದ, ಉದಾಹರಣೆಗೆ ಗುರುತಿಸಲ್ಪಡದ ಅವಶ್ಯಕತೆಗಳಿಂದ, ಉಂಟಾಗುತ್ತದೆ; ಕಾರ್ಯಸೂಚಿ ವಿನ್ಯಾಸಕನು ಕರ್ತವ್ಯಲೋಪದ ತಪ್ಪುಗಳನ್ನು ಎಸಗಲು ಇದು ಕಾರಣವಾಗುತ್ತದೆ.^[೧೪] ಪರೀಕ್ಷಣೀಯತೆ, ಆರೋಹ್ಯತೆ (ಪ್ರಮಾಣವೃದ್ಧಿ ಸಾಮರ್ಥ್ಯ), ಸಮರ್ಥನೀಯತೆ, ಉಪಯುಕ್ತತೆ, ಕಾರ್ಯಕ್ಷಮತೆ, ಮತ್ತು ಭದ್ರತೆಯಂಥ ಕಾರ್ಯತ್ಮಕವಲ್ಲದ ಅವಶ್ಯಕತೆಗಳು, ಅವಶ್ಯಕತೆಗಳ ಅಂತರಗಳ ಒಂದು ಸಾಮಾನ್ಯ ಮೂಲವಾಗಿದೆ.

ಈ ಕೆಳಕಂಡ ಪ್ರಕ್ರಿಯೆಗಳ ಮೂಲಕ ತಂತ್ರಾಂಶ ದೋಷಗಳು ಸಂಭವಿಸುತ್ತವೆ. ಕಾರ್ಯಸೂಚಿಯ ಸಂಯೋಜಕನೋರ್ವನು ಒಂದು ತಪ್ಪನ್ನು (ಪ್ರಮಾದ) ಎಸಗಿದಾಗ, ಅದು ತಂತ್ರಾಂಶದ ಮೂಲ ಸಂಕೇತದಲ್ಲಿನ ಒಂದು ದೋಷಕ್ಕೆ (ನ್ಯೂನತೆ, ಕೊರತೆ) ಕಾರಣವಾಗುತ್ತದೆ. ಒಂದು ವೇಳೆ ಈ ದೋಷವನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಿದ್ದೇ ಆದಲ್ಲಿ, ನಿರ್ದಿಷ್ಟ ಸನ್ನಿವೇಶಗಳಲ್ಲಿ ಯಂತ್ರ ವ್ಯವಸ್ಥೆಯು ತಪ್ಪು ಫಲಿತಾಂಶಗಳನ್ನು ಉಂಟುಮಾಡಿ, ವೈಫಲ್ಯತೆಯೊಂದಕ್ಕೆ ಕಾರಣವಾಗುತ್ತದೆ.^[೧೫] ಎಲ್ಲಾ ದೋಷಗಳೂ ಅವಶ್ಯವಾಗಿ ವೈಫಲ್ಯತೆಗಳಲ್ಲಿ ಪರ್ಯವಸಾನಗೊಳ್ಳುತ್ತವೆ ಎಂದೇನೂ ಇಲ್ಲ. ಉದಾಹರಣೆಗೆ, ಜಡ ಸಂಕೇತದಲ್ಲಿನ ದೋಷಗಳು ಎಂದಿಗೂ ವೈಫಲ್ಯತೆಗಳನ್ನು ಉಂಟುಮಾಡುವುದಿಲ್ಲ. ಪರಿಸರವು ಬದಲಾಯಿಸಲ್ಪಟ್ಟಾಗ ದೋಷವೊಂದು ಒಂದು ವೈಫಲ್ಯತೆಯಾಗಿ ಬದಲಾಗಬಲ್ಲದು. ಒಂದು ಹೊಸ ಯಂತ್ರಾಂಶದ ವೇದಿಕೆಯ ಮೇಲೆ ತಂತ್ರಾಂಶವು ಚಾಲಿಸಲ್ಪಡುತ್ತಿರುವುದು, ಮೂಲ ದತ್ತಾಂಶದಲ್ಲಿನ ಮಾರ್ಪಾಡುಗಳು ಅಥವಾ ವಿಭಿನ್ನ ತಂತ್ರಾಂಶದೊಂದಿಗೆ ಪರಸ್ಪರ ಕಾರ್ಯನಿರ್ವಹಿಸುವಿಕೆ ಇವು ಪರಿಸರದಲ್ಲಿನ ಈ ಬದಲಾವಣೆಗಳ ಉದಾಹರಣೆಗಳಲ್ಲಿ ಸೇರಿವೆ.^[೧೫] ಏಕೈಕ ದೋಷವೊಂದು ಒಂದು ವ್ಯಾಪಕ ಶ್ರೇಣಿಯ ವೈಫಲ್ಯತೆಯ ಲಕ್ಷಣಗಳಿಗೆ ಕಾರಣವಾಗಬಹುದು.

ದೋಷಗಳನ್ನು ಮುಂಚಿತವಾಗಿ ಕಂಡುಹಿಡಿಯುವುದು[ಬದಲಾಯಿಸಿ]

ದೋಷವೊಂದನ್ನು ಆದಷ್ಟು ಬೇಗ ಕಂಡುಕೊಂಡಲ್ಲಿ ಅದನ್ನು ದುರಸ್ತಿಮಾಡುವುದು ಅತ್ಯಂತ ಸುಲಭ ಎಂಬುದು ಸಾಮಾನ್ಯವಾಗಿ ನಂಬಲ್ಪಟ್ಟಿರುವ ಅಂಶವಾಗಿದೆ.^[೧೬] ದೋಷವು ಯಾವ ಘಟ್ಟದಲ್ಲಿ ಕಂಡುಹಿಡಿಯಲ್ಪಟ್ಟಿತು ಎಂಬುದನ್ನು ಅವಲಂಬಿಸಿ, ದೋಷವನ್ನು ದುರಸ್ತಿಮಾಡುವುದರ ವೆಚ್ಚವನ್ನು ಈ ಕೆಳಕಂಡ ಕೋಷ್ಟಕವು ತೋರಿಸುತ್ತದೆ.^[೧೭] ಉದಾಹರಣೆಗೆ, ಒಂದು ವೇಳೆ ಅವಶ್ಯಕತೆಗಳಲ್ಲಿನ ಸಮಸ್ಯೆಯೊಂದು ಬಿಡುಗಡೆಯ-ನಂತರವಷ್ಟೇ ಕಂಡುಬಂದಲ್ಲಿ, ಅವಶ್ಯಕತೆಗಳ ಅವಲೋಕನದಿಂದ ಒಂದು ವೇಳೆ ಅದಾಗಲೇ ಕಂಡುಬಂದಿದ್ದರೆ ಆಗುತ್ತಿದ್ದ ವೆಚ್ಚಗಳಿಗಿಂತ, ಅದನ್ನು ದುರಸ್ತಿಮಾಡಲೆಂದು 10–100 ಪಟ್ಟು ಹೆಚ್ಚು ವೆಚ್ಚವಾಗುತ್ತದೆ.

ದೋಷವೊಂದನ್ನು ದುರಸ್ತಿಮಾಡಲು ಆಗುವ ವೆಚ್ಚ		ಪತ್ತೆಹಚ್ಚಲಾದ ಸಮಯ
ದೋಷವೊಂದನ್ನು ದುರಸ್ತಿಮಾಡಲು ಆಗುವ ವೆಚ್ಚ		ಅವಶ್ಯಕತೆಗಳು	ವಿನ್ಯಾಸ ರಚನೆ	ನಿರ್ಮಾಣ	ಯಂತ್ರ ವ್ಯವಸ್ಥೆಯ ಪರೀಕ್ಷೆ	ಬಿಡುಗಡೆಯ-ನಂತರದ್ದು
ಪರಿಚಯಿಸಲ್ಪಟ್ಟ ಸಮಯ	ಅವಶ್ಯಕತೆಗಳು	1×	3×	5–10×	10×	10–100×
	ವಿನ್ಯಾಸ ರಚನೆ	-	1×	10×	15×	25–100×
	ನಿರ್ಮಾಣ	-	-	1×	10×	10–25×

ಹೊಂದಾಣಿಕೆ[ಬದಲಾಯಿಸಿ]

ತಂತ್ರಾಂಶವು ತೋರಿಸುವ ಹೊಂದಾಣಿಕೆಯ ಒಂದು ಕೊರತೆಯು ಅದರ ವೈಫಲ್ಯತೆಯ (ವಾಸ್ತವವಾದ ಅಥವಾ ಗ್ರಹಿಸಲ್ಪಟ್ಟ) ಒಂದು ಸಾಮಾನ್ಯ ಕಾರಣವಾಗಿದೆ; ಅಂದರೆ, ಇತರ ಅನ್ವಯಿಕೆ ತಂತ್ರಾಂಶ, ಕಾರ್ಯಾಚರಣಾ ವ್ಯವಸ್ಥೆಗಳು (ಅಥವಾ ಕಾರ್ಯಾಚರಣಾ ವ್ಯವಸ್ಥೆಯ ಆವೃತ್ತಿಗಳು, ಇವು ಹಳೆಯದು ಅಥವಾ ಹೊಸದು ಆಗಿರಬಹುದು), ಅಥವಾ ಮೂಲಕ್ಕಿಂತ ಮಹತ್ತರವಾಗಿ ಭಿನ್ನವಾಗಿರುವ ಉದ್ದಿಷ್ಟ ಪರಿಸರಗಳೊಂದಿಗೆ (ಅಂದರೆ, ಡೆಸ್ಕ್‌ಟಾಪ್‌ ಒಂದರ ಮೇಲೆ ಚಾಲಿಸಲ್ಪಡಬೇಕು ಎಂದು ಆಶಿಸಲ್ಪಟ್ಟಿದ್ದರೂ, ಈಗ ಒಂದು ವೆಬ್‌‌ ಅನ್ವಯಿಕೆಯಾಗಿ ಮಾರ್ಪಡಬೇಕಾಗಿರುವುದು ಅಗತ್ಯವಾಗಿರುವ ಮತ್ತು ಒಂದು ವೆಬ್‌‌ ಬ್ರೌಸರ್‌‌ನಲ್ಲಿ ಅಭಿವ್ಯಕ್ತಗೊಳ್ಳಬೇಕಾಗಿರುವ ಒಂದು ಅಂತ್ಯದ ಅಥವಾ GUI ಅನ್ವಯಿಕೆಯಂಥದು) ಹೊಂದಾಣಿಕೆಯಾಗುವಲ್ಲಿ ತಂತ್ರಾಂಶವು ತೋರಿಸುವ ಕೊರತೆಯು ಅದರ ವೈಫಲ್ಯತೆಯ ಒಂದು ಸಾಮಾನ್ಯ ಕಾರಣವಾಗಿರುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, ಹಿಮ್ಮುಖದ ಹೊಂದಾಣಿಕೆಯ ಕೊರತೆಯೊಂದರ ನಿದರ್ಶನದಲ್ಲಿ ಇದು ಸಂಭವಿಸಲು ಸಾಧ್ಯವಿದೆ. ಏಕೆಂದರೆ, ಉದ್ದಿಷ್ಟ ಪರಿಸರದ ವಿನೂತನ ಆವೃತ್ತಿಯ ಮೇಲೆ ಮಾತ್ರವೇ ಕಾರ್ಯಸೂಚಿಯ ಸಂಯೋಜಕರು ತಂತ್ರಾಂಶವನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುತ್ತಾರೆ ಮತ್ತು ಪರೀಕ್ಷಿಸುತ್ತಾರೆ; ಇಂಥದೊಂದು ವಿನೂತನ ಆವೃತ್ತಿಯನ್ನು ಎಲ್ಲಾ ಬಳಕೆದಾರರೂ ಉಪಯೋಗಿಸುತ್ತಿರದೇ ಇರಬಹುದು. ಇದು ಆಶಿಸದ ಪರಿಣಾಮವನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ. ಅಂದರೆ, ಉದ್ದಿಷ್ಟ ಪರಿಸರದ ಹಿಂದಿನ ಆವೃತ್ತಿಗಳ ಮೇಲೆ, ಅಥವಾ ಉದ್ದಿಷ್ಟ ಪರಿಸರದ ಹಿಂದಿನ ಆವೃತ್ತಿಗಳು ಬಳಸಲ್ಪಡುವಲ್ಲಿ ಸಮರ್ಥವಾಗಿದ್ದ ಹಳತಾದ ಯಂತ್ರಾಂಶದ ಮೇಲೆ ವಿನೂತನ ಕೃತಿಯು ಕಾರ್ಯನಿರ್ವಹಿಸದಿರಬಹುದು. ಕೆಲವೊಮ್ಮೆ, ಕಾರ್ಯಾಚರಣಾ ವ್ಯವಸ್ಥೆಯ ಕಾರ್ಯತ್ಮಕತೆಯನ್ನು ಒಂದು ಪ್ರತ್ಯೇಕ ಕಾರ್ಯಸೂಚಿಯ ಮೂಲಮಾನ ಅಥವಾ ಸಂಗ್ರಹಾಗಾರವಾಗಿ ಪೂರ್ವನಿಯಾಮಕವಾಗಿ ಬೇರ್ಪಡಿಸುವ ಮೂಲಕ ಇಂಥ ಸಮಸ್ಯೆಗಳನ್ನು ದುರಸ್ತಿಮಾಡಬಹುದು.

ಪ್ರದಾನ ಸಂಯೋಜನೆಗಳು ಮತ್ತು ಪೂರ್ವಭಾವಿ ಸ್ಥಿತಿಗತಿಗಳು[ಬದಲಾಯಿಸಿ]

ತಂತ್ರಾಂಶ ಪರೀಕ್ಷೆಯೊಂದಿಗಿನ ಒಂದು ಅತ್ಯಂತ ಮೂಲಭೂತವಾದ ಸಮಸ್ಯೆಯೆಂದರೆ, ಪ್ರದಾನಗಳು ಮತ್ತು ಪೂರ್ವಭಾವಿ ಸ್ಥಿತಿಗತಿಗಳ (ಆರಂಭಿಕ ಸ್ಥಿತಿಗತಿ) ಎಲ್ಲಾ ಸಂಯೋಜನೆಗಳ ಅಡಿಯಲ್ಲಿ ಪರೀಕ್ಷೆಯನ್ನು ಕೈಗೊಳ್ಳುವುದು ಕಾರ್ಯಸಾಧ್ಯವಲ್ಲ, ಒಂದು ಸರಳ ಉತ್ಪನ್ನದೊಂದಿಗೂ ಸಹ ಇದು ಸಾಧ್ಯವಿಲ್ಲ.^[೧೨]^[೧೮] ಅಂದರೆ, ತಂತ್ರಾಂಶ ಉತ್ಪನ್ನವೊಂದರಲ್ಲಿನ ದೋಷಗಳ ಸಂಖ್ಯೆಗಳು ಅತ್ಯಂತ ದೊಡ್ಡದಾಗಿರಲು ಸಾಧ್ಯವಿದೆ ಮತ್ತು ವಿರಳವಾಗಿ ಸಂಭವಿಸುವ ದೋಷಗಳನ್ನು ಪರೀಕ್ಷಾ ಹಂತದಲ್ಲಿ ಕಂಡುಹಿಡಿಯುವುದು ಕಷ್ಟಕರ ಎಂಬುದು ಇದರರ್ಥ. ಹೆಚ್ಚು ಅರ್ಥಪೂರ್ಣವಾಗಿ ಹೇಳುವುದಾದರೆ, ಗುಣಮಟ್ಟದ ಕಾರ್ಯತ್ಮಕವಲ್ಲದ ಆಯಾಮಗಳಾದ (ಅದು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸಬೇಕು ಎಂದು ಭಾವಿಸಲ್ಪಡುವುದಕ್ಕೆ ಪ್ರತಿಯಾಗಿ ಅದು ಹೇಗೆ ಇರಬೇಕು ಎಂದು ಭಾವಿಸಲ್ಪಡುವುದು) ಉಪಯುಕ್ತತೆ, ಆರೋಹ್ಯತೆ (ಪ್ರಮಾಣವೃದ್ಧಿ ಸಾಮರ್ಥ್ಯ), ಕಾರ್ಯಕ್ಷಮತೆ, ಹೊಂದಾಣಿಕೆ, ವಿಶ್ವಾಸಾರ್ಹತೆ ಮೊದಲಾದವುಗಳು ಹೆಚ್ಚಿನ ರೀತಿಯಲ್ಲಿ ವಸ್ತುನಿಷ್ಠವಾಗಿರಲು ಸಾಧ್ಯವಿದೆ; ಇದು ಓರ್ವನಿಗೆ ಸಾಕಷ್ಟಿರುವ ಮೌಲ್ಯವನ್ನು ರೂಪಿಸುವ, ಮತ್ತೋರ್ವನಿಗೆ ಅಸಹನೀಯವಾಗಿರಬಹುದಾದ ಅಂಶವಾಗಿದೆ.

ಸ್ಥಾಯೀ ಪರೀಕ್ಷೆಗೆ ಪ್ರತಿಯಾಗಿ ಚಲನಶೀಲ ಪರೀಕ್ಷೆ[ಬದಲಾಯಿಸಿ]

ತಂತ್ರಾಂಶ ಪರೀಕ್ಷೆಗೆ ಸಂಬಂಧಿಸಿದಂತೆ ಅನೇಕ ವಿಧಾನಗಳು ಅಸ್ತಿತ್ವದಲ್ಲಿವೆ. ಅವಲೋಕನಗಳು, ಪರಿಗಣನೆಗಳು, ಅಥವಾ ಪರಿಶೀಲನೆಗಳು ಸ್ಥಾಯೀ ಪರೀಕ್ಷೆ ಎಂಬುದಾಗಿ ಪರಿಗಣಿಸಲ್ಪಟ್ಟರೆ, ಪರೀಕ್ಷಾ ಪ್ರಕರಣಗಳ ಒಂದು ನಿರ್ದಿಷ್ಟ ಸಜ್ಜಿಕೆಯೊಂದಿಗಿನ ಕಾರ್ಯಸೂಚಿತ ಸಂಕೇತವನ್ನು ವಾಸ್ತವವಾಗಿ ಕಾರ್ಯಗತಗೊಳಿಸುವುದನ್ನು ಚಲನಶೀಲ ಪರೀಕ್ಷೆ ಎಂಬುದಾಗಿ ಉಲ್ಲೇಖಿಸಲಾಗುತ್ತದೆ. ಸ್ಥಾಯೀ ಪರೀಕ್ಷೆಯನ್ನು ಬಿಟ್ಟುಬಿಡಬಹುದಾಗಿರುತ್ತದೆ (ಮತ್ತು ದುರದೃಷ್ಟವಶಾತ್‌ ಅನೇಕವೇಳೆ ಬಳಕೆಯಲ್ಲಿದೆ). ಕಾರ್ಯಸೂಚಿಯು ಸ್ವತಃ ಮೊಟ್ಟಮೊದಲ ಬಾರಿಗೆ ಬಳಸಲ್ಪಟ್ಟಾಗ (ಇದನ್ನು ಪರೀಕ್ಷಾ ಘಟ್ಟದ ಆರಂಭ ಎಂಬುದಾಗಿ ಸಾಮಾನ್ಯವಾಗಿ ಪರಿಗಣಿಸಲಾಗುತ್ತದೆ) ಚಲನಶೀಲ ಪರೀಕ್ಷೆಯು ಸಂಭವಿಸುತ್ತದೆ. ಸಂಕೇತದ ನಿರ್ದಿಷ್ಟ ವಿಭಾಗಗಳನ್ನು (ಮೂಲಮಾನಗಳು ಅಥವಾ ಪ್ರತ್ಯೇಕವಾದ ಕಾರ್ಯಗಳು) ಪರೀಕ್ಷಿಸುವ ದೃಷ್ಟಿಯಿಂದ, ಕಾರ್ಯಸೂಚಿಯು 100% ಸಂಪೂರ್ಣವಾಗುವುದಕ್ಕೆ ಮುಂಚಿತವಾಗಿ ಚಲನಶೀಲ ಪರೀಕ್ಷೆಯು ಪ್ರಾರಂಭವಾಗಬಹುದಾಗಿದೆ. ಉಳಿಕೆಗಳು/ಚಾಲಕ ಭಾಗಗಳನ್ನು ಬಳಸುವುದು ಅಥವಾ ದೋಷಗಳನ್ನು ತೆಗೆದುಹಾಕುವ ಪರಿಸರವೊಂದರಿಂದ ನೆರವೇರಿಕೆಯನ್ನು ಕೈಗೊಳ್ಳುವುದು ಇದಕ್ಕೆ ಸಂಬಂಧಿಸಿದ ವಿಶಿಷ್ಟ ಕೌಶಲಗಳಾಗಿವೆ. ಉದಾಹರಣೆಗೆ, ಹರವುಹಾಳೆ (ಸ್ಪ್ರೆಡ್‌ಶೀಟ್‌) ಕಾರ್ಯಸೂಚಿಗಳು ತಮ್ಮದೇ ಆದ ಸ್ವಭಾವದ ಕಾರಣದಿಂದಾಗಿ, ಪ್ರಭಾವ ಬೀರುವ ರೀತಿಯಲ್ಲಿ ("ಹಾರಾಡುತ್ತ") ಒಂದು ದೊಡ್ಡದಾದ ವ್ಯಾಪ್ತಿಗೆ ಪರೀಕ್ಷಿಸಲ್ಪಡುತ್ತವೆ ಹಾಗೂ ಪ್ರತಿ ಲೆಕ್ಕಾಚಾರ ಅಥವಾ ಪಠ್ಯದ ಕುಶಲ ಬಳಕೆಯ ನಂತರ ಫಲಿತಾಂಶಗಳು ತಕ್ಷಣದಲ್ಲಿ ಪ್ರದರ್ಶಿಸಲ್ಪಡುತ್ತವೆ.

ತಂತ್ರಾಂಶ ಪರಿಶೀಲನೆ ಮತ್ತು ಕ್ರಮಬದ್ಧಗೊಳಿಸುವಿಕೆ[ಬದಲಾಯಿಸಿ]

ಪರಿಶೀಲನೆ ಮತ್ತು ಕ್ರಮಬದ್ಧಗೊಳಿಸುವಿಕೆಯೊಂದಿಗಿನ ಸಹಯೋಗದಲ್ಲಿ ತಂತ್ರಾಂಶ ಪರೀಕ್ಷೆಯನ್ನು ಬಳಸಲಾಗುತ್ತದೆ:^[೧೯]

ಪರಿಶೀಲನೆ: ನಾವು ತಂತ್ರಾಂಶವನ್ನು ಸರಿಯಾಗಿ ರೂಪಿಸಿದ್ದೇವೆಯೇ? (ಅಂದರೆ, ಅದು ನಿರ್ದಿಷ್ಟ ವಿವರಣೆಗೆ ಹೊಂದಿಕೊಳ್ಳುವಂತಿದೆಯೇ).
ಕ್ರಮಬದ್ಧಗೊಳಿಸುವಿಕೆ: ನಾವು ಸರಿಯಾದ ತಂತ್ರಾಂಶವನ್ನು ರೂಪಿಸಿದ್ದೇವೆಯೇ? (ಅಂದರೆ, ಇದು ಗ್ರಾಹಕ ಬಯಸುವ ರೀತಿಯಲ್ಲಿದೆಯೇ).

ಪರಿಶೀಲನೆ ಮತ್ತು ಕ್ರಮಬದ್ಧಗೊಳಿಸುವಿಕೆ ಎಂಬ ಶಬ್ದಗಳನ್ನು ಉದ್ಯಮದಲ್ಲಿ ಸಾಮಾನ್ಯವಾಗಿ ವಿನಿಮಯಸಾಧ್ಯವಾಗಿ ಬಳಸಲಾಗುತ್ತದೆ; ಈ ಎರಡು ಶಬ್ದಗಳು ತಪ್ಪಾಗಿ ವ್ಯಾಖ್ಯಾನಿಸಲ್ಪಟ್ಟಿರುವುದನ್ನೂ ಸಹ ನಾವು ಸಾಮಾನ್ಯವಾಗಿ ಕಾಣಬಹುದಾಗಿದೆ. ತಂತ್ರಾಂಶ ಎಂಜಿನಿಯರಿಂಗ್‌ ಪರಿಭಾಷೆಗೆ ಸಂಬಂಧಿಸಿದಂತಿರುವ IEEEನ ಪ್ರಮಾಣಕ ಶಬ್ದಸಂಗ್ರಹದ ಅನುಸಾರ:

ಪರಿಶೀಲನೆ ಎಂಬುದು ಒಂದು ಯಂತ್ರ ವ್ಯವಸ್ಥೆಯ ಅಥವಾ ಅಂಗಭಾಗದ ಮೌಲ್ಯನಿರ್ಣಯಿಸುವ ಪ್ರಕ್ರಿಯೆಯಾಗಿದ್ದು, ಅಭಿವೃದ್ಧಿಯ ಒಂದು ನಿರ್ದಿಷ್ಟ ಹಂತದ ಉತ್ಪನ್ನಗಳು ಆ ಹಂತದ ಆರಂಭದಲ್ಲಿ ವಿಧಿಸಲ್ಪಟ್ಟ ಷರತ್ತುಗಳನ್ನು ಈಡೇರಿಸುತ್ತವೆಯೇ ಎಂಬುದನ್ನು ನಿರ್ಣಯಿಸಲು ಅದನ್ನು ಬಳಸಲಾಗುತ್ತದೆ.

ಕ್ರಮಬದ್ಧಗೊಳಿಸುವಿಕೆ ಎಂಬುದು ಅಭಿವೃದ್ಧಿ ಪ್ರಕ್ರಿಯೆಯ ಅವಧಿಯಲ್ಲಿ ಅಥವಾ ಅದರ ಅಂತ್ಯದಲ್ಲಿ ನಿರ್ವಹಿಸಲಾಗುವ ಒಂದು ಯಂತ್ರ ವ್ಯವಸ್ಥೆಯ ಅಥವಾ ಅಂಗಭಾಗದ ಮೌಲ್ಯನಿರ್ಣಯದ ಪ್ರಕ್ರಿಯೆಯಾಗಿದ್ದು, ನಿರ್ದಿಷ್ಟಪಡಿಸಿದ ಅವಶ್ಯಕತೆಗಳನ್ನು ಅದು ಈಡೇರಿಸುತ್ತದೆಯೇ ಎಂಬುದನ್ನು ನಿರ್ಣಯಿಸಲು ಸದರಿ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಬಳಸಲಾಗುತ್ತದೆ.

ತಂತ್ರಾಂಶ ಪರೀಕ್ಷಾ ತಂಡ[ಬದಲಾಯಿಸಿ]

ತಂತ್ರಾಂಶ ಪರೀಕ್ಷೆಯನ್ನು ತಂತ್ರಾಂಶ ಪರೀಕ್ಷಕರ ವತಿಯಿಂದ ನಡೆಸಬಹುದಾಗಿರುತ್ತದೆ. 1980ರ ದಶಕದವರೆಗೂ "ತಂತ್ರಾಂಶ ಪರೀಕ್ಷಕ" ಎಂಬ ಶಬ್ದವನ್ನು ಸಾರ್ವತ್ರಿಕವಾಗಿ ಬಳಸಲಾಗುತ್ತಿತ್ತಾದರೂ, ನಂತರದ ಅವಧಿಯಲ್ಲಿ ಇದನ್ನೂ ಸಹ ಒಂದು ಪ್ರತ್ಯೇಕ ವೃತ್ತಿಯಾಗಿ ನೋಡುವ ಪರಿಪಾಠವು ಶುರುವಾಯಿತು. ತಂತ್ರಾಂಶ ಪರೀಕ್ಷೆಯಲ್ಲಿನ^[೨೦] ಅವಧಿಗಳು ಮತ್ತು ವಿಭಿನ್ನ ಗುರಿಗಳಿಗೆ ಸಂಬಂಧಿಸಿದಂತೆ ವಿಭಿನ್ನ ಪಾತ್ರಗಳು ಅಸ್ತಿತ್ವವನ್ನು ಕಂಡುಕೊಂಡಿವೆ. ಅವುಗಳೆಂದರೆ: ವ್ಯವಸ್ಥಾಪಕ , ಪರೀಕ್ಷಾ ಮುಖ್ಯಸ್ಥ , ಪರೀಕ್ಷಾ ವಿನ್ಯಾಸಕ , ಪರೀಕ್ಷಕ , ಸ್ವಯಂಚಾಲನೆಯ ಅಭಿವರ್ಧಕ , ಮತ್ತು ಪರೀಕ್ಷಾ ಕಾರ್ಯನಿರ್ವಾಹಕ .

ತಂತ್ರಾಂಶದ ಗುಣಮಟ್ಟದ ಖಾತರಿ (ಸಾಫ್ಟ್‌‌ವೇರ್‌‌ ಕ್ವಾಲಿಟಿ ಅಶ್ಯೂರೆನ್ಸ್‌‌-SQA)[ಬದಲಾಯಿಸಿ]

ತಂತ್ರಾಂಶ ಪರೀಕ್ಷೆಯು ವಿವಾದಾತ್ಮಕವಾಗಿದ್ದರೂ ಸಹ, ತಂತ್ರಾಂಶದ ಗುಣಮಟ್ಟದ ಖಾತರಿ (SQA) ಪ್ರಕ್ರಿಯೆಯ ಒಂದು ಪ್ರಮುಖ ಭಾಗವಾಗಿ ಅದನ್ನು ಪರಿಗಣಿಸಬಹುದಾಗಿದೆ.^[೧೨] SQAಯಲ್ಲಿ, ತಂತ್ರಾಂಶ ಸಂಸ್ಕರಣದ ಪರಿಣತರು ಮತ್ತು ಶ್ರಾವಕರು, ತಂತ್ರಾಂಶ ಮತ್ತು ಅದರ ಅಭಿವೃದ್ಧಿಯ ಕುರಿತಾದ ಒಂದು ವಿಶಾಲವಾದ ನೋಟವನ್ನು ಕಾಣಲು ಅವಕಾಶವಿರುತ್ತದೆ. ವಿತರಿಸಲ್ಪಟ್ಟ ತಂತ್ರಾಂಶದಲ್ಲಿ ಕಂಡುಬರಬಹುದಾದ, ನ್ಯೂನತೆಯ ಪ್ರಮಾಣ (ಡಿಫೆಕ್ಟ್‌ ರೇಟ್‌) ಎಂದು ಕರೆಯಲ್ಪಡುವ ದೋಷಗಳ ಮೊತ್ತವನ್ನು ತಗ್ಗಿಸುವ ಸಲುವಾಗಿ, ಅವರು ತಂತ್ರಾಂಶ ಎಂಜಿನಿಯರಿಂಗ್‌ ಪ್ರಕ್ರಿಯೆಯನ್ನೇ ಪರೀಕ್ಷಿಸುತ್ತಾರೆ ಮತ್ತು ಬದಲಿಸುತ್ತಾರೆ.

ಒಂದು "ಸ್ವೀಕಾರಯೋಗ್ಯ ದೋಷದ ಪ್ರಮಾಣ" ಎಂಬುದು ತಂತ್ರಾಂಶದ ಸ್ವರೂಪದ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿರುತ್ತದೆ; ಹಾರಾಟದ ಅನುಕರಣಕಾರಕ ವಿಡಿಯೋ ಆಟವೊಂದು, ಒಂದು ವಾಸ್ತವಿಕ ವಿಮಾನಕ್ಕೆ ಸಂಬಂಧಿಸಿದ ತಂತ್ರಾಂಶಕ್ಕಿಂತಲೂ ಸಾಕಷ್ಟು ಹೆಚ್ಚಿನ ಮಟ್ಟದಲ್ಲಿರುವ ದೋಷ ಸಹಿಷ್ಣುತೆಯನ್ನು ಹೊಂದಿರುತ್ತದೆ.

SQAನೊಂದಿಗೆ ನಿಕಟ ಕೊಂಡಿಗಳು ಅಸ್ತಿತ್ವದಲ್ಲಿವೆಯಾದರೂ, ಪರೀಕ್ಷಾ ವಿಭಾಗಗಳು ಅನೇಕ ವೇಳೆ ಸ್ವತಂತ್ರವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ ಮತ್ತು ಕೆಲವೊಂದು ಕಂಪನಿಗಳಲ್ಲಿ ಯಾವುದೇ ತೆರನಾದ SQA ಚಟುವಟಿಕೆಯು ಇಲ್ಲದಿರಲೂ ಸಾಧ್ಯವಿದೆ.

ತಂತ್ರಾಂಶ ಪರೀಕ್ಷೆ ಎಂಬುದು ತಂತ್ರಾಂಶದಲ್ಲಿನ ದೋಷಗಳನ್ನು ಪತ್ತೆಹಚ್ಚಲೆಂಬ ಉದ್ದೇಶದೊಂದಿಗೆ ಕೈಗೊಳ್ಳಲಾಗುವ ಒಂದು ಕಾರ್ಯಭಾರವಾಗಿದ್ದು, ಇದನ್ನು ನೆರವೇರಿಸುವುದಕ್ಕಾಗಿ ಕಂಪ್ಯೂಟರ್‌ ಕಾರ್ಯಸೂಚಿಯ ನಿರೀಕ್ಷಿಸಲ್ಪಟ್ಟ ಫಲಿತಾಂಶಗಳನ್ನು ದತ್ತಮಾಹಿತಿಗಳ ಒಂದು ನಿರ್ದಿಷ್ಟ ಸಜ್ಜಿಕೆಗೆ ಮೀಸಲಾದ ಅದರ ವಾಸ್ತವಿಕ ಫಲಿತಾಂಶಗಳೊಂದಿಗೆ ಹೋಲಿಸಿ ವ್ಯತ್ಯಾಸವನ್ನು ಎತ್ತಿತೋರಿಸಲಾಗುತ್ತದೆ. ಇದಕ್ಕೆ ತದ್ವಿರುದ್ಧವಾಗಿ, QA (ಗುಣಮಟ್ಟ ಖಾತರಿ) ಎಂಬುದು ಕಾರ್ಯನೀತಿಗಳು ಮತ್ತು ಕ್ರಮವಿಧಾನಗಳ ಅನುಷ್ಠಾನವಾಗಿದ್ದು, ಮೊದಲ ಸ್ಥಳದಲ್ಲಿಯೇ ದೋಷಗಳು ಸಂಭವಿಸದಂತೆ ತಡೆಗಟ್ಟುವ ಉದ್ದೇಶದಿಂದ ಅದನ್ನು ಕೈಗೊಳ್ಳಲಾಗುತ್ತದೆ.

ಪರೀಕ್ಷಾ ವಿಧಾನಗಳು[ಬದಲಾಯಿಸಿ]

ಪೆಟ್ಟಿಗೆಯ ವಿಧಾನ[ಬದಲಾಯಿಸಿ]

ತಂತ್ರಾಂಶ ಪರೀಕ್ಷಾ ವಿಧಾನಗಳನ್ನು ಬಿಳಿ-ಪೆಟ್ಟಿಗೆ ಪರೀಕ್ಷೆ ಮತ್ತು ಕಪ್ಪು-ಪೆಟ್ಟಿಗೆ ಪರೀಕ್ಷೆ ಎಂಬುದಾಗಿ ಸಾಂಪ್ರದಾಯಿಕವಾಗಿ ವಿಭಾಗಿಸಲಾಗಿದೆ. ಪರೀಕ್ಷಾ ಎಂಜಿನಿಯರ್‌ ಓರ್ವನು ಪರೀಕ್ಷಾ ಪ್ರಕರಣಗಳನ್ನು ವಿನ್ಯಾಸಗೊಳಿಸುವಾಗ ತಳೆಯುವ ನಿಲುವನ್ನು ವಿವರಿಸಲೆಂದು ಈ ಎರಡು ವಿಧಾನಗಳನ್ನು ಬಳಸಲಾಗುತ್ತದೆ.

ಬಿಳಿ-ಪೆಟ್ಟಿಗೆ ಪರೀಕ್ಷೆ[ಬದಲಾಯಿಸಿ]

ಆಂತರಿಕ ದತ್ತಾಂಶ ರಚನೆಗಳು ಮತ್ತು ಗಣನೆ ಪದ್ಧತಿಗಳಷ್ಟೇ ಅಲ್ಲದೇ ಇವನ್ನು ಅನುಷ್ಠಾನಗೊಳಿಸುವ ಸಂಕೇತದೊಂದಿಗೆ ಪರೀಕ್ಷಕನು ಸಂಪರ್ಕ ಸಾಧಿಸಿದಾಗ ಅದು ಬಿಳಿ ಪೆಟ್ಟಿಗೆ ಪರೀಕ್ಷೆ ಎನಿಸಿಕೊಳ್ಳುತ್ತದೆ.

ಬಿಳಿ-ಪೆಟ್ಟಿಗೆ ಪರೀಕ್ಷೆಯ ಬಗೆಗಳು

ಈ ಕೆಳಕಂಡ ಬಗೆಯ ಬಿಳಿ-ಪೆಟ್ಟಿಗೆ ಪರೀಕ್ಷೆಗಳು ಅಸ್ತಿತ್ವದಲ್ಲಿವೆ:

API ಪರೀಕ್ಷೆ (ಅಪ್ಲಿಕೇಷನ್‌ ಪ್ರೋಗ್ರಾಮಿಂಗ್‌ ಇಂಟರ್‌ಫೇಸ್‌) - ಸಾರ್ವಜನಿಕ ಮತ್ತು ಖಾಸಗಿ APIಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಅನ್ವಯಿಕೆಯನ್ನು ಪರೀಕ್ಷಿಸುವಿಕೆ
ಸಂಕೇತ ವ್ಯಾಪ್ತಿ - ಸಂಕೇತವ್ಯಾಪ್ತಿಯ ಕೆಲವೊಂದು ಮಾನದಂಡಗಳನ್ನು ಪೂರೈಸಲೆಂದು ಪರೀಕ್ಷೆಗಳನ್ನು ಸೃಷ್ಟಿಸುವಿಕೆ (ಉದಾಹರಣೆಗೆ, ಕಾರ್ಯಸೂಚಿಯಲ್ಲಿನ ಎಲ್ಲಾ ನಿರೂಪಣೆಗಳು ಕನಿಷ್ಟಪಕ್ಷ ಒಂದು ಸಲ ಕಾರ್ಯಗತಗೊಳಿಸಲ್ಪಡುವಂತಾಗಲು, ಪರೀಕ್ಷಾ ವಿನ್ಯಾಸಕನು ಪರೀಕ್ಷೆಗಳನ್ನು ಸೃಷ್ಟಿಸಬಲ್ಲ)
ದೋಷದ ಒಳಹೊಗಿಸುವಿಕೆಯ ವಿಧಾನಗಳು - ಸಂಕೇತದ ಮಾರ್ಗಗಳನ್ನು ಪರೀಕ್ಷಿಸಲೆಂದು ದೋಷಗಳನ್ನು ಪರಿಚಯಿಸುವ ಮೂಲಕ ಪರೀಕ್ಷೆಯೊಂದರ ವ್ಯಾಪ್ತಿಯನ್ನು ಸುಧಾರಿಸುವಿಕೆ
ರೂಪಾಂತರ ಪರೀಕ್ಷಾ ವಿಧಾನಗಳು
ಸ್ಥಾಯೀ ಪರೀಕ್ಷೆ - ಬಿಳಿ-ಪೆಟ್ಟಿಗೆ ಪರೀಕ್ಷೆಯು ಎಲ್ಲಾ ಸ್ಥಾಯೀ ಪರೀಕ್ಷೆಯನ್ನು ಒಳಗೊಳ್ಳುತ್ತದೆ

ಪರೀಕ್ಷೆಯ ವ್ಯಾಪ್ತಿ: ಕಪ್ಪು-ಪೆಟ್ಟಿಗೆ ಪರೀಕ್ಷಾ ವಿಧಾನಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಸೃಷ್ಟಿಸಲ್ಪಟ್ಟ ಪರೀಕ್ಷಾ ಮಾಲಿಕೆಯೊಂದರ ಸಂಪೂರ್ಣತೆಯನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡಲೂ ಸಹ ಬಿಳಿ-ಪೆಟ್ಟಿಗೆ ಪರೀಕ್ಷಾ ವಿಧಾನಗಳನ್ನು ಬಳಸಬಹುದು. ಅಪರೂಪವಾಗಿ ಪರೀಕ್ಷಿಸಲ್ಪಟ್ಟ ಯಂತ್ರ ವ್ಯವಸ್ಥೆಯೊಂದರ ಭಾಗಗಳನ್ನು ತಂತ್ರಾಂಶ ತಂಡವು ಪರೀಕ್ಷಿಸುವುದಕ್ಕೆ ಇದು ಅವಕಾಶ ಮಾಡಿಕೊಡುತ್ತದೆ ಮತ್ತು ಅತ್ಯಂತ ಪ್ರಮುಖವಾದ ಕಾರ್ಯ ಘಟ್ಟಗಳು ಪರೀಕ್ಷಿಸಲ್ಪಟ್ಟಿವೆ ಎಂಬುದನ್ನು ಇದು ಖಾತ್ರಿಪಡಿಸುತ್ತದೆ.^[೨೧]

ಸಂಕೇತವ್ಯಾಪ್ತಿಯ ಎರಡು ಸಾಮಾನ್ಯ ಸ್ವರೂಪಗಳೆಂದರೆ:

ನೆರವೇರಿಸಲ್ಪಟ್ಟ ಕಾರ್ಯಗಳ ಕುರಿತಾಗಿ ವರದಿ ಸಲ್ಲಿಸುವ ಕಾರ್ಯಚಟುವಟಿಕೆಯ ವ್ಯಾಪ್ತಿ ,
ಪರೀಕ್ಷೆಯನ್ನು ಸಂಪೂರ್ಣಗೊಳಿಸಲೆಂದು ಕಾರ್ಯಗತಗೊಳಿಸಲ್ಪಟ್ಟ ಸಾಲುಗಳ ಸಂಖ್ಯೆಯ ಕುರಿತಾಗಿ ವರದಿ ಸಲ್ಲಿಸುವ ನಿರೂಪಣೆಯ ವ್ಯಾಪ್ತಿ

ಒಂದು ಶೇಕಡಾವಾರು ಸ್ವರೂಪದಲ್ಲಿ ಅಳೆಯಲ್ಪಡುವ ಸಂಕೇತ ವ್ಯಾಪ್ತಿಯ ಅಳತೆಯೊಂದನ್ನು ಅವೆರಡೂ ಹಿಂದಿರುಗಿಸುತ್ತವೆ.

ಕಪ್ಪು-ಪೆಟ್ಟಿಗೆ ಪರೀಕ್ಷೆ[ಬದಲಾಯಿಸಿ]

ಕಪ್ಪು-ಪೆಟ್ಟಿಗೆ ಪರೀಕ್ಷೆಯು ಆಂತರಿಕ ಅನುಷ್ಠಾನದ ಯಾವುದೇ ಅರಿವಿಲ್ಲದೆಯೇ ತಂತ್ರಾಂಶವನ್ನು ಒಂದು "ಕಪ್ಪು-ಪೆಟ್ಟಿಗೆ" ಎಂಬುದಾಗಿ ಪರಿಗಣಿಸುತ್ತದೆ. ಕಪ್ಪು-ಪೆಟ್ಟಿಗೆ ಪರೀಕ್ಷಾ ವಿಧಾನಗಳಲ್ಲಿ ಇವೆಲ್ಲವೂ ಸೇರಿವೆ: ಸಮಾನಸ್ಥಿತಿಯ ಪ್ರತ್ಯೇಕಿಸುವಿಕೆ, ಎಲ್ಲೆಗೆರೆಯ ಮೌಲ್ಯ ವಿಶ್ಲೇಷಣೆ, ಎಲ್ಲಾ-ಜೋಡಿಗಳ ಪರೀಕ್ಷೆ, ಜಾಳು ಪರೀಕ್ಷೆ, ಮಾದರಿ-ಆಧರಿತ ಪರೀಕ್ಷೆ, ಪತ್ತೆಹಚ್ಚಲು ಸಾಧ್ಯವಿರುವಿಕೆಯ ಜಾಲ, ಪರಿಶೋಧನಾತ್ಮಕ ಪರೀಕ್ಷೆ ಮತ್ತು ನಿರ್ದಿಷ್ಟ ವಿವರಣೆ-ಆಧರಿತ ಪರೀಕ್ಷೆ.

ನಿರ್ದಿಷ್ಟ ವಿವರಣೆ-ಆಧರಿತ ಪರೀಕ್ಷೆ : ಅನ್ವಯಿಸುವ ಅವಶ್ಯಕತೆಗಳ ಅನುಸಾರ ತಂತ್ರಾಂಶದ ಕಾರ್ಯತ್ಮಕತೆಯನ್ನು ಪರೀಕ್ಷಿಸುವುದರೆಡೆಗೆ ನಿರ್ದಿಷ್ಟ ವಿವರಣೆ-ಆಧರಿತ ಪರೀಕ್ಷೆಯು ಗುರಿಯಿರಿಸುತ್ತದೆ.^[೨೨] ಈ ರೀತಿಯಾಗಿ, ಪರೀಕ್ಷಕನು ಪರೀಕ್ಷಾ ವಸ್ತುವಿನೊಳಗೆ ದತ್ತಾಂಶವನ್ನು ಪ್ರದಾನ ಮಾಡುತ್ತಾನೆ (ಒದಗಿಸುತ್ತಾನೆ) ಮತ್ತು ಅದರಿಂದ ಬರುವ ಫಲಿತ ಮಾಹಿತಿಯನ್ನಷ್ಟೇ ನೋಡುತ್ತಾನೆ. ಈ ಮಟ್ಟದ ಪರೀಕ್ಷೆಯು ನಡೆಯಬೇಕೆಂದರೆ, ಸುಪರಿಷ್ಕೃತ ಪರೀಕ್ಷಾ ಪ್ರಕರಣಗಳನ್ನು ಪರೀಕ್ಷಕನಿಗೆ ಒದಗಿಸುವುದು ಸಾಮಾನ್ಯವಾಗಿ ಅಗತ್ಯವಾಗಿರುತ್ತದೆ. ಒಂದು ನಿರ್ದಿಷ್ಟ ದತ್ತಮಾಹಿತಿಗೆ ಸಂಬಂಧಿಸಿದಂತೆ ಫಲಿತ ಮೌಲ್ಯ (ಅಥವಾ ವರ್ತನೆಯು) ಪರೀಕ್ಷಾ ನಿದರ್ಶನದಲ್ಲಿ ನಿರ್ದಿಷ್ಟಪಡಿಸಿದ ನಿರೀಕ್ಷಿತ ಮೌಲ್ಯದ ರೀತಿಯಲ್ಲಿಯೇ "ಇದೆಯೇ" ಅಥವಾ "ಇಲ್ಲವೇ" ಎಂಬುದನ್ನು ನಂತರದಲ್ಲಿ ಪರೀಕ್ಷಕನು ಸರಳವಾಗಿ ಪರಿಶೀಲಿಸುವುದು ಸಾಧ್ಯವಾಗುತ್ತದೆ.

ನಿರ್ದಿಷ್ಟ ವಿವರಣೆ-ಆಧರಿತ ಪರೀಕ್ಷೆಯು ಅವಶ್ಯಕವಾಗಿದೆಯಾದರೂ, ಇದು ನಿರ್ದಿಷ್ಟ ಅಪಾಯಗಳಿಗೆ ಪ್ರತಿಯಾಗಿ ರಕ್ಷಿಸುವಷ್ಟು ಸಮರ್ಥವಾಗಿರುವುದಿಲ್ಲ.^[೨೩]

ಪ್ರಯೋಜನಗಳು ಮತ್ತು ಅನನುಕೂಲಗಳು : ಕಪ್ಪು-ಪೆಟ್ಟಿಗೆ ಪರೀಕ್ಷಕನು ಸಂಕೇತದೊಂದಿಗೆ ಯಾವುದೇ ಕಟ್ಟುಪಾಡುಗಳನ್ನು (ಬಂಧನಗಳನ್ನು) ಹೊಂದಿರುವುದಿಲ್ಲ, ಮತ್ತು ಓರ್ವ ಪರೀಕ್ಷಕನ ಗ್ರಹಿಕೆಯು ಅತ್ಯಂತ ಸರಳವಾಗಿರುತ್ತದೆ: ಸಂಕೇತವೊಂದು ದೋಷಗಳನ್ನು ಖಂಡಿತಾ ಹೊಂದಿರಬೇಕು ಎಂಬುದೇ ಆ ಗ್ರಹಿಕೆ. ಕಾರ್ಯಸೂಚಿಯ ಸಂಯೋಜಕರು ಕಂಡುಕೊಳ್ಳಲಾರದ ದೋಷಗಳನ್ನು, "ಕೇಳಿದಾಗಲೇ ನೀವು ಸ್ವೀಕರಿಸಲು ಸಾಧ್ಯ" ಎಂಬ ತತ್ತ್ವವನ್ನು ಬಳಸಿಕೊಂಡು ಕಪ್ಪು-ಪೆಟ್ಟಿಗೆ ಪರೀಕ್ಷಕರು ಕಂಡುಕೊಳ್ಳುತ್ತಾರೆ. ಮತ್ತೊಂದೆಡೆ, "ಒಂದು ಮಿಂಚುಬೆಳಕಿನ ನೆರವಿಲ್ಲದೆಯೇ ಒಂದು ಕತ್ತಲೆಯ ಚಕ್ರವ್ಯೂಹದಲ್ಲಿ ಮಾಡುವ ಒಂದು ನಡಿಗೆಯಂತೆ" ಎಂಬುದಾಗಿ ಕಪ್ಪು-ಪೆಟ್ಟಿಗೆ ಪರೀಕ್ಷೆಯು ಉಲ್ಲೇಖಿಸಲ್ಪಟ್ಟಿದೆ; ಏಕೆಂದರೆ, ಪರೀಕ್ಷಿಸಲ್ಪಡುತ್ತಿರುವ ತಂತ್ರಾಂಶವು ವಾಸ್ತವವಾಗಿ ಹೇಗೆ ರೂಪಿಸಲ್ಪಟ್ಟಿತ್ತು ಎಂಬುದು ಪರೀಕ್ಷಕನಿಗೆ ಗೊತ್ತಿರುವುದಿಲ್ಲ. ಇದರ ಪರಿಣಾಮವಾಗಿ, ಕೆಲವೊಂದು ಸನ್ನಿವೇಶಗಳು ಉದ್ಭವಿಸುತ್ತವೆ: ಅಂದರೆ, ಕೇವಲ ಏಕೈಕ ಪರೀಕ್ಷಾ ನಿದರ್ಶನದಿಂದ ಪರೀಕ್ಷಿಸಲ್ಪಡಬಹುದಾಗಿದ್ದ ಅಂಶವೊಂದನ್ನು ತಪಾಸಿಸಲು ಓರ್ವ ಪರೀಕ್ಷಕನು ಅನೇಕ ಪರೀಕ್ಷಾ ಪ್ರಕರಣಗಳನ್ನು ಬರೆಯುವ, ಮತ್ತು/ಅಥವಾ ಹಿಂತುದಿಯ ಕೆಲವೊಂದು ಭಾಗಗಳು ಪರೀಕ್ಷಿಸಲ್ಪಡದೆಯೇ ಹೋಗುವಂಥ ಸನ್ನಿವೇಶಗಳು ಉದ್ಭವಿಸುತ್ತವೆ.

ಆದ್ದರಿಂದ, ಕಪ್ಪು-ಪೆಟ್ಟಿಗೆ ಪರೀಕ್ಷೆಯು ಒಂದೆಡೆ "ಒಂದು ಸಂಬಂಧಿಸಿರದ ಅಭಿಪ್ರಾಯ"ದ ಪ್ರಯೋಜನವನ್ನು ಹೊಂದಿದ್ದರೆ, ಮತ್ತೊಂದೆಡೆ "ಕುರುಡಾಗಿ ಪರಿಶೋಧಿಸುವುದರ" ಅನನುಕೂಲತೆಯನ್ನು ಹೊಂದಿದೆ. ^[೨೪]

ಬೂದು-ಪೆಟ್ಟಿಗೆ ಪರೀಕ್ಷೆ[ಬದಲಾಯಿಸಿ]

ಬೂದು-ಪೆಟ್ಟಿಗೆ ಪರೀಕ್ಷೆ ಯು (Grey box testing) (ಅಮೆರಿಕನ್ನರ ಕಾಗುಣಿತ: gray box testing ) ಪರೀಕ್ಷಾ ಪ್ರಕರಣಗಳನ್ನು ವಿನ್ಯಾಸಗೊಳಿಸುವುದರ ಉದ್ದೇಶಗಳಿಗೆ ಸಂಬಂಧಿಸಿದಂತಿರುವ ಆಂತರಿಕ ದತ್ತಾಂಶ ರಚನೆಗಳು ಮತ್ತು ಗಣನೆಯ ಪದ್ಧತಿಗಳ ಅರಿವನ್ನು ಹೊಂದುವುದನ್ನು ಒಳಗೊಳ್ಳುತ್ತದೆ; ಆದರೆ ಪರೀಕ್ಷೆಯು ಬಳಕೆದಾರನ ಮಟ್ಟದಲ್ಲಿ ಅಥವಾ ಕಪ್ಪು-ಪೆಟ್ಟಿಗೆ ಮಟ್ಟದಲ್ಲಿ ನಡೆಯುತ್ತದೆ. ಪ್ರದಾನ ದತ್ತಾಂಶದ ಕುಶಲಬಳಕೆ ಮಾಡುವಿಕೆ ಮತ್ತು ಫಲಿತ ಮಾಹಿತಿಯ ಫಾರ್ಮ್ಯಾಟ್‌ ಮಾಡುವಿಕೆಯಂಥ ಪ್ರಕ್ರಿಯೆಗಳು ಬೂದು-ಪೆಟ್ಟಿಗೆಯಾಗಿ ಅರ್ಹತೆ ಪಡೆಯುವುದಿಲ್ಲ; ಏಕೆಂದರೆ ಪ್ರದಾನ ದತ್ತಾಂಶ ಮತ್ತು ಫಲಿತ ಮಾಹಿತಿಗಳು ಪರೀಕ್ಷೆ ಒಳಪಟ್ಟಿರುವ ವ್ಯವಸ್ಥೆ ಎಂಬುದಾಗಿ ನಾವು ಕರೆಯುತ್ತಿರುವ "ಕಪ್ಪು-ಪೆಟ್ಟಿಗೆ"ಯಿಂದ ನಿಚ್ಚಳವಾಗಿ ಹೊರಗಡೆ ಇರುತ್ತವೆ. ಎರಡು ವಿಭಿನ್ನ ಅಭಿವರ್ಧಕರಿಂದ ಬರೆಯಲ್ಪಟ್ಟ ಸಂಕೇತದ ಎರಡು ಮೂಲಮಾನಗಳ ನಡುವೆ ಸಮಗ್ರೀಕರಣ ಪರೀಕ್ಷೆಯನ್ನು ನಡೆಸುವಾಗ ಈ ವೈಲಕ್ಷಣ್ಯವು ನಿರ್ದಿಷ್ಟವಾಗಿ ಪ್ರಮುಖವಾಗಿದ್ದು, ಇಲ್ಲಿ ಕೇವಲ ಇಂಟರ್‌ಫೇಸ್‌ಗಳು ಪರೀಕ್ಷೆಗಾಗಿ ಒಡ್ಡಿಕೊಂಡಿರುತ್ತವೆ. ಆದಾಗ್ಯೂ, ದತ್ತಾಂಶ ಭಂಡಾರವೊಂದರ ಮಾರ್ಪಡಿಸುವಿಕೆಯು ಬೂದು-ಪೆಟ್ಟಿಗೆಯಾಗಿ ಅರ್ಹತೆ ಪಡೆಯುತ್ತದೆ; ಏಕೆಂದರೆ ಪರೀಕ್ಷೆಗೆ ಒಳಪಟ್ಟಿರುವ ಯಂತ್ರ ವ್ಯವಸ್ಥೆಯ ಹೊರಗಡೆಯಿರುವ ದತ್ತಾಂಶವನ್ನು ಬದಲಾಯಿಸಲು ಬಳಕೆದಾರನು ಸಾಮಾನ್ಯವಾಗಿ ಅಸಮರ್ಥನಾಗಿರುತ್ತಾನೆ. ಉದಾಹರಣೆಯಾಗಿ ಹೇಳುವುದಾದರೆ, ಎಲ್ಲೆಗೆರೆ ಮೌಲ್ಯಗಳು ಅಥವಾ ತಪ್ಪು ಸಂದೇಶಗಳನ್ನು ನಿರ್ಣಯಿಸಲೆಂದು ಬೂದು-ಪೆಟ್ಟಿಗೆ ಪರೀಕ್ಷೆಯು ಹಿಮ್ಮೊಗದ ಎಂಜಿನಿಯರಿಂಗ್‌ ಸೌಲಭ್ಯವನ್ನೂ ಒಳಗೊಂಡಿರುವ ಸಾಧ್ಯತೆಯಿರುತ್ತದೆ.

ಪರೀಕ್ಷಾ ಮಟ್ಟಗಳು[ಬದಲಾಯಿಸಿ]

ತಂತ್ರಾಂಶದ ಅಭಿವೃದ್ಧಿ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ಪರೀಕ್ಷೆಗಳು ಎಲ್ಲಿ ಸೇರಿಸಲ್ಪಟ್ಟವು ಎಂಬುದರ ಆಧಾರದ ಮೇಲೆ, ಅಥವಾ ಪರೀಕ್ಷೆಯ ನಿಷ್ಕೃಷ್ಟತೆಯ ಮಟ್ಟದ ಆಧಾರದ ಮೇಲೆ ಪರೀಕ್ಷೆಗಳನ್ನು ಆಗಿಂದಾಗ್ಗೆ ಒಟ್ಟುಗೂಡಿಸಲಾಗುತ್ತದೆ.

ಘಟಕದ ಪರೀಕ್ಷೆ[ಬದಲಾಯಿಸಿ]

ಸಾಮಾನ್ಯವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಣೆಯ ಮಟ್ಟದಲ್ಲಿನ ಸಂಕೇತದ ನಿರ್ದಿಷ್ಟ ವಿಭಾಗವೊಂದರ ಕಾರ್ಯತ್ಮಕತೆಯನ್ನು ಪರಿಶೀಲಿಸುವ ಪರೀಕ್ಷೆಗಳಿಗೆ ಘಟಕ ಪರೀಕ್ಷೆ ಎಂಬುದಾಗಿ ಉಲ್ಲೇಖಿಸುತ್ತದೆ. ವಸ್ತು-ಉದ್ದೇಶಿತ ಪರಿಸರವೊಂದರಲ್ಲಿ ಇದು ಸಾಮಾನ್ಯವಾಗಿ ವರ್ಗ ಮಟ್ಟದಲ್ಲಿ ನಡೆಯುತ್ತದೆ, ಮತ್ತು ಕನಿಷ್ಟತಮವಾದ ಘಟಕ ಪರೀಕ್ಷೆಗಳು ನಿರ್ಮಾತೃಗಳು ಮತ್ತು ನಾಶಕರನ್ನು ಒಳಗೊಂಡಿರುತ್ತವೆ.^[೨೫]

ನಿರ್ದಿಷ್ಟ ಚಟುವಟಿಕೆಯು ನಿರೀಕ್ಷಿಸಲ್ಪಟ್ಟಂತೆಯೇ ಕಾರ್ಯನಿರತವಾಗಿದೆ ಎಂಬುದನ್ನು ಖಾತ್ರಿಪಡಿಸಲು ಅಭಿವರ್ಧಕರು ಸಂಕೇತದ (ಬಿಳಿ-ಪೆಟ್ಟಿಗೆ ಶೈಲಿ) ಕುರಿತಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಾರಾದ್ದರಿಂದ, ಈ ಬಗೆಯ ಪರೀಕ್ಷೆಗಳು ಅಭಿವರ್ಧಕರಿಂದ ಸಾಮಾನ್ಯವಾಗಿ ಬರೆಯಲ್ಪಟ್ಟಿರುತ್ತವೆ. ಇಕ್ಕಟ್ಟು ಪ್ರಕರಣಗಳು ಅಥವಾ ಸಂಕೇತದಲ್ಲಿನ ಇತರ ಶಾಖೆಗಳನ್ನು ಸೆರೆಹಿಡಿಯಲೆಂದು, ಒಂದು ಚಟುವಟಿಕೆಯು ಅನೇಕ ಪರೀಕ್ಷೆಗಳನ್ನು ಹೊಂದಿರಲು ಸಾಧ್ಯವಿದೆ. ತಂತ್ರಾಂಶದ ತುಣುಕೊಂದರ ಕಾರ್ಯತ್ಮಕತೆಯನ್ನು ಘಟಕ ಪರೀಕ್ಷೆಯೊಂದೇ ಪರಿಶೀಲಿಸಲಾರದಾದರೂ, ತಂತ್ರಾಂಶವು ಬಳಸುವ ನಿರ್ಮಾಣ ಘಟಕಗಳು ಪರಸ್ಪರ ಸ್ವತಂತ್ರವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ ಎಂಬುದನ್ನು ಖಾತ್ರಿಪಡಿಸಲು ಅದನ್ನು ಬಳಸಲಾಗುತ್ತದೆ.

ಘಟಕ ಪರೀಕ್ಷೆಯನ್ನು ಅಂಗಭಾಗದ ಪರೀಕ್ಷೆ ಎಂಬುದಾಗಿಯೂ ಕರೆಯಲಾಗುತ್ತದೆ.

ಸಮಗ್ರೀಕರಣ ಪರೀಕ್ಷೆ[ಬದಲಾಯಿಸಿ]

ತಂತ್ರಾಂಶ ವಿನ್ಯಾಸವೊಂದಕ್ಕೆ ಪ್ರತಿಯಾಗಿ ಅಂಗಭಾಗಗಳ ನಡುವಿನ ಇಂಟರ್‌ಫೇಸ್‌ಗಳನ್ನು ಪರಿಶೀಲಿಸಲು ಬಯಸುವ ತಂತ್ರಾಂಶ ಪರೀಕ್ಷೆಯ ಯಾವುದೇ ಬಗೆಯು ಸಮಗ್ರೀಕರಣ ಪರೀಕ್ಷೆ ಎನಿಸಿಕೊಳ್ಳುತ್ತದೆ. ತಂತ್ರಾಂಶದ ಅಂಗಭಾಗಗಳು ಒಂದು ಪುನರುಕ್ತಿ ರೂಪದ ವಿಧಾನದಲ್ಲಿ ಅಥವಾ ಎಲ್ಲಾ ಒಟ್ಟಾಗಿ ("ಬಿಗ್‌‌ ಬ್ಯಾಂಗ್‌") ಸಂಯೋಜಿಸಲ್ಪಟ್ಟಿರಬಹುದು. ಇಂಟರ್‌ಫೇಸ್‌ ಸಮಸ್ಯೆಗಳು ಹೆಚ್ಚು ಕ್ಷಿಪ್ರವಾಗಿ ಸ್ಥಳೀಕರಿಸಲ್ಪಡಲು ಮತ್ತು ದುರಸ್ತಿಮಾಡಲ್ಪಡಲು ಪುನರುಕ್ತಿ ರೂಪದ ವಿಧಾನವು ಅನುವುಮಾಡಿಕೊಡುತ್ತದೆಯಾದ್ದರಿಂದ, ಈ ವಿಧಾನವು ಒಂದು ಉತ್ತಮವಾದ ಪರಿಪಾಠ ಎಂಬುದಾಗಿ ಸಾಮಾನ್ಯವಾಗಿ ಪರಿಗಣಿಸಲ್ಪಟ್ಟಿದೆ.

ಇಂಟರ್‌ಫೇಸ್‌ಗಳಲ್ಲಿನ ದೋಷಗಳನ್ನು ಮತ್ತು ಸಂಯೋಜಿಸಲ್ಪಟ್ಟ ಅಂಗಭಾಗಗಳ (ಮೂಲಮಾನಗಳ) ನಡುವಿನ ಪರಸ್ಪರ ಕ್ರಿಯೆಯನ್ನು ಬಹಿರಂಗಪಡಿಸುವ ನಿಟ್ಟಿನಲ್ಲಿ ಸಮಗ್ರೀಕರಣ ಪರೀಕ್ಷೆಯು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ರಚನೆಯ ವಿನ್ಯಾಸದ ಅಂಶಗಳಿಗೆ ಸಂಬಂಧಪಟ್ಟಿರುವ ಪರೀಕ್ಷಿಸಲ್ಪಟ್ಟ ತಂತ್ರಾಂಶದ ಅಂಗಭಾಗಗಳ ಕ್ರಮತಃ ದೊಡ್ಡದಾದ ಗುಂಪುಗಳು, ತಂತ್ರಾಂಶವು ಒಂದು ವ್ಯವಸ್ಥೆಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವವರೆಗೂ ಸಂಯೋಜಿಸಲ್ಪಡುತ್ತವೆ ಮತ್ತು ಪರೀಕ್ಷಿಸಲ್ಪಡುತ್ತವೆ.^[೨೬]

ಯಂತ್ರ ವ್ಯವಸ್ಥೆಯ ಪರೀಕ್ಷೆ[ಬದಲಾಯಿಸಿ]

ಸಂಪೂರ್ಣವಾಗಿ ಸಂಯೋಜಿಸಲ್ಪಟ್ಟಿರುವ ಯಂತ್ರ ವ್ಯವಸ್ಥೆಯೊಂದು ತನ್ನ ಅವಶ್ಯಕತೆಗಳನ್ನು ಈಡೇರಿಸುತ್ತದೆಯೇ ಎಂಬುದನ್ನು ಪರಿಶೀಲಿಸಲು ಯಂತ್ರ ವ್ಯವಸ್ಥೆಯ ಪರೀಕ್ಷೆಯು ಅದನ್ನು ಪರೀಕ್ಷಿಸುತ್ತದೆ.^[೨೭]

ಯಂತ್ರ ವ್ಯವಸ್ಥೆಯ ಸಮಗ್ರೀಕರಣ ಪರೀಕ್ಷೆ[ಬದಲಾಯಿಸಿ]

ಯಂತ್ರ ವ್ಯವಸ್ಥೆಯ ಅವಶ್ಯಕತೆಗಳಲ್ಲಿ ವ್ಯಾಖ್ಯಾನಿಸಲ್ಪಟ್ಟ ಯಾವುದೇ ಬಾಹ್ಯ ಅಥವಾ ತೃತೀಯ ವ್ಯವಸ್ಥೆಗಳಿಗೆ ಯಂತ್ರ ವ್ಯವಸ್ಥೆಯೊಂದು ಸಂಯೋಜಿಸಲ್ಪಟ್ಟಿದೆ ಎಂಬುದನ್ನು ಯಂತ್ರ ವ್ಯವಸ್ಥೆಯ ಸಮಗ್ರೀಕರಣ ಪರೀಕ್ಷೆಯು ಪರಿಶೀಲಿಸುತ್ತದೆ.^{[ಸೂಕ್ತ ಉಲ್ಲೇಖನ ಬೇಕು]}

ನಿವರ್ತನ ಪರೀಕ್ಷೆ[ಬದಲಾಯಿಸಿ]

ಸಂಕೇತದಲ್ಲಿನ ಒಂದು ಪ್ರಮುಖ ಬದಲಾವಣೆಯು ಸಂಭವಿಸಿದ ನಂತರ ದೋಷಗಳನ್ನು ಕಂಡುಹಿಡಿಯುವುದರ ಕುರಿತಾಗಿ ನಿವರ್ತನ ಪರೀಕ್ಷೆ ಯು ಗಮನ ಹರಿಸುತ್ತದೆ. ನಿರ್ದಿಷ್ಟವಾಗಿ ಹೇಳುವುದಾದರೆ, ಮರುಕಳಿಸಿರುವ ತಂತ್ರಾಂಶ ನಿವರ್ತನಗಳು, ಅಥವಾ ಹಳೆಯ ದೋಷಗಳನ್ನು ಬಹಿರಂಗಪಡಿಸಲು ಇದು ಬಯಸುತ್ತದೆ. ಹಿಂದೆ ಸರಿಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದ್ದ ತಂತ್ರಾಂಶದ ಕಾರ್ಯತ್ಮಕತೆಯು ಆಶಿಸಲ್ಪಟ್ಟಂತೆ ಕಾರ್ಯನಿರ್ವಹಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಿದಾಗ ಇಂಥ ನಿವರ್ತನಗಳು ಸಂಭವಿಸುತ್ತವೆ. ವಿಶಿಷ್ಟವೆಂಬಂತೆ, ತಂತ್ರಾಂಶದ ಹೊಸದಾಗಿ ಅಭಿವೃದ್ಧಿಪಡಿಸಲ್ಪಟ್ಟ ಭಾಗವು ಹಿಂದೆ ಅಸ್ತಿತ್ವದಲ್ಲಿದ್ದ ಸಂಕೇತದೊಂದಿಗೆ ಘರ್ಷಿಸಿದಾಗ, ಕಾರ್ಯಸೂಚಿಯ ಬದಲಾವಣೆಗಳ ಒಂದು ಆಶಿಸದ ಪರಿಣಾಮವಾಗಿ ನಿವರ್ತನಗಳು ಸಂಭವಿಸುತ್ತವೆ. ಹಿಂದೆ ಚಾಲಿಸಲಾದ ಪರೀಕ್ಷೆಗಳ ಮರು-ಚಾಲಿಸುವಿಕೆ ಮತ್ತು ಹಿಂದೆ ದುರಸ್ತಿಮಾಡಲ್ಪಟ್ಟ ದೋಷಗಳು ಮತ್ತೆ-ಹೊರಹೊಮ್ಮಿವೆಯೇ ಇಲ್ಲವೇ ಎಂಬುದರ ತಪಾಸಿಸುವಿಕೆಗಳು ನಿವರ್ತನ ಪರೀಕ್ಷೆಯ ಸಾಮಾನ್ಯ ವಿಧಾನಗಳಲ್ಲಿ ಸೇರಿವೆ. ಬಿಡುಗಡೆ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿನ ಹಂತ ಮತ್ತು ಸೇರಿಸಲಾದ ಲಕ್ಷಣಗಳ ಅಪಾಯದ ಮೇಲೆ ಪರೀಕ್ಷೆಯ ಆಳವು ಅವಲಂಬಿತವಾಗಿರುತ್ತದೆ. ಬಿಡುಗಡೆಯಲ್ಲಿ ತಡವಾಗಿ ಸೇರಿಸಲ್ಪಟ್ಟ ಬದಲಾವಣೆಗಳಿಗೆ ಸಂಬಂಧಿಸಿದಂತೆ ಅವು ಸಂಪೂರ್ಣವಾಗಿರಬಹುದು ಅಥವಾ ಅಪಾಯಕಾರಿ ಎಂಬುದಾಗಿ ಪರಿಗಣಿಸಲ್ಪಡಬಹುದು; ಅಂದರೆ ಇದು ಅತ್ಯಂತ ಮೇಲು ಮೇಲಿನ ಅಪಾಯದ ಸ್ವರೂಪದಲ್ಲಿದ್ದು, ಒಂದು ವೇಳೆ ಬದಲಾವಣೆಗಳು ಬಿಡುಗಡೆಯ ಆರಂಭಿಕ ಹಂತದಲ್ಲಿದ್ದರೆ ಅಥವಾ ಕಡಿಮೆ ಅಪಾಯದಿಂದ ಕೂಡಿರುವಂಥವು ಎಂದು ಪರಿಗಣಿಸಲ್ಪಟ್ಟರೆ, ಪ್ರತಿ ಲಕ್ಷಣದ ಮೇಲಿನ ಸಕಾರಾತ್ಮಕ ಪರೀಕ್ಷೆಗಳನ್ನು ಅದು ಒಳಗೊಂಡಿರುತ್ತದೆ.

ಅಂಗೀಕಾರದ ಪರೀಕ್ಷೆ[ಬದಲಾಯಿಸಿ]

ಅಂಗೀಕಾರ ಪರೀಕ್ಷೆಯು ಈ ಕೆಳಗಿನ ಎರಡು ಅಂಶಗಳ ಪೈಕಿ ಒಂದಾಗಿರಬಹುದು:

ಮುಖ್ಯ ಪರೀಕ್ಷಾ ಪ್ರಕ್ರಿಯೆಗೆ ಒಂದು ಹೊಸ ರಚನೆಯನ್ನು ಪರಿಚಯಿಸುವುದಕ್ಕೆ ಮುಂಚಿತವಾಗಿರುವ ಒಂದು ಅಂಗೀಕಾರ ಪರೀಕ್ಷೆಯಾಗಿ, ಅಂದರೆ ಸಮಗ್ರೀಕರಣ ಅಥವಾ ನಿವರ್ತನ ಪರೀಕ್ಷೆಗೆ ಮುಂಚಿತವಾಗಿ ಹೊಗೆ ಪರೀಕ್ಷೆಯೊಂದನ್ನು ಬಳಸಲಾಗುತ್ತದೆ.
ಗ್ರಾಹಕರು ತಮ್ಮ ಪ್ರಯೋಗಾಲಯದ ಪರಿಸರದಲ್ಲಿ ತಮ್ಮದೇ ಆದ ಯಂತ್ರಾಂಶದ ಮೇಲೆ ಅನೇಕವೇಳೆ ನಿರ್ವಹಿಸುವ ಅಂಗೀಕಾರ ಪರೀಕ್ಷೆಯನ್ನು ಬಳಕೆದಾರ ಅಂಗೀಕಾರ ಪರೀಕ್ಷೆ (ಯೂಸರ್‌ ಅಕ್ಸೆಪ್ಟೆನ್ಸ್‌ ಟೆಸ್ಟ್‌-UAT) ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ. ಅಭಿವೃದ್ಧಿಯ ಯಾವುದೇ ಎರಡು ಹಂತಗಳ ನಡುವಿನ ತಳ್ಳಿಕೆ ಪ್ರಕ್ರಿಯೆಯ ಭಾಗವಾಗಿ ಅಂಗೀಕಾರ ಪರೀಕ್ಷೆಯು ನಿರ್ವಹಿಸಲ್ಪಡಬಹುದು. ^{[ಸೂಕ್ತ ಉಲ್ಲೇಖನ ಬೇಕು]}

ಆಲ್ಫಾ ಪರೀಕ್ಷೆ[ಬದಲಾಯಿಸಿ]

ಆಲ್ಫಾ ಪರೀಕ್ಷೆ ಎಂಬುದು ತಂತ್ರಾಂಶದ ಅಭಿವರ್ಧಕರ ತಾಣದಲ್ಲಿ ಸಂಭಾವ್ಯ ಬಳಕೆದಾರರು/ಗ್ರಾಹಕರಿಂದ ಅಥವಾ ಸ್ವತಂತ್ರ ಪರೀಕ್ಷಾ ತಂಡದಿಂದ ನಿರ್ವಹಿಸಲ್ಪಡುವ, ಅನುಕರಿಸಲ್ಪಟ್ಟ ಅಥವಾ ವಾಸ್ತವಿಕವಾದ ಕಾರ್ಯಾತ್ಮಕ ಪರೀಕ್ಷೆಯಾಗಿದೆ. ತಂತ್ರಾಂಶವು ಬೀಟಾ ಪರೀಕ್ಷೆಗೆ ಒಳಪಡುವುದಕ್ಕೆ ಮುಂಚಿತವಾಗಿ, ಆಂತರಿಕ ಅಂಗೀಕಾರ ಪರೀಕ್ಷೆಯ ಒಂದು ಸ್ವರೂಪವಾಗಿ, ಆದೇಶಕ್ಕನುಗುಣವಾಗಿ ರೂಪಿಸಿರದ ತಂತ್ರಾಂಶಕ್ಕೆ ಸಂಬಂಧಿಸಿದಂತೆ ಆಲ್ಫಾ ಪರೀಕ್ಷೆಯನ್ನು ಅನೇಕವೇಳೆ ಬಳಸಿಕೊಳ್ಳಲಾಗುತ್ತದೆ. van Veenendaal, Erik. "Standard glossary of terms used in Software Testing". Retrieved 17 June 2010.

ಬೀಟಾ ಪರೀಕ್ಷೆ[ಬದಲಾಯಿಸಿ]

ಬೀಟಾ ಪರೀಕ್ಷೆ ಯು ಆಲ್ಫಾ ಪರೀಕ್ಷೆಯ ನಂತರ ಬರುತ್ತದೆ. ಬೀಟಾ ಆವೃತ್ತಿಗಳು ಎಂಬುದಾಗಿ ಕರೆಯಲ್ಪಡುವ ತಂತ್ರಾಂಶದ ಆವೃತ್ತಿಗಳು, ಕಾರ್ಯಸೂಚಿ ನಿರ್ವಹಣಾ ತಂಡದ ಆಚೆಯಿರುವ ಒಂದು ಸೀಮಿತ ಶ್ರೋತೃವರ್ಗಕ್ಕೆ ಬಿಡುಗಡೆ ಮಾಡಲ್ಪಡುತ್ತವೆ. ಜನರ ಸಮೂಹಕ್ಕೆ ತಂತ್ರಾಂಶವನ್ನು ಬಿಡುಗಡೆ ಮಾಡಲಾಗುವುದರಿಂದ, ಉತ್ಪನ್ನವು ಕೆಲವೇ ನ್ಯೂನತೆಗಳನ್ನು ಅಥವಾ ದೋಷಗಳನ್ನು ಹೊಂದಿದೆ ಎಂಬುದನ್ನು ಮುಂದಿನ ಪರೀಕ್ಷೆಯು ಖಾತ್ರಿಪಡಿಸಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ. ಪರಿಣಾಮ ಮಾಹಿತಿಯ (ಫೀಡ್‌ಬ್ಯಾಕ್‌‌) ಕ್ಷೇತ್ರವು ಗರಿಷ್ಟತಮ ಸಂಖ್ಯೆಯ ಭವಿಷ್ಯದ ಬಳಕೆದಾರರಿಗೆ ಹೆಚ್ಚಿನ ಮಟ್ಟದಲ್ಲಿ ತಲುಪುವಂತಾಗಲೆಂದು, ಕೆಲವೊಮ್ಮೆ ಬೀಟಾ ಆವೃತ್ತಿಗಳನ್ನು ಸಾರ್ವಜನಿಕರಿಗೆ ಮುಕ್ತವಾಗಿ ಲಭ್ಯವಾಗುವಂತೆ ಮಾಡಲಾಗುತ್ತದೆ.^{[ಸೂಕ್ತ ಉಲ್ಲೇಖನ ಬೇಕು]}

ಕಾರ್ಯತ್ಮಕವಲ್ಲದ ಪರೀಕ್ಷೆ[ಬದಲಾಯಿಸಿ]

ತಂತ್ರಾಂಶದ ಕಾರ್ಯತ್ಮಕವಲ್ಲದ ಮಗ್ಗುಲುಗಳನ್ನು ಪರೀಕ್ಷಿಸುವುದಕ್ಕಾಗಿ ವಿಶೇಷ ವಿಧಾನಗಳು ಅಸ್ತಿತ್ವದಲ್ಲಿವೆ. ತಂತ್ರಾಂಶದ ಸರಿಯಾದ ಕಾರ್ಯಾಚರಣೆಯನ್ನು (ಸರಿಯಾದ ಕಾರ್ಯಾಚರಣೆ ಎಂದರೆ, ವಿನ್ಯಾಸದ ಅವಶ್ಯಕತೆಗಳಲ್ಲಿ ವಿಶದೀಕರಿಸಲ್ಪಟ್ಟ ನಿರೀಕ್ಷಿತ ವರ್ತನೆಯನ್ನು ಇದು ಹೊಂದಿಸುತ್ತದೆ ಎಂದರ್ಥ) ಪ್ರಮಾಣೀಕರಿಸುವ ಅಥವಾ ನೆಲೆಗೊಳಿಸುವ ಕಾರ್ಯತ್ಮಕ ಪರೀಕ್ಷೆಗೆ ಪ್ರತಿಯಾಗಿ ಕಾರ್ಯತ್ಮಕವಲ್ಲದ ಪರೀಕ್ಷೆಯು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ; ಅಂದರೆ, ಅಸಿಂಧುವಾದ ಅಥವಾ ಅನಿರೀಕ್ಷಿತವಾದ ದತ್ತಮಾಹಿತಿಗಳನ್ನು ತಂತ್ರಾಂಶವು ಸ್ವೀಕರಿಸಿದಾಗಲೂ, ತಂತ್ರಾಂಶವು ಸೂಕ್ತವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆಯೇ ಎಂಬುದನ್ನು ಕಾರ್ಯತ್ಮಕವಲ್ಲದ ಪರೀಕ್ಷೆಯು ಪರಿಶೀಲಿಸುತ್ತದೆ. ಜಾಳಾಗಿಸುವಿಕೆಯ ಸ್ವರೂಪದಲ್ಲಿ ಕೈಗೊಳ್ಳಲಾಗುವ ತಂತ್ರಾಂಶದ ದೋಷದ ಒಳಹೊಗಿಸುವಿಕೆಯು, ಕಾರ್ಯತ್ಮಕವಲ್ಲದ ಪರೀಕ್ಷೆಯ ಒಂದು ಉದಾಹರಣೆಯಾಗಿದೆ. ಕಾರ್ಯತ್ಮಕವಲ್ಲದ ಪರೀಕ್ಷೆಯು, ಅದರಲ್ಲೂ ವಿಶೇಷವಾಗಿ ತಂತ್ರಾಂಶಕ್ಕೆ ಸಂಬಂಧಿಸಿದಂತಿರುವ ಈ ಪರೀಕ್ಷೆಯು, ಪರೀಕ್ಷೆಗೆ ಒಳಪಟ್ಟಿರುವ ಸಾಧನವು ಅಸಿಂಧುವಾದ ಅಥವಾ ಅನಿರೀಕ್ಷಿತವಾದ ದತ್ತಮಾಹಿತಿಗಳನ್ನು ಸಹಿಸಿಕೊಳ್ಳಬಲ್ಲದೇ ಅಥವಾ ಇಲ್ಲವೇ ಎಂಬುದನ್ನು ಪ್ರಮಾಣೀಕರಿಸಲು ವಿನ್ಯಾಸಗೊಳಿಸಲ್ಪಟ್ಟಿರುತ್ತದೆ; ಇದರಿಂದಾಗಿ, ದತ್ತಮಾಹಿತಿಯನ್ನು ಕ್ರಮಬದ್ಧಗೊಳಿಸುವ ವಾಡಿಕೆಯ ಅನುಕ್ರಮಗಳ ಸಶಕ್ತತೆಯನ್ನು ಮಾತ್ರವೇ ಅಲ್ಲದೇ, ತಪ್ಪನ್ನು-ನಿಭಾಯಿಸುವ ವಾಡಿಕೆಯ ಅನುಕ್ರಮಗಳನ್ನೂ ಸಹ ಪ್ರಮಾಣೀಕರಿಸುವುದು ಸಾಧ್ಯವಾಗುತ್ತದೆ. ವಾಣಿಜ್ಯೋದ್ದೇಶದ ಹಲವಾರು ಕಾರ್ಯತ್ಮಕವಲ್ಲದ ಪರೀಕ್ಷಾ ಸಾಧನಗಳು ತಂತ್ರಾಂಶದ ದೋಷದ ಒಳಹೊಗಿಸುವಿಕೆಯ ಪುಟದಿಂದ ಸಂಪರ್ಕವನ್ನು ಹೊಂದಿರುತ್ತವೆ; ಕಾರ್ಯತ್ಮಕವಲ್ಲದ ಪರೀಕ್ಷೆಯನ್ನು ನಿರ್ವಹಿಸುವ, ಮುಕ್ತ-ಮೂಲದ ಮತ್ತು ಉಚಿತವಾದ ಹಲವಾರು ತಂತ್ರಾಂಶ ಸಾಧನಗಳೂ ಸಹ ಇಲ್ಲಿ ಲಭ್ಯವಿವೆ.

ತಂತ್ರಾಂಶ ಕಾರ್ಯಕ್ಷಮತೆಯ ಪರೀಕ್ಷೆ ಮತ್ತು ಹೊರೆ ಪರೀಕ್ಷೆ[ಬದಲಾಯಿಸಿ]

ಒಂದು ನಿರ್ದಿಷ್ಟ ಕಾರ್ಯಹೊರೆಯ ಅಡಿಯಲ್ಲಿ ಒಂದು ಯಂತ್ರ ವ್ಯವಸ್ಥೆ ಅಥವಾ ಉಪ-ಯಂತ್ರ ವ್ಯವಸ್ಥೆಯು ಎಷ್ಟು ಕ್ಷಿಪ್ರವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ನಿರ್ಣಯಿಸಲು ಕಾರ್ಯಕ್ಷಮತೆಯ ಪರೀಕ್ಷೆಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲಾಗಿರುತ್ತದೆ. ಪ್ರಮಾಣವೃದ್ಧಿ ಸಾಮರ್ಥ್ಯ, ವಿಶ್ವಾಸಾರ್ಹತೆ ಮತ್ತು ಸಂಪನ್ಮೂಲದ ಬಳಕೆಯಂಥ ಯಂತ್ರ ವ್ಯವಸ್ಥೆಯ ಇತರ ಗುಣಮಟ್ಟದ ಅಂಶಗಳನ್ನು ಊರ್ಜಿತಗೊಳಿಸುವ ಮತ್ತು ಪರಿಶೀಲಿಸುವ ಕಾರ್ಯವನ್ನೂ ಸಹ ಇದು ನೆರವೇರಿಸಬಲ್ಲದು. ಅದು ದೊಡ್ಡ ಪರಿಮಾಣಗಳ ದತ್ತಾಂಶವೇ ಆಗಿರಲಿ ಅಥವಾ ಒಂದು ದೊಡ್ಡ ಸಂಖ್ಯೆಯ ಬಳಕೆದಾರರೇ ಆಗಿರಲಿ, ಒಂದು ನಿರ್ದಿಷ್ಟ ಹೊರೆಯ ಅಡಿಯಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಣೆಯನ್ನು ಮುಂದುವರಿಸಬಲ್ಲ ಪರೀಕ್ಷೆಗೆ ಹೊರೆ ಪರೀಕ್ಷೆಯು ಪ್ರಧಾನವಾಗಿ ಸಂಬಂಧಪಟ್ಟಿರುತ್ತದೆ. ಇದಕ್ಕೆ ತಂತ್ರಾಂಶದ ಆರೋಹ್ಯತೆ (ಪ್ರಮಾಣವೃದ್ಧಿ ಸಾಮರ್ಥ್ಯ) ಎಂಬುದಾಗಿ ಸಾಮಾನ್ಯವಾಗಿ ಉಲ್ಲೇಖಿಸಲಾಗುತ್ತದೆ. ಒಂದು ಕಾರ್ಯತ್ಮಕವಲ್ಲದ ಚಟುವಟಿಕೆಯಾಗಿ ನಿರ್ವಹಿಸಲ್ಪಟ್ಟಾಗಿನ ಸಂಬಂಧಿತ ಹೊರೆ ಪರೀಕ್ಷಾ ಚಟುವಟಿಕೆಯನ್ನು ಸಹಿಷ್ಣುತೆ ಪರೀಕ್ಷೆ ಎಂಬುದಾಗಿ ಅನೇಕವೇಳೆ ಉಲ್ಲೇಖಿಸಲಾಗುತ್ತದೆ.

ಗಾತ್ರದ ಪರೀಕ್ಷೆ ಎಂಬುದು ಪರೀಕ್ಷಾ ಕಾರ್ಯತ್ಮಕತೆಗೆ ಇರುವ ಒಂದು ಮಾರ್ಗವಾಗಿದೆ. ಒತ್ತಡದ ಪರೀಕ್ಷೆ ಎಂಬುದು ಪರೀಕ್ಷಾ ವಿಶ್ವಾಸಾರ್ಹತೆಗೆ ಇರುವ ಒಂದು ಮಾರ್ಗವಾಗಿದೆ. ಹೊರೆ ಪರೀಕ್ಷೆ ಎಂಬುದು ಪರೀಕ್ಷಾ ಕಾರ್ಯಕ್ಷಮತೆಗೆ ಇರುವ ಒಂದು ಮಾರ್ಗವಾಗಿದೆ. ಹೊರೆ ಪರೀಕ್ಷೆಯ ನಿರ್ದಿಷ್ಟ ಗುರಿಗಳೇನು ಎಂಬುದರ ಕುರಿತು ಇರುವ ಒಮ್ಮತಾಭಿಪ್ರಾಯವು ಅಲ್ಪಪ್ರಮಾಣದ್ದಾಗಿದೆ. ಹೊರೆ ಪರೀಕ್ಷೆ, ಕಾರ್ಯಕ್ಷಮತೆಯ ಪರೀಕ್ಷೆ, ವಿಶ್ವಾಸಾರ್ಹತೆಯ ಪರೀಕ್ಷೆ, ಮತ್ತು ಗಾತ್ರದ ಪರೀಕ್ಷೆ ಎಂಬ ಶಬ್ದಗಳನ್ನು ಅನೇಕವೇಳೆ ವಿನಿಮಯಸಾಧ್ಯವಾಗಿ ಬಳಸಲಾಗುತ್ತದೆ.

ಸ್ಥಿರತೆಯ ಪರೀಕ್ಷೆ[ಬದಲಾಯಿಸಿ]

ಒಂದು ಸ್ವೀಕಾರಯೋಗ್ಯ ಅವಧಿಯೊಳಗೆ ಅಥವಾ ಅದಕ್ಕೂ ಮೇಲೆ ತಂತ್ರಾಂಶವೊಂದು ನಿರಂತರವಾಗಿ ಚೆನ್ನಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸಬಲ್ಲದೇ ಎಂಬುದನ್ನು ನೋಡಲು ಸ್ಥಿರತೆಯ ಪರೀಕ್ಷೆಯು ತಪಾಸಿಸುತ್ತದೆ. ಕಾರ್ಯತ್ಮಕವಲ್ಲದ ತಂತ್ರಾಂಶ ಪರೀಕ್ಷೆಯ ಈ ಚಟುವಟಿಕೆಯನ್ನು ಹೊರೆ (ಅಥವಾ ಸಹಿಷ್ಣುತೆ) ಪರೀಕ್ಷೆ ಎಂಬುದಾಗಿ ಅನೇಕವೇಳೆ ಉಲ್ಲೇಖಿಸಲಾಗುತ್ತದೆ.

ಉಪಯುಕ್ತತೆಯ ಪರೀಕ್ಷೆ[ಬದಲಾಯಿಸಿ]

ಬಳಸಲು ಮತ್ತು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಬಳಕೆದಾರರ ಇಂಟರ್‌ಫೇಸ್‌ ಸುಲಭವಾಗಿದೆಯೇ ಅಥವಾ ಇಲ್ಲವೇ ಎಂಬುದನ್ನು ತಪಾಸಿಸಲು ಉಪಯುಕ್ತತೆಯ ಪರೀಕ್ಷೆಯು ಅಗತ್ಯವಾಗಿರುತ್ತದೆ.

ಭದ್ರತೆಯ ಪರೀಕ್ಷೆ[ಬದಲಾಯಿಸಿ]

ಅಕ್ರಮ ಬಳಕೆದಾರರಿಂದ ಯಂತ್ರ ವ್ಯವಸ್ಥೆಯ ಅತಿಕ್ರಮ ಪ್ರವೇಶವಾಗುವುದನ್ನು ತಡೆಗಟ್ಟಲೆಂದು ರಹಸ್ಯವಾದ ದತ್ತಾಂಶವನ್ನು ಸಂಸ್ಕರಿಸುವ ತಂತ್ರಾಂಶಕ್ಕೆ ಸಂಬಂಧಿಸಿದಂತೆ ಭದ್ರತೆಯ ಪರೀಕ್ಷೆಯು ಅವಶ್ಯಕವಾಗಿರುತ್ತದೆ.

ಅಂತರರಾಷ್ಟ್ರೀಕರಣ ಮತ್ತು ಸ್ಥಳೀಕರಣ[ಬದಲಾಯಿಸಿ]

ತಂತ್ರಾಂಶದ ಈ ಮಗ್ಗುಲುಗಳನ್ನು ಪರೀಕ್ಷಿಸಲು ಅಂತರರಾಷ್ಟ್ರೀಕರಣ ಮತ್ತು ಸ್ಥಳೀಕರಣವು ಅಗತ್ಯವಾಗಿದ್ದು, ಇದಕ್ಕಾಗಿ ಒಂದು ಹುಸಿ-ಸ್ಥಳೀಕರಣ ವಿಧಾನವನ್ನು ಬಳಸಬಹುದಾಗಿದೆ. ಅನ್ವಯಿಕೆಯನ್ನು ಹೊಸದೊಂದು ಭಾಷೆಗೆ ಭಾಷಾಂತರಿಸಲಾದ ನಂತರವೂ ಅಥವಾ ಒಂದು ಹೊಸ ಸಂಸ್ಕೃತಿಗಾಗಿ (ವಿಭಿನ್ನ ಮಾಧ್ಯಮಗಳು ಅಥವಾ ಸಮಯ ವಲಯಗಳಂಥವು) ರೂಪಾಂತರಿಸಲಾದ ನಂತರವೂ, ಅನ್ವಯಿಕೆಯು ಇನ್ನೂ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಇದು ಪರಿಶೀಲಿಸುತ್ತದೆ.

ವಿನಾಶಕ ಪರೀಕ್ಷೆ[ಬದಲಾಯಿಸಿ]

ತಂತ್ರಾಂಶದ ಅಥವಾ ಉಪ-ಯಂತ್ರ ವ್ಯವಸ್ಥೆಯೊಂದರ ಸಶಕ್ತತೆಯನ್ನು ಪರೀಕ್ಷಿಸುವ ಉದ್ದೇಶದಿಂದ, ಅದು ವಿಫಲಗೊಳ್ಳುವಂತಾಗಲು ವಿನಾಶಕ ಪರೀಕ್ಷೆಯು ಪ್ರಯತ್ನಿಸುತ್ತದೆ.

ಪರೀಕ್ಷಾ ಪ್ರಕ್ರಿಯೆ[ಬದಲಾಯಿಸಿ]

ಸಾಂಪ್ರದಾಯಿಕ CMMI ಅಥವಾ ಜಲಪಾತ ಅಭಿವೃದ್ಧಿ ಮಾದರಿ[ಬದಲಾಯಿಸಿ]

ತಂತ್ರಾಂಶ ಪರೀಕ್ಷೆಯ ಒಂದು ಸಾಮಾನ್ಯ ಪರಿಪಾಠವೆಂದರೆ, ತಂತ್ರಾಂಶದ ಕಾರ್ಯತ್ಮಕತೆಯು ಅಭಿವೃದ್ಧಿಪಡಿಸಲ್ಪಟ್ಟ ನಂತರ ಅದು ಗ್ರಾಹಕರಿಗೆ ವಿತರಿಸಲ್ಪಡುವ ಮೊದಲು, ಪರೀಕ್ಷಕರ ಒಂದು ಸ್ವತಂತ್ರ ಗುಂಪು ಪರೀಕ್ಷೆಯನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ.^[೨೮] ಯೋಜನೆಯ ವಿಳಂಬಗಳಿಗೆ ಸಂಬಂಧಿಸಿದಂತೆ ಸರಿದೂಗಿಸಲೆಂದು ಒಂದು ಯೋಜನಾ ದತ್ತಕೋಶವಾಗಿ ಬಳಸಲ್ಪಡುತ್ತಿರುವ ಪರೀಕ್ಷಾ ಹಂತದಲ್ಲಿ ಈ ಪರಿಪಾಠವು ಅನೇಕವೇಳೆ ಕೊನೆಗೊಳ್ಳುತ್ತದೆ; ಇದರಿಂದಾಗಿ ಪರೀಕ್ಷಾ ಕಾರ್ಯಕ್ಕೆ ವಿನಿಯೋಗಿಸಲ್ಪಟ್ಟ ಸಮಯಕ್ಕೆ ಹೊಂದಿಕೊಂಡಂತಾಗುತ್ತದೆ.^[೨೯]

ಯೋಜನೆಯು ಆರಂಭಗೊಂಡ ಅದೇ ಕ್ಷಣದಲ್ಲೇ ತಂತ್ರಾಂಶ ಪರೀಕ್ಷೆಯನ್ನು ಆರಂಭಿಸುವುದು ಮತ್ತೊಂದು ಪರಿಪಾಠವಾಗಿದೆ ಮತ್ತು ಇದು ಯೋಜನೆಯು ಸಮಾಪ್ತಿಯಾಗುವವರೆಗೂ ನಡೆಯುವ ಒಂದು ನಿರಂತರ ಪ್ರಕ್ರಿಯೆಯಾಗಿದೆ.^[೩೦]

ಅಗೈಲ್ ಅಥವಾ ಪರಮೋಚ್ಚ ಅಭಿವೃದ್ಧಿ ಮಾದರಿ[ಬದಲಾಯಿಸಿ]

ವೈದೃಶ್ಯವಾಗಿ ಹೇಳುವುದಾದರೆ, ಪರಮೋಚ್ಚ ಕಾರ್ಯಸೂಚಿ ನಿರ್ವಹಣೆ ಮತ್ತು ಅಗೈಲ್ ತಂತ್ರಾಂಶದ ಅಭಿವೃದ್ಧಿ ಚಟುವಟಿಕೆಯಂಥ ಅಸ್ತಿತ್ವಕ್ಕೆ ಬರುತ್ತಿರುವ ಕೆಲವೊಂದು ತಂತ್ರಾಂಶ ವಿಧಾನಗಳು, "ಪರೀಕ್ಷಾ-ಪ್ರೇರಿತ ತಂತ್ರಾಂಶ ಅಭಿವೃದ್ಧಿ" ಮಾದರಿಯೊಂದಕ್ಕೆ ಅಂಟಿಕೊಳ್ಳುತ್ತವೆ. ಈ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ, ಘಟಕ ಪರೀಕ್ಷೆಗಳನ್ನು ಮೊದಲು ಬರೆಯಲಾಗುತ್ತದೆ ಹಾಗೂ ತಂತ್ರಾಂಶದ ಎಂಜಿನಿಯರ್‌ಗಳು ಇದನ್ನು (ಅನೇಕವೇಳೆ ಪರಮೋಚ್ಚ ಕಾರ್ಯಸೂಚಿ ನಿರ್ವಹಣೆಯ ವಿಧಾನಶಾಸ್ತ್ರದಲ್ಲಿನ ಜೋಡಿ ಕಾರ್ಯಸೂಚಿ ನಿರ್ವಹಣೆಯೊಂದಿಗೆ) ಕೈಗೊಳ್ಳುತ್ತಾರೆ. ನಿರೀಕ್ಷಿಸಲ್ಪಟ್ಟಂತೆ, ಈ ಪರೀಕ್ಷೆಗಳು ಆರಂಭದಲ್ಲಿ ಸ್ವಾಭಾವಿಕವಾಗಿ ವಿಫಲಗೊಳ್ಳುತ್ತವೆ. ನಂತರ ಸಂಕೇತವು ಬರೆಯಲ್ಪಟ್ಟಂತೆ, ವರ್ಧಿಸುತ್ತಾ ಹೋಗುವ ಪರೀಕ್ಷಾ ಮಾಲಿಕೆಗಳ ದೊಡ್ಡದಾದ ಭಾಗಗಳನ್ನು ಅದು ವರ್ಗಾಯಿಸುತ್ತಾ ಹೋಗುತ್ತದೆ. ವೈಫಲ್ಯತೆಯ ಹೊಸ ಸ್ಥಿತಿಗತಿಗಳು ಮತ್ತು ಇಕ್ಕಟ್ಟಿನ ಪ್ರಕರಣಗಳು ಪತ್ತೆಹಚ್ಚಲ್ಪಡುವುದರಿಂದ, ಪರೀಕ್ಷಾ ಮಾಲಿಕೆಗಳು ನಿರಂತರವಾಗಿ ಪರಿಷ್ಕರಿಸಲ್ಪಡುತ್ತವೆ, ಮತ್ತು ಅಭಿವೃದ್ಧಿಪಡಿಸಲ್ಪಟ್ಟ ಯಾವುದೇ ನಿವರ್ತನ ಪರೀಕ್ಷೆಗಳೊಂದಿಗೆ ಅವು ಸಂಯೋಜಿಸಲ್ಪಡುತ್ತವೆ. ತಂತ್ರಾಂಶದ ಉಳಿದ ಮೂಲ ಸಂಕೇತದ ಜೊತೆಜೊತೆಗೆ ಘಟಕ ಪರೀಕ್ಷೆಗಳು ನಿರ್ವಹಿಸಲ್ಪಡುತ್ತವೆ ಮತ್ತು ನಿರ್ಮಾಣ ಪ್ರಕ್ರಿಯೆಯೊಳಗೆ ಸಾಮಾನ್ಯವಾಗಿ (ಅಂತರ್ಗತವಾಗಿ ಪರಸ್ಪರ ಪ್ರಭಾವ ಬೀರುವ ಪರೀಕ್ಷೆಗಳು, ಆಂಶಿಕವಾಗಿ ಕೈಯಿಂದ ಮಾಡಿದ ವಿನ್ಯಾಸದ ಅಂಗೀಕಾರ ಪ್ರಕ್ರಿಯೆಯೊಂದಕ್ಕೆ ಕೆಳಮಟ್ಟಕ್ಕೆ ಇಳಿಸಲ್ಪಡುತ್ತಿರುವುದರೊಂದಿಗೆ) ಸಂಯೋಜಿಸಲ್ಪಡುತ್ತವೆ. ನಿರಂತರ ನಿಯೋಜನೆಯನ್ನು ಸಾಧಿಸುವುದು ಈ ಪರೀಕ್ಷಾ ಪ್ರಕ್ರಿಯೆಯ ಅಂತಿಮ ಗುರಿಯಾಗಿದ್ದು, ಇಲ್ಲಿ ತಂತ್ರಾಂಶ ಪರಿಷ್ಕರಣೆಗಳನ್ನು ಸಾರ್ವಜನಿಕರ ಗಮನಕ್ಕೆ ಬರುವಂತೆ ಆಗಿಂದಾಗ್ಗೆ ಪ್ರಕಟಿಸಬಹುದಾಗಿರುತ್ತದೆ. ^[೩೧] ^[೩೨]

ಪರೀಕ್ಷಾ ಆವರ್ತನದ ಒಂದು ಮಾದರಿ[ಬದಲಾಯಿಸಿ]

ಸಂಸ್ಥೆಗಳು ಅಥವಾ ಸಂಘಟನೆಗಳ ನಡುವೆ ಬದಲಾವಣೆಗಳು ಇರುತ್ತವೆಯಾದರೂ, ಪರೀಕ್ಷೆಗೆ ಸಂಬಂಧಿಸಿದ ಒಂದು ವಿಶಿಷ್ಟ ಆವರ್ತನವು ಅಸ್ತಿತ್ವದಲ್ಲಿದೆ.^[೩೩] ಜಲಪಾತ ಅಭಿವೃದ್ಧಿ ಮಾದರಿಯನ್ನು ಅಳವಡಿಸಿಕೊಂಡಿರುವ ಸಂಸ್ಥೆಗಳ ಪೈಕಿ ಈ ಕೆಳಕಂಡ ಮಾದರಿಯು ಸಾಮಾನ್ಯವಾಗಿರುತ್ತದೆ.

ಅವಶ್ಯಕತೆಗಳ ವಿಶ್ಲೇಷಣೆ : ತಂತ್ರಾಂಶ ಅಭಿವೃದ್ಧಿಯ ಜೀವಿತಾವಧಿಯ ಅವಶ್ಯಕತೆಗಳ ಹಂತದಲ್ಲಿ ಪರೀಕ್ಷೆಯು ಪ್ರಾರಂಭವಾಗಬೇಕಾಗುತ್ತದೆ. ವಿನ್ಯಾಸದ ಹಂತದ ಅವಧಿಯಲ್ಲಿ, ವಿನ್ಯಾಸವೊಂದರ ಯಾವ ಮಗ್ಗುಲುಗಳು ಪರೀಕ್ಷಣೀಯವಾಗಿವೆ ಮತ್ತು ಯಾವ ಮಾಪಕ ಲಕ್ಷಣಗಳೊಂದಿಗೆ ಆ ಪರೀಕ್ಷೆಗಳು ಕೆಲಸ ಮಾಡುತ್ತವೆ ಎಂಬುದನ್ನು ನಿರ್ಣಯಿಸುವಲ್ಲಿ ಪರೀಕ್ಷಕರು ಅಭಿವರ್ಧಕರೊಂದಿಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಾರೆ.
ಪರೀಕ್ಷಾ ಯೋಜಿಸುವಿಕೆ : ಪರೀಕ್ಷಾ ಕಾರ್ಯತಂತ್ರ, ಪರೀಕ್ಷಾ ಯೋಜನೆ, ಪೂರ್ವಪರೀಕ್ಷಾ ಸಾಧನ ಸೃಷ್ಟಿಯಂಥ ಅನೇಕ ಚಟುವಟಿಕೆಗಳು ಪರೀಕ್ಷೆಯ ಸಂದರ್ಭದಲ್ಲಿ ನಡೆಸಲ್ಪಡುವುದರಿಂದ, ಒಂದು ಯೋಜನೆಯು ಅಗತ್ಯವಾಗಿರುತ್ತದೆ.
ಪರೀಕ್ಷಾ ಅಭಿವೃದ್ಧಿ : ಪರೀಕ್ಷಾ ತಂತ್ರಾಂಶದಲ್ಲಿ ಬಳಸಲ್ಪಡುವ ಪರೀಕ್ಷಾ ಕ್ರಮವಿಧಾನಗಳು, ಪರೀಕ್ಷಾ ಸನ್ನಿವೇಶಗಳು, ಪರೀಕ್ಷಾ ಪ್ರಕರಣಗಳು, ಪರೀಕ್ಷಾ ದತ್ತಾಂಶ ಸಜ್ಜಿಕೆಗಳು, ಪರೀಕ್ಷಾ ಮೂಲಪ್ರತಿಗಳು ಇದರಲ್ಲಿ ಸೇರಿರುತ್ತವೆ.
ಪರೀಕ್ಷಾ ನೆರವೇರಿಕೆ : ಯೋಜನೆಗಳು ಮತ್ತು ಪರೀಕ್ಷಾ ದಸ್ತಾವೇಜುಗಳನ್ನು ಆಧರಿಸಿ ಪರೀಕ್ಷಕರು ತಂತ್ರಾಂಶವನ್ನು ಕಾರ್ಯರೂಪಕ್ಕೆ ತರುತ್ತಾರೆ ಹಾಗೂ ಏನಾದರೂ ತಪ್ಪುಗಳು ಕಂಡುಬಂದಲ್ಲಿ ಅವನ್ನು ಅಭಿವೃದ್ಧಿ ತಂಡಕ್ಕೆ ವರದಿ ಮಾಡುತ್ತಾರೆ.
ಪರೀಕ್ಷಾ ವರದಿಗಾರಿಕೆ : ಪರೀಕ್ಷೆಯು ಒಮ್ಮೆಗೆ ಸಂಪೂರ್ಣಗೊಳಿಸಲ್ಪಟ್ಟಿತೆಂದರೆ, ಪರೀಕ್ಷಕರು ಅದರ ಛಂದೋವಿಧಾನವನ್ನು ಸೃಷ್ಟಿಸುತ್ತಾರೆ ಹಾಗೂ ತಮ್ಮ ಪರೀಕ್ಷಾ ಪ್ರಯತ್ನದ ಕುರಿತಾಗಿ ಹಾಗೂ ಪರೀಕ್ಷಿಸಲ್ಪಟ್ಟ ತಂತ್ರಾಂಶವು ಬಿಡುಗಡೆಗಾಗಿ ಸಿದ್ಧವಾಗಿದೆಯೇ ಅಥವಾ ಇಲ್ಲವೇ ಎಂಬುದರ ಕುರಿತಾಗಿ ಅಂತಿಮ ವರದಿಗಳನ್ನು ರೂಪಿಸುತ್ತಾರೆ.
ಪರೀಕ್ಷಾ ಫಲಿತಾಂಶದ ವಿಶ್ಲೇಷಣೆ : ಅಥವಾ ದೋಷ ವಿಶ್ಲೇಷಣೆಯನ್ನು ಅಭಿವೃದ್ಧಿ ತಂಡವು ಸಾಮಾನ್ಯವಾಗಿ ಗಿರಾಕಿಯ ಜೊತೆಜೊತೆಗೆ ಮಾಡುತ್ತದೆ; ಯಾವ ದೋಷಗಳನ್ನು ಸಂಸ್ಕರಿಸಬೇಕು, ದುರಸ್ತಿಮಾಡಬೇಕು, ತಿರಸ್ಕರಿಸಬೇಕು (ಅಂದರೆ, ಆಧಾರವಾಗಿರುವ ತಂತ್ರಾಂಶವು ಸೂಕ್ತವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದೆಯೇ ಎಂಬುದನ್ನು ಕಂಡುಕೊಳ್ಳುವುದು) ಅಥವಾ ನಂತರದಲ್ಲಿ ಕೈಗೆತ್ತಿಕೊಳ್ಳಲು ಅನುವಾಗುವಂತೆ ಮುಂದೂಡಬೇಕು ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸಲೆಂದು ಈ ವಿಶ್ಲೇಷಣೆಯನ್ನು ಕೈಗೊಳ್ಳಲಾಗುತ್ತದೆ.
ದೋಷದ ಮರುಪರೀಕ್ಷೆ : ಅಭಿವೃದ್ಧಿ ತಂಡದ ವತಿಯಿಂದ ದೋಷವೊಂದು ಒಮ್ಮೆಗೆ ಕೈಗೆತ್ತಿಕೊಳ್ಳಲ್ಪಟ್ಟು ನಿರ್ವಹಣೆಗೆ ಒಳಪಟ್ಟಿತೆಂದರೆ, ಅದನ್ನು ಪರೀಕ್ಷಾ ತಂಡವು ಮರುಪರೀಕ್ಷಿಸುತ್ತದೆ. ಇದನ್ನು ಪೃಥಕ್ಕರಣ ಪರೀಕ್ಷೆ ಎಂದೂ ಸಹ ಕರೆಯಲಾಗುತ್ತದೆ.
ನಿವರ್ತನ ಪರೀಕ್ಷೆ : ಹೊಸತಾದ, ಮಾರ್ಪಡಿಸಲ್ಪಟ್ಟ, ಅಥವಾ ದುರಸ್ತಿಮಾಡಲ್ಪಟ್ಟ ತಂತ್ರಾಂಶದ ಪ್ರತಿ ಸಮಗ್ರೀಕರಣಕ್ಕೆ ಸಂಬಂಧಿಸಿದಂತೆ ಪರೀಕ್ಷೆಗಳ ಒಂದು ಉಪವರ್ಗದ ಒಂದು ಸಣ್ಣ ಪರೀಕ್ಷಾ ಕಾರ್ಯಸೂಚಿಯ ವಿನ್ಯಾಸವನ್ನು ಹೊಂದುವುದು ಸಾಮಾನ್ಯವಾಗಿದೆ; ವಿನೂತನ ವಿತರಣೆಯು ಯಾವುದನ್ನೂ ನಾಶಪಡಿಸಿಲ್ಲ ಎಂಬುದನ್ನು ಖಾತ್ರಿಪಡಿಸಲು, ಹಾಗೂ ತಂತ್ರಾಂಶ ಉತ್ಪನ್ನವು ಈಗಲೂ ಒಟ್ಟಾರೆಯಾಗಿ ಸರಿಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದೆ ಎಂಬುದನ್ನು ಖಾತ್ರಿಪಡಿಸಲು ಈ ಕ್ರಮವನ್ನು ಕೈಗೊಳ್ಳಲಾಗುತ್ತದೆ.
ಪರೀಕ್ಷಾ ಸಮಾಪ್ತಿ : ಪರೀಕ್ಷೆಯು ಒಮ್ಮೆಗೆ ನಿರ್ಗಮನದ ಮಾನದಂಡಗಳನ್ನು ಈಡೇರಿಸಿತೆಂದರೆ, ಪ್ರಮುಖ ಫಲಿತ ಮಾಹಿತಿಗಳ ಸೆರೆಹಿಡಿಯುವಿಕೆ, ಕಲಿತ ಪಾಠಗಳು, ಫಲಿತಾಂಶಗಳು, ದಾಖಲಿಸುವಿಕೆಗಳು, ಯೋಜನೆಗೆ ಸಂಬಂಧಿಸಿದ ದಸ್ತಾವೇಜುಗಳಂಥ ಚಟುವಟಿಕೆಗಳನ್ನು ದಾಖಲೆಯಾಗಿ ಸಂಗ್ರಹಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಭವಿಷ್ಯಸ ಯೋಜನೆಗಳಿಗೆ ಸಂಬಂಧಿಸಿದಂತೆ ಒಂದು ಆಕರ ಭಾಗವಾಗಿ ಬಳಸಲಾಗುತ್ತದೆ.

ಸ್ವಯಂಚಾಲಿತ ಪರೀಕ್ಷೆ[ಬದಲಾಯಿಸಿ]

ಕಾರ್ಯಸೂಚಿ ನಿರ್ವಹಣೆಯ ಅನೇಕ ಗುಂಪುಗಳು ಸ್ವಯಂಚಾಲಿತ ಪರೀಕ್ಷೆಯನ್ನು ಹೆಚ್ಚೆಚ್ಚು ನೆಚ್ಚಿಕೊಂಡಿವೆ; ಅದರಲ್ಲೂ ವಿಶೇಷವಾಗಿ, ಪರೀಕ್ಷಾ-ಪ್ರೇರಿತ ಅಭಿವೃದ್ಧಿಯನ್ನು ಬಳಸುವ ಗುಂಪುಗಳಲ್ಲಿ ಇದು ಹೆಚ್ಚಾಗಿ ಕಂಡುಬರುತ್ತದೆ. ಪರೀಕ್ಷೆಗಳನ್ನು ಲಿಖಿತರೂಪದಲ್ಲಿ ತಿಳಿಸುವಂತಹ ಅನೇಕ ಚೌಕಟ್ಟುಗಳು ಇಲ್ಲಿ ಅಸ್ತಿತ್ವದಲ್ಲಿವೆ, ಮತ್ತು ಒಂದು ಆವೃತ್ತಿ ನಿಯಂತ್ರಣದ ವ್ಯವಸ್ಥೆಯೊಳಗೆ ಸಂಕೇತವು ಪ್ರತಿ ಬಾರಿಯೂ ಪ್ರವೇಶಿಸಿದಾಗಲೂ, ನಿರಂತರ ಸಮಗ್ರೀಕರಣದ ತಂತ್ರಾಂಶವು ಪರೀಕ್ಷೆಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಚಾಲಿಸುತ್ತದೆ.

ಓರ್ವ ಮಾನವನು ಸೃಷ್ಟಿಸಬಲ್ಲ ರೀತಿಯಲ್ಲಿ ಪ್ರತಿಯೊಂದನ್ನೂ (ಮತ್ತು ಅದನ್ನು ಮಾಡುವುದರ ಕುರಿತು ಅವರು ಆಲೋಚಿಸುವ ಎಲ್ಲಾ ಮಾರ್ಗಗಳನ್ನು) ಸ್ವಯಂಚಾಲನ ತಂತ್ರವು ಮರುಸೃಷ್ಟಿಸಲಾರದಾದರೂ, ನಿವರ್ತನ ಪರೀಕ್ಷೆಗೆ ಸಂಬಂಧಿಸಿದಂತೆ ಅದು ಅತ್ಯಂತ ಪ್ರಯೋಜನಕಾರಿಯಾಗಬಲ್ಲದು. ಆದಾಗ್ಯೂ, ನಿಜವಾಗಿಯೂ ಪ್ರಯೋಜನಕಾರಿಯಾಗಿ ಪರಿಣಮಿಸುವ ದೃಷ್ಟಿಯಿಂದ ಪರೀಕ್ಷಾ ಮೂಲಪ್ರತಿಗಳ ಒಂದು ಚೆನ್ನಾಗಿ-ಅಭಿವೃದ್ಧಿಪಡಿಸಲ್ಪಟ್ಟ ಪರೀಕ್ಷಾ ಮಾಲಿಕೆಯನ್ನು ಇದು ಹೊಂದುವುದು ಅಗತ್ಯವಾಗಿರುತ್ತದೆ.

ಪರೀಕ್ಷಾ ಸಾಧನಗಳು[ಬದಲಾಯಿಸಿ]

ಪರೀಕ್ಷಾ ಸಾಧನಗಳು ಮತ್ತು ದೋಷ ತೆಗೆದುಹಾಕುವ ಸಾಧನಗಳ ನೆರವಿನಿಂದ ಕಾರ್ಯಸೂಚಿ ಪರೀಕ್ಷೆ ಮತ್ತು ದೋಷದ ಪತ್ತೆಹಚ್ಚುವಿಕೆಯನ್ನು ಗಮನಾರ್ಹವಾಗಿ ಕೈಗೊಳ್ಳಬಹುದು. ಪರೀಕ್ಷಾ ಸಾಧನಗಳು/ದೋಷ ತೆಗೆದುಹಾಕುವ ಸಾಧನಗಳಲ್ಲಿ ಈ ಕೆಳಗೆ ನಮೂದಿಸಿರುವ ಲಕ್ಷಣಗಳು ಸೇರಿರುತ್ತವೆ:

ಕಾರ್ಯಸೂಚಿ ಮುನ್ಸೂಚಕಗಳು: ಕಾರ್ಯಸೂಚಿ ಸಂಕೇತದ ಪೂರ್ಣ ಅಥವಾ ಆಂಶಿಕ ಮುನ್ಸೂಚನೆಗಳಿಗೆ ಇವು ಅವಕಾಶ ನೀಡುತ್ತವೆ. ಅಂಥ ಮುನ್ಸೂಚನೆಗಳಲ್ಲಿ ಇವು ಸೇರಿವೆ:
- ಸೂಚನಾ ಸಜ್ಜಿಕೆಯ ಅನುಕರಣಕಾರಕ: ಸೂಚನಾ ಮಟ್ಟದ ಸಂಪೂರ್ಣ ಮುನ್ಸೂಚನೆ ಮತ್ತು ಪತ್ತೆ ಸೌಕರ್ಯಗಳಿಗೆ ಇದು ಅವಕಾಶ ನೀಡುತ್ತದೆ
- ಕಾರ್ಯಸೂಚಿ ಸಜೀವ ಚಿತ್ರಿಕೆ: ಮೂಲ ಮಟ್ಟದಲ್ಲಿ ಅಥವಾ ಯಂತ್ರ ಸಂಕೇತದಲ್ಲಿನ ಹಂತ-ಹಂತದ ನೆರವೇರಿಕೆ ಮತ್ತು ಸೋಪಾಧಿಕ ವಿರಾಮದ-ಹಂತಕ್ಕೆ ಇದು ಅವಕಾಶ ನೀಡುತ್ತದೆ
- ಸಂಕೇತ ವ್ಯಾಪ್ತಿಯ ವರದಿಗಳು
ಫಾರ್ಮ್ಯಾಟ್‌ ಮಾಡಲಾದ ಸಂಗ್ರಹಾಗಾರ ಅಥವಾ ಸಾಂಕೇತಿಕವಾದ ದೋಷ ತೆಗೆದುಹಾಕುವಿಕೆ: ದೋಷಪರಿಮಾಣದ ಮೇಲಿನ ಅಥವಾ ಆರಿಸಲ್ಪಟ್ಟ ಘಟ್ಟಗಳಲ್ಲಿನ ಕಾರ್ಯಸೂಚಿ ಚಲ ಪರಿಮಾಣಗಳ ಪರಿಶೀಲನೆಗೆ ಅವಕಾಶನೀಡುವ ಸಾಧನಗಳು
GUI ಮೂಲಕ ಯಂತ್ರ ವ್ಯವಸ್ಥೆಯ-ಮಟ್ಟದ ಪರೀಕ್ಷೆಗಳನ್ನು ಪುನರಾವರ್ತಿಸಲು, ಸ್ವಯಂಚಾಲಿತ ಕಾರ್ಯತ್ಮಕ GUI ಪರೀಕ್ಷಾ ಸಾಧನಗಳನ್ನು ಬಳಸಲಾಗುತ್ತದೆ
ಮಾನದಂಡಗಳು: ಕೈಗೊಳ್ಳಬೇಕಾದ ಓಟದ-ಅವಧಿಯ ಕಾರ್ಯಕ್ಷಮತೆಯ ಹೋಲಿಕೆಗಳಿಗೆ ಇವು ಅವಕಾಶ ನೀಡುತ್ತವೆ
ಕಾರ್ಯಕ್ಷಮತೆಯ ವಿಶ್ಲೇಷಣೆ (ಅಥವಾ ರೇಖಿಸುವ ಉಪಕರಣಗಳು): ಅಪಾಯ ಸ್ಥಳಗಳು ಮತ್ತು ಸಂಪನ್ಮೂಲ ಬಳಕೆಯನ್ನು ಎತ್ತಿತೋರಿಸುವಲ್ಲಿ ಇವು ನೆರವಾಗಬಲ್ಲವು

ಇವುಗಳ ಪೈಕಿಯ ಕೆಲವೊಂದು ಲಕ್ಷಣಗಳನ್ನು ಒಂದು ಸಂಯೋಜಿಸಲ್ಪಟ್ಟ ಅಭಿವೃದ್ಧಿ ಪರಿಸರದೊಳಗೆ (ಇಂಟಿಗ್ರೇಟೆಡ್‌ ಡೆವಲಪ್‌ಮೆಂಟ್‌ ಎನ್ವಿರಾನ್ಮೆಂಟ್‌-IDE) ಒಟ್ಟುಗೂಡಿಸಬಹುದು.

ತಂತ್ರಾಂಶ ಪರೀಕ್ಷೆಯಲ್ಲಿನ ಅಳೆಯುವಿಕೆ[ಬದಲಾಯಿಸಿ]

ಸಾಮಾನ್ಯವಾಗಿ ಹೇಳುವುದಾದರೆ, ಗುಣಮಟ್ಟವೆಂಬುದು ಸರಿಯಾಗಿರುವಿಕೆ, ಸಂಪೂರ್ಣತೆ, ಭದ್ರತೆಯಂಥ^{[ಸೂಕ್ತ ಉಲ್ಲೇಖನ ಬೇಕು]} ವಿಷಯಗಳ ನಿರ್ಬಂಧಕ್ಕೆ ಒಳಗಾಗಿರುತ್ತದೆಯಾದರೂ, ISO ಪ್ರಮಾಣಕವಾದ ISO/IEC 9126 ಅಡಿಯಲ್ಲಿ ವಿವರಿಸಲ್ಪಟ್ಟಿರುವಂಥ ಹೆಚ್ಚು ತಾಂತ್ರಿಕವಾದ ಅವಶ್ಯಕತೆಗಳನ್ನೂ ಅದು ಒಳಗೊಂಡಿರಲು ಸಾಧ್ಯವಿದೆ; ಸಾಮರ್ಥ್ಯ, ವಿಶ್ವಾಸಾರ್ಹತೆ, ದಕ್ಷತೆ, ಸಾಗಿಸಲಾಗುವಿಕೆ, ಸಮರ್ಥನೀಯತೆ, ಹೊಂದಾಣಿಕೆ, ಮತ್ತು ಉಪಯುಕ್ತತೆ ಇವೇ ಅಂಥ ತಾಂತ್ರಿಕ ಅವಶ್ಯಕತೆಗಳಾಗಿವೆ.

ಛಂದೋವಿಧಾನಗಳು (ಅಳತೆಗಳು) ಎಂಬುದಾಗಿ ಅನೇಕವೇಳೆ ಕರೆಯಲ್ಪಡುವ, ಆಗಿಂದಾಗ್ಗೆ-ಬಳಸಲ್ಪಡುವ ಅನೇಕ ತಂತ್ರಾಂಶ ಕ್ರಮಗಳು ಅಸ್ತಿತ್ವದಲ್ಲಿದ್ದು, ತಂತ್ರಾಂಶದ ಸ್ಥಿತಿಗತಿಯನ್ನು ನಿರ್ಣಯಿಸುವಲ್ಲಿ ಅಥವಾ ಪರೀಕ್ಷೆಯ ಸಮರ್ಪಕತೆಯನ್ನು ನಿರ್ಣಯಿಸುವಲ್ಲಿ ನೆರವಾಗಲೆಂದು ಅವನ್ನು ಬಳಸಲಾಗುತ್ತದೆ.

ಪರೀಕ್ಷಾ ಕೃತಕವಸ್ತುಗಳು[ಬದಲಾಯಿಸಿ]

ತಂತ್ರಾಂಶ ಪರೀಕ್ಷಾ ಪ್ರಕ್ರಿಯೆಯು ಹಲವಾರು ಕೃತಕವಸ್ತುಗಳನ್ನು ಸೃಷ್ಟಿಸಬಲ್ಲದು.

ಪರೀಕ್ಷಾ ಯೋಜನೆ: ಪರೀಕ್ಷೆಯ ನಿರ್ದಿಷ್ಟ ವಿವರಣೆಯೊಂದನ್ನು ಒಂದು ಪರೀಕ್ಷಾ ಯೋಜನೆ ಎಂಬುದಾಗಿ ಕರೆಯಲಾಗುತ್ತದೆ. ಯಾವ ಪರೀಕ್ಷಾ ಯೋಜನೆಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ಅಭಿವರ್ಧಕರು ಚೆನ್ನಾಗಿ ಅರಿತಿರುತ್ತಾರೆ ಮತ್ತು ಈ ಮಾಹಿತಿಯನ್ನು ವ್ಯವಸ್ಥಾಪನೆಗೆ ಮತ್ತು ಅಭಿವರ್ಧಕರಿಗೆ ಒದಗಿಸಲಾಗುತ್ತದೆ. ಅವುಗಳ ಸಂಕೇತವನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುವಾಗ ಅಥವಾ ಹೆಚ್ಚುವರಿ ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡುವಾಗ, ಅವರನ್ನು ಹೆಚ್ಚು ಜಾಗರೂಕರನ್ನಾಗಿಸುವುದು ಇದರ ಹಿಂದಿನ ಪರಿಕಲ್ಪನೆಯಾಗಿದೆ. ಒಂದು ಪರೀಕ್ಷಾ ಕಾರ್ಯತಂತ್ರ ಎಂದು ಕರೆಯಲ್ಪಡುವ ಉನ್ನತ-ಮಟ್ಟದ ದಸ್ತಾವೇಜೊಂದನ್ನು ಕೆಲವೊಂದು ಕಂಪನಿಗಳು ಹೊಂದಿರುತ್ತವೆ.

ಪತ್ತೆಹಚ್ಚಲು ಸಾಧ್ಯವಿರುವಿಕೆಯ ಜಾಲ: ಪತ್ತೆಹಚ್ಚಲು ಸಾಧ್ಯವಿರುವಿಕೆಯ ಜಾಲ ಎಂಬುದು ಒಂದು ಕೋಷ್ಟಕವಾಗಿದ್ದು, ಅದು ಪರೀಕ್ಷಾ ದಸ್ತಾವೇಜುಗಳೊಂದಿಗೆ ಅವಶ್ಯಕತೆಗಳನ್ನು ಅಥವಾ ವಿನ್ಯಾಸ ದಸ್ತಾವೇಜುಗಳನ್ನು ಪರಸ್ಪರ ಸಂಬಂಧಿಸುತ್ತದೆ. ಮೂಲ ದಸ್ತಾವೇಜುಗಳು ಬದಲಾಯಿಸಲ್ಪಟ್ಟಾಗ ಪರೀಕ್ಷೆಗಳನ್ನು ಬದಲಾಯಿಸಲು, ಅಥವಾ ಪರೀಕ್ಷಾ ಫಲಿತಾಂಶಗಳು ಸರಿಯಾಗಿವೆ ಎಂಬುದನ್ನು ಪರಿಶೀಲಿಸಲು ಇದನ್ನು ಬಳಸಲಾಗುತ್ತದೆ.

ಪರೀಕ್ಷಾ ನಿದರ್ಶನ: ಪರೀಕ್ಷಾ ನಿದರ್ಶನವೊಂದು ಸಾಮಾನ್ಯವಾಗಿ ಇವೆಲ್ಲವನ್ನೂ ಒಳಗೊಂಡಿರುತ್ತದೆ: ಒಂದು ಅನನ್ಯ ಗುರುತುಕಾರಕ, ವಿನ್ಯಾಸದ ನಿರ್ದಿಷ್ಟ ವಿವರಣೆಯೊಂದರಿಂದ ಬಂದ ಅವಶ್ಯಕತೆಯ ಉಲ್ಲೇಖಗಳು, ಪೂರ್ವಭಾವಿ ಸ್ಥಿತಿಗತಿಗಳು, ಘಟನೆಗಳು, ದತ್ತ-ಮಾಹಿತಿ, ಫಲಿತ-ಮಾಹಿತಿ, ನಿರೀಕ್ಷಿಸಲ್ಪಟ್ಟ ಫಲಿತಾಂಶ ಹಾಗೂ ವಾಸ್ತವಿಕ ಫಲಿತಾಂಶವನ್ನು ಅನುಸರಿಸುವುದಕ್ಕಾಗಿರುವ ಹಂತಗಳ (ಇವನ್ನು ಕ್ರಮಗಳು ಎಂದೂ ಕರೆಯಲಾಗುತ್ತದೆ) ಒಂದು ಸರಣಿ. ಪ್ರಾಯೋಗಿಕವಾಗಿ ವ್ಯಾಖ್ಯಾನಿಸಲ್ಪಟ್ಟಿರುವ ಪ್ರಕಾರ, ಪರೀಕ್ಷಾ ನಿದರ್ಶನ ಎಂಬುದು ಒಂದು ದತ್ತ-ಮಾಹಿತಿ ಮತ್ತು ಒಂದು ನಿರೀಕ್ಷಿತ ಫಲಿತಾಂಶವಾಗಿರುತ್ತದೆ.^[೩೪] "ಷರತ್ತು xಗೆ ಸಂಬಂಧಿಸಿದಂತೆ ನೀವು ಪಡೆದ ಫಲಿತಾಂಶವು y ಆಗಿದೆ" ಎಂಬ ರೀತಿಯಲ್ಲಿ ಇದು ಪ್ರಾಯೋಗಿಕವಾಗಿರಲು ಸಾಧ್ಯವಿದ್ದರೆ, ದತ್ತ-ಮಾಹಿತಿಯ ಸನ್ನಿವೇಶ ಹಾಗೂ ಯಾವ ಫಲಿತಾಂಶಗಳನ್ನು ನಿರೀಕ್ಷಿಸಬಹುದು ಎಂಬುದನ್ನು ಇತರ ಪರೀಕ್ಷಾ ಪ್ರಕರಣಗಳು ಹೆಚ್ಚು ವಿವರವಾಗಿ ವಿವರಿಸಿವೆ. ಪ್ರಾಸಂಗಿಕವಾಗಿ ಇದು ಹಂತಗಳ ಒಂದು ಸರಣಿಯಾಗಿರಲು ಸಾಧ್ಯವಿದೆಯಾದರೂ (ಆದರೆ, ವಾಸ್ತವವಾಗಿ ಮಿತವ್ಯಯದ ಕಾರಣದಿಂದಾಗಿ ಅನೇಕ ಪರೀಕ್ಷಾ ಪ್ರಕರಣಗಳಿಗೆ ಪ್ರತಿಯಾಗಿ ಚಲಾಯಿಸಲ್ಪಡಬಹುದಾದ ಪ್ರತ್ಯೇಕ ಪರೀಕ್ಷಾ ಕ್ರಮವಿಧಾನವೊಂದರಲ್ಲಿ ಅನೇಕವೇಳೆ ಹಂತಗಳು ಸೇರಿಕೊಂಡಿರಬಹುದಾಗಿದೆ), ಒಂದು ನಿರೀಕ್ಷಿತ ಫಲಿತಾಂಶ ಅಥವಾ ನಿರೀಕ್ಷಿತ ಪರಿಣಾಮವನ್ನು ಇದು ಹೊಂದಿರಲು ಸಾಧ್ಯವಿದೆ. ಐಚ್ಛಿಕ ಕ್ಷೇತ್ರಗಳಲ್ಲಿ ಇವೆಲ್ಲವೂ ಸೇರಿವೆ: ಒಂದು ಪರೀಕ್ಷಾ ನಿದರ್ಶನದ ID, ಪರೀಕ್ಷಾ ಹಂತ, ಅಥವಾ ನೆರವೇರಿಕೆ ಸಂಖ್ಯೆಯ ಅನುಕ್ರಮ, ಸಂಬಂಧಿಸಿದ ಅವಶ್ಯಕತೆ(ಗಳು), ಆಳ, ಪರೀಕ್ಷಾ ವರ್ಗ, ಲೇಖಕ, ಹಾಗೂ ಪರೀಕ್ಷೆಯು ಸ್ವಯಂಚಾಲನಗೊಳಿಸಬಲ್ಲ ಲಕ್ಷಣವನ್ನು ಹೊಂದಿದೆಯೇ ಮತ್ತು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸಲ್ಪಟ್ಟಿದೆಯೇ ಎಂಬುದಕ್ಕೆ ಸಂಬಂಧಿಸಿದಂತಿರುವ ತಾಳೆ-ಪೆಟ್ಟಿಗೆಗಳು. ದೊಡ್ಡದಾದ ಪರೀಕ್ಷಾ ಪ್ರಕರಣಗಳು ಪೂರ್ವಾಪೇಕ್ಷಿತ ಸ್ಥಿತಿಗತಿಗಳು ಅಥವಾ ಹಂತಗಳು, ಮತ್ತು ವಿವರಣೆಗಳನ್ನೂ ಸಹ ಒಳಗೊಂಡಿರಬಹುದು. ಪರೀಕ್ಷಾ ನಿದರ್ಶನವೊಂದು ವಾಸ್ತವಿಕ ಫಲಿತಾಂಶಕ್ಕೆ ಸಂಬಂಧಿಸಿದಂತೆ ಒಂದು ಸ್ಥಳವನ್ನೂ ಸಹ ಒಳಗೊಂಡಿರುವುದು ಅಗತ್ಯವಾಗಿರುತ್ತದೆ. ಈ ಹಂತಗಳನ್ನು ಒಂದು ಶಬ್ದ ಸಂಸ್ಕಾರಕ (ವರ್ಡ್‌ ಪ್ರೊಸೆಸರ್‌)‌ ದಸ್ತಾವೇಜು, ಹರವುಹಾಳೆ (ಸ್ಪ್ರೆಡ್‌ಶೀಟ್‌), ದತ್ತಾಂಶ ಸಂಗ್ರಹ, ಅಥವಾ ಇತರ ಸಾಮಾನ್ಯ ಭಂಡಾರದಲ್ಲಿ ಶೇಖರಿಸಿಡಲು ಸಾಧ್ಯವಿದೆ. ಹಿಂದಿನ ಪರೀಕ್ಷಾ ಫಲಿತಾಂಶಗಳು, ಫಲಿತಾಂಶಗಳನ್ನು ಸೃಷ್ಟಿಸಿದ್ದು ಯಾರು, ಮತ್ತು ಆ ಫಲಿತಾಂಶಗಳನ್ನು ಸೃಷ್ಟಿಸಲು ಯಂತ್ರ ವ್ಯವಸ್ಥೆಯ ಯಾವ ರಚನಾ ಸ್ವರೂಪವನ್ನು ಬಳಸಲಾಯಿತು ಎಂಬುದನ್ನೂ ಸಹ ದತ್ತಾಂಶ ಸಂಗ್ರಹದ ವ್ಯವಸ್ಥೆಯೊಂದರಲ್ಲಿ ನೀವು ನೋಡಬಹುದು. ಈ ಹಿಂದಿನ ಫಲಿತಾಂಶಗಳು ಒಂದು ಪ್ರತ್ಯೇಕ ಕೋಷ್ಟಕದಲ್ಲಿ ಸಾಮಾನ್ಯವಾಗಿ ಶೇಖರಿಸಲ್ಪಟ್ಟಿರುತ್ತವೆ.

ಪರೀಕ್ಷಾ ಮೂಲಪ್ರತಿ: ಪರೀಕ್ಷಾ ಮೂಲಪ್ರತಿ ಎಂಬುದು ಒಂದು ಪರೀಕ್ಷಾ ನಿದರ್ಶನ, ಪರೀಕ್ಷಾ ಕ್ರಮವಿಧಾನ, ಮತ್ತು ಪರೀಕ್ಷಾ ದತ್ತಾಂಶದ ಸಂಯೋಜನೆಯಾಗಿರುತ್ತದೆ. ಸ್ವಯಂಚಾಲಿತ ನಿವರ್ತನ ಪರೀಕ್ಷಾ ಸಾಧನಗಳಿಂದ ಸೃಷ್ಟಿಸಲ್ಪಟ್ಟ ಕಾರ್ಯದ ಉತ್ಪನ್ನದಿಂದ ಈ ಶಬ್ದವನ್ನು ಆರಂಭದಲ್ಲಿ ಪಡೆಯಲಾಯಿತು. ಇಂದು, ಪರೀಕ್ಷಾ ಮೂಲಪ್ರತಿಗಳು ಕೈಯಿಂದ ಮಾಡಿದ, ಸ್ವಯಂಚಾಲಿತವಾದ ಅಥವಾ ಎರಡೂ ಸ್ವರೂಪಗಳ ಒಂದು ಸಂಯೋಜನೆಯಾಗಿರಲು ಸಾಧ್ಯವಿದೆ.

ಪರೀಕ್ಷಾ ಮಾಲಿಕೆ: ಒಂದು ಪರೀಕ್ಷಾ ಮಾಲಿಕೆ ಎಂಬುದು ಪರೀಕ್ಷಾ ಪ್ರಕರಣಗಳ ಒಂದು ಸಂಗ್ರಹಕ್ಕೆ ಮೀಸಲಾದ ಅತ್ಯಂತ ಸಾಮಾನ್ಯ ಶಬ್ದವಾಗಿದೆ. ಪರೀಕ್ಷಾ ಪ್ರಕರಣಗಳ ಪ್ರತಿ ಸಂಗ್ರಹಕ್ಕೆ ಸಂಬಂಧಿಸಿದ ಹೆಚ್ಚು ವಿವರವಾದ ಸೂಚನೆಗಳು ಅಥವಾ ಗುರಿಗಳನ್ನೂ ಸಹ ಪರೀಕ್ಷಾ ಮಾಲಿಕೆಯು ಅನೇಕವೇಳೆ ಒಳಗೊಳ್ಳುತ್ತದೆ. ಪರೀಕ್ಷೆಯ ಸಂದರ್ಭದಲ್ಲಿ ಯಂತ್ರ ವ್ಯವಸ್ಥೆಯ ರಚನಾ ಸ್ವರೂಪವನ್ನು ಪರೀಕ್ಷಕನು ಗುರುತಿಸುವಲ್ಲಿನ ವಿಭಾಗವನ್ನು ಇದು ನಿಶ್ಚಿತವಾಗಿಯೂ ಒಳಗೊಂಡಿರುತ್ತದೆ. ಪರೀಕ್ಷಾ ನಿದರ್ಶನಗಳ ಒಂದು ಗುಂಪಿನಲ್ಲಿ ಪೂರ್ವಾಪೇಕ್ಷಿತ ಸ್ಥಿತಿಗತಿಗಳು ಅಥವಾ ಹಂತಗಳು ಮತ್ತು ಈ ಕೆಳಕಾಣಿಸಿದ ಪರೀಕ್ಷೆಗಳ ವಿವರಣೆಗಳೂ ಸಹ ಸೇರಿಕೊಂಡಿರಬಹುದು.

ಪರೀಕ್ಷಾ ದತ್ತಾಂಶ: ಬಹುತೇಕ ಪ್ರಕರಣಗಳಲ್ಲಿ, ನಿರ್ದಿಷ್ಟ ಲಕ್ಷಣವೊಂದರ ಅದೇ ಕಾರ್ಯತ್ಮಕತೆಯನ್ನು ಪರೀಕ್ಷಿಸಲು ಮೌಲ್ಯಗಳ ಅಥವಾ ದತ್ತಾಂಶದ ಅನೇಕ ವರ್ಗಗಳು ಬಳಸಲ್ಪಡುತ್ತವೆ. ಎಲ್ಲಾ ಪರೀಕ್ಷಾ ಮೌಲ್ಯಗಳು ಮತ್ತು ಬದಲಾಯಿಸಬಹುದಾದ ಪರಿಸರೀಯ ಅಂಗಭಾಗಗಳು ಪ್ರತ್ಯೇಕ ಕಡತಗಳಲ್ಲಿ ಸಂಗ್ರಹಿಸಲ್ಪಟ್ಟಿರುತ್ತವೆ ಹಾಗೂ ಪರೀಕ್ಷಾ ದತ್ತಾಂಶವಾಗಿ ಶೇಖರಿಸಲ್ಪಟ್ಟಿರುತ್ತವೆ. ಉತ್ಪನ್ನ ಅಥವಾ ಒಂದು ಯೋಜನೆಯೊಂದಿಗೆ ಈ ದತ್ತಾಂಶವನ್ನು ಗಿರಾಕಿಗೆ ಒದಗಿಸುವುದು ಕೂಡಾ ಪ್ರಯೋಜನಕಾರಿಯಾಗಿರುತ್ತದೆ.

ಪರೀಕ್ಷಾ ಸರಂಜಾಮು: ತಂತ್ರಾಂಶ, ಉಪಕರಣಗಳು, ದತ್ತಾಂಶ ಪ್ರದಾನ ಮತ್ತು ಫಲಿತ ಮಾಹಿತಿಯ ಮಾದರಿಗಳು, ಮತ್ತು ರಚನಾ ಸ್ವರೂಪಗಳೆಲ್ಲವನ್ನೂ ಒಟ್ಟಾಗಿ ಒಂದು ಪರೀಕ್ಷಾ ಸರಂಜಾಮು ಎಂಬುದಾಗಿ ಉಲ್ಲೇಖಿಸಲಾಗುತ್ತದೆ.

ಪ್ರಮಾಣೀಕರಣಗಳು[ಬದಲಾಯಿಸಿ]

ತಂತ್ರಾಂಶದ ಪರೀಕ್ಷಕರು ಮತ್ತು ಗುಣಮಟ್ಟ ಖಾತರಿಯ ಪರಿಣತರ ವೃತ್ತಿಪರ ಮಹತ್ವಾಕಾಂಕ್ಷೆಗಳನ್ನು ಬೆಂಬಲಿಸುವ ಸಲುವಾಗಿ ಹಲವಾರು ಪ್ರಮಾಣೀಕರಣದ ಕಾರ್ಯಸೂಚಿಗಳು ಚಾಲ್ತಿಯಲ್ಲಿವೆ. ತಂತ್ರಾಂಶವನ್ನು ಪರೀಕ್ಷಿಸುವುದಕ್ಕಿರುವ ಸಾಮರ್ಥ್ಯವನ್ನು ಅಭ್ಯರ್ಥಿಯು ನಿರೂಪಿಸಬೇಕು ಎಂಬುದಾಗಿ ಪ್ರಸಕ್ತವಾಗಿ ನೀಡಲ್ಪಟ್ಟ ಯಾವುದೇ ಪ್ರಮಾಣೀಕರಣವು ವಾಸ್ತವವಾಗಿ ಬಯಸುವುದಿಲ್ಲ. ವ್ಯಾಪಕವಾಗಿ ಅಂಗೀಕರಿಸಲ್ಪಟ್ಟ ಜ್ಞಾನದ ಘಟಕವೊಂದರ ಮೇಲೆ ಯಾವ ಪ್ರಮಾಣೀಕರಣವೂ ಆಧರಿತವಾಗಿಲ್ಲ. ಪರೀಕ್ಷಾ ಕ್ಷೇತ್ರವು ಪ್ರಮಾಣೀಕರಣಕ್ಕೆ ಸಂಬಂಧಿಸಿದಂತೆ ಸಿದ್ಧವಾಗಿಲ್ಲ ಎಂಬುದಾಗಿ ಕೆಲವರು ಘೋಷಿಸುವುದಕ್ಕೆ ಇದು ಕಾರಣವಾಗಿದೆ.^[೩೫] ಸ್ವತಃ ಪ್ರಮಾಣೀಕರಣವೊಂದೇ ಓರ್ವ ವ್ಯಕ್ತಿಯ ಉತ್ಪಾದಕತೆ, ಆತನ ಪರಿಣತಿ, ಅಥವಾ ಪ್ರಾಯೋಗಿಕ ಜ್ಞಾನವನ್ನು ಅಳೆಯಲಾರದು, ಮತ್ತು ಓರ್ವ ಪರೀಕ್ಷಕನಾಗಿ ಆತ ಹೊಂದಿರುವ ಅರ್ಹತೆ, ಅಥವಾ ವೃತ್ತಿಪರತೆಯ ಕುರಿತಾಗಿ ಖಾತರಿ ನೀಡಲಾರದು.^[೩೬]

ತಂತ್ರಾಂಶ ಪರೀಕ್ಷೆಯ ಪ್ರಮಾಣೀಕರಣದ ಬಗೆಗಳು ಹೀಗಿವೆ

ಪರೀಕ್ಷೆ-ಆಧರಿತ : ಇವು ವಿಧ್ಯುಕ್ತಗೊಳಿಸಿದ ಪರೀಕ್ಷೆಗಳಾಗಿದ್ದು, ಇವುಗಳಲ್ಲಿ ತೇರ್ಗಡೆಯಾಗುವುದು ಅಗತ್ಯ; ಸ್ವಯಂ-ಅಧ್ಯಯನದಿಂದಲೂ ಸಹ ಇವನ್ನು ಕಲಿಯಲು ಸಾಧ್ಯವಿದೆ [ಉದಾಹರಣೆಗೆ ISTQB ಅಥವಾ QAIಗೆ ಸಂಬಂಧಿಸಿದ ಪರೀಕ್ಷೆಗಳು]^[೩೭]
ಶಿಕ್ಷಣ-ಆಧರಿತ : ಇವು ಬೋಧಕರ-ನೇತೃತ್ವದ ವ್ಯಾಸಂಗಾವಧಿಗಳಾಗಿದ್ದು, ಇಲ್ಲಿ ಪ್ರತಿಯೊಂದು ಶಿಕ್ಷಣಕ್ರಮದಲ್ಲೂ ತೇರ್ಗಡೆಯಾಗುವುದು ಅಗತ್ಯವಾಗಿದೆ [ಉದಾಹರಣೆಗೆ ಇಂಟರ್‌‌ನ್ಯಾಷನಲ್‌ ಇನ್‌‌ಸ್ಟಿಟ್ಯೂಟ್‌ ಆಫ್‌ ಸಾಫ್ಟ್‌ವೇರ್‌ ಟೆಸ್ಟಿಂಗ್‌‌ (IIST)].

ಪರೀಕ್ಷಾ ಪ್ರಮಾಣೀಕರಣಗಳು

ಕ್ವಾಲಿಟಿ ಅಶ್ಯೂರೆನ್ಸ್‌ ಇನ್‌‌ಸ್ಟಿಟ್ಯೂಟ್‌ (QAI)^[೩೮] ವತಿಯಿಂದ ನೀಡಲ್ಪಡುವ ಸರ್ಟಿಫಿಕೇಟ್‌ ಅಸೋಸಿಯೇಟ್‌ ಇನ್‌ ಸಾಫ್ಟ್‌ವೇರ್‌ ಟೆಸ್ಟಿಂಗ್‌ (CAST)
ಇಂಟರ್‌‌ನ್ಯಾಷನಲ್‌ ಇನ್‌‌ಸ್ಟಿಟ್ಯೂಟ್‌ ಆಫ್‌ ಸಾಫ್ಟ್‌ವೇರ್‌ ಟೆಸ್ಟಿಂಗ್‌‌ ^[೩೯] ವತಿಯಿಂದ ನೀಡಲ್ಪಡುವ CATe
ಕ್ವಾಲಿಟಿ ಅಶ್ಯೂರೆನ್ಸ್‌ ಇನ್‌‌ಸ್ಟಿಟ್ಯೂಟ್‌ (QAI)^[೩೮] ವತಿಯಿಂದ ನೀಡಲ್ಪಡುವ ಸರ್ಟಿಫೈಡ್‌ ಮ್ಯಾನೇಜರ್‌ ಇನ್‌ ಸಾಫ್ಟ್‌‌ವೇರ್‌ ಟೆಸ್ಟಿಂಗ್‌ (CMST)
ಕ್ವಾಲಿಟಿ ಅಶ್ಯೂರೆನ್ಸ್‌ ಇನ್‌‌ಸ್ಟಿಟ್ಯೂಟ್‌ (QAI)^[೩೮] ವತಿಯಿಂದ ನೀಡಲ್ಪಡುವ ಸರ್ಟಿಫೈಡ್‌ ಸಾಫ್ಟ್‌‌ವೇರ್‌ ಟೆಸ್ಟರ್‌‌ (CSTE)
ಇಂಟರ್‌‌ನ್ಯಾಷನಲ್‌ ಇನ್‌‌ಸ್ಟಿಟ್ಯೂಟ್‌ ಆಫ್‌ ಸಾಫ್ಟ್‌ವೇರ್‌ ಟೆಸ್ಟಿಂಗ್‌‌ ^[೩೯] ವತಿಯಿಂದ ನೀಡಲ್ಪಡುವ ಸರ್ಟಿಫೈಡ್‌ ಸಾಫ್ಟ್‌‌ವೇರ್‌ ಟೆಸ್ಟ್‌ ಪ್ರೊಫೆಷನಲ್‌ (CSTP)
K. J. ರಾಸ್‌ & ಅಸೋಸಿಯೇಟ್ಸ್‌ ^[೪೦] ವತಿಯಿಂದ ನೀಡಲ್ಪಡುವ CSTP (TM) (ಆಸ್ಟ್ರೇಲಿಯಾದ ಆವೃತ್ತಿ)
ಇನ್ಫರ್ಮೇಷನ್‌ ಸಿಸ್ಟಮ್ಸ್‌ ಎಕ್ಸಾಮಿನೇಷನ್ಸ್‌ ಬೋರ್ಡ್‌ ವತಿಯಿಂದ ನೀಡಲ್ಪಡುವ ISEB
ಇಂಟರ್‌‌ನ್ಯಾಷನಲ್‌ ಸಾಫ್ಟ್‌ವೇರ್‌ ಟೆಸ್ಟಿಂಗ್‌ ಕ್ವಾಲಿಫಿಕೇಷನ್‌ ಬೋರ್ಡ್‌ ^[೪೧]^[೪೨] ವತಿಯಿಂದ ನೀಡಲ್ಪಡುವ ISTQB ಸರ್ಟಿಫೈಡ್‌ ಟೆಸ್ಟರ್‌, ಫೌಂಡೇಷನ್‌ ಲೆವೆಲ್‌ (CTFL)
ಇಂಟರ್‌‌ನ್ಯಾಷನಲ್‌ ಸಾಫ್ಟ್‌ವೇರ್‌ ಟೆಸ್ಟಿಂಗ್‌ ಕ್ವಾಲಿಫಿಕೇಷನ್‌ ಬೋರ್ಡ್‌ ^[೪೧]^[೪೨] ವತಿಯಿಂದ ನೀಡಲ್ಪಡುವ ISTQB ಸರ್ಟಿಫೈಡ್‌ ಟೆಸ್ಟರ್‌, ಅಡ್ವಾನ್ಸ್‌ಡ್‌ ಲೆವೆಲ್‌ (CTAL)
ಎಕ್ಸಾಮಿನೇಷನ್‌ ಇನ್‌‌ಸ್ಟಿಟ್ಯೂಟ್‌ ಫಾರ್‌ ಇನ್ಫರ್ಮೇಷನ್‌ ಸೈನ್ಸ್‌ ^[೪೩] ವತಿಯಿಂದ ನೀಡಲ್ಪಡುವ TMPF Tಮ್ಯಾಪ್‌ ನೆಕ್ಸ್ಟ್‌ ಫೌಂಡೇಷನ್‌
ಎಕ್ಸಾಮಿನೇಷನ್‌ ಇನ್‌‌ಸ್ಟಿಟ್ಯೂಟ್‌ ಫಾರ್‌ ಇನ್ಫರ್ಮೇಷನ್‌ ಸೈನ್ಸ್‌ ^[೪೩] ವತಿಯಿಂದ ನೀಡಲ್ಪಡುವ TMPA Tಮ್ಯಾಪ್‌ ನೆಕ್ಸ್ಟ್‌ ಅಡ್ವಾನ್ಸ್ಡ್‌‌

ಗುಣಮಟ್ಟ ಖಾತರಿಯ ಪ್ರಮಾಣೀಕರಣಗಳು

ಕ್ವಾಲಿಟಿ ಅಶ್ಯೂರೆನ್ಸ್‌ ಇನ್‌‌ಸ್ಟಿಟ್ಯೂಟ್‌ (QAI) ವತಿಯಿಂದ ನೀಡಲ್ಪಡುವ CMSQ.^[೩೮]
ಕ್ವಾಲಿಟಿ ಅಶ್ಯೂರೆನ್ಸ್‌ ಇನ್‌‌ಸ್ಟಿಟ್ಯೂಟ್‌ (QAI)^[೩೮] ವತಿಯಿಂದ ನೀಡಲ್ಪಡುವ CSQA
ಅಮೆರಿಕನ್‌ ಸೊಸೈಟಿ ಆಫ್‌ ಕ್ವಾಲಿಟಿ (ASQ)^[೪೪] ವತಿಯಿಂದ ನೀಡಲ್ಪಡುವ CSQE
ಅಮೆರಿಕನ್‌ ಸೊಸೈಟಿ ಆಫ್‌ ಕ್ವಾಲಿಟಿ (ASQ)^[೪೪] ವತಿಯಿಂದ ನೀಡಲ್ಪಡುವ CQIA

ವಿವಾದ[ಬದಲಾಯಿಸಿ]

ಕೆಲವೊಂದು ಪ್ರಮುಖವಾದ ತಂತ್ರಾಂಶ ಪರೀಕ್ಷಾ ವಿವಾದಗಳಲ್ಲಿ ಇವು ಸೇರಿವೆ:

ಯಾವುದನ್ನು ಜವಾಬ್ದಾರಿಯುತ ತಂತ್ರಾಂಶ ಪರೀಕ್ಷೆ ಎಂದು ಕರೆಯಬಹುದು?: ಪರೀಕ್ಷೆಯ^[೪೫] "ಸಂದರ್ಭ-ಪ್ರೇರಿತ" ಶಾಲೆಯ ಸದಸ್ಯರ ಅಭಿಪ್ರಾಯದ ಅನುಸಾರ, ಪರೀಕ್ಷೆಯ ಯಾವುದೇ "ಅತ್ಯುತ್ತಮ ಪರಿಪಾಠಗಳು" ಅಸ್ತಿತ್ವದಲ್ಲಿ ಇಲ್ಲವಾದರೂ, ಅದರ ಬದಲಿಗೆ ಸದರಿ ಪರೀಕ್ಷೆಯು ಪರಿಣತಿಗಳ ಒಂದು ಸಜ್ಜಿಕೆಯಾಗಿದ್ದು, ಪ್ರತಿಯೊಂದು ಅನನ್ಯ ಸನ್ನಿವೇಶಕ್ಕೆ ಹೊಂದಿಕೊಳ್ಳುವ ರೀತಿಯಲ್ಲಿ ಪರೀಕ್ಷಾ ಪರಿಪಾಠಗಳನ್ನು ಆರಿಸಲು ಅಥವಾ ಆವಿಷ್ಕರಿಸಲು ಅದು ಪರೀಕ್ಷಕನಿಗೆ ಅವಕಾಶ ಕಲ್ಪಿಸುತ್ತದೆ^[೪೬]

ಅಗೈಲ್‌ಗೆ ಪ್ರತಿಯಾಗಿ ಸಾಂಪ್ರದಾಯಿಕ ಪರೀಕ್ಷೆ: ಅನಿರ್ದಿಷ್ಟತೆ ಮತ್ತು ಏಕರೂಪದ ಬದಲಾವಣೆಯ ಸ್ಥಿತಿಗತಿಗಳ ಅಡಿಯಲ್ಲಿ ಕಾರ್ಯ ನಿರ್ವಹಿಸುವುದನ್ನು ಪರೀಕ್ಷಕರು ಕಲಿಯಬೇಕೇ ಅಥವಾ ಪ್ರಕ್ರಿಯೆಯ "ಪರಿಪಕ್ವತೆ"ಯ ಕಡೆಗೆ ಅವರು ಗುರಿಯಿರಿಸಿಕೊಳ್ಳಬೇಕೇ? ಅಗೈಲ್ ಪರೀಕ್ಷಾ ಚಟುವಟಿಕೆಯು ಮುಖ್ಯವಾಗಿ ವಾಣಿಜ್ಯ ವಲಯಗಳಲ್ಲಿ^[೪೭]^[೪೮] 2006ರಿಂದಲೂ ಬೆಳೆಯುತ್ತಿರುವ ಜನಪ್ರಿಯತೆಗೆ ಸಾಕ್ಷಿಯಾಗಿದ್ದರೆ, ಸರ್ಕಾರಕ್ಕೆ ಮತ್ತು ಸೇನೆಗೆ^[೪೯] ತಂತ್ರಾಂಶವನ್ನು ಒದಗಿಸುವವರು ಸಾಂಪ್ರದಾಯಿಕವಾದ ಪರೀಕ್ಷೆಯ-ಕೊನೆಯ ಮಾದರಿಗಳ (ಉದಾಹರಣೆಗೆ ಜಲಪಾತ ಮಾದರಿಯಲ್ಲಿ) ಪರವಾಗಿ ಈ ವಿಧಾನಶಾಸ್ತ್ರವನ್ನು^{[neutrality is disputed]} ಸ್ವೀಕರಿಸುವಲ್ಲಿ ನಿಧಾನಗತಿಯನ್ನು ತೋರಿಸಿದ್ದಾರೆ.

Exploratory test vs. scripted^[೫೦]: ಪರೀಕ್ಷೆಗಳು ಕಾರ್ಯಗತಗೊಳಿಸಲ್ಪಡುವ ಅದೇ ಸಮಯದಲ್ಲಿಯೇ ಅವು ವಿನ್ಯಾಸಗೊಳ್ಳಬೇಕೇ ಅಥವಾ ಅವು ಮುಂಗಡವಾಗಿ ವಿನ್ಯಾಸಗೊಳ್ಳಬೇಕೇ?

ಕೈಯಿಂದ ಮಾಡಿದ ಪರೀಕ್ಷೆಗೆ ಪ್ರತಿಯಾಗಿ ಸ್ವಯಂಚಾಲಿತ ಪರೀಕ್ಷೆ: ಕೆಲವೊಂದು ಬರಹಗಾರರು ಅಭಿಪ್ರಾಯಪಡುವ ಪ್ರಕಾರ, ಪರೀಕ್ಷಾ ಸ್ವಯಂಚಾಲನೆಯು ಅದರ ಮೌಲ್ಯದೊಂದಿಗೆ ಹೋಲಿಸಿದಾಗ ತೀರಾ ದುಬಾರಿಯಾಗಿರುವುದರಿಂದ, ಅದನ್ನು ಮಿತವಾಗಿ ಬಳಸಬೇಕು.^[೫೧] ಇನ್ನೂ ಹೆಚ್ಚು ನಿರ್ದಿಷ್ಟವಾಗಿ ಹೇಳುವುದಾದರೆ, ಪರೀಕ್ಷಾ-ಪ್ರೇರಿತ ಅಭಿವೃದ್ಧಿಯು ಅಭಿಪ್ರಾಯಪಡುವ ಪ್ರಕಾರ, ಅಭಿವರ್ಧಕರು ಕಾರ್ಯತ್ಮಕತೆಯನ್ನು ಸಂಕೇತಿಸುವುದಕ್ಕೆ ಮುಂಚಿತವಾಗಿ Xಘಟಕದ ಬಗೆಯ ಘಟಕ-ಪರೀಕ್ಷೆಗಳನ್ನು ಬರೆಯಬೇಕು. ಆಗ ಮಾತ್ರವೇ ಅವಶ್ಯಕತೆಗಳನ್ನು ಸೆರೆಹಿಡಿಯುವ ಮತ್ತು ಅನುಷ್ಠಾನಗೊಳಿಸುವ ಒಂದು ಮಾರ್ಗವಾಗಿ ಪರೀಕ್ಷೆಗಳನ್ನು ಪರಿಗಣಿಸಲು ಸಾಧ್ಯ.

Software design vs. software implementation^[೫೨]: ಪರೀಕ್ಷೆಯನ್ನು ಕೇವಲ ಅಂತ್ಯದಲ್ಲಿ ಮಾತ್ರವೇ ನಿರ್ವಹಿಸಬೇಕೇ ಅಥವಾ ಇಡೀ ಪ್ರಕ್ರಿಯೆಯ ಉದ್ದಕ್ಕೂ ನಡೆಸಿಕೊಂಡು ಹೋಗಬೇಕೇ?

ಕಾವಲುಗಾರರನ್ನು ಯಾರು ಕಾಯುತ್ತಾರೆ?: ಯಾವುದೇ ಸ್ವರೂಪದ ವೀಕ್ಷಣೆಯೂ ಸಹ ಒಂದು ಪಾರಸ್ಪರಿಕ ಕ್ರಿಯೆ ಎಂಬುದು ಇದರ ಹಿಂದಿರುವ ಪರಿಕಲ್ಪನೆ-ಯಾವುದು ಪರೀಕ್ಷಿಸಲ್ಪಡುತ್ತಿದೆ ಎಂಬುದರ ಮೇಲೂ ಸಹ ಪರೀಕ್ಷೆಯ ಕ್ರಮವು ಪರಿಣಾಮ ಬೀರಬಹುದು.^[೫೩]

ಇವನ್ನೂ ಗಮನಿಸಿ[ಬದಲಾಯಿಸಿ]

Page ಮಾಡ್ಯೂಲ್:Portal/styles.css has no content.

ಪುಸ್ತಕ: Software testing

ವಿಕಿಪೀಡಿಯ ಪುಸ್ತಕಗಳು ಲೇಖನಗಳ ಸಂಗ್ರಹ. ಇದನ್ನು ಇಳಿಸಿಕೊಳ್ಲಬಹುದು ಅಥವಾ ಮುದ್ರಣಕ್ಕೆ ಆದೇಶಿಸಬಹುದು.

ಎಲ್ಲಾ-ಜೋಡಿಗಳ ಪರೀಕ್ಷೆ
ಸ್ವಯಂಚಾಲಿತ ಪರೀಕ್ಷೆ
ಚಲನಶೀಲ ಕಾರ್ಯಸೂಚಿಯ ವಿಶ್ಲೇಷಣೆ
ಔಪಚಾರಿಕ ಪರಿಶೀಲನೆ
GUI ತಂತ್ರಾಂಶ ಪರೀಕ್ಷೆ
ಕೈಯಿಂದ ಮಾಡಿದ ಪರೀಕ್ಷೆ
ಲಂಬಕೋನೀಯ ಶ್ರೇಣಿ ಪರೀಕ್ಷೆ
ಜೋಡಿ ಪರೀಕ್ಷೆ
ಹಿಮ್ಮೊಗದ ಲಾಕ್ಷಣಿಕ ಪತ್ತೆಹಚ್ಚಲು ಸಾಧ್ಯವಿರುವಿಕೆ
ತಂತ್ರಾಂಶ ಪರೀಕ್ಷಣೀಯತೆ
ಸ್ಥಾಯೀ ಸಂಕೇತ ವಿಶ್ಲೇಷಣೆ
ವೆಬ್‌‌ ಪರೀಕ್ಷೆ

ಉಲ್ಲೇಖಗಳು[ಬದಲಾಯಿಸಿ]

↑ ಎಕ್ಸ್‌ಪ್ಲೊರೇಟರಿ ಟೆಸ್ಟಿಂಗ್‌ Archived 2009-01-26 ವೇಬ್ಯಾಕ್ ಮೆಷಿನ್ ನಲ್ಲಿ., ಸೆಮ್‌ ಕೇನರ್‌‌, ಫ್ಲೋರಿಡಾ ಇನ್‌‌ಸ್ಟಿಟ್ಯೂಟ್‌ ಆಫ್‌ ಟೆಕ್ನಾಲಜಿ, ಕ್ವಾಲಿಟಿ ಅಶ್ಯೂರೆನ್ಸ್‌ ಇನ್‌‌ಸ್ಟಿಟ್ಯೂಟ್‌ ವರ್ಲ್ಡ್‌ವೈಡ್‌ ಆನ್ಯುಯಲ್‌ ಸಾಫ್ಟ್‌ವೇರ್‌ ಟೆಸ್ಟಿಂಗ್‌‌ ಕಾನ್ಫರೆನ್ಸ್‌ , ಓರ್ಲೆಂಡೊ, FL, ನವೆಂಬರ್‌ 2006
↑ ಲೀಟ್ನರ್, A., ಸಿಯುಪಾ, I., ಒರಿಯೋಲ್‌, M., ಮೆಯೆರ್‌‌, B., ಫಿವಾ, A., "ಕಾಂಟ್ರಾಕ್ಟ್‌ ಡ್ರಿವನ್‌ ಡೆವಲಪ್‌ಮೆಂಟ್‌ = ಟೆಸ್ಟ್‌ ಡ್ರಿವನ್‌ ಡೆವಲಪ್‌ಮೆಂಟ್‌ - ರೈಟಿಂಗ್‌ ಟೆಸ್ಟ್‌ ಕ್ಲಾಸಸ್‌"; ತಂತ್ರಾಂಶ ಎಂಜಿನಿಯರಿಂಗ್‌ನ ತಳಹದಿಗಳ ಕುರಿತಾದ 2007ರ ACM SIGSOFT ವಿಚಾರ ಸಂಕಿರಣ (ಡುಬ್ರೊವ್ನಿಕ್‌‌, ಕ್ರೊವೇಷಿಯಾ) ಮತ್ತು ESEC/FSE'07: ಐರೋಪ್ಯ ತಂತ್ರಾಂಶ ಎಂಜಿನಿಯರಿಂಗ್‌ ಸಮ್ಮೇಳನದ ನಡಾವಳಿಗಳು, 2007ರ ಸೆಪ್ಟೆಂಬರ್‌
↑ ಸಾಪ್ಟ್‌‌ವೇರ್‌ ಎರರ್ಸ್‌ ಕಾಸ್ಟ್‌ U.S. ಇಕಾನಮಿ $59.5 ಬಿಲಿಯನ್‌ ಆನ್ಯುಯಲಿ, NIST ವರದಿ
↑ ^೪.೦ ^೪.೧ Myers, Glenford J. (1979). The Art of Software Testing. John Wiley and Sons. ISBN 0-471-04328-1.
↑ Company, People's Computer (1987). "Dr. Dobb's journal of software tools for the professional programmer". Dr. Dobb's journal of software tools for the professional programmer. M&T Pub. 12 (1–6): 116.
↑ Gelperin, D. (1988). "The Growth of Software Testing". CACM. 31 (6). ISSN 0001-0782. {{cite journal}}: Unknown parameter |coauthors= ignored (|author= suggested) (help)
↑ 1956ರವರೆಗಿನ ಅವಧಿಯು ದೋಷಗಳನ್ನು ತೆಗೆದುಹಾಕುವುದರೆಡೆಗೆ ಉದ್ದೇಶಿತವಾಗಿದ್ದ ಅವಧಿಯಾಗಿದ್ದು, ಈ ಸಂದರ್ಭದಲ್ಲಿ ದೋಷಗಳನ್ನು ತೆಗೆದುಹಾಕುವುದರೆಡೆಗೆ ಪರೀಕ್ಷೆಯು ಅನೇಕವೇಳೆ ಸಂಬಂಧವನ್ನು ಹೊಂದಿತ್ತು: ಪರೀಕ್ಷೆ ಮತ್ತು ದೋಷಗಳನ್ನು ತೆಗೆದುಹಾಕುವುದರ ನಡುವೆ ಅಲ್ಲಾವ ಸ್ಪಷ್ಟ ವ್ಯತ್ಯಾಸವೂ ಇರಲಿಲ್ಲ. Gelperin, D. (1988). "The Growth of Software Testing". CACM. 31 (6). ISSN 0001-0782. {{cite journal}}: Unknown parameter |coauthors= ignored (|author= suggested) (help)
↑ 1957ರಿಂದ–1978ರವರೆಗಿನ ಅವಧಿಯು ಪ್ರಮಾಣೀಕರಣ ಉದ್ದೇಶಿತ ಅವಧಿಯಾಗಿದ್ದು, ಈ ಸಂದರ್ಭದಲ್ಲಿ ದೋಷಗಳ ತೆಗೆದುಹಾಕುವಿಕೆ ಮತ್ತು ಪರೀಕ್ಷಾ ಪ್ರಕ್ರಿಯೆಗಳು ಪ್ರತ್ಯೇಕಿಸಲ್ಪಟ್ಟವು - ತಂತ್ರಾಂಶವು ಅವಶ್ಯಕತೆಗಳನ್ನು ಪೂರೈಸುತ್ತದೆ ಎಂಬುದು ಈ ಅವಧಿಯಲ್ಲಿ ತೋರಿಸಲ್ಪಟ್ಟಿತು. Gelperin, D. (1988). "The Growth of Software Testing". CACM. 31 (6). ISSN 0001-0782. {{cite journal}}: Unknown parameter |coauthors= ignored (|author= suggested) (help)
↑ 1979 ಮತ್ತು 1982ರ ನಡುವಿನ ಸಮಯವು ವಿನಾಶಕ ಉದ್ದೇಶಿತ ಅವಧಿ ಎಂಬುದಾಗಿ ಘೋಷಿಸಲ್ಪಟ್ಟಿದ್ದು, ತಪ್ಪುಗಳನ್ನು ಕಂಡುಹಿಡಿಯುವುದೇ ಈ ಅವಧಿಯಲ್ಲಿನ ಗುರಿಯಾಗಿತ್ತು. Gelperin, D. (1988). "The Growth of Software Testing". CACM. 31 (6). ISSN 0001-0782. {{cite journal}}: Unknown parameter |coauthors= ignored (|author= suggested) (help)
↑ 1983–1987ರ ಅವಧಿಯು ಮೌಲ್ಯಮಾಪನ ಉದ್ದೇಶಿತ ಅವಧಿ ಎಂಬುದಾಗಿ ವರ್ಗೀಕರಿಸಲ್ಪಟ್ಟಿದೆ: ತಂತ್ರಾಂಶದ ಜೀವಿತಾವಧಿಯ ಕಾಲದಲ್ಲಿ ಉತ್ಪನ್ನದ ಮೌಲ್ಯಮಾಪನವನ್ನು ಒದಗಿಸುವುದು ಮತ್ತು ಗುಣಮಟ್ಟವನ್ನು ಅಳೆಯುವುದು ಇಲ್ಲಿನ ಆಶಯವಾಗಿತ್ತು. Gelperin, D. (1988). "The Growth of Software Testing". CACM. 31 (6). ISSN 0001-0782. {{cite journal}}: Unknown parameter |coauthors= ignored (|author= suggested) (help)
↑ 1988ರಿಂದ ಮೊದಲ್ಗೊಂಡು ಇಲ್ಲಿಯವರೆಗಿನ ಅವಧಿಯನ್ನು ತಡೆಗಟ್ಟುವಿಕೆ ಉದ್ದೇಶಿತ ಅವಧಿ ಎಂಬುದಾಗಿ ಪರಿಗಣಿಸಲಾಗಿದ್ದು, ದೋಷಗಳನ್ನು ಪತ್ತೆಹಚ್ಚುವ ಮತ್ತು ದೋಷಗಳನ್ನು ತಡೆಗಟ್ಟುವ ಸಲುವಾಗಿ ತಂತ್ರಾಂಶವು ತನ್ನ ನಿರ್ದಿಷ್ಟ ವಿವರಣೆಯನ್ನು ಪೂರೈಸುತ್ತದೆ ಎಂಬುದನ್ನು ನಿರೂಪಿಸುವುದು ಈ ಅವಧಿಯಲ್ಲಿನ ಪರೀಕ್ಷೆಗಳ ಅಗತ್ಯವಾಗಿತ್ತು. Gelperin, D. (1988). "The Growth of Software Testing". CACM. 31 (6). ISSN 0001-0782. {{cite journal}}: Unknown parameter |coauthors= ignored (|author= suggested) (help)
↑ ^೧೨.೦ ^೧೨.೧ ^೧೨.೨ Kaner, Cem (1999). Testing Computer Software, 2nd Ed. New York, et al: John Wiley and Sons, Inc. pp. 480 pages. ISBN 0-471-35846-0. {{cite book}}: Unknown parameter |coauthors= ignored (|author= suggested) (help) ಉಲ್ಲೇಖ ದೋಷ: Invalid <ref> tag; name "Kaner1" defined multiple times with different content
↑ Kolawa, Adam (2007). Automated Defect Prevention: Best Practices in Software Management. Wiley-IEEE Computer Society Press. pp. 41–43. ISBN 0470042125. {{cite book}}: Unknown parameter |coauthors= ignored (|author= suggested) (help)
↑ Kolawa, Adam (2007). Automated Defect Prevention: Best Practices in Software Management. Wiley-IEEE Computer Society Press. p. 86. ISBN 0470042125. {{cite book}}: More than one of |pages= and |page= specified (help); Unknown parameter |coauthors= ignored (|author= suggested) (help)
↑ ^೧೫.೦ ^೧೫.೧ ವಿಭಾಗ 1.1.2, ಸರ್ಟಿಫೈಡ್‌ ಟೆಸ್ಟರ್‌ ಫೌಂಡೇಷನ್‌ ಲೆವೆಲ್‌ ಸಿಲಬಸ್‌ Archived 2008-12-17 ವೇಬ್ಯಾಕ್ ಮೆಷಿನ್ ನಲ್ಲಿ., ಇಂಟರ್‌‌ನ್ಯಾಷನಲ್‌ ಸಾಫ್ಟ್‌ವೇರ್‌ ಟೆಸ್ಟಿಂಗ್‌ ಕ್ವಾಲಿಫಿಕೇಷನ್ಸ್‌ ಬೋರ್ಡ್‌
↑ Kaner, Cem (2001). Lessons Learned in Software Testing: A Context-Driven Approach. Wiley. p. 4. ISBN 0-471-08112-4. {{cite book}}: Unknown parameter |coauthors= ignored (|author= suggested) (help)
↑ McConnell, Steve (2004). Code Complete (2nd ed.). Microsoft Press. p. 960. ISBN 0-7356-1967-0.
↑ ತತ್ತ್ವ 2, ವಿಭಾಗ 1.3, ಸರ್ಟಿಫೈಡ್‌ ಟೆಸ್ಟರ್‌ ಫೌಂಡೇಷನ್‌ ಲೆವೆಲ್‌ ಸಿಲಬಸ್‌ Archived 2008-12-17 ವೇಬ್ಯಾಕ್ ಮೆಷಿನ್ ನಲ್ಲಿ., ಇಂಟರ್‌‌ನ್ಯಾಷನಲ್‌ ಸಾಫ್ಟ್‌ವೇರ್‌ ಟೆಸ್ಟಿಂಗ್‌ ಕ್ವಾಲಿಫಿಕೇಷನ್ಸ್‌ ಬೋರ್ಡ್‌
↑ Tran, Eushiuan (1999). "Verification/Validation/Certification". In Koopman, P. (ed.). Topics in Dependable Embedded Systems. USA: Carnegie Mellon University. {{cite book}}: |access-date= requires |url= (help); Unknown parameter |chapterurl= ignored (help)
↑ ನೋಡಿ D. ಗೆಲ್‌ಪೆರಿನ್‌ ಮತ್ತು W.C. ಹೆಟ್‌ಜೆಲ್‌
↑ ಇಂಟ್ರಡಕ್ಷನ್‌, ಕೋಡ್‌ ಕವರೇಜ್‌ ಅನಾಲಿಸಿಸ್‌, ಸ್ಟೀವ್‌ ಕಾರ್ನೆಟ್‌
↑ Laycock, G. T. (1993). "The Theory and Practice of Specification Based Software Testing". Dept of Computer Science, Sheffield University, UK. Archived from the original (PostScript) on 2007-02-14. Retrieved 2008-02-13. {{cite journal}}: Cite journal requires |journal= (help)
↑ Bach, James (1999). "Risk and Requirements-Based Testing" (PDF). Computer. 32 (6): 113–114. Retrieved 2008-08-19. {{cite journal}}: Cite has empty unknown parameter: |coauthors= (help); Unknown parameter |month= ignored (help)
↑ Savenkov, Roman (2008). How to Become a Software Tester. Roman Savenkov Consulting. p. 159. ISBN 978-0-615-23372-7.
↑ Binder, Robert V. (1999). Testing Object-Oriented Systems: Objects, Patterns, and Tools. Addison-Wesley Professional. p. 45. ISBN 0-201-80938-9.
↑ Beizer, Boris (1990). Software Testing Techniques (Second ed.). New York: Van Nostrand Reinhold. pp. 21, 430. ISBN 0-442-20672-0.
↑ IEEE (1990). IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer Glossaries. New York: IEEE. ISBN 1559370793.
↑ e)ಟೆಸ್ಟಿಂಗ್‌ ಫೇಸ್‌ ಇನ್‌ ಸಾಫ್ಟ್‌ವೇರ್‌ ಟೆಸ್ಟಿಂಗ್‌‌:-
↑ Myers, Glenford J. (1979). The Art of Software Testing. John Wiley and Sons. pp. 145–146. ISBN 0-471-04328-1.
↑ Dustin, Elfriede (2002). Effective Software Testing. Addison Wesley. p. 3. ISBN 0-20179-429-2.
↑ Marchenko, Artem (November 16, 2007). "XP Practice: Continuous Integration". Archived from the original on 2011-07-07. Retrieved 2009-11-16. {{cite web}}: Cite has empty unknown parameter: |coauthors= (help)
↑ Gurses, Levent (February 19, 2007). "Agile 101: What is Continuous Integration?". Archived from the original on 2009-01-31. Retrieved 2009-11-16. {{cite web}}: Cite has empty unknown parameter: |coauthors= (help)
↑ Pan, Jiantao (Spring 1999). "Software Testing (18-849b Dependable Embedded Systems)". Topics in Dependable Embedded Systems. Electrical and Computer Engineering Department, Carnegie Mellon University.
↑ IEEE (1998). IEEE standard for software test documentation. New York: IEEE. ISBN 0-7381-1443-X.
↑ Kaner, Cem (2001). "NSF grant proposal to "lay a foundation for significant improvements in the quality of academic and commercial courses in software testing"" (PDF). Archived from the original (pdf) on 2009-11-27. Retrieved 2011-01-10.
↑ Kaner, Cem (2003). "Measuring the Effectiveness of Software Testers" (PDF). Archived from the original (pdf) on 2010-03-26. Retrieved 2011-01-10.
↑ Black, Rex (December 2008). Advanced Software Testing- Vol. 2: Guide to the ISTQB Advanced Certification as an Advanced Test Manager. Santa Barbara: Rocky Nook Publisher. ISBN 1933952369.
↑ ^೩೮.೦ ^೩೮.೧ ^೩೮.೨ ^೩೮.೩ ^೩೮.೪ ಕ್ವಾಲಿಟಿ ಅಶ್ಯೂರೆನ್ಸ್‌ ಇನ್‌‌ಸ್ಟಿಟ್ಯೂಟ್‌
↑ ^೩೯.೦ ^೩೯.೧ "ಇಂಟರ್‌‌ನ್ಯಾಷನಲ್‌ ಇನ್‌‌ಸ್ಟಿಟ್ಯೂಟ್‌ ಆಫ್‌ ಸಾಫ್ಟ್‌ವೇರ್‌ ಟೆಸ್ಟಿಂಗ್‌‌". Archived from the original on 2009-12-23. Retrieved 2011-01-10.
↑ "K. J. ರಾಸ್‌ & ಅಸೋಸಿಯೇಟ್ಸ್‌". Archived from the original on 2008-02-15. Retrieved 2011-01-10.
↑ ^೪೧.೦ ^೪೧.೧ "ISTQB".
↑ ^೪೨.೦ ^೪೨.೧ "ISTQB in the U.S."
↑ ^೪೩.೦ ^೪೩.೧ EXIN: ಎಕ್ಸಾಮಿನೇಷನ್‌ ಇನ್‌‌ಸ್ಟಿಟ್ಯೂಟ್‌ ಫಾರ್‌ ಇನ್ಫರ್ಮೇಷನ್‌ ಸೈನ್ಸ್‌
↑ ^೪೪.೦ ^೪೪.೧ "ಅಮೆರಿಕನ್‌ ಸೊಸೈಟಿ ಆಫ್‌ ಕ್ವಾಲಿಟಿ". Archived from the original on 2009-12-13. Retrieved 2011-01-10.
↑ context-driven-testing.com
↑ ಆರ್ಟಿಕಲ್‌ ಆನ್‌ ಟೇಕಿಂಗ್‌ ಅಗೈಲ್ ಟ್ರೈಟ್ಸ್‌ ವಿಥೌಟ್‌ ದಿ ಅಗೈಲ್ ಮೆಥಡ್‌.
↑ “ವೀ ಆರ್‌ ಆಲ್‌ ಪಾರ್ಟ್‌ ಆಫ್‌ ದಿ ಸ್ಟೋರಿ” Archived 2009-08-31 ವೇಬ್ಯಾಕ್ ಮೆಷಿನ್ ನಲ್ಲಿ. -ಡೇವಿಡ್‌ ಸ್ಟ್ರೋಮ್‌, ಜುಲೈ 1, 2009
↑ IEEE ಆರ್ಟಿಕಲ್‌ ಎಬೌಟ್‌ ಡಿಫರೆನ್ಸಸ್‌ ಇನ್‌ ಅಡಾಪ್ಷನ್‌ ಆಫ್‌ ಅಗೈಲ್ ಟ್ರೆಂಡ್ಸ್‌ ಬಿಟ್ವೀನ್‌ ಎಕ್ಸ್‌ಪೀರಿಯೆನ್ಸ್ಡ್‌ ಮ್ಯಾನೇಜರ್ಸ್‌ vs. ಯಂಗ್‌ ಸ್ಟೂಡೆಂಟ್ಸ್‌ ಆಫ್‌ ದಿ ಪ್ರಾಜೆಕ್ಟ್‌ ಮ್ಯಾನೇಜ್‌ಮೆಂಟ್‌ ಇನ್‌‌ಸ್ಟಿಟ್ಯೂಟ್‌. ಇದನ್ನೂ ನೋಡಿ: ಅಗೈಲ್ ಅಡಾಪ್ಷನ್‌ ಸ್ಟಡಿ ಫ್ರಮ್ 2007
↑ "ಅಗೈಲ್ ಸಾಫ್ಟ್‌ವೇರ್‌ ಡೆವಲಪ್‌ಮೆಂಟ್‌ ಪ್ರಾಕ್ಟೀಸಸ್‌ ಸ್ಲೋಲಿ ಎಂಟರಿಂಗ್‌ ದಿ ಮಿಲಿಟರಿ". Archived from the original on 2010-01-25. Retrieved 2011-01-10.
↑ IEEE article on Exploratory vs. Non Exploratory testing
↑ ಆನ್‌ ಎಕ್ಸಾಂಪಲ್‌ ಈಸ್‌ ಮಾರ್ಕ್‌ ಫ್ಯೂಸ್ಟರ್‌, ಡೊರೊಥಿ ಗ್ರಹಾಂ: ಸಾಫ್ಟ್‌ವೇರ್‌ ಟೆಸ್ಟ್‌ ಆಟೋಮೇಷನ್. ಅಡಿಸನ್‌ ವೆಸ್ಲಿ, 1999, ISBN 0-201-33140-3.
↑ [news/why-evangelising-unit-testing- Article referring to other links questioning the necessity of unit testing]
↑ ‌‌ಮೈಕ್ರೋಸಾಫ್ಟ್ ಡೆವಲಪ್‌ಮೆಂಟ್‌ ನೆಟ್‌ವರ್ಕ್‌ ಡಿಸ್ಕಷನ್‌ ಆನ್‌ ಎಕ್ಸಾಕ್ಟ್‌ಲಿ ದಿಸ್‌ ಟಾಪಿಕ್‌ Archived 2010-02-15 ವೇಬ್ಯಾಕ್ ಮೆಷಿನ್ ನಲ್ಲಿ.

ಬಾಹ್ಯ ಕೊಂಡಿಗಳು[ಬದಲಾಯಿಸಿ]

Software testing tools and products ಓಪನ್ ಡೈರೆಕ್ಟರಿ ಪ್ರಾಜೆಕ್ಟ್
"ಸಾಫ್ಟ್‌‌ವೇರ್‌ ದಟ್‌ ಮೇಕ್ಸ್‌ ಸಾಫ್ಟ್‌‌ವೇರ್‌‌ ಬೆಟರ್‌" Economist.com
ಆಟೋಮೇಟೆಡ್‌ ಸಾಫ್ಟ್‌‌ವೇರ್‌ ಟೆಸ್ಟಿಂಗ್‌ ಮೆಟ್ರಿಕ್ಸ್‌ ಇನ್‌ಕ್ಲೂಡಿಂಗ್‌ ಮ್ಯಾನುಯಲ್‌ ಟೆಸ್ಟಿಂಗ್‌ ಮೆಟ್ರಿಕ್ಸ್‌ Archived 2010-07-05 ವೇಬ್ಯಾಕ್ ಮೆಷಿನ್ ನಲ್ಲಿ.

ಟೆಂಪ್ಲೇಟು:Computer Science

REDIRECT Template:Software engineering

[1] ಎಕ್ಸ್‌ಪ್ಲೊರೇಟರಿ ಟೆಸ್ಟಿಂಗ್‌ Archived 2009-01-26 ವೇಬ್ಯಾಕ್ ಮೆಷಿನ್ ನಲ್ಲಿ., ಸೆಮ್‌ ಕೇನರ್‌‌, ಫ್ಲೋರಿಡಾ ಇನ್‌‌ಸ್ಟಿಟ್ಯೂಟ್‌ ಆಫ್‌ ಟೆಕ್ನಾಲಜಿ, ಕ್ವಾಲಿಟಿ ಅಶ್ಯೂರೆನ್ಸ್‌ ಇನ್‌‌ಸ್ಟಿಟ್ಯೂಟ್‌ ವರ್ಲ್ಡ್‌ವೈಡ್‌ ಆನ್ಯುಯಲ್‌ ಸಾಫ್ಟ್‌ವೇರ್‌ ಟೆಸ್ಟಿಂಗ್‌‌ ಕಾನ್ಫರೆನ್ಸ್‌ , ಓರ್ಲೆಂಡೊ, FL, ನವೆಂಬರ್‌ 2006

[2] ಲೀಟ್ನರ್, A., ಸಿಯುಪಾ, I., ಒರಿಯೋಲ್‌, M., ಮೆಯೆರ್‌‌, B., ಫಿವಾ, A., "ಕಾಂಟ್ರಾಕ್ಟ್‌ ಡ್ರಿವನ್‌ ಡೆವಲಪ್‌ಮೆಂಟ್‌ = ಟೆಸ್ಟ್‌ ಡ್ರಿವನ್‌ ಡೆವಲಪ್‌ಮೆಂಟ್‌ - ರೈಟಿಂಗ್‌ ಟೆಸ್ಟ್‌ ಕ್ಲಾಸಸ್‌"; ತಂತ್ರಾಂಶ ಎಂಜಿನಿಯರಿಂಗ್‌ನ ತಳಹದಿಗಳ ಕುರಿತಾದ 2007ರ ACM SIGSOFT ವಿಚಾರ ಸಂಕಿರಣ (ಡುಬ್ರೊವ್ನಿಕ್‌‌, ಕ್ರೊವೇಷಿಯಾ) ಮತ್ತು ESEC/FSE'07: ಐರೋಪ್ಯ ತಂತ್ರಾಂಶ ಎಂಜಿನಿಯರಿಂಗ್‌ ಸಮ್ಮೇಳನದ ನಡಾವಳಿಗಳು, 2007ರ ಸೆಪ್ಟೆಂಬರ್‌

[3] ಸಾಪ್ಟ್‌‌ವೇರ್‌ ಎರರ್ಸ್‌ ಕಾಸ್ಟ್‌ U.S. ಇಕಾನಮಿ $59.5 ಬಿಲಿಯನ್‌ ಆನ್ಯುಯಲಿ, NIST ವರದಿ

[Myers_1979-4] ೪.೦ ^೪.೧ Myers, Glenford J. (1979). The Art of Software Testing. John Wiley and Sons. ISBN 0-471-04328-1.

[5] Company, People's Computer (1987). "Dr. Dobb's journal of software tools for the professional programmer". Dr. Dobb's journal of software tools for the professional programmer. M&T Pub. 12 (1–6): 116.

[6] Gelperin, D. (1988). "The Growth of Software Testing". CACM. 31 (6). ISSN 0001-0782. {{cite journal}}: Unknown parameter |coauthors= ignored (|author= suggested) (help)

[7] 1956ರವರೆಗಿನ ಅವಧಿಯು ದೋಷಗಳನ್ನು ತೆಗೆದುಹಾಕುವುದರೆಡೆಗೆ ಉದ್ದೇಶಿತವಾಗಿದ್ದ ಅವಧಿಯಾಗಿದ್ದು, ಈ ಸಂದರ್ಭದಲ್ಲಿ ದೋಷಗಳನ್ನು ತೆಗೆದುಹಾಕುವುದರೆಡೆಗೆ ಪರೀಕ್ಷೆಯು ಅನೇಕವೇಳೆ ಸಂಬಂಧವನ್ನು ಹೊಂದಿತ್ತು: ಪರೀಕ್ಷೆ ಮತ್ತು ದೋಷಗಳನ್ನು ತೆಗೆದುಹಾಕುವುದರ ನಡುವೆ ಅಲ್ಲಾವ ಸ್ಪಷ್ಟ ವ್ಯತ್ಯಾಸವೂ ಇರಲಿಲ್ಲ. Gelperin, D. (1988). "The Growth of Software Testing". CACM. 31 (6). ISSN 0001-0782. {{cite journal}}: Unknown parameter |coauthors= ignored (|author= suggested) (help)

[8] 1957ರಿಂದ–1978ರವರೆಗಿನ ಅವಧಿಯು ಪ್ರಮಾಣೀಕರಣ ಉದ್ದೇಶಿತ ಅವಧಿಯಾಗಿದ್ದು, ಈ ಸಂದರ್ಭದಲ್ಲಿ ದೋಷಗಳ ತೆಗೆದುಹಾಕುವಿಕೆ ಮತ್ತು ಪರೀಕ್ಷಾ ಪ್ರಕ್ರಿಯೆಗಳು ಪ್ರತ್ಯೇಕಿಸಲ್ಪಟ್ಟವು - ತಂತ್ರಾಂಶವು ಅವಶ್ಯಕತೆಗಳನ್ನು ಪೂರೈಸುತ್ತದೆ ಎಂಬುದು ಈ ಅವಧಿಯಲ್ಲಿ ತೋರಿಸಲ್ಪಟ್ಟಿತು. Gelperin, D. (1988). "The Growth of Software Testing". CACM. 31 (6). ISSN 0001-0782. {{cite journal}}: Unknown parameter |coauthors= ignored (|author= suggested) (help)

[9] 1979 ಮತ್ತು 1982ರ ನಡುವಿನ ಸಮಯವು ವಿನಾಶಕ ಉದ್ದೇಶಿತ ಅವಧಿ ಎಂಬುದಾಗಿ ಘೋಷಿಸಲ್ಪಟ್ಟಿದ್ದು, ತಪ್ಪುಗಳನ್ನು ಕಂಡುಹಿಡಿಯುವುದೇ ಈ ಅವಧಿಯಲ್ಲಿನ ಗುರಿಯಾಗಿತ್ತು. Gelperin, D. (1988). "The Growth of Software Testing". CACM. 31 (6). ISSN 0001-0782. {{cite journal}}: Unknown parameter |coauthors= ignored (|author= suggested) (help)

[10] 1983–1987ರ ಅವಧಿಯು ಮೌಲ್ಯಮಾಪನ ಉದ್ದೇಶಿತ ಅವಧಿ ಎಂಬುದಾಗಿ ವರ್ಗೀಕರಿಸಲ್ಪಟ್ಟಿದೆ: ತಂತ್ರಾಂಶದ ಜೀವಿತಾವಧಿಯ ಕಾಲದಲ್ಲಿ ಉತ್ಪನ್ನದ ಮೌಲ್ಯಮಾಪನವನ್ನು ಒದಗಿಸುವುದು ಮತ್ತು ಗುಣಮಟ್ಟವನ್ನು ಅಳೆಯುವುದು ಇಲ್ಲಿನ ಆಶಯವಾಗಿತ್ತು. Gelperin, D. (1988). "The Growth of Software Testing". CACM. 31 (6). ISSN 0001-0782. {{cite journal}}: Unknown parameter |coauthors= ignored (|author= suggested) (help)

[Gelperin_1988-11] 1988ರಿಂದ ಮೊದಲ್ಗೊಂಡು ಇಲ್ಲಿಯವರೆಗಿನ ಅವಧಿಯನ್ನು ತಡೆಗಟ್ಟುವಿಕೆ ಉದ್ದೇಶಿತ ಅವಧಿ ಎಂಬುದಾಗಿ ಪರಿಗಣಿಸಲಾಗಿದ್ದು, ದೋಷಗಳನ್ನು ಪತ್ತೆಹಚ್ಚುವ ಮತ್ತು ದೋಷಗಳನ್ನು ತಡೆಗಟ್ಟುವ ಸಲುವಾಗಿ ತಂತ್ರಾಂಶವು ತನ್ನ ನಿರ್ದಿಷ್ಟ ವಿವರಣೆಯನ್ನು ಪೂರೈಸುತ್ತದೆ ಎಂಬುದನ್ನು ನಿರೂಪಿಸುವುದು ಈ ಅವಧಿಯಲ್ಲಿನ ಪರೀಕ್ಷೆಗಳ ಅಗತ್ಯವಾಗಿತ್ತು. Gelperin, D. (1988). "The Growth of Software Testing". CACM. 31 (6). ISSN 0001-0782. {{cite journal}}: Unknown parameter |coauthors= ignored (|author= suggested) (help)

[Kaner1-12] ೧೨.೦ ^೧೨.೧ ^೧೨.೨ Kaner, Cem (1999). Testing Computer Software, 2nd Ed. New York, et al: John Wiley and Sons, Inc. pp. 480 pages. ISBN 0-471-35846-0. {{cite book}}: Unknown parameter |coauthors= ignored (|author= suggested) (help) ಉಲ್ಲೇಖ ದೋಷ: Invalid <ref> tag; name "Kaner1" defined multiple times with different content

[kolawa-13] Kolawa, Adam (2007). Automated Defect Prevention: Best Practices in Software Management. Wiley-IEEE Computer Society Press. pp. 41–43. ISBN 0470042125. {{cite book}}: Unknown parameter |coauthors= ignored (|author= suggested) (help)

[14] Kolawa, Adam (2007). Automated Defect Prevention: Best Practices in Software Management. Wiley-IEEE Computer Society Press. p. 86. ISBN 0470042125. {{cite book}}: More than one of |pages= and |page= specified (help); Unknown parameter |coauthors= ignored (|author= suggested) (help)

[ctfl-15] ೧೫.೦ ^೧೫.೧ ವಿಭಾಗ 1.1.2, ಸರ್ಟಿಫೈಡ್‌ ಟೆಸ್ಟರ್‌ ಫೌಂಡೇಷನ್‌ ಲೆವೆಲ್‌ ಸಿಲಬಸ್‌ Archived 2008-12-17 ವೇಬ್ಯಾಕ್ ಮೆಷಿನ್ ನಲ್ಲಿ., ಇಂಟರ್‌‌ನ್ಯಾಷನಲ್‌ ಸಾಫ್ಟ್‌ವೇರ್‌ ಟೆಸ್ಟಿಂಗ್‌ ಕ್ವಾಲಿಫಿಕೇಷನ್ಸ್‌ ಬೋರ್ಡ್‌

[16] Kaner, Cem (2001). Lessons Learned in Software Testing: A Context-Driven Approach. Wiley. p. 4. ISBN 0-471-08112-4. {{cite book}}: Unknown parameter |coauthors= ignored (|author= suggested) (help)

[17] McConnell, Steve (2004). Code Complete (2nd ed.). Microsoft Press. p. 960. ISBN 0-7356-1967-0.

[18] ತತ್ತ್ವ 2, ವಿಭಾಗ 1.3, ಸರ್ಟಿಫೈಡ್‌ ಟೆಸ್ಟರ್‌ ಫೌಂಡೇಷನ್‌ ಲೆವೆಲ್‌ ಸಿಲಬಸ್‌ Archived 2008-12-17 ವೇಬ್ಯಾಕ್ ಮೆಷಿನ್ ನಲ್ಲಿ., ಇಂಟರ್‌‌ನ್ಯಾಷನಲ್‌ ಸಾಫ್ಟ್‌ವೇರ್‌ ಟೆಸ್ಟಿಂಗ್‌ ಕ್ವಾಲಿಫಿಕೇಷನ್ಸ್‌ ಬೋರ್ಡ್‌

[tran-19] Tran, Eushiuan (1999). "Verification/Validation/Certification". In Koopman, P. (ed.). Topics in Dependable Embedded Systems. USA: Carnegie Mellon University. {{cite book}}: |access-date= requires |url= (help); Unknown parameter |chapterurl= ignored (help)

[20] ನೋಡಿ D. ಗೆಲ್‌ಪೆರಿನ್‌ ಮತ್ತು W.C. ಹೆಟ್‌ಜೆಲ್‌

[21] ಇಂಟ್ರಡಕ್ಷನ್‌, ಕೋಡ್‌ ಕವರೇಜ್‌ ಅನಾಲಿಸಿಸ್‌, ಸ್ಟೀವ್‌ ಕಾರ್ನೆಟ್‌

[22] Laycock, G. T. (1993). "The Theory and Practice of Specification Based Software Testing". Dept of Computer Science, Sheffield University, UK. Archived from the original (PostScript) on 2007-02-14. Retrieved 2008-02-13. {{cite journal}}: Cite journal requires |journal= (help)

[23] Bach, James (1999). "Risk and Requirements-Based Testing" (PDF). Computer. 32 (6): 113–114. Retrieved 2008-08-19. {{cite journal}}: Cite has empty unknown parameter: |coauthors= (help); Unknown parameter |month= ignored (help)

[24] Savenkov, Roman (2008). How to Become a Software Tester. Roman Savenkov Consulting. p. 159. ISBN 978-0-615-23372-7.

[25] Binder, Robert V. (1999). Testing Object-Oriented Systems: Objects, Patterns, and Tools. Addison-Wesley Professional. p. 45. ISBN 0-201-80938-9.

[26] Beizer, Boris (1990). Software Testing Techniques (Second ed.). New York: Van Nostrand Reinhold. pp. 21, 430. ISBN 0-442-20672-0.

[ieee-27] IEEE (1990). IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer Glossaries. New York: IEEE. ISBN 1559370793.

[28] )ಟೆಸ್ಟಿಂಗ್‌ ಫೇಸ್‌ ಇನ್‌ ಸಾಫ್ಟ್‌ವೇರ್‌ ಟೆಸ್ಟಿಂಗ್‌‌:-

[29] Myers, Glenford J. (1979). The Art of Software Testing. John Wiley and Sons. pp. 145–146. ISBN 0-471-04328-1.

[30] Dustin, Elfriede (2002). Effective Software Testing. Addison Wesley. p. 3. ISBN 0-20179-429-2.

[31] Marchenko, Artem (November 16, 2007). "XP Practice: Continuous Integration". Archived from the original on 2011-07-07. Retrieved 2009-11-16. {{cite web}}: Cite has empty unknown parameter: |coauthors= (help)

[32] Gurses, Levent (February 19, 2007). "Agile 101: What is Continuous Integration?". Archived from the original on 2009-01-31. Retrieved 2009-11-16. {{cite web}}: Cite has empty unknown parameter: |coauthors= (help)

[33] Pan, Jiantao (Spring 1999). "Software Testing (18-849b Dependable Embedded Systems)". Topics in Dependable Embedded Systems. Electrical and Computer Engineering Department, Carnegie Mellon University.

[34] IEEE (1998). IEEE standard for software test documentation. New York: IEEE. ISBN 0-7381-1443-X.

[35] Kaner, Cem (2001). "NSF grant proposal to "lay a foundation for significant improvements in the quality of academic and commercial courses in software testing"" (PDF). Archived from the original (pdf) on 2009-11-27. Retrieved 2011-01-10.

[36] Kaner, Cem (2003). "Measuring the Effectiveness of Software Testers" (PDF). Archived from the original (pdf) on 2010-03-26. Retrieved 2011-01-10.

[37] Black, Rex (December 2008). Advanced Software Testing- Vol. 2: Guide to the ISTQB Advanced Certification as an Advanced Test Manager. Santa Barbara: Rocky Nook Publisher. ISBN 1933952369.

[Quality_Assurance_Institute-38] ೩೮.೦ ^೩೮.೧ ^೩೮.೨ ^೩೮.೩ ^೩೮.೪ ಕ್ವಾಲಿಟಿ ಅಶ್ಯೂರೆನ್ಸ್‌ ಇನ್‌‌ಸ್ಟಿಟ್ಯೂಟ್‌

[testinginstitute.com-39] ೩೯.೦ ^೩೯.೧ "ಇಂಟರ್‌‌ನ್ಯಾಷನಲ್‌ ಇನ್‌‌ಸ್ಟಿಟ್ಯೂಟ್‌ ಆಫ್‌ ಸಾಫ್ಟ್‌ವೇರ್‌ ಟೆಸ್ಟಿಂಗ್‌‌". Archived from the original on 2009-12-23. Retrieved 2011-01-10.

[40] "K. J. ರಾಸ್‌ & ಅಸೋಸಿಯೇಟ್ಸ್‌". Archived from the original on 2008-02-15. Retrieved 2011-01-10.

[istqb-41] ೪೧.೦ ^೪೧.೧ "ISTQB".

[astqb-42] ೪೨.೦ ^೪೨.೧ "ISTQB in the U.S."

[exin-exams.com-43] ೪೩.೦ ^೪೩.೧ EXIN: ಎಕ್ಸಾಮಿನೇಷನ್‌ ಇನ್‌‌ಸ್ಟಿಟ್ಯೂಟ್‌ ಫಾರ್‌ ಇನ್ಫರ್ಮೇಷನ್‌ ಸೈನ್ಸ್‌

[American_Society_for_Quality-44] ೪೪.೦ ^೪೪.೧ "ಅಮೆರಿಕನ್‌ ಸೊಸೈಟಿ ಆಫ್‌ ಕ್ವಾಲಿಟಿ". Archived from the original on 2009-12-13. Retrieved 2011-01-10.

[45] text-driven-testing.com

[46] ಆರ್ಟಿಕಲ್‌ ಆನ್‌ ಟೇಕಿಂಗ್‌ ಅಗೈಲ್ ಟ್ರೈಟ್ಸ್‌ ವಿಥೌಟ್‌ ದಿ ಅಗೈಲ್ ಮೆಥಡ್‌.

[47] “ವೀ ಆರ್‌ ಆಲ್‌ ಪಾರ್ಟ್‌ ಆಫ್‌ ದಿ ಸ್ಟೋರಿ” Archived 2009-08-31 ವೇಬ್ಯಾಕ್ ಮೆಷಿನ್ ನಲ್ಲಿ. -ಡೇವಿಡ್‌ ಸ್ಟ್ರೋಮ್‌, ಜುಲೈ 1, 2009

[48] IEEE ಆರ್ಟಿಕಲ್‌ ಎಬೌಟ್‌ ಡಿಫರೆನ್ಸಸ್‌ ಇನ್‌ ಅಡಾಪ್ಷನ್‌ ಆಫ್‌ ಅಗೈಲ್ ಟ್ರೆಂಡ್ಸ್‌ ಬಿಟ್ವೀನ್‌ ಎಕ್ಸ್‌ಪೀರಿಯೆನ್ಸ್ಡ್‌ ಮ್ಯಾನೇಜರ್ಸ್‌ vs. ಯಂಗ್‌ ಸ್ಟೂಡೆಂಟ್ಸ್‌ ಆಫ್‌ ದಿ ಪ್ರಾಜೆಕ್ಟ್‌ ಮ್ಯಾನೇಜ್‌ಮೆಂಟ್‌ ಇನ್‌‌ಸ್ಟಿಟ್ಯೂಟ್‌. ಇದನ್ನೂ ನೋಡಿ: ಅಗೈಲ್ ಅಡಾಪ್ಷನ್‌ ಸ್ಟಡಿ ಫ್ರಮ್ 2007

[49] "ಅಗೈಲ್ ಸಾಫ್ಟ್‌ವೇರ್‌ ಡೆವಲಪ್‌ಮೆಂಟ್‌ ಪ್ರಾಕ್ಟೀಸಸ್‌ ಸ್ಲೋಲಿ ಎಂಟರಿಂಗ್‌ ದಿ ಮಿಲಿಟರಿ". Archived from the original on 2010-01-25. Retrieved 2011-01-10.

[50] IEEE article on Exploratory vs. Non Exploratory testing

[51] ಆನ್‌ ಎಕ್ಸಾಂಪಲ್‌ ಈಸ್‌ ಮಾರ್ಕ್‌ ಫ್ಯೂಸ್ಟರ್‌, ಡೊರೊಥಿ ಗ್ರಹಾಂ: ಸಾಫ್ಟ್‌ವೇರ್‌ ಟೆಸ್ಟ್‌ ಆಟೋಮೇಷನ್. ಅಡಿಸನ್‌ ವೆಸ್ಲಿ, 1999, ISBN 0-201-33140-3.

[52] [news/why-evangelising-unit-testing- Article referring to other links questioning the necessity of unit testing]

[53] ‌‌ಮೈಕ್ರೋಸಾಫ್ಟ್ ಡೆವಲಪ್‌ಮೆಂಟ್‌ ನೆಟ್‌ವರ್ಕ್‌ ಡಿಸ್ಕಷನ್‌ ಆನ್‌ ಎಕ್ಸಾಕ್ಟ್‌ಲಿ ದಿಸ್‌ ಟಾಪಿಕ್‌ Archived 2010-02-15 ವೇಬ್ಯಾಕ್ ಮೆಷಿನ್ ನಲ್ಲಿ.

[೧]

[೨]

[೩]

[೪]

[೫]

[೬]

[೭]

[೮]

[೯]

[೧೦]

[೧೧]

[೧೨]

[೧೩]

[೧೪]

[೧೫]

[೧೬]

[೧೭]

[೧೮]

[೧೯]

[೨೦]

[೨೧]

[೨೨]

[೨೩]

[೨೪]

[೨೫]

[೨೬]

[೨೭]

[೨೮]

[೨೯]

[೩೦]

[೩೧]

[೩೨]

[೩೩]

[೩೪]

[೩೫]

[೩೬]

[೩೭]

[೩೮]

[೩೯]

[೪೦]

[೪೧]

[೪೨]

[೪೩]

[೪೪]

[೪೫]

[೪೬]

[೪೭]

[೪೮]

[೪೯]

[೫೦]

[೫೧]

[೫೨]

[೫೩]