Build verification testing

Build verification Testing:

            Build verification testing is also called as smoke testing.Build verification is a set of tests run on new build to verify that whether the build is application to proceed for testing.It is done priorly by test team before releasing  application to testing.This testing is mainly done for build validation and build acceptance.This test is done for each new build  if any of tests got failed that build is rejected by testing team.
Below is the process for Build verification testing:
        ·     The results are sent to TL / PM

·     Results are analyzed by TL / PM

·     The person who runs the tests and TL / PM diagnoses the cause of failure (if any)

·     If there is any defect, the relevant information is sent to respective developers

·     Developer fixes the bug

Once the bug is fixed; BVT test suite is executed again. This process gets repeated for every new build.

How to see cookies files

step 1: Open IE
step 2: click the tools menu->Internet options
step 3: Click general tab->search for browsing history which is under home page information
step 4: From browsing history click settings
step 5: In that window you will get three events a)move folder b) view objects c)view files
step 6: Click the view files you will get the temporary files which is the cookies files 

Cookies Testing

 Below is a list of major scenarios for cookies testing of a website. Multiple test cases can be generated from 

1.                   Check if the application is writing cookies properly or not.

2.                  Test to make sure that no personal or sensitive data is stored in the cookie. If it is there in cookies, it should be in encrypted format.

3.                  If the application under test is a public website, there should not be overuse of cookies. It may result in loss of website traffic if browser is prompting for cookies more often.

4.                  Close all browsers, delete all previously written cookies and disable the cookies from your browser settings. Navigate or use that part of web site which use cookies. It should display appropriate messages like "For smooth functioning of this site please enable cookies on your browser."

5.                  Set browser options to prompt whenever cookie is being stored / saved in your system. Navigate or use that part of web site which use cookies. It will prompt and ask if you want to accept or reject the cookie. Application under test should display an appropriate message if you reject the cookies. Also, check that if pages are getting crashed or data is getting corrupted.

6.                  Close all browsers windows and manually delete all cookies. Navigate various web pages and check and see if these web pages show unexpected behavior.

7.                  Edit few cookies manually in notepad or some other editor. Make modifications like alter the cookie content, name of the cookie, change expiry date etc. Now, test the site functionality. Corrupted cookies should not allow to read the data inside it.

8.                  Cookies written by one web site should not be accessible by other website.

9.                  If you are testing an online shopping portal, Check if reaching to your final order summary page deletes the cookie of previous page of shopping cart properly and no invalid action or purchase got executed from same logged in user.

10.               Check if the application under test is writing the cookies properly on different browsers as intended and site works properly using these cookies. This test can be done on browsers like different versions of internet explorer, Mozilla Firefox, Netscape, Opera etc.

11.                If the application under test is using cookies to maintain the logging state for users. Check if some id is being displayed in the address bar. Now, change the id & press enter. It should display an access denied message and and you should not be able to see other user's account.

BLACK BOX TESTING

Black Box Testing: Types and techniques of BBT

Black box testing treats the system as a “black-box”, so it doesn’t explicitly use Knowledge of the internal structure or code. Or in other words the Test engineer need not know the internal working of the “Black box” or application.
Main focus in black box testing is on functionality of the system as a whole. The term ‘behavioral testing’ is also used for black box testing and white box testing is also sometimes called ‘structural testing’. Behavioral test design is slightly different from black-box test design because the use of internal knowledge isn’t strictly forbidden, but it’s still discouraged.
Each testing method has its own advantages and disadvantages. There are some bugs that cannot be found using only black box or only white box. Majority of the applicationa are tested by black box testing method. We need to cover majority of test cases so that most of the bugs will get discovered by blackbox testing.
Black box testing occurs throughout the software development and Testing life cycle i.e in Unit, Integration, System, Acceptance and regression testing stages.
Tools used for Black Box testing:
Black box testing tools are mainly record and playback tools. These tools are used for regression testing that to check whether new build has created any bug in previous working application functionality. These record and playback tools records test cases in the form of some scripts like TSL, VB script, Java script, Perl.
Advantages of Black Box Testing
- Tester can be non-technical.
- Used to verify contradictions in actual system and the specifications.
- Test cases can be designed as soon as the functional specifications are complete
Disadvantages of Black Box Testing
- The test inputs needs to be from large sample space.
- It is difficult to identify all possible inputs in limited testing time. So writing test cases is slow and difficult
- Chances of having unidentified paths during this testing
Methods of Black box Testing:
Graph Based Testing Methods:
Each and every application is build up of some objects. All such objects are identified and graph is prepared. From this object graph each object relationship is identified and test cases written accordingly to discover the errors.
Error Guessing:
This is purely based on previous experience and judgment of tester. Error Guessing is the art of guessing where errors can be hidden. For this technique there are no specific tools, writing the test cases that cover all the application paths.
Boundary Value Analysis:
Many systems have tendency to fail on boundary. So testing boundry values of application is important. Boundary Value Analysis (BVA) is a test Functional Testing technique where the extreme boundary values are chosen. Boundary values include maximum, minimum, just inside/outside boundaries, typical values, and error values.
Extends equivalence partitioning
Test both sides of each boundary
Look at output boundaries for test cases too
Test min, min-1, max, max+1, typical values
BVA techniques:
1. Number of variables
For n variables: BVA yields 4n + 1 test cases.
2. Kinds of ranges
Generalizing ranges depends on the nature or type of variables
Advantages of Boundary Value Analysis
1. Robustness Testing – Boundary Value Analysis plus values that go beyond the limits
2. Min – 1, Min, Min +1, Nom, Max -1, Max, Max +1
3. Forces attention to exception handling
Limitations of Boundary Value Analysis
Boundary value testing is efficient only for variables of fixed values i.e boundary.
Equivalence Partitioning:
Equivalence partitioning is a black box testing method that divides the input domain of a program into classes of data from which test cases can be derived.
How is this partitioning performed while testing:
1. If an input condition specifies a range, one valid and one two invalid classes are defined.
2. If an input condition requires a specific value, one valid and two invalid equivalence classes are defined.
3. If an input condition specifies a member of a set, one valid and one invalid equivalence class is defined.
4. If an input condition is Boolean, one valid and one invalid class is defined.
Comparison Testing:
Different independent versions of same software are used to compare to each other for testing in this method.

