JSON : basic introduction and references

JavaScript Object Notation

Used as a lightweight data sharing format in between server and web application, and also in between web applications.

Agile development : manifesto

A group of developers together made a decission depending on their individual views and created the methodology called Agile.

In each development life cycle, it's the learning from the previous iteration and implement to improve the process...

There are 4 major compact principles (we call manifesto) to develop software/product in a better way, which talks as:

DataBase testing

Database testing: validate the front end data with the database.

Let's take an example of a e-commerce application,
user booked a mobile phone by entering phone model, shipping / billing address, and submits, Data stored into database.

Here we need to validate what the user enters data, should save exactly same to the database, then only correct device can be shipped to user.

In real time automation on database testing, user takes test data from external sources (excel or text file), enters detail on web application (then, data stores into database), then compares the external test data with the stored database data.....

Initial setup of MySQL database and it's basic

MySQL is considered to be most popular open source database,

For more information regarding versions and features, please refer http://dev.mysql.com/

Topics

• Download and Install.
• Initial Setup
• Creating database tables
• Adding/updating/deleting data to tables

Difference between Integration and System testing

System testing -

1) It is high level testing and always starts after Integration testing
2) For this testing, complete system is configured in a controlled environment and test cases are developed to simulate real life scenarios.
3) Purpose of this is to validate the application's accuracy and completeness in performing the function as per the requirement.

Integration Testing -

1) It is a lower level testing where testing is done to ensure that the interfaces between the components working as per the requirement.
In every application we intially implement small Sub-functionalities and integrate those...to make it a big functionality...so it is necessary to verify dependencies between the small sub-functionality.

Software LifeCycle

Life Cycles of a software:

SOFTWARE DEVELOPMENT LIFE CYCLE:
CRS (Customer Requirement Specification)
SRS (System Requirement Specification)
Planning & Analysis
Design (High level (In brief) & Low level (In detail))
Coding
Testing
Implementation
Maintenance

SOFTWARE TESTING LIFE CYCLE:
Req Specification
Req Analysis
Test Plan (Schedule, Features to be tested)
Test Cases
Test Execution
Bug Reporting
Retesting
Regression
Test Summary Report

Difference between Regression and Retesting

REGRESSION TESTING -Regression testing is repeated testing of an already tested program in each release or each build after modifications to discover any defects introduced or uncovered as a result of the changes in the product.
RETESTING - Retesting is the testing of a particular module due to the bug fixes,it is basically the act of repeating a test to verify that a found defect (an existing defect which is now fixed) has been correctly functioning.
NOTE - So we can say here retesting is a small part of regression testing in each release.

Software Product - Possible stages to get mistakes & their cost of fixing

Static and Dynamic testing

Static testing:
The Verification activities fall into the category of Static Testing. During static testing, you have a checklist to check whether the work you are doing is going as per the set standards of the organization. These standards can be for Coding, Integrating and Deployment. Review's, Inspection's and Walkthrough's are static testing methodologies
Dynamic testing:
Dynamic Testing involves working with the software, giving input values and checking if the output is as expected. These are the Validation activities. Unit Tests, Integration Tests, System Tests and Acceptance Tests are few of the Dynamic Testing methodologies.

Software testing - V-Model in detail

