Software Testing Concepts

Security testing is a process that is performed with the intention of revealing flaws in security mechanisms and finding the vulnerabilities or weaknesses of software applications. The prime objective of security testing is to find out how vulnerable a system may be and to determine whether its data and resources are protected from potential intruders. Online transactions have increased rapidly of late making security testing as one of the most critical areas of testing for such web applications. Security testing is more effective in identifying potential vulnerabilities when performed regularly.   Normally, security testing has the following attributes:    ● Authentication  ● Authorization  ● Confidentiality  ● Availability  ● Integrity  ● Non-repudiation  ● Resilience   Why is Security Testing Important?    A comprehensive security testing framework deals with validation across all layers of an applica...

Uniform Resource Locator (URL):    URL is an acronym for Uniform Resource Locator and is a reference (an address) to a resource on the Internet. URLs occur most commonly to reference web pages (Http) but are also used for file transfer (FTP), email (mailto), database access (JDBC), and many other applications.    A URL has two main components:    Protocol identifier: ​ For the URL http://example.com, the protocol identifier is Http.   Resource name:​ For the URL http://example.com, the resource name is example.com.    The resource name is the complete address to the resource. The format of the resource name depends entirely on the protocol used, but for many protocols, including HTTP, the resource name contains one or more of the following Components:   Host Name:​ The name of the machine on which the resource lives.  Filename: ​The pathname to the file on the machine.  Port Number: ​ The port number to ...

Web application testing, a software testing technique exclusively adopted to test the applications that are hosted on the web in which the application interfaces and other functionalities are tested.  Web Application Testing - Techniques:   1. ​Functionality Testing ​:​   Below are some of the checks that are performed but not limited to the below list:  ● Verify there is no dead page or invalid redirects.  ● First, check all the validations on each field.  ● Wrong inputs to perform negative testing.  ● Verify the workflow of the system.  ● Verify data integrity.   2. ​Usability testing​ :​ To verify how the application is easy to use with.  ● Test the navigation and controls.  ● Content checking.  ● Check for user intuition.  3.​ Interface testing ​: ​ Performed to verify the interface and the dataflow from one system to another.   4.​ Compatibility testing ​: ​  Compatibility te...

CCB Team Member ​:    ● Project Manager ​: ​ The Role of the project manager. A project manager is a person who has the overall responsibility for the successful initiation planning design execution monitoring controlling and closure of a project.   ● Client representative ​:  ​ This is the person responsible for managing the project on behalf of the client. This may be an individual from within the client's organization or maybe a consultant.   ● Quality Manager​ :  ​ Quality assurance managers provide training in best practices. They aim to make production employees responsible for managing their own quality standards.   ● Contract Manager ​: ​ The contract manager is the management of contracts made with customers' vendors partners or employees. The personnel involved in contract administration required to negotiate support and manage effective contracts are often expensive to train and retain.   ● Funding Ma...

The term configuration item (CI) refers to the fundamental structural unit of a configuration management system. Examples of CIs include individual requirements documents software models and plans. The configuration-management system oversees the life of the CIs through a combination of processes and tools by implementing and enabling the fundamental elements of identification change management status accounting and audits. This system aims to avoid the introduction of errors related to lack of testing as well as incompatibilities with other CIs.     Configuration Management Activities ​:     1. ​Configuration Item Identification ​:  ​In this phase, the item will be identified for making changes.  Example: ​Requirement document design document source code etc    2. ​Change Control ​: ​ Controlling the release and changes of the product throw out the software life cycle here CCB team will approve or disapprove changes prioritize the change...

Software configuration management (SC) is a software engineering discipline consisting of standard processes and techniques often used by organizations to manage the changes introduced to its software products. SC helps in identifying individual elements and configurations tracing changes and version selection control and baselining.   SC is also known as software control management. SC aims to control changes introduced to large complex software systems through reliable version selection and version control.   Software Configuration Management does​ ​   ● Introduction to Software Configuration management and Configuration management for software Testers.  ● Software configuration management (SC) is the discipline for systematically controlling the changes that tae place during Software evelopment.  ● Software development software consists of a collection of items (such as program documents etc..) that can easily be changed. uring software...

A defect report is a document that identifies and describes a defect detected by a tester. The purpose of a defect report is to state the problem as clearly as possible so that developers can replicate the defect easily and fix it.  Defect Report Template:    ID​ :  ​A unique identifier is given to the defect. (Usually, automated)   Project ​:  ​Project name.   Product: ​Product name.   Release Version: ​ Release version of the product. (e.g. 1.1.3)   Module ​: ​Specific module of the product where the defect was detected.   Defect Priority​ ​: ​Priority of the Defect.   Defect Severity ​: ​Severity of the Defect.   Summary ​: ​Summary of the defect. Keep this clear and concise. Description Detailed description of the defect. Describe as much as possible but without repeating anything or using complex words. Keep it simple but comprehensive.    Expected Results ​: ...

