Thursday, 27 January 2011


Software Testing?

Testing in general, is a process carried out by individuals or groups across all domains, where
requirements exist.
Whereas, In more software subjective language, The comparison of EV (expected value ) and
AV (Actual value) is known as testing. 
To get a better understanding of the sentence above , lets see a small example,
example 1. 
I have a bulb , and my requirement is that when i switch it on, it should glow. So My next step is to identify three things
Action to be performed  : turn the Switch on,
Expected value                   : Bulb should glow,
Actual value                        : Present Status of the bulb after performing the action ,( on or off ).
Now its the time for our test to generate a result based on a simple logic,
IF EV = AV then the result is PASS , else Any deviation will make the result as FAIL. 
Now , ideally based on the difference or margin of difference between the EV and AV , The Severity of the defectis  decided and is subjected for further rectifications.
  
  Conclusive Definition of Testing :
        Testing can be defined as the process in which the defects are Identified, Isolated and then subjected for rectification and Re ensuring that the end result is defect free (highest quality) in order to achieve maximum customer satisfaction.  ( An Interview definition. ).

Who can do testing & things to understand ( Pre requirement to understand Software testing effectively)

         As we have understood so far, that testing is a very general task and can be performed by anybody. But we have to understand the importance of software testing first,
In the earlier days of software development, the support for developing the programs was very little. Commercially very few rich companies used advanced software solutions.
As three decades of research and development has passed , IT sector has become sufficient enough to develop advanced software programming for even space exploration.

         Programming languages in the beginning were very complex and were not feasible to achieve larger calculations, Hardware was costly and was very limited in its capacity to perform continuous tasks, and Networking bandwidths was a  gen next topic.
But Now Object oriented Programming languages, Terra bytes of  memory and bandwidths of  hundreds of M bps, are the foundations for future's interactive web generation. Sites like Google, MSN and Yahoo make life much easier to live with Chat , Conferencing and Data management etc.
        
        So coming back to our goal (testing) , We need to realize that Software is here to stay and become a part of mankind. Its the reality of tomorrow and a necessity to be learnt for healthy survival in the coming technological era. More and more companies are spending billions of  cash for achieving the limits and in all these process one thing is attaining its place more prominently which is none other than QUALITY.
    I  used so much of background to stress quality because Its the final and direct goal of Quality assurance people or Test engineers.
  • Quality can be defined as Justification of all of the user's requirements in a product with the presence of value & safety.
So as you can see that quality is a much wider requirement of the masses when it comes to consumption of any service, So the Job of a Tester is to act like a user and verify the product Fit ( defect free = quality ).
  • Defect can be defined as deviation from a users requirement in a particular product or service. So the same product have different level of defects or No defects based on tastes and requirements of different users.
As more and more business solutions are moving from man to machine , both development and testing are headed for an unprecedented boom. Developers are under constant pressure of learning and updating themselves with the latest programming languages to keep up the pace with user's requirements.
    As a result , Testing is also becoming an Integral part of Software companies to produce quality results for beating the competition. Previously developers used to test the applications besides coding, but this had disadvantages , Like time consumption , emotional block to find defects in one's own creation and Post delivery maintenance which is a common requirement now. 
    So Finally Testers have been appointed to simultaneously test the applications along with the development , In order to identify defects as soon as possible to reduce time loss and improve efficiency of the developers.
    Who can do it?  Well, Anyone can do it. You need to be a graduate to enter software testing and comfortable relationship with the PC. All you have to get in your mind is that your job is to act like a third person or end user and taste (test) the food before they eat, and report it to the developer.
We are not correcting the mistake here, we are only identifying the defects and reporting it and waiting for the next release to check whether the defects are rectified and also to see whether new defects have raised.