Web Application Testing

While testing a web application you need to consider following Cases:

• Functionality Testing
• Performance Testing
• Usability Testing
• Server Side Interface
• Client Side Compatibility
• Security
Functionality:
In testing the functionality of the web sites the following should be tested:
• Links
i. Internal Links
ii. External Links
iii. Mail Links-have underline for mailid
iv. Broken Links-use web link validator tool for broken link finding and reporting
• Forms
i. Field validation-(javascript,jquery)
ii. Error message for wrong input-with colour red
iii. Optional and Mandatory fields
• Database
* Testing will be done on the database integrity.
• Cookies
* Testing will be done on the client system side, on the temporary Internet files.Delete the cookie and check whether application still in  login.After deleted cookie site user must gets logged out
Performance :
Performance testing can be applied to understand the web site’s scalability
• Load:-for this use load testing tools(load runner)
i. What is the no. of users per time?
ii. Check for peak loads and how system behaves
iii. Large amount of data accessed by user
• Stress:
i. Continuous Load
ii. Performance of memory, CPU, file handling etc..
Usability:
Usability testing is the process by which the human-computer interaction characteristics of a system are measured, and weaknesses are identified for correction.
• Ease of learning
• Navigation
• Subjective user satisfaction
• General appearance
Server Side Interface:
In web testing the server side interface should be tested. This is done by verify that communication is done properly. Compatibility of server with software, hardware, network and database should be tested.
Client Side Compatibility:
The client side compatibility is also tested in various platforms, using various browsers etc.
Security:
The primary reason for testing the security of a web is to identify potential vulnerabilities and subsequently repair them.
• Network Scanning
• Vulnerability Scanning
• Password Cracking
• Log Review
• Integrity Checkers
• Virus Detection

Testing Types