● Severity Defect:​   “ Severity of a bug depends on how much severe the bug is and the impact of the bug over operation of the program.”  For Example: ​ If an application crashes by clicking on some button then the severity of that issue is high and the priority is low.  Defect severity can be categorized into three class:    Major:​   It is a highly severe defect and collapses the system. However, certain parts of the system remain functional.   Medium:​   It causes some undesirable behavior, but the system is still functional.   Low:​   ​It won’t cause any major break-down of the system.     ● Priority Defect:​  “Priority of a bug depends upon the requirement of the project and how soon the bug needs to be fixed to deploy it.”   For Example:​ If the logo of the application is not correct or displaced then the priority of that issue is high and severity is low to fix it. ...

The bug life cycle is the cycle that a defect covers in its lifetime. This cycle starts when a tester finds a new bug and ends when a bug closed. The bug life cycle is also known as defect life cycle.   There are some steps which a bug covers during the bug life cycle are:  New: ​  When a tester finds a new bug it come under the new state.    Open: ​  In this stage, the developer Analyzes the bug and if he finds that the bug is valid then start working on it.  ● Duplicate:​ If the developer finds the same bug assigned earlier he change the status of that bug to duplicate.  ● Deferred:​ If the developer feels that this functionality in which bug is found is under construction or it will come in the next phase then he changes the state of that bug in Deferred.  ● Not a Defect:​ If the developer feels that bug is invalid or the requirement is changed then he changes its state to not a bug.   Assign to d...

Defect management is a process to identify the defect of the software. The Development team needs a defect management tool so that they can find defect easily and at a very early stage of process because as soon as the defect is detected the cost of fixing it will be low, but if the defect is detected in the later stage of development process then the cost of fixing that defect will be more. Defect management will work as a backbone to developing a team in finding the defect in the early stage in a very easy way.  Defect management process:    Identification:​   This will be the first step to identify the defect in the process this can be done by the testing team and sometimes the customer can also tell you about the defect.   Categorization:​  ​ After the defect is registered, then it passes to the desired person then checks it and categorize it that what type of defect it is and then move to the next step.   Prioritization:​  ...

Test Scenario ​:  ​ A Scenario is any functionality that can be tested. It is also called Test Condition, or Test Possibility.    Test Scenario Template :    ● Test Scenario ID   ● Test Scenario name  ● Objective  ● Pre-Condition  ● Test Condition   Test Scenario ID ​:   ​Each test Scenario should have a unique ID.   Test Scenario name ​:  ​ The title is important because it’s often the first or only thing you see when you are scanning a list of Test Scenarios.Clear titles are the key to help testers to find quickly the right test Scenario.   Objective​ :  ​ To mention the functionality name of the test scenario.   Pre-Condition ​:  ​ Any requirement that needs to be done before the execution of this test case.   Test Condition​ :  ​ Test Steps section gives the tester a numbered list of the steps to perform in the system, w...

Test Design Techniques​ ● Equivalence Class Partitioning ● Boundary Value Analysis BVA ● Error guessing Software testing Techniques help to design better cases. Since exhaustive testing is not possible; Testing Techniques help reduce the number of test cases to be executed while increasing test coverage. They help identify test conditions that are otherwise difficult to recognize. Equivalence Class Partitioning​ :​  Equivalent Class Partitioning allows dividing a set of test conditions into a partition which should be considered the same. This software testing method divides the input domain of a program into classes of data from which test cases should be designed. The concept behind this technique is that the test case of a representative value of each class is equal to a test of any other value of the same class. It allows us to Identify valid as well as invalid equivalence classes. Example:   We have to test the ATM machine for withdrawal transactions. The p...

Test design is to ensure that all requirements are met through a series of test procedures, increasing the probability of the software being capable of what is needed and wanted by the client.                                                                          OR  By design we mean to create a plan for how to implement an idea and technique is a method or way for performing a task. So, test design is creating a set of inputs for given software that will provide a set of expected outputs.  Test design should start the moment the system requirements have been approved and baselined.