Some Important terminologies

  • Project :  If something is developed based on a particular user/users requirements, and is used exclusively by them, then it is known as project. The finance is arranged by the client to complete the project successfully.
  • Product :  If something is developed based on company's specification (after a general survey of the market requirements) and can be used by multiple set of masses, then it is known as a product. The company has to fund the entire development and usually expect to break even after a successful market launch.
  • Defect v/s Defective : If the product is justifying partial requirements of a particular customer but is usable functionally, then we say that The product has a defect, But If the product is functionally non usable , then even if some requirements are satisfied, the product still will be tagged as Defective.
  • Quality Assurance : Quality assurance is a process of monitoring and guiding each and every role in the organization in order to make them perform their tasks according to the company's process guidelines.
  • Quality Control or Validation : To check whether the end result is the right product, In other words whether the developed service meets all the requirements or not.   
  • Quality Assurance Verification : It is the method to check whether the developed product or project has followed the right process or guidelines through all the phases of development.   
  •  NCR : Whenever the role is not following the process in performing the task assigned, then the penalty given to him is known as NCR ( Non Confirmacy raised).   
  •  Inspection : Its a process of checking conducted by a group of members on a role or a department suddenly without any prior intimation.   
  •  Audit : Audit is a process of checking conducted on the roles or a department with a prior notice, well in advance.   
  •  SCM : Software configuration management : This is a process carried out by a team to attain the following things Version control and Change control . In other terms SCM team is responsible for updating all the common documents used across various domains to maintain uniformity, and also name the project and update its version numbers by gauzing the amount of change in the application or service after development.  
  • Common Repository : Its a server accessible by authorized users , to store and retrieve the information safely and securely.
  • Base lining vs publishing : Its a process of finalizing the documents vs making it available to all the relevant resources.
  • Release : Its a process of sending the application from the development department to the testing department or from the company to the market.
  • SRN ( Software Release Note ) : Its a note prepared  by the development department and sent to the testing department during the release and it contains information about Path of the build, Installation information, test data, list of known issues, version no, date and credentials etc.,
  • SDN ( Software delivery Note ) : Its a note prepared by a team under the guidance of a Project manager, and will be submitted to the customer during delivery. It contains a carefully crated User manual and list of known issues and workarounds.
  • Slippage : The extra time taken to accomplish a task is known as slippage
  • Metrics v/s Matrix : Clear measurement of any task is defined as metrics, whereas a tabular format with linking information which is used for tracing any information back through references is called as Matrix.
  • Template v/s document : Template is a pre-defined set of questionnaire or  a professional fill in the blanks set up , which is used to prepare an finalize any document. The advantages of template is to maintain uniformity and easier comprehension, throughout all the documentation in a Project, group, department , company or even larger masses.
  • Change Request v/s Impact Analysis : Change request is the proposal of the customer to bring some changes into the project by filling a CRT ( change request template). Whereas Impact analysis is a study carried out by the business analysts to gauze , how much impact will fall on the already developed part of the application and how feasible it is to go ahead with the change or demands of the customer.

    Software Development Life Cycle (SDLC)

        This is a nothing but a model which is used to achieve efficient results in software companies and consists of 6 main phases. We will discuss each stage in a descriptive fashion, dissected into four parts individually, such as Tasks, Roles , Process and Proof of each phase completion. Remember SDLC is similar to waterfall model where the output of one phase acts as the input for the next phase of the cycle.
SDLC Image See references below 
   
     Initial     phase 
    Analysis phase 
    Design    phase
    Coding    phase
    Testing   phase
    Delivery and  Maintenance

       Initial-Phase/Requirements phase :

    Task     :     Interacting with the customer and gathering the requirements
    Roles    :    Business Analyst and  Engagement Manager (EM).
        
    Process : First the BA will take an appointment with the customer, Collects the requirement template, meets the customer , gathers requirements and comes back to the company with the requirements document. 

Then the EM will go through the requirements document . Try to find additional requirements , Get the prototype ( dummy, similar to end product) developed in order to get exact details in the case of unclear requirements or confused customers, and also deal with any excess cost of the project.
Proof : The Requirements document is the proof of completion of the first phase of SDLC .
Alternate names of the Requirements Document :
(Various companies and environments use different terminologies, But the logic is same )
FRS  : Functional Requirements Specification.
CRS : Customer/Client Requirement Specification,
URS : User Requirement Specifications,
BRS : Business Requirement Specifications,
BDD : Business Design Document,
BD : Business Document.

                                               Analysis Phase :

    Tasks    :    Feasibility Study,
Analysis Image references see below 
                           Tentative planning,
                           Technology selection
                           Requirement analysis
    Roles    :    System Analyst (SA)
                          Project Manager (PM)  
                          Technical manager (TM)     
