├── _config.yml ├── project_metafiles └── read.me ├── images ├── bread.png ├── kraken.jpg ├── legioner.png ├── debugging.jpg ├── navigator.jpg ├── realScrum.jpg ├── alexei_lupan.jpg ├── shakespeare.png ├── legioner-vector.png ├── no-app-for-that.jpg ├── scrumFramework.png ├── TraceabilityMatrix.jpg ├── 1954_Cadillac_Eldorado.jpg ├── Iterative_development_model.png └── ClassicAdHocExploratoryTesting.png ├── Software Testing Glossary (Alexei Lupan).pdf ├── glossary ├── System.tex ├── Criteria.tex ├── Coverage.tex ├── BugVerification.tex ├── Feature.tex ├── BugReporting.tex ├── Quality.tex ├── Server.tex ├── Build.tex ├── TestIdea.tex ├── Testability.tex ├── TestDesign.tex ├── Function.tex ├── DevelopmentofTestCases.tex ├── TestSuite.tex ├── AutomatedScripts.tex ├── UserStory.tex ├── Pairwise.tex ├── Requirement.tex ├── DomainAnalysisTesting.tex ├── MaintenanceofTestCases.tex ├── FunctionalTesting.tex ├── Precondition.tex ├── ChangeRequest.tex ├── Debugging.tex ├── NegativeTesting.tex ├── PositiveTesting.tex ├── Test.tex ├── TestCase.tex ├── ExhaustiveTesting.tex ├── ExploratoryTesting.tex ├── BugTrackingSystem.tex ├── DecisionTableTesting.tex ├── Staging.tex ├── FunctionalSpecifications.tex ├── TestScenario.tex ├── ItemPassFailCriteria.tex ├── IntegrationTesting.tex ├── DocumentationTesting.tex ├── Metaphor.tex ├── ContinuousIntegration.tex ├── DevelopmentEnvironment.tex ├── MonkeyTesting.tex ├── EndtoendTesting.tex ├── RootCause.tex ├── UseCase.tex ├── ImpactAnalysis.tex ├── AcceptanceCriteria.tex ├── BoundaryValueTesting.tex ├── ChecklistbasedTesting.tex ├── UsabilityTesting.tex ├── CostofQuality.tex ├── Strategy.tex ├── ChangeManagement.tex ├── DefectbasedTestDesignTechnique.tex ├── IterativeDevelopmentModel.tex ├── BestPractice.tex ├── CompatibilityTesting.tex ├── SuspensionCriteria.tex ├── Version.tex ├── BetaTesting.tex ├── SCRUM.tex ├── ActualResult.tex ├── FunctionalRequirement.tex ├── InScopeOutofScope.tex ├── VerificationAndValidation.tex ├── SmokeTesting.tex ├── RegressionTesting.tex ├── Component.tex ├── MigrationTesting.tex ├── NonfunctionalRequirement.tex ├── SecurityTesting.tex ├── Traceability.tex ├── Sprint.tex ├── AgileSoftwareDevelopment.tex ├── AgileTesting.tex ├── AdhocTesting.tex ├── AcceptanceTesting.tex ├── PairTesting.tex ├── AutomatedTesting.tex ├── EntryexitCriteriaforTesting.tex ├── Defect.tex ├── AlphaTesting.tex ├── PerformanceTesting.tex ├── WhiteBoxBlackBox.tex ├── EquivalenceClassTesting.tex ├── Bug.tex └── AvailabilityTesting.tex ├── .gitignore ├── _author.tex ├── _abstract.tex ├── my_scripts └── clearProjectFiles.sh ├── README.md ├── main.tex ├── project_styles └── project_styles_screen_version.sty └── Software Testing Glossary.kilepr /_config.yml: -------------------------------------------------------------------------------- 1 | theme: jekyll-theme-minimal -------------------------------------------------------------------------------- /project_metafiles/read.me: -------------------------------------------------------------------------------- 1 | This folder is used for my pdfLaTeX compiling script. -------------------------------------------------------------------------------- /images/bread.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/testitquickly/Software-Testing-Glossary/HEAD/images/bread.png -------------------------------------------------------------------------------- /images/kraken.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/testitquickly/Software-Testing-Glossary/HEAD/images/kraken.jpg -------------------------------------------------------------------------------- /images/legioner.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/testitquickly/Software-Testing-Glossary/HEAD/images/legioner.png -------------------------------------------------------------------------------- /images/debugging.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/testitquickly/Software-Testing-Glossary/HEAD/images/debugging.jpg -------------------------------------------------------------------------------- /images/navigator.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/testitquickly/Software-Testing-Glossary/HEAD/images/navigator.jpg -------------------------------------------------------------------------------- /images/realScrum.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/testitquickly/Software-Testing-Glossary/HEAD/images/realScrum.jpg -------------------------------------------------------------------------------- /images/alexei_lupan.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/testitquickly/Software-Testing-Glossary/HEAD/images/alexei_lupan.jpg -------------------------------------------------------------------------------- /images/shakespeare.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/testitquickly/Software-Testing-Glossary/HEAD/images/shakespeare.png -------------------------------------------------------------------------------- /images/legioner-vector.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/testitquickly/Software-Testing-Glossary/HEAD/images/legioner-vector.png -------------------------------------------------------------------------------- /images/no-app-for-that.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/testitquickly/Software-Testing-Glossary/HEAD/images/no-app-for-that.jpg -------------------------------------------------------------------------------- /images/scrumFramework.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/testitquickly/Software-Testing-Glossary/HEAD/images/scrumFramework.png -------------------------------------------------------------------------------- /images/TraceabilityMatrix.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/testitquickly/Software-Testing-Glossary/HEAD/images/TraceabilityMatrix.jpg -------------------------------------------------------------------------------- /images/1954_Cadillac_Eldorado.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/testitquickly/Software-Testing-Glossary/HEAD/images/1954_Cadillac_Eldorado.jpg -------------------------------------------------------------------------------- /images/Iterative_development_model.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/testitquickly/Software-Testing-Glossary/HEAD/images/Iterative_development_model.png -------------------------------------------------------------------------------- /images/ClassicAdHocExploratoryTesting.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/testitquickly/Software-Testing-Glossary/HEAD/images/ClassicAdHocExploratoryTesting.png -------------------------------------------------------------------------------- /Software Testing Glossary (Alexei Lupan).pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/testitquickly/Software-Testing-Glossary/HEAD/Software Testing Glossary (Alexei Lupan).pdf -------------------------------------------------------------------------------- /glossary/System.tex: -------------------------------------------------------------------------------- 1 | \section{System} 2 | \label{sec:System} 3 | 4 | A collection of components organized to accomplish a specific function or set of functions. 5 | 6 | Your body is a system. -------------------------------------------------------------------------------- /glossary/Criteria.tex: -------------------------------------------------------------------------------- 1 | \section{Criteria} 2 | \label{sec:Criteria} 3 | 4 | \rindex{\textbf{C}!Criteria}A standard of judgment or criticism. 5 | 6 | Or a rule or principle for evaluating or testing something. 7 | -------------------------------------------------------------------------------- /glossary/Coverage.tex: -------------------------------------------------------------------------------- 1 | \section{Coverage} 2 | \label{sec:Coverage} 3 | 4 | \rindex{\textbf{C}!Coverage}The degree, expressed as a percentage, to which a specified coverage item has been exercised by a test suite. 5 | -------------------------------------------------------------------------------- /glossary/BugVerification.tex: -------------------------------------------------------------------------------- 1 | \section{Bug Verification} 2 | \label{sec:Bug Verification} 3 | 4 | \rindex{\textbf{B}!Bug Verification}A process, where the tester try to reproduce on new build each bug, which was reported by developers as 'Fixed'. 5 | -------------------------------------------------------------------------------- /glossary/Feature.tex: -------------------------------------------------------------------------------- 1 | \section{Feature} 2 | \label{sec:Feature} 3 | 4 | \rindex{\textbf{F}!Feature}An attribute of a component or system specified or implied by requirements documentation (for example reliability, usability or design constraints). 5 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | howTo.tex 2 | *.*~ 3 | *.backup 4 | *.ilg 5 | *.ind 6 | *.aux 7 | *.glo 8 | *.gls 9 | *.idx 10 | *.log 11 | *.xdy 12 | *.glg 13 | *.out 14 | *.toc 15 | *.dvi 16 | *.ent 17 | *.bbl 18 | *.blg 19 | *.ps 20 | *kate-swp 21 | *.gz 22 | *.gui -------------------------------------------------------------------------------- /glossary/BugReporting.tex: -------------------------------------------------------------------------------- 1 | \section{Bug Reporting} 2 | \label{sec:Bug Reporting} 3 | 4 | The process of explaining the steps, which lead to the bug happens. This notice with a proven screenshot should be stored in a bug-tracking system [p.\pageref{sec:Bug Tracking System}]. -------------------------------------------------------------------------------- /glossary/Quality.tex: -------------------------------------------------------------------------------- 1 | \section{Quality} 2 | \label{sec:Quality} 3 | 4 | \rindex{\textbf{Q}!Quality}The degree to which a component, system or process meets specified requirements and/or user/customer needs and expectations. 5 | 6 | A \emph{value} to some person at some time. 7 | -------------------------------------------------------------------------------- /glossary/Server.tex: -------------------------------------------------------------------------------- 1 | \section{Server} 2 | \label{sec:Server} 3 | 4 | A program, that can simultaneously accept a lot of references to it, put them in a queue and execute them successively, one by one. 5 | 6 | Depending on context, the term can refer to the hardware, where the \rindex{\textbf{S}!Server}Server lives. 7 | -------------------------------------------------------------------------------- /glossary/Build.tex: -------------------------------------------------------------------------------- 1 | \section{Build} 2 | \label{sec:Build} 3 | 4 | \rindex{\textbf{B}!Build} \rindex{\textbf{V}!Version}A compiled version [p.\pageref{sec:Version}] of a program. 5 | 6 | \begin{quote} 7 | Any program. 8 | \end{quote} 9 | 10 | It comes from the \url{https://en.wikipedia.org/wiki/Software_versioning}. 11 | -------------------------------------------------------------------------------- /glossary/TestIdea.tex: -------------------------------------------------------------------------------- 1 | \section{Test Idea} 2 | \label{sec:Test Idea} 3 | 4 | \rindex{\textbf{T}!Test Idea}A conception or a statement about any software expectations or requirements, that potentially can/should be verified with boolean logic (YES/NO, TRUE/FALSE). 5 | 6 | Usually each title of a \rindex{\textbf{T}!Test Case}test case is a Test Idea. 7 | -------------------------------------------------------------------------------- /glossary/Testability.tex: -------------------------------------------------------------------------------- 1 | \section{Testability} 2 | \label{sec:Testability} 3 | 4 | The capability of the software product to enable modified software to be tested. 5 | 6 | Sounds weird, but in fact, this is a good topic for a scientific research in the name of almighty, say, \rindex{\textbf{A}!Allah} or any other guy who deny the scientific research. 7 | -------------------------------------------------------------------------------- /glossary/TestDesign.tex: -------------------------------------------------------------------------------- 1 | \section{Test Design} 2 | \label{sec:Test Design} 3 | 4 | The process of analysing everything in software and/or software requirements for testing purposes. 5 | 6 | It is somehow similar with inventing poetry without inspiration. 7 | 8 | It is not 'How to write \rindex{\textbf{T}!Test Case}test cases\ldots', but after analysing test cases will be created. 9 | -------------------------------------------------------------------------------- /glossary/Function.tex: -------------------------------------------------------------------------------- 1 | \section{Function} 2 | \label{sec:Function} 3 | 4 | \begin{quote} 5 | Cat's functions are 'to make purrrr' and to hunt some food. 6 | \end{quote} 7 | 8 | The \textbf{Function} is what a given entity does in being what it is. 9 | 10 | So, the \textbf{Functionality} is an ability of software to perform a task. 11 | 12 | Word is taken from the Latin \englishq{\textit{functio}} - to perform. 13 | -------------------------------------------------------------------------------- /glossary/DevelopmentofTestCases.tex: -------------------------------------------------------------------------------- 1 | \section{Development of Test Cases} 2 | \label{sec:Development of Test Cases} 3 | 4 | This is the best process in the testing work! 5 | 6 | Development, development, development, development, development, development, development, development, development of \rindex{\textbf{T}!Test Case}Test Cases! 7 | 8 | Can be done in a very clever way\footnote{~The righteous way.}. 9 | 10 | Or in a very dumb way. 11 | -------------------------------------------------------------------------------- /glossary/TestSuite.tex: -------------------------------------------------------------------------------- 1 | \section{Test Suite} 2 | \label{sec:Test Suite} 3 | 4 | \rindex{\textbf{T}!Test Suite}A set of several \rindex{\textbf{T}!Test Case}test cases for a component or system under test, where the post condition of one test is often used as the precondition for the next one. 5 | 6 | Sometime a suite it's just a logical 'folder' for a list of test cases, focused on testing something specific. 7 | 8 | One test case can apper in several test suites. 9 | -------------------------------------------------------------------------------- /glossary/AutomatedScripts.tex: -------------------------------------------------------------------------------- 1 | \section{Automated Scripts} 2 | \label{sec:Automated Scripts} 3 | The scenario for the Automation Robot. 4 | 5 | Shows how to interact with the application under testing. 6 | 7 | Usually a simple human cannot read/understand such scripts, but there are a lot of exceptions. Scripts can be writted in a simulation of normal language. 8 | 9 | You don't know, how the Robot will read and execute step by step this instruction, but you can understand at a global scale, what should be happen at each step. -------------------------------------------------------------------------------- /glossary/UserStory.tex: -------------------------------------------------------------------------------- 1 | \section{User Story} 2 | \label{sec:User Story} 3 | 4 | A high-level user or business \textbf{requirement} commonly used in agile software development, typically consisting of one or more sentences in the everyday or business language capturing what functionality a user needs, any non-functional criteria, and also includes acceptance criteria. 5 | 6 | Like Use Cases [p.\pageref{sec:Use Case}], the 'User Story' is a special form of a \rindex{\textbf{R}!Requirements}Requirement [p.\pageref{sec:Requirement}]. 7 | -------------------------------------------------------------------------------- /glossary/Pairwise.tex: -------------------------------------------------------------------------------- 1 | \section{Pairwise} 2 | \label{sec:Pairwise} 3 | 4 | \rindex{\textbf{P}!Pairwise}A powerful test design technique. Test cases are designed to execute all possible discrete combinations of each pair of input parameters. 5 | 6 | It can significantly reduce the number of all combinations of variables to test all pair combinations. 7 | 8 | Usually this powerful technique is used as a waste of time with respective attitude. Please, do not try it at home. You can fake that you totally understand what is talking about. 9 | -------------------------------------------------------------------------------- /glossary/Requirement.tex: -------------------------------------------------------------------------------- 1 | \section{Requirement} 2 | \label{sec:Requirement} 3 | 4 | \rindex{\textbf{R}!Requirements}A condition or capability needed by a user to solve a problem or achieve an objective that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed document. 5 | 6 | \rindex{\textbf{S}!Specifications}Specification is the next step after Requirement. Requirements tells what to do, and Specification tells how to do it~\textemdash~this can be two different docs. 7 | -------------------------------------------------------------------------------- /glossary/DomainAnalysisTesting.tex: -------------------------------------------------------------------------------- 1 | \section{Domain Analysis Testing} 2 | \label{sec:Domain Analysis Testing} 3 | 4 | \rindex{\textbf{D}!Domain Analysis}A very mature test design technique. 5 | 6 | Used to identify efficient and effective test cases when multiple variables can or should be tested together. 7 | 8 | Implies a lot of equivalence partitioning and boundary values analysis, so a junior tester will never be able to do it. 9 | 10 | Not every Senior Tester is familiar with this advanced approach to design test cases either. 11 | 12 | Sad but true. 13 | -------------------------------------------------------------------------------- /glossary/MaintenanceofTestCases.tex: -------------------------------------------------------------------------------- 1 | \section{Maintenance of Test Cases} 2 | \label{sec:Maintenance of Test Cases} 3 | 4 | \rindex{\textbf{M}!Maintenance of Test Cases}Maybe, the most annoying process for every smart tester in the world. 5 | 6 | \rindex{\textbf{R}!Requirements}Requirements (and Expectations) in a Product can happen many times during a product development lifecycle, so \rindex{\textbf{T}!Test Case}test cases can become totally obsolete. Rewrite them all, or write new test cases. 7 | 8 | What would you do with this issue? 9 | 10 | Real challenge, huh? 11 | -------------------------------------------------------------------------------- /glossary/FunctionalTesting.tex: -------------------------------------------------------------------------------- 1 | \section{Functional Testing} 2 | \label{sec:Functional Testing} 3 | 4 | \rindex{\textbf{F}!Functional Testing}Any testing based on an analysis of the specification of the functionality of a component or system. 5 | 6 | The functional testing will be executed to evaluate the compliance of a system or component or third-party with specified functional \rindex{\textbf{R}!Requirements}requirements and corresponding predicted results. 7 | 8 | Functional testing is performed for each planned feature and is guided by approved by \rindex{\textbf{C}!Customer}client requirements. 9 | -------------------------------------------------------------------------------- /glossary/Precondition.tex: -------------------------------------------------------------------------------- 1 | \section{Precondition} 2 | \label{sec:Precondition} 3 | 4 | \rindex{\textbf{P}!Precondition}Environmental and state conditions that must be fulfilled before the component or system can be executed with a particular test or test procedure. 5 | 6 | \subsection{Postcondition} 7 | \label{sec:Postcondition} 8 | 9 | \rindex{\textbf{P}!Postcondition}Environmental and state conditions that must be fulfilled after the execution of a test or test procedure. 10 | 11 | Warning, this is not the \rindex{\textbf{E}!Expected result}Expected result [p.\pageref{sec:Actual Result}]. 12 | -------------------------------------------------------------------------------- /glossary/ChangeRequest.tex: -------------------------------------------------------------------------------- 1 | \section{Change Request} 2 | \label{sec:Change Request} 3 | 4 | \rindex{\textbf{C}!Change Request}A formal proposal for an alteration to some requirements or functions. 5 | 6 | Often arises when the client want an addition (or alteration) to the agreed-upon deliverables for a project. Such a change may involve an additional feature or customization or an extension of service, among other things. So it had to be analyzed apart. 7 | 8 | Because change requests are beyond the scope of the agreement, they generally mean that the client will have to pay for the extra resources required to satisfy them. 9 | -------------------------------------------------------------------------------- /glossary/Debugging.tex: -------------------------------------------------------------------------------- 1 | \section{Debugging} 2 | \label{sec:Debugging} 3 | 4 | \rindex{\textbf{D}!Debugging}A process, where developers start to prove their best skills. 5 | 6 | The debugging is not the process of fixing bugs. Usually it looks like someone deliberately send to a program data with errors, trying to figure out where the calculation will be incorrect. When a weak point will be discovered, then the bug-fixing will begin. 7 | 8 | In ancient times (1940-1970) the debugging was the primary testing approach. Those programmers had to understand clearly what (and how) the computers doing their job. And they act respectively. 9 | -------------------------------------------------------------------------------- /glossary/NegativeTesting.tex: -------------------------------------------------------------------------------- 1 | \section{Negative Testing} 2 | \label{sec:Negative Testing} 3 | 4 | \rindex{\textbf{N}!Negative Testing}A test designed to determine the response of the system outside of normal parameters. 5 | 6 | It is designed to determine if the system performs error handling with an other than expected input. 7 | 8 | Understand, that when you check something like 'Enter following abracadabra and system should explain that there is an unaccepted symbol, please enter data without errors'~\textemdash~this is \rindex{\textbf{P}!Positive Testing}Positive Testing [p.\pageref{sec:Positive Testing}], because you have the expectations about systems response. 9 | -------------------------------------------------------------------------------- /glossary/PositiveTesting.tex: -------------------------------------------------------------------------------- 1 | \section{Positive Testing} 2 | \label{sec:Positive Testing} 3 | 4 | This is nothing else than the \rindex{\textbf{P}!Positive Testing}main approach to testing. 5 | 6 | Our main intention is to prove that an application will work 'as expected' on giving valid input data. 7 | 8 | In \rindex{\textbf{N}!Negative Testing}Negative testing [p.\pageref{sec:Negative Testing}] our intention is to prove that positive testing did not cover some situations. 9 | 10 | Suppose following situation: I will type an email address without '@', system should alert me about my error. What kind of testing type is that? Is that A positive or a negative one? 11 | -------------------------------------------------------------------------------- /glossary/Test.tex: -------------------------------------------------------------------------------- 1 | \section{Test} 2 | \label{sec:Test} 3 | 4 | Initially a Test is an assessment intended to measure the respondents' knowledge or other abilities. Remember your class years? 5 | 6 | In our industry a Test is the process of verifying that a software program works as expected from the point of \rindex{\textbf{V}!Verification}Verification or/and \rindex{\textbf{V}!Validation}Validation view [p.\pageref{sec:Verification}]. 7 | 8 | To perform a Test, brave Quality Assurance engineers should previously create their brilliant \rindex{\textbf{T}!Test Case}Test Cases. For doing this they need in advance the \rindex{\textbf{R}!Requirements}Requirements ready for review [p.\pageref{sec:Requirement}]. 9 | -------------------------------------------------------------------------------- /glossary/TestCase.tex: -------------------------------------------------------------------------------- 1 | \section{Test Case} 2 | \label{sec:Test Case} 3 | 4 | \rindex{\textbf{T}!Test Case}An instruction for create a test situation. 5 | 6 | \begin{center} 7 | Case = Situation. 8 | \end{center} 9 | 10 | Usually test cases looks like a set of 11 | 12 | \begin{enumerate} 13 | \item 14 | input values, 15 | \item execution preconditions, 16 | \item expected results 17 | \item and execution post-conditions, developed for a particular objective or test condition, such as to exercise a particular program path or to verify compliance with a specific requirement. 18 | \end{enumerate} 19 | 20 | Note, that it's all about a the test situation, that can be created artificially. 21 | -------------------------------------------------------------------------------- /glossary/ExhaustiveTesting.tex: -------------------------------------------------------------------------------- 1 | \section{Exhaustive Testing} 2 | \label{sec:Exhaustive Testing} 3 | 4 | \rindex{\textbf{E}!Exhaustive Testing}A test approach in which the \rindex{\textbf{T}!Test Suite}test suite comprises all combinations of input values and preconditions. 5 | 6 | \begin{quote} 7 | All combinations! 8 | \end{quote} 9 | 10 | As you know, nobody can test all input combinations into a modern software, so every moron knows that exhaustive testing is totally impossible. 11 | 12 | In fact, exhaustive testing it is totally possible, but not all the time necessary. You cannot test everything. But you can predict everything that can happen with the tested software. Predictability lead to control. 13 | -------------------------------------------------------------------------------- /glossary/ExploratoryTesting.tex: -------------------------------------------------------------------------------- 1 | \section{Exploratory Testing} 2 | \label{sec:Exploratory Testing} 3 | 4 | \rindex{\textbf{E}!Exploratory Testing}A very cool, but informal test design technique. 5 | 6 | It is hard to explain this approach in a few words, because it is completely unusual for almost all testers. But it can be demonstrated and explained step-by-step (it's like riding a bicycle). 7 | 8 | Here is the simplest explanation of this approach: 9 | 10 | \begin{figure}[!h] 11 | \centering 12 | \includegraphics[width=\linewidth]{ClassicAdHocExploratoryTesting} 13 | \caption{\ttfamily{Simple explanation of Classic \& Ad Hoc \& Exploratory testing}} 14 | \label{fig:ClassicAdHocExploratoryTesting} 15 | \end{figure} 16 | -------------------------------------------------------------------------------- /glossary/BugTrackingSystem.tex: -------------------------------------------------------------------------------- 1 | \section{Bug Tracking System} 2 | \label{sec:Bug Tracking System} 3 | 4 | Any software that facilitates the collaborative recording and status tracking of defects and changes. 5 | 6 | Usually the \url{https://www.atlassian.com/software/jira} system is used for this. 7 | 8 | \begin{quote} 9 | In fact, \rindex{\textbf{J}!Jira}Jira is not a bug-tracking system, it's a Task-tracking system. but any defect recorded can be viewed as a 'task for fixing', so nobody cares. \end{quote} 10 | 11 | I'll preffer \url{https://www.mantisbt.org/}. 12 | 13 | Choose your own Bug Tracker. 14 | -------------------------------------------------------------------------------- /glossary/DecisionTableTesting.tex: -------------------------------------------------------------------------------- 1 | \section{Decision Table Testing} 2 | \label{sec:Decision Table Testing} 3 | 4 | \rindex{\textbf{D}!Decision Table Testing}An excellent logical tool to capture certain kinds of system requirements and to document internal system design. 5 | 6 | They are used to record complex business rules that a system must implement. 7 | 8 | They can serve as a guide to creating test cases. Decision tables are a vital tool in the tester's personal toolbox. 9 | 10 | Not every analyst, designer, programmer and/or tester are familiar with this technique\footnote{~Quote from \russianq{A Practitioner's Guide to Software Test Design} by \rindex{\textbf{L}!Lee Copeland}Lee Copeland, 2004, Artech House, Inc.}. 11 | 12 | Sad but true. 13 | -------------------------------------------------------------------------------- /glossary/Staging.tex: -------------------------------------------------------------------------------- 1 | \section{Staging} 2 | \label{sec:Staging} 3 | 4 | In theater a \rindex{\textbf{S}!Stage}Staging is the platform on which actors perform their 'To be, or not to be\ldots' So, this is a place, where something is shown to an appreciative audience. 5 | 6 | A 'staging server' is any server that stores the software with testing purposes, but the environment is almost production-similar. 7 | 8 | Usually only client-side testers have access to Staging server, where they can, for example, use real Credit Card for testing. 9 | 10 | And customer usually check the software on the staging server, not on testing server. 11 | 12 | Sometimes this thing is called \rindex{\textbf{U}!UAT, User Acceptance Testing}UAT~\textemdash~User Acceptance Testing. 13 | -------------------------------------------------------------------------------- /glossary/FunctionalSpecifications.tex: -------------------------------------------------------------------------------- 1 | \section{Functional Specification} 2 | \label{sec:Functional Specification} 3 | 4 | \rindex{\textbf{F}!Functional Specification}This is an extention of a Functional \rindex{\textbf{R}!Requirements}Requirement [p.\pageref{sec:Functional Requirement}]. 5 | 6 | \textbf{Functional Requirement} is an abstract, which describes \emph{what} a software system should do from the user point of view. 7 | 8 | \begin{quote} 9 | I want to have a red car for driving on the streets. 10 | \end{quote} 11 | 12 | \textbf{Functional Specification} describes \emph{how exactly} the functional requirement will be implemented. 13 | 14 | \begin{quote} 15 | I want to have a car painted in \#ff0000 with engine 1.6 and McPherson suspension. 16 | \end{quote} 17 | -------------------------------------------------------------------------------- /glossary/TestScenario.tex: -------------------------------------------------------------------------------- 1 | \section{Test Scenario} 2 | \label{sec:Test Scenario} 3 | 4 | \rindex{\textbf{T}!Test Scenario}The simplest explanation about what steps need to be taken in order to create expected test situation to verify a software requirement without getting into specific detailed test steps, test data, and/or expected results. 5 | 6 | Example: "\textit{How to put an elephant into a refrigerator?}" 7 | 8 | \begin{enumerate} 9 | \item open the fridge door, 10 | \item put the elephant in a refrigerator, 11 | \item close the refrigerator door. 12 | \end{enumerate} 13 | 14 | Sometimes waste, complex \rindex{\textbf{T}!Test Case}test cases are preceded by test scenarios. 15 | 16 | And it is obvious, that every test case aggregate a test scenario (step one, step two, step three\ldots) 17 | -------------------------------------------------------------------------------- /glossary/ItemPassFailCriteria.tex: -------------------------------------------------------------------------------- 1 | \section{Item Pass/Fail Criteria} 2 | \label{sec:Item Pass/Fail Criteria} 3 | 4 | \begin{quote} 5 | Understand what is a \rindex{\textbf{C}!Criteria}Criteria first [p.\pageref{sec:Criteria}]. 6 | \end{quote} 7 | 8 | \textbf{Pass/Fail Criteria} will be used to ensure the completeness of the test process. 9 | 10 | It sound very obvious, but try to explain your judgement about '\textit{How do you know, that the testing of Change Avatar in User Profile is done?}' Sometimes is very easy to understand this (I can change user Avatar, all satisfied citizens are going home). But sometimes not. 11 | 12 | \begin{quote} 13 | Where is the previous user Avatar picture? It is still available, but was marked as 'Deleted'? Or it was completely deleted from file server? 14 | \end{quote} 15 | -------------------------------------------------------------------------------- /glossary/IntegrationTesting.tex: -------------------------------------------------------------------------------- 1 | \section{Integration Testing} 2 | \label{sec:Integration Testing} 3 | 4 | \rindex{\textbf{I}!Integration Testing}Integration testing is a process, where different parts of system under testing are engaged one by another. 5 | 6 | Such testing is done to ensure that all engaged components (may be included third-parties) maintain data integrity and can operate in coordination with other system artifacts in the same environment. 7 | 8 | This type of testing is performed to expose defects in the interfaces and in the interactions between integrated components or systems. There are a huge possibility, that each software component can be bugless apart, but on the integration phase can appear some bugs, that cannot be imagined, supposed and identified. They can be discovered only at the Integration testing phase. 9 | -------------------------------------------------------------------------------- /glossary/DocumentationTesting.tex: -------------------------------------------------------------------------------- 1 | \section{Documentation Testing} 2 | \label{sec:Documentation Testing} 3 | 4 | \rindex{\textbf{D}!Documentation Testing}A confusing term. There are no reason for test the documentation. Use it in testing, that's all! 5 | 6 | Just grab \rindex{\textbf{R}!Requirements}requirements and think: 7 | \begin{itemize} 8 | \item what should be implemented, 9 | \item what can be tested. 10 | \end{itemize} 11 | 12 | \begin{figure}[!h] 13 | \centering 14 | \includegraphics[width=0.8\linewidth]{no-app-for-that} 15 | \caption{\ttfamily{“Sorry, son\ldots”}} 16 | \label{fig:no-app-for-that} 17 | \end{figure} 18 | 19 | You will need only \rindex{\textbf{N}!Notepad} Notepad and your own imagination for this. 20 | 21 | Note all your ideas and questions, search for answers, and repeat steps one by one (this is an incremental task) till the end of your career in testing. 22 | -------------------------------------------------------------------------------- /glossary/Metaphor.tex: -------------------------------------------------------------------------------- 1 | \section{Metaphor} 2 | \label{sec:Metaphor} 3 | 4 | A \rindex{\textbf{M}!Metaphor}\emph{Metaphor} is a figure of speech that refers, for rhetorical effect, the attributes of one thing by mentioning another thing. 5 | 6 | It may provide clarity or identify hidden similarities between two ideas. A \textit{Metaphor} directly equates this two items, and does not use "like" or "as" as does a \textit{Simile}. 7 | 8 | Example: 9 | 10 | \begin{verse} 11 | The moon has looming over the horizon like\footnote{~Yeah, the word "like" was used, but anyway} a big orange. 12 | \end{verse} 13 | 14 | From the other side, nobody will understand the same metaphor, used vice versa: 15 | 16 | \begin{verse} 17 | An orange has lying on a plate, like a moon over the horizon. 18 | \end{verse} 19 | 20 | Sound stupid, isn't it? 21 | 22 | Some methapors works perfect in both sides, some not. 23 | -------------------------------------------------------------------------------- /glossary/ContinuousIntegration.tex: -------------------------------------------------------------------------------- 1 | \section{Continuous Integration (CI)} 2 | \label{sec:Continuous Integration (CI)} 3 | 4 | \rindex{\textbf{C}!Continuous Integration (CI)}In software engineering this is a practice of merging all developer working copies with a shared mainline several times a day. 5 | 6 | It was first named and proposed as part of extreme programming (XP). Was originally intended to be used in combination with automated unit tests written through the practices of test-driven development. 7 | 8 | Initially this was conceived of as running all unit tests and verifying they all passed before committing to the mainline. This helps avoid one developer's work in progress breaking another developer's copy. If necessary, partially complete features can be disabled before committing using feature toggles. 9 | 10 | Continuous integration isn't universally accepted as an improvement over frequent integration. 11 | -------------------------------------------------------------------------------- /glossary/DevelopmentEnvironment.tex: -------------------------------------------------------------------------------- 1 | \section{Development Environment} 2 | \label{sec:Development Environment} 3 | 4 | \rindex{\textbf{D}!Development Environment}A dev environment is any infrastructure, where the developers has the full authority to make any changes they needed. 5 | 6 | Opposite is the \rindex{\textbf{T}!Testing Environment}Testing Environment. This can be a server with a full replication from Development server, but only QA makes decisions about the updating anything on their environment. 7 | 8 | By the way, the software, aims to help in programming is a Development Environment too. But it is called 'Integrated Development Environment'. 9 | 10 | \begin{quote} 11 | E.g., the \rindex{\textbf{E}!Eclipse}'Eclipse' is an IDE (Integrated Development Environment). And \rindex{\textbf{I}!IntelliJ IDEA}'IntelliJ IDEA' is an IDE (Integrated Development Environment). And even \rindex{\textbf{E}!MS Excel}MS Excel can be an IDE for VisualBasic developers. 12 | \end{quote} 13 | -------------------------------------------------------------------------------- /glossary/MonkeyTesting.tex: -------------------------------------------------------------------------------- 1 | \section{Monkey Testing} 2 | \label{sec:Monkey Testing} 3 | 4 | \rindex{\textbf{M}!Monkey Testing}A metaphor for naming the producer of any input for a program. 5 | 6 | The name 'monkey' comes from the the 'Infinite monkey'\footnote{~\url{http://en.wikipedia.org/wiki/Infinite_monkey_theorem}} theorem. There is an adage that ‘\textit{thousand monkeys at a thousand typewriters will eventually type out the entire works of \rindex{\textbf{W}!William Shakespeare}Shakespeare}’. 7 | 8 | \begin{figure}[!h] 9 | \centering 10 | \includegraphics[width=0.8\linewidth]{shakespeare} 11 | \caption{\ttfamily{This is Shakespeare. He looks at you as at an infinite monkey}} 12 | \label{fig:shakespeare} 13 | \end{figure} 14 | 15 | For example, a monkey test can enter random strings into text boxes to ensure handling of all possible user input or provide garbage files to check for loading routines that have blind faith in their data. The test monkey is technically known to conduct \rindex{\textbf{R}!Random Testing}Random testing. 16 | -------------------------------------------------------------------------------- /glossary/EndtoendTesting.tex: -------------------------------------------------------------------------------- 1 | \section{End-to-end Testing} 2 | \label{sec:End-to-end Testing} 3 | 4 | \rindex{\textbf{E}!End-to-end Testing}A convenient expression for establish the complexity of system being to test and the nature of test cases, designed for this. 5 | 6 | Consider a platform, where individual component systems are integrated with each other, so a new shop (a new system) can be created without having to develop applications from new. Complexity of such software requires to test whether the flow of an application is performing as designed from start to finish. 7 | 8 | Example~\textemdash~Promotions. Every step can be tested apart, but it is more important to be sure that the whole process (create and apply new Promotion) works as expected. 9 | 10 | The purpose of carrying out end-to-end tests is to identify system dependencies and to ensure that the right information is passed between various system components and systems. 11 | 12 | Someone can act such type of testing like very annoying. Well, complex thing requires complex testing. 13 | -------------------------------------------------------------------------------- /_author.tex: -------------------------------------------------------------------------------- 1 | \section*{About author} 2 | \label{sec:About author} 3 | 4 | \begin{minipage}{0.45\textwidth} 5 | 6 | \Huge \textbf{Alexei Lupan} \newline 7 | \normalsize Software Tester \& QA Trainer 8 | 9 | \bigskip 10 | 11 | \begin{flushleft} 12 | I do functional testing, testing and \mbox{requirements analysis} for large e-commerce web-services and I\textquotesingle m always interested to deal with tricky test-design issues. 13 | \end{flushleft} 14 | 15 | And I\textquotesingle m happy with baritone guitars and Robert Heinlein's books. 16 | 17 | \bigskip 18 | 19 | \href{https://www.linkedin.com/in/testitquickly/}{LinkedIn.com/in/testitquickly/} 20 | 21 | \href{https://testitquickly.com/}{testitquickly.com} 22 | 23 | \href{mailto:astenix@testitquickly.com}{astenix@testitquickly.com} 24 | 25 | \end{minipage} % не разрывать строки 26 | \begin{minipage}{0.3\textwidth} %\tcbox[boxsep=-2em, colframe=white!0!white, colback=white!0] 27 | \tcbox[boxsep=3em, colframe=white!0!white, colback=white!0]{\includegraphics[width=7cm]{alexei_lupan}} 28 | \end{minipage} 29 | -------------------------------------------------------------------------------- /glossary/RootCause.tex: -------------------------------------------------------------------------------- 1 | \section{Root Cause Analysis} 2 | \label{sec:Root Cause Analysis} 3 | 4 | \rindex{\textbf{R}!Root Cause Analysis}A root cause is an initiating cause of a causal chain which leads to an outcome or effect of interest. In short: \textit{find why someone was killed, and you can find the killer}. 5 | 6 | Root cause analysis is a method of problem solving that tries to identify the root causes of faults or problems. A lot of developers can expect such analyse from testers, but this is insane. Root cause analysis practice solve problems by attempting to identify and correct the root causes of events, as opposed to simply addressing their symptoms. Focusing correction on root causes has the goal of \emph{preventing problem recurrence}, and here testers fails. 7 | 8 | There are many different tools, processes, and philosophies for performing Root Cause Analysis. However, several very-broadly defined approaches or "schools" can be identified by their basic approach or field of origin: safety-based, production-based, process-based, failure-based, and systems-based. 9 | -------------------------------------------------------------------------------- /glossary/UseCase.tex: -------------------------------------------------------------------------------- 1 | \section{Use Case} 2 | \label{sec:Use Case} 3 | 4 | In software and systems engineering, a \rindex{\textbf{U}!Use Case}\emph{Use Case} is a list of steps, typically defining interactions between a role (known in Unified Modeling Language as an "actor") and a system, to achieve a goal. The actor can be a human, an external system, or time. 5 | 6 | In our industry Use Cases become a special form of a \rindex{\textbf{R}!Requirements}Requirement. 7 | 8 | \begin{quote} 9 | We may say that Requirements evolve in Use Cases. 10 | 11 | Or~\textemdash~this is another form of Requirements, nothing to worry about it. 12 | 13 | Anyway, Use Cases derive from \rindex{\textbf{U}!User Story}User Stories [p.\pageref{sec:User Story}]. 14 | \end{quote} 15 | 16 | Use Cases have been widely used in modern software engineering over the last two decades. With its iterative and evolutionary nature, use case is also a good fit for agile development. 17 | 18 | When you have good Use Cases, you will be able to create a lot of good \rindex{\textbf{T}!Test Case}Test Cases. 19 | -------------------------------------------------------------------------------- /glossary/ImpactAnalysis.tex: -------------------------------------------------------------------------------- 1 | \section{Impact Analysis} 2 | \label{sec:Impact Analysis} 3 | 4 | \rindex{\textbf{I}!Impact Analysis}In fact, this should be named \textbf{Change impact analysis}, but anyway~\textemdash~this is a method to identify the potential consequences of a change in a complex system. 5 | 6 | Consider \rindex{\textbf{N}!Notepad}'Notepad' as a simple software under test. We can add new functions (or modify existed). We would like to set assure, that this change will not alter existed functions. How? 7 | 8 | We can proceed to regression testing (consider the level of boring testers and costs). Or we can setup a table, where we will trace all Notepad functionality and their junction points. 9 | 10 | Now, we can see, which functionality will be affected by changes, and can retest only areas, where changes will have the impact. 11 | 12 | Problem with this impact tables is the same as for any other project documentation~\textemdash~they should be updated on a regular basis. 13 | 14 | And yes, if the project is short or 'small'~\textemdash~we can omit such documents. 15 | -------------------------------------------------------------------------------- /glossary/AcceptanceCriteria.tex: -------------------------------------------------------------------------------- 1 | \section{Acceptance Criteria} 2 | \label{sec:Acceptance Criteria} 3 | 4 | \begin{quote} 5 | Understand what is a \rindex{\textbf{C}!Criteria}Criteria first [p.\pageref{sec:Criteria}]. 6 | \end{quote} 7 | 8 | An \rindex{\textbf{A}!Acceptance criteria}\emph{Acceptance criteria} is a set of expectations. 9 | 10 | \textbf{Example}: '\textit{Yes, it works exactly as I expected! Shut up and take my money!}'. 11 | 12 | \textbf{Main idea}: the \emph{Acceptance Criteria} should be established directly by the user (or customer, or any other authorized entity), charged with authority to approve or reject, otherwise the whole idea has no sense. \begin{quote} 13 | Expectations must be satisfied by development team in order to be accepted by their customer. 14 | 15 | So, who can/should establish them instead of \rindex{\textbf{C}!Customer}Customer?\end{quote} 16 | 17 | Fun is that a Customer has no needs of any requirements or even acceptance criterias~\textemdash~the development team required them. If nobody understand this simple issue~\textemdash~your project can slide to hell. 18 | -------------------------------------------------------------------------------- /glossary/BoundaryValueTesting.tex: -------------------------------------------------------------------------------- 1 | \section{Boundary Value Testing} 2 | \label{sec:Boundary Value Testing} 3 | 4 | A test-design technique for explain the source where tester can search for ideas to create test cases. 5 | 6 | Represent an input (or output) value which is on the edge of an equivalence partition or at the smallest incremental distance on either side of an edge (boundary). 7 | 8 | \begin{description} 9 | \item[Example:] 10 | You can test a car at his minimum and maximum speed values (10 and 100 miles per hour). 11 | 12 | If the test will be ok, you can suppose, that in the interior of this range the car will work as expected. 13 | 14 | So, instead of doing 90 test cases (10 m/h, 11 m/h, 12 m/h....) you can check only two test cases and suppose (just suppose) that car will work as expected. 15 | \end{description} 16 | 17 | Sometimes this approach can help to save time and materials. 18 | 19 | Sometimes this approach totally sucks, if tester make a logical mistake or a false admit, that in the interior of the range everything will work as expected. 20 | -------------------------------------------------------------------------------- /_abstract.tex: -------------------------------------------------------------------------------- 1 | \begin{abstract} 2 | This is not an another '\textit{Full glossary of terms used in Software Testing}', or '\textit{Let's bring together every known term in our industry, because everyone needs it\ldots}'. 3 | 4 | I just had to notice my own \emph{definition dictionary} of some terms, so I did it. 5 | 6 | English is not my pet language, so any ping about ANY inaccuracy in this doc wil be appreciated. Thank you in advance. 7 | 8 | \bigskip 9 | 10 | Also you can: 11 | \begin{enumerate} 12 | \item 13 | download a new version of this pdf for free from GitHub \href{https://github.com/astenix/Software-Testing-Glossary}{bit.ly/2SLVYfz} (there are SCREEN and PRINT versions of this doc), 14 | \item 15 | ask me, if something wrong or unclear, 16 | \item 17 | pay attention to the fact that some terms require a detailed explanation, which is a subject of a whole lesson, apart from of a glossary, 18 | \item 19 | use and share this doc in any way but not with any commercial purposes. 20 | \end{enumerate} 21 | 22 | \begin{flushright} 23 | {\large\scshape Alex\'ei}\\ 24 | \end{flushright} 25 | 26 | \end{abstract} 27 | -------------------------------------------------------------------------------- /glossary/ChecklistbasedTesting.tex: -------------------------------------------------------------------------------- 1 | \section{Checklist-based Testing} 2 | \label{sec:Checklist-based Testing} 3 | 4 | \rindex{\textbf{R}!Checklist-based Testing}Stupid term, but it is very human\ldots 5 | 6 | If you need to dig a hole in the mother Earth, you will need a spade. And the process of creating a hole will be called 'to dig', not something like 'spade digging'. Because it doesn't matter, how you will dig a hole. You will use a spade, of course. Or your hands. 7 | 8 | When you will use in testing a checklist, this is still the same testing, right?! 9 | 10 | But if you want to feel yourself less dumb, you can say, that you will use the \textbf{Checklist-based Testing}. Something unusual! Something great! A new type of testing! 11 | 12 | And if someone will interfere, just tell him following magic words: \russianq{\textit{A checklist-based Testing is a test design technique whereby the experienced tester uses a high-level list of items to be noted, checked, or remembered, or a set of rules or criteria against which a product has to be verified. Step aside, whiffet!}} 13 | 14 | All the chicks will starve to death admiring you, my ass. 15 | -------------------------------------------------------------------------------- /glossary/UsabilityTesting.tex: -------------------------------------------------------------------------------- 1 | \section{Usability Testing} 2 | \label{sec:Usability Testing} 3 | 4 | Usability testing is a technique used in user-centered interaction design to evaluate a product by testing it on users. This can be seen as an irreplaceable usability practice, since it gives direct input on how real users use the system. This is in contrast with usability inspection methods where experts use different methods to evaluate a user interface without involving users. 5 | 6 | Even if it is called 'testing', it doesn't look like usual functional testing, done by QA engineers. 7 | 8 | \begin{quote} 9 | But this is a testing, because it involved some research and it brings information. 10 | \end{quote} 11 | 12 | Usability testing focuses on measuring a human-made product's capacity to meet its intended purpose. Examples of products that commonly benefit from usability testing are foods, consumer products, web sites or web applications, computer interfaces, documents, and devices. Usability testing measures the usability, or ease of use, of a specific object or set of objects, whereas general human-computer interaction studies attempt to formulate universal principles. -------------------------------------------------------------------------------- /glossary/CostofQuality.tex: -------------------------------------------------------------------------------- 1 | \section{Cost of Quality} 2 | \label{sec:Cost of Quality} 3 | 4 | \rindex{\textbf{C}!Cost of Quality}This is a calculation of the total cost of quality-related efforts and deficiencies. The results of such calculations sometimes lead to sever managerial decisions at the whole Project scale. 5 | 6 | It was first described by \rindex{\textbf{A}!Armand Feigenbaum}Armand Feigenbaum in a 1956 Harvard Business Review article. 7 | 8 | Cost of Quality is the total costs incurred on quality activities and issues and often split into prevention costs, appraisal costs, internal failure costs and external failure costs. 9 | 10 | If you don't know how much \$\$ costs the last founded Defect, then you cannot know the Cost of Quality on your Project. 11 | 12 | Advanced in the Project, this amount grows, because with the time each Project engage more and more software, time and materials. Sometimes managers try to reduce the cost of quality without reduce the quality. Well, sometimes this help a lot. Sometimes this is not the smartest decision. It depends of... 13 | 14 | Check the 'Cost of poor quality' ideas \url{https://en.wikipedia.org/wiki/Cost_of_poor_quality}. 15 | -------------------------------------------------------------------------------- /glossary/Strategy.tex: -------------------------------------------------------------------------------- 1 | \section{Strategy} 2 | \label{sec:Strategy} 3 | 4 | \begin{quote} 5 | \textbf{Source}: Merriam-Webster's Learner's Dictionary \\ \& \url{https://en.wikipedia.org/wiki/Strategy} 6 | \end{quote} 7 | 8 | \rindex{\textbf{S}!Strategy} \rindex{\textbf{W}!War}It is a very ancient word, means "\texttt{art of military troops leader}". 9 | 10 | It comes from the science (and art) of military command exercised to meet the enemy in combat under advantageous conditions for our glorious troops and disadvantageous conditions for our disgraceful enemy. 11 | 12 | \begin{quote} 13 | And our enemy tries to do the same. Like in a chess game. 14 | \end{quote} 15 | 16 | Strategy is important because the resources available to commandment are usually limited. 17 | 18 | Strategic planning and strategic thinking involves 19 | \begin{itemize} 20 | \item 21 | setting goals, 22 | \item determining a general pattern of actions to achieve the goals, 23 | \item and mobilizing resources to execute the actions. \end{itemize} 24 | 25 | You don't really know how this goal will be achieved, because it is a matter of the \emph{Tactics}. 26 | -------------------------------------------------------------------------------- /glossary/ChangeManagement.tex: -------------------------------------------------------------------------------- 1 | \section{Change Management} 2 | \label{sec:Change Management} 3 | 4 | \rindex{\textbf{C}!Change Management}This is an approach to controlled way to effect a change, or a proposed change, to a product or service. 5 | 6 | It is not only about software testing. But if you tend to be a manager in testing area\ldots\footnote{~See a nice 'How-to introductory guide' to Change management area at \url{http://www.change-management.com/how-to-guide.htm}} 7 | 8 | \subsection{'Change management' principles} 9 | \label{sec:'Change management' principles} 10 | 11 | \begin{enumerate} 12 | \item 13 | At all times involve and agree support from people within system (system = environment, processes, culture, relationships, behaviors, etc., whether personal or organizational). 14 | \item 15 | Understand where you/the organization is at the moment. 16 | \item 17 | Understand where you want to be, when, why, and what the measures will be for having got there. 18 | \item 19 | Plan development towards above No.3 in appropriate achievable measurable stages. 20 | \item 21 | Communicate, involve, enable and facilitate involvement from people, as early and openly and as fully as is possible. 22 | \end{enumerate} 23 | -------------------------------------------------------------------------------- /glossary/DefectbasedTestDesignTechnique.tex: -------------------------------------------------------------------------------- 1 | \section{Defect-based Test Design Technique} 2 | \label{sec:Defect-based Test Design Technique} 3 | 4 | \rindex{\textbf{D}!Defect-based}Well, this is not a technique (an approach, I suppose), but it's worthing your attentive attention. 5 | 6 | If you will focus on searching defects, not on checking if requirements are implemented~\textemdash~what will you see? 7 | 8 | When the target defects are determined based on taxonomies (a \rindex{\textbf{T}!Taxonomy}Taxonomy is a hierarchical list) that list root causes, defects, and failures, adequate coverage is achieved when sufficient tests are created to detect the target defects and no additional practical tests are suggested. 9 | 10 | \textbf{Example}: list some potential defects for your app. Or make some assumptions, like 'User add several items to cart, and each entry will not disappear with each new item added' and~\textemdash~check it out. If this will happen for real~\textemdash~hooray, you just supposed a bug and you really made him discovered! 11 | 12 | If not~\textemdash~suppose something else, and check it out. 13 | 14 | This approach is far, far away from reading basic requirements, add an item to cart, as expected, and declare, that everything is ok. 15 | -------------------------------------------------------------------------------- /glossary/IterativeDevelopmentModel.tex: -------------------------------------------------------------------------------- 1 | \section{Iterative Development Model} 2 | \label{sec:Iterative Development Model} 3 | 4 | Check \href{http://en.wikipedia.org/wiki/Iterative_and_incremental_development}{Iterative and incremental development}\footnote{~\url{http://en.wikipedia.org/wiki/Iterative_and_incremental_development}} article in wikipedia, please. There are nice pictures too. 5 | 6 | Iterative Development ModelIterative and Incremental development is any combination of both iterative design or iterative method and incremental build model for software development. This process may be described as an 'evolutionary acquisition' or 'incremental build' approach. 7 | 8 | The relationship between iterations and increments is determined by the overall software development methodology and software development process. The exact number and nature of the particular incremental builds and what is iterated will be specific to each individual development effort. 9 | 10 | Iterative and incremental development are essential parts of the Modified waterfall models, Rational Unified Process, Extreme Programming and generally the various agile software development frameworks. 11 | 12 | It follows a similar process to the 'plan-do-check-act' cycle of business process improvement. 13 | -------------------------------------------------------------------------------- /glossary/BestPractice.tex: -------------------------------------------------------------------------------- 1 | \section{Best Practice} 2 | \label{sec:Best Practice} 3 | 4 | 5 | This is the worst thing, that you can get from something (or someone) and try to adapt it at your needs. There are no best practices, everything depends of the context. You cannot get the most valuable from the \rindex{\textbf{C}!Capitalism}Capitalism and \rindex{\textbf{C}!Communism}Communism, and mix it in a new religion for your own project. 6 | 7 | \begin{quote} 8 | 9 | 10 | What is the best in Capitalism is immediately available with its worst things, and this things cannot be separated, like Mercedes cannot be separated from 'german approach of doing cars'. Just imagine the building of Mercedes in Russia. 11 | 12 | What is the best for one crew, can be crucial badly for any other. 13 | \end{quote} 14 | 15 | Simple, honest alternatives to 'Best practices' are available: 16 | 17 | \begin{itemize} 18 | \item “Here’s what I would recommend for this situation...” 19 | \item “Here is a practice I find interesting...” 20 | \item “Here is my favorite practice for dealing with {x}...” 21 | \item “{Person $X$} attributes {practice $Y$} for his success. Maybe you’d like to learn about it...” 22 | \end{itemize} 23 | 24 | Saying \russianq{best practice} is obviously irresponsible. 25 | -------------------------------------------------------------------------------- /glossary/CompatibilityTesting.tex: -------------------------------------------------------------------------------- 1 | \section{Compatibility Testing} 2 | \label{sec:Compatibility Testing} 3 | 4 | \rindex{\textbf{C}!Compatibility Testing}This is a part of non-functional testing. During this type of testing we try to understand, if the tested application is compatible with the computing environment or other specified application. 5 | 6 | For example, an app designed to retrieve data from Internet should be compatible with all type of networks. Or an app, designed to work with Excel 97 format (.xls) should work with \rindex{\textbf{E}!MS Excel}Excel 2010 format (.xlsx) 7 | 8 | Often you will hear about \rindex{\textbf{F}!Firefox}Browser compatibility testing, which can be more appropriately referred to as user experience testing, but anyway. This requires that the web applications are tested on different web browsers, to ensure the following: 9 | 10 | \begin{itemize} 11 | \item 12 | Users have the same visual experience irrespective of the browsers through which they view the web application. 13 | \item 14 | In terms of functionality, the application must behave and respond the same way across different browsers and sometimes~\textemdash~operating systems. 15 | \item 16 | Hardware (different phones and applications). \end{itemize} 17 | -------------------------------------------------------------------------------- /glossary/SuspensionCriteria.tex: -------------------------------------------------------------------------------- 1 | \section{Suspension and Resumption Criteria} 2 | \label{sec:Suspension and Resumption Criteria} 3 | \begin{quote} 4 | Understand what is a \rindex{\textbf{C}!Criteria}Criteria first [p.\pageref{sec:Criteria}]. 5 | \end{quote} 6 | 7 | \rindex{\textbf{E}!Entry criteria}\emph{Entry and Exit criteria} are the conditions which when satisfies, the test team starts (enters) the testing process and stops (exits) it. 8 | 9 | \rindex{\textbf{S}!Suspention criteria}\emph{Suspension and Resumption criteria} are the conditions which when satisfies, the test team temporarily suspends (suspension) the testing process and resumes (resumption) it. 10 | 11 | A test process may have to be suspended temporarily until the show stopper \rindex{\textbf{B}!Bug}bugs are resolved. 12 | 13 | Examples: 14 | 15 | \begin{quote} 16 | The project scope was agreed and approved by the client at the time indicated in the project schedule, but something goes wrong with the testing environment 17 | 18 | The project scope is agreed, the requirements are defined and approved by the client, but requirements was unexpectedly changed 19 | 20 | The credentials to the third-parties or/and external tools was available at the time indicated in the project schedule, but SUDDENLY they are not working.\end{quote} 21 | -------------------------------------------------------------------------------- /my_scripts/clearProjectFiles.sh: -------------------------------------------------------------------------------- 1 | #!/bin/bash 2 | # ---------------------------------- 3 | # Author: Alexei Lupan 4 | # The script delete technical files from project rest after closing Kile. 5 | # It doesnt' ask questions. It is ireversible. 6 | # Man: https://losst.ru/komanda-find-v-linux 7 | # echo -e добавляет перенос строки через \n 8 | 9 | echo -e "\nList of removed files: \n" 10 | # ../ 11 | # Подняться на уровень выше (ведь скрипт лежит в подкаталоге). 12 | # -not -path "../.git/*" 13 | # Убрать из поиска каталог .git, бо там тоже хранятся файлы 14 | # с расширениями "для удаления", и если их убрать, поломается 15 | # синхронизация с репозиториями в git. 16 | # -regex '.*\.\(aux\... 17 | # Выполнить поиск по расширениям файлов согласно регулярке. 18 | # -print 19 | # Вывести список найденных файлов. Просто для информации. 20 | #-delete 21 | # Удалить все файлы из этого списка. 22 | # Опция -delete всегда в конце всей команды! 23 | # Иначе будут удалены ВСЕ файлы в корне, включая файлы, 24 | # которые не заканчиваются на указаные расширения, и файлы 25 | # в глубоких суб-суб-каталогах. 26 | 27 | find ../ -not -path "../.git/*" -regex '.*\.\(aux\|backup\|bbl\|bib~\|blg\|dvi\|gitignore~\|glg\|glo\|glo\|gls\|idx\|ind\|ilg\|log\|lot\|lof\|out\|plt\|ps\|sh~\|sty~\|tex~\|toc\|gz\|xdy\)' -print -delete 28 | 29 | echo -e "\n= = = = DONE \n" 30 | -------------------------------------------------------------------------------- /glossary/Version.tex: -------------------------------------------------------------------------------- 1 | \section{Version} 2 | \label{sec:Version} 3 | 4 | \rindex{\textbf{V}!Version}The versioning is the process of assigning either unique version names or unique version numbers to unique states of computer software. 5 | 6 | Usually the version of a program is presented like this: 7 | 8 | \begin{quote} 9 | ver. \texttt{3.12.242}\end{quote} 10 | 11 | Let's read it: 12 | 13 | \begin{description} 14 | \item[Major release]~\textemdash~\#3. 15 | 16 | The software was developed to the third release. 17 | 18 | \item[Minor release]~\textemdash~\#12. 19 | 20 | In the third major release was added some functionality. Maybe was added 12 new functions in one day. 21 | 22 | Maybe not, maybe to 11 already existed functions today was the 12. 23 | 24 | Maybe in major release \#3 was added only one new function, with 11 important updates. 25 | 26 | \item[Build]~\textemdash~\#242 \rindex{\textbf{B}!Build} 27 | 28 | I can suppose, that someone had a bad day and made 242 bugfixes. Each bugfix increase build numbering with $+1$. 29 | \end{description} 30 | 31 | At a fine-grained level, revision control is often used for keeping track of incrementally different versions of electronic information, whether or not this information is computer software. 32 | 33 | We can change numbers at any time. Now we have ver. \texttt{3.12.242}. Add one new feature, and this can be ver. \texttt{3.13.0} Apply some small modifications, and we have ver. \texttt{3.13.1} Add one new feature, and here is the ver. \texttt{3.14.0} 34 | -------------------------------------------------------------------------------- /glossary/BetaTesting.tex: -------------------------------------------------------------------------------- 1 | \section{Beta Testing} 2 | \label{sec:Beta Testing} 3 | 4 | \rindex{\textbf{B}!Beta Testing}Beta Testing is a testing approach, specific only for mass-market products (\rindex{\textbf{W}!MS Word}Word, \rindex{\textbf{S}!Skype}Skype, \rindex{\textbf{F}!Firefox}Firefox so on). 5 | 6 | Means that the Development team select a big bunch of already existed users of their product (usually this happens outside of the development company), and ship to them the Product in Testing 'as is'. 7 | 8 | \textbf{Main idea}~\textemdash~developments will receive a lot of '\textit{Something is going wrong when I tried to do following...}' messages. This can help in testing the Product on different testing configuration, without spending time trying to create it in our testing laboratory. And User Experience can reveal something really unexpected. 9 | 10 | \textbf{Main problem}: not every message from beta testing users is a \rindex{\textbf{B}!Bug Report}\emph{Bug Report}. Will be a lot of garbage or already reported issues. Will be generated a lot of issues, which cannot be reproduced for some reasons (usually, because of a lack of information and because bug reporters didn't know that there are some common rules of writing bug reports). 11 | 12 | And even if all messages will be Bug Reports, do you know how to deal with a thousand of reports about the same \rindex{\textbf{B}!Bug}Bug? 13 | 14 | For internet shops Beta testing is not applicable at all (users can be scared of bugs at Checkout, so only Alpha Testing [p.\pageref{sec:Alpha Testing}] is appropriate), and is a part of standard testing process. 15 | -------------------------------------------------------------------------------- /glossary/SCRUM.tex: -------------------------------------------------------------------------------- 1 | \section{SCRUM} 2 | \label{sec:SCRUM} 3 | 4 | \rindex{\textbf{S}!SCRUM}The term itself comes from Rugby game, and describes a way of starting play again, in which players from each team come together and try to get control of the ball by pushing against each other and using their feet, when the ball is thrown in between their feet. 5 | 6 | \begin{figure}[!h] 7 | \centering 8 | \includegraphics[width=0.8\linewidth]{realScrum} 9 | \caption{\ttfamily{This is the real Scrum}} 10 | \label{fig:realScrum} 11 | \end{figure} 12 | 13 | You can say '\textit{Jump everybody and let's kill them all!}' and millions will respond~\textemdash~yes! Well, this is \rindex{\textbf{W}!War}Rugby. 14 | 15 | But you will suppose the SCRUM as a development approach, huh?! 16 | 17 | \begin{figure}[!h] 18 | \centering 19 | \includegraphics[width=1\linewidth]{scrumFramework} 20 | \caption{\ttfamily{SCRUM Framework}} 21 | \label{fig:scrumFramework} 22 | \end{figure} 23 | 24 | You will even say 'A software development methodology!', do you?! 25 | 26 | This is not a methodology. 27 | 28 | This is a software development framework (a \rindex{\textbf{S}!Strategy}strategy) for managing product development, driven by agile principles. For being applied, the dev team already should have a development methodology. 29 | 30 | Again, framework OVER a methodology. 31 | 32 | \begin{verbatim} 33 | ELSE 34 | Fail(); 35 | \end{verbatim} 36 | 37 | See \rindex{\textbf{A}!Agile Software Development} Agile Software Development explanation [p.\pageref{sec:Agile Software Development}] \& agile principles at (\url{http://agilemanifesto.org/}) or GTFO. 38 | -------------------------------------------------------------------------------- /glossary/ActualResult.tex: -------------------------------------------------------------------------------- 1 | \section{Actual Result} 2 | \label{sec:Actual Result} 3 | 4 | You always have some \textbf{Expectations} when you make an action for testing. Otherwise the whole testing has no sense. 5 | 6 | \begin{quote} 7 | Testing is always to compare the \rindex{\textbf{E}!Expected result}\emph{Expected} and the \rindex{\textbf{A}!Actual result}\emph{Actual} results. 8 | 9 | When you have no expectations, then you can make an investigation, a research~\textemdash~anything but not testing. 10 | \end{quote} 11 | 12 | Suppose, that I want to know if I can send an email notification from a Product page. 13 | 14 | I have an expectation like \ordinaryq{\textit{I will call \ordinaryq{Send email} function, I will provide appropriate data in input fields, and I will receive a notification}}. This is the \textbf{Expected result} of a test case. 15 | 16 | Suppose, that I am really open a Product Detail Page and I am looking for the \ordinaryq{Send email} function. It is available? If yes, than I really can send an email with it? 17 | 18 | This will be the \textbf{Actual result}. 19 | 20 | You can have more than one actual results. 21 | 22 | A tester should always suppose the \textbf{Expected result} (a mandatory part of any Test Case [p.\pageref{sec:Test Case}]), but he will never be sure about the Actual result. 23 | 24 | If any difference between Expected and Actual Result~\textemdash~this can be a \hyperref[sec:Bug]{Bug} [p.\pageref{sec:Bug}]. 25 | 26 | \begin{quote} 27 | Or the Expected result is wrong, and Test Case should be updated. 28 | 29 | Or something was unexpectedly changed during development. 30 | 31 | Or a third-party application has down. 32 | \end{quote} 33 | -------------------------------------------------------------------------------- /glossary/FunctionalRequirement.tex: -------------------------------------------------------------------------------- 1 | \section{Functional Requirement} 2 | \label{sec:Functional Requirement} 3 | 4 | \rindex{\textbf{F}!Functional Requirement}In programming a Function is a named section of a program that performs a specific task. 5 | 6 | In the same way that a File is a named section of some data on your hard-disk drive. 7 | 8 | \begin{quote} 9 | The term function is also used synonymously with operation and command. For example, you execute the 'delete' function to erase a word. 10 | \end{quote} 11 | 12 | A \textbf{Function}, in its most general use, is what a given entity does in being what it is [p.\pageref{sec:Function}]. 13 | 14 | The \textbf{Functionality} is an ability of software to perform a task. 15 | 16 | A \textbf{Functional Requirement} is an abstract, which describes the functionality task that a software system should \textbf{do} for the user needs. 17 | 18 | \begin{quote} 19 | And a Non-functional requirements usually place constraints on \textbf{how} the system will do so. See [p.\pageref{sec:Non-functional Requirement}] for details. \end{quote} 20 | 21 | An \textbf{example} of a functional requirement would be that a system must send a an email whenever a certain condition is met (e.g. an order is placed, a customer signs up, etc). 22 | 23 | \begin{quote} 24 | A related non-functional requirement for the system can be that emails should be sent with a latency of no greater than 12 hours from such an activity. 25 | \end{quote} 26 | 27 | Then \textbf{Functional Requirements} are done, it's time to write \textbf{Functional Specifications}. 28 | 29 | You understand the difference between Requirements and Specifications? 30 | -------------------------------------------------------------------------------- /glossary/InScopeOutofScope.tex: -------------------------------------------------------------------------------- 1 | \section{In Scope / Out of Scope} 2 | \label{sec:In Scope / Out of Scope} 3 | 4 | A 'scope' is an abstract term for setting the area or subject relevant for the discussion. 5 | 6 | \begin{quote} 7 | For example, two men meet for a coffee. For sure, they will start to discuss business issues, and only business issues will be in scope of their conversation. Any other stuff (cars, pets, women) will be 'out of scope'. 8 | 9 | But when this two will have to exterminate the second bottle of \rindex{\textbf{W}!Whiskey}'Johnnie Walker', business issues will become 'out of scope', and chat will be oriented to cars, women, pets and other important for business issues. \end{quote} 10 | 11 | Same thing relate to testing: testers have to establish from the start which functionality will be tested during next testing session; they should list all functions 'in scope' and all the functions, which will not be tested during this session, and agree with Development and Client about why this will be and those will not be tested. 12 | 13 | \begin{quote} 14 | By the way, such documents are called Testing Scope and they are an indispensable part of any \rindex{\textbf{T}!Test Plan}Test Plan.\end{quote} 15 | 16 | Why testers must define the Testing Scope? This should be done especially to cover testers heads in case of strange questions appears, like '\textit{But why this and those things wasn't tested?}'. 17 | 18 | Sometimes testers can save their lives with this 'in scope' and 'out of scope' lists. 19 | 20 | Sometimes not. 21 | -------------------------------------------------------------------------------- /glossary/VerificationAndValidation.tex: -------------------------------------------------------------------------------- 1 | \section{Verification} 2 | \label{sec:Verification} 3 | 4 | This is the basic level of any testing, it comes from the verb \texttt{to verify}. 5 | 6 | \rindex{\textbf{V}!Verification}Verification is the simplest confirmation of any \emph{expectation} (or assumption) by examination and through provision of objective evidence that specified requirements have been fulfilled. 7 | 8 | \textbf{Example}: have a pie. 9 | 10 | \begin{quote} 11 | Or a \emph{borscht}. 12 | 13 | Or a car. 14 | \end{quote} 15 | 16 | Verification is the basic checking that this pie can be eaten, and if so, then the quality of the pie is ok. 17 | 18 | Sometimes it is more than enough just to be sure, that software does what was expected. 19 | 20 | But sometime not. 21 | 22 | I am sure, that you will expect, that the pie should be tasty, right?! 23 | 24 | \subsection{and Validation} 25 | \label{sec:and Validation} 26 | 27 | \rindex{\textbf{V}!Validation}Confirmation by examination and through provision of objective evidence that the informal requirements for a specific intended use or application have been fulfilled. 28 | 29 | Any pie can be cooked as expected by recipe, and this can be tested (verified). But even if recipe is only one, the taste of pies will vary from one cook to other. And because it is very hard to set the requirements of 'how to do a tasty pie', this start to lead to informal requirements. And such reqs can be tested only at the \emph{Validation} level. 30 | 31 | This two terms are always presented in testing, but they are not declared. 32 | 33 | Any \rindex{\textbf{T}!Test Case}test case can be declared as '\textit{This is a validation test}' or '\textit{This test is about verification only}'. But obviously, nobody will ask '\textit{Let's write some validational test cases, please}'. 34 | -------------------------------------------------------------------------------- /glossary/SmokeTesting.tex: -------------------------------------------------------------------------------- 1 | \section{Smoke Testing} 2 | \label{sec:Smoke Testing} 3 | 4 | \rindex{\textbf{S}!Smoke Testing}This is just a convenient metaphor, defining a process of superficial testing, required to being done before the real, deeper advanced testing started. 5 | 6 | The idea consist in following: before starting to explore new build, set assure that all at least main functionality (differ from project to project) is on: 7 | 8 | \begin{itemize} 9 | \item 10 | product catalog is available, 11 | \item you can add a product to cart, 12 | \item you can run trough checkout process, 13 | \item user profile are available, 14 | \item and so on. 15 | \end{itemize} 16 | 17 | If smoke testing will fail, then the whole testing process will be worthless. 18 | 19 | If smoke testing is ok, then we can advance in testing, as expected. 20 | 21 | Usually normal people call this checking \rindex{\textbf{S}!Sanity Testing}'sanity testing' (and developers do the same), others (factory engineers) \rindex{\textbf{I}!Integrity Testing}'integrity testing'. As manual functional testers, we called it 'Smoke testing'. 22 | 23 | \begin{quote} 24 | A lot of years ago the testing of electronic devices started with real 'smoke testing'~\textemdash~plug the device to an outlet and set power 'on'. 25 | 26 | If you see light and smoke~\textemdash~forget about testing, the device is broken, you will burn. \end{quote} 27 | 28 | Smoke testing is always based on a subset of defined/planned \rindex{\textbf{T}!Test Case}test cases, that cover the main functionality of a component or system, to ascertaining that the most crucial functions of a program work, but not bothering with finer details. 29 | 30 | A daily build and smoke test is among industry best practices. 31 | -------------------------------------------------------------------------------- /glossary/RegressionTesting.tex: -------------------------------------------------------------------------------- 1 | \section{Regression Testing} 2 | \label{sec:Regression Testing} 3 | 4 | This process is very annoying and costs are high, but we can drive it in a smart way, trough \rindex{\textbf{I}!Impact Analysis}Impact Analysis [p.\pageref{sec:Impact Analysis}]. 5 | 6 | \rindex{\textbf{R}!Regression Testing}So, every system (social, political, military or software system) should continuously expand his functional possibilities to survive. This is a \textbf{Progress}. 7 | 8 | But with more opportunities, the more relationships appears, and the more chances to find a defect. Or not to find it. This is a \textbf{Regress}. 9 | 10 | \textbf{Regression testing} is performed for getting know, if regression appears. 11 | 12 | \begin{quote} 13 | Testing brings information, remember this simple idea? 14 | \end{quote} 15 | 16 | This activity only looks like we should test some modification in software to ensure that defects have not been introduced or uncovered in unchanged areas of the software, as a result of the changes made. In fact, 'Regression testing' can be done periodically, without any changes in software. 17 | 18 | \begin{quote} 19 | Now deal with it.\end{quote} 20 | 21 | One of our interest is to discover negative behavior, that's why we are doomed to perform a 'Regression testing' each time when new functionality is added to a software. 22 | 23 | And 'Regression testing' it is sometimes performed when the environment is changed. 24 | 25 | \begin{quote} 26 | Environment, not software. You can call this 'Integration testing', but what kind of Integration it is, if the software still the same? 27 | \end{quote} 28 | 29 | You will be a great donkey, if you will advance in 'Regression testing' having only old \rindex{\textbf{T}!Test Case}test cases, '\textit{Cause this is just a re-test, right, ma?}'. You will need new test cases because of ANY significant change in software structure. 30 | -------------------------------------------------------------------------------- /glossary/Component.tex: -------------------------------------------------------------------------------- 1 | \section{Component Testing} 2 | \label{sec:Component Testing} 3 | 4 | A \rindex{\textbf{C}!Component Testing}\textbf{Component} is an abstract common term. We suppose here any minimal software item that can be tested in isolation, without interaction with any other software items. 5 | 6 | \begin{quote} 7 | E.g., user only can create new profile, but all other functions like setup user avatar or name are unavailable (or are not tested for some reason). The user profile is just a Component from the System point of view, and inside of this Component the ability to add an avatar is just a Component too. 8 | 9 | Your finger is a component of your hand. And your hand is a component of your body. And your body is a component of your country. 10 | 11 | Any complex System can be just a component of any other System.\end{quote} 12 | 13 | \textbf{Component Testing} is aimed at verification of the correct work of \textbf{individual} software components, such as specific functional areas or/and features (or sub-features) without ensure that any other components works as expected. 14 | 15 | It may include the \rindex{\textbf{F}!Function Testing}functional testing, as well as testing of designs and content of the features or/and functional areas. 16 | 17 | The \textbf{strong side} of this approach is obvious~\textemdash~the component can be tested from A to Z. 18 | 19 | Common \textbf{weakness} of this approach: apart some components can work as expected, but then they are engaged in a system, they can interfere with other components and some unexpected defects may appear. That's why only component testing will never be enough. 20 | 21 | Usually internet shops are deployed as a bunch of components, which are already integrated. This means, that a clear isolation of some Components for testing purposes cannot be achieved. That's fine, because we always provide our shops packed with all amount of functionality. 22 | -------------------------------------------------------------------------------- /glossary/MigrationTesting.tex: -------------------------------------------------------------------------------- 1 | \section{Migration Testing} 2 | \label{sec:Migration Testing} 3 | 4 | \rindex{\textbf{M}!Migration Testing}Consider that a company switch from one DBMS to another (from MySQL to Oracle). Or the architecture of DB requires a massive innovation. Then will be required a database Migration testing. 5 | 6 | Database migration may be done manually, but it is more common to use an automated ETL (Extract-Transform-Load) process to move the data. 7 | 8 | Database migration testing may encounter problems when: 9 | \begin{enumerate} 10 | \item The data in the source database(s) changes during the test; 11 | \item Some of the source data is corrupt; 12 | \item The mappings between the tables/ fields of the source databases(s) and target database are changed by the database development/ migration team; 13 | \item A part of the data from the source database is rejected by the target database; 14 | \item Data migration takes too long because the database migration process is too slow or the source data file is too large. 15 | \end{enumerate} 16 | 17 | The test approach for database migration testing consists of the following activities: 18 | 19 | \begin{enumerate} 20 | \item 21 | Design the validation tests. In order to test database migration, SQL queries are created either by hand or using a tool, such as a query creator. The test queries should contain logging statements for the purpose of effective analysis and bug reporting after the tests are complete. 22 | \item Set up the test environment. The test environment should contain a copy of the source database, the ETL tool (if applicable) and a clean copy of the target database. The test environment should be isolated so that it is not changed externally during the tests. 23 | \item Run your validation tests Depending on the test design, the database migration process does not need to completely finish before starting tests. 24 | \item Report the bugs. 25 | \end{enumerate} 26 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Software Testing Glossary 2 | 3 | A damn simple definition dictionary from testitquickly.com 4 | 5 | There are two versions of this doc with identical content: 6 | * pdf [for screen](https://github.com/testitquickly/Software-Testing-Glossary/raw/master/Software%20Testing%20Glossary%20(Alexei%20Lupan).pdf) / [bit.ly/2SNogHg](http://bit.ly/2SNogHg) 7 | * pdf [for print](https://github.com/testitquickly/Software-Testing-Glossary/raw/print_version/Software%20Testing%20Glossary%20(Alexei%20Lupan).pdf) / [bit.ly/3bA88S0](http://bit.ly/3bA88S0) 8 | 9 | ## Abstract 10 | This is not an another ’_Full glossary of terms used in Software Testing_’. I just had to notice my own definition dictionary of some terms, so I did it. 11 | 12 | English is not my pet language, so any ping about ANY inaccuracy in this doc wil be appreciated. Thank you in advance. 13 | 14 | Also you can: 15 | - download a new version of this pdf for free from this repo (SCREEN version of this doc is in _master_ and PRINT version is in _print_version_ branch), 16 | - ask me, if something wrong or unclear, 17 | - understand, that some terms require a detailed explanation, which is a subject of a whole lesson, apart from of a glossary, 18 | - use and share this doc in any way but not with any commercial purposes. 19 | 20 | ## About author 21 | Alexei Lupan, QA analyst & trainer 22 | Alexei Lupan 23 | 24 | Interested in test design issues and organization and providing full advanced trainings for new QA stuff. 25 | 26 | Happy with baritone guitars and Robert Heinlein’s books. 27 | 28 | LinkedIn: [testitquickly](https://www.linkedin.com/in/testitquickly/) 29 | 30 | Personal Website: [testitquickly.com](https://testitquickly.com/) 31 | 32 | Email: astenix@testitquickly.com 33 | 34 | Project URL: [testitquickly.github.io/Software-Testing-Glossary/](https://testitquickly.github.io/Software-Testing-Glossary/) 35 | -------------------------------------------------------------------------------- /glossary/NonfunctionalRequirement.tex: -------------------------------------------------------------------------------- 1 | \section{Non-functional Requirement} 2 | \label{sec:Non-functional Requirement} 3 | 4 | A \rindex{\textbf{R}!Requirements}requirement that does not relate to functionality, but to attributes such as reliability, efficiency, usability, maintainability and portability. 5 | 6 | Typically non-functional requirements fall into areas such as: 7 | \begin{itemize} 8 | \item 9 | Accessibility 10 | \item Capacity, current and forecast 11 | \item Compliance 12 | \item Documentation 13 | \item Disaster recovery 14 | \item Efficiency 15 | \item Effectiveness 16 | \item Extensibility 17 | \item Fault tolerance 18 | \item Interoperability 19 | \item Maintainability 20 | \item Privacy 21 | \item Portability 22 | \item Quality 23 | \item Reliability 24 | \item Resilience 25 | \item Response time 26 | \item Robustness 27 | \item Scalability 28 | \item Security 29 | \item Stability 30 | \item Supportability 31 | \item Testability 32 | \end{itemize} 33 | 34 | \begin{quote} 35 | How you will test the Effectiveness of \rindex{\textbf{W}!MS Word}MS Word processor? :) 36 | \end{quote} 37 | 38 | Non-functional requirements are sometimes defined in terms of metrics (something that can be measured about the system) to make them more tangible. For example, the Effectiveness of MS Word processor can be described binary~\textemdash~it is effective or not. Or it can be described, for example, from 1 to 10 points. 39 | 40 | Suppose the level of user excitement when he drive an Cadillac Eldorado 1959~\textemdash~this is a non-functional requirement. 41 | 42 | Suppose the level of user annoying when he use an app, which crashes each time when wi-fi connection is down for a second~\textemdash~this is a non-functional requirement. 43 | 44 | \subsection{Non-functional Testing} 45 | \label{sec:Non-functional Testing} 46 | 47 | Testing the attributes of a component or system that do not relate to functionality, e.g. reliability, efficiency, usability, maintainability and portability. 48 | -------------------------------------------------------------------------------- /glossary/SecurityTesting.tex: -------------------------------------------------------------------------------- 1 | \section{Security Testing} 2 | \label{sec:Security Testing} 3 | 4 | \rindex{\textbf{S}!Security Testing}Usually~\textemdash~a process intended to reveal flaws in the security mechanisms of an information system that protect data and maintain functionality as intended. 5 | 6 | It looks like a simple 'Let's find some possibility to stole credit card numbers from our shop!' approach, but in fact Security Testing represent a totally different approach than testing some functionality, involving a lot of programming skills. Usually it looks like someone explore/decompile a program and write his own program for explore and decompile others. 7 | 8 | \begin{quote} 9 | If you are bored for a little by \rindex{\textbf{F}!Functional Testing}Functional Testing, and you are looking for something else, then Security is the latest area for you. This is a whole profession, whis involve a lot of programming and administration servers skills and knowledge. 10 | \end{quote} 11 | 12 | Well, winter is coming\ldots~Prepare for cold times. Are we enough strong for say 'Hello!' to winter? Are our bodies prepared for that? 13 | 14 | Imagine a simple Doctor. At university he studied the human body, starting with cutting the frogs in the school laboratory, and then progressively started the autopsy of human bodies in the dissecting room. 15 | 16 | Now suppose yourself. Do you know about medicine something more than 'If I'll get a chill, I will drink a hot tea with lemon and Aspirin!? 17 | 18 | Feel the difference? 19 | 20 | Who can effectively suppose/assume/find some weaknesses in human body? You, with tea and Aspirin, or a Doctor, who has killed during his university ages more frogs than you saw movies with \rindex{\textbf{B}!Bruce Lee}Bruce Lee? 21 | 22 | Only just because it is called 'testing' (exactly like 'Functional Testing'!), each year a new generation of junior-jedi testers tries to study 'something new in testing'. 23 | 24 | To succeed in security testing, it is necessary not only to understand how something is built, but why someone made certain technical decisions. 25 | -------------------------------------------------------------------------------- /glossary/Traceability.tex: -------------------------------------------------------------------------------- 1 | \section{Traceability} 2 | \label{sec:Traceability} 3 | 4 | \begin{figure}[!h] 5 | \centering 6 | \includegraphics[width=1\linewidth]{TraceabilityMatrix} 7 | \caption{\ttfamily{Traceability Matrix sample}} 8 | \label{fig:TraceabilityMatrix} 9 | \end{figure} 10 | 11 | \rindex{\textbf{T}!Traceability}Traceability is the ability to identify related items in documentation and software, such as requirements with associated tests. 12 | 13 | A traceability matrix is a document, usually in the form of a table, that correlates any two baselined documents that require a many-to-many relationship to determine the completeness of the relationship. 14 | 15 | It is often used with high-level requirements (these often consist of marketing requirements) and detailed requirements of the product to the matching parts of high-level design, detailed design, \rindex{\textbf{T}!Test Plan}test plan, and \rindex{\textbf{T}!Test Case}test cases. 16 | 17 | A requirements traceability matrix may be used to check to see if the current project requirements are being met, and to help in the creation of a request for proposal, software requirements specification, various deliverable documents, and project plan tasks. 18 | 19 | Common usage is to take the identifier for each of the items of one document and place them in the left column. The identifiers for the other document are placed across the top row. When an item in the left column is related to an item across the top, a mark is placed in the intersecting cell. The number of relationships are added up for each row and each column. This value indicates the mapping of the two items. Zero values indicate that no relationship exists. It must be determined if a relationship must be made. Large values imply that the relationship is too complex and should be simplified. 20 | 21 | To ease the creation of traceability matrices, it is advisable to add the relationships to the source documents for both backward traceability and forward traceability. That way, when an item is changed in one baselined document, it's easy to see what needs to be changed in the other. 22 | -------------------------------------------------------------------------------- /glossary/Sprint.tex: -------------------------------------------------------------------------------- 1 | \section{Sprint} 2 | \label{sec:Sprint} 3 | 4 | The term \rindex{\textbf{S}!Sprint}\emph{Sprint} is coming from sport. It is the act of running over a short distance at top speed. 5 | 6 | \begin{quote} 7 | Opposite is 'stayer'~\textemdash~a long-distance runner.\end{quote} 8 | 9 | Depending of physical statement, runners specialize in running on long or short distances, because this are two different strategies of running. 10 | 11 | \begin{quote} 12 | Sprinters runs very fast, but only at short distances (no more than 100 m). They should make an extra effort from start, immediately, without any compromises, without trying to save some power or even air breathing. Human physiology dictates that a runner's near-top speed cannot be maintained for more than 30–35 seconds due to the accumulation of lactic acid in muscles. Just get up and run! 13 | 14 | Stayers starts slowly, at first they should try to hold on the group of all runners, at maximum saving energy. They will need all their power and speed in the latter stages of running, closer to the finish band. For example, marathon runners can run 42 km (plus ~195 m). \end{quote} 15 | 16 | In \rindex{\textbf{A}!Agile Software Development}Agile Software Development [p.\pageref{sec:Agile Software Development}] the term 'sprint' means almost the same~\textemdash~a short-time activity (typically one week long), where all the people involved in a project, being focused on development of some task for the project, give maximum of their power and attention. 17 | 18 | It is obvious, that to be a real sprinter 'week by week' without long rest it is impossible. In fact, everyone involved in project use a Stayer strategy. But nobody cares, because not everyone even understand the meaning of 'Sprint' term. You want me to say 'a sprint' instead of 'a week'? No problem. \rindex{\textbf{S}!SCRUM}Scrum, sprint, scope~\textemdash~whatever. You are the boss. 19 | -------------------------------------------------------------------------------- /glossary/AgileSoftwareDevelopment.tex: -------------------------------------------------------------------------------- 1 | \section{Agile Software Development} 2 | \label{sec:Agile Software Development} 3 | 4 | Means any software development approach, based and guided by \rindex{\textbf{A}!Agile Software Development}agile principles~(\url{http://agilemanifesto.org/}). 5 | 6 | Warning, based on agile \emph{Principles}, not Methodologies. 7 | 8 | There is a huge difference between \emph{Principles}: 9 | \begin{quote} 10 | \textit{I will not tolerate then someone will have no answer to a question, I will try to explain it immediately. I don't know how I will do it, I can use Jira tickets, email, Skype, personal visits, this doesn't matter.} 11 | \end{quote} 12 | and a \emph{Methodology}: 13 | \begin{quote} 14 | \textit{Everybody shut up! From now every person, who will need my answer to any question, should:} 15 | \begin{enumerate} 16 | \item \textit{formulate his question shortly and briefly (link to a guide)}, 17 | \item \textit{raise an issue in Jira using a 'Question' template (link to a guide)}, 18 | \item \textit{assign it to the appropriate person,} 19 | \item \textit{mention his QA Lead and Test Manager in watchers mandatory.} 20 | \end{enumerate} 21 | \end{quote} 22 | 23 | Feel free to feel the difference. 24 | 25 | Yes, the 'Agile methodology' does not exist. 26 | 27 | \begin{quote} 28 | The same with \rindex{\textbf{S}!SCRUM}SCRUM [p.\pageref{sec:SCRUM}]~\textemdash~this is not a methodology too, this is a software development \emph{framework} (a common strategy) for managing product development, driven by agile principles. 29 | 30 | You can drive a development process by SCRUM framework, used only \emph{over} a Methodology. 31 | \end{quote} 32 | 33 | A lot of people wants to know about 'Agile' only '\textit{You will always have a working product delivered}' (Lies!) or '\textit{We can easily rework any issue, just tell us what to do}' (Deliberate lies!) , or '\textit{True agile testers didn't use test cases!}' (Kill this bastard!), or '\textit{We will have no requirements, because we are Agile, aren't we?}' (Not enough bullets\ldots) and didn't care about how such goals will be achieved. This can drive the project to the hell, but we are brave enough to getting things done, aren't we? 34 | -------------------------------------------------------------------------------- /glossary/AgileTesting.tex: -------------------------------------------------------------------------------- 1 | \section{Agile Testing} 2 | \label{sec:Agile Testing} 3 | 4 | Even if it should be based on \rindex{\textbf{A}!Agile Software Development}Agile Software Development principles\footnote{~\url{http://agilemanifesto.org/}} [p.\pageref{sec:Agile Software Development}], the Testing activities still remain the same. 5 | 6 | There are no such thing like \rindex{\textbf{A}!Agile Testing}\emph{Agile Testing}. 7 | 8 | \begin{quote} 9 | What is the difference between drinking water from a cup or from a bottle? Anyway, you just drink water. 10 | \end{quote} 11 | 12 | The same with Testing~\textemdash~you should have to do all old things like 13 | 14 | \begin{enumerate} 15 | \item 16 | gather requirements, 17 | \item 18 | understand expextations, 19 | \item 20 | understand and preview situations for being tested, 21 | \item 22 | the expected results 23 | \item 24 | … 25 | \end{enumerate} 26 | 27 | The most common problem started immediately from '\emph{There are no \rindex{\textbf{R}!Requirements}Requirements}' issue. 28 | 29 | Everything else in Agile Testing derive from this goddamned '\emph{there are no Requirements}' mantra. You can have \rindex{\textbf{U}!User Story}User stories \& \rindex{\textbf{U}!Use Case}Use Cases, but for writing brilliant \rindex{\textbf{T}!Test Case}Test Cases you would scream for good brand old \rindex{\textbf{R}!Requirements}Requirements. 30 | 31 | The Testing process in agile development requires a totally new logical approach, and you may not fit with it at all. 32 | 33 | For example, for a tester in Agile is very important to be a master in \rindex{\textbf{E}!Exploratory Testing}Exploratory Testing or at least \rindex{\textbf{A}!Ad hoc testing}Ad Hoc testing, not a master in writing and executing \rindex{\textbf{T}!Test Case}Test Cases; and is important to handle very well the \rindex{\textbf{A}!Automated Testing}Automated Testing (from unit to complex functional testing), for increase speed of testing. 34 | 35 | Some person can excellent fit, others will certainly fail~\textemdash~this is a matter of psychology. 36 | 37 | And you can fail because you act with Agile like with just another \emph{development process}, not like with an approach of do the development \emph{closest to client needs}, and this is the second most common problem with Agile testing. 38 | -------------------------------------------------------------------------------- /glossary/AdhocTesting.tex: -------------------------------------------------------------------------------- 1 | \section{Ad hoc testing} 2 | \label{sec:Ad hoc testing} 3 | 4 | The term \rindex{\textbf{A}!Ad hoc testing}\ordinaryq{\emph{ad hoc}} has a Latin language origin, and can be translated like 5 | 6 | \begin{quote} 7 | \ordinaryq{\textit{Emergency, jump on everybody, there is no time to think, we have no plan, just let's kick out some barbarians, just go-go-go!}}. 8 | \end{quote} 9 | 10 | For us this is a name of a testing approach, usually explained as testing, but without test cases or requirements\footnote{~See figure \ordinaryq{Simple explanation of Classic \& Ad Hoc \& Exploratory Testing} at [p.\pageref{fig:ClassicAdHocExploratoryTesting}].}: 11 | 12 | \begin{itemize} 13 | \item without formal test preparation; 14 | \item with no recognized test design technique is used; 15 | \item without expectations for results and arbitrariness guides the test execution activity. 16 | \end{itemize} 17 | 18 | But this is very, very stupid! 19 | 20 | In fact, nobody said \russianq{DO NOT USE REQUIREMENTS in Ad hoc testing!} 21 | \begin{quote} 22 | Use them! 23 | \end{quote} 24 | 25 | Nobody said \russianq{DO NOT USE TEST CASES in Ad Hoc testing!} 26 | \begin{quote} 27 | Use them! 28 | \end{quote} 29 | 30 | The Ad Hoc is the second part of Classic Testing. Like 31 | \begin{itemize} 32 | \item 33 | White \& Black, 34 | \item 35 | Guitar \& Strings, 36 | \item 37 | Bonnie \& Clyde. 38 | \end{itemize} 39 | 40 | The Ad hoc testing approach aims to \emph{support} the formal testing approach (you call it Classic testing), where all testing activities are based on formal and logical execution. 41 | 42 | The weakest side of formal testing is the lack of some scenarios, that can be omitted by development team, but they can be discovered by end-users. The Ad Hoc testing can help to identify possible bugs, that cannot be discovered using formal scenarios. 43 | 44 | Some monkeys think that the Ad Hoc testing is the same as \rindex{\textbf{M}!Monkey Testing}'Monkey Testing' [p.\pageref{sec:Monkey Testing}]. They're wrong. 45 | 46 | \begin{itemize} 47 | \item {In monkey testing tester even doesn't understand, what and for what he has doing with the application.} 48 | 49 | \item {In Ad Hoc testing tester understand his goals and application capabilities, he implies logic in his actions, but he can easily switch between his goals and scenarios, without any reason for doing it.} 50 | \end{itemize} 51 | -------------------------------------------------------------------------------- /glossary/AcceptanceTesting.tex: -------------------------------------------------------------------------------- 1 | \section{Acceptance Testing} 2 | \label{sec:Acceptance Testing} 3 | 4 | A very ambiguous term. Depending of context: 5 | 6 | \textbf{1} 7 | 8 | A development project phase. 9 | 10 | At the end of any development project phase a customer representatives can started a (sometimes~\textemdash~\emph{very}) rigorous checking of every requirements, expectations and business capabilities implemented during the development process. Sometimes it is the unique solution to prevent a possible brilliant technical solution from failure. 11 | 12 | \rindex{\textbf{C}!Customer}Customer did not test, customer \emph{use} the product. You \emph{test} the product. You cannot test the product as a Customer does it. 13 | 14 | \begin{quote} 15 | You can test till the death on the \textbf{Development} and \textbf{Testing} environments, but only the \russianq{\textbf{UAT}} (\rindex{\textbf{U}!UAT, User Acceptance Testing}User Acceptance Testing) environment can be considered as the closest to production environment. So, some serious bugs can be founded \textbf{only} on UAT environment. \end{quote} 16 | 17 | That's why \russianq{Acceptance Testing} can be done only from the customer point of view~\textemdash~by the customer himself. We can only help him, by sharing our test-docs/ideas. 18 | 19 | \begin{quote} 20 | And only by the Customer itself. 21 | 22 | Or only by his brave testers and accountants. 23 | \end{quote} 24 | 25 | Only on UAT you can use for checkout not only 'Visa for testing' cards, but real payment issues. 26 | 27 | Only on UAT you can use real payment filters, or a real database with customer's stuff, or a real connection with Warehouse. 28 | 29 | And this is the reason to not invite development team to test on UAT and Production servers. 30 | 31 | \textbf{2} 32 | 33 | An approach to software development. 34 | 35 | This approach is coming from TDD ('Testing Driven Development') family. 36 | 37 | Implies that every requirement statement is published and handled by the customer as automated Test case (using with special software like \rindex{\textbf{F}!FitNesse}'FitNesse' wiki-system - see demo at \url{https://youtu.be/wzmVJ3HYftA}. 38 | -------------------------------------------------------------------------------- /glossary/PairTesting.tex: -------------------------------------------------------------------------------- 1 | \section{Pair Testing} 2 | \label{sec:Pair Testing} 3 | 4 | Sometimes more than one human beings work together on a single task. If the task is about testing something~\textemdash~welcome to \rindex{\textbf{P}!Pair Testing}Pair testing. 5 | 6 | One does the testing and the other analyzes or reviews the testing. They can always switch their roles. 7 | 8 | Pair Testing can significantly speed up the testing. One person is a \textbf{Driver}, second is a \textbf{Navigator}. 9 | 10 | \begin{figure}[!h] 11 | \centering 12 | \includegraphics[width=0.8\linewidth]{navigator} 13 | \caption{\ttfamily{Beyond the limits}} 14 | \label{fig:Navigator} 15 | \end{figure} 16 | 17 | Both minds can generate testing ideas, and immediately execute them. While Navigator stay for make a note about what was doing and the results, Driver can run and generate next idea, and so on. This can be done between one tester and developer or business analyst or between two testers with both participants taking turns at driving the keyboard. No limits, really! 18 | 19 | This approach come from \rindex{\textbf{E}!Exploratory Testing}Exploratory Testing area [p.\pageref{sec:Exploratory Testing}], and it's very controversial. From the manager's point of view, Pair Testing looks like TWO working units do ONE job, so one testing task costs double. While this, will be better if those TWO working units were doing at the same time TWO testing tasks. 20 | 21 | For sure, this if very OK, when the task is to dig a hole at the land. And sometimes testing really looks like digging. 22 | 23 | \begin{quote} 24 | You remember the '\textit{You see, in this world there are two kinds of people, my friend: those with a loaded gun and those who dig. You dig}' © from 'The Good The Bad and the Ugly' movie? 25 | 26 | We must understand and admit this truest statement. \end{quote} 27 | 28 | But there are a lot of tasks in testing, when we need more brains for work, than hands. For such tasks \rindex{\textbf{P}!Pair Testing}Pair Testing can be a wonderful approach, where TWO smart people can work as ONE unit best and quicker than two working units apart. 29 | 30 | At the end of Pair Testing this two persons survive so many challenges, that as a nice persons, they have to marry each other, so be careful with this software development technique. 31 | -------------------------------------------------------------------------------- /glossary/AutomatedTesting.tex: -------------------------------------------------------------------------------- 1 | \section{Automated Testing} 2 | \label{sec:Automated Testing} 3 | 4 | An approach to testing, where some functional testing in application under development can be done by special Robots instead of Human beings. 5 | 6 | \begin{quote} 7 | Sometime it helps. Sometimes not. 8 | 9 | It can be fun. It can be stupid.\end{quote} 10 | 11 | Usually such testing activity can only demonstrate that your application works as expected~\textemdash~nothing was broken or damaged during development. 12 | 13 | Automated test cases are very 'simple and stupid'. 14 | 15 | \begin{quote} 16 | Suppose, that you have a link as an image on the page, and the image was lost for some reason. 17 | 18 | Automated tests will be 'blind and deaf' if no images will be available on page for a hyperlink~\textemdash~test script will click on link and the testing will go on without any error warnings.\end{quote} 19 | 20 | Automated test cases are very unstable, they will fail immediately, if the locators of elements on the page will have ANY (even one symbol) changes. For this reason, each fail should be investigated apart, because nobody knows, if the fail happens because of a bug, or because the test script itself is obsolete or incomplete. 21 | 22 | Automated test cases run very fast, they can interact with tested software faster than any human can see. 23 | 24 | \begin{quote} 25 | For the first time this looks fun, but later you realize, that you cannot understand what happens on the page during testing. You lose the control. 26 | \end{quote} 27 | 28 | Automated test cases can use an unlimited test data variety. 29 | 30 | This approach involve a lot of special programming work before the testing begin and a lot of programming after. 31 | 32 | This job can be done by developers or by skilled testers, but anyway~\textemdash~for being done, it requires the availability of well done developed and documented \rindex{\textbf{T}!Test Case}Test Cases. 33 | 34 | The candidates for the test automation may be as follows by priorities: 35 | 36 | \begin{enumerate} 37 | \item 38 | test cases that are included in smoke testing; 39 | \item 40 | test cases that are executed more frequently during regression testing; 41 | \item 42 | test cases that are executed less often, such as low priority test cases that are not included either in smoke tests or in regression tests; 43 | \item 44 | test cases that are difficult to execute manually because of large data sets, or because it takes too much time to setup and run). \end{enumerate} 45 | -------------------------------------------------------------------------------- /glossary/EntryexitCriteriaforTesting.tex: -------------------------------------------------------------------------------- 1 | \section{Entry and Exit Criteria for Testing} 2 | \label{sec:Entry and Exit Criteria for Testing} 3 | 4 | \begin{quote} 5 | Understand what is a \rindex{\textbf{C}!Criteria}Criteria first [p.\pageref{sec:Criteria}]. 6 | \end{quote} 7 | 8 | Sometimes is very hard to agree about when we can start or stop testing. 9 | 10 | For example, developers already had developed something, and \rindex{\textbf{C}!Customer}Client call us to start testing. In his opinion, this is enough for starting testing~\textemdash~here are some functionality, just use your imagination and common sense and go on. But we still have no requirements, and we cannot be sure, that we are on the same page with developers about what and how should work. Can we just shut up and let's the mortal testing begin, or we will hang on our hands and refuse to start, because we had no time for preparation, no test cases, no requirements\ldots? 11 | 12 | Yes, if we have common sense and we can discuss with our customer any issue, we can start without any requirements and fears. 13 | 14 | But if the Customer is \rindex{\textbf{M}!Mafia}Al Capone itself, and in case of something will fail on our website you will wake up in the morning being silently buried in a black box under the heavy ground\ldots We need to agree something before the process will start. 15 | 16 | Entry/exit Criteria for Testing are a set of generic and specific Conditions discussed between the client and executor. This criteria doesn't exist as a law, and always can be/should be revisited. 17 | 18 | \subsection{Entry criteria for testing} 19 | \label{sec:Entry criteria for testing} 20 | 21 | \rindex{\textbf{E}!Entry criteria}The purpose of Entry criteria is to prevent a task from starting which would entail more (wasted) effort compared to the effort needed to remove the failed entry criteria. 22 | 23 | Entry criteria for testing can be following: 24 | 25 | \begin{itemize} 26 | \item 27 | for each functionality we have a requirement available, 28 | \item 29 | we have enough human resources for the testing process, 30 | \item 31 | all third-party units are available for being used with our system under test, 32 | \item 33 | build is frozen and no new functionality will be added or changed... \end{itemize} 34 | 35 | 36 | \subsection{Exit criteria for testing} 37 | \label{sec:Exit criteria for testing} 38 | 39 | \rindex{\textbf{E}!Exit criteria} The purpose of Exit criteria is to prevent a task from being considered completed when there are still outstanding parts of the task which have not been finished. Exit criteria are used to report against and to plan when to stop testing. 40 | 41 | Exit criteria for testing can be following: 42 | 43 | \begin{itemize} 44 | \item all critical functionality was tested and here is the complete report, 45 | \item all discovered critical bugs was fixed and retested, 46 | \item the time for testing is out...\end{itemize} 47 | 48 | By the way, sometimes \textbf{Exit Criteria} for Testing is called as \textbf{Completion Criteria}. 49 | -------------------------------------------------------------------------------- /glossary/Defect.tex: -------------------------------------------------------------------------------- 1 | \section{Defect} 2 | \label{sec:Defect} 3 | 4 | \rindex{\textbf{D}!Defect}A flaw in a component or system that can cause the component or system to fail to perform its required function, e.g. an incorrect statement or data definition. 5 | 6 | Usually we name it \rindex{\textbf{B}!Bug}Bug [p.\pageref{sec:Bug}]. 7 | 8 | \subsection{Defect Management} 9 | \label{sec:Defect Management} 10 | 11 | This is a process of 12 | 13 | \begin{itemize} 14 | \item 15 | recognizing, 16 | \item 17 | investigating, 18 | \item 19 | taking action 20 | \item 21 | and disposing of defects. 22 | \end{itemize} 23 | 24 | It involves recording defects, classifying them and identifying the impact on the project or tested application. 25 | 26 | \subsection{Defect Report} 27 | \label{sec:Defect Report} 28 | 29 | A document (an item in \rindex{\textbf{J}!Jira}Jira) reporting on any flaw in a component or system that can cause the component or system to fail to perform its required function. 30 | 31 | \subsection{Priority and Severity} 32 | \label{sec:Priority and Severity} 33 | 34 | Consider the impact of Defect at the whole system. 35 | 36 | And here is two terms for this classification: 37 | 38 | \subsubsection{Severity} 39 | \label{sec:Severity} 40 | 41 | \begin{description} 42 | \item[Critical]~\textemdash~such severity is assigned when you lose the ability to work with the System because a Bug happens. You have lose information, or the Product cannot do his main task, or the Device is reset because of overloading... Almost every Bug at Checkout is Critical :) 43 | 44 | \item[Major] – well, you can somehow continue to work, or you can switch to another task, but the system is seriously affected by this Bug. 45 | 46 | \item[Minor] – bug is available, but it does not adversely affect the Product functionality. \end{description} 47 | 48 | Who is charged with authority to set the Severity? 49 | 50 | First of all~\textemdash~the tester, who had discovered the Bug. 51 | 52 | Second~\textemdash~the team lead. 53 | 54 | Or the Manager. 55 | 56 | Or the Client itself. 57 | 58 | \subsubsection{Priority} 59 | \label{sec:Priority} 60 | 61 | The level of business importance assigned to an item, e.g. defect. 62 | 63 | For example, on our site user can buy some cool stuff, and on the checkout the field 'Provide your credit card info' is missed. This is a Critical bug with High priority. 64 | 65 | Or on our site user can buy some cool stuff, and on the checkout the field 'Provide your credit card info' is available, but is named 'Provide your credit card info hzhzhzhzhzh'. This is a Major bug with High priority. 66 | 67 | Or on our site user can buy some cool stuff, and on the checkout the field 'Provide your credit card info' is available, but is named 'Provide your credit card' instead of 'Provide your credit card info'. This is a Minor bug with High priority. 68 | 69 | Or on our site user can buy some cool stuff, and they can download our worldwide stores list, but the file is missed on the file server. This is a Major bug with Minor priority. Yes, this is a bug, it is important, but we will fix it when we will have enough time. Forget about it\ldots 70 | -------------------------------------------------------------------------------- /glossary/AlphaTesting.tex: -------------------------------------------------------------------------------- 1 | \section{Alpha Testing} 2 | \label{sec:Alpha Testing} 3 | 4 | \rindex{\textbf{A}!Alpha Testing}Alpha Testing is the name of an approach to testing, where the Development team ships his work to \emph{internal} testing team only. 5 | 6 | Get it? An \emph{approach}, not a phase in testing process. But anything can be presented like a phase, so\ldots 7 | 8 | Alpha Testing approach is specific for development Internet Shops, games and almost any kind of software, where human beings opinion matters. 9 | 10 | Surely, technically we can always publish an software with some bugs, and '\textit{…if users will tell us about it, we will fix them quickly. It is just a question of \rindex{\textbf{C}!Cost of Failure}'cost of failure}'. 11 | 12 | Well, today the cost of failure looks very low, because 'You can easily fix the software online'. 13 | 14 | \begin{quote} 15 | \rindex{\textbf{S}!Skype}Skype, \rindex{\textbf{F}!Firefox}Firefox, \rindex{\textbf{T}!Twitter}Twitter, \rindex{\textbf{F}!Facebook}Facebook~\textemdash~they always ship first, then fix. 16 | 17 | Why don't you do the same? 18 | \end{quote} 19 | 20 | But 'Shops' always means 'Money', and money requires confidence. We cannot ship an Internet Shop with any bugs in functionality, because it can scarry future customers and this can burn out our asses. Or because they can cheat, and again, this is all about money. 21 | 22 | And not every bug can be fixed quickly. 23 | 24 | So we will frenzy test our software BEFORE it will be offered to our customers and will call this \emph{Alpha Testing}. 25 | 26 | The next big step will/can be \rindex{\textbf{B}!Beta Testing}\textbf{Beta Testing} [p.\pageref{sec:Beta Testing}]: this means that the Development team will select a small bunch of potential users of their product (usually outside from the development company), and will ship to them the Product 'as is', just for testing purposes. 27 | 28 | \begin{quote} 29 | And, because you are asking, we are aware that there is no \emph{Gamma} or \emph{Delta} testing. 30 | 31 | But they was! An IBM PM Martin Belsky\footnote{~\href{http://bit.ly/2kf9S9H}{bit.ly/2kf9S9H}} has invented them just for name some logical steps. 32 | 33 | \begin{description} 34 | \item[The $A$-test] was a feasibility and manufacturability evaluation done before any commitment to design and development. 35 | 36 | \item[The $B$-test] was a demonstration that the engineering model functioned as specified. 37 | 38 | \item[The $C$-test] (corresponding to today's beta) was the $B$-test performed on early samples of the production design. 39 | 40 | \item[The $D$-test] was the $C$-test, repeated after the model had been in production a while, to verify final safety. \end{description} 41 | 42 | We don't care about this today, so\ldots 43 | \end{quote} 44 | 45 | There is a \textbf{Main problem} with Alpha Testing~\textemdash~internal testing cannot reveal EACH issue, that can happens in production. It can assure only that all functionality works as expected in expected scenarios and conditions. 46 | 47 | \begin{quote} 48 | Are you really sure, that all scenarios and conditions in your software was foreseen? 49 | 50 | Really? 51 | \end{quote} 52 | 53 | Often this limitation is very clear to development, but not for the \rindex{\textbf{C}!Customer}Customer. 54 | -------------------------------------------------------------------------------- /glossary/PerformanceTesting.tex: -------------------------------------------------------------------------------- 1 | \section{Performance Testing} 2 | \label{sec:Performance Testing} 3 | 4 | Initially, \rindex{\textbf{P}!Performance testing}\emph{Performance} is an activity that a person does to entertain an audience, such as singing a song or acting in a play on a Broadway. 5 | 6 | In technical language, \emph{Performance} is the ability of a mechanism to do an required action (or activity). It can be evaluated only as a numerical value. 7 | 8 | \begin{quote} 9 | \textbf{Example}: the old Cadillac Eldorado 1953 engine, we have reached a level of 100 km/h in 42 seconds, and this was possible because of 210 horsepower expected and available. 10 | 11 | Performance can be evaluated, varied and measured in follow mode: 'Let's find out, if will be possible to reach a level of 100 km/h in 32 seconds at the old Cadillac Eldorado 1953 engine, if we will setup 240 horsepower instead of 230'. 12 | 13 | Performance can be evaluated, varied and measured in follow mode 'Let's find out, how much time the old Cadillac Eldorado 1953 engine will work, if we will put a brick on the accelerator pedal and will have to wait'. 14 | \end{quote} 15 | 16 | \subsection{Load \& Stress testing} 17 | \label{sec:Load and Stress testing} 18 | 19 | Performance testing simply implies \textbf{Load} and \textbf{Stress} testing. Difference between this testing types is logical and lies in the fact that different types of performance testing answer to different business questions. 20 | 21 | \begin{quote} 22 | \rindex{\textbf{L}!Load testing}Load testing help us to understand the behavior of the system under a specific \textbf{expected} load. 23 | 24 | \rindex{\textbf{S}!Stress testing}Stress testing is normally used to understand the \textbf{upper limits} of capacity within the system. \end{quote} 25 | 26 | \textbf{Example}: there are an application with DB based on the MySQL. MySQL is a popular choice of database for use in web applications, an open-source relational database management system. 27 | 28 | MySQL can easily support 200 hits per second (12 000 per minute, and 720 000 per hour, and 17 280 000 per day). How to test the performance of this web-site? 29 | 30 | \begin{quote} 31 | We can use JMeter for generate 100 hits per second. Is anything ok? 32 | 33 | Let's generate 190 hits. Is anything ok? 34 | 35 | Let's generate 210 hits. Is anything ok? 36 | 37 | Let's generate 300 hits. Is anything ok? 38 | 39 | Let's generate 500 hits. Is anything ok? 40 | 41 | Let's generate 210 hits during 6 hours. Is anything ok? \end{quote} 42 | 43 | We have the same utils and we do the same things. But first it was simple Performance testing, then it became Load testing, then it became Stress testing, then it again became Load testing. 44 | 45 | \subsection{Reliability Testing} 46 | \label{sec:Reliability Testing} 47 | 48 | \rindex{\textbf{R}!Reliability Testing}'Reliability' is a term for testing a software's ability to function, given environmental conditions, for a particular amount of time. 49 | 50 | For example, turn on the coffee machine and use it 100 hours without any stop. Will be some problems in the software and functionality? Will be coffee available after this 100 hours? And if Yes, then what about 200 non-stop hours? Or 1000? 51 | 52 | \subsection{Maintenance Testing} 53 | \label{sec:Maintenance Testing} 54 | 55 | \rindex{\textbf{M}!Maintenance Testing}Is that testing which is performed to either identify equipment problems, diagnose equipment problems or to confirm that repair measures have been effective. 56 | 57 | It can be performed at either the system level, the equipment level, or the component level. 58 | 59 | Maintenance testing uses system performance requirements as the basis for identifying the appropriate components for further inspection or repair. 60 | 61 | A good testing program will maintain a record of test results and maintenance actions taken. These data will be evaluated for trends and serve as the basis for decisions on appropriate testing frequency, need to replace or upgrade equipment and performance improvement opportunities. 62 | -------------------------------------------------------------------------------- /glossary/WhiteBoxBlackBox.tex: -------------------------------------------------------------------------------- 1 | \section{White Box / Black Box Testing} 2 | \label{sec:White Box Black Box Testing} 3 | 4 | It is completely not about colors (Black/White), but nobody cares (and clearly will not). 5 | 6 | Please, do not share the stupid idea that \ordinaryq{\textit{White Box can be done when you look into the source code, and the Black Box can be done when you don't have an acces to source code}}. There are thousand of situations, when you'll look directly into the source code, and you will perform classic Black Box testing. 7 | 8 | \begin{quote} 9 | Later you will realize, that developers understand this \ordinaryq{boxes} better than testers\ldots 10 | \end{quote} 11 | 12 | \rindex{\textbf{W}!White Box} \rindex{\textbf{B}!Black Box}\ordinaryq{White~\&~Black} boxes are just a very convenient \emph{metaphors} [p.\pageref{sec:Metaphor}] in testing terminology. They perfectly explain the source where tester has searched for ideas to create \rindex{\textbf{T}!Test Case}test cases\footnote{~Situations to be tested}. 13 | 14 | Keep it simple. As a tester you have to 15 | \begin{itemize} 16 | \item 17 | realize what kind of situation may happen when user will start to interact with the application (and which situations can happen, but should not), 18 | \item 19 | create these situations one by one and see what's happen. \end{itemize} 20 | 21 | This is the whole \emph{Testing}. 22 | 23 | You can have all those situations listed in \rindex{\textbf{R}!Requirements}Requirements [p.\pageref{sec:Requirement}]. If it so, then you are a lucky bastard (or you are in army). But for a mass-market application (any modern website) you will be out of this luxury. So, you have to invent or discover them by yourself. How to do it? 24 | 25 | Sometimes you can know exactly how your app should working. You will imagine situations (so \rindex{\textbf{T}!Test Case}test cases will appear), and you will swtich to the illuminated zone~\textemdash~the \ordinaryq{White box} metaphor. 26 | 27 | \begin{quote} 28 | Doesn't matter, where you will bring this information. You can read requirements? Now you know. You can read source code? Now you know. You can ask someone who knows about it? Now you know too. 29 | \end{quote} 30 | 31 | Sometimes you know nothing, and you slide to a darker zone (the 'Black box' metaphor), where you have to often suppose what should happen than knowing exactly. You should explore, like \ordinaryq{Let's provide to this input field several characters and see how the software will react to it\ldots}. 32 | 33 | As you can see, the \emph{researching} (or, sometimes, exploration) is not a testing. They are always close, but they are not the same. 34 | 35 | \begin{quote} 36 | In testing you ALWAYS know the \rindex{\textbf{E}!Expected result}expected result. And you can compare it with \rindex{\textbf{A}!Actual result}actual result. 37 | 38 | In researching you may be blind about the expected result, but when you will know~\textemdash~you can test. That's why texting and researching are always close. 39 | \end{quote} 40 | 41 | \subsection{Why \ordinaryq{boxes}} 42 | 43 | The software, in the eyes of a tester, is like a box with some magic inside. 44 | 45 | You don't know exactly how and why the coffe-machine works, but you can interact with it. The \ordinaryq{box} is \ordinaryq{black}. 46 | 47 | You may not understand how and why an engine works (or how it looks like), but you can drive a car. The \ordinaryq{box} is \ordinaryq{black}. 48 | 49 | You don't know what to do with your miserable life, but you still live it. The \ordinaryq{box} is \ordinaryq{black}. 50 | 51 | And if you know How and Why it works~\textemdash~the box became \ordinaryq{transparent} for you. 52 | 53 | \begin{quote} 54 | That's why someone can say \ordinaryq{A glass box}, or even \ordinaryq{The transparent box}, opposite to \ordinaryq{The black box}. 55 | \end{quote} 56 | 57 | \subsection{What about strategies} 58 | 59 | \rindex{\textbf{G}!Glenford J. Myers}Bearded old school testers (covered by bearded old school developers) claims that the \ordinaryq{White/Black Box Testing} is a \emph{strategy}\footnote{~\russianq{Art of Software Testing} by Glenford J. Myers, 1979, John Wiley \& Sons, Inc.} [p.\pageref{sec:Strategy}]. And if this is a strategy, then we can combine the \ordinaryq{black} and \ordinaryq{white} to the \ordinaryq{gray box}. 60 | 61 | Well, it really looks alike. But no. 62 | 63 | And there are no \ordinaryq{gray} boxes in testing. 64 | -------------------------------------------------------------------------------- /main.tex: -------------------------------------------------------------------------------- 1 | % SCREEN version 2 | \documentclass[a4paper, oneside, 12pt]{article} 3 | 4 | \usepackage{project_styles/project_styles_screen_version} 5 | 6 | \makeindex 7 | 8 | \hypersetup{ 9 | pdfinfo={ 10 | Title={Software Testing Glossary from testitquickly.com}, 11 | Author={Alexei Lupan}, 12 | Subject={Software Testing}, 13 | Keywords={Testing, Glossary}, 14 | Year={2016} 15 | }} 16 | 17 | % Указал место, где находятся все картинки проекта 18 | \graphicspath{{./images/}} 19 | 20 | % Перечень возможных расширений изображений 21 | \DeclareGraphicsExtensions{.jpg,.gif,.png,.eps,.pdf} 22 | 23 | \begin{document} 24 | 25 | \thispagestyle{empty} 26 | {\begingroup 27 | \centering 28 | \vfill 29 | {\fontsize{40}{60}\selectfont \textbf{Software Testing \\Glossary}} 30 | 31 | \vfill \null 32 | 33 | 34 | \begin{center} 35 | {\Large Alexei Lupan}\\ 36 | \Large \today 37 | \end{center} 38 | \endgroup} 39 | 40 | \newpage 41 | 42 | \input{_abstract} 43 | 44 | \newpage 45 | 46 | \input{_author.tex} 47 | 48 | \newpage 49 | 50 | \tableofcontents 51 | 52 | \newpage 53 | 54 | \pagestyle{plain} 55 | 56 | \input{./glossary/AcceptanceCriteria} 57 | \input{./glossary/AcceptanceTesting} 58 | \input{./glossary/ActualResult} 59 | \input{./glossary/AdhocTesting} 60 | \input{./glossary/AgileSoftwareDevelopment} 61 | \input{./glossary/AgileTesting} 62 | \input{./glossary/AlphaTesting} 63 | \input{./glossary/AutomatedScripts} 64 | \input{./glossary/AutomatedTesting} 65 | \input{./glossary/AvailabilityTesting} 66 | \input{./glossary/BestPractice} 67 | \input{./glossary/BetaTesting} 68 | \input{./glossary/BoundaryValueTesting} 69 | \input{./glossary/Bug} 70 | \input{./glossary/BugReporting} 71 | \input{./glossary/BugTrackingSystem} 72 | \input{./glossary/BugVerification} 73 | \input{./glossary/Build} 74 | \input{./glossary/ChangeManagement} 75 | \input{./glossary/ChangeRequest} 76 | \input{./glossary/ChecklistbasedTesting} 77 | \input{./glossary/CompatibilityTesting} 78 | \input{./glossary/Component} 79 | \input{./glossary/ContinuousIntegration} 80 | \input{./glossary/CostofQuality} 81 | \input{./glossary/Coverage} 82 | \input{./glossary/Criteria} 83 | \input{./glossary/Debugging} 84 | \input{./glossary/DecisionTableTesting} 85 | \input{./glossary/Defect} 86 | \input{./glossary/DefectbasedTestDesignTechnique} 87 | \input{./glossary/DevelopmentEnvironment} 88 | \input{./glossary/DevelopmentofTestCases} 89 | \input{./glossary/DocumentationTesting} 90 | \input{./glossary/DomainAnalysisTesting} 91 | \input{./glossary/EndtoendTesting} 92 | \input{./glossary/EntryexitCriteriaforTesting} 93 | \input{./glossary/EquivalenceClassTesting} 94 | \input{./glossary/ExhaustiveTesting} 95 | \input{./glossary/ExploratoryTesting} 96 | \input{./glossary/Feature} 97 | \input{./glossary/Function} 98 | \input{./glossary/FunctionalRequirement} 99 | \input{./glossary/FunctionalSpecifications} 100 | \input{./glossary/FunctionalTesting} 101 | \input{./glossary/ImpactAnalysis} 102 | \input{./glossary/InScopeOutofScope} 103 | \input{./glossary/IntegrationTesting} 104 | \input{./glossary/ItemPassFailCriteria} 105 | \input{./glossary/IterativeDevelopmentModel} 106 | \input{./glossary/MaintenanceofTestCases} 107 | \input{./glossary/Metaphor} 108 | \input{./glossary/MigrationTesting} 109 | \input{./glossary/MonkeyTesting} 110 | \input{./glossary/NegativeTesting} 111 | \input{./glossary/NonfunctionalRequirement} 112 | \input{./glossary/PairTesting} 113 | \input{./glossary/Pairwise} 114 | \input{./glossary/PerformanceTesting} 115 | \input{./glossary/PositiveTesting} 116 | \input{./glossary/Precondition} 117 | \input{./glossary/Quality} 118 | \input{./glossary/RegressionTesting} 119 | \input{./glossary/Requirement} 120 | \input{./glossary/RootCause} 121 | \input{./glossary/SCRUM} 122 | \input{./glossary/SecurityTesting} 123 | \input{./glossary/Server} 124 | \input{./glossary/SmokeTesting} 125 | \input{./glossary/Sprint} 126 | \input{./glossary/Staging} 127 | \input{./glossary/Strategy} 128 | \input{./glossary/SuspensionCriteria} 129 | \input{./glossary/System} 130 | \input{./glossary/Test} 131 | \input{./glossary/Testability} 132 | \input{./glossary/TestCase} 133 | \input{./glossary/TestDesign} 134 | \input{./glossary/TestIdea} 135 | \input{./glossary/TestScenario} 136 | \input{./glossary/TestSuite} 137 | \input{./glossary/Traceability} 138 | \input{./glossary/UsabilityTesting} 139 | \input{./glossary/UseCase} 140 | \input{./glossary/UserStory} 141 | \input{./glossary/VerificationAndValidation} 142 | \input{./glossary/Version} 143 | \input{./glossary/WhiteBoxBlackBox} 144 | 145 | \clearpage 146 | 147 | \printindex 148 | 149 | \end{document} 150 | -------------------------------------------------------------------------------- /glossary/EquivalenceClassTesting.tex: -------------------------------------------------------------------------------- 1 | \section{Equivalence Class Testing} 2 | \label{sec:Equivalence Class Testing} 3 | 4 | \begin{quote} 5 | \rindex{\textbf{E}!Equivalence Class Testing}This should be called \textbf{Equivalence partitioning of test cases}, but nobody cares.\end{quote} 6 | 7 | Don't pretend that this technique can be used to reduce the number of test cases without lowering the test coverage, because reducing test cases always lower the test coverage level. Automobiles was created for consuming petrol or for carrying human beings from the maternity hospital to the cemetery as fast as possible? 8 | 9 | \subsection{Class} 10 | 11 | A \rindex{\textbf{C}!Class}class is a group of some items with some common attributes, characteristics, qualities, or traits. 12 | 13 | Grouping is useful for science, it helps to discuss as single entities whole classes, not separate items. 14 | 15 | Trick is that \emph{one item} can inherit different characteristics and qualities \emph{at the same time}. For example, an usual \emph{man} can be added to several groups (classes) simultaneously: 16 | 17 | \begin{itemize} 18 | \item 19 | human being 20 | \item 21 | bus driver 22 | \item 23 | pig 24 | \item 25 | father 26 | \end{itemize} 27 | 28 | \subsection{Equivalence} 29 | 30 | There are a lot of terms for showing that two items are equal: equal, comparable, identical, correspondent, duplicate, matched, uniform. 31 | 32 | Any two things can be called equal, if they have the exactly same attributes. 33 | 34 | \begin{quote} 35 | 36 | \textbf{Example}: you have two brand new bottles of \rindex{\textbf{W}!Whiskey}whiskey. 37 | 38 | They exists apart in this Universe, but now they are identical, equal, the same, they duplicate each other. 39 | 40 | If you will open one bottle, they immediately will become unequal (one is opened, the other is sealed). 41 | 42 | But once both bottles are opened, they again become equal. 43 | \end{quote} 44 | 45 | Ok, this bottles cannot be called 'equal' for real. But they can be declared as 'equal' only for our convenience. 46 | 47 | There is an \emph{meta} word for such statement: this two bottles are not equal (identical), but for the final result you can act with them like they ARE identical. This is called \emph{Equivalence}. 48 | 49 | \begin{quote} 50 | 51 | \textbf{Other example}: you should use a passenger train for travel in \rindex{\textbf{M}!Metro train}metro. Will matter what kind of train you will have to use? His color, capacity, length, personal number and the manufacturing year, or something like that? 52 | 53 | No! All those DIFFERENT trains from your route WILL BE equivalent one to others, while your journey. 54 | 55 | If you will use one of thousand trains, you can assume, that all other trains can complete the same task. 56 | 57 | Again, all those trains are not equal one to others. Each of them has his own number, different colors, different history and brake conditions, they was released in different ages. They are not equal, they are only equivalent. 58 | \end{quote} 59 | 60 | Warning! Equivalence is not a substitution or something totally equal. 'Equivalence' is not 'Equality'. 61 | 62 | 63 | \subsection{Equivalence partitioning of test cases} 64 | 65 | An equivalence class \emph{can} consists from a set of data that is treated the same by the module or that should produce the same result. Any data value within a class is equivalent, in terms of testing, to any other value. Specifically, we would expect that if one \rindex{\textbf{T}!Test Case}test case in an equivalence class detects a defect, all other test cases in the same equivalence class are likely to detect the same defect. 66 | 67 | A group of tests forms an equivalence class if you \emph{believe} that: 68 | 69 | \begin{itemize} 70 | \item 71 | They all test the same thing. 72 | \item 73 | If one test catches a bug, the others probably will too. 74 | \item 75 | If one test doesn't catch a bug, the others probably won't either. 76 | \end{itemize} 77 | 78 | This approach assumes, of course, that a specification exists that defines the various equivalence classes to be tested. 79 | 80 | And you should clearly understand, that your 'grouping' of test cases can be formally good, but totally wrong. 81 | 82 | The \textbf{main gap}: for example, you get your car from the car service, and the mechanic says: \russianq{\textit{We had to check all the wheels. Well, we checked only two wheels with brakes. You know, they're all four are equivalent to each other, so we have checked out those two, they are ok, so we \emph{assume} that the remaining wheels are ok too. Have a nice day}}. Will you have a nice day? 83 | 84 | Divide into equivalence classes only \rindex{\textbf{T}!Test Case}Test cases, not the \rindex{\textbf{F}!Functionality}Functionality of a product. 85 | -------------------------------------------------------------------------------- /glossary/Bug.tex: -------------------------------------------------------------------------------- 1 | \section{Bug} 2 | \label{sec:Bug} 3 | 4 | This is an 'umbrella' term. 5 | 6 | Usually a \rindex{\textbf{B}!Bug}\emph{Bug} is a flaw in a component (or system) that can cause the component (or system) to fail to perform its required function, e.g. an incorrect statement or data definition. 7 | 8 | But not every Bug is a \rindex{\textbf{D}!Defect}Defect [p.\pageref{sec:Defect}]. You cannot always be sure, what is the root cause of a flaw. An \emph{Error} (a human mistake) in programming code can lead to a \emph{Defect}. Sometimes a Bug can be nothing than a \emph{Failure}\footnote{~Deviation of the component or system from its expected delivery, service or result.}, or a \emph{Mistake}, or an \emph{Error}\ldots 9 | 10 | It will be more convenient, if we will use a common term for all this artifacts~\textemdash~the \emph{Bug}. 11 | 12 | ANY deviation from the expected result during testing can be treated as a \emph{Bug}. 13 | 14 | But not every deviation is a bug. 15 | 16 | \begin{quote} 17 | Women wear dresses and earrings (this is an expectation). 18 | 19 | When you will see a women wearing trousers (a deviation from expectation), will you ask for severe explanations? 20 | 21 | Clearly not. Go home and revise your requirements and assumptions. 22 | \end{quote} 23 | 24 | \subsection{Why it is called 'A Bug'} 25 | 26 | A typical version of the story of the 'bug' term is: 27 | 28 | \begin{quote} 29 | In September 9, 1945, \rindex{\textbf{G}!Grace Hopper}Grace Hopper\footnote{~Grace Hopper (Dec 9, 1906 – Jan 1, 1992), a United States Navy Rear Admiral, one of the first programmers of the \englishq{Mark I} computer in 1944; she invented the first compiler for a computer programming language and was one of those who popularized the idea of machine-independent programming languages. Hooray for Grace!} work on the 'Mark II' computer at the Harvard Faculty. 30 | 31 | Operators traced an error in the 'Mark II' to a moth trapped in a relay. 32 | 33 | Dead bug was carefully removed and taped to the log book. 34 | 35 | Stemming from the first bug, today we call errors or glitches in a program a bug. 36 | 37 | Amen. 38 | \end{quote} 39 | 40 | \begin{figure}[!h] 41 | \centering 42 | \includegraphics[width=0.8\linewidth]{debugging} 43 | \caption{\ttfamily{'First actual case of bug being found'. September 9, 1947}} 44 | \label{fig:Debugging} 45 | \end{figure} 46 | 47 | Well\ldots 48 | 49 | You can call me a naïve idiot, but what if into the 'Mark II' has been climbed and deadly shocked not a moth, but a cat? 50 | 51 | \begin{quote} 52 | Or a programmer? 53 | \end{quote} 54 | 55 | In fact, the term "bug" to describe defects already has been a part of engineering jargon for many decades and predates computers and computer software. It may have originally been used in hardware engineering to describe mechanical malfunctions. 56 | 57 | For instance, \rindex{\textbf{T}!Thomas Edison}Thomas Edison wrote the following words in a letter to an associate in 1878\footnote{~Edison to Puskas, 13 November 1878, Edison papers, Edison National Laboratory, U.S. National Park Service, West Orange, N.J., cited in Hughes, Thomas Parke (1989). American Genesis: A Century of Invention and Technological Enthusiasm, 1870-1970. Penguin Books. p. 75. ISBN 978-0-14-009741-2.}: 58 | 59 | \begin{quote} 60 | It has been just so in all of my inventions. The first step is an intuition, and comes with a burst, then difficulties arise~\textemdash~this thing gives out and [it is] then that "Bugs"~\textemdash~as such little faults and difficulties are called~\textemdash~show themselves and months of intense watching, study and labor are requisite before commercial success or failure is certainly reached. 61 | \end{quote} 62 | 63 | In '40 every computer guy was a radio mechanic or somehow similar to it (you cannot operate an old fashioned computer without being able to repair it several times by a day by your own hands and an soldering iron). So, computer operators were already familiar with the engineering term 'bug'. They amusedly kept the insect in the computer log, because it is really fun to discover a personalization of 'a bug'. That's why they noted it as the "\textit{First actual case of bug being found}" :) 64 | 65 | \begin{quote} 66 | Today this log book, complete with attached moth, is part of the collection of the Smithsonian National Museum of American History. 67 | 68 | Why a log: on those days every interaction with the computer had to be noted on a paper. \end{quote} 69 | 70 | And Grace Hopper did not find the bug, as she readily acknowledged that. The notation "\textit{First actual case of bug being found}" was made by a group of computer operators, including William "Bill" Burke~\textemdash~maybe he wrote the famous sentence. 71 | 72 | And the date in the log book was September 9, 1947, not 1945. The related term "debug" also appears to predate its usage in computing: the Oxford English Dictionary's etymology of the word contains an attestation from 1945, in the context of aircraft engines. 73 | -------------------------------------------------------------------------------- /project_styles/project_styles_screen_version.sty: -------------------------------------------------------------------------------- 1 | % SCREEN version 2 | 3 | % ========== ОСНОВНЫЕ НАСТРОЙКИ ДОКУМЕНТА ========== 4 | 5 | % От этого зависят правильные переносы в словах. 6 | \usepackage[english]{babel} 7 | 8 | % кодировка по-умолчанию. 9 | % ВНИМАНИЕ, параметр {inputenc} должен использоваться в документе только один раз 10 | \RequirePackage[utf8]{inputenc} 11 | \usepackage{lmodern} 12 | \usepackage[T1]{fontenc} 13 | 14 | % Выбор шрифта IBM Plex 15 | \usepackage{plex-serif} 16 | \usepackage[sfdefault]{plex-sans} 17 | 18 | % ========== НАСТРОЙКИ ЗАГОЛОВКОВ ========== 19 | 20 | % Выводим каждый \section с новой страницы 21 | \usepackage{titlesec} 22 | \newcommand{\sectionbreak}{\clearpage} 23 | 24 | % ========== НАСТРОЙКИ АБЗАЦЕВ ========== 25 | 26 | % To get a straight right margin in the output, LaTeX inserts varying amounts of space between the words. By default, it also inserts slightly more space at the end of a sentence. However, the extra space added at the end of sentences is generally considered typographically old-fashioned in English language printing. The additional space after periods can be disabled with the command 27 | \frenchspacing 28 | 29 | % убираем отступ для красной строки в абзаце 30 | \parindent=0em 31 | 32 | % принудительно увеличенный интервал между абзацами. 33 | \parskip=0.4em 34 | 35 | % принудительно увеличенный интервал между строчками, чтобы повысить читаемость, бо сливались 36 | \renewcommand{\baselinestretch}{1.2} 37 | 38 | % принудительно увеличенный интервал между абзацами 39 | \setlength{\parskip}{1em} 40 | 41 | % Перечеркивание текста — \sout{Hello world} 42 | % Обязательна опция [normalem], иначе ulem превратит ВСЕ \emph{} в простой подчеркнутый текст 43 | \usepackage[normalem]{ulem} 44 | 45 | % ========== СОБСТВЕННЫЕ СТИЛИ ========== 46 | 47 | \usepackage{textcomp} 48 | 49 | % Решение заебучего отсутствия пробела после закрывающей французской кавычки: текст, который надо взять в кавычки, берем в \russianq{} 50 | \newcommand{\russianq}[1]{\guillemotleft{#1}\guillemotright} 51 | 52 | % Обрамление текста ординарными, идеально ровными кавычками (зависят от \usepackage{textcomp}) 53 | \newcommand{\ordinaryq}[1]{\textquotesingle {#1}\textquotesingle} 54 | 55 | % Обрамление текста английскими кавычками (зависят от \usepackage{textcomp}) 56 | \newcommand{\englishq}[1]{``{#1}''} 57 | 58 | % Обрамление текста квадратными скобками 59 | \newcommand{\squaredBrackets}[1]{\lbrack{#1}\rbrack} 60 | 61 | % ========== НАСТРОЙКИ ОСНОВНЫХ СВОЙСТВ ДОКУМЕНТА ========== 62 | 63 | \title{\Huge{Software Testing Glossary}} 64 | 65 | \author{{\textbf{Alex\'ei Lup\'an}}} 66 | 67 | % Управление расстоянием между строками в tableofcontents 68 | \usepackage{tocloft} 69 | \setlength\cftparskip{-1pt} 70 | \setlength\cftbeforesecskip{1pt} 71 | % change the vertical spacing between the title "Table of Contents" and the first entry 72 | \setlength\cftaftertoctitleskip{15pt} 73 | 74 | % ========== НАСТРОЙКИ ИНДЕКСА ТЕРМИНОВ ========== 75 | 76 | \usepackage{imakeidx} % Normal LaTeX indexing 77 | 78 | % Уменьшил размер всех вхождений в индекс (шрифт чуть меньше общего) 79 | \indexsetup{othercode=\small} 80 | 81 | % включил возможность создания индекса терминов. 82 | \makeindex[ 83 | % program=makeindex, 84 | title=Index, 85 | program=xindy, 86 | columns=1, % можно =2 для двух колонок, но могут возникнуть сложности с переносами. 87 | columnseprule=true, 88 | noautomatic=false, 89 | intoc=true, % "Предметный указатель" отражается в общем содержимом документа. 90 | options=-C utf8 -s project_styles/index_style.ist] 91 | % options={-s index_style.ist -C utf8 -M multilingual.xdy}] 92 | 93 | % https://tex.stackexchange.com/questions/8351/what-do-makeatletter-and-makeatother-do 94 | \makeatletter 95 | % Все индексовые вхождения писать только так: \rindex{\textbf{W}!Web} 96 | % Тогда они будут аккуратно обрабатываться и сортироваться сперва по английскому, а затем по русскому алфавиту. 97 | \newcommand{\rindex}[2][\imki@jobname]{\index[#1]{\detokenize{#2}}} 98 | 99 | % Выравниванием термины в колонках по левому краю 100 | \def\@idxitem{\par\hangindent 0pt} 101 | \makeatother 102 | 103 | % ========== НАСТРОЙКИ КАРТИНОК ========== 104 | 105 | % Возможность конвертировать eps картинки в pdf 106 | \usepackage{graphicx} 107 | 108 | % a Perl script that con­verts an EPS file to an ‘en­cap­su­lated’ PDF file (a sin­gle page file whose me­dia box is the same as the orig­i­nal EPS’s bound­ing box). The re­sult­ing file suit­able for in­clu­sion by pdfTeX as an im­age. 109 | \usepackage{epstopdf} 110 | 111 | % Возможность выравнивать картинки (обтекание текстом) 112 | \usepackage{wrapfig} 113 | 114 | % Возможность устанавливать рамки вокруг includegraphics. 115 | \usepackage[most]{tcolorbox} 116 | 117 | % ========== НАСТРОЙКИ РАЗМЕРА СТРАНИЦ ========== 118 | 119 | % Нативные, с широкими полями. 120 | 121 | % ========== НАСТРОЙКИ ОСТАЛЬНЫХ СВОЙСТВ ДОКУМЕНТА ========== 122 | 123 | % ужимаем готовый pdf 124 | \pdfcompresslevel=5 125 | 126 | % чтобы работал поиск по PDF 127 | \usepackage{cmap} 128 | 129 | % you have to put \usepackage[pdftex]{hyperref} 130 | % as the last command into the preamble of your document. 131 | % Параметр colorlinks=true убирает рамки вокруг ссылок, превращая ссылки в окрашенный текст. Догадаться о том, что его надо перевести в режим true, блять, невозможно. 132 | \usepackage[pdftex,colorlinks=true]{hyperref} 133 | 134 | \usepackage{todo} 135 | -------------------------------------------------------------------------------- /glossary/AvailabilityTesting.tex: -------------------------------------------------------------------------------- 1 | \section{Availability Testing} 2 | \label{sec:Availability Testing} 3 | 4 | \rindex{\textbf{A}!Availability Testing}\emph{Availability} is the probability that a system will work \textbf{as} required \textbf{when} required during the period of a mission. 5 | 6 | You won't have to check it often in functional testing. Let's define it just for the sake of understanding. 7 | 8 | \textbf{Main idea}: to reduce and eliminate the expected downtime, you should have a clear knowledge of how much time the app (or the machine) will be operational till the death, if nobody intervenes. 9 | 10 | This is very important to know when we talk about web-servers (or aircrafts, or hard drives and so on). 11 | 12 | Testing for availability means 13 | \begin{itemize} 14 | \item 15 | running an application for a planned period of time, 16 | \item 17 | collecting 18 | \begin{itemize} 19 | \item 20 | failure events 21 | \item 22 | and repair times, 23 | \end{itemize} 24 | \item 25 | and comparing the availability percentage to the original service level agreement. \end{itemize} 26 | 27 | Availability testing is primarily concerned with measuring and minimizing the actual repair time. This is a simple mathematics. 28 | 29 | But before of all you should know several things: 30 | 31 | I. Mean~Time~To~Failure ($MTTF$) 32 | 33 | \begin{quote} 34 | Is the time, on average, that you would expect a clock-work to fail when it has been running. It is a simple indicator of clock-work \rindex{\textbf{R}!Reliability}reliability. 35 | 36 | Example: a clock-work runs for 500 hours. It breaks down 5 times during that period. 37 | 38 | Mean~Time~To~Failure ($MTTF$) $=$ 500 $/$ 5 $=$ \textbf{100 hours} 39 | \end{quote} 40 | 41 | II. Mean~Time~Between~Failure ($MTBF$) 42 | 43 | \begin{quote} 44 | Is the time, on average, that you would expect a clock-work to fail including time lost for repairs are undertaken. It is an indicator of the combined reliability and \rindex{\textbf{M}!Maintenance efficiency}maintenance effectiveness/efficiency. 45 | 46 | Example: a clock-work runs for 500 hours, and it has 200 hours downtime due to 5 failures. 47 | 48 | Mean~Time~Between~Failure ($MTBF$) $=$ (500 $+$ 200) $/$ 5 $=$ \textbf{140 hours} 49 | \end{quote} 50 | 51 | III. Mean~Time~To~Repair ($MTTR$) 52 | 53 | \begin{quote} 54 | Is the time, on average, that you would expect a stoppage to last including time spent waiting for maintenance engineer, diagnosis, waiting for parts, actual repair and testing. 55 | 56 | It is an indicator of maintenance effectiveness/efficiency. 57 | 58 | Note that there is another indicator that can be used here, Mean~Corrective~Repair~Time ($MCRT$). 59 | \begin{quote} 60 | Mean~Corrective~Repair~Time is only interested in the actual repair time assuming all tools, spares and required manpower are available (efficiency). 61 | 62 | Mean~Time~To~Repair ($MTTR$) $-$ Mean~Corrective~Repair~Time ($MCRT$) $=$ Waste and therefore gives you an indication of how ineffective your stores and maintenance resource strategy is. \end{quote} 63 | 64 | Notice that as $MTTR$ trends towards zero, the percentage availability trends towards 100\%. 65 | 66 | \end{quote} 67 | 68 | Still here? Ok, here is an example. 69 | 70 | As above, clock-work runs for 500 hours, has 200 hours downtime due to 5 failures. 71 | 72 | Mean~Time~To~Repair ($MTTR$) $=$ 200 $/$ 5 $=$ \textbf{40 hours} 73 | 74 | Therefore: 75 | 76 | Mean~Time~To~Failure ($MTTF$) $+$ Mean~Time~To~Repair ($MTTR$) $=$ Mean~Time~Between~Failure ($MTBF$) 77 | 78 | Now, how to calculate the \emph{Availability}~\textemdash~just use data from following variables: 79 | 80 | \begin{enumerate} 81 | 82 | \item Mean~Time~To~Failure ($MTTF$) 83 | \item Mean~Time~Between~Failure ($MTBF$) 84 | \item and Mean~Time~To~Repair ($MTTR$) 85 | \end{enumerate} 86 | 87 | Or more importantly, the unavailability of the clock-work due to maintenance causing failures. 88 | 89 | Example, huh? 90 | 91 | As above, clock-work runs 500 hours breaks down 5 times and 200 minutes are spent waiting repair $/$ spares $/$ repairing. 92 | 93 | Availability: 94 | \begin{quote} 95 | 96 | $=$ ((500 $+$ 200) $-$ 200) $/$ (500 $+$ 200) 97 | 98 | $=$ (700 $-$ 200) $/$ 700 99 | 100 | $=$ 71\% 101 | \end{quote} 102 | 103 | Or 104 | 105 | \begin{equation}\label{eq:Availability calculation} 106 | \frac{Mean~Time~To~Failure~(MTTF)} 107 | {Mean~Time~Between~Failure~(MTBF)} = Availability 108 | \end{equation} 109 | 110 | or 111 | 112 | 113 | \begin{equation}\label{eq:Same Availability calculation} 114 | \frac{Mean~Time~To~Failure~(MTTF)} 115 | {Mean~Time~To~Failure~(MTTF) + Mean~Time~To~Repair~(MTTR)} = Availability 116 | \end{equation} 117 | 118 | \begin{quote} 119 | 100 $/$ 140 $=$ 71\% 120 | \end{quote} 121 | 122 | Or 123 | 124 | \begin{quote} 125 | 100 $/$ (100 $+$ 40) $=$ 71\% 126 | \end{quote} 127 | 128 | Ok. \textbf{What about \emph{Unavailability}?} 129 | 130 | \begin{quote} 131 | 1 $-$ $Availability$ $=$ 29\% 132 | \end{quote} 133 | 134 | Or 135 | \begin{quote} 136 | 200 $/$ (500 $+$ 200) $=$ 29\% 137 | \end{quote} 138 | 139 | Or 140 | 141 | \begin{quote} 142 | MTTR $/$ MTBF or MTTR $/$ (MTTF $+$ MTTR) 143 | 144 | 40 $/$ 140 or 40 $/$ (100 $+$ 40) $=$ 29\% 145 | \end{quote} 146 | 147 | Still here? 148 | 149 | Here is an another example of the formula for calculating percentage availability: 150 | \begin{equation}\label{eq:Percentage Availability} 151 | \frac{Mean~Time~Between~Failures}{Mean~Time~Between~Failures + Mean~Time~To~Repair} \times 100 152 | \end{equation} 153 | 154 | “\textit{Mean Time}” means, statistically, the average time. 155 | 156 | “\textit{Mean Time Between Failures}” is literally the average time elapsed from one failure to the next. Usually people think of it as the average time that something works until it fails and needs to be repaired (again). 157 | 158 | “\textit{Mean Time To Repair}” is the average time that it takes to repair something after a failure. 159 | -------------------------------------------------------------------------------- /Software Testing Glossary.kilepr: -------------------------------------------------------------------------------- 1 | [General] 2 | bib_extensions=.bib 3 | bibliographyBackendAutoDetected= 4 | bibliographyBackendUserOverride= 5 | def_graphic_ext= 6 | img_extIsRegExp=false 7 | img_extensions=.eps .jpg .jpeg .png .pdf .ps .fig .gif 8 | kileprversion=3 9 | kileversion=2.9.92 10 | masterDocument= 11 | name=Software Testing Glossary 12 | pkg_extIsRegExp=false 13 | pkg_extensions=.cls .sty .bbx .cbx .lbx 14 | src_extIsRegExp=false 15 | src_extensions=.tex .ltx .latex .dtx .ins 16 | 17 | [Tool/MakeIndex/Default] 18 | options='%S.idx' 19 | 20 | [Tools] 21 | MakeIndex=Default 22 | QuickBuild= 23 | 24 | [item:_abstract.tex] 25 | archive=true 26 | encoding=UTF-8 27 | highlight=LaTeX 28 | mode=LaTeX 29 | 30 | [item:_author.tex] 31 | archive=true 32 | encoding=UTF-8 33 | highlight=LaTeX 34 | mode=LaTeX 35 | 36 | [item:glossary/AcceptanceCriteria.tex] 37 | archive=true 38 | encoding=UTF-8 39 | highlight=LaTeX 40 | mode=LaTeX 41 | 42 | [item:glossary/AcceptanceTesting.tex] 43 | archive=true 44 | encoding=UTF-8 45 | highlight=LaTeX 46 | mode=LaTeX 47 | 48 | [item:glossary/ActualResult.tex] 49 | archive=true 50 | encoding=UTF-8 51 | highlight=LaTeX 52 | mode=LaTeX 53 | 54 | [item:glossary/AdhocTesting.tex] 55 | archive=true 56 | column=0 57 | encoding=UTF-8 58 | highlight=LaTeX 59 | line=0 60 | mode=LaTeX 61 | open=false 62 | order=1 63 | 64 | [item:glossary/AgileSoftwareDevelopment.tex] 65 | archive=true 66 | encoding=UTF-8 67 | highlight=LaTeX 68 | mode=LaTeX 69 | 70 | [item:glossary/AgileTesting.tex] 71 | archive=true 72 | encoding=UTF-8 73 | highlight=LaTeX 74 | mode=LaTeX 75 | 76 | [item:glossary/AlphaTesting.tex] 77 | archive=true 78 | encoding=UTF-8 79 | highlight=LaTeX 80 | mode=LaTeX 81 | 82 | [item:glossary/AutomatedScripts.tex] 83 | archive=true 84 | encoding=UTF-8 85 | highlight=LaTeX 86 | mode=LaTeX 87 | 88 | [item:glossary/AutomatedTesting.tex] 89 | archive=true 90 | encoding=UTF-8 91 | highlight=LaTeX 92 | mode=LaTeX 93 | 94 | [item:glossary/AvailabilityTesting.tex] 95 | archive=true 96 | encoding=UTF-8 97 | highlight=LaTeX 98 | mode=LaTeX 99 | 100 | [item:glossary/BestPractice.tex] 101 | archive=true 102 | encoding=UTF-8 103 | highlight=LaTeX 104 | mode=LaTeX 105 | 106 | [item:glossary/BetaTesting.tex] 107 | archive=true 108 | encoding=UTF-8 109 | highlight=LaTeX 110 | mode=LaTeX 111 | 112 | [item:glossary/BoundaryValueTesting.tex] 113 | archive=true 114 | encoding=UTF-8 115 | highlight=LaTeX 116 | mode=LaTeX 117 | 118 | [item:glossary/Bug.tex] 119 | archive=true 120 | encoding=UTF-8 121 | highlight=LaTeX 122 | mode=LaTeX 123 | 124 | [item:glossary/BugReporting.tex] 125 | archive=true 126 | encoding=UTF-8 127 | highlight=LaTeX 128 | mode=LaTeX 129 | 130 | [item:glossary/BugTrackingSystem.tex] 131 | archive=true 132 | encoding=UTF-8 133 | highlight=LaTeX 134 | mode=LaTeX 135 | 136 | [item:glossary/BugVerification.tex] 137 | archive=true 138 | encoding=UTF-8 139 | highlight=LaTeX 140 | mode=LaTeX 141 | 142 | [item:glossary/Build.tex] 143 | archive=true 144 | encoding=UTF-8 145 | highlight=LaTeX 146 | mode=LaTeX 147 | 148 | [item:glossary/ChangeManagement.tex] 149 | archive=true 150 | encoding=UTF-8 151 | highlight=LaTeX 152 | mode=LaTeX 153 | 154 | [item:glossary/ChangeRequest.tex] 155 | archive=true 156 | encoding=UTF-8 157 | highlight=LaTeX 158 | mode=LaTeX 159 | 160 | [item:glossary/ChecklistbasedTesting.tex] 161 | archive=true 162 | encoding=UTF-8 163 | highlight=LaTeX 164 | mode=LaTeX 165 | 166 | [item:glossary/CompatibilityTesting.tex] 167 | archive=true 168 | encoding=UTF-8 169 | highlight=LaTeX 170 | mode=LaTeX 171 | 172 | [item:glossary/Component.tex] 173 | archive=true 174 | encoding=UTF-8 175 | highlight=LaTeX 176 | mode=LaTeX 177 | 178 | [item:glossary/ContinuousIntegration.tex] 179 | archive=true 180 | encoding=UTF-8 181 | highlight=LaTeX 182 | mode=LaTeX 183 | 184 | [item:glossary/CostofQuality.tex] 185 | archive=true 186 | encoding=UTF-8 187 | highlight=LaTeX 188 | mode=LaTeX 189 | 190 | [item:glossary/Coverage.tex] 191 | archive=true 192 | encoding=UTF-8 193 | highlight=LaTeX 194 | mode=LaTeX 195 | 196 | [item:glossary/Criteria.tex] 197 | archive=true 198 | encoding=UTF-8 199 | highlight=LaTeX 200 | mode=LaTeX 201 | 202 | [item:glossary/Debugging.tex] 203 | archive=true 204 | encoding=UTF-8 205 | highlight=LaTeX 206 | mode=LaTeX 207 | 208 | [item:glossary/DecisionTableTesting.tex] 209 | archive=true 210 | encoding=UTF-8 211 | highlight=LaTeX 212 | mode=LaTeX 213 | 214 | [item:glossary/Defect.tex] 215 | archive=true 216 | encoding=UTF-8 217 | highlight=LaTeX 218 | mode=LaTeX 219 | 220 | [item:glossary/DefectbasedTestDesignTechnique.tex] 221 | archive=true 222 | encoding=UTF-8 223 | highlight=LaTeX 224 | mode=LaTeX 225 | 226 | [item:glossary/DevelopmentEnvironment.tex] 227 | archive=true 228 | encoding=UTF-8 229 | highlight=LaTeX 230 | mode=LaTeX 231 | 232 | [item:glossary/DevelopmentofTestCases.tex] 233 | archive=true 234 | encoding=UTF-8 235 | highlight=LaTeX 236 | mode=LaTeX 237 | 238 | [item:glossary/DocumentationTesting.tex] 239 | archive=true 240 | encoding=UTF-8 241 | highlight=LaTeX 242 | mode=LaTeX 243 | 244 | [item:glossary/DomainAnalysisTesting.tex] 245 | archive=true 246 | encoding=UTF-8 247 | highlight=LaTeX 248 | mode=LaTeX 249 | 250 | [item:glossary/EndtoendTesting.tex] 251 | archive=true 252 | encoding=UTF-8 253 | highlight=LaTeX 254 | mode=LaTeX 255 | 256 | [item:glossary/EntryexitCriteriaforTesting.tex] 257 | archive=true 258 | encoding=UTF-8 259 | highlight=LaTeX 260 | mode=LaTeX 261 | 262 | [item:glossary/EquivalenceClassTesting.tex] 263 | archive=true 264 | encoding=UTF-8 265 | highlight=LaTeX 266 | mode=LaTeX 267 | 268 | [item:glossary/ExhaustiveTesting.tex] 269 | archive=true 270 | encoding=UTF-8 271 | highlight=LaTeX 272 | mode=LaTeX 273 | 274 | [item:glossary/ExploratoryTesting.tex] 275 | archive=true 276 | encoding=UTF-8 277 | highlight=LaTeX 278 | mode=LaTeX 279 | 280 | [item:glossary/Feature.tex] 281 | archive=true 282 | encoding=UTF-8 283 | highlight=LaTeX 284 | mode=LaTeX 285 | 286 | [item:glossary/Function.tex] 287 | archive=true 288 | encoding=UTF-8 289 | highlight=LaTeX 290 | mode=LaTeX 291 | 292 | [item:glossary/FunctionalRequirement.tex] 293 | archive=true 294 | encoding=UTF-8 295 | highlight=LaTeX 296 | mode=LaTeX 297 | 298 | [item:glossary/FunctionalSpecifications.tex] 299 | archive=true 300 | encoding=UTF-8 301 | highlight=LaTeX 302 | mode=LaTeX 303 | 304 | [item:glossary/FunctionalTesting.tex] 305 | archive=true 306 | encoding=UTF-8 307 | highlight=LaTeX 308 | mode=LaTeX 309 | 310 | [item:glossary/ImpactAnalysis.tex] 311 | archive=true 312 | encoding=UTF-8 313 | highlight=LaTeX 314 | mode=LaTeX 315 | 316 | [item:glossary/InScopeOutofScope.tex] 317 | archive=true 318 | encoding=UTF-8 319 | highlight=LaTeX 320 | mode=LaTeX 321 | 322 | [item:glossary/IntegrationTesting.tex] 323 | archive=true 324 | encoding=UTF-8 325 | highlight=LaTeX 326 | mode=LaTeX 327 | 328 | [item:glossary/ItemPassFailCriteria.tex] 329 | archive=true 330 | encoding=UTF-8 331 | highlight=LaTeX 332 | mode=LaTeX 333 | 334 | [item:glossary/IterativeDevelopmentModel.tex] 335 | archive=true 336 | encoding=UTF-8 337 | highlight=LaTeX 338 | mode=LaTeX 339 | 340 | [item:glossary/MaintenanceofTestCases.tex] 341 | archive=true 342 | encoding=UTF-8 343 | highlight=LaTeX 344 | mode=LaTeX 345 | 346 | [item:glossary/Metaphor.tex] 347 | archive=true 348 | encoding=UTF-8 349 | highlight=LaTeX 350 | mode=LaTeX 351 | 352 | [item:glossary/MigrationTesting.tex] 353 | archive=true 354 | encoding=UTF-8 355 | highlight=LaTeX 356 | mode=LaTeX 357 | 358 | [item:glossary/MonkeyTesting.tex] 359 | archive=true 360 | encoding=UTF-8 361 | highlight=LaTeX 362 | mode=LaTeX 363 | 364 | [item:glossary/NegativeTesting.tex] 365 | archive=true 366 | encoding=UTF-8 367 | highlight=LaTeX 368 | mode=LaTeX 369 | 370 | [item:glossary/NonfunctionalRequirement.tex] 371 | archive=true 372 | encoding=UTF-8 373 | highlight=LaTeX 374 | mode=LaTeX 375 | 376 | [item:glossary/PairTesting.tex] 377 | archive=true 378 | encoding=UTF-8 379 | highlight=LaTeX 380 | mode=LaTeX 381 | 382 | [item:glossary/Pairwise.tex] 383 | archive=true 384 | encoding=UTF-8 385 | highlight=LaTeX 386 | mode=LaTeX 387 | 388 | [item:glossary/PerformanceTesting.tex] 389 | archive=true 390 | encoding=UTF-8 391 | highlight=LaTeX 392 | mode=LaTeX 393 | 394 | [item:glossary/PositiveTesting.tex] 395 | archive=true 396 | encoding=UTF-8 397 | highlight=LaTeX 398 | mode=LaTeX 399 | 400 | [item:glossary/Precondition.tex] 401 | archive=true 402 | encoding=UTF-8 403 | highlight=LaTeX 404 | mode=LaTeX 405 | 406 | [item:glossary/Quality.tex] 407 | archive=true 408 | encoding=UTF-8 409 | highlight=LaTeX 410 | mode=LaTeX 411 | 412 | [item:glossary/RegressionTesting.tex] 413 | archive=true 414 | encoding=UTF-8 415 | highlight=LaTeX 416 | mode=LaTeX 417 | 418 | [item:glossary/Requirement.tex] 419 | archive=true 420 | encoding=UTF-8 421 | highlight=LaTeX 422 | mode=LaTeX 423 | 424 | [item:glossary/RootCause.tex] 425 | archive=true 426 | encoding=UTF-8 427 | highlight=LaTeX 428 | mode=LaTeX 429 | 430 | [item:glossary/SCRUM.tex] 431 | archive=true 432 | encoding=UTF-8 433 | highlight=LaTeX 434 | mode=LaTeX 435 | 436 | [item:glossary/SecurityTesting.tex] 437 | archive=true 438 | encoding=UTF-8 439 | highlight=LaTeX 440 | mode=LaTeX 441 | 442 | [item:glossary/Server.tex] 443 | archive=true 444 | encoding=UTF-8 445 | highlight=LaTeX 446 | mode=LaTeX 447 | 448 | [item:glossary/SmokeTesting.tex] 449 | archive=true 450 | encoding=UTF-8 451 | highlight=LaTeX 452 | mode=LaTeX 453 | 454 | [item:glossary/Sprint.tex] 455 | archive=true 456 | encoding=UTF-8 457 | highlight=LaTeX 458 | mode=LaTeX 459 | 460 | [item:glossary/Staging.tex] 461 | archive=true 462 | encoding=UTF-8 463 | highlight=LaTeX 464 | mode=LaTeX 465 | 466 | [item:glossary/Strategy.tex] 467 | archive=true 468 | encoding=UTF-8 469 | highlight=LaTeX 470 | mode=LaTeX 471 | 472 | [item:glossary/SuspensionCriteria.tex] 473 | archive=true 474 | encoding=UTF-8 475 | highlight=LaTeX 476 | mode=LaTeX 477 | 478 | [item:glossary/System.tex] 479 | archive=true 480 | encoding=UTF-8 481 | highlight=LaTeX 482 | mode=LaTeX 483 | 484 | [item:glossary/Test.tex] 485 | archive=true 486 | encoding=UTF-8 487 | highlight=LaTeX 488 | mode=LaTeX 489 | 490 | [item:glossary/TestCase.tex] 491 | archive=true 492 | encoding=UTF-8 493 | highlight=LaTeX 494 | mode=LaTeX 495 | 496 | [item:glossary/TestDesign.tex] 497 | archive=true 498 | encoding=UTF-8 499 | highlight=LaTeX 500 | mode=LaTeX 501 | 502 | [item:glossary/TestIdea.tex] 503 | archive=true 504 | encoding=UTF-8 505 | highlight=LaTeX 506 | mode=LaTeX 507 | 508 | [item:glossary/TestScenario.tex] 509 | archive=true 510 | encoding=UTF-8 511 | highlight=LaTeX 512 | mode=LaTeX 513 | 514 | [item:glossary/TestSuite.tex] 515 | archive=true 516 | encoding=UTF-8 517 | highlight=LaTeX 518 | mode=LaTeX 519 | 520 | [item:glossary/Testability.tex] 521 | archive=true 522 | encoding=UTF-8 523 | highlight=LaTeX 524 | mode=LaTeX 525 | 526 | [item:glossary/Traceability.tex] 527 | archive=true 528 | encoding=UTF-8 529 | highlight=LaTeX 530 | mode=LaTeX 531 | 532 | [item:glossary/UseCase.tex] 533 | archive=true 534 | encoding=UTF-8 535 | highlight=LaTeX 536 | mode=LaTeX 537 | 538 | [item:glossary/UserStory.tex] 539 | archive=true 540 | encoding=UTF-8 541 | highlight=LaTeX 542 | mode=LaTeX 543 | 544 | [item:glossary/VerificationAndValidation.tex] 545 | archive=true 546 | encoding=UTF-8 547 | highlight=LaTeX 548 | mode=LaTeX 549 | 550 | [item:glossary/Version.tex] 551 | archive=true 552 | encoding=UTF-8 553 | highlight=LaTeX 554 | mode=LaTeX 555 | 556 | [item:glossary/WhiteBoxBlackBox.tex] 557 | archive=true 558 | encoding=UTF-8 559 | highlight=LaTeX 560 | mode=LaTeX 561 | 562 | [item:main.tex] 563 | archive=true 564 | encoding=UTF-8 565 | highlight=LaTeX 566 | mode=LaTeX 567 | 568 | [item:project_styles/project_styles_screen_version.sty] 569 | archive=true 570 | encoding=UTF-8 571 | highlight=LaTeX 572 | mode=LaTeX 573 | 574 | [view-settings,view=0,item:ProjectStyle.sty] 575 | CursorColumn=0 576 | CursorLine=17 577 | JumpList= 578 | ViMarks=.,17,0,[,17,0,],17,0 579 | 580 | [view-settings,view=0,item:_abstract.tex] 581 | CursorColumn=54 582 | CursorLine=12 583 | JumpList= 584 | ViMarks=.,2,0,[,2,0,],2,0 585 | 586 | [view-settings,view=0,item:glossary/AcceptanceCriteria.tex] 587 | CursorColumn=0 588 | CursorLine=0 589 | JumpList= 590 | ViMarks= 591 | 592 | [view-settings,view=0,item:glossary/AcceptanceTesting.tex] 593 | CursorColumn=199 594 | CursorLine=36 595 | JumpList= 596 | ViMarks=.,36,190,[,36,189,],36,190 597 | 598 | [view-settings,view=0,item:glossary/ActualResult.tex] 599 | CursorColumn=0 600 | CursorLine=0 601 | JumpList= 602 | ViMarks= 603 | 604 | [view-settings,view=0,item:glossary/AdhocTesting.tex] 605 | CursorColumn=46 606 | CursorLine=5 607 | JumpList= 608 | ViMarks=.,5,46,[,5,46,],5,46 609 | 610 | [view-settings,view=0,item:glossary/AgileSoftwareDevelopment.tex] 611 | CursorColumn=26 612 | CursorLine=5 613 | JumpList= 614 | ViMarks=.,5,25,[,5,25,],5,25 615 | 616 | [view-settings,view=0,item:glossary/AgileTesting.tex] 617 | CursorColumn=228 618 | CursorLine=36 619 | JumpList= 620 | ViMarks=.,32,283,[,32,283,],32,299 621 | 622 | [view-settings,view=0,item:glossary/AlphaTesting.tex] 623 | CursorColumn=83 624 | CursorLine=27 625 | JumpList= 626 | ViMarks=.,27,82,[,27,75,],27,82 627 | 628 | [view-settings,view=0,item:glossary/AutomatedScripts.tex] 629 | CursorColumn=83 630 | CursorLine=8 631 | JumpList= 632 | ViMarks=.,7,0,[,7,0,],7,0 633 | 634 | [view-settings,view=0,item:glossary/AutomatedTesting.tex] 635 | CursorColumn=279 636 | CursorLine=43 637 | JumpList= 638 | ViMarks=.,43,279,[,43,279,],43,279 639 | 640 | [view-settings,view=0,item:glossary/AvailabilityTesting.tex] 641 | CursorColumn=58 642 | CursorLine=47 643 | JumpList= 644 | ViMarks=.,47,57,[,47,57,],47,57 645 | 646 | [view-settings,view=0,item:glossary/BestPractice.tex] 647 | CursorColumn=0 648 | CursorLine=0 649 | JumpList= 650 | ViMarks=.,9,63,[,9,61,],9,63 651 | 652 | [view-settings,view=0,item:glossary/BetaTesting.tex] 653 | CursorColumn=162 654 | CursorLine=13 655 | JumpList= 656 | ViMarks=.,9,86,[,9,77,],9,86 657 | 658 | [view-settings,view=0,item:glossary/BoundaryValueTesting.tex] 659 | CursorColumn=0 660 | CursorLine=0 661 | JumpList= 662 | ViMarks= 663 | 664 | [view-settings,view=0,item:glossary/Bug.tex] 665 | CursorColumn=0 666 | CursorLine=39 667 | JumpList= 668 | ViMarks=.,56,33,[,56,21,],56,33 669 | 670 | [view-settings,view=0,item:glossary/BugReporting.tex] 671 | CursorColumn=0 672 | CursorLine=0 673 | JumpList= 674 | ViMarks= 675 | 676 | [view-settings,view=0,item:glossary/BugTrackingSystem.tex] 677 | CursorColumn=16 678 | CursorLine=12 679 | JumpList= 680 | ViMarks=.,8,19,[,8,16,],8,19 681 | 682 | [view-settings,view=0,item:glossary/BugVerification.tex] 683 | CursorColumn=6 684 | CursorLine=3 685 | JumpList= 686 | ViMarks=.,3,5,[,3,1,],3,5 687 | 688 | [view-settings,view=0,item:glossary/Build.tex] 689 | CursorColumn=74 690 | CursorLine=8 691 | JumpList= 692 | ViMarks=.,8,74,[,8,74,],8,74 693 | 694 | [view-settings,view=0,item:glossary/ChangeManagement.tex] 695 | CursorColumn=250 696 | CursorLine=20 697 | JumpList= 698 | ViMarks=.,9,0,[,9,0,],9,0 699 | 700 | [view-settings,view=0,item:glossary/ChangeRequest.tex] 701 | CursorColumn=6 702 | CursorLine=5 703 | JumpList= 704 | ViMarks=.,3,5,[,3,1,],3,5 705 | 706 | [view-settings,view=0,item:glossary/ChecklistbasedTesting.tex] 707 | CursorColumn=6 708 | CursorLine=13 709 | JumpList= 710 | ViMarks=.,3,5,[,3,1,],3,5 711 | 712 | [view-settings,view=0,item:glossary/CompatibilityTesting.tex] 713 | CursorColumn=0 714 | CursorLine=16 715 | JumpList= 716 | ViMarks=.,7,40,[,7,26,],7,40 717 | 718 | [view-settings,view=0,item:glossary/Component.tex] 719 | CursorColumn=276 720 | CursorLine=20 721 | JumpList= 722 | ViMarks=.,14,41,[,14,39,],14,41 723 | 724 | [view-settings,view=0,item:glossary/ContinuousIntegration.tex] 725 | CursorColumn=6 726 | CursorLine=7 727 | JumpList= 728 | ViMarks=.,3,5,[,3,1,],3,5 729 | 730 | [view-settings,view=0,item:glossary/CostofQuality.tex] 731 | CursorColumn=96 732 | CursorLine=13 733 | JumpList= 734 | ViMarks=.,5,58,[,5,58,],5,58 735 | 736 | [view-settings,view=0,item:glossary/Coverage.tex] 737 | CursorColumn=6 738 | CursorLine=3 739 | JumpList= 740 | ViMarks=.,3,5,[,3,1,],3,5 741 | 742 | [view-settings,view=0,item:glossary/Criteria.tex] 743 | CursorColumn=0 744 | CursorLine=0 745 | JumpList= 746 | ViMarks= 747 | 748 | [view-settings,view=0,item:glossary/Debugging.tex] 749 | CursorColumn=6 750 | CursorLine=5 751 | JumpList= 752 | ViMarks=.,3,5,[,3,1,],3,5 753 | 754 | [view-settings,view=0,item:glossary/DecisionTableTesting.tex] 755 | CursorColumn=31 756 | CursorLine=3 757 | JumpList= 758 | ViMarks=.,3,30,[,3,30,],3,30 759 | 760 | [view-settings,view=0,item:glossary/Defect.tex] 761 | CursorColumn=286 762 | CursorLine=67 763 | JumpList= 764 | ViMarks=.,67,286,[,67,286,],67,286 765 | 766 | [view-settings,view=0,item:glossary/DefectbasedTestDesignTechnique.tex] 767 | CursorColumn=6 768 | CursorLine=3 769 | JumpList= 770 | ViMarks=.,3,5,[,3,1,],3,5 771 | 772 | [view-settings,view=0,item:glossary/DevelopmentEnvironment.tex] 773 | CursorColumn=0 774 | CursorLine=11 775 | JumpList= 776 | ViMarks=.,10,249,[,11,0,],-1,-1 777 | 778 | [view-settings,view=0,item:glossary/DevelopmentofTestCases.tex] 779 | CursorColumn=22 780 | CursorLine=9 781 | JumpList= 782 | ViMarks=.,5,135,[,5,119,],5,135 783 | 784 | [view-settings,view=0,item:glossary/DocumentationTesting.tex] 785 | CursorColumn=26 786 | CursorLine=13 787 | JumpList= 788 | ViMarks=.,13,25,[,13,25,],13,25 789 | 790 | [view-settings,view=0,item:glossary/DomainAnalysisTesting.tex] 791 | CursorColumn=0 792 | CursorLine=11 793 | JumpList= 794 | ViMarks=.,11,12,[,11,4,],11,12 795 | 796 | [view-settings,view=0,item:glossary/EndtoendTesting.tex] 797 | CursorColumn=83 798 | CursorLine=11 799 | JumpList= 800 | ViMarks=.,3,5,[,3,1,],3,5 801 | 802 | [view-settings,view=0,item:glossary/EntryexitCriteriaforTesting.tex] 803 | CursorColumn=36 804 | CursorLine=13 805 | JumpList= 806 | ViMarks=.,13,35,[,13,35,],13,35 807 | 808 | [view-settings,view=0,item:glossary/EquivalenceClassTesting.tex] 809 | CursorColumn=94 810 | CursorLine=82 811 | JumpList= 812 | ViMarks=.,82,81,[,82,81,],82,93 813 | 814 | [view-settings,view=0,item:glossary/ExhaustiveTesting.tex] 815 | CursorColumn=0 816 | CursorLine=7 817 | JumpList= 818 | ViMarks=.,3,71,[,3,71,],3,71 819 | 820 | [view-settings,view=0,item:glossary/ExploratoryTesting.tex] 821 | CursorColumn=175 822 | CursorLine=5 823 | JumpList= 824 | ViMarks=.,3,5,[,3,1,],3,5 825 | 826 | [view-settings,view=0,item:glossary/Feature.tex] 827 | CursorColumn=15 828 | CursorLine=3 829 | JumpList= 830 | ViMarks=.,3,15,[,3,15,],3,15 831 | 832 | [view-settings,view=0,item:glossary/Function.tex] 833 | CursorColumn=0 834 | CursorLine=2 835 | JumpList= 836 | ViMarks=.,2,0,[,2,0,],2,0 837 | 838 | [view-settings,view=0,item:glossary/FunctionalRequirement.tex] 839 | CursorColumn=0 840 | CursorLine=24 841 | JumpList= 842 | ViMarks=.,3,5,[,3,1,],3,5 843 | 844 | [view-settings,view=0,item:glossary/FunctionalSpecifications.tex] 845 | CursorColumn=33 846 | CursorLine=11 847 | JumpList= 848 | ViMarks=.,11,33,[,11,33,],11,33 849 | 850 | [view-settings,view=0,item:glossary/FunctionalTesting.tex] 851 | CursorColumn=102 852 | CursorLine=7 853 | JumpList= 854 | ViMarks=.,7,101,[,7,86,],7,101 855 | 856 | [view-settings,view=0,item:glossary/ImpactAnalysis.tex] 857 | CursorColumn=23 858 | CursorLine=13 859 | JumpList= 860 | ViMarks=.,5,22,[,5,16,],5,22 861 | 862 | [view-settings,view=0,item:glossary/InScopeOutofScope.tex] 863 | CursorColumn=72 864 | CursorLine=8 865 | JumpList= 866 | ViMarks=.,8,71,[,8,71,],8,71 867 | 868 | [view-settings,view=0,item:glossary/IntegrationTesting.tex] 869 | CursorColumn=4 870 | CursorLine=7 871 | JumpList= 872 | ViMarks=.,7,3,[,7,3,],7,3 873 | 874 | [view-settings,view=0,item:glossary/ItemPassFailCriteria.tex] 875 | CursorColumn=0 876 | CursorLine=0 877 | JumpList= 878 | ViMarks= 879 | 880 | [view-settings,view=0,item:glossary/IterativeDevelopmentModel.tex] 881 | CursorColumn=0 882 | CursorLine=2 883 | JumpList= 884 | ViMarks=.,3,0,[,3,0,],3,120 885 | 886 | [view-settings,view=0,item:glossary/MaintenanceofTestCases.tex] 887 | CursorColumn=146 888 | CursorLine=5 889 | JumpList= 890 | ViMarks=.,5,146,[,5,146,],5,146 891 | 892 | [view-settings,view=0,item:glossary/Metaphor.tex] 893 | CursorColumn=19 894 | CursorLine=1 895 | JumpList= 896 | ViMarks=.,3,14,[,3,14,],3,14 897 | 898 | [view-settings,view=0,item:glossary/MigrationTesting.tex] 899 | CursorColumn=14 900 | CursorLine=24 901 | JumpList= 902 | ViMarks=.,3,5,[,3,1,],3,5 903 | 904 | [view-settings,view=0,item:glossary/MonkeyTesting.tex] 905 | CursorColumn=275 906 | CursorLine=14 907 | JumpList= 908 | ViMarks=.,14,274,[,14,261,],14,274 909 | 910 | [view-settings,view=0,item:glossary/NegativeTesting.tex] 911 | CursorColumn=318 912 | CursorLine=7 913 | JumpList= 914 | ViMarks=.,7,318,[,7,318,],7,318 915 | 916 | [view-settings,view=0,item:glossary/NonfunctionalRequirement.tex] 917 | CursorColumn=146 918 | CursorLine=45 919 | JumpList= 920 | ViMarks=.,45,0,[,45,0,],45,0 921 | 922 | [view-settings,view=0,item:glossary/PairTesting.tex] 923 | CursorColumn=0 924 | CursorLine=25 925 | JumpList= 926 | ViMarks=.,24,0,[,24,0,],-1,-1 927 | 928 | [view-settings,view=0,item:glossary/Pairwise.tex] 929 | CursorColumn=6 930 | CursorLine=3 931 | JumpList= 932 | ViMarks=.,3,5,[,3,1,],3,5 933 | 934 | [view-settings,view=0,item:glossary/PerformanceTesting.tex] 935 | CursorColumn=251 936 | CursorLine=60 937 | JumpList= 938 | ViMarks=.,54,5,[,54,1,],54,5 939 | 940 | [view-settings,view=0,item:glossary/PositiveTesting.tex] 941 | CursorColumn=47 942 | CursorLine=3 943 | JumpList= 944 | ViMarks=.,3,47,[,3,47,],3,47 945 | 946 | [view-settings,view=0,item:glossary/Precondition.tex] 947 | CursorColumn=0 948 | CursorLine=3 949 | JumpList= 950 | ViMarks= 951 | 952 | [view-settings,view=0,item:glossary/Quality.tex] 953 | CursorColumn=15 954 | CursorLine=3 955 | JumpList= 956 | ViMarks=.,3,14,[,3,12,],3,14 957 | 958 | [view-settings,view=0,item:glossary/RegressionTesting.tex] 959 | CursorColumn=168 960 | CursorLine=3 961 | JumpList= 962 | ViMarks=.,28,161,[,28,161,],28,161 963 | 964 | [view-settings,view=0,item:glossary/Requirement.tex] 965 | CursorColumn=173 966 | CursorLine=5 967 | JumpList= 968 | ViMarks=.,5,171,[,5,151,],5,171 969 | 970 | [view-settings,view=0,item:glossary/RootCause.tex] 971 | CursorColumn=207 972 | CursorLine=7 973 | JumpList= 974 | ViMarks=.,7,0,[,7,0,],7,0 975 | 976 | [view-settings,view=0,item:glossary/SCRUM.tex] 977 | CursorColumn=61 978 | CursorLine=12 979 | JumpList= 980 | ViMarks=.,12,61,[,12,61,],12,61 981 | 982 | [view-settings,view=0,item:glossary/SecurityTesting.tex] 983 | CursorColumn=206 984 | CursorLine=19 985 | JumpList= 986 | ViMarks=.,19,205,[,19,205,],19,205 987 | 988 | [view-settings,view=0,item:glossary/Server.tex] 989 | CursorColumn=82 990 | CursorLine=5 991 | JumpList= 992 | ViMarks=.,5,81,[,5,68,],5,81 993 | 994 | [view-settings,view=0,item:glossary/SmokeTesting.tex] 995 | CursorColumn=171 996 | CursorLine=24 997 | JumpList= 998 | ViMarks=.,24,171,[,24,171,],24,171 999 | 1000 | [view-settings,view=0,item:glossary/Sprint.tex] 1001 | CursorColumn=315 1002 | CursorLine=17 1003 | JumpList= 1004 | ViMarks=.,17,314,[,17,314,],17,314 1005 | 1006 | [view-settings,view=0,item:glossary/Staging.tex] 1007 | CursorColumn=25 1008 | CursorLine=3 1009 | JumpList= 1010 | ViMarks=.,3,24,[,3,20,],3,24 1011 | 1012 | [view-settings,view=0,item:glossary/Strategy.tex] 1013 | CursorColumn=28 1014 | CursorLine=6 1015 | JumpList= 1016 | ViMarks=.,6,27,[,6,0,],6,27 1017 | 1018 | [view-settings,view=0,item:glossary/SuspensionCriteria.tex] 1019 | CursorColumn=17 1020 | CursorLine=8 1021 | JumpList= 1022 | ViMarks=.,8,16,[,8,7,],8,16 1023 | 1024 | [view-settings,view=0,item:glossary/System.tex] 1025 | CursorColumn=0 1026 | CursorLine=0 1027 | JumpList= 1028 | ViMarks= 1029 | 1030 | [view-settings,view=0,item:glossary/Test.tex] 1031 | CursorColumn=213 1032 | CursorLine=7 1033 | JumpList= 1034 | ViMarks=.,7,212,[,7,212,],7,212 1035 | 1036 | [view-settings,view=0,item:glossary/TestCase.tex] 1037 | CursorColumn=9 1038 | CursorLine=19 1039 | JumpList= 1040 | ViMarks=.,3,8,[,3,8,],3,8 1041 | 1042 | [view-settings,view=0,item:glossary/TestDesign.tex] 1043 | CursorColumn=40 1044 | CursorLine=7 1045 | JumpList= 1046 | ViMarks=.,7,39,[,7,32,],7,39 1047 | 1048 | [view-settings,view=0,item:glossary/TestIdea.tex] 1049 | CursorColumn=40 1050 | CursorLine=5 1051 | JumpList= 1052 | ViMarks=.,5,39,[,5,31,],5,39 1053 | 1054 | [view-settings,view=0,item:glossary/TestScenario.tex] 1055 | CursorColumn=82 1056 | CursorLine=15 1057 | JumpList= 1058 | ViMarks= 1059 | 1060 | [view-settings,view=0,item:glossary/TestSuite.tex] 1061 | CursorColumn=47 1062 | CursorLine=7 1063 | JumpList= 1064 | ViMarks=.,5,16,[,5,9,],5,16 1065 | 1066 | [view-settings,view=0,item:glossary/Testability.tex] 1067 | CursorColumn=0 1068 | CursorLine=3 1069 | JumpList= 1070 | ViMarks=.,3,0,[,3,0,],3,0 1071 | 1072 | [view-settings,view=0,item:glossary/Traceability.tex] 1073 | CursorColumn=24 1074 | CursorLine=5 1075 | JumpList= 1076 | ViMarks=.,5,23,[,5,23,],5,23 1077 | 1078 | [view-settings,view=0,item:glossary/UseCase.tex] 1079 | CursorColumn=99 1080 | CursorLine=17 1081 | JumpList= 1082 | ViMarks=.,5,71,[,5,60,],5,71 1083 | 1084 | [view-settings,view=0,item:glossary/UserStory.tex] 1085 | CursorColumn=104 1086 | CursorLine=5 1087 | JumpList= 1088 | ViMarks=.,5,103,[,5,103,],5,103 1089 | 1090 | [view-settings,view=0,item:glossary/VerificationAndValidation.tex] 1091 | CursorColumn=11 1092 | CursorLine=1 1093 | JumpList= 1094 | ViMarks=.,26,16,[,26,7,],26,16 1095 | 1096 | [view-settings,view=0,item:glossary/Version.tex] 1097 | CursorColumn=187 1098 | CursorLine=32 1099 | JumpList= 1100 | ViMarks=.,23,49,[,23,49,],23,49 1101 | 1102 | [view-settings,view=0,item:glossary/WhiteBoxBlackBox.tex] 1103 | CursorColumn=46 1104 | CursorLine=27 1105 | JumpList= 1106 | ViMarks=.,11,118,[,11,118,],11,129 1107 | --------------------------------------------------------------------------------