Software Testing Types:
Black box testing – Tests are based on requirements and functionality.
White box testing – This testing is based on knowledge of the internal logic of an application’s code. Also known as Glass box Testing. Internal software and code working should be known for this type of testing. Tests are based on coverage of code statements, branches, paths, conditions.
Unit testing – Testing of individual software components or modules. Typically done by the programmer and not by testers, as it requires detailed knowledge of the internal program design and code. may require developing test driver modules or test harnesses.
Incremental integration testing – Bottom up approach for testing i.e continuous testing of an application as new functionality is added; Application functionality and modules should be independent enough to test separately. done by programmers or by testers.
Integration testing – Testing of integrated modules to verify combined functionality after integration. Modules are typically code modules, individual applications, client and server applications on a network, etc. This type of testing is especially relevant to client/server and distributed systems.
Functional testing – This type of testing ignores the internal parts and focus on the output is as per requirement or not. Black-box type testing geared to functional requirements of an application.
System testing – Entire system is tested as per the requirements. Black-box type testing that is based on overall requirements specifications, covers all combined parts of a system.
End-to-end testing – Similar to system testing, involves testing of a complete application environment in a situation that mimics real-world use, such as interacting with a database, using network communications, or interacting with other hardware, applications, or systems if appropriate.
Sanity testing - Testing to determine if a new software version is performing well enough to accept it for a major testing effort. If application is crashing for initial use then system is not stable enough for further testing and build or application is assigned to fix.
Regression testing – Testing the application as a whole for the modification in any module or functionality. Difficult to cover all the system in regression testing so typically automation tools are used for these testing types.
Acceptance testing -Normally this type of testing is done to verify if system meets the customer specified requirements. User or customer do this testing to determine whether to accept application.
Load testing – Its a performance testing to check system behavior under load. Testing an application under heavy loads, such as testing of a web site under a range of loads to determine at what point the system’s response time degrades or fails.
Stress testing – System is stressed beyond its specifications to check how and when it fails. Performed under heavy load like putting large number beyond storage capacity, complex database queries, continuous input to system or database load.
Performance testing – Term often used interchangeably with ‘stress’ and ‘load’ testing. To check whether system meets performance requirements. Used different performance and load tools to do this.
Usability testing – User-friendliness check. Application flow is tested, Can new user understand the application easily, Proper help documented whenever user stuck at any point. Basically system navigation is checked in this testing.
Install/uninstall testing - Tested for full, partial, or upgrade install/uninstall processes on different operating systems under different hardware, software environment.
Recovery testing – Testing how well a system recovers from crashes, hardware failures, or other catastrophic problems.
Security testing – Can system be penetrated by any hacking way. Testing how well the system protects against unauthorized internal or external access. Checked if system, database is safe from external attacks.
Compatibility testing – Testing how well software performs in a particular hardware/software/operating system/network environment and different combination s of above.
Comparison testing – Comparison of product strengths and weaknesses with previous versions or other similar products.
Alpha testing – In house virtual user environment can be created for this type of testing. Testing is done at the end of development. Still minor design changes may be made as a result of such testing.
Beta testing – Testing typically done by end-users or others. Final testing before releasing application for commercial purpose.

Testing process

·     Analysis Requirements: gathering and analyzing customer requirements.

·   Software Test Plan (STP): definition of scope and goals; elaboration of appropriate testing methodologies; preparation of software testing strategy; assigning roles and responsibilities; definition of resource requirements, start and completion criteria.

·     Test Environment: setting up the test infrastructure, identification of testing environment and test tools, installation and configuration of the product.

·     Test Metrics: description of areas to be measured, development and collection of metrics.

·     Test Design and Implementation: development of test scenarios, test cases, test check-list, test procedures, test scripts; development of test applications, etc.

·     Test Execution: performance of testing, both static or dynamic, which is provided for usage of manual and automatic test cases as required by STP and STS.

·     Defect Management (Bug Tracking): recording testing results, defect description (Problem Reports, Change Requests); defect review and testing results analysis; errors correction; defect resolution verification.

REReporting: status reports, weekly reports, milestone reports, closure report.

\

Test Design Techniques

Test Design Techniques:

While developing the test cases if at all the test engineer feels complex in some areas to over come that complexity usually the test engineer will use test design techniques.

            Generally two types of techniques are used in most of the companies.

1.      Boundary Value Analysis (BVA).

2.      Equableness Class Partition (ECP).

1). Boundary Value Analysis (BVA).

When ever the engineers need to develop test cases for a range kind of input then they will go for boundary value analysis. Which describes to concentrate on the boundary of the rang.

            Usually they test with the following values.

            LB-1    LB       LB+1               MV                  UB-1    UB       UB+1

2). Equableness Class Partition (ECP).

When ever the test engineer need to develop test cases for a feature which has more number of validation then one will go for equableness class partition. Which describe first divide the class of inputs and then prepare the test cases.

Ex:      Develop the test cases for E-Mail Test box whose validations are as follows.

Requirements:

1.      It should accept Minimum 4 characters Maximum 20 characters.

2.      It should accept only small characters.

3.      It should accept @ and _ special symbols only.

Boundary Value Analysis:

LB-1    LB       LB+1               MV                  UB-1    UB       UB+1

            3ch      4ch      5ch                  12ch                19ch    20ch    21ch

Equableness Class Partition (ECP).

Valid	Invalid
4char 5char 12char 19char 20char a – z @ _	3char 21char A – Z 0 – 9 All the Special Symbols apart form @ and _. Alpha Numeric. Blank Space Dismal Numbers.

Test Case Document:

Test Case ID	Test Case Type	Description	Expected Value
1 2	+ve -ve	Enter the value as per the VIT Enter the value as per the IIT	It should accept. It should not accept.

 Valid Input Table (VIT).                                                   Invalid Input Table (IIT).

Sl NO	Input
1 2 3 4 5 6	abcd ab@zx abcdabcd@ab_ abcdabcddcbaaccd_@z abcdabcdabcdabcdz@_x abcdabcdabcdabcd_xyz

