Language of Testing | Software Testing Vocabulary


While communicating with colleagues or clients or within testing team, we commonly use vocabulary like “unit testing, “functional testing”, regression testing”,” system testing”, “test policies”, Bug Triage” etc.
If we communicate the same to a person who is not a test professional we need to explain in detail each and every term. So in this case communication becomes so difficult and painful. To speak the language of testing, you need to learn its vocabulary.Find below a huge collection of testing vocabulary:Affinity Diagram: A group process that takes large amounts of language data, such as developing by brainstorming, and divides it into categories
Audit: This is an inspection/assessment activity that verifies compliance with plans, policies and procedures and ensures that resources are conserved.

Baseline:A quantitative measure of the current level of performance.
Benchmarking: Comparing your company’s products, services or processes against best practices or competitive practices, to help define superior performance of a product,service or support processes.
Black-box Testing: A test technique that focuses on testing the functionality of the program component or application against its specifications without knowlegde of how the system constructed.
Boundary value analysis: A data selection technique in which test data is chosen from the “boundaries” of the input or output domain classes, data structures and procedure parameters. Choices often include the actual minimum and maximum boundary values, the maximum value plus or minus one and the minimum value plus or minus one.
Branch Testing: A test method that requires that each possible branch on each decision be executed on at least once.
Brainstorming: A group process for generating creative and diverse ideas.
Bug: A catchall term for all software defects or errors.

Debugging: The process of analysing and correcting syntactic, logic and other errors identified during testing.
Decision Coverage: A white-box testing technique that measures the number of – or percentage – of decision directions executed by the test case designed. 100% Decision coverage would indicate that all decision directions had been executed at least once during testing. Alternatively each logical path through the program can be tested.
Decision Table
A tool for documenting the unique combinations of conditions and associated results in order to derive unique test cases for validation testing.
Defect Tracking Tools
Tools for documenting defects as they are found during testing and for
tracking their status through to resolution.
Desk Check: A verification technique conducted by the author of the artifcat to verify the completeness of their own work. This technique does not involve anyone else.
Dynamic Analysis: Analysis performed by executing the program code.Dynamic analysis executes or simulates a development phase product and it detects errors by analyzing the response of the product to sets of input data.

Entrance Criteria: Required conditions and standards for work product quality that must be present or met for entry into the next stage of the software development process.
Equivalence Partitioning: A test technique that utilizes a subset of data that is representative of a larger class. This is done in place of undertaking exhaustive testing of each value of the larger class of data.
Error or defect: 1.A discrepancy between a computed, observed or measured value or condition and the true, specified or theortically correct value or conditon 2.Human action that results in software containing a fault (e.g., omission or misinterpretation of user requirements in a software specification, incorrect translation or omission of a requirement in the design specification)
Error Guessing: Test data selection techniques for picking values that seem likely to cause defects. This technique is based upon the theory that test cases and test data can be developed based on intuition and experience of the tester.
Exhaustive Testing: Executing the program through all possible combination of values for program variables.
Exit criteria: Standards for work product quality which block the promotion of incomplete or defective work products to subsequent stages of the software development process.

Flowchart
Pictorial representations of data flow and computer logic. It is frequently easier to understand and assess the structure and logic of an application system by developing a flow chart than to attempt to understand narrative descriptions or verbal explanations. The flowcharts for systems are normally developed manually, while flowcharts of programs can be produced.
Force Field Analysis
A group technique used to identify both driving and restraining forces that influence a current situation.
Formal Analysis
Technique that uses rigorous mathematical techniques to analyze the algorithms of a solution for numerical properties, efficiency, and correctness.
Functional Testing
Testing that ensures all functional requirements are met without regard to the final program structure.

Histogram
A graphical description of individually measured values in a data set that is organized according to the frequency or relative frequency of occurrence. A histogram illustrates the shape of the distribution of individual values in a data set along with information regarding the average and variation.

Inspection
A formal assessment of a work product conducted by one or more qualified independent reviewers to detect defects, violations of development standards, and other problems. Inspections involve authors only when specific questions concerning deliverables exist. An inspection identifies defects, but does not attempt to correct them. Authors take corrective actions and arrange follow-up reviews as needed.
Integration Testing
This test begins after two or more programs or application components have been successfully unit tested. It is conducted by the development team to validate the interaction or communication/flow of information between the individual components which will be integrated.

Life Cycle Testing
The process of verifying the consistency, completeness, and correctness of software at each stage of the development life cycle.

Pass/Fail Criteria
Decision rules used to determine whether a software item or feature passes or fails a test.
Path Testing
A test method satisfying the coverage criteria that each logical path through the program be tested. Often, paths through the program are grouped into a finite set of classes and one path from each class is tested.
Performance Test
Validates that both the online response time and batch run times meet the defined performance requirements.
Policy
Managerial desires and intents concerning either process (intended objectives) or products (desired attributes).
Population Analysis
Analyzes production data to identify, independent from the specifications, the types and frequency of data that the system will have to process/produce. This verifies that the specs can handle types and frequency of actual data and can be used to create validation tests.
Procedure
The step-by-step method followed to ensure that standards are met.
Process
1. The work effort that produces a product. This includes efforts of people and equipment guided by policies, standards, and procedures.
2. A statement of purpose and an essential set of practices (activities) that address that purpose.
Proof of Correctness
The use of mathematical logic techniques to show that a relationship between program variables assumed true at program entry implies that another relationship between program variables holds at program exit.