Almost all organizations follow V-model due to its flexibility structure, it reduces the total duration of the project life cycle as several activities goes in parallel.
When we say several activities goes in parallel means the verification and validation process.
In VERIFICATION(what has to be done) we normally maintain documents (in form of inspections (formal reviews) and walkthroughs (informal review)) which will be followed in whole process of SDLC to ensure we are on the proper track and VALIDATION is the actual implementation of the verification where we test actual product.
Normally when a requirement comes, business analyst analyses the document and then creating business req spec. then planning will be done by the project manager or senior manager and last both Dev and QA team will be notified from where the parallelism of verification and validation comes in to picture.
Once requirement is provided, both QA and Dev work starts where Dev write the code and testers creating the test cases for testing.
In the above diagram,
Verification Phases --> Validation phases
Requirements analysis --> UAT
In this phase, the requirements of the proposed system are collected by analyzing the needs of the user(s). However, it does not determine how the software will be designed or built. Usually, the users are interviewed and a document called the user requirements document is generated. The user requirements document will typically describe the system’s functional, physical, interface, performance, data, security requirements etc as expected by the user, The users carefully review this document as this document would serve as the guideline.
Users who understand the business functions/requirements run the tests as given in the acceptance test plans(requirement analysis phase), including installation and Online help.
System Design --> system testing
normally business analyst analyze and understand the business of the proposed system by studying the user requirements document. They figure out possibilities and techniques by which the user requirements can be implemented. If any of the requirements is not feasible, the user is informed of the issue. A resolution is found and the user requirement document is edited accordingly, this document contains business scenarios, sample windows, reports for the better understanding. Other technical documentation like entity diagrams, data dictionary will also be produced in this phase.
System testing will compare the system specifications against the actual system, The documents prepared in system design phase are helpful to test the system testing in other words system testing test cases prepared at system design phase(verification) but actual testing will be done at system testing phase(validation). .
Architecture Design --> Integration testing
This phase can also be called as high-level design (HLD), Software architecture is commonly represented as two-tier, three-tier or multi-tier models which typically comprises of the database layer, user-interface layer and the application layer. The modules and components representing each layer, operating environment and interfaces are laid out in detail. The output of this phase is the high-level design document which typically consists of the list of modules, brief functionality of each module, their interface relationships, dependencies, database tables, architecture diagrams, technology details etc.
Based on the architectural design (verification), integration testing is carried out in integration testing (validation) phase where separate modules will be tested together expose faults in the interfaces and in the interaction between integrated components.
Module Design --> Unit testing
this phase is also called as low-level design (LLD). The designed system is broken up in to smaller units or modules and each of them is explained so that the programmer can start coding directly. The low level design document or program specifications will contain a detailed functional logic of the module which includes database tables, with all elements, including their type and size - all interface details with complete API, references- all dependency issues- errors, message listings- complete input and outputs for a module. The unit test case design is developed in this stage and the actual testing is done at unit testing phase after coding is done.
Coding-->
This is kept separate/middle as coding starts after all requirements freeze and verification documents finalized and before actual testing of product.
Demerits of V-model –
Requirement freezes once we start v-model as in middle of process we cant change the requirement, so if a product is started to built we need to make sure the requirement is perfect, but in case of big projects requirement keep on changing depend on situation, effects n needs, so in most organization uses Iterative model which is just customized model of v-model where v-model repeats in each release where requirements come inform of change requests or enhancements.

Bug tracking tool - for e.g - Bugzilla

Bugzilla is a very known bug tracking tool where testers normally raise or keep track of bugs in each release of product. It's most essential to know the details of how to raise a new bug or keep track of all the raised bugs so that the testing process become smoother.

Below is the details of bug life cycle of a newly raised bug -

A bug can be raised with status NEW or UNCONFIRMED - NEW - A bug found with proper reference of requirement. UNCONFIRMED - When a bug is found with out any proper requirement or any specific reference or unsure bugs (in this status, developer try to get the design document or can consult with the business analyst to make sure if the bug is valid or not). If it is a valid bug, developer will move the bug to NEW status and takes the responsibility to fix the bug by assigning to him self or if necessary to respective module developer) If it is not a valid bug or no reference found from developer or business analyst, the bug will be moved to INVALID and CLOSED at end of release.