Sl No	Input
1 2 3 4 5 6 7	abc ABCD ABCD123 12345.5 abcd abcd abcd abcd abcdabcd-----abc*#)

                                        

SDLC process Followed for software project

SDLC (Software Development Life Cycle)

It contains 6 phases.

Ø      Initial phase / Requirement phase.

Ø      Analysis phase.

Ø      Design phase.

Ø      Coding phase.

Ø      Testing phase.

Ø      Delivery and maintenance phase.

Initial Phase

Task                Interacting with the customer and gathering the requirements.

Roles               BA (Business Annalist)

                        EM (Engagement Manager)

Process

First of all the business analist will take an appointment from the customer, collects the templates from the company meats the customer on the appointed date gathers the requirements with the support of the templates and comeback to the company with a requirements documents. Then the engagement manager will check for the extra requirements if at all he fined any extra requirements he is responsible for the excess cast of the project. The engagement manager is also responsible for prototype demonstration in case of confused requirements.

Template

It is defined as a pre-defined format with pre-defined fields used for preparing a document perfectly.

Prototype

It is a rough and rapidly developed model used for demonstrating to the client in order to gather clear requirements and to win the confidence of a customer.

Proof

The proof of this phase is requirements document which is also called with the following name

FRS      -           (Functional Requirement Specification)

BRS     -           (Business Requirement Specification)

CRS     -           (Client/Customer Requirement Specification)

URS     -           (User Requirement Specification)

BDD    -           (Business Design Document)

BD       -           (Business Document)

Note

Some company’s may the over all information in one document called as ‘BRS’ and the detailed information in other document called ‘FRS’. But most of the company’s will maintain both of information in a single document.

Analysis  Phase

Task                Feasibility study.

                        Tentative planning.

                        Technology selection.

                        Requirement A\analysis.

 

Roles               System Annalist  (SA)

                        Project Manager (PM)

                        Team Manager   (TM)

Process

(I) Feasibility study It is detailed study of the requirements in order to check whether all the requirements are possible are not.

(II) Tentative planning The resource planning and time planning is temporary done in this section.

(III) Technology selection The lists of all the technologies that are to be used to accomplish the project successfully will be   analyzed listed out hear in this section.

(IV) Requirement analysis

The list of all the requirements like human resources, hardware, software required to accomplish this project successfully will be clearly analyzed and listed out hear in this section.

Proof               The proof of this phase is SRC (Software Requirement Specification).

 

Design phase

Tasks              HLD (High Level Designing)                           LLD (Low Level Designing)

Roles               HLD is done by the CA (Chief Architect).                   LLD is done by the TL  (Technical Lead).

Process

The chief architect will divided the whole project into modules by drawing some diagrams and technical lead will divided each module into sub modules by drawing some diagrams using UML (Unified Modeling Language).

                        The technical lead will also prepare the PSEUDO Code.

Proof               The proof of this phase is technical design document (TDD).

Pseudo Code     It is a set of English instructions used for guiding the developer to develop the actual code easily.

Module

Module is defined as a group of related functionalities to perform a major task.

Coding Phase

Task                Programming / Coding.

Roles               Developers / Programmers.

Process

Developers will develop the actual source code by using the PSUEDO Code and following the coding standards like proper indentation, color-coding, proper commenting and etc…

Proof               The proof of this phase is SCD (Source Code Document).

Testing Phase

Task                Testing.

Roles               Test Engineer.

Process

           

q  First of all the Test Engineer will receive the requirement documents and review it for under studying the requirements.

q  If at all they get any doubts while understanding the requirements they will prepare the Review Report (RR) with all the list of doubts.

q  Once the clarifications are given and after understanding the requirements clearly they will take the test case template and write the test cases.

q  Once the build is released they will execute the test cases.

q  After executions if at all find any defects then they will list out them in a defect profile document.

q  Then they will send defect profile to the developers and wait for the next build.

q  Once the next build is released they will once again execute the test cases

q  If they find any defects they will follow the above procedure again and again till the product is defect free.

q  Once they feel product is defect free they will stop the process.

Proof               The proof of this phase is Quality Product.

Test case        

Test case is an idea of a Test Engineer based on the requirement to test a particular feature.

Delivery and Maintenance phase

Delivery

Task                Installing application in the client environment.

Roles               Senior Test Engineers / Deployment Engineer.

Process           

The senior test engineers are deployment engineer will go to the client place and install the application into the client environment with the help of guidelines provided in the deployment document.

Maintenance

After the delivery if at all any problem occur then that will become a task based on the problem the corresponding roll will be appointed. Based on the problem role will define the process and solve the problem.