Use Case- Paths/ Flows ● Basic path  successful  ● Alternate path  successful   ● Exceptional path  unsuccessful  ● Error path  unsuccessful    Basic path successful ​ ​ The main flow of events describes a single path through the system. It specifies the interactions between the actor and the system for an ideal condition. It represents the most common way that the use case plays out successfully and contains the most common sequence of user-system interactions.    Alternate path successful​   ​ An alternate flow is a series of actions other than the basic flow that results in a user completing his or her goal. Often, It is considered to be an optional flow. It means that the user has chosen to take an alternative path through the system.    Exceptional path unsuccessful​   ​ An exceptional flow is any action that will cause the Actor to not to complete or achieve the desired...

Attributes of a Use case Template USE CASE ID ​ States a unique ID for each use case.  USE CASE NAME ​  States the use case name. The name expresses the objective or result of the use case.   ​BRIEF​ DESCRIPTION ​  Describes the role and purpose of the use case.    ACTORS ​  Specifies a role played by a user or any other system that interacts with the subject.    PRE-CONDITION ​ A state of the system that must be present before a use case starts.    POST-CONDITIONS ​  A list of possible states for the system immediately after a use case is finished.    BASIC FLOW OF EVENTS ​ Describes the ideal, primary behavior of the system.    ALTERNATIVE FLOW ​  Describes deviations from the basic flow.    EXCEPTIONAL FLOW ​  Explains the exceptions from the basic flow.    KEY SCENARIOS ​  Enlist the most important scenarios of the use case. There can be many...

A use case is a description of a particular use of the system by an actor or user. It is used widely in developing tests at system or acceptable level. A use case is a software and system engineering term that describes how a user uses a system to accomplish a particular goal. A use case acts as a software modeling technique that defines the features to be implemented and the resolution of any errors that may be encountered.   Use Case Testing   Use Case Testing is a technique that helps identify test cases that cover the entire system, on a transaction by transaction basis from start to the finishing point. Use cases are a sequence of steps that describe the interactions between the actor and the system. Use cases are defined in terms of the actor, not the system, describing what the actor does and what the actor sees rather than what inputs the system expects and what the system’s outputs.   Business Analyst and Project Manager will write use cases. ...

Functional Requirements ​: ​ This requirement will answer the question of ​ WHAT ​the application should do. Functional requirements are product features or functions that developers must implement to enable users to accomplish their tasks. So, it’s important to make them clear both for the development team and the stakeholders. Generally, functional requirements describe system behavior under specific conditions.   ● Describes the behavior of the system as it relates to the system functionality.  ● Includes the description of the required functions, outlines of associated reports or online queries, and details of data to be held in the system.  ● Specified by users themselves.       Non- Functional Requirements​ :  ​ This requirement will answer the question of ​ HOW ​ it should do how it looks like. Non-functional requirements describe how a system must behave and establish constraints of its functionality. This type of r...

Correct requirements:​    Correctness in requirements is simply about getting it right. We wrote previously about how to apply use cases to creating correct requirements. Writing requirements correctly is as much about getting accurate information as it is about accurately documenting the information we gather.   Correctness applies in a context. Are these the right requirements to achieve the goal ?    Unambiguous requirements:​    unambiguous requirements are about understanding what is written, and what is read. A great requirement has a single interpretation. A good requirement has a single reasonable interpretation. As part of our development process, we will use listening skills like active listening to make sure that our development team understands the requirement intended to write.     Traceable requirements: ​  The significance of traceability within a requirement tool or a test management tool enables links ...

Implicit and Explicit requirements Explicit Requirements​ :    ● The Things business analyst Wrote Down.  ● These are the requirements explicitly stated or mentioned by the customer.  ● Explicit requirements are most commonly found in documents communicated by stakeholders to the development team.   ● This is the simplest type and the easiest to test.  ● The development team might take the form of an elaborate design specification, a set of acceptance criteria.  ● Explicit requirements in the form of claims that is, communications to end-users about things the software can do.   Implicit Requirements​ :  ● The Things client Will Expect  ● These are the requirements that are not explicitly stated by the customer, but implied or derived from the requirement stated by the customer.  ● These are all the things that users are going to expect that were not captured explicitly.  ● Examples include performance...

 ​What is done in the Requirements gathering & Analysis phase?    Requirement gathering is the first and basic phase of the software development life cycle. this phase is essential for developing software. the requirement serves the detail descriptions of functions that software should provide. requirement specifies the need of the client. Business analysts and subject experts are responsible for the requirement gathering process.  The most important phase of the SDLC is the requirement gathering and analysis phase because this is when the project team begins to understand what the customer wants from the project. During the analysis phase, the project team needs to ensure they can deliver the requirements.  After the customer provides requirements for the product, the project manager and members of the project team begin to analyze the requirements. The business managers analyze each requirement to ensure the requirement can be included in the softwar...