After the bug is in NEW status, it will be ASSIGNED to the respective module developer who try to study the details about the bug and fix the bug - after assigning the bug to the developer, the bug can be either in FIXED (if developer fixes the bug), DUPLICATE (if any existing bug with the same details raised by some other tester), WONTFIX (if the developer team not able to fix the bug), WORKSFORME (if the product is behaving as intended), INVALID (if the bug is bogus), REMIND ME LATER ( if the bug is of less priority or cann't fix in this build or release).

In case of bug is in INVALID/WORKSFORME, it's tester's responsibility to recheck/review the bug details and let the developer know more about the bug if it is really an issue and the tester can REOPEN the bug or else the bug status can be moved to CLOSED status at end of release.

If the bug is FIXED/RESOLVED, tester need to retest the same bug and can move to VERIFIED (if the bug is really fixed) or can move to REOPEN is still having issue after fixing.

NOTE - the above mentioned details are as per my experience, some companies may customize the bug template, almost all the bug tracking tool more or less follow same procedure.

Have fun in breaking the product to raise bugs!!!!!

Difference between Smoke and Sanity testing

Smoke Testing: Normally we perform this to check the stability of the build to deploy in testing environment for further testing. During smoke testing of the software, we do not go into finer details.
The term Smoke testing came at time of developing an electronic chip board, when a electronic chip is made, the developers connect to power supply and check if smoke is coming from that chip or not to make sure that current passes through all the parts of chip or not.

Sanity testing: Sanity testing is testing the application(After receiving a build with a change request or enhancement) to ensure if it is stable enough to continue further testing. If the test fails or any showstopper or critical issue, we cannot continue testing further. Sanity testing is the initial test after the build release.
NOTE - BVT is also called smoke testing or build acceptance testing (BAT)

Software Dev life cycle & software Testing life cycle...

SOFTWARE DEVELOPMENT LIFE CYCLE:

CRS (Customer Requirement Specification)

SRS (System Requirement Specification)

Planning & Analysis

Design (High level (In brief) & Low level (In detail))

Coding

Testing

Implementation

Maintenance

SOFTWARE TESTING LIFE CYCLE:

Req Specification

Req Analysis

Test Plan (Schedule, Features to be tested)

Test Cases

Test Execution

Bug Reporting

Retesting/Regression

Test Summary Report

Sample papers for ISTQB Exam...

get the docs from the below link...
http://docs.google.com/leaf?id=0B1RjrG8wwL_FYzc3NWEzMDktMDIzMC00YjY3LWEyOTgtNWEwZWYyZGU1MTdl&hl=en

ALL THE BEST!!!!

Levels of testing

Unit testing:

The primary goal of unit testing is to take the smallest piece of testable software in the application, isolate it from the remainder of the code, and determine whether it behaves exactly as expected. Each unit is tested separately before integrating them into modules to test the interfaces between modules. Unit testing has proven its value in that a large percentage of defects are identified during its use. The module Interface is tested to ensure that information properly flows into and out of the program unit under test

Integration testing:

Integration testing is a logical extension of unit testing. In its simplest form, two units that have already been tested are combined into a component and the interface between them is tested. A component, in this sense, refers to an integrated aggregate of more than one unit. In a realistic scenario, many units are combined into components, which are in turn aggregated into even larger parts of the program. The idea is to test combinations of pieces and eventually expand the process to test your modules with those of other groups. Eventually all the modules making up a process are tested together. Beyond that, if the program is composed of more than one process, they should be tested in pairs rather than all at once.
Integration testing identifies problems that occur when units are combined. By using a test plan that requires you to test each unit and ensure the viability of each before combining units, you know that any errors discovered when combining units are likely related to the interface between units. This method reduces the number of possibilities to a far simpler level of analysis.
You can do integration testing in a variety of ways but the following are three common strategies:
The top-down approach to integration testing requires the highest-level modules be test and integrated first. This allows high-level logic and data flow to be tested early in the process and it tends to minimize the need for drivers. However, the need for stubs complicates test management and low-level utilities are tested relatively late in the development cycle. Another disadvantage of top-down integration testing is its poor support for early release of limited functionality.
The bottom-up approach requires the lowest-level units be tested and integrated first. These units are frequently referred to as utility modules. By using this approach, utility modules are tested early in the development process and the need for stubs is minimized. The downside, however, is that the need for drivers complicates test management and high-level logic and data flow are tested late. Like the top-down approach, the bottom-up approach also provides poor support for early release of limited functionality.
The third approach, sometimes referred to as the umbrella approach, requires testing along functional data and control-flow paths. First, the inputs for functions are integrated in the bottom-up pattern discussed above. The outputs for each function are then integrated in the top-down manner. The primary advantage of this approach is the degree of support for early release of limited functionality. It also helps minimize the need for stubs and drivers. The potential weaknesses of this approach are significant, however, in that it can be less systematic than the other two approaches, leading to the need for more regression testing.

System testing:

The purpose of integration testing is to detect any inconsistencies between the software units that are integrated together (called assemblages) or between any of the assemblages and the hardware. System testing is a more limiting type of testing; it seeks to detect defects both within the "inter-assemblages" and also within the system as a whole.

Testing + Methods of testing + Techniques

TESTING:

Execution of program with the intend of finding errors & to check the functionality of product, so as to see it needs the requirements of customers.

METHODS OF TESTING:
1. MANUAL
2. AUTOMATION (TESTING DONE BY SOME TOOLS)

TECHNIQUES:

BLACK BOX: 

Checking the functionality of application with out knowing the code in side it (without knowing the implementation),
Normally QA analysts or testers perform this kind of testing.
Even automation testing comes under blackbox testing.

WHITE BOX:

Testing the code block or algorithm or data flow in the application, even we call it as unit testing.
Normally developers perform this kind of testing.

GREY BOX:

White & Black box testing.

Error, Bug, Defect

Simple Wikipedia definition of Bug is: "A computer bug is an error, flaw, mistake, failure, or fault in a computer program that prevents it from working correctly or produces an incorrect result.

Bugs arise from mistakes and errors, made by people, in either a program’s source code or its design."

Other definitions can be:An unwanted and unintended property of a program or piece of hardware, especially one that causes it to malfunction. or a fault in a program, which causes the program to perform in an unintended or unanticipated manner.
Lastly the general definition of bug is: "failure to conform to specifications".

Error: Mistakes by humans.

Bug: failure in software which arise from errors.

Defect: When a bug is found after the product is shipped to market.

Priority & Severity in testing

Severity:

Severity determines the defect's effect on the application.

Severity is given by Testers

Priority: 

Determines the defect urgency of repair.

Priority is given by Test lead or project manager1.

How we define these things