Quality
A product is a quality product if it is defect free. To the producer, a product is a quality product if it meets or conforms to the statement of requirements that defines the product. This statement is usually shortened to: quality means meets requirements. From a customer’s perspective, quality means “fit for use.”
Quality Assurance (QA)
Deals with ‘prevention’ of defects in the product being developed.It is associated with a process.The set of support activities (including facilitation, training, measurement, and analysis) needed to provide adequate confidence that processes are established and continuously improved to produce products that meet specifications and
are fit for use.
Quality Control (QC)
Its focus is defect detection and removal. Testing is a quality control activity
Quality Improvement
To change a production process so that the rate at which defective products (defects) are produced is reduced. Some process changes may require the product to be changed.
 


Prioritization of Test Cases


Importance of prioritizing
There is no limit to how much testing we could do. We cannot test everything, exhaustive testing (testing all combinations of inputs and preconditions) is impractical, so we must prioritise. It is easy enough to identify far more test cases than we will ever have time to execute so we need an approach to selecting a subset of them. Selecting test cases at random is not an effective strategy. We need to use a more intelligent approach that helps identify which tests are most important. In short, we must prioritize our tests.

Prioritize tests so that whenever you stop testing you have done the best testing in the time available.

How to prioritize
The principle is that we must adopt a prioritization scheme for selecting some tests above others. As we start from highest priority and scan the tests in decreasing order of priority, there must be a point at which we reach the first test that is of too low a priority to be done. All tests of a lower priority still are de-scoped. There are many different criteria that can be used to prioritize tests and they can be used in combination. Possible ranking criteria include the following:

  • Ask the end-user to prioritize the requirements (and test those first)
  • Test first the areas of the software that have had most faults in the past
  • Test most those areas of the software that are most complex or critical.
  • Tests that would find the most severe failures.
  • Tests that would find the most visible failures.
  • Tests that would find the most likely faults.
     
Reference: http://goo.gl/HL40G (iseb notes)


Three Simple truths in Software Development ~ from The Agile Samurai by (Jonathan Rasmusson)


Three Simple truths in Software Development1. It is impossible to gather all the requirements at the beginning of a project.
2. Whatever requirements you do gather are guaranteed to change.
3. There will always be more to do than time and money will allow.

– Accepting the first truth means you are not afraid to begin your journey without knowing everything up front.- Accepting the second means you no longer fear or avoid change. You know it is coming.

– And by accepting the third, you no longer get stressed when your todo list exceeds your time and resources to deliver.

Once you accept these three simple project truths, much of the stress and anxiety traditionally associated with software delivery disappears. You are then able to think and innovate with a level of focus and clarity that escapes most in our industry.

Source: The Agile Samurai – How Agile Masters Deliver Great Software (Jonathan Rasmusson)

Just love this book.. This book is must read for Agile practitioners.

You can buy this book from Amazon: 


Evaluating / Interviewing Software Test Lead and Managers – Test Management Questions.


Some unique and useful questions (specific to Test Management) to evaluate Software Test Leads and Managers:


1. Under extreme conditions, how you can keep yourself and your team energized?2. What is your criteria to evaluate a software tester?

3. Your thoughts on limiting the scope of testing by measuring testability?

4. How you can encourage your team (testers) for bug advocacy?

5. Any thoughts on reducing the cost of testing without cutting the resources?

6. How you keep yourself updated on the latest testing techniques, strategies, testing tools/ test frameworks and so on? (If answer is like – “Reading websites.. blogs..” then ask the names of blogs/sites).

7. How we can achieve time-boxing in testing?

8. In case when there is time crunch, do you think forcing tradeoff(s) in testing is a right step?

9. It is being said by experts that “Studying epistemology helps you test better“. Do you agree on this? Your thoughts on Epistemology?


Giveaway Contest – 4 Books – QTP Descriptive Programming Unplugged

As we posted earlier, Tarun Lalwani and Anshoo Arora (authors of book QTP Descriptive Programming Unplugged) has offered 2 copies for our blog readers. We are going to double this count by giving away 2 books from our side. So there will be total of 4 books. To Participate in this giveaway you need to register below (widget at the end of this post).

Note – Our previous giveaways were for Indian readers only. But this giveaway is for all readers all countries 🙂

Steps:

1. Like this Facebook Page and click YES in below form (10 Points) – Mandatory
3. Follow us @testingconcepts on Twitter and enter your twitter handle(username) in below form (4 Points) – Optional
3. Tweet about this giveaway (see below bold text) and enter the URL in below form (25 Points) – Optional

Tweet this message (entire text in bold):
Giveaway Contest – 4 Books – “QTP Descriptive Programming Unplugged” – http://t.co/cX7I3AP5 via @testingconcepts


More points = more chances to win the book.

Contest begins from today and ends on Nov 18, 2012. After the end date, we will choose 4 random entries as winners from the participants/entries with higher points.

a Rafflecopter giveaway