Process :    A detailed study on the requirements and judging the possibilities and scope of the requirements is known as feasibility study. It is done by the Manager level teams usually. After that in the next step we move to a temporary scheduling of staff to initiate the project, Select a suitable technology to develop the project effectively ( customer's choice is given first preference , If it is feasible ).
              And Finally the Hardware, software and  Human resources required are listed out in a document to baseline the project.
Proof        :    The proof document of the analysis phase is SRS ( System Requirement Specification.)

                                                 Design Phase :

    Tasks    :    High level Designing (H.L.D)
                      :    Low level Designing   (L.L.D)
    Roles    :    Chief Architect ( handle HLD )
                     :    Technical lead ( involved in LLD)
Process :    The Chief Architect will divide the whole project into modules by drawing some graphical layouts using Unif[ied Modeling Language (UML). The Technical lead will further divide those modules into sub modules using UML . And both will be responsible for visioning the GUI ( The screen where user interacts with the application OR Graphical User Interface .) and developing the Pseudo code (A dummy code Or usually, Its a set of English Instructions to help the developers in coding the application.)

                                                Coding Phase :

    Task :     Developing the programs
    Roles:     Developers/programmers
Process : The developers will take the support of technical design document and will be following the coding standards, while actual source code is developed. Some of the Industry standard coding methods includeIndentation, Color coding, Commenting etc.
Proof :  The proof document of the coding phase is Source Code Document (SCD).

                                          Testing Phase :

    Task     : Testing
    Roles    : Test engineers, Quality Assurance team.
Process : Since It is the core of our article , we will look at a descriptive fashion of understanding the testing process in an I T environment.
  • First, the Requirements document will be received by the testing department
  • The test engineers will review the requirements in order to understand them.
  • While revising , If at all any doubts arise, then the testers will list out all the unclear requirements in a document named Requirements Clarification Note (RCN).
  • Then they send the RCN to the author of the requirement document ( i.e, Business Analyst ) in order to get the clarifications.
  • Once the clarifications are done and sent to the testing team, they will take the test case template and write the test cases. ( test cases like example1 above).
  • Once the first build is released, they will execute the test cases.
  • While executing the test cases , If at all they find any defects, they will report it in the Defect Profile Document or DPD.
  • Since the DPD is in the common repository, the developers will be notified of the status of the defect.
  • Once the defects are sorted out, the development team releases the next build for testing. And also update the status of defects in the DPD.
  • Testers will here check for the previous defects, related defects, new defects and update the DPD.
Proof : The last two steps are carried out till the product is defect free , so quality assured product is the proof of the testing phase ( and that is why it is a very important stage of SDLC in modern times).

                                            Delivery & Maintenance phase

    Tasks     : Delivery
                       : Post delivery maintenance
    Roles     : Deployment engineers
Process : Delivery : The deployment engineers will go to the customer environment and install the application in the customer's environment & submit the application along with the appropriate release notes to the customer .
                  Maintenance : Once the application is delivered the customer will start using the application, While using if any problem occurs , then it becomes a new task, Based on the severity of the issue corresponding roles and process will be formulated. Some customers may be expecting continuous maintenance, In that case a team of software engineers will be taking care of the application regularly. 
 

    


Software Testing Methods & Levels of Testing.

   There are three methods of testing , Black Box, White Box & Grey box testing, Let's see.
    Black Box testing   :   If one performs testing only on the functional part of an application (where end users can perform actions) without having the structural knowledge, then that method of testing is known as Black box testing. Usually test engineers are in this category. 
    White Box testing   :   If one performs testing on the structural part of the application then that method of testing is known as white box testing. Usually developers or white box testers are the ones to do it successfully. 
    Grey Box testing   :    If one performs testing on both the functional part as well as the structural part of an application, then that method of testing is known as Grey box testing. It's an old way of testing and is not as effective as the previous two methods and is losing popularity recently.

Levels of Testing

There are 5 levels of testing in a software environment. They are as follows,


                                    Image: Systematic & Simultaneous Levels of testing.                                        (The ticked options are the ones where Black box testers are required and the
                                           other performed by the developers usually).         
Unit level testing:  A unit is defined as smallest part of an application. In this level of testing, each and every program will be tested in order to confirm whether the conditions, functions and loops etc are working fine or not. Usually the white box testers or developers are the performers at this level.
Module level testing: A module is defined as a group of related features to perform a major task. At this level the modules are sent to the testing department and the test engineers will be validating the functional part of the modules.
  
Integration level testing: At this level the developers will be developing the interfaces in order to integrate the tested modules. While Integrating the modules they will test whether the interfaces that connect the modules are functionally working or not.
Usually, the developers opt to integrate the modules in the following methods, 
  •    Top down Approach: In this approach the parent modules are developed first and then the corresponding child modules will be developed. In case while integrating the modules if any mandatory module is missing then that is replaced with a temporary program called stub, to facilitate testing.
  •    Bottom up approach: In this approach the child modules will be developed first and will be integrated back to the parent modules. While integrating the modules in this way, if at all any mandatory module is missing, then that module is replaced with a temporary program known as driver to facilitate testing. 
  •    Hybrid or Sandwich approach: In this approach both the TD & BU approaches will be mixed due to several reasons. 
  •    Big Bang approach: In this approach one wait till all the modules are developed and integrate them finally at a time. 
        System Level testing :
        Arguably, the Core of the testing comes in this level. Its a major phase in this testing level, because depending on the requirement and afford-ability of the company, Automation testing, load, performance & stress testing etc will be carried out in this phase which demands additional skills from a tester.
System: Once the stable complete application is installed into an environment, then as a whole it can be called as a system (envt. + Application)      
 At SLS level, the test engineers will perform many different types of testing, but the most Important one is, 
 System Integration Test:  In this type of testing one will perform some actions on the modules that were integrated by the developers in the previous phase, and simultaneously check whether the reflections are proper in the related connected modules.  
Example 2:  Let's take An ATM machine application, with the modules as follows,
 Welcome screen, Balance inquiry screen, Withdrawal screen & Deposit screen.
Assuming that these 4 modules were integrated by the  developers, So black box testers can perform System Integration testing like this :-
      Test case 1:
Check Balance: Let's say amount is X
Deposit amount: Let's say amount is Y
Check balance: Expected Value
If the Actual Value is X + Y, then it is equal to the Expected Value. And because EV = AV, the result is PASS.
User Acceptance Level Testing: 
At this level the user will be invited and in his presence, testing will be carried on. Its the final testing before user signs off and accepts the application. Whatever user may desire, the corresponding features need to be tested functionally by the black box testers or Senior testers in the project.

    


    Types of Testing:

    There are two categories broadly to classify all the available types of testing software. They are Statictesting & Dynamic testing. Static means testing where No actions are performed on the application, and features like GUI and appearance related testing comes under this category. And Dynamic is where user needs to perform some actions on the application to test like functionality checking, link checking etc.
    Initially there were very few popular types of testing, which were lengthy and manual. But as the applications are becoming more and more complex, Its inevitable that, not only features , functionality and appearance but performance and stability also are major areas to be concentrated.
    The following types are the most is use and we will discuss about each of them one by one.
Build Acceptance Test/Verification/Sanity testing (BAT) : Its a type of testing in which one will perform an overall testing on the application to validate whether it is proper for further detailed testing. Usually testing team conducts this in high risk applications before accepting the application from the development department. 
     Other two terms Smoke testing and Sanity testing are in debate from time immemorial to find a fixed definition. Majority feel that If developers test the overall application before releasing to the testing team for further action is known as Smoke testing and future actions performed by black box test engineers is known asSanity testing. But this is cited as vice versa. 
Regression Testing : Its a type of testing in one will perform testing on the already tested functionality again and again. As the name suggests regression is revisiting the same functionality of a feature, but it happens in the following two cases.
     Case1 : When the test engineers find some defects and report it to the developers, The development team fixes the issue and releases the next build. Once the next build is released, as per the requirement the testers will check wether the defect is fixed, and also whether the related features are still working fine which might have been affected while fixing the defect. 
    Example 3:  Lets say that you wanted a bike with 17" tyres instead of 15" and sent the bike to the service center for changing it. Before sending it back for changing, you tested all the other features and you are satisfied with them.  Once the bike is returned to you with new tyres, you will also check the look and feel overall, and check whether the brakes still work as expected, whether the mileage maintains its expected value and all related features that can be affected by this change. Testing the tyre in this case is New testing and all the other features will fall under Regression testing. 
      Case 2 : Whenever some new feature is added to the application in the middle of development, and released for testing. The test engineers may need to check additionally all the related features of the newly added feature. In this case also all the features except the new functionality comes under Regression testing. 
Retesting : Its a type of testing in which one will perform testing on the same functionality again and again with multiple sets of data in order to come to a conclusion whether its working fine or not. 
    Example 4:  Lets say the customer wants a bank application and the login screen must have the password field that only accepts alphanumeric (eg. abc123, 56df etc) data and no special characters ( *,$,# etc). In this case one needs to test the field with all possible combinations and different sets of data to conclude that the password field is working fine. Such kind of repeated testing on any feature is called Retesting.
  
 Alpha Testing  & Beta Testing : These are both performed in the User acceptance testing phase, If the customer visits the company and the comapny's own test engineers perform testing in their own premises, then it is referred as Alpha testing.
If the testing is carried out at the client's environment and is carried out by the end users or third party test experts, then it is known as Beta testing . ( Remember that both these types are before the actual implementation of the software in the clients environment, hence the term user acceptance. )
Installation Testing : Its a type of testing in which one will install the application into the environment by following the guidelines given in the Deployment document / Installation guide. If at all the installation is succesful then one will come to a conclusion that the installation guide and the instructions in it are correct and it is appropriate to install the application, otherwise report the problems in the deployment document.
 One main point is to ensure that, In this type of testing we are checking the user manual and not the product. ( i.e, the installation/setup guide and not the application's capability to install.) 
 Compatibility testing : Its a type of testing in which one will install the application into multiple environments prepared with different combinations or environmental components in order to check whether the application is suitable with those environments or not. Usually this type of testing is carried out on products rather than projects.
 Monkey Testing : Its a type of testing in which Abnormal actions are performed intentionally on the application in order to check the stability of the application. Remember it is different from stress testing or load testing. We are concentrating on the stability of the features and functionality in the case of extreme possibilities of actions performed on the application by different kind of users.
 Useability Testing : In this kind of testing we will check the user freindliness of the application. Depending on the complexity of the application, one needs to test whether information about all the features are understandable easily. Navigation of the application must be easy to follow.
 Exploratory Testing : Its a type of testing in which domain experts ( knowledge of business & functions) will perform testing on the application without having the knowledge of requirements just by parallely exploring the functionality. If you go by the simple definition of exploring, It means having minimum idea about something,  & then doing something related to it in order to know something more about it.
 End to End Testing : Its a type of testing in which we perform testing on various end to end scenarios of an application. Which means performing various operations on the applications like different users in real time scenario.
    Example 5 : Lets take a bank application and consider the different end to end scenarios that exist within the application.  Scenario 1 : Login, Balance enquiry , & Logout.
                        Scenario 2 : Login, Deposit, Withdrawal & logout.
                        Scenario 3 : Login, Balance enquiry, Deposit, Withdrawal, Logout. etc.
 Security Testing : Its a type of testing in which one will test whether the application is a secured application or not. In order to do the same, A black box test engineer will concentrate on the following types of testing.  
  •         Authentication Testing :  It is a type of testing in which one will try to enter into the application by entering different combinations of usernames and passwords in order to check whether the application is allowing only the authorized users or not.
  •         Direct URL testing : It is a type of testing in which one will enter the direct URL's ( Uniform resource locator) of the secured pages and check whether the application is allowing the access to those areas or not.
  •         Firewall Leakage testing : Firewall term is a very widely misunderstood word and  it generally means a barrier between two levels. ' The definition comes from an Old African story where people used to put fire around them while sleeping, in order to prevent red-ants coming near them. ' So In this type of testing, One will enter into the application as one level of user ( ex. member, ) and try to access other higher level of users pages (ex. admin ,) , In order to check whether the firewalls are working fine or not. 
 Port testing: Its a type of testing in which one will install the application into the clients environment and check whether it is compatible with that environment. ( According to the requirements, one needs to find what kind of environment is needed to be tested, whether it is product or project etc .) 
 Soak Testing/Reliability testing : Its a type of testing in which one will perform testing on the application continuosly for long period of time in order to check the stability of the application.    
 Mutation testing : Its a type of testing in which one will perform testing on the application or its related factors by doing some changes to the logics or layers of the environment. (Refer Software environment  for details) Any thing from the functionality of a feature to the applications overall route can be tested with different set of combinations of environment.
 Adhoc testing : Its a type of testing in which the test engineers will perform testing in their own style after understanding the requirements clearly. ( Note that in Exploratory testing the domain experts do not have the knowledge of requirements whereas in this case the test engineers have the expected values set. )

0 comments:

Post a Comment

TrainingHUB. Powered by Blogger.

Total Pageviews

THE BEST QTP TRAINING INSTITUTE IN HYDERABAD

QTP Training in hyderabad

Sql Tutorial

Popular Posts

Our Facebook Page

TrainingHUB

Followers